Re: git: 14dcd4098374 - main - linuxkpi: `GFP_KERNEL` equals `M_NOWAIT` now

On Fri, Nov 24, 2023 at 05:31:54PM +0000, Jean-SébastienPédron wrote:
> The branch main has been updated by dumbbell:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=14dcd40983748596d116d91acb934a8a95ac76bc
> 
> commit 14dcd40983748596d116d91acb934a8a95ac76bc
> Author:     Jean-Sébastien Pédron <dumbbell@FreeBSD.org>
> AuthorDate: 2023-11-24 17:30:33 +0000
> Commit:     Jean-Sébastien Pédron <dumbbell@FreeBSD.org>
> CommitDate: 2023-11-24 17:31:32 +0000
> 
>     linuxkpi: `GFP_KERNEL` equals `M_NOWAIT` now
>     
>     ... instead of `M_WAITOK`.
>     
>     [Why]
>     The reason is that in some places in the DRM drivers (in particular, the
>     framebuffer management code), kmalloc() is called from a non-sleepable
>     context, such as after a call to mtx_lock(8) with an MTX_DEF mutex.
>     
>     If `GFP_KERNEL` is defined as `M_WAITOK`, we hit an assertion from
>     witness(4).
>     
>     [How]
>     The definition of `GFP_KERNEL` is changed to `M_NOWAIT`. This means that
>     callers should verify the return value of kmalloc(). Fortunately, this
>     is always the case in Linux.
>     
>     Reviewed by:    bz, emaste, manu
>     Approved by:    manu
>     Differential Revision:  https://reviews.freebsd.org/D42054

Unfortunately this broke even attach of the mlx5(4) driver.
According to the 'official' Linux kernel documentation, the GFP_KERNEL
flag implies sleepable context.  mlx5_core uses the passed GFP flag to
determine if it is called in the sleepable context, and now even initial
load assumes that it cannot perform sleeping ops.  See, for instance,
second if() statement in the mlx5_fwp_alloc() function.

I think that it is more likely that use of (FreeBSD) mutex should be
replaced by sx somewhere in DRM than to try to push all possible fixes
for this change.