Franck LENORMAND wrote:
> The capacity to generate or load keys already available in the Linux key
> retention service does not allows to exploit CAAM capabilities hence we
> need to create a new key_type. The new key type "caam_tk" allows to:
> - Create a black key from random
> - Create a bla
Peter Zijlstra wrote:
> I tried using wake_up_var() today and accidentally noticed that it
> didn't imply an smp_mb() and specifically requires it through
> wake_up_bit() / waitqueue_active().
Thinking about it again, I'm not sure why you need to add the barrier when
wake_up() (which this is a w
Looking at:
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.10&id=3b0ef9ade65e299a8c13df5fe70352360c6bd05c
Reviewed-by: David Howells
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Can I get a cc on the original patch?
David
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Arnd Bergmann wrote:
> From what I can tell, neither of the two are called in atomic context, so
> you should be able to use a GFP_KERNEL allocation.
You need to be careful doing that since the allocation might happen in the AFS
writeback path. I use GFP_NOIO or GFP_NOFS in rxkad.c and skb_cow_
Hi,
With 6.5-rc2 (6.5.0-0.rc2.20230721gitf7e3a1bafdea.20.fc39.x86_64), I'm seeing
a bunch of processes getting stuck in the D state on my desktop after a few
hours of reading email and compiling stuff. It's happened every day this week
so far and I managed to grab stack traces of the stuck proces
