Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 have the potential to eat my files... cheers, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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_this_page, no? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 looks like the page only had two buffers on it, and accessing the fourth one blows up (accessing the third one gets NULL, which is why it only blows up on the fourth one). But it _has_ to have four buffers on it. Two buffers just aren't enough to cover a 4kB page. Uh. DUH! I found the bug. It shouldn't be "bh->b_next". That's just the next buffer on the hash chain. It should be "bh->b_this_page". Just change block_truncate_page() to use b_this_page instead of b_next. The "good news" is that me testing this would neve rhave found it, because all my filesystems are 4kB blocks, so the "next bh" case never triggers at all. Thanks, and THIS time it really is fixed. I mean, how many times can we get it wrong? At some point, we just have to run out of really bad ideas.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 problem, and ext2 wasn't.
We might actually want to get away from the default handler: it made sense
as we were gradually rewriting old code to conform to new rules, but these
days it's just dangerous when it can result in something like the above. I
_almost_ had the same bug in the truncate patch I sent out yesterday, and
I caught it only because I was thinking hard about it.
It migth be something as simple as doing a
static void uninitialized_bh_io_handler(struct buffer_head *bh, int uptodate)
{
printk("Uhhuh, bh without uninitialized end-io function\n");
/* ..but fall back on the old default after complaining */
end_buffer_io_async(bh, uptodate);
}
which will still _work_, but complain quite loudly if somebody just relies
on the old default hander..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
--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 heads is done. > > So, by the time generic_file_write (or the new truncate code) calls > UnlockPage, the page could have been unlocked by i/o, and relocked by > another process. > > Or am I missing something? > 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 problem, and ext2 wasn't. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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+trfix/ (default) -m /boot/System.map-2.4.0-test8-pre5+trfix (specified) Unable to handle kernel NULL pointer dereference at virtual address c012cae6 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: ebx: 0080 ecx: edx: 0c00 esi: c10f02c0 edi: 0400 ebp: 0242 esp: c39d5e38 ds: 0018 es: 0018 ss: 0018 Process pine (pid: 1295, stackpage=c39d5000) Stack: 0084 c63353c0 c1299e0a c10f02c0 c654b2c0 c63353c0 0081 0dbe 0020 c0148487 c633545c 00020dbe c014786c c63353c0 0048 c39d5f70 00020dbe c3c0d600 c1299e00 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 8b 00 ff 44 24 20 89 44 24 2c 39 54 24 24 73 ea 8b 54 24 2c >>EIP; c012cae6<= Trace; c0148487 Trace; c014786c Trace; c012036b Trace; c011e685 Trace; c011e776 Trace; c013c41a Trace; c013c4e8 Trace; c0128b99 Trace; c0128e00 Trace; c0108e4f Code; c012cae6 <_EIP>: Code; c012cae6<= 0: 8b 00 movl (%eax),%eax <= Code; c012cae8 2: ff 44 24 20 incl 0x20(%esp,1) Code; c012caec 6: 89 44 24 2c movl %eax,0x2c(%esp,1) Code; c012caf0 a: 39 54 24 24 cmpl %edx,0x24(%esp,1) Code; c012caf4 e: 73 ea jaefffa <_EIP+0xfffa> c012cae0 Code; c012caf6 10: 8b 54 24 2c movl 0x2c(%esp,1),%edx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 doubt, always mount a scratch monkey" > > I have a spare partition for this kind of tests, and I am happy to > report that a quick test this morning shows: > > * the innd data corruption that started this whole thread appears > to be solved; That's really cool. It means that innd problem was really due to the we-don't-zero-out-block-tail bug. Wow. It was a looong way from 2.3.7... > * I could not trigger any data corruption by a simple > "fire up mutt and delete some mails in the inbox" test. > > Definitely needs additional testing, but so far it looks good. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 doubt, always mount a scratch monkey" I have a spare partition for this kind of tests, and I am happy to report that a quick test this morning shows: * the innd data corruption that started this whole thread appears to be solved; That's really cool. It means that innd problem was really due to the we-don't-zero-out-block-tail bug. Wow. It was a looong way from 2.3.7... * I could not trigger any data corruption by a simple "fire up mutt and delete some mails in the inbox" test. Definitely needs additional testing, but so far it looks good. knocking on the wood - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
--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 heads is done. So, by the time generic_file_write (or the new truncate code) calls UnlockPage, the page could have been unlocked by i/o, and relocked by another process. Or am I missing something? 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 problem, and ext2 wasn't. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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+trfix/ (default) -m /boot/System.map-2.4.0-test8-pre5+trfix (specified) Unable to handle kernel NULL pointer dereference at virtual address c012cae6 *pde = Oops: CPU:0 EIP:0010:[c012cae6] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: ebx: 0080 ecx: edx: 0c00 esi: c10f02c0 edi: 0400 ebp: 0242 esp: c39d5e38 ds: 0018 es: 0018 ss: 0018 Process pine (pid: 1295, stackpage=c39d5000) Stack: 0084 c63353c0 c1299e0a c10f02c0 c654b2c0 c63353c0 0081 0dbe 0020 c0148487 c633545c 00020dbe c014786c c63353c0 0048 c39d5f70 00020dbe c3c0d600 c1299e00 Call Trace: [c0148487] [c014786c] [c012036b] [c011e685] [c011e776] [c013c41a] [c013c4e8] [c0128b99] [c0128e00] [c0108e4f] Code: 8b 00 ff 44 24 20 89 44 24 2c 39 54 24 24 73 ea 8b 54 24 2c EIP; c012cae6 block_truncate_page+d2/1c8 = Trace; c0148487 ext2_truncate+c3/48c Trace; c014786c ext2_get_block+0/534 Trace; c012036b truncate_inode_pages+1eb/204 Trace; c011e685 vmtruncate+51/150 Trace; c011e776 vmtruncate+142/150 Trace; c013c41a inode_setattr+36/ac Trace; c013c4e8 notify_change+58/70 Trace; c0128b99 do_truncate+49/60 Trace; c0128e00 sys_ftruncate+100/11c Trace; c0108e4f tracesys+1f/23 Code; c012cae6 block_truncate_page+d2/1c8 _EIP: Code; c012cae6 block_truncate_page+d2/1c8 = 0: 8b 00 movl (%eax),%eax = Code; c012cae8 block_truncate_page+d4/1c8 2: ff 44 24 20 incl 0x20(%esp,1) Code; c012caec block_truncate_page+d8/1c8 6: 89 44 24 2c movl %eax,0x2c(%esp,1) Code; c012caf0 block_truncate_page+dc/1c8 a: 39 54 24 24 cmpl %edx,0x24(%esp,1) Code; c012caf4 block_truncate_page+e0/1c8 e: 73 ea jaefffa _EIP+0xfffa c012cae0 block_truncate_page+cc/1c8 Code; c012caf6 block_truncate_page+e2/1c8 10: 8b 54 24 2c movl 0x2c(%esp,1),%edx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 problem, and ext2 wasn't.
We might actually want to get away from the default handler: it made sense
as we were gradually rewriting old code to conform to new rules, but these
days it's just dangerous when it can result in something like the above. I
_almost_ had the same bug in the truncate patch I sent out yesterday, and
I caught it only because I was thinking hard about it.
It migth be something as simple as doing a
static void uninitialized_bh_io_handler(struct buffer_head *bh, int uptodate)
{
printk("Uhhuh, bh without uninitialized end-io function\n");
/* ..but fall back on the old default after complaining */
end_buffer_io_async(bh, uptodate);
}
which will still _work_, but complain quite loudly if somebody just relies
on the old default hander..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 looks like the page only had two buffers on it, and accessing the fourth one blows up (accessing the third one gets NULL, which is why it only blows up on the fourth one). But it _has_ to have four buffers on it. Two buffers just aren't enough to cover a 4kB page. Uh. DUH! I found the bug. It shouldn't be "bh-b_next". That's just the next buffer on the hash chain. It should be "bh-b_this_page". Just change block_truncate_page() to use b_this_page instead of b_next. The "good news" is that me testing this would neve rhave found it, because all my filesystems are 4kB blocks, so the "next bh" case never triggers at all. Thanks, and THIS time it really is fixed. I mean, how many times can we get it wrong? At some point, we just have to run out of really bad ideas.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 block_truncate_page+d2/1c8 = 0: 8b 00 movl (%eax),%eax = Offset 0 is -b_next... Huh? It should be -b_this_page, no? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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. Obvious I'm really really really looking forward to the first kernel since 2.3.7 that doesn't have the potential to eat my files... /Obvious cheers, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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'd test it .. I was planning on setting up vmware with an install and tryings > stuff there. But I have too much !@#$ homework. > > Anyone else want to be brave and volunteer? It's for a good cause! > -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 ->buffers is there and map the buffers in given > > range" is too fscking common and deserves a function of its own. > > Yeah, maybe. It's just that every single case has different semantics > inside the loop. So it would basically boil down to either macros or to > passign around function pointers.. I'm not sure, but anyway, that's a separate story. Let's avoid doing too many things simultaneously... Right now we really need to get the truncate() mess settled down on ext2, then we will be able to reproduce the whole set of fixes on other block filesystems. The sooner ext2 will get stable - the better. BTW, folks - do forced fsck before testing new kernels. These days it's a must-do. There had been a lot of chances to screw fs, so testing new variants on that may be interesting, but hardly useful. Oh, and do it on the _old_ kernels. Just to be sure that you have relatively clean setup. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 . 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 tested. > > Note that it doesn't ahve to be _me_ that tests the thing. Hint, hint. > > [ yeah, I know. Testing these kinds of things is dangerous. I'll do it > first thing in the morning if nobody else beats me to it. It looks ok, > but even just a silly typo can cause nasty fs corruption here, as we've > seen in the past ] > > Linus > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 tested. Note that it doesn't ahve to be _me_ that tests the thing. Hint, hint. [ yeah, I know. Testing these kinds of things is dangerous. I'll do it first thing in the morning if nobody else beats me to it. It looks ok, but even just a silly typo can cause nasty fs corruption here, as we've seen in the past ] Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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'm still learning) if anyone knew which files have the potential to become corrupt. Is it only open files or can it also be files that aren't being accessed. The reason I ask is because my netscape prefs file contained half of my missing mailbox and I couldn't recall if I had opened netscape when the last corruption occured. On Tue, Sep 05, 2000 at 07:14:02PM -0700, Linus Torvalds wrote: > > > 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 > simpler than writing, exactly because we don't need to allocate any new > blocks etc. > > 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 etc small details), you probably shouldn't actually test this out > as-is unless you are _really_ daring and don't mind fixing up after me. > It's more a "this is how it should work" kind of thing. > > Al? Mind giving it a quick look? > > Linus > > --- -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 > more than one block. Not a big deal, but worth getting it right Yeah, but that's a much bigger issue. Not something we can or want to fix for 2.4.x. I think it makes most sense as a complete change of interface: instead of asking the filesystem for the blocknumber, we could ask the filesystem to generate the buffer list for that page. Your other this would be solved by this too: > * with some filesystems we really want an analog of get_block() > acting on array. Aside of UFS, FAT-derived filesystems are obvious candidates. > I mean, WTF? Why bother recalculating the thing if allocation unit is larger > than IO unit? I don't think it's about being a larger IO unit - it can be a smaller IO unit that isn't even aligned with a 4kB page, for example. It's potentially valid to have each page split up into 1kB+2kB+1kB requests, because the filesystem really might be a 2kB system but for some strange reason isn't doing aligned buffers or whatever. The issue of a "tail" is the same thing. A 2kB block filesystem with a 512 byte tail, so a page might be 2kB+512B+unmapped if it is at the end of the file. But right now there's no way we'd make _those_ kinds of changes. In fact, right now I'd be happy to just have a working truncate() for a change ;) > * "make sure that ->buffers is there and map the buffers in given > range" is too fscking common and deserves a function of its own. Yeah, maybe. It's just that every single case has different semantics inside the loop. So it would basically boil down to either macros or to passign around function pointers.. > BTW, Jeff's complaint about size restriction in ll_rw_block() is > valid. It made sense when we used the thing only for buffer-cache, but > these days it looks bogus. It doesn't work as alias-prevention anymore, so > there's little point in doing it. Oh, I agree completely. What you didn't see me was me suggesting to Jeff that he just remove the check. It turns out that apparently several low-level drivers complain at that point, so it's more than just that single test, though. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 etc small details), you probably shouldn't actually test this out > as-is unless you are _really_ daring and don't mind fixing up after me. > It's more a "this is how it should work" kind of thing. > > Al? Mind giving it a quick look? 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 more than one block. Not a big deal, but worth getting it right * "make sure that ->buffers is there and map the buffers in given range" is too fscking common and deserves a function of its own. * with some filesystems we really want an analog of get_block() acting on array. Aside of UFS, FAT-derived filesystems are obvious candidates. I mean, WTF? Why bother recalculating the thing if allocation unit is larger than IO unit? I'll play with #2 and see what can be done there. I have a funny feeling that lots of things will merrily factor out, so we may end up with ability to do 10-liner transition to kiobuf whenever we will decide to do it. BTW, Jeff's complaint about size restriction in ll_rw_block() is valid. It made sense when we used the thing only for buffer-cache, but these days it looks bogus. It doesn't work as alias-prevention anymore, so there's little point in doing it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 printing eip: c0130583 *pde = Oops: CPU:0 EIP:0010:[] EFLAGS: 00010293 eax: ebx: ecx: 0800 edx: esi: 0800 edi: 0001 ebp: esp: ceb19e40 ds: 0018 es: 0018 ss: 0018 Process mutt (pid: 2153, stackpage=ceb19000) Stack: c1382a80 ce0ab000 0649 0800 c0130b52 ceb640a0 c1382a80 09b7 1000 0dea 000b ceb640a0 ceb640a0 09b7 c014d31e ceb6413c 006f49b7 0649 ceb640a0 ceb6413c Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: 8b 43 18 83 e0 01 0f 44 ef eb 35 89 f6 f6 43 18 10 74 2d f0 >>EIP; c0130583 <__block_commit_write+43/c0> <= Trace; c0130b52 Trace; c014d31e Trace; c012336d Trace; c012156d Trace; c012168d Trace; c014189e Trace; c014198e Trace; c012c71a Trace; c0124608 Trace; c012c963 Trace; c010a65f Code; c0130583 <__block_commit_write+43/c0> <_EIP>: Code; c0130583 <__block_commit_write+43/c0> <= 0: 8b 43 18 mov0x18(%ebx),%eax <= Code; c0130586 <__block_commit_write+46/c0> 3: 83 e0 01 and$0x1,%eax Code; c0130589 <__block_commit_write+49/c0> 6: 0f 44 ef cmove %edi,%ebp Code; c013058c <__block_commit_write+4c/c0> 9: eb 35 jmp40 <_EIP+0x40> c01305c3 <__block_commit_write+83/c0> Code; c013058e <__block_commit_write+4e/c0> b: 89 f6 mov%esi,%esi Code; c0130590 <__block_commit_write+50/c0> d: f6 43 18 10 testb $0x10,0x18(%ebx) Code; c0130594 <__block_commit_write+54/c0> 11: 74 2d je 40 <_EIP+0x40> c01305c3 <__block_commit_write+83/c0> Code; c0130596 <__block_commit_write+56/c0> 13: f0 00 00 lock add %al,(%eax) Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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
simpler than writing, exactly because we don't need to allocate any new
blocks etc.
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 etc small details), you probably shouldn't actually test this out
as-is unless you are _really_ daring and don't mind fixing up after me.
It's more a "this is how it should work" kind of thing.
Al? Mind giving it a quick look?
Linus
---
diff -u --recursive --new-file p5/linux/fs/buffer.c linux/fs/buffer.c
--- p5/linux/fs/buffer.cTue Sep 5 18:56:06 2000
+++ linux/fs/buffer.c Tue Sep 5 19:09:08 2000
@@ -1724,31 +1724,63 @@
return 0;
}
-int block_zero_page(struct address_space *mapping, loff_t from, unsigned length)
+int block_truncate_page(struct address_space *mapping, loff_t from, get_block_t
+*get_block)
{
unsigned long index = from >> PAGE_CACHE_SHIFT;
unsigned offset = from & (PAGE_CACHE_SIZE-1);
+ unsigned blocksize, iblock, length, pos;
struct inode *inode = (struct inode *)mapping->host;
struct page *page;
+ struct buffer_head *bh;
int err;
+ blocksize = inode->i_sb->s_blocksize;
+ length = offset & (blocksize - 1);
+
+ /* Block boundary? Nothing to do */
if (!length)
return 0;
- page = read_cache_page(mapping, index,
- (filler_t *)mapping->a_ops->readpage, NULL);
+ length = blocksize - length;
+ iblock = index << (PAGE_CACHE_SHIFT - inode->i_sb->s_blocksize_bits);
+
+ page = grab_cache_page(mapping, index);
err = PTR_ERR(page);
if (IS_ERR(page))
goto out;
- lock_page(page);
- err = -EIO;
- if (!Page_Uptodate(page))
- goto unlock;
+
+ if (!page->buffers)
+ create_empty_buffers(page, inode, blocksize);
+
+ /* Find the buffer that contains "offset" */
+ bh = page->buffers;
+ pos = blocksize;
+ while (offset >= pos) {
+ bh = bh->b_next;
+ iblock++;
+ pos += blocksize;
+ }
+
+ if (!buffer_uptodate(bh)) {
+ err = 0;
+ if (!buffer_mapped(bh)) {
+ get_block(inode, iblock, bh, 0);
+ if (!buffer_mapped(bh))
+ goto unlock;
+ }
+ err = -EIO;
+ bh->b_end_io = end_buffer_io_sync;
+ ll_rw_block(READ, 1, );
+ wait_on_buffer(bh);
+ if (!buffer_uptodate(bh))
+ goto unlock;
+ }
memset((char *) kmap(page) + offset, 0, length);
flush_dcache_page(page);
- __block_commit_write(inode, page, offset, offset+length);
kunmap(page);
+
+ mark_buffer_dirty(bh);
err = 0;
unlock:
diff -u --recursive --new-file p5/linux/fs/ext2/inode.c linux/fs/ext2/inode.c
--- p5/linux/fs/ext2/inode.cTue Sep 5 18:56:06 2000
+++ linux/fs/ext2/inode.c Tue Sep 5 19:01:29 2000
@@ -874,7 +874,7 @@
int nr = 0;
int n;
long iblock;
- unsigned blocksize, tail;
+ unsigned blocksize;
if (!(S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
S_ISLNK(inode->i_mode)))
@@ -887,9 +887,8 @@
blocksize = inode->i_sb->s_blocksize;
iblock = (inode->i_size + blocksize-1)
>> EXT2_BLOCK_SIZE_BITS(inode->i_sb);
- tail = (iblock << EXT2_BLOCK_SIZE_BITS(inode->i_sb)) - inode->i_size;
- block_zero_page(inode->i_mapping, inode->i_size, tail);
+ block_truncate_page(inode->i_mapping, inode->i_size, ext2_get_block);
n = ext2_block_to_path(inode, iblock, offsets);
if (n == 0)
diff -u --recursive --new-file p5/linux/include/linux/fs.h linux/include/linux/fs.h
--- p5/linux/include/linux/fs.h Tue Sep 5 18:56:07 2000
+++ linux/include/linux/fs.hTue Sep 5 19:00:59 2000
@@ -1173,7 +1173,7 @@
int generic_block_bmap(struct address_space *, long, get_block_t *);
int generic_commit_write(struct file *, struct page *, unsigned, unsigned);
-int block_zero_page(struct address_space *, loff_t, unsigned);
+int block_truncate_page(struct address_space *, loff_t, get_block_t *);
extern int generic_file_mmap(struct file *, struct vm_area_struct *);
extern ssize_t generic_file_read(struct file *, char *, size_t, loff_t *);
diff -u --recursive --new-file p5/linux/kernel/ksyms.c linux/kernel/ksyms.c
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 was valid. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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); +unmap: kunmap(page); err = 0; Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 see some filesystem where it happens because of how the filesystem is done, but basically I think we should avoid it if possible. Which it is). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 losing the buffer_head ring of that page. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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->buffers" thing seems to be NULL. Which is certainly interesting. And, thinking about it, quite legal. The page can have been up-to-date a long time ago, and we ended up pruning the buffers away in order to be able to free the page later - so when truncate comes along and wants to look at the buffers they don't exist any more. 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()" first, for example.) We really should have done a true "block_truncate_write()", but it looked so clever to just re-use the existing code. Fair enough. Still willing to test? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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-buffers" thing seems to be NULL. Which is certainly interesting. And, thinking about it, quite legal. The page can have been up-to-date a long time ago, and we ended up pruning the buffers away in order to be able to free the page later - so when truncate comes along and wants to look at the buffers they don't exist any more. 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()" first, for example.) We really should have done a true "block_truncate_write()", but it looked so clever to just re-use the existing code. Fair enough. Still willing to test? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 see some filesystem where it happens because of how the filesystem is done, but basically I think we should avoid it if possible. Which it is). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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
simpler than writing, exactly because we don't need to allocate any new
blocks etc.
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 etc small details), you probably shouldn't actually test this out
as-is unless you are _really_ daring and don't mind fixing up after me.
It's more a "this is how it should work" kind of thing.
Al? Mind giving it a quick look?
Linus
---
diff -u --recursive --new-file p5/linux/fs/buffer.c linux/fs/buffer.c
--- p5/linux/fs/buffer.cTue Sep 5 18:56:06 2000
+++ linux/fs/buffer.c Tue Sep 5 19:09:08 2000
@@ -1724,31 +1724,63 @@
return 0;
}
-int block_zero_page(struct address_space *mapping, loff_t from, unsigned length)
+int block_truncate_page(struct address_space *mapping, loff_t from, get_block_t
+*get_block)
{
unsigned long index = from PAGE_CACHE_SHIFT;
unsigned offset = from (PAGE_CACHE_SIZE-1);
+ unsigned blocksize, iblock, length, pos;
struct inode *inode = (struct inode *)mapping-host;
struct page *page;
+ struct buffer_head *bh;
int err;
+ blocksize = inode-i_sb-s_blocksize;
+ length = offset (blocksize - 1);
+
+ /* Block boundary? Nothing to do */
if (!length)
return 0;
- page = read_cache_page(mapping, index,
- (filler_t *)mapping-a_ops-readpage, NULL);
+ length = blocksize - length;
+ iblock = index (PAGE_CACHE_SHIFT - inode-i_sb-s_blocksize_bits);
+
+ page = grab_cache_page(mapping, index);
err = PTR_ERR(page);
if (IS_ERR(page))
goto out;
- lock_page(page);
- err = -EIO;
- if (!Page_Uptodate(page))
- goto unlock;
+
+ if (!page-buffers)
+ create_empty_buffers(page, inode, blocksize);
+
+ /* Find the buffer that contains "offset" */
+ bh = page-buffers;
+ pos = blocksize;
+ while (offset = pos) {
+ bh = bh-b_next;
+ iblock++;
+ pos += blocksize;
+ }
+
+ if (!buffer_uptodate(bh)) {
+ err = 0;
+ if (!buffer_mapped(bh)) {
+ get_block(inode, iblock, bh, 0);
+ if (!buffer_mapped(bh))
+ goto unlock;
+ }
+ err = -EIO;
+ bh-b_end_io = end_buffer_io_sync;
+ ll_rw_block(READ, 1, bh);
+ wait_on_buffer(bh);
+ if (!buffer_uptodate(bh))
+ goto unlock;
+ }
memset((char *) kmap(page) + offset, 0, length);
flush_dcache_page(page);
- __block_commit_write(inode, page, offset, offset+length);
kunmap(page);
+
+ mark_buffer_dirty(bh);
err = 0;
unlock:
diff -u --recursive --new-file p5/linux/fs/ext2/inode.c linux/fs/ext2/inode.c
--- p5/linux/fs/ext2/inode.cTue Sep 5 18:56:06 2000
+++ linux/fs/ext2/inode.c Tue Sep 5 19:01:29 2000
@@ -874,7 +874,7 @@
int nr = 0;
int n;
long iblock;
- unsigned blocksize, tail;
+ unsigned blocksize;
if (!(S_ISREG(inode-i_mode) || S_ISDIR(inode-i_mode) ||
S_ISLNK(inode-i_mode)))
@@ -887,9 +887,8 @@
blocksize = inode-i_sb-s_blocksize;
iblock = (inode-i_size + blocksize-1)
EXT2_BLOCK_SIZE_BITS(inode-i_sb);
- tail = (iblock EXT2_BLOCK_SIZE_BITS(inode-i_sb)) - inode-i_size;
- block_zero_page(inode-i_mapping, inode-i_size, tail);
+ block_truncate_page(inode-i_mapping, inode-i_size, ext2_get_block);
n = ext2_block_to_path(inode, iblock, offsets);
if (n == 0)
diff -u --recursive --new-file p5/linux/include/linux/fs.h linux/include/linux/fs.h
--- p5/linux/include/linux/fs.h Tue Sep 5 18:56:07 2000
+++ linux/include/linux/fs.hTue Sep 5 19:00:59 2000
@@ -1173,7 +1173,7 @@
int generic_block_bmap(struct address_space *, long, get_block_t *);
int generic_commit_write(struct file *, struct page *, unsigned, unsigned);
-int block_zero_page(struct address_space *, loff_t, unsigned);
+int block_truncate_page(struct address_space *, loff_t, get_block_t *);
extern int generic_file_mmap(struct file *, struct vm_area_struct *);
extern ssize_t generic_file_read(struct file *, char *, size_t, loff_t *);
diff -u --recursive --new-file p5/linux/kernel/ksyms.c linux/kernel/ksyms.c
--- p5/linux/kernel/ksyms.c
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 printing eip: c0130583 *pde = Oops: CPU:0 EIP:0010:[c0130583] EFLAGS: 00010293 eax: ebx: ecx: 0800 edx: esi: 0800 edi: 0001 ebp: esp: ceb19e40 ds: 0018 es: 0018 ss: 0018 Process mutt (pid: 2153, stackpage=ceb19000) Stack: c1382a80 ce0ab000 0649 0800 c0130b52 ceb640a0 c1382a80 09b7 1000 0dea 000b ceb640a0 ceb640a0 09b7 c014d31e ceb6413c 006f49b7 0649 ceb640a0 ceb6413c Call Trace: [c0130b52] [c014d31e] [c012336d] [c012156d] [c012168d] [c014189e] [c014198e] [c012c71a] [c0124608] [c012c963] [c010a65f] Code: 8b 43 18 83 e0 01 0f 44 ef eb 35 89 f6 f6 43 18 10 74 2d f0 EIP; c0130583 __block_commit_write+43/c0 = Trace; c0130b52 block_zero_page+b2/dc Trace; c014d31e ext2_truncate+aa/3c8 Trace; c012336d truncate_inode_pages+1e1/200 Trace; c012156d vmtruncate+4d/178 Trace; c012168d vmtruncate+16d/178 Trace; c014189e inode_setattr+36/ac Trace; c014198e notify_change+7a/bc Trace; c012c71a do_truncate+4a/60 Trace; c0124608 file_read_actor+0/5c Trace; c012c963 sys_ftruncate+df/f4 Trace; c010a65f system_call+33/38 Code; c0130583 __block_commit_write+43/c0 _EIP: Code; c0130583 __block_commit_write+43/c0 = 0: 8b 43 18 mov0x18(%ebx),%eax = Code; c0130586 __block_commit_write+46/c0 3: 83 e0 01 and$0x1,%eax Code; c0130589 __block_commit_write+49/c0 6: 0f 44 ef cmove %edi,%ebp Code; c013058c __block_commit_write+4c/c0 9: eb 35 jmp40 _EIP+0x40 c01305c3 __block_commit_write+83/c0 Code; c013058e __block_commit_write+4e/c0 b: 89 f6 mov%esi,%esi Code; c0130590 __block_commit_write+50/c0 d: f6 43 18 10 testb $0x10,0x18(%ebx) Code; c0130594 __block_commit_write+54/c0 11: 74 2d je 40 _EIP+0x40 c01305c3 __block_commit_write+83/c0 Code; c0130596 __block_commit_write+56/c0 13: f0 00 00 lock add %al,(%eax) Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 -buffers is there and map the buffers in given range" is too fscking common and deserves a function of its own. Yeah, maybe. It's just that every single case has different semantics inside the loop. So it would basically boil down to either macros or to passign around function pointers.. I'm not sure, but anyway, that's a separate story. Let's avoid doing too many things simultaneously... Right now we really need to get the truncate() mess settled down on ext2, then we will be able to reproduce the whole set of fixes on other block filesystems. The sooner ext2 will get stable - the better. BTW, folks - do forced fsck before testing new kernels. These days it's a must-do. There had been a lot of chances to screw fs, so testing new variants on that may be interesting, but hardly useful. Oh, and do it on the _old_ kernels. Just to be sure that you have relatively clean setup. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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); +unmap: kunmap(page); err = 0; Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
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 was valid. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
