All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Prarit Bhargava <prarit@redhat.com>
Cc: Jessica Yu <jeyu@kernel.org>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-s390@vger.kernel.org, Cathy Avery <cavery@redhat.com>
Subject: Re: [-next] system hangs likely due to "modules: Only return -EEXIST for modules that have finished loading"
Date: Mon, 29 Apr 2019 07:55:20 +0200	[thread overview]
Message-ID: <20190429055520.GA3665@osiris> (raw)
In-Reply-To: <6a69074a-e913-3b67-feef-9b62a7400f8a@redhat.com>

On Sat, Apr 27, 2019 at 06:42:51AM -0400, Prarit Bhargava wrote:
> On 4/27/19 6:24 AM, Heiko Carstens wrote:
> 
> > 
> > diff --git a/kernel/module.c b/kernel/module.c
> > index 410eeb7e4f1d..48748cfec991 100644
> > --- a/kernel/module.c
> > +++ b/kernel/module.c
> > @@ -3585,6 +3585,7 @@ again:
> >  					       finished_loading(mod->name));
> >  			if (err)
> >  				goto out_unlocked;
> > +			cond_resched();
> Heiko, I'm testing on 2-cpu systems which appear to show the problem ~10% of the
> time.  On another system I backed out my original patch to set a baseline, and
> noticed that occasionally the time to boot the system doubles from ~4 seconds to
> 9 seconds.  Is this something you're also concerned with?

This _could_ be an issue, since I see the problem much more likely to
happen on systems with many devices (where many means only something
like 10 block devices). As far as I can tell it looks like
systemd/udevd tries to modprobe at the s390-trng module for each(!)
device.
I have no idea why it is doing that... however given that (failed)
module handling now sometimes takes more time, this might become a
real issue on system with several 1000s of block devices, which is a
realistic scenario at least on s390.

      reply	other threads:[~2019-04-29  5:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-26 13:07 [-next] system hangs likely due to "modules: Only return -EEXIST for modules that have finished loading" Heiko Carstens
2019-04-26 13:22 ` Prarit Bhargava
2019-04-26 15:07   ` Heiko Carstens
2019-04-26 16:09     ` Jessica Yu
2019-04-26 17:15       ` Prarit Bhargava
2019-04-26 18:10       ` Prarit Bhargava
2019-04-26 19:45         ` Prarit Bhargava
2019-04-27  0:20           ` Prarit Bhargava
2019-04-27 10:24             ` Heiko Carstens
2019-04-27 10:35               ` Prarit Bhargava
2019-04-27 10:42               ` Prarit Bhargava
2019-04-29  5:55                 ` Heiko Carstens [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190429055520.GA3665@osiris \
    --to=heiko.carstens@de.ibm.com \
    --cc=cavery@redhat.com \
    --cc=jeyu@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=prarit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.