13 Jan, 2012

3 commits

  • module_param(bool) used to counter-intuitively take an int. In
    fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
    trick.

    This tightens the check (you'll get a warning about incompatible
    return type) but still allows it. Next kernel version, we'll remove
    it.

    Signed-off-by: Rusty Russell

    Rusty Russell
     
  • For historical reasons, we allow module_param(bool) to take an int (or
    an unsigned int). That's going away.

    A few drivers really want an int: they set it to -1 and a parameter
    will set it to 0 or 1. This sucks: reading them from sysfs will give
    'Y' for both -1 and 1, but if we change it to an int, then the users
    might be broken (if they did "param" instead of "param=1").

    Use a new 'bint' parser for them.

    (ntfs has a different problem: it needs an int for debug_msgs because
    it's also exposed via sysctl.)

    Cc: Steve Glendinning
    Cc: Jean Delvare
    Cc: Guenter Roeck
    Cc: Hoang-Nam Nguyen
    Cc: Christoph Raisch
    Cc: Roland Dreier
    Cc: Sean Hefty
    Cc: Hal Rosenstock
    Cc: linux390@de.ibm.com
    Cc: Anton Altaparmakov
    Cc: Jaroslav Kysela
    Cc: Takashi Iwai
    Cc: lm-sensors@lm-sensors.org
    Cc: linux-rdma@vger.kernel.org
    Cc: linux-s390@vger.kernel.org
    Cc: linux-ntfs-dev@lists.sourceforge.net
    Cc: alsa-devel@alsa-project.org
    Acked-by: Takashi Iwai (For the sound part)
    Acked-by: Guenter Roeck (For the hwmon driver)
    Signed-off-by: Rusty Russell

    Rusty Russell
     
  • module_param_array(), unlike its non-array cousins, didn't check the type
    of the variable. Fixing this found two bugs.

    Cc: Luca Risolia
    Cc: Mauro Carvalho Chehab
    Cc: Eric Piel
    Cc: linux-media@vger.kernel.org
    Signed-off-by: Rusty Russell

    Rusty Russell
     

31 Oct, 2011

1 commit

  • There are files which use module_param and MODULE_PARM_DESC
    back to back. They only include moduleparam.h which makes sense,
    but the implicit presence of module.h everywhere hid the fact
    that MODULE_PARM_DESC wasn't in moduleparam.h at all. Relocate
    the macro to moduleparam.h so that the moduleparam infrastructure
    can be used independently of module.h

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

26 Oct, 2011

1 commit

  • The user may use "foo-bar" for a kernel parameter defined as "foo_bar".
    Make sure it works the other way around too.

    Apply the equality of dashes and underscores on early_params and __setup
    params as well.

    The example given in Documentation/kernel-parameters.txt indicates that
    this is the intended behaviour.

    With the patch the kernel accepts "log-buf-len=1M" as expected.
    https://bugzilla.redhat.com/show_bug.cgi?id=744545

    Signed-off-by: Michal Schmidt
    Signed-off-by: Rusty Russell (neatened implementations)

    Michal Schmidt
     

19 May, 2011

1 commit

  • Reorder structure kparam_array to remove 8 bytes of alignment padding on
    64 bit builds, dropping its size from 40 to 32 bytes.

    Also update the macro module_param_array_named to initialise the
    structure using its member names to allow it to be changed without
    touching all its call sites.

    'git grep' finds module_param_array in 1037 places so this patch will
    save a small amount of data space across many modules.

    Signed-off-by: Richard Kennedy
    Signed-off-by: Rusty Russell

    Richard Kennedy
     

24 Jan, 2011

1 commit

  • Add an unused struct declaration statement requiring a
    terminating semicolon to the compile-in case to provoke an
    error if __MODULE_INFO() is used without the terminating
    semicolon. Previously MODULE_ALIAS("foo") (no semicolon)
    compiled fine if MODULE was not selected.

    Cc: Dan Carpenter
    Signed-off-by: Linus Walleij
    Signed-off-by: Rusty Russell

    Linus Walleij
     

27 Oct, 2010

1 commit

  • gcc aligns strings as a performance consideration for those cases where
    strings are being used a lot.

    Their use is not performance critical, and hence it seems better to save
    some space.

    Signed-off-by: Jan Beulich
    Acked-by: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Beulich
     

11 Aug, 2010

6 commits

  • gcc allows this when arg is a function, but sparse complains:

    drivers/char/ipmi/ipmi_watchdog.c:303:1: error: cannot dereference this type
    drivers/char/ipmi/ipmi_watchdog.c:307:1: error: cannot dereference this type
    drivers/char/ipmi/ipmi_watchdog.c:311:1: error: cannot dereference this type

    Reported-by: Randy Dunlap
    Tested-by: Randy Dunlap
    Signed-off-by: Rusty Russell

    Rusty Russell
     
  • Also reorders the macros with the most common ones at the top.

    Signed-off-by: Rusty Russell
    Reviewed-by: Takashi Iwai
    Tested-by: Phil Carmody

    Rusty Russell
     
  • There may be cases (most obviously, sysfs-writable charp parameters) where
    a module needs to prevent sysfs access to parameters.

    Rather than express this in terms of a big lock, the functions are
    expressed in terms of what they protect against. This is clearer, esp.
    if the implementation changes to a module-level or even param-level lock.

    Signed-off-by: Rusty Russell
    Reviewed-by: Takashi Iwai
    Tested-by: Phil Carmody

    Rusty Russell
     
  • Since this section can be read-only (they're in .rodata), they should
    always have been const. Minor flow-through various functions.

    Signed-off-by: Rusty Russell
    Tested-by: Phil Carmody

    Rusty Russell
     
  • This allows us to generalize the KPARAM_KMALLOCED flag, by calling a function
    on every parameter when a module is unloaded.

    Signed-off-by: Rusty Russell
    Reviewed-by: Takashi Iwai
    Tested-by: Phil Carmody

    Rusty Russell
     
  • This is more kernel-ish, saves some space, and also allows us to
    expand the ops without breaking all the callers who are happy for the
    new members to be NULL.

    The few places which defined their own param types are changed to the
    new scheme (more which crept in recently fixed in following patches).

    Since we're touching them anyway, we change get() and set() to take a
    const struct kernel_param (which they really are). This causes some
    harmless warnings until we fix them (in following patches).

    To reduce churn, module_param_call creates the ops struct so the callers
    don't have to change (and casts the functions to reduce warnings).
    The modern version which takes an ops struct is called module_param_cb.

    Signed-off-by: Rusty Russell
    Reviewed-by: Takashi Iwai
    Tested-by: Phil Carmody
    Cc: "David S. Miller"
    Cc: Ville Syrjala
    Cc: Dmitry Torokhov
    Cc: Alessandro Rubini
    Cc: Michal Januszewski
    Cc: Trond Myklebust
    Cc: "J. Bruce Fields"
    Cc: Neil Brown
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-input@vger.kernel.org
    Cc: linux-fbdev-devel@lists.sourceforge.net
    Cc: linux-nfs@vger.kernel.org
    Cc: netdev@vger.kernel.org

    Rusty Russell
     

29 Oct, 2009

1 commit

  • e180a6b7759a "param: fix charp parameters set via sysfs" fixed the case
    where charp parameters written via sysfs were freed, leaving drivers
    accessing random memory.

    Unfortunately, storing a flag in the kparam struct was a bad idea: it's
    rodata so setting it causes an oops on some archs. But that's not all:

    1) module_param_array() on charp doesn't work reliably, since we use an
    uninitialized temporary struct kernel_param.
    2) there's a fundamental race if a module uses this parameter and then
    it's changed: they will still access the old, freed, memory.

    The simplest fix (ie. for 2.6.32) is to never free the memory. This
    prevents all these problems, at cost of a memory leak. In practice, there
    are only 18 places where a charp is writable via sysfs, and all are
    root-only writable.

    Reported-by: Takashi Iwai
    Cc: Sitsofe Wheeler
    Cc: Frederic Weisbecker
    Cc: Christof Schmitt
    Signed-off-by: Rusty Russell
    Cc: stable@kernel.org

    Rusty Russell
     

12 Jun, 2009

3 commits


31 Mar, 2009

1 commit

  • Impact: fix crash on reading from /sys/module/.../ieee80211_default_rc_algo

    The module_param type "charp" simply sets a char * pointer in the
    module to the parameter in the commandline string: this is why we keep
    the (mangled) module command line around. But when set via sysfs (as
    about 11 charp parameters can be) this memory is freed on the way
    out of the write(). Future reads hit random mem.

    So we kstrdup instead: we have to check we're not in early commandline
    parsing, and we have to note when we've used it so we can reliably
    kfree the parameter when it's next overwritten, and also on module
    unload.

    (Thanks to Randy Dunlap for CONFIG_SYSFS=n fixes)

    Reported-by: Sitsofe Wheeler
    Diagnosed-by: Frederic Weisbecker
    Tested-by: Frederic Weisbecker
    Tested-by: Christof Schmitt
    Signed-off-by: Rusty Russell

    Rusty Russell
     

22 Oct, 2008

2 commits

  • There are a lot of one-liner uses of __setup() in the kernel: they're
    cumbersome and not queryable (definitely not settable) via /sys. Yet
    it's ugly to simplify them to module_param(), because by default that
    inserts a prefix of the module name (usually filename).

    So, introduce a "core_param". The parameter gets no prefix, but
    appears in /sys/module/kernel/parameters/ (if non-zero perms arg). I
    thought about using the name "core", but that's more common than
    "kernel". And if you create a module called "kernel", you will die
    a horrible death.

    Signed-off-by: Rusty Russell

    Rusty Russell
     
  • The kparam code tries to handle over-length parameter prefixes at
    runtime. Not only would I bet this has never been tested, it's not
    clear that truncating names is a good idea either.

    So let's check at compile time. We need to move the #define to
    moduleparam.h to do this, though.

    Signed-off-by: Rusty Russell

    Rusty Russell
     

14 Feb, 2008

1 commit

  • On alpha, ia64 and ppc64 only relocations to local data can go into
    read-only sections. The vast majority of module parameters use the global
    generic param_set_*/param_get_* functions, so the 'const' attribute for
    struct kernel_param is not only useless, but it also causes compile
    failures due to 'section type conflict' in those rare cases where
    param_set/get are local functions.

    This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8964

    Signed-off-by: Ivan Kokshaysky
    Cc: Richard Henderson
    Cc: "Luck, Tony"
    Cc: Anton Blanchard
    Cc: Paul Mackerras
    Cc: Adrian Bunk
    Cc: Kamalesh Babulal
    Cc: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ivan Kokshaysky
     

29 Jan, 2008

1 commit


17 Oct, 2007

1 commit


20 Feb, 2007

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial: (25 commits)
    Documentation/kernel-docs.txt update.
    arch/cris: typo in KERN_INFO
    Storage class should be before const qualifier
    kernel/printk.c: comment fix
    update I/O sched Kconfig help texts - CFQ is now default, not AS.
    Remove duplicate listing of Cris arch from README
    kbuild: more doc. cleanups
    doc: make doc. for maxcpus= more visible
    drivers/net/eexpress.c: remove duplicate comment
    add a help text for BLK_DEV_GENERIC
    correct a dead URL in the IP_MULTICAST help text
    fix the BAYCOM_SER_HDX help text
    fix SCSI_SCAN_ASYNC help text
    trivial documentation patch for platform.txt
    Fix typos concerning hierarchy
    Fix comment typo "spin_lock_irqrestore".
    Fix misspellings of "agressive".
    drivers/scsi/a100u2w.c: trivial typo patch
    Correct trivial typo in log2.h.
    Remove useless FIND_FIRST_BIT() macro from cardbus.c.
    ...

    Linus Torvalds
     

18 Feb, 2007

1 commit


17 Feb, 2007

1 commit


08 Dec, 2006

1 commit

  • One of the mistakes a module_param() user can make is to supply default
    value of module parameter as the last argument. module_param() accepts
    permissions instead. If default value is, say, 3 (-------wx), parameter
    becomes world-writeable.

    So far, the only remedy was to apply grep(1) and read drivers submitted
    to -mm. BTDT.

    With this patch applied, compiler will finally do some job.

    *) bounds checking on permissions
    *) world-writeable bit checking on permissions
    *) compile breakage if checks trigger

    First version of this check (only "& 2" part) directly caught 4 out of 7
    places during my last grep.

    Subject: Neverending module_param() bugs
    [X] drivers/acpi/sbs.c:101:module_param(capacity_mode, int, CAPACITY_UNIT);
    [X] drivers/acpi/sbs.c:102:module_param(update_mode, int, UPDATE_MODE);
    [ ] drivers/acpi/sbs.c:103:module_param(update_info_mode, int, UPDATE_INFO_MODE);
    [ ] drivers/acpi/sbs.c:104:module_param(update_time, int, UPDATE_TIME);
    [ ] drivers/acpi/sbs.c:105:module_param(update_time2, int, UPDATE_TIME2);
    [X] drivers/char/watchdog/sbc8360.c:203:module_param(timeout, int, 27);
    [X] drivers/media/video/tuner-simple.c:13:module_param(offset, int, 0666);

    Signed-off-by: Alexey Dobriyan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

26 Mar, 2006

1 commit


07 Jan, 2006

1 commit

  • Now when kbuild passes KBUILD_MODNAME with "" do not __stringify it when
    used. Remove __stringnify for all users.
    This also fixes the output of:

    $ ls -l /sys/module/
    drwxr-xr-x 4 root root 0 2006-01-05 14:24 pcmcia
    drwxr-xr-x 4 root root 0 2006-01-05 14:24 pcmcia_core
    drwxr-xr-x 3 root root 0 2006-01-05 14:24 "processor"
    drwxr-xr-x 3 root root 0 2006-01-05 14:24 "psmouse"

    The quoting of the module names will be gone again.
    Thanks to GregKH + Kay Sievers for reproting this.

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds