linux-kernel - Re: [RFC PATCH] fs: use a sequence counter instead of file_lock in fd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1429649860.18561.7.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Tue, 21 Apr 2015 13:57:40 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Mateusz Guzik <mguzik@...hat.com>
Cc:	Al Viro <viro@...IV.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Yann Droneaud <ydroneaud@...eya.com>,
	Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] fs: use a sequence counter instead of file_lock in
 fd_install

On Tue, 2015-04-21 at 22:06 +0200, Mateusz Guzik wrote:
> On Tue, Apr 21, 2015 at 11:05:43AM -0700, Eric Dumazet wrote:

> > 3) I avoid multiple threads doing a resize and then only one wins the
> > deal.
> > 
> 
> One could argue this last bit could be committed separately (a different
> logical change).

Not really. The prior code was fine, but the addition of
synchronize_sched() made the overhead much bigger in case multiple
threads do this at the same time.

> 
> As I read up about synchronize_sched and rcu_read_lock_sched, the code
> should be correct.

> >  	spin_lock(&files->file_lock);
> >  	if (!new_fdt)
> >  		return -ENOMEM;
> > @@ -170,9 +173,12 @@ static int expand_fdtable(struct files_struct *files, int nr)
> >  		if (cur_fdt != &files->fdtab)
> >  			call_rcu(&cur_fdt->rcu, free_fdtable_rcu);
> >  	} else {
> > +		WARN_ON_ONCE(1);
> >  		/* Somebody else expanded, so undo our attempt */
> >  		__free_fdtable(new_fdt);
> 
> The reader may be left confused why there is a warning while the comment
> does not indicate anything is wrong.

My intent is to remove completely this code, but I left this
WARN_ON_ONCE() for my tests, just to make sure my theory was right ;)

> 
> >  	}
> > +	/* coupled with smp_rmb() in __fd_install() */
> > +	smp_wmb();
> >  	return 1;
> >  }
> >  
> > @@ -187,19 +193,33 @@ static int expand_fdtable(struct files_struct *files, int nr)
> >  static int expand_files(struct files_struct *files, int nr)
> >  {
> >  	struct fdtable *fdt;
> > +	int expanded = 0;
> >  
> > +begin:
> >  	fdt = files_fdtable(files);
> >  
> >  	/* Do we need to expand? */
> >  	if (nr < fdt->max_fds)
> > -		return 0;
> > +		return expanded;
> >  
> >  	/* Can we expand? */
> >  	if (nr >= sysctl_nr_open)
> >  		return -EMFILE;
> >  
> > +	while (unlikely(files->resize_in_progress)) {
> > +		spin_unlock(&files->file_lock);
> > +		expanded = 1;
> > +		wait_event(files->resize_wait, !files->resize_in_progress);
> > +		spin_lock(&files->file_lock);
> > +		goto begin;
> > +	}
> 
> This does not loop anymore, so s/while/if/ ?

You are right, thanks !



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/