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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZVjePqyic7pvcb24@Boquns-Mac-mini.home>
Date: Sat, 18 Nov 2023 07:54:38 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: Andrew Lunn <andrew@...n.ch>
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

On Sat, Nov 18, 2023 at 04:32:26PM +0100, Andrew Lunn wrote:
> > 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

Surely *we* do, and looks like I created more confusion ;-) Maybe I
should say "execution context" as in include/linux/preempt.h: NMI, hard
IRQ, softirq, task.

> 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.
> 

Also as I tried to explain previously, the type of contexts doesn't
matter. Yes, once you hold a spinlock, you enter atomic context, but you
are still in the same task execution context, so acquiring and releasing
in the same task execution doesn't count as "Sending". But if after
acquired one somehow passes the guard to another task, or an interrupt
handler, that's "Sending".

> 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.
> 

In Rust doc [1], `Send` means:

	Types that can be transferred across thread boundaries.

but of course, we have more "thread-like" things in kernel, so I think
"execution context" may be a better term?

[1]: https://doc.rust-lang.org/core/marker/trait.Send.html

Regards,
Boqun

> 	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ