On Mon, 1 Dec 2025, Benjamin Marzinski wrote:
> On Mon, Dec 01, 2025 at 10:13:10PM +0100, Mikulas Patocka wrote:
> > There is reported 'scheduling while atomic' bug when using dm-snapshot on
> > real-time kernels. The reason for the bug is that the hlist_bl code does
> > preempt_disable() when taking the lock and the kernel attempts to take
> > other spinlocks while holding the hlist_bl lock.
> >
> > Fix this by converting a hlist_bl spinlock into a regular spinlock.
>
> This looks correct, but it will either cause an increase in the memory
> used, or a possible performance hit due to lock contention on a smaller
> number of hash buckets, depending on whether the number of hash buckets
> calculated by the device/chunk size is larger than the new, smaller
> calc_max_buckets() limit. Since calc_max_buckets() limits the memory use
> to 2MB, I suspect that for most devices, this will result in fewer
> buckets (a 2G cow device with a 16K chunk size on a 64bit machine would
> hit the calc_max_buckets() limit of 262144 buckets before. Depending on
> how the kernel is configured, the limit is now likely half that, so cow
> devices of over 1G are likely to start having fewer buckets).
>
> I wonder if we should double the calc_max_buckets() memory limit, or
> perhaps play some #ifdef games so that only real-time kernels are
> effected by this change.
>
> -Ben
On 32-bit architectures, the vmalloc space is limited (to about 128MiB),
so I wouldn't increase the total limit.
Mikulas
