It finally dawned on me what the clean fix to sysfs_rename_dir
calling kobject_set_name is.  Move the work into kobject_rename
where it belongs.  The callers serialize us anyway so this is
safe.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When looking at kobject_rename I found two bugs with
that exist when sysfs support is disabled in the kernel.

kobject_rename does not change the name on the kobject when
sysfs support is not compiled in.

kobject_rename without locking attempts to check the
validity of a rename operation, which the kobject layer
simply does not have the infrastructure to do.

This patch documents the previously unstated requirement of
kobject_rename that is the responsibility of the caller to
provide mutual exclusion and to be certain that the new_name
for the kobject is valid.

This patch modifies sysfs_rename_dir in !CONFIG_SYSFS case
to call kobject_set_name to actually change the kobject_name.

This patch removes the bogus and misleading check in kobject_rename
that attempts to see if a rename is valid.  The check is bogus
because we do not have the proper locking.  The check is misleading
because it looks like we can and do perform checking at the kobject
level that we don't.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Because they can be, and because code like this produces a warning if
they're not:

struct device_attribute dev_attr;

sysfs_notify(&kobj, NULL, dev_attr.attr.name);
Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
CC: Neil Brown <neilb@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add a helper that registers simple platform_device w/o resources but with
parent and device data.

This is usefull to cleanup platform code from code that registers such
simple devices as leds-gpio, generic-bl, etc.
Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

As inode creation is protected by sysfs_mutex, ilookup5_nowait()
always either fails to find at all or finds one which is fully
initialized, so using ilookup5_nowait() or ilookup5() doesn't make any
difference.  Switch to ilookup5() as it's planned to be removed.  This
change also makes lookup return value handling a bit simpler.

This change was suggested by Al Viro.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Al Viro <viro@hera.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This creates the attributes before the uevent is sent.
Signed-off-by: NDrew Moseley <dmoseley@mvista.com>
Acked-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use sysfs_streq() in bus_find_device_by_name() so trailing newlines
are ignored (E.G. in bind/unbind).
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

dev_WARN is both compacter and gives better debug information
than just a WARN_ON, since people and tools will copy the device
information message together with the WARN_ON in bug reports.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

device_pm_add() has a WARN_ON that is showing relatively high on
kerneloops.org, but unfortunately the WARN_ON is less than useful
in that it doesn't print any information about what device is causing
the issue.

This patch fixes this by turning the WARN_ON() into the newly
introduces dev_WARN() which will print information about the
device in question.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

in the line of dev_printk(), this patch introduces a dev_WARN() function,
that takes a struct device and then a printk format/args set of arguments.
Unlike dev_printk(), the effect is that of WARN() in that a full warning
message (including filename/line, module list, versions and a backtrace)
is printed in addition to the device name and the arguments.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

On Thu, Sep 11, 2008 at 10:27:10AM +0200, Ingo Molnar wrote:

> and it's working fine on most boxes. One testbox found this new locking
> scenario:
>
> PM: Adding info for No Bus:vcsa7
> EDAC DEBUG: MC0: i82860_check()
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.27-rc6-tip #1
> -------------------------------------------------------
> X/4873 is trying to acquire lock:
>  (&bb->mutex){--..}, at: [<c020ba20>] mmap+0x40/0xa0
>
> but task is already holding lock:
>  (&mm->mmap_sem){----}, at: [<c0125a1e>] sys_mmap2+0x8e/0xc0
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&mm->mmap_sem){----}:
>        [<c017dc96>] validate_chain+0xa96/0xf50
>        [<c017ef2b>] __lock_acquire+0x2cb/0x5b0
>        [<c017f299>] lock_acquire+0x89/0xc0
>        [<c01aa8fb>] might_fault+0x6b/0x90
>        [<c040b618>] copy_to_user+0x38/0x60
>        [<c020bcfb>] read+0xfb/0x170
>        [<c01c09a5>] vfs_read+0x95/0x110
>        [<c01c1443>] sys_pread64+0x63/0x80
>        [<c012146f>] sysenter_do_call+0x12/0x43
>        [<ffffffff>] 0xffffffff
>
> -> #0 (&bb->mutex){--..}:
>        [<c017d8b7>] validate_chain+0x6b7/0xf50
>        [<c017ef2b>] __lock_acquire+0x2cb/0x5b0
>        [<c017f299>] lock_acquire+0x89/0xc0
>        [<c0d6f2ab>] __mutex_lock_common+0xab/0x3c0
>        [<c0d6f698>] mutex_lock_nested+0x38/0x50
>        [<c020ba20>] mmap+0x40/0xa0
>        [<c01b111e>] mmap_region+0x14e/0x450
>        [<c01b170f>] do_mmap_pgoff+0x2ef/0x310
>        [<c0125a3d>] sys_mmap2+0xad/0xc0
>        [<c012146f>] sysenter_do_call+0x12/0x43
>        [<ffffffff>] 0xffffffff
>
> other info that might help us debug this:
>
> 1 lock held by X/4873:
>  #0:  (&mm->mmap_sem){----}, at: [<c0125a1e>] sys_mmap2+0x8e/0xc0
>
> stack backtrace:
> Pid: 4873, comm: X Not tainted 2.6.27-rc6-tip #1
>  [<c017cd09>] print_circular_bug_tail+0x79/0xc0
>  [<c017d8b7>] validate_chain+0x6b7/0xf50
>  [<c017a5b5>] ? trace_hardirqs_off_caller+0x15/0xb0
>  [<c017ef2b>] __lock_acquire+0x2cb/0x5b0
>  [<c017f299>] lock_acquire+0x89/0xc0
>  [<c020ba20>] ? mmap+0x40/0xa0
>  [<c0d6f2ab>] __mutex_lock_common+0xab/0x3c0
>  [<c020ba20>] ? mmap+0x40/0xa0
>  [<c0d6f698>] mutex_lock_nested+0x38/0x50
>  [<c020ba20>] ? mmap+0x40/0xa0
>  [<c020ba20>] mmap+0x40/0xa0
>  [<c01b111e>] mmap_region+0x14e/0x450
>  [<c01afb88>] ? arch_get_unmapped_area_topdown+0xf8/0x160
>  [<c01b170f>] do_mmap_pgoff+0x2ef/0x310
>  [<c0125a3d>] sys_mmap2+0xad/0xc0
>  [<c012146f>] sysenter_do_call+0x12/0x43
>  [<c0120000>] ? __switch_to+0x130/0x220
>  =======================
> evbug.c: Event. Dev: input3, Type: 20, Code: 0, Value: 500
> warning: `sudo' uses deprecated v2 capabilities in a way that may be insecure.
>
> i've attached the config.
>
> at first sight it looks like a genuine bug in fs/sysfs/bin.c?

Yes, it is a real bug by the looks. bin.c takes bb->mutex under mmap_sem
when it is mmapped, and then does its copy_*_user under bb->mutex too.

Here is a basic fix for the sysfs lor.


From: Nick Piggin <npiggin@suse.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch adds a quick check for the driver<->device match before
taking the locks and doin gthe expensive checks. Taking the lock hurts
in asynchronous boot context where the device lock gets hit; one of the
init functions takes the lock and goes to do an expensive hardware init;
the other init functions walk the same PCI list and get stuck on the
lock as a result.

For the common case, we can know there's no chance whatsoever of a match
if the device isn't in the drivers ID table... so this patch does that
check as a best-effort-avoid-the-lock approach.

Bootcharts for before and after can be seen at
http://www.fenrus.org/before.svg
http://www.fenrus.org/after.svg

Note the long time "agp_ali_init" takes in the first graph; my laptop
doesn't even have an ALI chip in it!  (the bootgraphs look a bit
dissimilar, but that's the point, the first one has a bunch of arbitrary
delays in it that cause it to look very different)

This reduces my kernel boot time by about 20%
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If device_register() in device_create_vargs() fails, the device
must be cleaned up with put_device() (which is also fine on NULL)
instead of kfree().
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Make the comments on how to use device_initialize(), device_add()
and device_register() a bit clearer - in particular, explicitly
note that put_device() must be used once we tried to add the device
to the hierarchy.
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch makes the following needlessly global functions static:
- ibft_attr_show_initiator()
- ibft_attr_show_nic()
- ibft_attr_show_target()
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NKonrad Rzeszutek <ketuzsezr@darnok.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Support sysfs_notify from atomic context with new sysfs_notify_dirent

sysfs_notify currently takes sysfs_mutex.
This means that it cannot be called in atomic context.
sysfs_mutex  is sometimes held over a malloc (sysfs_rename_dir)
so it can block on low memory.

In md I want to be able to notify on a sysfs attribute from
atomic context, and I don't want to block on low memory because I
could be in the writeout path for freeing memory.

So:
 - export the "sysfs_dirent" structure along with sysfs_get, sysfs_put
   and sysfs_get_dirent so I can get the sysfs_dirent that I want to
   notify on and hold it in an md structure.
 - split sysfs_notify_dirent out of sysfs_notify so the sysfs_dirent
   can be notified on with no blocking (just a spinlock).
Signed-off-by: NNeil Brown <neilb@suse.de>
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch makes the needlessly global struct platform_pm_ops static.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Base infrastructure to enable per-module debug messages.

I've introduced CONFIG_DYNAMIC_PRINTK_DEBUG, which when enabled centralizes
control of debugging statements on a per-module basis in one /proc file,
currently, <debugfs>/dynamic_printk/modules. When, CONFIG_DYNAMIC_PRINTK_DEBUG,
is not set, debugging statements can still be enabled as before, often by
defining 'DEBUG' for the proper compilation unit. Thus, this patch set has no
affect when CONFIG_DYNAMIC_PRINTK_DEBUG is not set.

The infrastructure currently ties into all pr_debug() and dev_dbg() calls. That
is, if CONFIG_DYNAMIC_PRINTK_DEBUG is set, all pr_debug() and dev_dbg() calls
can be dynamically enabled/disabled on a per-module basis.

Future plans include extending this functionality to subsystems, that define 
their own debug levels and flags.

Usage:

Dynamic debugging is controlled by the debugfs file, 
<debugfs>/dynamic_printk/modules. This file contains a list of the modules that
can be enabled. The format of the file is as follows:

	<module_name> <enabled=0/1>
		.
		.
		.

	<module_name> : Name of the module in which the debug call resides
	<enabled=0/1> : whether the messages are enabled or not

For example:

	snd_hda_intel enabled=0
	fixup enabled=1
	driver enabled=0

Enable a module:

	$echo "set enabled=1 <module_name>" > dynamic_printk/modules

Disable a module:

	$echo "set enabled=0 <module_name>" > dynamic_printk/modules

Enable all modules:

	$echo "set enabled=1 all" > dynamic_printk/modules

Disable all modules:

	$echo "set enabled=0 all" > dynamic_printk/modules

Finally, passing "dynamic_printk" at the command line enables
debugging for all modules. This mode can be turned off via the above
disable command.

[gkh: minor cleanups and tweaks to make the build work quietly]
Signed-off-by: NJason Baron <jbaron@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change how the Ethernet/RNDIS gadget driver builds:  don't
use separate compilation, since it works poorly when key
parts are library code (with init sections etc).  Instead
be as close as we can to "gcc --combine ...".

This is a bit more complicated than most of the others
because it had to resolve a few symbol collisions.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change how the CDC Composite gadget driver builds:  don't
use separate compilation, since it works poorly when key
parts are library code (with init sections etc).  Instead
be as close as we can to "gcc --combine ...".
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change how the file storage gadget driver builds:  don't
use separate compilation, since it works poorly when key
parts are library code (with init sections etc).  Instead
be as close as we can to "gcc --combine ...".
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change how the printer gadget driver builds:  don't use
separate compilation, since it works poorly when key parts
are library code (with init sections etc).  Instead be as
close as we can to "gcc --combine ...".
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change how the MIDI gadget driver builds:  don't use separate
compilation, since it works poorly when key parts are library
code (with init sections etc).  Instead be as close as we can
to "gcc --combine ...".
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change how the Gadget Zero driver builds:  don't use
separate compilation, since it works poorly when key
parts are library code (with init sections etc).
Instead be as close as we can to "gcc --combine ...".
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change how the serial gadget driver builds:  don't use
separate compilation, since it works poorly when key parts
are library code (with init sections etc).  Instead be as
close as we can to "gcc --combine ...".
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that the tree is cleaned up, device_create_drvdata can be safely
removed.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that device_create() has been audited, rename things back to the
original call to be sane.

Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that device_create() has been audited, rename things back to the
original call to be sane.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that device_create() has been audited, rename things back to the
original call to be sane.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that device_create() has been audited, rename things back to the
original call to be sane.

Cc: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that device_create() has been audited, rename things back to the
original call to be sane.

Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that device_create() has been audited, rename things back to the
original call to be sane.

Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that device_create() has been audited, rename things back to the
original call to be sane.

Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that device_create() has been audited, rename things back to the
original call to be sane.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that device_create() has been audited, rename things back to the
original call to be sane.

Cc: Roland Dreier <rolandd@cisco.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that device_create() has been audited, rename things back to the
original call to be sane.

Cc: Ben Collins <ben.collins@ubuntu.com>
Acked-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that device_create() has been audited, rename things back to the
original call to be sane.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that device_create() has been audited, rename things back to the
original call to be sane.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Print the name of the last-accessed sysfs file when we oops, to help track
down oopses which occur in sysfs store/read handlers.  Because these oopses
tend to not leave any trace of the offending code in the stack traces.

Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix "notes" kobject leak

It happens every rmmod if KALLSYMS=y and SYSFS=y.

	# modprobe foo

kobject: 'foo' (ffffffffa00743d0): kobject_add_internal: parent: 'module', set: 'module'
kobject: 'holders' (ffff88017e7c5770): kobject_add_internal: parent: 'foo', set: '<NULL>'
kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env
kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo'
kobject: 'notes' (ffff88017fa9b668): kobject_add_internal: parent: 'foo', set: '<NULL>'
	  ^^^^^

	# rmmod foo

kobject: 'holders' (ffff88017e7c5770): kobject_cleanup
kobject: 'holders' (ffff88017e7c5770): auto cleanup kobject_del
kobject: 'holders' (ffff88017e7c5770): calling ktype release
kobject: (ffff88017e7c5770): dynamic_kobj_release
kobject: 'holders': free name
kobject: 'foo' (ffffffffa00743d0): kobject_cleanup
kobject: 'foo' (ffffffffa00743d0): does not have a release() function, it is broken and must be fixed.
kobject: 'foo' (ffffffffa00743d0): auto cleanup 'remove' event
kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env
kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo'
kobject: 'foo' (ffffffffa00743d0): auto cleanup kobject_del
kobject: 'foo': free name

	[whooops]
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>