On Mon, Feb 23, 2026 at 08:25:38PM +0100, Mikulas Patocka wrote:
>
>
> On Mon, 23 Feb 2026, Vishal Moola (Oracle) wrote:
>
> > On Thu, Feb 12, 2026 at 05:33:30PM +0100, Mikulas Patocka wrote:
> > > The commit 07003531e03c8 ("mm/vmalloc: warn on invalid vmalloc gfp
> > > flags") breaks the device mapper VDO target. The VDO target calls vmalloc
> > > with __GFP_RETRY_MAYFAIL and this flag is not in the mask of allowed
> > > flags.
> > >
> > > There is no reason why vmalloc couldn't support __GFP_RETRY_MAYFAIL, so
> > > let's add this flag to GFP_VMALLOC_SUPPORTED.
> >
> > My only skepticism about this comes from the line in the
> > vmalloc_node_range() doc:
> > "and %__GFP_RETRY_MAYFAIL are not supported."
> >
> > I myself don't know why that may be. Could you elaborate on if/why the
> > doc is wrong please?
>
> This statement was added by Michal Hocko in the commit
> b7d90e7a5ea8d64e668d5685925900d33d3884d5. Michal, could you explain why do
> you think that __GFP_RETRY_MAYFAIL is not supported?
>
> The VDO module needs to allocate large amounts of memory and it doesn't
> want to trigger the OOM killer (which would kill some innocent task and
> wouldn't solve the out of memory condition at all), so I think that
> __GFP_RETRY_MAYFAIL is appropriate.
>
I do not see any problems using this with vmalloc from the first glance.
KASAN path was hard-coded when it comes to GFP but it is not anymore.
--
Uladzislau Rezki
