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  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]
Date:	Tue, 16 Sep 2014 09:44:57 -0400
From:	Jeff Moyer <>
To:	Milosz Tanski <>
Cc:	LKML <>,
	Christoph Hellwig <>,
	"linux-fsdevel\" <>,, Mel Gorman <>,
	Volker Lendecke <>,
	Tejun Heo <>,
Subject: Re: [RFC PATCH 0/7] Non-blockling buffered fs read (page cache only)

Milosz Tanski <> writes:

> Jeff,
> This patchset creates a new read (readv2/preadv2) syscall(s) that take
> a extra flag argument (kind of like recvmsg). What it doesn't do is
> change the current behavior of of the O_NONBLOCK, if the file is
> open() with O_NONBLOCK flag. It shouldn't break any existing
> applications since you have to opt into using this by using the new
> syscall.

Hi, Milosz,

Ah, I misread one of the patches.  Now that I've applied the series, I
see that you're testing the flag argument, not the file open flags.

> I don't have a preference either way if we should create a new flag or
> re-use O_NONBLOCK the flag. Instead, I'm hoping to get some consensus
> here from senior kernel developers like yourself. Maybe a RWF_NONBLOCK
> (I'm stealing from eventfd, EFD_NONBLOCK).

I think I'd rather name the flag something other than O_NONBLOCK, if for
no other reason that to avoid confusion.

> As a side note, I noticed that EFD_NONBLOCK, SFD_NONBLOCK, etc... all
> alias to the value of O_NONBLOCK and there's a bunch of bug checks in
> the code like this:

That's because the flag is passed on to anon_inode_getfile.  See also
this define:


A general note on your subjects -- you should make them more specific to
the subsystem you're updating.  Commit titles like "documentation
update" are a bit too broad.  ;-)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists