Linus Torvalds wrote:
> Now, I don't think this is really a valid usage pattern, so it's most
> likely to be a result of a buggy application, but I can imagine having
> some strange kind of user-space VM memory management scheme that depends
> on SIGBUS to maintain a file length. I've never heard
Alan Cox wrote:
>
> > I would expect problems with truncate, mmap, rename, POSIX locks, fasync,
> > ptrace and mount go unnoticed for _long_. Ditto for parts of procfs
>
> Well the ptrace one still has mysteriously breaks usermode linux against it
> on my list here. Was that ever explained.
On Sun, 29 Oct 2000, Alan Cox wrote:
> > I would expect problems with truncate, mmap, rename, POSIX locks, fasync,
> > ptrace and mount go unnoticed for _long_. Ditto for parts of procfs
>
> Well the ptrace one still has mysteriously breaks usermode linux against it
> on my list here. Was
> I would expect problems with truncate, mmap, rename, POSIX locks, fasync,
> ptrace and mount go unnoticed for _long_. Ditto for parts of procfs
Well the ptrace one still has mysteriously breaks usermode linux against it
on my list here. Was that ever explained. It looked like the stack got
On Sun, 29 Oct 2000, Linus Torvalds wrote:
>
> Making it policy that we have to re-test page->mapping after aquireing the
> page lock might be the simplest fix for 2.4.x. It still means that we
> might end up allowing people to have a "bad" page in the VM space due to
> the "test->insert" race
On Sun, 29 Oct 2000, Alexander Viro wrote:
>
> One possible way is to access page->mapping _only_ under the page lock
> and in cases when we call ->i_mapping->a_ops->foo check the ->mapping
> before the method call.
I'm leaning towards this for a 2.4.x solution.
As far as I can tell,
On Sun, 29 Oct 2000, Linus Torvalds wrote:
> approach for 2.4.x where we just re-test against the file size in multiple
> places where this can happen - but it would be nicer to handle this more
> cleanly.
One possible way is to access page->mapping _only_ under the page lock
and in cases
On Sun, 29 Oct 2000, Paul Mackerras wrote:
>
> I have tracked down why I am getting the oops with page->mapping == 0
> in block_read_full_page. Well, at least if not the ultimate cause,
> then the penultimate cause. It's basically yet another truncate bug
> (tm). I have so
Paul Mackerras wrote:
> I am not any kind of expert on the page cache but it seems to me that
> maybe after locking the page we should check if it is still the page
> we want (i.e. page->mapping and page->index are still correct), and go
> back and look up the page again if not. Presumably there
Linus,
I have tracked down why I am getting the oops with page->mapping == 0
in block_read_full_page. Well, at least if not the ultimate cause,
then the penultimate cause. It's basically yet another truncate bug
(tm). I have some fairly detailed traces which I can send you if you
l
Linus,
I have tracked down why I am getting the oops with page-mapping == 0
in block_read_full_page. Well, at least if not the ultimate cause,
then the penultimate cause. It's basically yet another truncate bug
(tm). I have some fairly detailed traces which I can send you if you
like
Paul Mackerras wrote:
I am not any kind of expert on the page cache but it seems to me that
maybe after locking the page we should check if it is still the page
we want (i.e. page-mapping and page-index are still correct), and go
back and look up the page again if not. Presumably there will
On Sun, 29 Oct 2000, Linus Torvalds wrote:
approach for 2.4.x where we just re-test against the file size in multiple
places where this can happen - but it would be nicer to handle this more
cleanly.
One possible way is to access page-mapping _only_ under the page lock
and in cases when we
On Sun, 29 Oct 2000, Alexander Viro wrote:
One possible way is to access page-mapping _only_ under the page lock
and in cases when we call -i_mapping-a_ops-foo check the -mapping
before the method call.
I'm leaning towards this for a 2.4.x solution.
As far as I can tell, page-mapping is
On Sun, 29 Oct 2000, Linus Torvalds wrote:
Making it policy that we have to re-test page-mapping after aquireing the
page lock might be the simplest fix for 2.4.x. It still means that we
might end up allowing people to have a "bad" page in the VM space due to
the "test-insert" race
I would expect problems with truncate, mmap, rename, POSIX locks, fasync,
ptrace and mount go unnoticed for _long_. Ditto for parts of procfs
Well the ptrace one still has mysteriously breaks usermode linux against it
on my list here. Was that ever explained. It looked like the stack got
Alan Cox wrote:
I would expect problems with truncate, mmap, rename, POSIX locks, fasync,
ptrace and mount go unnoticed for _long_. Ditto for parts of procfs
Well the ptrace one still has mysteriously breaks usermode linux against it
on my list here. Was that ever explained. It looked
Linus Torvalds wrote:
Now, I don't think this is really a valid usage pattern, so it's most
likely to be a result of a buggy application, but I can imagine having
some strange kind of user-space VM memory management scheme that depends
on SIGBUS to maintain a file length. I've never heard of
18 matches
Mail list logo
