[PATCH] Revert "module, async: async_synchronize_full() on module init iff async is used"

[PATCH] Revert "module, async: async_synchronize_full() on module init iff async is used"

[Igor Pylypiv]

This reverts commit 774a1221e862b343388347bac9b318767336b20b.

We need to finish all async code before the module init sequence is done.
In the reverted commit the PF_USED_ASYNC flag was added to mark a thread
that called async_schedule(). Then the PF_USED_ASYNC flag was used to
determine whether or not async_synchronize_full() needs to be invoked.
This works when modprobe thread is calling async_schedule(), but it
does not work if module dispatches init code to a worker thread which
then calls async_schedule().

For example, PCI driver probing is invoked from a worker thread based on
a node where device is attached:

	if (cpu < nr_cpu_ids)
		error = work_on_cpu(cpu, local_pci_probe, &ddi);
	else
		error = local_pci_probe(&ddi);

We end up in a situation where a worker thread gets the PF_USED_ASYNC flag
set instead of the modprobe thread. As a result, async_synchronize_full()
is not invoked and modprobe completes without waiting for the async code
to finish.

The issue was discovered while loading the pm80xx driver:
(scsi_mod.scan=async)

modprobe pm80xx                      worker
...
  do_init_module()
  ...
    pci_call_probe()
      work_on_cpu(local_pci_probe)
                                     local_pci_probe()
                                       pm8001_pci_probe()
                                         scsi_scan_host()
                                           async_schedule()
                                           worker->flags |= PF_USED_ASYNC;
                                     ...
      < return from worker >
  ...
  if (current->flags & PF_USED_ASYNC) <--- false
  	async_synchronize_full();

Commit 21c3c5d28007 ("block: don't request module during elevator init")
fixed the deadlock issue which the reverted commit 774a1221e862 ("module,
async: async_synchronize_full() on module init iff async is used") tried
to fix.

Since commit 0fdff3ec6d87 ("async, kmod: warn on synchronous
request_module() from async workers") synchronous module loading
from async is not allowed.

Given that the original deadlock issue is fixed and it is no longer allowed
to call synchronous request_module() from async we can remove PF_USED_ASYNC
flag to make module init consistently invoke async_synchronize_full()
unless async module probe is requested.

Signed-off-by: Igor Pylypiv <ipylypiv@google.com>
Reviewed-by: Changyuan Lyu <changyuanl@google.com>
---
 include/linux/sched.h |  1 -
 kernel/async.c        |  3 ---
 kernel/module.c       | 25 +++++--------------------
 3 files changed, 5 insertions(+), 24 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index f5b2be39a78c..75ba8aa60248 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1680,7 +1680,6 @@ extern struct pid *cad_pid;
 #define PF_MEMALLOC		0x00000800	/* Allocating memory */
 #define PF_NPROC_EXCEEDED	0x00001000	/* set_user() noticed that RLIMIT_NPROC was exceeded */
 #define PF_USED_MATH		0x00002000	/* If unset the fpu must be initialized before use */
-#define PF_USED_ASYNC		0x00004000	/* Used async_schedule*(), used by module init */
 #define PF_NOFREEZE		0x00008000	/* This thread should not be frozen */
 #define PF_FROZEN		0x00010000	/* Frozen for system suspend */
 #define PF_KSWAPD		0x00020000	/* I am kswapd */
diff --git a/kernel/async.c b/kernel/async.c
index b8d7a663497f..b2c4ba5686ee 100644
--- a/kernel/async.c
+++ b/kernel/async.c
@@ -205,9 +205,6 @@ async_cookie_t async_schedule_node_domain(async_func_t func, void *data,
 	atomic_inc(&entry_count);
 	spin_unlock_irqrestore(&async_lock, flags);
 
-	/* mark that this task has queued an async job, used by module init */
-	current->flags |= PF_USED_ASYNC;
-
 	/* schedule for execution */
 	queue_work_node(node, system_unbound_wq, &entry->work);
 
diff --git a/kernel/module.c b/kernel/module.c
index 24dab046e16c..46a5c2ed1928 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3725,12 +3725,6 @@ static noinline int do_init_module(struct module *mod)
 	}
 	freeinit->module_init = mod->init_layout.base;
 
-	/*
-	 * We want to find out whether @mod uses async during init.  Clear
-	 * PF_USED_ASYNC.  async_schedule*() will set it.
-	 */
-	current->flags &= ~PF_USED_ASYNC;
-
 	do_mod_ctors(mod);
 	/* Start the module */
 	if (mod->init != NULL)
@@ -3756,22 +3750,13 @@ static noinline int do_init_module(struct module *mod)
 
 	/*
 	 * We need to finish all async code before the module init sequence
-	 * is done.  This has potential to deadlock.  For example, a newly
-	 * detected block device can trigger request_module() of the
-	 * default iosched from async probing task.  Once userland helper
-	 * reaches here, async_synchronize_full() will wait on the async
-	 * task waiting on request_module() and deadlock.
-	 *
-	 * This deadlock is avoided by perfomring async_synchronize_full()
-	 * iff module init queued any async jobs.  This isn't a full
-	 * solution as it will deadlock the same if module loading from
-	 * async jobs nests more than once; however, due to the various
-	 * constraints, this hack seems to be the best option for now.
-	 * Please refer to the following thread for details.
+	 * is done. This has potential to deadlock if synchronous module
+	 * loading is requested from async (which is not allowed!).
 	 *
-	 * http://thread.gmane.org/gmane.linux.kernel/1420814
+	 * See commit 0fdff3ec6d87 ("async, kmod: warn on synchronous
+	 * request_module() from async workers") for more details.
 	 */
-	if (!mod->async_probe_requested && (current->flags & PF_USED_ASYNC))
+	if (!mod->async_probe_requested)
 		async_synchronize_full();
 
 	ftrace_free_mem(mod, mod->init_layout.base, mod->init_layout.base +
-- 
2.35.0.rc0.227.g00780c9af4-goog

Re: [PATCH] Revert "module, async: async_synchronize_full() on module init iff async is used"

[Linus Torvalds]

On Fri, Jan 28, 2022 at 1:40 AM Igor Pylypiv <ipylypiv@google.com> wrote:
>
> This reverts commit 774a1221e862b343388347bac9b318767336b20b.

Whee. That's from early 2013, more than 9 years ago.

> This works when modprobe thread is calling async_schedule(), but it
> does not work if module dispatches init code to a worker thread which
> then calls async_schedule().

Hmm.

You make a good argument:

> Commit 21c3c5d28007 ("block: don't request module during elevator init")
> fixed the deadlock issue which the reverted commit 774a1221e862 ("module,
> async: async_synchronize_full() on module init iff async is used") tried
> to fix.
>
> Since commit 0fdff3ec6d87 ("async, kmod: warn on synchronous
> request_module() from async workers") synchronous module loading
> from async is not allowed.

This does seem to imply that limiting it to PF_USED_ASYNC is largely
pointless, at least for the originally stated reason of deadlocks with
other module loading.

However, we've done this for *so* long that I wonder if there might be
situations that have ended up depending on the lack of synchronization
for pure performance reasons.

If *this* module loading process started the async work, then we'd
wait for it, but what if there's other async work that was started by
others? This revert would now make us wait for that async work too,
and that might be a big deal slowing things down at boot time.

Looking at it, this is all under the 'module_mutex', so I guess we are
already single-threaded at least wrt loading other modules, so the
amount of unrelated async work going on is presumably fairly low and
that isn't an issue.

Anyway, I think this patch is the right thing to do, but just the fact
that we've avoided that async wait for so long makes me a bit nervous
about fallout from the revert.

Comments? Maybe this is a "just apply it, see if somebody screams" situation?

                   Linus

Re: [PATCH] Revert "module, async: async_synchronize_full() on module init iff async is used"

[Igor Pylypiv]

On Fri, Jan 28, 2022 at 09:39:12AM +0200, Linus Torvalds wrote:
> On Fri, Jan 28, 2022 at 1:40 AM Igor Pylypiv <ipylypiv@google.com> wrote:
> >
> > This reverts commit 774a1221e862b343388347bac9b318767336b20b.
> 
> Whee. That's from early 2013, more than 9 years ago.
> 
> > This works when modprobe thread is calling async_schedule(), but it
> > does not work if module dispatches init code to a worker thread which
> > then calls async_schedule().
> 
> Hmm.
> 
> You make a good argument:
> 
> > Commit 21c3c5d28007 ("block: don't request module during elevator init")
> > fixed the deadlock issue which the reverted commit 774a1221e862 ("module,
> > async: async_synchronize_full() on module init iff async is used") tried
> > to fix.
> >
> > Since commit 0fdff3ec6d87 ("async, kmod: warn on synchronous
> > request_module() from async workers") synchronous module loading
> > from async is not allowed.
> 
> This does seem to imply that limiting it to PF_USED_ASYNC is largely
> pointless, at least for the originally stated reason of deadlocks with
> other module loading.
> 
> However, we've done this for *so* long that I wonder if there might be
> situations that have ended up depending on the lack of synchronization
> for pure performance reasons.
> 
> If *this* module loading process started the async work, then we'd
> wait for it, but what if there's other async work that was started by
> others? This revert would now make us wait for that async work too,
> and that might be a big deal slowing things down at boot time.

Thanks Linus! It is not like we have no wait at all today, we have it
for drivers that call async directly (not through a worker). A potential
future refactor of some driver to start using async may also "suddenly"
enable synchronization through PF_USED_ASYNC.

In case someone encounters a noticeable boot time slowdown they can pass
the 'async_probe' parameter to probe a waiting module asynchronously.

> 
> Looking at it, this is all under the 'module_mutex', so I guess we are
> already single-threaded at least wrt loading other modules, so the
> amount of unrelated async work going on is presumably fairly low and
> that isn't an issue.
> 
> Anyway, I think this patch is the right thing to do, but just the fact
> that we've avoided that async wait for so long makes me a bit nervous
> about fallout from the revert.
> 
> Comments? Maybe this is a "just apply it, see if somebody screams" situation?
> 
>                    Linus

Re: [PATCH] Revert "module, async: async_synchronize_full() on module init iff async is used"

[Tejun Heo]

On Thu, Jan 27, 2022 at 03:39:53PM -0800, Igor Pylypiv wrote:
> This reverts commit 774a1221e862b343388347bac9b318767336b20b.
> 
> We need to finish all async code before the module init sequence is done.
> In the reverted commit the PF_USED_ASYNC flag was added to mark a thread
> that called async_schedule(). Then the PF_USED_ASYNC flag was used to
> determine whether or not async_synchronize_full() needs to be invoked.
> This works when modprobe thread is calling async_schedule(), but it
> does not work if module dispatches init code to a worker thread which
> then calls async_schedule().
> 
> For example, PCI driver probing is invoked from a worker thread based on
> a node where device is attached:
> 
> 	if (cpu < nr_cpu_ids)
> 		error = work_on_cpu(cpu, local_pci_probe, &ddi);
> 	else
> 		error = local_pci_probe(&ddi);
> 
> We end up in a situation where a worker thread gets the PF_USED_ASYNC flag
> set instead of the modprobe thread. As a result, async_synchronize_full()
> is not invoked and modprobe completes without waiting for the async code
> to finish.
> 
> The issue was discovered while loading the pm80xx driver:
> (scsi_mod.scan=async)
> 
> modprobe pm80xx                      worker
> ...
>   do_init_module()
>   ...
>     pci_call_probe()
>       work_on_cpu(local_pci_probe)
>                                      local_pci_probe()
>                                        pm8001_pci_probe()
>                                          scsi_scan_host()
>                                            async_schedule()
>                                            worker->flags |= PF_USED_ASYNC;
>                                      ...
>       < return from worker >
>   ...
>   if (current->flags & PF_USED_ASYNC) <--- false
>   	async_synchronize_full();
> 
> Commit 21c3c5d28007 ("block: don't request module during elevator init")
> fixed the deadlock issue which the reverted commit 774a1221e862 ("module,
> async: async_synchronize_full() on module init iff async is used") tried
> to fix.
> 
> Since commit 0fdff3ec6d87 ("async, kmod: warn on synchronous
> request_module() from async workers") synchronous module loading
> from async is not allowed.
> 
> Given that the original deadlock issue is fixed and it is no longer allowed
> to call synchronous request_module() from async we can remove PF_USED_ASYNC
> flag to make module init consistently invoke async_synchronize_full()
> unless async module probe is requested.
> 
> Signed-off-by: Igor Pylypiv <ipylypiv@google.com>
> Reviewed-by: Changyuan Lyu <changyuanl@google.com>

That's quite a walk down the memory lane and I agree with your analysis. The
PF_USED_ASYNC is redundant for correctness with the removal of synchrnous
loading from iosched path and the WARN_ON guarantees that nothing in kernel
is creating a similar situation.

Acked-by: Tejun Heo <tj@kernel.org>

Thanks.

-- 
tejun

Re: [PATCH] Revert "module, async: async_synchronize_full() on module init iff async is used"

[Tejun Heo]

On Tue, Feb 01, 2022 at 07:43:27AM -1000, Tejun Heo wrote:
> That's quite a walk down the memory lane and I agree with your analysis. The
> PF_USED_ASYNC is redundant for correctness with the removal of synchrnous
> loading from iosched path and the WARN_ON guarantees that nothing in kernel
> is creating a similar situation.
> 
> Acked-by: Tejun Heo <tj@kernel.org>

BTW, I can route this through workqueue tree but -mm or going to Linus's
tree directly might be a better option. Any opinions?

Thanks.

-- 
tejun

Re: [PATCH] Revert "module, async: async_synchronize_full() on module init iff async is used"

[Tejun Heo]

Hello,

On Fri, Jan 28, 2022 at 09:39:12AM +0200, Linus Torvalds wrote:
> However, we've done this for *so* long that I wonder if there might be
> situations that have ended up depending on the lack of synchronization
> for pure performance reasons.
> 
> If *this* module loading process started the async work, then we'd
> wait for it, but what if there's other async work that was started by
> others? This revert would now make us wait for that async work too,
> and that might be a big deal slowing things down at boot time.
> 
> Looking at it, this is all under the 'module_mutex', so I guess we are
> already single-threaded at least wrt loading other modules, so the
> amount of unrelated async work going on is presumably fairly low and
> that isn't an issue.

Looks like we're multi-threaded while running the mod inits which launch the
async jobs and single-threaded while waiting for them to finish. Greg should
know a lot better than me but according to my hazy memory and cursory code
reading udev is multi-processed when loading modules, which makes it a lot
less likely that this will impact boot time in most cases.

> Anyway, I think this patch is the right thing to do, but just the fact
> that we've avoided that async wait for so long makes me a bit nervous
> about fallout from the revert.
> 
> Comments? Maybe this is a "just apply it, see if somebody screams" situation?

So, yeah, I think the risk is pretty low and even in the unlikely case that
someone is affected, the workaround is pretty straight-forward - not waiting
for the module loading to finish if appropriate.

Thanks.

-- 
tejun

Re: [PATCH] Revert "module, async: async_synchronize_full() on module init iff async is used"

[Greg Kroah-Hartman]

On Tue, Feb 01, 2022 at 08:13:14AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Fri, Jan 28, 2022 at 09:39:12AM +0200, Linus Torvalds wrote:
> > However, we've done this for *so* long that I wonder if there might be
> > situations that have ended up depending on the lack of synchronization
> > for pure performance reasons.
> > 
> > If *this* module loading process started the async work, then we'd
> > wait for it, but what if there's other async work that was started by
> > others? This revert would now make us wait for that async work too,
> > and that might be a big deal slowing things down at boot time.
> > 
> > Looking at it, this is all under the 'module_mutex', so I guess we are
> > already single-threaded at least wrt loading other modules, so the
> > amount of unrelated async work going on is presumably fairly low and
> > that isn't an issue.
> 
> Looks like we're multi-threaded while running the mod inits which launch the
> async jobs and single-threaded while waiting for them to finish. Greg should
> know a lot better than me but according to my hazy memory and cursory code
> reading udev is multi-processed when loading modules, which makes it a lot
> less likely that this will impact boot time in most cases.

I think userspace is multi-processed here, which should help with the
reading of the modules from disk at boot while others are actually being
loaded due to the kernel lock.

> > Anyway, I think this patch is the right thing to do, but just the fact
> > that we've avoided that async wait for so long makes me a bit nervous
> > about fallout from the revert.
> > 
> > Comments? Maybe this is a "just apply it, see if somebody screams" situation?
> 
> So, yeah, I think the risk is pretty low and even in the unlikely case that
> someone is affected, the workaround is pretty straight-forward - not waiting
> for the module loading to finish if appropriate.

I agree with Linus, let's see if anyone notices :)

thanks,

greg k-h

Re: [PATCH] Revert "module, async: async_synchronize_full() on module init iff async is used"

[Luis Chamberlain]

On Tue, Feb 01, 2022 at 07:50:08AM -1000, Tejun Heo wrote:
> On Tue, Feb 01, 2022 at 07:43:27AM -1000, Tejun Heo wrote:
> > That's quite a walk down the memory lane and I agree with your analysis. The
> > PF_USED_ASYNC is redundant for correctness with the removal of synchrnous
> > loading from iosched path and the WARN_ON guarantees that nothing in kernel
> > is creating a similar situation.
> > 
> > Acked-by: Tejun Heo <tj@kernel.org>
> 
> BTW, I can route this through workqueue tree but -mm or going to Linus's
> tree directly might be a better option. Any opinions?

FWIW, although I was not working on modules when the reverted commit was
merged, my take on this is concern for a regression, much more than
others. However I do agree that async probe can help for any slowdown,
and the idea was that folks would eventually strive slowly to make more
and more modules default to async probe as they can verify that's fine.

With that said,

Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>

And I'd prefer this go through Linus' tree since this is a fix and
can be merged already. That would help with Aaron's kernel/module.c
refactor work (no functional changes) too as that will soon slice and
dice that to a kernel/module/*.c files.

 Luis

Re: [PATCH] Revert "module, async: async_synchronize_full() on module init iff async is used"

[Linus Torvalds]

On Tue, Feb 1, 2022 at 9:50 AM Tejun Heo <tj@kernel.org> wrote:
>
> BTW, I can route this through workqueue tree but -mm or going to Linus's
> tree directly might be a better option. Any opinions?

I'll take it directly. Hopefully nobody notices anything at all - but
if it causes unexpected serialization and somebody screams we'll know
more at that point..

           Linus