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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
