search for: rtnl

...? > > > And when timeout expires, set FAILED bit in device status? > > > > virtio spec does not set any limits on the timing of vq > > processing. > > Indeed, but I thought the driver could decide it is too long for it. > > The issue is we keep waiting with rtnl locked, it can quickly make the > system unusable. if this is a problem we should find a way not to keep rtnl locked indefinitely. > > > > 2- still handle surprise removal correctly by waking in that case > > > > > > > > > > > > > > >...

...report errors back. > > But if they do they can always set this flag too. > > This may have false negatives and may confuse the management. > > Maybe we can extend the networking core to allow some device specific > configurations to be done with device specific lock without rtnl. For > example, split the set_channels to > > pre_set_channels > set_channels > post_set_channels > > The device specific part could be done in pre and post without a rtnl lock? > > Thanks Would the benefit be that errors can be reported to userspace then? Then maybe...

...ould it make sense to also have a timeout? >> And when timeout expires, set FAILED bit in device status? > > virtio spec does not set any limits on the timing of vq > processing. Indeed, but I thought the driver could decide it is too long for it. The issue is we keep waiting with rtnl locked, it can quickly make the system unusable. >>> 2- still handle surprise removal correctly by waking in that case >>> >>> >>> >>>>> --- >>>>> drivers/net/virtio_net.c | 4 +++- >>>>> 1 file changed, 3 inse...

...ls setting and refill) > > Cc: Rusty Russell <rusty at rustcorp.com.au> > Cc: Michael S. Tsirkin <mst at redhat.com> > Signed-off-by: Jason Wang <jasowang at redhat.com> It bothers me that we look at the flag without any locks here. I think we'll need to take the rtnl lock at least on restore. > --- > The patch were need for 3.10 and above. > --- > drivers/net/virtio_net.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index c4bc1cc..92f0096 100644 >...

...ls setting and refill) > > Cc: Rusty Russell <rusty at rustcorp.com.au> > Cc: Michael S. Tsirkin <mst at redhat.com> > Signed-off-by: Jason Wang <jasowang at redhat.com> It bothers me that we look at the flag without any locks here. I think we'll need to take the rtnl lock at least on restore. > --- > The patch were need for 3.10 and above. > --- > drivers/net/virtio_net.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index c4bc1cc..92f0096 100644 >...

...), 29 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 7b187ec..3d0eff53 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -147,6 +147,17 @@ struct receive_queue { struct xdp_rxq_info xdp_rxq; }; +/* Control VQ buffers: protected by the rtnl lock */ +struct control_buf { + struct virtio_net_ctrl_hdr hdr; + virtio_net_ctrl_ack status; + struct virtio_net_ctrl_mq mq; + u8 promisc; + u8 allmulti; + u16 vid; + u64 offloads; +}; + struct virtnet_info { struct virtio_device *vdev; struct virtqueue *cvq; @@ -192,14 +203,7 @@ struct virtn...

There is an new minor update to iproute2 utilities available: http://developer.osdl.org/dev/iproute2/download/iproute2-050929.tar.gz Also, this (and future) releases are now signed, for key info read: http://developer.osdl.org/dev/iproute2/signature.html [Stephen Hemminger] Fix uninitialized memory and leaks Add -batch option to ip. Update to 2.6.14 headers [Arnaldo] Integrate

...0 0.0 212048 4532 ? Ss 13:34 0:00 /usr/bin/abrt-watch-log -F BUG: WARNING: at WARNING: CPU: INFO: possible recursive locking detected ernel BUG at list_del corruption list_add corruption do_IRQ: stack overflow: ear stack overflow (cur: eneral protection fault nable to handle kernel ouble fault: RTNL: assertion failed eek! page_mapcount(page) went negative! adness at NETDEV WATCHDOG ysctl table check failed : nobody cared IRQ handler type mismatch Machine Check Exception: Machine check events logged divide error: bounds: coprocessor segment overrun: invalid TSS: segment not present: invalid...

...es tries to use sleep instead of busy polling. In this version, I take a step back: the hardening part is not implemented and leave for future investigation. We use to aggree to use interruptible sleep but it doesn't work for a general workqueue. Please review. Thanks Changes since V1: - use RTNL to synchronize rx mode worker - use completion for simplicity - don't try to harden CVQ command Changes since RFC: - switch to use BAD_RING in virtio_break_device() - check virtqueue_is_broken() after being woken up - use more_used() instead of virtqueue_get_buf() to allow caller to get buf...

...;maxime.coquelin at redhat.com> For the potential missing interrupt with non-compliant devices, I guess it could be handled with the hardening work as same thing could happen if the VDUSE application crashed for example. Regards, Maxime [0]: > Thanks > > Changes since V1: > - use RTNL to synchronize rx mode worker > - use completion for simplicity > - don't try to harden CVQ command > > Changes since RFC: > > - switch to use BAD_RING in virtio_break_device() > - check virtqueue_is_broken() after being woken up > - use more_used() instead of virtqueu...

...+), 29 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 7b187ec..82f50e5 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -147,6 +147,17 @@ struct receive_queue { struct xdp_rxq_info xdp_rxq; }; +/* Control VQ buffers: protected by the rtnl lock */ +struct control_buf { + struct virtio_net_ctrl_hdr hdr; + virtio_net_ctrl_ack status; + struct virtio_net_ctrl_mq mq; + u8 promisc; + u8 allmulti; + u16 vid; + u64 offloads; +}; + struct virtnet_info { struct virtio_device *vdev; struct virtqueue *cvq; @@ -192,14 +203,7 @@ struct virtn...

...1281 0 1 May01 ? 00:00:01 /usr/bin/abrt-watch-log -F BUG: WARNING: at WARNING: CPU: INFO: possible recursive locking detected ernel BUG at list_del corruption list_add corruption do_IRQ: stack overflow: ear stack overflow (cur: eneral protection fault nable to handle kernel ouble fault: RTNL: assertion failed eek! page_mapcount(page) went negative! adness at NETDEV WATCHDOG ysctl table check failed : nobody cared IRQ handler type mismatch Kernel panic - not syncing: Machine Check Exception: Machine check events logged divide error: bounds: coprocessor segment overrun: invalid TSS: segm...

...esched() in the waiting loop. Before doing this we need first make sure the cvq command is not executed in atomic environment, so we need first convert rx mode handling to a workqueue. Please review. Thanks Changes since V2: - Don't use interrupt but cond_resched() Changes since V1: - use RTNL to synchronize rx mode worker - use completion for simplicity - don't try to harden CVQ command Changes since RFC: - switch to use BAD_RING in virtio_break_device() - check virtqueue_is_broken() after being woken up - use more_used() instead of virtqueue_get_buf() to allow caller to get buf...

...the kernel tree, but this function seems like a > > weakness in the virtio-crypto device. > > > The control queues of virtio-net and virtio-console are also be locked > Please see: > __send_control_msg() in virtio_console.c and virtio-net's control queue > protected by rtnl lock. > > I didn't want to protect session creations but the virtqueue's operations > like what other virtio devices do. > > > While QEMU is servicing the create session command this vcpu is blocked. > > The QEMU global mutex is held so no other vcpu can enter QEMU...

...the kernel tree, but this function seems like a > > weakness in the virtio-crypto device. > > > The control queues of virtio-net and virtio-console are also be locked > Please see: > __send_control_msg() in virtio_console.c and virtio-net's control queue > protected by rtnl lock. > > I didn't want to protect session creations but the virtqueue's operations > like what other virtio devices do. > > > While QEMU is servicing the create session command this vcpu is blocked. > > The QEMU global mutex is held so no other vcpu can enter QEMU...

...to use cond_resched() in the waiting loop. Before doing this we need first make sure the cvq command is not executed in atomic environment, so we need first convert rx mode handling to a workqueue. Note that, this doesn't try to solve the case that a malicous device may block networking stack (RTNL) or break freezer which requries more thought to gracefully exit and resend the commands. Please review. Changes since V3: - Tweak the comments - Tweak the changelog to explain the rx mode lost after resuming. - No functional changes Changes since V2: - Don't use interrupt but cond_resched...

...0 10:51:05 -07:00 +++ b/net/bridge/br_ioctl.c 2004-05-20 10:51:05 -07:00 @@ -27,14 +27,43 @@ ? jiffies_to_clock_t(timer->expires - jiffies) : 0; } -int br_ioctl_device(struct net_bridge *br, unsigned int cmd, - unsigned long arg0, unsigned long arg1, unsigned long arg2) +/* called with RTNL */ +static int get_bridge_ifindices(int *indices, int num) { - if (br == NULL) - return -EINVAL; + struct net_device *dev; + int i = 0; - switch (cmd) - { + for (dev = dev_base; dev && i < num; dev = dev->next) { + if (dev->priv_flags & IFF_EBRIDGE) + indices[i++] = dev...

This patch convert rx mode setting to be done in a workqueue, this is a must for allow to sleep when waiting for the cvq command to response since current code is executed under addr spin lock. Signed-off-by: Jason Wang <jasowang at redhat.com> --- Changes since V1: - use RTNL to synchronize rx mode worker --- drivers/net/virtio_net.c | 55 +++++++++++++++++++++++++++++++++++++--- 1 file changed, 52 insertions(+), 3 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 56ca1d270304..5d2f1da4eaa0 100644 --- a/drivers/net/virtio_net.c +++ b/...

...ss then: > > > > > >>> 1- debugging. Currently it's easy to see a warning if CPU is stuck > > > > > >>> in a loop for a while, and we also get a backtrace. > > > > > >>> E.g. with this - how do we know who has the RTNL? > > > > > >>> We need to integrate with kernel/watchdog.c for good results > > > > > >>> and to make sure policy is consistent. > > > > > >> > > > > > >> That's fine, will consider this. > &g...

...gt; > > > > >>> 1- debugging. Currently it's easy to see a warning if CPU is stuck > > > > > > >>> in a loop for a while, and we also get a backtrace. > > > > > > >>> E.g. with this - how do we know who has the RTNL? > > > > > > >>> We need to integrate with kernel/watchdog.c for good results > > > > > > >>> and to make sure policy is consistent. > > > > > > >> > > > > > > >> That's fine, will co...