From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 30 Sep 2007 08:46:46 +0200 From: Jens Axboe Subject: Re: [patch] splice mmap_sem deadlock Message-ID: <20070930064646.GF11717@kernel.dk> References: <20070928160035.GD12538@wotan.suse.de> <20070928173144.GA11717@kernel.dk> <20070928181513.GB11717@kernel.dk> <20070928193017.GC11717@kernel.dk> <20070929131043.GC14159@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070929131043.GC14159@wotan.suse.de> Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: Linus Torvalds , Andrew Morton , Linux Memory Management List List-ID: On Sat, Sep 29 2007, Nick Piggin wrote: > On Fri, Sep 28, 2007 at 01:02:50PM -0700, Linus Torvalds wrote: > > > > > > On Fri, 28 Sep 2007, Jens Axboe wrote: > > > > > > Hmm, part of me doesn't like this patch, since we now end up beating on > > > mmap_sem for each part of the vec. It's fine for a stable patch, but how > > > about > > > > > > - prefaulting the iovec > > > - using __get_user() > > > - only dropping/regrabbing the lock if we have to fault > > > > "__get_user()" doesn't help any. But we should do the same thing we do for > > generic_file_write(), or whatever - probe it while in an atomic region. > > > > So something like the appended might work. Untested. > > I got an idea for getting rid of mmap_sem from here completely. Which > is why I was looking at these callers in the first place. > > It would be really convenient and help me play with the idea if mmap_sem > is wrapped closely around get_user_pages where possible... Well, move it back there in your first patch? Not a big deal, surely :-) > If you're really worried about mmap_sem batching here, can you just > avoid this complexity and do all the get_user()s up-front, before taking > mmap_sem at all? You only have to save PIPE_BUFFERS number of > them. Sure, that is easily doable at the cost of some stack. I have other patches that grow PIPE_BUFFERS dynamically in the pipeline, so I'd prefer not to since that'll then turn into a dynamic allocation. -- Jens Axboe -- 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-mm.org/ . Don't email: email@kvack.org