On Wed, 6 Sep 2000, Tim Waugh wrote:
> On Wed, Sep 06, 2000 at 08:29:49AM -0700, Linus Torvalds wrote:
>
> > Just change block_truncate_page() to use b_this_page instead of b_next.
>
> That seems to fix it.
I'm really really really looking forward to the first kernel
since 2.3.7 that doesn't h
On Wed, Sep 06, 2000 at 08:29:49AM -0700, Linus Torvalds wrote:
> Just change block_truncate_page() to use b_this_page instead of b_next.
That seems to fix it.
Thanks,
Tim.
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Wed, 6 Sep 2000, Tim Waugh wrote:
> On Tue, Sep 05, 2000 at 07:14:02PM -0700, Linus Torvalds wrote:
>
> > How about this patch?
>
> Got this oops.
> Code; c012cae6<=
>0: 8b 00 movl (%eax),%eax <=
Offset 0 is ->b_next... Huh? It should be ->b_th
On Wed, 6 Sep 2000, Tim Waugh wrote:
> On Tue, Sep 05, 2000 at 07:14:02PM -0700, Linus Torvalds wrote:
>
> > How about this patch?
>
> Got this oops.
This one I cannot explain.
It's a bh that is NULL, but it's a new case completely. It looks like you
have a 1kB blocksize, no? It furthermore
On Wed, 6 Sep 2000, Chris Mason wrote:
>
> Ah, I was missing that __block_prepare_write and __block_write_fullpage
> both set the end_io handler to end_io_sync. In one case, reiserfs is doing
> i/o without properly setting the handler, which is why I was seeing bugs
> caused by the above pr
--On 09/05/00 21:35:13 -0400 Chris Mason <[EMAIL PROTECTED]> wrote:
>
> Ok, hopefully this will make sense...
>
> __block_commit_write calls balance_dirty, which might wait on bdflush,
> running all the io on the page. The async_end_io handlers will unlock
> the page once io on all the buffer h
On Tue, Sep 05, 2000 at 07:14:02PM -0700, Linus Torvalds wrote:
> How about this patch?
Got this oops.
Tim.
*/
ksymoops 2.3.3 on i586 2.4.0-test8-pre5+trfix. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test8-pre5+trfi
On 6 Sep 2000, Henrik [ISO-8859-1] Størner wrote:
> In <[EMAIL PROTECTED]> Linus Torvalds
><[EMAIL PROTECTED]> writes:
>
> >How about this patch?
>
> >NOTE NOTE NOTE! I'm on my way home now to be a family man, so I've not
> >actually tested it AT ALL. You have been warned.
>
> "When in doub
In <[EMAIL PROTECTED]> Linus Torvalds
<[EMAIL PROTECTED]> writes:
>How about this patch?
>NOTE NOTE NOTE! I'm on my way home now to be a family man, so I've not
>actually tested it AT ALL. You have been warned.
"When in doubt, always mount a scratch monkey"
I have a spare partition for this k
I went ahead and applied the patch and subjected my machine to some heavy disk
thrashing. Nothing has oopsed yet. Netscape is still running. Throwing >1.0 GB
files around isnt exhibiting any problems.
Need others to verify.
On Tue, Sep 05, 2000 at 11:48:45PM -0400, Mohammad A . Haque wrote:
> I
On Tue, 5 Sep 2000, Linus Torvalds wrote:
> Yeah, but that's a much bigger issue. Not something we can or want to fix
> for 2.4.x.
No arguments. UFS will have to live with its private copy for a while
(truncate there may have to zero out more than 4Kb of data).
> > * "make sure that ->bu
I'd test it .. I was planning on setting up vmware with an install and trying stuff
there. But I have too much !@#$ homework.
Anyone else want to be brave and volunteer? It's for a good cause!
On Tue, Sep 05, 2000 at 08:35:37PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 5 Sep 2000, Mohammad A
On Tue, 5 Sep 2000, Mohammad A . Haque wrote:
>
> Just wanted to throw I out that I JUST experienced the same oops with
> netscape. I'mgoing to wait until Al submits a patch that he has gone
> over to see if it fixes the problem.
Well, Al seems to agree with mine, but it still hasn't been test
Umm..what .. you get back here this instant .. Linus..come back here ...
Just kidding.
Just wanted to throw I out that I JUST experienced the same oops with netscape.
I'mgoing to wait until Al submits a patch that he has gone over to see if it fixes the
problem.
Also wanted to ask (because I
On Tue, 5 Sep 2000, Alexander Viro wrote:
>
> It looks OK, except for the following (issues are actually common to
> all block_... functions):
> * if we ever do allocation unit != IO block size (have to do it on
> UFS, probably want it on ext2 to break 4Kb limit) we'll have to deal with
>
On Tue, 5 Sep 2000, Linus Torvalds wrote:
> We just grab the page, populate it with buffers if required, and find the
> one buffer that we need to clear out. We clear it out and mark it dirty.
> End of story.
>
> NOTE: Udo, because I haven't actually tested this (it may not actually
> compile
On Wed, Sep 06, 2000 at 02:55:29AM +0200, Udo A. Steinberg wrote:
> >>EIP; c0130400 <__block_commit_write+50/c0> <=
Just got the same Oops with test8-pre5 while exiting mutt:
Writing /var/spool/mail/sim...Unable to handle kernel NULL pointer dereference at
virtual address 0018
print
How about this patch?
NOTE NOTE NOTE! I'm on my way home now to be a family man, so I've not
actually tested it AT ALL. You have been warned.
The basic approach should be ok, and it avoids using the write path at all
because it isn't actually needed. The truncate() case is, in the end, much
si
On Tue, 5 Sep 2000, David S. Miller wrote:
>Date: Tue, 5 Sep 2000 21:31:17 -0400 (EDT)
>From: Alexander Viro <[EMAIL PROTECTED]>
>
>Me neither, but IMO I have a cop-out:
>
> Think it's a good idea to kunmap the page twice? :-)
Successful prepare_write() will kmap() it...
-
Date: Tue, 5 Sep 2000 21:39:59 -0400 (EDT)
From: Alexander Viro <[EMAIL PROTECTED]>
On Tue, 5 Sep 2000, David S. Miller wrote:
> Think it's a good idea to kunmap the page twice? :-)
Successful prepare_write() will kmap() it...
Oops, indeed, I did not realize nested kmap/kunmap w
Date:Tue, 5 Sep 2000 21:31:17 -0400 (EDT)
From: Alexander Viro <[EMAIL PROTECTED]>
Me neither, but IMO I have a cop-out:
Think it's a good idea to kunmap the page twice? :-)
...
__block_commit_write(inode, page, offset, offset+length);
+kunmap(page);
+unm
--On 09/05/00 18:13:53 -0700 Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 6 Sep 2000, Udo A. Steinberg wrote:
>>
>> I'm still experiencing ext2 corruption even with the newest patch
>> test8-pre5. I'm not using bugtraq, mutt or pine and I'm fairly sure
>> it's not caused by a badly wr
On Tue, 5 Sep 2000, Linus Torvalds wrote:
>
>
> On Tue, 5 Sep 2000, Alexander Viro wrote:
> >
> > How about reverting to compare-and-write-if-nonzero variant?
> > _That_ will be definitely legal.
>
> Yes, but I would really hate to have the case that a (shortening) truncate
> could fail du
On Tue, 5 Sep 2000, Alexander Viro wrote:
>
> How about reverting to compare-and-write-if-nonzero variant?
> _That_ will be definitely legal.
Yes, but I would really hate to have the case that a (shortening) truncate
could fail due to disk-full issues.
I think that's just wrong (sure, I can s
On Tue, 5 Sep 2000, Linus Torvalds wrote:
>
>
> On Tue, 5 Sep 2000, Alexander Viro wrote:
> >
> > WTF? Erm... Linus, I suspect that we are losing the thing on the
> > very simple effect: readpage() gets buffer_heads, all right, but then
> > we lose the lock. That's your window for losing t
On Tue, 5 Sep 2000, Alexander Viro wrote:
>
> WTF? Erm... Linus, I suspect that we are losing the thing on the
> very simple effect: readpage() gets buffer_heads, all right, but then
> we lose the lock. That's your window for losing the buffer_head ring of
> that page.
Note that it's not even
On Tue, 5 Sep 2000, Linus Torvalds wrote:
> This is basically all due to the fact that the new truncate logic does a
> "__block_commit_write()" without ever having itself called any of the
> routines that establish the buffers (a regular write will always have
> called "__block_prepare_write()
On Wed, 6 Sep 2000, Udo A. Steinberg wrote:
> Calltrace follows:
[bh==NULL in the loop in __block_commit_write()]
WTF? Erm... Linus, I suspect that we are losing the thing on the
very simple effect: readpage() gets buffer_heads, all right, but then
we lose the lock. That's your window for l
On Wed, 6 Sep 2000, Udo A. Steinberg wrote:
>
> I'm still experiencing ext2 corruption even with the newest patch
> test8-pre5. I'm not using bugtraq, mutt or pine and I'm fairly sure
> it's not caused by a badly written application or strange input.
Interesting oops.
Basically your "page->bu
Hello,
I'm still experiencing ext2 corruption even with the newest patch
test8-pre5. I'm not using bugtraq, mutt or pine and I'm fairly sure
it's not caused by a badly written application or strange input.
Right now Linux oopsed and badly broke the whole FS.
Hopefully this will help tracking th
30 matches
Mail list logo
