[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <rkbycxlik4jcgyebnxqgxues5c4m44rthezk3rqot7ti4mlzkb@dttwxxk7kehk>
Date: Fri, 13 Jun 2025 12:05:50 +0200
From: Jan Kara <jack@...e.cz>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Luis Henriques <luis@...lia.com>, Jan Kara <jack@...e.cz>,
Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-dev@...lia.com
Subject: Re: [PATCH] fs: drop assert in file_seek_cur_needs_f_lock
On Thu 12-06-25 23:35:09, Mateusz Guzik wrote:
> On Thu, Jun 12, 2025 at 8:07 PM Luis Henriques <luis@...lia.com> wrote:
> > > I guess the commit message could be improved. Something like:
> > >
> > > The assert in function file_seek_cur_needs_f_lock() can be triggered very
> > > easily because there are many users of vfs_llseek() (such as overlayfs)
> > > that do their custom locking around llseek instead of relying on
> > > fdget_pos(). Just drop the overzealous assertion.
> >
> > Thanks, makes more sense.
> >
> > Christian, do you prefer me to resend the patch or is it easier for you to
> > just amend the commit? (Though, to be fair, the authorship could also be
> > changed as I mostly reported the issue and tested!)
> >
>
> How about leaving a trace in the code.
>
> For example a comment of this sort in place of the assert:
> Note that we are not guaranteed to be called after fdget_pos() on this
> file obj, in which case the caller is expected to provide the
> appropriate locking.
I'm not opposed to that.
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists