Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1542887 > unrolled thread

Re: [RFC 09/10] kmod: add helpers for getting kmod count and limit

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC 09/10] kmod: add helpers for getting kmod count and limit Petr Mladek <pmladek@suse.com> - 2016-12-15 18:00 +0100
    Re: [RFC 09/10] kmod: add helpers for getting kmod count and limit "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-12-16 09:00 +0100

#1542887 — Re: [RFC 09/10] kmod: add helpers for getting kmod count and limit

On Thu 2016-12-08 11:49:20, Luis R. Rodriguez wrote:
> This adds helpers for getting access to the kmod count and limit from
> userspace. While at it, this also lets userspace fine tune the kmod
> limit after boot, it uses the shiny new proc_douintvec_minmax().
> 
> These knobs should help userspace more gracefully and deterministically
> handle module loading.
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> ---
>  include/linux/kmod.h |  8 +++++
>  kernel/kmod.c        | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++--
>  kernel/sysctl.c      | 14 +++++++++
>  3 files changed, 103 insertions(+), 2 deletions(-)

I am not sure if it is worth it. As you say in the 3rd patch,
there was rather low limit for 16 years and nobody probably had
problems with it.

Anyway, it seems that such know should also get documented in
Documentation/sysctl/kernel.txt

Best Regards,
Petr

[toc] | [next] | [standalone]

#1543236

On Thu, Dec 15, 2016 at 05:56:19PM +0100, Petr Mladek wrote:
> On Thu 2016-12-08 11:49:20, Luis R. Rodriguez wrote:
> > This adds helpers for getting access to the kmod count and limit from
> > userspace. While at it, this also lets userspace fine tune the kmod
> > limit after boot, it uses the shiny new proc_douintvec_minmax().
> > 
> > These knobs should help userspace more gracefully and deterministically
> > handle module loading.
> >
> > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> > ---
> >  include/linux/kmod.h |  8 +++++
> >  kernel/kmod.c        | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++--
> >  kernel/sysctl.c      | 14 +++++++++
> >  3 files changed, 103 insertions(+), 2 deletions(-)
> 
> I am not sure if it is worth it. As you say in the 3rd patch,
> there was rather low limit for 16 years and nobody probably had
> problems with it.

Note, *probably* - ie, this could have gone unreported for a while, and
to be frank how can we know for sure a pesky module just did not load due
to this? In the case of get_fs_type() issue this can be fatal for a partition
mount, not a good example to wait to look forward to before we take this
serious.

I added the sysctl value mostly for read purposes, the count is probably
useless for any accounting to be done in userspace due to delays this
reading and making this value useful in userspace can have, I can nuke
that. The kmod-limit however seems very useful so that userspace knows
how to properly thread *safely* modprobe calls more deterministically.

Adding write support to let one bump the limit was just an easy convenience
possible given the read support was being added, but its use should
really only be useful for testing purposes post bootup given that the
real value in the limit will be important at boot time prior to the sysctl
parsing. The real know tweak which should be used in case of issues is
the module parameter added earlier.

So I could drop the kmod-count, and just make the kmod-limit read-only.
Thoughts?

> Anyway, it seems that such know should also get documented in
> Documentation/sysctl/kernel.txt

Will do if we keep them, thanks.

  Luis

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web