On 5/14/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> Reviewed-by: Vlastimil Babka <vbabka@xxxxxxx> > --- > > 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 :) > > Thanks, Lorenzo > > include/linux/fs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/fs.h b/include/linux/fs.h > index e2721a1ff13d..09c8495dacdb 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -2248,7 +2248,7 @@ static inline bool file_has_valid_mmap_hooks(struct file *file) > /* Hooks are mutually exclusive. */ > if (WARN_ON_ONCE(has_mmap && has_mmap_prepare)) > return false; > - if (WARN_ON_ONCE(!has_mmap && !has_mmap_prepare)) > + if (!has_mmap && !has_mmap_prepare) > return false; > > return true; > -- > 2.49.0
