linux-kernel - Re: [RFC][PATCH] set_page_buffer_dirty should skip unmapped buffers

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:	Wed, 06 Sep 2006 20:04:27 -0700
From:	Badari Pulavarty <pbadari@...ibm.com>
To:	Andrew Morton <akpm@...l.org>
CC:	Jan Kara <jack@...e.cz>, Anton Altaparmakov <aia21@....ac.uk>,
	sct@...hat.com, linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [RFC][PATCH] set_page_buffer_dirty should skip unmapped buffers

Andrew Morton wrote:
> On Wed, 6 Sep 2006 19:27:33 +0200
> Jan Kara <jack@...e.cz> wrote:
>
>   
>>   Ugh! Are you sure? For this path the buffer must be attached (only) to
>> the running transaction. But then how the commit code comes to it?
>> Somebody would have to even manage to refile the buffer from the
>> committing transaction to the running one while the buffer is in wbuf[].
>> Could you check whether someone does __journal_refile_buffer() on your
>> marked buffers, please? Or whether we move buffer to BJ_Locked list in
>> the write_out_data: loop? Thanks.
>>     
>
> The ext3-debug patch will help here.  It records, within the bh, the inputs
> from the last 32 BUFFER_TRACE()s which were run against this bh.  If a
> J_ASSERT fails then you get a nice trace of the last 32 "things" which
> happened to this bh, including the bh's state at that transition.  It
> basically tells you everything you need to know to find the bug.
>
> It's worth spending the time to become familiar with it - I used it a lot in
> early ext3 development.
>   

I will try the patch. Unfortunately, adding more debug is causing the 
problem reproduction
difficult.
> I've been unable to reproduce this crash, btw.  Is there some magic
> incantation apat from running `fsx-linux'?
>   
All I do is on a single 1k filesystem, run 4 copies of fsx (on 4 
different files, ofcourse).
I hit the assert anywhere between 10min-2hours.

Thanks,
Badari

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