-stable review patch. If anyone has any objections, please let us know.
--
From: J. Bruce Fields <[EMAIL PROTECTED]>
patch 97855b49b6bac0bd25f16b017883634d13591d00 in mainline.
It's currently possible to send posix_locks_deadlock() into an infinite
loop (under the BKL).
For no
On Wed, 2007-11-14 at 23:24 +0100, Nick Piggin wrote:
> mmap()s can be different from read in that the syscall may have little
> relation to when the data gets used. But I guess it's still a best
> effort thing. Fair enough.
Agreed that mmap() is special and very problematic on NFS. However I
ca
On Wed, 2007-11-14 at 22:50 +0100, Peter Zijlstra wrote:
> Right, but I guess what Nick asked is, if pages could be stale to start
> with, how is that avoided in the future.
>
> The way I understand it, this re-validate is just a best effort at
> getting a coherent image.
The normal convention f
On Wed, Nov 14, 2007 at 05:18:50PM -0500, Trond Myklebust wrote:
>
> On Wed, 2007-11-14 at 22:50 +0100, Peter Zijlstra wrote:
> > Right, but I guess what Nick asked is, if pages could be stale to start
> > with, how is that avoided in the future.
> >
> > The way I understand it, this re-validate
On Wed, 2007-11-14 at 16:41 -0500, Trond Myklebust wrote:
> On Wed, 2007-11-14 at 22:31 +0100, Peter Zijlstra wrote:
> > On Wed, 2007-11-14 at 22:22 +0100, Nick Piggin wrote:
> > > On Wed, Nov 14, 2007 at 09:01:39PM +0100, Peter Zijlstra wrote:
> > > > Normal locking order is:
> > > >
> > > > i
On Wed, 2007-11-14 at 22:31 +0100, Peter Zijlstra wrote:
> On Wed, 2007-11-14 at 22:22 +0100, Nick Piggin wrote:
> > On Wed, Nov 14, 2007 at 09:01:39PM +0100, Peter Zijlstra wrote:
> > > Normal locking order is:
> > >
> > > i_mutex
> > > mmap_sem
> > >
> > > However NFS's ->mmap hook, whic
On Wed, Nov 14, 2007 at 03:59:39PM +, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Christoph Lameter has patches exactly to make PAGE_CACHE_SIZE larger than
> > PAGE_SIZE, and they seem to work without much effort. I happen to hate the
> > patches ;) but that doesn't cha
On Wed, 2007-11-14 at 22:22 +0100, Nick Piggin wrote:
> On Wed, Nov 14, 2007 at 09:01:39PM +0100, Peter Zijlstra wrote:
> > Normal locking order is:
> >
> > i_mutex
> > mmap_sem
> >
> > However NFS's ->mmap hook, which is called under mmap_sem, can take i_mutex.
> > Avoid this potential de
On Wed, Nov 14, 2007 at 03:57:46PM +, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > In core code, the PAGE_CACHE_SIZE is for page cache struct pages. Single
> > struct pages (not page arrays). Take a look at generic mapping read or
> > something.
>
> So you're saying a
On Wed, 2007-11-14 at 21:01 +0100, Peter Zijlstra wrote:
> Currently there is an AB-BA deadlock in NFS mmap.
>
> nfs_file_mmap() can take i_mutex, while holding mmap_sem, whereas the regular
> locking order is the other way around.
>
> This patch-set attempts to solve this issue.
Looks good fro
On Wed, Nov 14, 2007 at 09:01:39PM +0100, Peter Zijlstra wrote:
> Normal locking order is:
>
> i_mutex
> mmap_sem
>
> However NFS's ->mmap hook, which is called under mmap_sem, can take i_mutex.
> Avoid this potential deadlock by doing the work that requires i_mutex from
> the new ->mmap_pr
Seems I forgot to mention this is an RFC :-)
On Wed, 2007-11-14 at 21:01 +0100, Peter Zijlstra wrote:
> Currently there is an AB-BA deadlock in NFS mmap.
>
> nfs_file_mmap() can take i_mutex, while holding mmap_sem, whereas the regular
> locking order is the other way around.
>
> This patch-set
It appears that some filesystems (NFS) require i_mutex in ->mmap(). This
violates the normal locking order of:
i_mutex
mmap_sem
In order to provide a mmap hook that is outside of mmap_sem, pull this lock
into do_mmap{,_pgoff}.
___do_mmap_pgoff() - base function, requires mmap_sem
__do_mmap
Some filesystems (NFS) need i_mutex in ->mmap(), this violates the normal
locking order. Provide a hook before we take mmap_sem.
This leaves a window between ->mmap_prepare() and ->mmap(), if thats a problem
(Trond?) we could also provide ->mmap_finish() and guarantee it being called
if ->mmap_pre
Currently there is an AB-BA deadlock in NFS mmap.
nfs_file_mmap() can take i_mutex, while holding mmap_sem, whereas the regular
locking order is the other way around.
This patch-set attempts to solve this issue.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the bo
Normal locking order is:
i_mutex
mmap_sem
However NFS's ->mmap hook, which is called under mmap_sem, can take i_mutex.
Avoid this potential deadlock by doing the work that requires i_mutex from
the new ->mmap_prepare().
[ Is this sufficient, or does it introduce a race? ]
Signed-off-by: P
On Wed, Nov 14, 2007 at 12:32:45PM -0700, Andreas Dilger wrote:
> On Nov 14, 2007 11:32 -0500, Chuck Lever wrote:
> > I disagree: we don't need a "bullet-proof" log. We can get a significant
> > performance improvement even with a permanent dnotify log implemented in
> > user-space. We already
On Nov 14, 2007 11:32 -0500, Chuck Lever wrote:
> I disagree: we don't need a "bullet-proof" log. We can get a significant
> performance improvement even with a permanent dnotify log implemented in
> user-space. We already have well-defined fallback behavior if such a log
> is missing or inco
On Wed, Nov 14, 2007 at 02:22:51PM -0500, Jon Smirl wrote:
> On 11/14/07, J. Bruce Fields <[EMAIL PROTECTED]> wrote:
> > On Wed, Nov 14, 2007 at 04:30:16PM +0100, Andi Kleen wrote:
> > > "Jon Smirl" <[EMAIL PROTECTED]> writes:
> > >
> > > > On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
> > >
On 11/14/07, J. Bruce Fields <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 14, 2007 at 04:30:16PM +0100, Andi Kleen wrote:
> > "Jon Smirl" <[EMAIL PROTECTED]> writes:
> >
> > > On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
> > >> On Nov 13, 2007, at 7:04 PM, Jon Smirl wrote:
> > >> > Is it feasibl
On Wed, Nov 14, 2007 at 04:30:16PM +0100, Andi Kleen wrote:
> "Jon Smirl" <[EMAIL PROTECTED]> writes:
>
> > On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
> >> On Nov 13, 2007, at 7:04 PM, Jon Smirl wrote:
> >> > Is it feasible to do something like this in the linux file system
> >> > archite
On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
> >> Jon Smirl wrote:
> >>> On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
> On Nov 13, 2007, at 7:04 PM, Jon Smirl wrote:
> > Is it feasible to do something
Jon Smirl wrote:
On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
Jon Smirl wrote:
On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
On Nov 13, 2007, at 7:04 PM, Jon Smirl wrote:
Is it feasible to do something like this in the linux file system
architecture?
Beagle beats on my disk for
Nick Piggin <[EMAIL PROTECTED]> wrote:
> Christoph Lameter has patches exactly to make PAGE_CACHE_SIZE larger than
> PAGE_SIZE, and they seem to work without much effort. I happen to hate the
> patches ;) but that doesn't change the fact that PAGE_CACHE_SIZE is
> relatively useful and it is not at
Nick Piggin <[EMAIL PROTECTED]> wrote:
> In core code, the PAGE_CACHE_SIZE is for page cache struct pages. Single
> struct pages (not page arrays). Take a look at generic mapping read or
> something.
So you're saying a struct page controls an area of PAGE_CACHE_SIZE, not an
area of PAGE_SIZE? I
"Jon Smirl" <[EMAIL PROTECTED]> writes:
> On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
>> On Nov 13, 2007, at 7:04 PM, Jon Smirl wrote:
>> > Is it feasible to do something like this in the linux file system
>> > architecture?
>> >
>> > Beagle beats on my disk for an hour when I reboot. Of c
On Wed, Nov 14, 2007 at 01:56:53PM +, David Howells wrote:
>
> Are we ever going to have PAGE_CACHE_SIZE != PAGE_SIZE? If not, why not
> discard PAGE_CACHE_SIZE as it's then redundant.
>
Christoph Lameter has patches exactly to make PAGE_CACHE_SIZE larger than
PAGE_SIZE, and they seem to wo
On Wed, Nov 14, 2007 at 12:18:43PM +, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > > The problem is that the code called assumes that the struct page *
> > > argument points to a single page, not an array of pages as would
> > > presumably be the case if PAGE_CACHE_SIZE
On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
> >> On Nov 13, 2007, at 7:04 PM, Jon Smirl wrote:
> >>> Is it feasible to do something like this in the linux file system
> >>> architecture?
> >>>
> >>> Beagle beats on m
Jon Smirl wrote:
On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
On Nov 13, 2007, at 7:04 PM, Jon Smirl wrote:
Is it feasible to do something like this in the linux file system
architecture?
Beagle beats on my disk for an hour when I reboot. Of course I don't
like that and I shut Beagle of
Are we ever going to have PAGE_CACHE_SIZE != PAGE_SIZE? If not, why not
discard PAGE_CACHE_SIZE as it's then redundant.
PAGE_CACHE_SIZE is also an ill-defined concept. Just grep in Documentation/
and it only comes up in a couple of places, neither particularly informative.
If there's a possibi
On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
> On Nov 13, 2007, at 7:04 PM, Jon Smirl wrote:
> > Is it feasible to do something like this in the linux file system
> > architecture?
> >
> > Beagle beats on my disk for an hour when I reboot. Of course I don't
> > like that and I shut Beagle of
On Nov 13, 2007, at 7:04 PM, Jon Smirl wrote:
Is it feasible to do something like this in the linux file system
architecture?
Beagle beats on my disk for an hour when I reboot. Of course I don't
like that and I shut Beagle off.
Leopard, by the way, does exactly this: it has a daemon that sta
Nick Piggin <[EMAIL PROTECTED]> wrote:
> > The problem is that the code called assumes that the struct page *
> > argument points to a single page, not an array of pages as would
> > presumably be the case if PAGE_CACHE_SIZE > PAGE_SIZE.
>
> Incorrect. Christoph's patch for example does this by u
34 matches
Mail list logo
