This is a note to let you know that I've just added the patch titled

    USB: kaweth.c: use GFP_ATOMIC under spin_lock

to the 3.0-stable tree which can be found at:
    
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     usb-kaweth.c-use-gfp_atomic-under-spin_lock.patch
and it can be found in the queue-3.0 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.


>From 32a2b80371e48f11c6316b18009a1020641287b0 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <[email protected]>
Date: Fri, 27 Jul 2012 01:46:51 +0000
Subject: USB: kaweth.c: use GFP_ATOMIC under spin_lock


From: Dan Carpenter <[email protected]>

[ Upstream commit e4c7f259c5be99dcfc3d98f913590663b0305bf8 ]

The problem is that we call this with a spin lock held.  The call tree
is:
        kaweth_start_xmit() holds kaweth->device_lock.
        -> kaweth_async_set_rx_mode()
           -> kaweth_control()
              -> kaweth_internal_control_msg()

The kaweth_internal_control_msg() function is only called from
kaweth_control() which used GFP_ATOMIC for its allocations.

Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
 drivers/net/usb/kaweth.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/usb/kaweth.c
+++ b/drivers/net/usb/kaweth.c
@@ -1308,7 +1308,7 @@ static int kaweth_internal_control_msg(s
         int retv;
         int length = 0; /* shut up GCC */
 
-        urb = usb_alloc_urb(0, GFP_NOIO);
+       urb = usb_alloc_urb(0, GFP_ATOMIC);
         if (!urb)
                 return -ENOMEM;
 


Patches currently in stable-queue which might be from [email protected] 
are

queue-3.0/usb-kaweth.c-use-gfp_atomic-under-spin_lock.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to