linux-kernel - Re: [PATCH] fs: Preserve error code in get_empty

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: <20130215022134.GA11376@ZenIV.linux.org.uk>
Date:	Fri, 15 Feb 2013 02:21:35 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Anatol Pomozov <anatol.pomozov@...il.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Louis Huemiller <lhuemill@...gle.com>
Subject: Re: [PATCH] fs: Preserve error code in get_empty_filp()

On Fri, Oct 05, 2012 at 11:16:12AM -0700, Anatol Pomozov wrote:
> Hi, AlViro
> 
> Is any reason why this change is ignored? For me it looks like a
> straightforward bugfix.
> 
> A little bit of context for this change. We at Google work on a test
> framework that shows how kernel behaves under memory pressure. In the
> codepath that I am fixing the syscalls return ENFILE error, but in
> fact the correct error would be ENOMEM. get_empty_filp() should
> preserve the original error and not to replace all errors with ENFILE.

The trouble is, you are introducing previously impossible return values
for pipe(2).  The rest of it is probably OK (even though I'd prefer to
split get_empty_filp() part into a separate commit), but this one has
potential for breaking previously correct userland code.  OTOH, FreeBSD has
done that a while ago and they apparently had been able to cope with the
fallout.

I'll put that thing sans the fs/pipe.c part in for-next, but IMO the
change of pipe(2) shouldn't go in at the moment.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/