Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751876AbbFWFbg (ORCPT ); Tue, 23 Jun 2015 01:31:36 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:34581 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750840AbbFWFb0 (ORCPT ); Tue, 23 Jun 2015 01:31:26 -0400 Message-ID: <1435037481.4110.4.camel@edumazet-glaptop2.roam.corp.google.com> Subject: Re: [PATCH v2] fs/file.c: don't acquire files->file_lock in fd_install() From: Eric Dumazet To: Al Viro Cc: Mateusz Guzik , Andrew Morton , "Paul E. McKenney" , Yann Droneaud , Konstantin Khlebnikov , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 23 Jun 2015 07:31:21 +0200 In-Reply-To: <20150622023207.GA24951@ZenIV.linux.org.uk> References: <20150420134326.GC2513@mguzik> <20150420151054.GD2513@mguzik> <1429550126.7346.268.camel@edumazet-glaptop2.roam.corp.google.com> <1429562991.7346.290.camel@edumazet-glaptop2.roam.corp.google.com> <1429639543.7346.329.camel@edumazet-glaptop2.roam.corp.google.com> <20150421200624.GA16097@mguzik> <20150421201201.GB16097@mguzik> <1429650413.18561.10.camel@edumazet-glaptop2.roam.corp.google.com> <1429678768.18561.64.camel@edumazet-glaptop2.roam.corp.google.com> <1430281503.3711.27.camel@edumazet-glaptop2.roam.corp.google.com> <20150622023207.GA24951@ZenIV.linux.org.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1754 Lines: 47 On Mon, 2015-06-22 at 03:32 +0100, Al Viro wrote: > On Tue, Apr 28, 2015 at 09:25:03PM -0700, Eric Dumazet wrote: > > > @@ -553,11 +572,20 @@ void __fd_install(struct files_struct *files, unsigned int fd, > > struct file *file) > > { > > struct fdtable *fdt; > > - spin_lock(&files->file_lock); > > - fdt = files_fdtable(files); > > + > > + rcu_read_lock_sched(); > > + > > + while (unlikely(files->resize_in_progress)) { > > + rcu_read_unlock_sched(); > > + wait_event(files->resize_wait, !files->resize_in_progress); > > + rcu_read_lock_sched(); > > + } > > + /* coupled with smp_wmb() in expand_fdtable() */ > > + smp_rmb(); > > + fdt = rcu_dereference_sched(files->fdt); > > BUG_ON(fdt->fd[fd] != NULL); > > rcu_assign_pointer(fdt->fd[fd], file); > > - spin_unlock(&files->file_lock); > > + rcu_read_unlock_sched(); > > Umm... You've taken something that was safe to use in atomic contexts > and turned into something that might wait for GFP_KERNEL allocation; what's > to guarantee that no users get broken by that? At the very least, you want > to slap might_sleep() in there - the actual sleep is going to be very rare, > so it would be an extremely hard to reproduce and debug. > > AFAICS, all current in-tree users should be safe, but fd_install() is exported > and quiet changes of that sort are rather antisocial. Generally I don't give > a damn about out-of-tree code, but this one is over the top. > > I _think_ it's otherwise OK, but please, add might_sleep() *AND* a note in > Documentation/filesystems/porting. > Good points. I am currently traveling and will address this asap. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/