Linus Torvalds <[EMAIL PROTECTED]> writes:
> On 28 Dec 2000, Christoph Rohland wrote:
> >
> > First we need the following patch since otherwise we use a swap entry
> > without having the count increased:
>
> No, that shouldn't be needed.
>
> Look at the code-path: the kernel has the page
On 28 Dec 2000, Christoph Rohland wrote:
>
> First we need the following patch since otherwise we use a swap entry
> without having the count increased:
No, that shouldn't be needed.
Look at the code-path: the kernel has the page locked, so nothing will
de-allocate the swap entry - so it's
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On 27 Dec 2000, Christoph Rohland wrote:
> Woul dyou mind testing this alternate fix instead:
Does not work, but is the right direction I think.
First we need the following patch since otherwise we use a swap entry
without having the count
Linus Torvalds [EMAIL PROTECTED] writes:
On 27 Dec 2000, Christoph Rohland wrote:
Woul dyou mind testing this alternate fix instead:
Does not work, but is the right direction I think.
First we need the following patch since otherwise we use a swap entry
without having the count increased:
On 28 Dec 2000, Christoph Rohland wrote:
First we need the following patch since otherwise we use a swap entry
without having the count increased:
No, that shouldn't be needed.
Look at the code-path: the kernel has the page locked, so nothing will
de-allocate the swap entry - so it's
Linus Torvalds [EMAIL PROTECTED] writes:
On 28 Dec 2000, Christoph Rohland wrote:
First we need the following patch since otherwise we use a swap entry
without having the count increased:
No, that shouldn't be needed.
Look at the code-path: the kernel has the page locked, so
On 27 Dec 2000, Christoph Rohland wrote:
> Marcelo Tosatti <[EMAIL PROTECTED]> writes:
>
> > I think that incrementing the swap entry count will not allow swap from
> > removing the swap entry (as the comment says)
>
> I think the culprit is somewhere else. The error occurs in nopage of a
>
Marcelo Tosatti <[EMAIL PROTECTED]> writes:
> I think that incrementing the swap entry count will not allow swap from
> removing the swap entry (as the comment says)
I think the culprit is somewhere else. The error occurs in nopage of a
process, not in swapoff.
Looking at the following in
On 27 Dec 2000, Christoph Rohland wrote:
> BTW: The generic swapoff path itself has still races if a process is
> paging in a page which is just freed on swap by try_to_unuse. It gives
> 'VM: bad swap entries' and worse. But this is not shmem
> specific. Marcelo would you like to look into
Hi Linus,
The following patch (against clean test13-pre4) removes the races in
shmem_unuse. I changed inode.c to not lock the inode if there is no
write_inode function. So I can grab the inode while holding the
spinlock.
It also optimises the shmem_ftruncate behaviour.
BTW: The generic swapoff
Hi Linus,
The following patch (against clean test13-pre4) removes the races in
shmem_unuse. I changed inode.c to not lock the inode if there is no
write_inode function. So I can grab the inode while holding the
spinlock.
It also optimises the shmem_ftruncate behaviour.
BTW: The generic swapoff
On 27 Dec 2000, Christoph Rohland wrote:
BTW: The generic swapoff path itself has still races if a process is
paging in a page which is just freed on swap by try_to_unuse. It gives
'VM: bad swap entries' and worse. But this is not shmem
specific. Marcelo would you like to look into this?
Marcelo Tosatti [EMAIL PROTECTED] writes:
I think that incrementing the swap entry count will not allow swap from
removing the swap entry (as the comment says)
I think the culprit is somewhere else. The error occurs in nopage of a
process, not in swapoff.
Looking at the following in
On 27 Dec 2000, Christoph Rohland wrote:
Marcelo Tosatti [EMAIL PROTECTED] writes:
I think that incrementing the swap entry count will not allow swap from
removing the swap entry (as the comment says)
I think the culprit is somewhere else. The error occurs in nopage of a
process,
14 matches
Mail list logo
