Thread (2 messages) 2 messages, 2 authors, 2002-11-15

Re: [patch/2.4] ll_rw_blk stomping on bh state [Re: kernel BUG at journal.c:1732! (2.4.19)]

From: Andrew Morton <hidden>
Date: 2002-11-15 17:58:31
Also in: lkml

"Stephen C. Tweedie" wrote:
Hi,

On Tue, Nov 12, 2002 at 06:53:45PM +0000, Stephen C. Tweedie wrote:
quoted
On Tue, Nov 12, 2002 at 09:57:05AM -0800, Andrew Morton wrote:
quoted
"Stephen C. Tweedie" wrote:
quoted
                if (maxsector < count || maxsector - count < sector) {
                        /* Yecch */
                        bh->b_state &= (1 << BH_Lock) | (1 << BH_Mapped);
...
Folks, just which buffer flags do we want to preserve in this case?
quoted
Why do we want to clear any flags in there at all?  To prevent
a storm of error messages from a buffer which has a silly block
number?
That's the only reason I can think of.  Simply scrubbing all the state
bits is totally the wrong way of going about that, of course.
So what's the vote on this?  It's a decision between clearing only the
obvious bit (BH_Dirty) on the one hand, and keeping the code as
unchanged as possible to reduce the possibility of introducing new
bugs.

But frankly I can't see any convincing argument for clearing anything
except the dirty state in this case.
I'd agree with that.  And the dirty bit will already be cleared, won't it?

Maybe just treat it as an IO error and leave it at that; surely that won't
introduce any problems, given all the testing that has gone into the
error handling paths :)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help