Linus Torvalds wrote:
> I'd rather just change the rule that "writepage()" will clear the dirty
> bit itself and always unlock (and "1" just to inform the upper layers that
> the page cannot be thrown away).
Change to that rule or from? I *think* you just said:
- If ->writepage successfully
hi,
On Wed, Jan 03, 2001 at 10:28:05AM -0800, Linus Torvalds wrote:
>
> On Wed, 3 Jan 2001, Chris Mason wrote:
> >
> > Just noticed the filemap_fdatasync code doesn't check the return value from
> > writepage. Linus, would you take a patch that redirtied the page, puts it
> > back onto the
On Thu, 4 Jan 2001, Chris Mason wrote:
>
> The page dirty bit is not reset.
> the page is never unlocked.
>
> So how about something like this in filemap_fdatasync
I'd rather just change the rule that "writepage()" will clear the dirty
bit itself and always unlock (and "1" just to inform the
Ok, lets just fix filemap_fdatasync. We can tackle the msync/fsync
interaction with screwed up FS writepages later, since all of the existing
writepage funcs are safe. The problems I see with filemap_fdatasync when
writepage returns 1:
The page dirty bit is not reset.
the page is never
On Thu, 4 Jan 2001, Marcelo Tosatti wrote:
> On 4 Jan 2001, Christoph Rohland wrote:
> > Chris Mason <[EMAIL PROTECTED]> writes:
> > > That would loop forever if the writepage func kept returning 1 though
[snip]
> > return 1 if the swap space is exhausted. So everybody using shared
> >
Chris Mason <[EMAIL PROTECTED]> writes:
> Yes, right now the shmem writepage calls are the only ones returning one at
> all. But, the question of how to properly fsync/msync these kinds of pages
> still stands. Returning from an fsync before writing them isn't correct.
Yes, and [fm]sync
On 4 Jan 2001, Christoph Rohland wrote:
> Chris Mason <[EMAIL PROTECTED]> writes:
> > Just noticed the filemap_fdatasync code doesn't check the return value from
> > writepage. Linus, would you take a patch that redirtied the page, puts it
> > back onto the dirty list (at the tail), and
On Thursday, January 04, 2001 10:48:13 AM +0100 Christoph Rohland
<[EMAIL PROTECTED]> wrote:
> Chris Mason <[EMAIL PROTECTED]> writes:
>> Just noticed the filemap_fdatasync code doesn't check the return value
>> from writepage. Linus, would you take a patch that redirtied the page,
>> puts it
Chris Mason <[EMAIL PROTECTED]> writes:
> Just noticed the filemap_fdatasync code doesn't check the return value from
> writepage. Linus, would you take a patch that redirtied the page, puts it
> back onto the dirty list (at the tail), and unlocks the page when writepage
> returns 1?
>
> That
Chris Mason [EMAIL PROTECTED] writes:
Just noticed the filemap_fdatasync code doesn't check the return value from
writepage. Linus, would you take a patch that redirtied the page, puts it
back onto the dirty list (at the tail), and unlocks the page when writepage
returns 1?
That would
On Thursday, January 04, 2001 10:48:13 AM +0100 Christoph Rohland
[EMAIL PROTECTED] wrote:
Chris Mason [EMAIL PROTECTED] writes:
Just noticed the filemap_fdatasync code doesn't check the return value
from writepage. Linus, would you take a patch that redirtied the page,
puts it back onto
On 4 Jan 2001, Christoph Rohland wrote:
Chris Mason [EMAIL PROTECTED] writes:
Just noticed the filemap_fdatasync code doesn't check the return value from
writepage. Linus, would you take a patch that redirtied the page, puts it
back onto the dirty list (at the tail), and unlocks the
On Thu, 4 Jan 2001, Marcelo Tosatti wrote:
On 4 Jan 2001, Christoph Rohland wrote:
Chris Mason [EMAIL PROTECTED] writes:
That would loop forever if the writepage func kept returning 1 though
[snip]
return 1 if the swap space is exhausted. So everybody using shared
anonymous,
Chris Mason [EMAIL PROTECTED] writes:
Yes, right now the shmem writepage calls are the only ones returning one at
all. But, the question of how to properly fsync/msync these kinds of pages
still stands. Returning from an fsync before writing them isn't correct.
Yes, and [fm]sync should not
Ok, lets just fix filemap_fdatasync. We can tackle the msync/fsync
interaction with screwed up FS writepages later, since all of the existing
writepage funcs are safe. The problems I see with filemap_fdatasync when
writepage returns 1:
The page dirty bit is not reset.
the page is never
On Thu, 4 Jan 2001, Chris Mason wrote:
The page dirty bit is not reset.
the page is never unlocked.
So how about something like this in filemap_fdatasync
I'd rather just change the rule that "writepage()" will clear the dirty
bit itself and always unlock (and "1" just to inform the upper
hi,
On Wed, Jan 03, 2001 at 10:28:05AM -0800, Linus Torvalds wrote:
On Wed, 3 Jan 2001, Chris Mason wrote:
Just noticed the filemap_fdatasync code doesn't check the return value from
writepage. Linus, would you take a patch that redirtied the page, puts it
back onto the dirty list
Linus Torvalds wrote:
I'd rather just change the rule that "writepage()" will clear the dirty
bit itself and always unlock (and "1" just to inform the upper layers that
the page cannot be thrown away).
Change to that rule or from? I *think* you just said:
- If -writepage successfully
On Wednesday, January 03, 2001 10:28:05 AM -0800 Linus Torvalds
<[EMAIL PROTECTED]> wrote:
> On Wed, 3 Jan 2001, Chris Mason wrote:
>>
>> Just noticed the filemap_fdatasync code doesn't check the return value
>> from writepage. Linus, would you take a patch that redirtied the page,
>> puts
On Wed, 3 Jan 2001, Chris Mason wrote:
>
> Just noticed the filemap_fdatasync code doesn't check the return value from
> writepage. Linus, would you take a patch that redirtied the page, puts it
> back onto the dirty list (at the tail), and unlocks the page when writepage
> returns 1?
I
Chris Mason wrote:
>
> Hi guys,
>
> Just noticed the filemap_fdatasync code doesn't check the return value from
> writepage. Linus, would you take a patch that redirtied the page, puts it
> back onto the dirty list (at the tail), and unlocks the page when writepage
> returns 1?
It would be a
Hi guys,
Just noticed the filemap_fdatasync code doesn't check the return value from
writepage. Linus, would you take a patch that redirtied the page, puts it
back onto the dirty list (at the tail), and unlocks the page when writepage
returns 1?
That would loop forever if the writepage func
Hi guys,
Just noticed the filemap_fdatasync code doesn't check the return value from
writepage. Linus, would you take a patch that redirtied the page, puts it
back onto the dirty list (at the tail), and unlocks the page when writepage
returns 1?
That would loop forever if the writepage func
Chris Mason wrote:
Hi guys,
Just noticed the filemap_fdatasync code doesn't check the return value from
writepage. Linus, would you take a patch that redirtied the page, puts it
back onto the dirty list (at the tail), and unlocks the page when writepage
returns 1?
It would be a lot
On Wednesday, January 03, 2001 10:28:05 AM -0800 Linus Torvalds
[EMAIL PROTECTED] wrote:
On Wed, 3 Jan 2001, Chris Mason wrote:
Just noticed the filemap_fdatasync code doesn't check the return value
from writepage. Linus, would you take a patch that redirtied the page,
puts it back
In article <[EMAIL PROTECTED]>,
Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
>
>Ok, here it is.
>
>I hope I got all locking and all special cases right.
>
>Comments ?
Looks good.
There's a few things this misses, the worst of which were all my bugs in
the original description. Things like
On Thu, 28 Dec 2000, Linus Torvalds wrote:
> All done. It looks something like 5-10 places, most of which are about 10
> lines of diff each, if even that.
>
> The only real worry would be that the locking isn't rigth, but getting the
> pagemap lock should be the safe thing, and from a lock
On Thu, 28 Dec 2000, Linus Torvalds wrote:
All done. It looks something like 5-10 places, most of which are about 10
lines of diff each, if even that.
The only real worry would be that the locking isn't rigth, but getting the
pagemap lock should be the safe thing, and from a lock
In article [EMAIL PROTECTED],
Marcelo Tosatti [EMAIL PROTECTED] wrote:
Ok, here it is.
I hope I got all locking and all special cases right.
Comments ?
Looks good.
There's a few things this misses, the worst of which were all my bugs in
the original description. Things like "don't unlock
29 matches
Mail list logo
