Chris Mason <[EMAIL PROTECTED]>
06/21/01 08:20 PM
Please respond to Chris Mason
To: Andrea Arcangeli <[EMAIL PROTECTED]>, Linus Torvalds
<[EMAIL PROTECTED]>
cc: Stefan Bader/Germany/IBM@IBMDE,
[EMAIL PROTECTED]
Subject: Re: corre
Chris Mason [EMAIL PROTECTED]
06/21/01 08:20 PM
Please respond to Chris Mason
To: Andrea Arcangeli [EMAIL PROTECTED], Linus Torvalds
[EMAIL PROTECTED]
cc: Stefan Bader/Germany/IBM@IBMDE,
[EMAIL PROTECTED]
Subject:Re: correction: fs/buffer.c
On Thu, 21 Jun 2001, Andrea Arcangeli wrote:
> On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote:
> What's the problem with the existing code, and why do people want to add a
> > (unnecessary) new bit?
>
> there's no problem with the existing code, what I understood is that
> they
On Thursday, June 21, 2001 07:15:22 PM +0200 Andrea Arcangeli
<[EMAIL PROTECTED]> wrote:
> On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote:
> What's the problem with the existing code, and why do people want to add
> a
>> (unnecessary) new bit?
>
> there's no problem with the
On Thu, Jun 21, 2001 at 07:15:22PM +0200, Andrea Arcangeli wrote:
> On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote:
> What's the problem with the existing code, and why do people want to add a
> > (unnecessary) new bit?
>
> there's no problem with the existing code, what I
On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote:
What's the problem with the existing code, and why do people want to add a
> (unnecessary) new bit?
there's no problem with the existing code, what I understood is that
they cannot overwrite the ->b_end_io callback in the lowlevel
On Thu, Jun 21, 2001 at 09:54:47AM -0700, Linus Torvalds wrote:
> The above _will_ break. "tmp" may be locked due to the write - and the
indeed, I missed the pending writes sorry.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Thu, 21 Jun 2001, Andrea Arcangeli wrote:
>
> It seems we can more simply drop the tmp->b_end_io == end_buffer_io_async
> check enterely and safely.
I doubt it.
Think about somebody who writes a partial page (but a full buffer).
Somebody _else_ then reads the rest of the page. You'll have
On Thu, 21 Jun 2001, Andrea Arcangeli wrote:
>
> I think the patch is ok. We must have a way to track down which bh are
> actually getting read,
We _do_ have a way. The way is called "bh->b_end_io == end_io_async".
What's the problem with the existing code, and why do people want to add a
On Thu, Jun 21, 2001 at 04:39:11PM +0200, [EMAIL PROTECTED] wrote:
> diff -ruN old/fs/buffer.c new/fs/buffer.c
> --- old/fs/buffer.c Thu Jun 21 09:47:20 2001
> +++ new/fs/buffer.c Thu Jun 21 10:44:01 2001
> @@ -798,11 +798,12 @@
> * that unlock the page..
> */
>
On Thu, Jun 21, 2001 at 11:16:42AM -0400, Chris Mason wrote:
> Think of a mixture of fsync_inode_buffers and async i/o on page. Since
> fsync_inode_buffers uses ll_rw_block, if that end_io handler is the last to
> run the page never gets unlocked.
correct
Andrea
-
To unsubscribe from this
On Thursday, June 21, 2001 05:08:13 PM +0200 Andrea Arcangeli
<[EMAIL PROTECTED]> wrote:
>
> It seems we can more simply drop the tmp->b_end_io == end_buffer_io_async
> check enterely and safely. Possibly we could build a debugging logic to
> make sure nobody ever lock down a buffer mapped on
On Thu, Jun 21, 2001 at 04:39:11PM +0200, [EMAIL PROTECTED] wrote:
>
>
>
> Hi,
>
> I ran into some problems with buffer.c trying to unlock a page of
sorry for the huge delay in the answer, I was going to answer your
previous two emails very shortly (I didn't forgotten ;).
> async io buffer
On Thu, Jun 21, 2001 at 04:39:11PM +0200, [EMAIL PROTECTED] wrote:
Hi,
I ran into some problems with buffer.c trying to unlock a page of
sorry for the huge delay in the answer, I was going to answer your
previous two emails very shortly (I didn't forgotten ;).
async io buffer heads
On Thursday, June 21, 2001 05:08:13 PM +0200 Andrea Arcangeli
[EMAIL PROTECTED] wrote:
It seems we can more simply drop the tmp-b_end_io == end_buffer_io_async
check enterely and safely. Possibly we could build a debugging logic to
make sure nobody ever lock down a buffer mapped on a
On Thu, Jun 21, 2001 at 11:16:42AM -0400, Chris Mason wrote:
Think of a mixture of fsync_inode_buffers and async i/o on page. Since
fsync_inode_buffers uses ll_rw_block, if that end_io handler is the last to
run the page never gets unlocked.
correct
Andrea
-
To unsubscribe from this list:
On Thu, Jun 21, 2001 at 04:39:11PM +0200, [EMAIL PROTECTED] wrote:
diff -ruN old/fs/buffer.c new/fs/buffer.c
--- old/fs/buffer.c Thu Jun 21 09:47:20 2001
+++ new/fs/buffer.c Thu Jun 21 10:44:01 2001
@@ -798,11 +798,12 @@
* that unlock the page..
*/
On Thu, 21 Jun 2001, Andrea Arcangeli wrote:
It seems we can more simply drop the tmp-b_end_io == end_buffer_io_async
check enterely and safely.
I doubt it.
Think about somebody who writes a partial page (but a full buffer).
Somebody _else_ then reads the rest of the page. You'll have one
On Thu, Jun 21, 2001 at 09:54:47AM -0700, Linus Torvalds wrote:
The above _will_ break. tmp may be locked due to the write - and the
indeed, I missed the pending writes sorry.
Andrea
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote:
What's the problem with the existing code, and why do people want to add a
(unnecessary) new bit?
there's no problem with the existing code, what I understood is that
they cannot overwrite the -b_end_io callback in the lowlevel
On Thu, Jun 21, 2001 at 07:15:22PM +0200, Andrea Arcangeli wrote:
On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote:
What's the problem with the existing code, and why do people want to add a
(unnecessary) new bit?
there's no problem with the existing code, what I understood
On Thursday, June 21, 2001 07:15:22 PM +0200 Andrea Arcangeli
[EMAIL PROTECTED] wrote:
On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote:
What's the problem with the existing code, and why do people want to add
a
(unnecessary) new bit?
there's no problem with the existing
On Thu, 21 Jun 2001, Andrea Arcangeli wrote:
On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote:
What's the problem with the existing code, and why do people want to add a
(unnecessary) new bit?
there's no problem with the existing code, what I understood is that
they cannot
23 matches
Mail list logo
