this works fine in pre8. thanks all!
Joseph Cheek wrote:
> copying files off a loopback-mounted vfat filesystem exposes this bug.
> test11 worked fine.
>
> loop.o built as module. this hard crashes the machine, every time
> [PIII-450]. i don't know how to debug this, is there a FAQ?
>
>
this works fine in pre8. thanks all!
Joseph Cheek wrote:
copying files off a loopback-mounted vfat filesystem exposes this bug.
test11 worked fine.
loop.o built as module. this hard crashes the machine, every time
[PIII-450]. i don't know how to debug this, is there a FAQ?
On Sat, 9 Dec 2000, Mikulas Patocka wrote:
>
> I did a test. I disabled readahead except for reading all 4 buffers in
> map_4sectors.
>
> I observed 14% slowdown on walking directories with find and 4% slowdown
> on grepping one my working directory (10M, 281 files).
>
> If you can't make it
On Sat, 9 Dec 2000, Alexander Viro wrote:
> On Sat, 9 Dec 2000, Andries Brouwer wrote:
>
> > On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
> >
> > > > @@ -1210,7 +1204,6 @@
> > > [breada()]
> > > Umm... why do we keep it, in the first place? AFAICS the only
> > > in-tree
Linus Torvalds <[EMAIL PROTECTED]> writes:
> > Modulo the comments above - fine with me. However, there is stuff in
> > drivers/md that I don't understand. Ingo, could you comment on the use of
> > ->b_end_io there?
>
> I already sent him mail about it for the same reason.
How about
On Sat, 9 Dec 2000, Alexander Viro wrote:
> Fine
> > - atomic_inc(>b_count);
>
> Why? It's cleaner the old way - why bother postponing that until we
> lock the thing?
I had a rule: we always do the "lock_buffer()" and "b_count increment"
together with setting "b_end_io =
On Fri, 8 Dec 2000, Alexander Viro wrote:
> BTW, what do you think about the following:
> * add_to_page_cache() is not exported and never used. Kill?
I have my eye on that for execute-in-place of romfs from real ROM chips -
making up struct pages for parts of the ROM chips and inserting
Date:Sat, 9 Dec 2000 00:45:51 -0800 (PST)
From: Linus Torvalds <[EMAIL PROTECTED]>
out:
-if (nr) {
-ll_rw_block(WRITE, nr, arr);
-} else {
-UnlockPage(page);
-}
+UnlockPage(page);
ClearPageUptodate(page);
On Sat, 9 Dec 2000, Andries Brouwer wrote:
> On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
>
> > > @@ -1210,7 +1204,6 @@
> > [breada()]
> > Umm... why do we keep it, in the first place? AFAICS the only
> > in-tree user is hpfs_map_sector() and it doesn't look like we
On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
> > @@ -1210,7 +1204,6 @@
> [breada()]
> Umm... why do we keep it, in the first place? AFAICS the only
> in-tree user is hpfs_map_sector() and it doesn't look like we really
> need it there. OTOH, trimming the buffer.c down is
On Sat, 9 Dec 2000, Linus Torvalds wrote:
> This is a preliminary patch that I have not compiled and probably breaks,
> but you get the idea. I'm going to sleep, to survive another night with
> three small kids.
>
> If somebody wants to run with this, please try it out, but realize that
>
On Sat, 9 Dec 2000, Linus Torvalds wrote:
>
> This is a preliminary patch that I have not compiled and probably breaks,
> but you get the idea. I'm going to sleep, to survive another night with
> three small kids.
Call me stupid [ Chorus: "You're stupid, Linus" ], but I actually compiled
and
On Fri, 8 Dec 2000, Alexander Viro wrote:
> On Fri, 8 Dec 2000, Linus Torvalds wrote:
>
> > Looking more at this issue, I suspect that the easiest pretty solution
> > that everybody can probably agree is reasonable is to either pass down the
> > end-of-io callback to ll_rw_block as you
On Fri, 8 Dec 2000, Alexander Viro wrote:
On Fri, 8 Dec 2000, Linus Torvalds wrote:
Looking more at this issue, I suspect that the easiest pretty solution
that everybody can probably agree is reasonable is to either pass down the
end-of-io callback to ll_rw_block as you suggested, or,
On Sat, 9 Dec 2000, Linus Torvalds wrote:
This is a preliminary patch that I have not compiled and probably breaks,
but you get the idea. I'm going to sleep, to survive another night with
three small kids.
Call me stupid [ Chorus: "You're stupid, Linus" ], but I actually compiled
and
On Sat, 9 Dec 2000, Linus Torvalds wrote:
This is a preliminary patch that I have not compiled and probably breaks,
but you get the idea. I'm going to sleep, to survive another night with
three small kids.
If somebody wants to run with this, please try it out, but realize that
it's a
On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
@@ -1210,7 +1204,6 @@
[breada()]
Umm... why do we keep it, in the first place? AFAICS the only
in-tree user is hpfs_map_sector() and it doesn't look like we really
need it there. OTOH, trimming the buffer.c down is
On Sat, 9 Dec 2000, Andries Brouwer wrote:
On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
@@ -1210,7 +1204,6 @@
[breada()]
Umm... why do we keep it, in the first place? AFAICS the only
in-tree user is hpfs_map_sector() and it doesn't look like we really
need
Date:Sat, 9 Dec 2000 00:45:51 -0800 (PST)
From: Linus Torvalds [EMAIL PROTECTED]
out:
-if (nr) {
-ll_rw_block(WRITE, nr, arr);
-} else {
-UnlockPage(page);
-}
+UnlockPage(page);
ClearPageUptodate(page);
On Fri, 8 Dec 2000, Alexander Viro wrote:
BTW, what do you think about the following:
* add_to_page_cache() is not exported and never used. Kill?
I have my eye on that for execute-in-place of romfs from real ROM chips -
making up struct pages for parts of the ROM chips and inserting
On Sat, 9 Dec 2000, Alexander Viro wrote:
Fine
- atomic_inc(bh-b_count);
Why? It's cleaner the old way - why bother postponing that until we
lock the thing?
I had a rule: we always do the "lock_buffer()" and "b_count increment"
together with setting "b_end_io =
Linus Torvalds [EMAIL PROTECTED] writes:
Modulo the comments above - fine with me. However, there is stuff in
drivers/md that I don't understand. Ingo, could you comment on the use of
-b_end_io there?
I already sent him mail about it for the same reason.
How about sending mail to
On Sat, 9 Dec 2000, Alexander Viro wrote:
On Sat, 9 Dec 2000, Andries Brouwer wrote:
On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
@@ -1210,7 +1204,6 @@
[breada()]
Umm... why do we keep it, in the first place? AFAICS the only
in-tree user is
On Sat, 9 Dec 2000, Mikulas Patocka wrote:
I did a test. I disabled readahead except for reading all 4 buffers in
map_4sectors.
I observed 14% slowdown on walking directories with find and 4% slowdown
on grepping one my working directory (10M, 281 files).
If you can't make it
On Fri, 8 Dec 2000, Linus Torvalds wrote:
> Looking more at this issue, I suspect that the easiest pretty solution
> that everybody can probably agree is reasonable is to either pass down the
> end-of-io callback to ll_rw_block as you suggested, or, preferably by just
> forcing the _caller_ to
On Fri, 8 Dec 2000, Alexander Viro wrote:
>
> I'm quite aware of that fact ;-) However, you said
>
>On the other hand, I have this suspicion that there is an even simpler
>solution: stop using the end_buffer_io_sync version for writes
>altogether.
>
> If that happens (i.e. if
On Fri, 8 Dec 2000, Linus Torvalds wrote:
>
>
> On Fri, 8 Dec 2000, Alexander Viro wrote:
> >
> > Erm... So you want to make ->commit_write() page-unlocking? Fine with me,
> > but that will make for somewhat bigger patch. Hey, _you_ are in position
> > to change the locking rules, freeze or
Linus Torvalds wrote:
>
> On Fri, 8 Dec 2000, Daniel Phillips wrote:
> >
> > [ flush-buffers taking the page lock ]
> >
> > This is great when you have buffersize==pagesize. When there are
> > multiple buffers per page it means that some of the buffers might have
> > to wait for flushing just
On Fri, 8 Dec 2000, Daniel Phillips wrote:
>
> [ flush-buffers taking the page lock ]
>
> This is great when you have buffersize==pagesize. When there are
> multiple buffers per page it means that some of the buffers might have
> to wait for flushing just because bdflush started IO on some
On Fri, 08 Dec 2000, Linus Torvalds wrote:
> Btw, I also think that the dirty buffer flushing should get the page lock.
> Right now it touches the buffer list without holding the lock on the page
> that the buffer is on, which means that there is really nothign that
> prevents it from racing with
On Fri, 8 Dec 2000, Alexander Viro wrote:
>
> Erm... So you want to make ->commit_write() page-unlocking? Fine with me,
> but that will make for somewhat bigger patch. Hey, _you_ are in position
> to change the locking rules, freeze or not, so if it's OK with you...
No.
Read the code a bit
On Fri, 8 Dec 2000, Alexander Viro wrote:
>
> Fix: postpone changing ->b_end_io until the call of ll_rw_block(); if by
> the time of ll_rw_block() some fragments will still have IO in progress -
> wait on them.
>
> Comments?
Yes.
On the other hand, I have this suspicion that there is an
Folks, see if the following patch helps. AFAICS it closes a pretty real
race - we could call block_write_full_page() for a page that has sync
IO in progress and blindly change ->b_end_io callbacks on the bh with
pending requests. With a little bit of bad luck they would complete before
we got to
I'm doing some massive grepping (basically, audit of page locking),
but nothing relevant so far. There was some catch (aside of documenting
the thing and finding several completely unrelated buglets):
* ramfs_writepage() doesn't UnlockPage(). Deadlock.
*
[EMAIL PROTECTED] said:
> Can you test some more? In particular, I'd love to hear if this
> happens with vfat even without loopback, or with loopback even without
> vfat (make an ext2 filesystem or similar instead). That woul dnarrow
> down the bug further.
Loopback-mounted iso9660 does it
[EMAIL PROTECTED] said:
Can you test some more? In particular, I'd love to hear if this
happens with vfat even without loopback, or with loopback even without
vfat (make an ext2 filesystem or similar instead). That woul dnarrow
down the bug further.
Loopback-mounted iso9660 does it too.
I'm doing some massive grepping (basically, audit of page locking),
but nothing relevant so far. There was some catch (aside of documenting
the thing and finding several completely unrelated buglets):
* ramfs_writepage() doesn't UnlockPage(). Deadlock.
*
Folks, see if the following patch helps. AFAICS it closes a pretty real
race - we could call block_write_full_page() for a page that has sync
IO in progress and blindly change -b_end_io callbacks on the bh with
pending requests. With a little bit of bad luck they would complete before
we got to
On Fri, 8 Dec 2000, Alexander Viro wrote:
Fix: postpone changing -b_end_io until the call of ll_rw_block(); if by
the time of ll_rw_block() some fragments will still have IO in progress -
wait on them.
Comments?
Yes.
On the other hand, I have this suspicion that there is an even
On Fri, 8 Dec 2000, Alexander Viro wrote:
Erm... So you want to make -commit_write() page-unlocking? Fine with me,
but that will make for somewhat bigger patch. Hey, _you_ are in position
to change the locking rules, freeze or not, so if it's OK with you...
No.
Read the code a bit more.
On Fri, 08 Dec 2000, Linus Torvalds wrote:
Btw, I also think that the dirty buffer flushing should get the page lock.
Right now it touches the buffer list without holding the lock on the page
that the buffer is on, which means that there is really nothign that
prevents it from racing with the
On Fri, 8 Dec 2000, Daniel Phillips wrote:
[ flush-buffers taking the page lock ]
This is great when you have buffersize==pagesize. When there are
multiple buffers per page it means that some of the buffers might have
to wait for flushing just because bdflush started IO on some other
On Fri, 8 Dec 2000, Linus Torvalds wrote:
On Fri, 8 Dec 2000, Alexander Viro wrote:
Erm... So you want to make -commit_write() page-unlocking? Fine with me,
but that will make for somewhat bigger patch. Hey, _you_ are in position
to change the locking rules, freeze or not, so if
On Fri, 8 Dec 2000, Alexander Viro wrote:
I'm quite aware of that fact ;-) However, you said
On the other hand, I have this suspicion that there is an even simpler
solution: stop using the end_buffer_io_sync version for writes
altogether.
If that happens (i.e. if write
On Fri, 8 Dec 2000, Linus Torvalds wrote:
Looking more at this issue, I suspect that the easiest pretty solution
that everybody can probably agree is reasonable is to either pass down the
end-of-io callback to ll_rw_block as you suggested, or, preferably by just
forcing the _caller_ to do
Linus Torvalds wrote:
>
> It's not a new bug - it's an old bug that apparently is uncovered by a
> new stricter test.
>
> Apparently loopback unlocks an already unlocked page - which has always
> been a serious offense, but has never been detected before.
>
> test12-pre6+ detects it, and thus
On Thu, 07 Dec 2000 17:23:51 -0800,
Joseph Cheek <[EMAIL PROTECTED]> wrote:
>i'll check it out. i'm compiling ksymoops now, is there a way to get it to
>work without a static libbfd? all i've got is a libbfd.so, and i'm going to
>need to recompile binutils if i must have a libbfd.a.
hi,
comments below.
Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> Joseph Cheek <[EMAIL PROTECTED]> wrote:
> >copying files off a loopback-mounted vfat filesystem exposes this bug.
> >test11 worked fine.
>
> It's not a new bug - it's an old bug that apparently is uncovered by a
>
i'll check it out. i'm compiling ksymoops now, is there a way to get it to
work without a static libbfd? all i've got is a libbfd.so, and i'm going to
need to recompile binutils if i must have a libbfd.a.
Linus Torvalds wrote:
> Your stack trace isn't symbolic (see
In article <[EMAIL PROTECTED]>,
Joseph Cheek <[EMAIL PROTECTED]> wrote:
>copying files off a loopback-mounted vfat filesystem exposes this bug.
>test11 worked fine.
It's not a new bug - it's an old bug that apparently is uncovered by a
new stricter test.
Apparently loopback unlocks an already
On Thu, 07 Dec 2000 14:42:38 -0800,
Joseph Cheek <[EMAIL PROTECTED]> wrote:
>loop.o built as module. this hard crashes the machine, every time
>[PIII-450]. i don't know how to debug this, is there a FAQ?
linux/Documentation/oops-tracing.txt
-
To unsubscribe from this list: send the line
copying files off a loopback-mounted vfat filesystem exposes this bug.
test11 worked fine.
loop.o built as module. this hard crashes the machine, every time
[PIII-450]. i don't know how to debug this, is there a FAQ?
[transcribed by hand]:
# mount -o loop /tmp/cdboot.288 /mnt/cd
# cd /mnt/cd
copying files off a loopback-mounted vfat filesystem exposes this bug.
test11 worked fine.
loop.o built as module. this hard crashes the machine, every time
[PIII-450]. i don't know how to debug this, is there a FAQ?
[transcribed by hand]:
# mount -o loop /tmp/cdboot.288 /mnt/cd
# cd /mnt/cd
On Thu, 07 Dec 2000 14:42:38 -0800,
Joseph Cheek [EMAIL PROTECTED] wrote:
loop.o built as module. this hard crashes the machine, every time
[PIII-450]. i don't know how to debug this, is there a FAQ?
linux/Documentation/oops-tracing.txt
-
To unsubscribe from this list: send the line
In article [EMAIL PROTECTED],
Joseph Cheek [EMAIL PROTECTED] wrote:
copying files off a loopback-mounted vfat filesystem exposes this bug.
test11 worked fine.
It's not a new bug - it's an old bug that apparently is uncovered by a
new stricter test.
Apparently loopback unlocks an already
i'll check it out. i'm compiling ksymoops now, is there a way to get it to
work without a static libbfd? all i've got is a libbfd.so, and i'm going to
need to recompile binutils if i must have a libbfd.a.
Linus Torvalds wrote:
Your stack trace isn't symbolic (see
hi,
comments below.
Linus Torvalds wrote:
In article [EMAIL PROTECTED],
Joseph Cheek [EMAIL PROTECTED] wrote:
copying files off a loopback-mounted vfat filesystem exposes this bug.
test11 worked fine.
It's not a new bug - it's an old bug that apparently is uncovered by a
new stricter
On Thu, 07 Dec 2000 17:23:51 -0800,
Joseph Cheek [EMAIL PROTECTED] wrote:
i'll check it out. i'm compiling ksymoops now, is there a way to get it to
work without a static libbfd? all i've got is a libbfd.so, and i'm going to
need to recompile binutils if i must have a libbfd.a.
Linus Torvalds wrote:
It's not a new bug - it's an old bug that apparently is uncovered by a
new stricter test.
Apparently loopback unlocks an already unlocked page - which has always
been a serious offense, but has never been detected before.
test12-pre6+ detects it, and thus the
59 matches
Mail list logo