lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 21 Aug 2014 16:31:53 -0700 (PDT) From: David Miller <davem@...emloft.net> To: chas@....nrl.navy.mil Cc: netdev@...r.kernel.org, linux-atm-general@...ts.sourceforge.net Subject: Re: [PATCH net-next] lec: Use rtnl lock/unlock when updating MTU From: "Chas Williams (CONTRACTOR)" <chas@....nrl.navy.mil> Date: Thu, 14 Aug 2014 20:56:27 -0400 > In message <20140814.143706.1833450188258591738.davem@...hat.com>,David Miller writes: >>From: Chas Williams - CONTRACTOR <chas@....nrl.navy.mil> >>Date: Thu, 14 Aug 2014 09:19:47 -0400 >> >>> The LECS response contains the MTU that should be used. Correctly >>> synchronize with other layers when updating. >>> >>> Signed-off-by: Chas Williams - CONTRACTOR <chas@....nrl.navy.mil> >> >>I don't think you can sleep from this function, which rtnl_lock() may >>require. Look elsewhere in this routine, it's doing GFP_ATOMIC >>allocations even. > > Its been a while but... > > This is the send routine for a virtual atm device that is the control > interface bewteen the user space client and the kernel. The user space > client creates an atm socket and uses an ioctl to connect that atm socket > to the this virtual device. So the call path is something like: > > sendmsg() -> vcc_sendmsg() -> virtual atm device.send() > > Generally speaking, you can't sleep in the send routine of an atm device > since there are other potential users besides sockets. > > The GFP_ATOMIC usage is probably a lack of understanding. The other > IRQ level locks are necessary for coordination. Ok, that makes sense, thanks for explaining the context in which this is invoked. Patch applied, thanks again. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists