linux-kernel - Re: [PATCH] fs: Correct SuS compliance for open of large file without options

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 27 Sep 2007 10:23:43 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Theodore Tso <tytso@....edu>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jens Axboe <jens.axboe@...cle.com>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] fs: Correct SuS compliance for open of large file
 without options

On Thu, 27 Sep 2007 11:59:02 -0400 Theodore Tso <tytso@....edu> wrote:

> On Thu, Sep 27, 2007 at 04:19:12PM +0100, Alan Cox wrote:
> > > Well it's not my call, just seems like a really bad idea to change the
> > > error value. You can't claim full coverage for such testing anyway, it's
> > > one of those things that people will complain about two releases later
> > > saying it broke app foo.
> > 
> > Strange since we've spent years changing error values and getting them
> > right in the past. 
> 
> I doubt there any apps which are going to specifically check for EFBIG
> and do soemthing different if they get EOVERFLOW instead.  If it was
> something like EAGAIN or EPERM, I'd be more concerned, but EFBIG
> vs. EOVERFLOW?  C'mon!

Yeah.  There's no correct answer here (apart from "get it right the first
time").  There are risks either way, and it _is_ a bug.  Bummer.

> > There are real things to worry about - sysfs, sysfs, sysfs, ... and all
> > the other crap which is continually breaking stuff, not spec compliance
> > corrections that don't break things but move us into compliance with the
> > standard
> 
> I've got to agree with Alan, the sysfs/udev breakages that we've done
> are far more significant, and the fact that we continue to expose
> internal data structures via sysfs is a gaping open pit is far more
> likely to cause any kind of problems than changing an error return.

Funny you should mention that.  I was staring in astonishment at the
pending sysfs patch pile last night.  Forty syfs patches and twenty-odd
patches against driver core and the kobject layer.

That's a huge amount of churn for a core piece of kernel infrastructure
which has been there for four or five years.  Not a good sign.  I mean,
it's not as if, say, the CPU scheduler guys keep on rewriting all their
junk.

oh, wait..
-
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/