[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.2101211603590.5622@cbobk.fhfr.pm>
Date: Thu, 21 Jan 2021 16:05:52 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: Denis Efremov <efremov@...ux.com>
cc: Jens Axboe <axboe@...nel.dk>, linux-kernel@...r.kernel.org,
linux-block@...r.kernel.org, Wim Osterholt <wim@....tudelft.nl>
Subject: Re: [PATCH RESEND] floppy: fix open(O_ACCMODE) for ioctl-only open
On Thu, 21 Jan 2021, Denis Efremov wrote:
> > From: Jiri Kosina <jkosina@...e.cz>
> > Subject: [PATCH v2] floppy: reintroduce O_NDELAY fix
> >
> > Originally fixed in 09954bad4 ("floppy: refactor open() flags handling")
> > then reverted for unknown reason in f2791e7eadf437 instead of taking
> > the open(O_ACCMODE) for ioctl-only open fix, which had the changelog below
> >
> > ====
> > Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
> > side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that
> > this is being used setfdprm userspace for ioctl-only open().
> >
> > Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE)
> > modes, while still keeping the original O_NDELAY bug fixed.
> >
> > Cc: stable@...r.kernel.org # v4.5+
>
> Are you sure that it's not worth to backport it to LTS v4.4? Because
> f2791e7ead is just a revert and 09954bad4 is not presented in v4.4 I'm
> not sure what fixes tag is better to use in this case.
You are right; I'll drop the '4.5+' indicator and will backport it once/if
it hits Linus' tree.
> > + if (mode & (FMODE_READ|FMODE_WRITE)) {
> > + UDRS->last_checked = 0;
>
> UDRS will still break the compilation here.
Doh, forgot to refresh before sending, sorry for the noise.
I'll send the final version once I get confirmation from the reporter that
it's fixing the issue properly, add his Reported-by: etc.
Thanks,
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists