linux-kernel - Re: 2.6.18 ext3 panic.

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:	Fri, 13 Oct 2006 09:56:14 +0200
From:	Jan Kara <jack@...e.cz>
To:	Badari Pulavarty <pbadari@...ibm.com>
Cc:	Eric Sandeen <esandeen@...hat.com>, Andrew Morton <akpm@...l.org>,
	Eric Sandeen <sandeen@...deen.net>,
	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.18 ext3 panic.

> Eric Sandeen wrote:
> >Andrew Morton wrote:
> >
> >  
> >>On Thu, 12 Oct 2006 14:28:20 +0200
> >>Jan Kara <jack@...e.cz> wrote:
> >>
> >>  
> >>    
> >>>Where can we call
> >>>journal_dirty_data() without PageLock?
> >>>    
> >>>      
> >>block_write_full_page() will unlock the page, so ext3_writepage()
> >>will run journal_dirty_data_fn() against an unlocked page.
> >>
> >>I haven't looked into the exact details of the race, but it should
> >>be addressable via jbd_lock_bh_state() or j_list_lock coverage
> >>    
> >I'm testing with something like this now; seem sane?
> >
> >journal_dirty_data & journal_unmap_data both check do 
> >jbd_lock_bh_state(bh) close to the top... journal_dirty_data_fn has 
> >checked buffer_mapped before getting into journal_dirty_data, but that 
> >state may
> >change before the lock is grabbed.  Similarly re-check after we drop the 
> >lock.
> >
> >  
> This is exactly  the solution I proposed earlier (to check 
> buffer_mapped() before calling submit_bh()).
> But at that time, Jan pointed out that the whole handling is wrong.
  Yes, and it was. However it turned out that there are more problems
than I thought ;).

> But if this is the only case we need to handle, I am okay with this band 
> aid :)
  I think Eric's patch may be a part of it. But we still need to check whether
the buffer is not after EOF before submitting it (or better said just
after we manage to lock the buffer). Because while we are waiting for
the buffer lock, journal_unmap_buffer() can still come and steal the
buffer - at least the write-out in journal_dirty_data() definitely needs
the check if I haven't overlooked something.

								Honza
-- 
Jan Kara <jack@...e.cz>
SuSE CR Labs
-
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/