Andrew: (to save you having to dive into rest of thread) Could you add the Fixes line suggested by David below? Thanks! :) On Wed, May 14, 2025 at 10:49:57AM +0200, David Hildenbrand wrote: > On 14.05.25 10:40, Lorenzo Stoakes wrote: > > Having encountered a trinity report in linux-next (Linked in the 'Closes' > > tag) it appears that there are legitimate situations where a file-backed > > mapping can be acquired but no file->f_op->mmap or file->f_op->mmap_prepare > > is set, at which point do_mmap() should simply error out with -ENODEV. > > > > Since previously we did not warn in this scenario and it appears we rely > > upon this, restore this situation, while retaining a WARN_ON_ONCE() for the > > case where both are set, which is absolutely incorrect and must be > > addressed and thus always requires a warning. > > > > If further work is required to chase down precisely what is causing this, > > then we can later restore this, but it makes no sense to hold up this > > series to do so, as this is existing and apparently expected behaviour. > > > > Reported-by: kernel test robot <oliver.sang@xxxxxxxxx> > > Closes: https://lore.kernel.org/oe-lkp/202505141434.96ce5e5d-lkp@xxxxxxxxx > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> > > --- > > > > Andrew - > > > > Since this series is in mm-stable we should take this fix there asap (and > > certainly get it to -next to fix any further error reports). I didn't know > > whether it was best for it to be a fix-patch or not, so have sent > > separately so you can best determine what to do with it :) > > A couple more days in mm-unstable probably wouldn't have hurt here, > especially given that I recall reviewing + seeing review yesterday? > > Fixes: c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file callback") > > Acked-by: David Hildenbrand <david@xxxxxxxxxx> > > -- > Cheers, > > David / dhildenb >
