16 Nov, 2012

1 commit


03 Oct, 2012

1 commit

  • Pull user namespace changes from Eric Biederman:
    "This is a mostly modest set of changes to enable basic user namespace
    support. This allows the code to code to compile with user namespaces
    enabled and removes the assumption there is only the initial user
    namespace. Everything is converted except for the most complex of the
    filesystems: autofs4, 9p, afs, ceph, cifs, coda, fuse, gfs2, ncpfs,
    nfs, ocfs2 and xfs as those patches need a bit more review.

    The strategy is to push kuid_t and kgid_t values are far down into
    subsystems and filesystems as reasonable. Leaving the make_kuid and
    from_kuid operations to happen at the edge of userspace, as the values
    come off the disk, and as the values come in from the network.
    Letting compile type incompatible compile errors (present when user
    namespaces are enabled) guide me to find the issues.

    The most tricky areas have been the places where we had an implicit
    union of uid and gid values and were storing them in an unsigned int.
    Those places were converted into explicit unions. I made certain to
    handle those places with simple trivial patches.

    Out of that work I discovered we have generic interfaces for storing
    quota by projid. I had never heard of the project identifiers before.
    Adding full user namespace support for project identifiers accounts
    for most of the code size growth in my git tree.

    Ultimately there will be work to relax privlige checks from
    "capable(FOO)" to "ns_capable(user_ns, FOO)" where it is safe allowing
    root in a user names to do those things that today we only forbid to
    non-root users because it will confuse suid root applications.

    While I was pushing kuid_t and kgid_t changes deep into the audit code
    I made a few other cleanups. I capitalized on the fact we process
    netlink messages in the context of the message sender. I removed
    usage of NETLINK_CRED, and started directly using current->tty.

    Some of these patches have also made it into maintainer trees, with no
    problems from identical code from different trees showing up in
    linux-next.

    After reading through all of this code I feel like I might be able to
    win a game of kernel trivial pursuit."

    Fix up some fairly trivial conflicts in netfilter uid/git logging code.

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (107 commits)
    userns: Convert the ufs filesystem to use kuid/kgid where appropriate
    userns: Convert the udf filesystem to use kuid/kgid where appropriate
    userns: Convert ubifs to use kuid/kgid
    userns: Convert squashfs to use kuid/kgid where appropriate
    userns: Convert reiserfs to use kuid and kgid where appropriate
    userns: Convert jfs to use kuid/kgid where appropriate
    userns: Convert jffs2 to use kuid and kgid where appropriate
    userns: Convert hpfs to use kuid and kgid where appropriate
    userns: Convert btrfs to use kuid/kgid where appropriate
    userns: Convert bfs to use kuid/kgid where appropriate
    userns: Convert affs to use kuid/kgid wherwe appropriate
    userns: On alpha modify linux_to_osf_stat to use convert from kuids and kgids
    userns: On ia64 deal with current_uid and current_gid being kuid and kgid
    userns: On ppc convert current_uid from a kuid before printing.
    userns: Convert s390 getting uid and gid system calls to use kuid and kgid
    userns: Convert s390 hypfs to use kuid and kgid where appropriate
    userns: Convert binder ipc to use kuids
    userns: Teach security_path_chown to take kuids and kgids
    userns: Add user namespace support to IMA
    userns: Convert EVM to deal with kuids and kgids in it's hmac computation
    ...

    Linus Torvalds
     

07 Sep, 2012

1 commit


28 Aug, 2012

1 commit


17 Aug, 2012

1 commit


27 Jul, 2012

1 commit

  • Pull driver core changes from Greg Kroah-Hartman:
    "Here's the big driver core pull request for 3.6-rc1.

    Unlike 3.5, this kernel should be a lot tamer, with the printk changes
    now settled down. All we have here is some extcon driver updates, w1
    driver updates, a few printk cleanups that weren't needed for 3.5, but
    are good to have now, and some other minor fixes/changes in the driver
    core.

    All of these have been in the linux-next releases for a while now.

    Signed-off-by: Greg Kroah-Hartman "

    * tag 'driver-core-3.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (38 commits)
    printk: Export struct log size and member offsets through vmcoreinfo
    Drivers: hv: Change the hex constant to a decimal constant
    driver core: don't trigger uevent after failure
    extcon: MAX77693: Add extcon-max77693 driver to support Maxim MAX77693 MUIC device
    sysfs: fail dentry revalidation after namespace change fix
    sysfs: fail dentry revalidation after namespace change
    extcon: spelling of detach in function doc
    extcon: arizona: Stop microphone detection if we give up on it
    extcon: arizona: Update cable reporting calls and split headset
    PM / Runtime: Do not increment device usage counts before probing
    kmsg - do not flush partial lines when the console is busy
    kmsg - export "continuation record" flag to /dev/kmsg
    kmsg - avoid warning for CONFIG_PRINTK=n compilations
    kmsg - properly print over-long continuation lines
    driver-core: Use kobj_to_dev instead of re-implementing it
    driver-core: Move kobj_to_dev from genhd.h to device.h
    driver core: Move deferred devices to the end of dpm_list before probing
    driver core: move uevent call to driver_register
    driver core: fix shutdown races with probe/remove(v3)
    Extcon: Arizona: Add driver for Wolfson Arizona class devices
    ...

    Linus Torvalds
     

14 Jul, 2012

3 commits


14 Jun, 2012

1 commit


27 Jan, 2012

1 commit

  • Cautious admins may want to restrict access to debugfs. Currently a
    manual chown/chmod e.g. in an init script is needed to achieve that.
    Distributions that want to make the mount options configurable need
    to add extra config files. By allowing to set the root inode's uid,
    gid and mode via mount options no such hacks are needed anymore.
    Instead configuration becomes straight forward via fstab.

    Signed-off-by: Ludwig Nussel
    Signed-off-by: Greg Kroah-Hartman

    Ludwig Nussel
     

04 Jan, 2012

2 commits


23 Aug, 2011

1 commit


19 Feb, 2011

1 commit


04 Feb, 2011

1 commit


29 Oct, 2010

1 commit


26 Oct, 2010

1 commit

  • Instead of always assigning an increasing inode number in new_inode
    move the call to assign it into those callers that actually need it.
    For now callers that need it is estimated conservatively, that is
    the call is added to all filesystems that do not assign an i_ino
    by themselves. For a few more filesystems we can avoid assigning
    any inode number given that they aren't user visible, and for others
    it could be done lazily when an inode number is actually needed,
    but that's left for later patches.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Dave Chinner
    Signed-off-by: Al Viro

    Christoph Hellwig
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

09 Feb, 2010

1 commit


27 Jan, 2010

1 commit


12 Dec, 2009

1 commit

  • Setting fops and private data outside of the mutex at debugfs file
    creation introduces a race where the files can be opened with the wrong
    file operations and private data. It is easy to trigger with a process
    waiting on file creation notification.

    Signed-off-by: Mathieu Desnoyers
    Signed-off-by: Andrew Morton
    Cc: stable
    Signed-off-by: Greg Kroah-Hartman

    Mathieu Desnoyers
     

04 Dec, 2009

1 commit


16 Jun, 2009

1 commit

  • debugfs: dont stop on first failed recursive delete

    While running a while loop of removing a module that removes a debugfs
    directory with debugfs_remove_recursive, and at the same time doing a
    while loop of cat of a file in that directory, I would hit a point where
    somehow the cat of the file caused the remove to fail.

    The result is that other files did not get removed when the module
    was removed. I simple read of one of those file can oops the kernel
    because the operations to the file no longer exist (removed by module).

    The funny thing is that the file being cat'ed was removed. It was
    the siblings that were not. I see in the code to debugfs_remove_recursive
    there's a test that checks if the child fails to bail out of the loop
    to prevent an infinite loop.

    What this patch does is to still try any siblings in that directory.
    If all the siblings fail, or there are no more siblings, then we exit
    the loop.

    This fixes the above symptom, but...

    This is no full proof. It makes the debugfs_remove_recursive a bit more
    robust, but it does not explain why the one file failed. There may
    be some kind of delay deletion that makes the debugfs think it did
    not succeed. So this patch is more of a fix for the symptom but not
    the disease.

    This patch still makes the debugfs_remove_recursive more robust and
    until I can find out why the bug exists, this patch will keep
    the kernel from oopsing in most cases. Even after the cause is found
    I think this change can stand on its own and should be kept.

    [ Impact: prevent kernel oops on module unload and reading debugfs files ]

    Signed-off-by: Steven Rostedt
    Signed-off-by: Greg Kroah-Hartman

    Steven Rostedt
     

23 Mar, 2009

1 commit

  • Impact: add new debugfs API

    With ftrace, some tracers are registered in early initcalls
    and attempt to create files on the debugfs filesystem.
    Depending on when they are activated, they can try to create their
    file at any time. Some checks can be done on the tracing area
    but providing a helper to know if debugfs is registered make it
    really more easy.

    Signed-off-by: Frederic Weisbecker
    Acked-by: Greg Kroah-Hartman
    Cc: Steven Rostedt
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

06 Jan, 2009

1 commit


13 Oct, 2008

1 commit

  • Discussion on the mailing list questioned the use of these
    magic values in userspace, concluding these values are already
    exported to userspace via statfs and their correct/incorrect
    usage is left up to the userspace application.

    - Move special fs magic number definitions to magic.h
    - Add magic.h include

    Signed-off-by: Mimi Zohar
    Reviewed-by: James Morris
    Signed-off-by: James Morris

    Mimi Zohar
     

22 Jul, 2008

1 commit

  • debugfs_remove_recursive() will remove a dentry and all its children.
    Drivers can use this to zap their whole debugfs tree so that they don't
    need to keep track of every single debugfs dentry they created.

    It may fail to remove the whole tree in certain cases:

    sh-3.2# rmmod atmel-mci < /sys/kernel/debug/mmc0/ios/clock
    mmc0: card b368 removed
    atmel_mci atmel_mci.0: Lost dma0chan1, falling back to PIO
    sh-3.2# ls /sys/kernel/debug/mmc0/
    ios

    But I'm not sure if that case can be handled in any sane manner.

    Signed-off-by: Haavard Skinnemoen
    Cc: Pierre Ossman
    Signed-off-by: Greg Kroah-Hartman

    Haavard Skinnemoen
     

05 Mar, 2008

1 commit

  • extern does not belong in C files, move declaration to linux/debugfs.h
    fs/debugfs/file.c:42:30: warning: symbol 'debugfs_file_operations' was not declared. Should it be static?
    fs/debugfs/file.c:54:31: warning: symbol 'debugfs_link_operations' was not declared. Should it be static?

    Signed-off-by: Harvey Harrison
    Signed-off-by: Greg Kroah-Hartman

    Harvey Harrison
     

25 Jan, 2008

5 commits


21 Oct, 2007

1 commit


19 Jul, 2007

1 commit

  • Hi,

    This patch kills the pointless debugfs rmdir() printk() when called on a
    non-empty directory. blktrace will sometimes have to call it a few times
    when forcefully ending a trace, which polutes the log with pointless
    warnings.

    Rationale:

    - It's more code to work-around this "problem" in the debugfs users, and
    you would have to add code to check for empty directories to do so (or
    assume that debugfs is using simple_ helpers, but that would be a
    layering violation).

    - Other rmdir() implementations don't complain about something this
    silly.

    Signed-off-by: Jens Axboe
    Signed-off-by: Greg Kroah-Hartman

    Jens Axboe
     

12 Jul, 2007

1 commit


03 May, 2007

1 commit


17 Feb, 2007

2 commits

  • Just mention which error will be returned if debugfs is disabled. Callers
    should be able to figure out themselves what they need to check.

    Signed-off-by: Cornelia Huck
    Signed-off-by: Greg Kroah-Hartman

    Cornelia Huck
     
  • debugfs: implement symbolic links

    Implement a new function debugfs_create_symlink() which can be used
    to create symbolic links in debugfs. This function can be useful
    for people moving functionality from /proc to debugfs (e.g. the
    gcov-kernel patch).

    Signed-off-by: Peter Oberparleiter
    Signed-off-by: Greg Kroah-Hartman

    Peter Oberparleiter