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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <e7d0226a-9a38-4ce9-a9b5-7bb80a19bff6@lunn.ch> Date: Sat, 18 Nov 2023 16:32:26 +0100 From: Andrew Lunn <andrew@...n.ch> To: Boqun Feng <boqun.feng@...il.com> Cc: Greg KH <gregkh@...uxfoundation.org>, Alice Ryhl <aliceryhl@...gle.com>, fujita.tomonori@...il.com, benno.lossin@...ton.me, miguel.ojeda.sandonis@...il.com, netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, tmgross@...ch.edu, wedsonaf@...il.com Subject: Re: [PATCH net-next v7 1/5] rust: core abstractions for network PHY drivers > One example of not `Send` type (or `!Send`) is spinlock guard: > > let guard: Guard<..> = some_lock.lock(); > > creating a Guard means "spin_lock()" and dropping a Guard means > "spin_unlock()", since we cannot acquire a spinlock in one context and > release it in another context in kernel, so `Guard<..>` is `!Send`. Thanks for the explanation. Kernel people might have a different meaning for context, especially in this example. We have process context and atomic context. Process context you are allowed to sleep, atomic context you cannot sleep. If you are in process context and take a spinlock, you change into atomic context. And when you release the spinlock you go back to process context. So with this meaning of context, you do acquire the spinlock in one context, and release it in another. So we are going to have to think about the context the word context is used in, and expect kernel and Rust people to maybe think of it differently. Andrew
Powered by blists - more mailing lists