linux-kernel - Re: [PATCH] ext2: reduce redundant check of '*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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20110118134345.GC3138@thunk.org>
Date:	Tue, 18 Jan 2011 08:43:45 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Jan Kara <jack@...e.cz>
Cc:	Simon Xu <xu.simon@...cle.com>, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ext2: reduce redundant check of '*options'

On Mon, Jan 17, 2011 at 06:02:03PM +0100, Jan Kara wrote:
> Seriously, if you want to do some useful fixing then have a look for
> example at making ext3/4 (in fact JBD/JBD2) handle transaction allocation
> failures gratefully.  Currently we just loop in start_this_handle()
> infinitely until we can make the allocation which is a bit dumb. So it
> would be good, to make as many places as possible able to handle ENOMEM
> from start_this_handle() and propagate the error to user space. In some
> cases, it might not be easily possible (e.g. during writeout of dirty
> memory, where proper handling needs more thought) but lots of cases
> should be rather simple and need just auditing the code paths. Thanks.

Uh, this is actually a rather subtle set of fixes that you are
proposing, because it won't be obvious to someone who hasn't paid very
careful attention to who calls certain functions (i.e., such as the
writepages function), which get propagated to user space, and which
will just cause mysterious data corruption of files --- especially
since the writeback daemon doesn't check error returns (!!!).  So if
someone changed writepages to return ENOMEM, and then said, "How
delightful!  My work is done...", it would result in nothing getting
back to userspace in most cases, and the writeback code would mark the
pages as clean, and on the next reboot, the data would be lost.

So this is *not* a change that I would recommend to people who are
just beginning to learn how to program the kernel, and have been
taught by some kernel programmers that the best thing to do is to take
trivial-style changes and submit them upstream.

					- Ted
--
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/