From: "Stephen C. Tweedie" <sct@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>,
Rik van Riel <riel@nl.linux.org>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Ben LaHaise <bcrl@redhat.com>, Christoph Rohland <cr@sap.com>
Subject: Re: [PATCH] Fix races in 2.4.2-ac22 SysV shared memory
Date: Sun, 25 Mar 2001 00:13:38 +0000 [thread overview]
Message-ID: <20010325001338.C11686@redhat.com> (raw)
In-Reply-To: <20010323011331.J7756@redhat.com> <Pine.LNX.4.31.0103231157200.766-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.31.0103231157200.766-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Fri, Mar 23, 2001 at 11:58:50AM -0800
Hi,
On Fri, Mar 23, 2001 at 11:58:50AM -0800, Linus Torvalds wrote:
> Ehh.. Sleeping with the spin-lock held? Sounds like a truly bad idea.
Uggh --- the shmem code already does, see:
shmem_truncate->shmem_truncate_part->shmem_free_swp->
lookup_swap_cache->find_lock_page
It looks messy: lookup_swap_cache seems to be abusing the page lock
gratuitously, but there are probably callers of it which rely on the
assumption that it performs an implicit wait_on_page().
Rik, do you think it is really necessary to take the page lock and
release it inside lookup_swap_cache? I may be overlooking something,
but I can't see the benefit of it --- we can still race against
page_launder, so the page may still get locked behind our backs after
we get the reference from lookup_swap_cache (page_launder explicitly
avoids taking the pagecache hash spinlock which might avoid this
particular race).
--Stephen
WARNING: multiple messages have this Message-ID (diff)
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>,
Rik van Riel <riel@nl.linux.org>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Ben LaHaise <bcrl@redhat.com>, Christoph Rohland <cr@sap.com>
Subject: Re: [PATCH] Fix races in 2.4.2-ac22 SysV shared memory
Date: Sun, 25 Mar 2001 00:13:38 +0000 [thread overview]
Message-ID: <20010325001338.C11686@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.31.0103231157200.766-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Fri, Mar 23, 2001 at 11:58:50AM -0800
Hi,
On Fri, Mar 23, 2001 at 11:58:50AM -0800, Linus Torvalds wrote:
> Ehh.. Sleeping with the spin-lock held? Sounds like a truly bad idea.
Uggh --- the shmem code already does, see:
shmem_truncate->shmem_truncate_part->shmem_free_swp->
lookup_swap_cache->find_lock_page
It looks messy: lookup_swap_cache seems to be abusing the page lock
gratuitously, but there are probably callers of it which rely on the
assumption that it performs an implicit wait_on_page().
Rik, do you think it is really necessary to take the page lock and
release it inside lookup_swap_cache? I may be overlooking something,
but I can't see the benefit of it --- we can still race against
page_launder, so the page may still get locked behind our backs after
we get the reference from lookup_swap_cache (page_launder explicitly
avoids taking the pagecache hash spinlock which might avoid this
particular race).
--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2001-03-25 0:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-23 1:13 [PATCH] Fix races in 2.4.2-ac22 SysV shared memory Stephen C. Tweedie
2001-03-23 19:58 ` Linus Torvalds
2001-03-23 19:58 ` Linus Torvalds
2001-03-23 22:20 ` Alan Cox
2001-03-23 22:20 ` Alan Cox
2001-03-23 22:23 ` Alexander Viro
2001-03-23 22:23 ` Alexander Viro
2001-03-23 22:29 ` Alan Cox
2001-03-23 22:29 ` Alan Cox
2001-03-23 22:27 ` Linus Torvalds
2001-03-23 22:27 ` Linus Torvalds
2001-03-23 22:35 ` Alan Cox
2001-03-23 22:35 ` Alan Cox
2001-03-23 22:37 ` Linus Torvalds
2001-03-23 22:37 ` Linus Torvalds
2001-03-23 22:31 ` David S. Miller
2001-03-23 22:31 ` David S. Miller
2001-03-25 0:13 ` Stephen C. Tweedie [this message]
2001-03-25 0:13 ` Stephen C. Tweedie
2001-03-25 1:05 ` Rik van Riel
2001-03-25 1:05 ` Rik van Riel
2001-03-25 16:50 ` Stephen C. Tweedie
2001-03-25 16:50 ` Stephen C. Tweedie
2001-03-28 9:18 ` Christoph Rohland
2001-03-28 9:18 ` Christoph Rohland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010325001338.C11686@redhat.com \
--to=sct@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bcrl@redhat.com \
--cc=cr@sap.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@nl.linux.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.