linux-kernel - Re: [PATCH] reiserfs: Truncate blocks not used by a write (v2)

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]

Date:	Thu, 17 Sep 2009 02:56:34 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	Jan Kara <jack@...e.cz>, linux-kernel@...r.kernel.org,
	hch@...radead.org, reiserfs-devel@...r.kernel.org, jeffm@...e.com
Subject: Re: [PATCH] reiserfs: Truncate blocks not used by a write (v2)

On Wed, Sep 16, 2009 at 02:48:15PM -0700, Andrew Morton wrote:
> On Wed, 16 Sep 2009 19:25:12 +0200
> Jan Kara <jack@...e.cz> wrote:
> 
> > It can happen that write does not use all the blocks allocated in write_begin
> > either because of some filesystem error (like ENOSPC) or because page with
> > data to write has been removed from memory. We truncate these blocks so that
> > we don't have dangling blocks beyond i_size.
> 
> This clashes a bit with the kill-the-bkl/reiserfs stuff in linux-next.

Note that the kill-the-bkl/reiserfs tree has suffered from too much
lock inversion problems lately. Even though I just fixed the last one
reported, I would feel more comfortable to schedule this tree for .33
rather than .32

So this tree can be removed from -next and reintegrated once -rc1 is
released, without problem.

So that if this patch is scheduled for .32, I can fix the conflict
myself once -rc1 is released and not burden Stephen with this conflict
which is useless to handle in -next for now.

Thanks.

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