[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250428134231.3215496-1-lizhi.xu@windriver.com>
Date: Mon, 28 Apr 2025 21:42:31 +0800
From: Lizhi Xu <lizhi.xu@...driver.com>
To: <hch@...radead.org>
CC: <axboe@...nel.dk>, <linux-block@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <lizhi.xu@...driver.com>,
<ming.lei@...hat.com>,
<syzbot+6af973a3b8dfd2faefdc@...kaller.appspotmail.com>,
<syzkaller-bugs@...glegroups.com>
Subject: Re: [PATCH V3] loop: Add sanity check for read/write_iter
On Mon, 28 Apr 2025 05:49:20 -0700, Christoph Hellwig wrote:
> > +static int loop_check_backing_file(struct file *file, blk_mode_t mode, bool change)
> > +{
> > + if (!file->f_op->read_iter)
> > + return -EINVAL;
> > +
> > + if (((file->f_mode & FMODE_WRITE) ||
> > + (!change && (mode & BLK_OPEN_WRITE))) &&
> > + (!file->f_op->write_iter))
> > + return -EINVAL;
>
> This looks a bit odd. Both callers have the open struct file, so
> we should be able to check f_mode for both cases and not need the
> change flag as far as I can tell. Or did I miss something/
Changing flags? What are you talking about?
This patch is to fix filesystems that are missing read_iter or wirte_iter
support.
>
> If for some reason we could not pass the fmode, the helper is
> probably not all that useful.
The helper function does not pass fmode, but passes 'blk_mode_t mode',
because it is used when executing LOOP_SET_FD or LOOP_CONFIGURE, but not
when executing LOOP_CHANGE_FD.
I think the purpose of this helper function is just to facilitate code
management and facilitate similar problems later.
Powered by blists - more mailing lists