linux-kernel - Re: [PATCH v2] floppy: refactor open() flags handling (was Re: mm: uninterruptable tasks hanged on mmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+bwn9jgXApDbCit8CWm1gzxe6PkTsQitcYdr9z=3Ew3jw@mail.gmail.com>
Date:	Fri, 5 Feb 2016 15:26:58 +0100
From:	Dmitry Vyukov <dvyukov@...gle.com>
To:	Jiri Kosina <jikos@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Konstantin Khlebnikov <koct9i@...il.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Takashi Iwai <tiwai@...e.de>,
	syzkaller <syzkaller@...glegroups.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: Re: [PATCH v2] floppy: refactor open() flags handling (was Re: mm:
 uninterruptable tasks hanged on mmap_sem)

On Fri, Feb 5, 2016 at 2:51 PM, Jiri Kosina <jikos@...nel.org> wrote:
> On Fri, 5 Feb 2016, Dmitry Vyukov wrote:
>
>> > could you please feed the patch below (on top of the previous floppy fix)
>> > to your syzkaller machinery and test whether you are still able to
>> > reproduce the problem? It passess my local testing here.
>>
>> Now that open exits early with EWOULDBLOCK, I guess the reproduced is
>> not doing anything particularly interesting.
>
> Yeah. But as I explained in the changelog, I think it's a valid thing to
> do (opinions welcome).
>
> I don't think having a huge discussion about what nonblocking really means
> for floppy and then try to refactor the whole driver to support that would
> make sense.

I don't have any objections. And I agree that it does not make sense
to spend any considerable time on optimizing this driver.


> Alternatively we can take more conservative aproach, accept the
> nonblocking flag, but do the regular business of the driver.
>
> Actually, let's try that, to make sure that we don't introduce userspace
> breakage.
>
> Could you please retest with the patch below?

Reapplied.
Agree that it's better to not bail out on O_NONBLOCK.