From: Christoph Rohland <cr@sap.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
MM mailing list <linux-mm@kvack.org>
Subject: Re: [Patch] deadlock on write in tmpfs
Date: 02 May 2001 14:00:53 +0200 [thread overview]
Message-ID: <m3hez4arka.fsf@linux.local> (raw)
In-Reply-To: <m3hez5ci6p.fsf@linux.local> <20010501173210.S26638@redhat.com>
In-Reply-To: <20010501173210.S26638@redhat.com>
Hi Stephen,
On Tue, 1 May 2001, Stephen C. Tweedie wrote:
> If the locking is for a completely different reason, then a
> different semaphore is quite appropriate. In this case you're
> trying to lock the shm internal info structures, which is quite
> different from the sort of inode locking which the VFS tries to do
> itself, so the new semaphore appears quite clean --- and definitely
> needed.
It's not the addition to the inode semaphore I do care about, but the
addition to the spin lock which protects also the shmem internals. But
you are probably right: It only protects the onthefly pages between
page cache and swap cache.
Greetings
Christoph
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Rohland <cr@sap.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
MM mailing list <linux-mm@kvack.org>
Subject: Re: [Patch] deadlock on write in tmpfs
Date: 02 May 2001 14:00:53 +0200 [thread overview]
Message-ID: <m3hez4arka.fsf@linux.local> (raw)
In-Reply-To: <20010501173210.S26638@redhat.com>
Hi Stephen,
On Tue, 1 May 2001, Stephen C. Tweedie wrote:
> If the locking is for a completely different reason, then a
> different semaphore is quite appropriate. In this case you're
> trying to lock the shm internal info structures, which is quite
> different from the sort of inode locking which the VFS tries to do
> itself, so the new semaphore appears quite clean --- and definitely
> needed.
It's not the addition to the inode semaphore I do care about, but the
addition to the spin lock which protects also the shmem internals. But
you are probably right: It only protects the onthefly pages between
page cache and swap cache.
Greetings
Christoph
--
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-05-02 12:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-01 13:39 [Patch] deadlock on write in tmpfs Christoph Rohland
2001-05-01 13:39 ` Christoph Rohland
2001-05-01 16:32 ` Stephen C. Tweedie
2001-05-01 16:32 ` Stephen C. Tweedie
2001-05-02 12:00 ` Christoph Rohland [this message]
2001-05-02 12:00 ` 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=m3hez4arka.fsf@linux.local \
--to=cr@sap.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.com \
--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.