From: Tejun Heo <tj@kernel.org>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH] sysfs: handle duplicate removal attempts in sysfs_remove_group()
Date: Wed, 20 Nov 2013 01:18:30 -0500 [thread overview]
Message-ID: <20131120061830.GA16081@mtj.dyndns.org> (raw)
In-Reply-To: <1384866598-19716-1-git-send-email-mika.westerberg@linux.intel.com>
(cc'ing Bjorn)
Hello,
On Tue, Nov 19, 2013 at 03:09:58PM +0200, Mika Westerberg wrote:
> Commit bcdde7e221a8 (sysfs: make __sysfs_remove_dir() recursive) changed
> the behavior so that directory removals will be done recursively. This
> means that the sysfs group might already be removed if its parent directory
> has been removed.
>
> The current code outputs warnings similar to following log snippet when it
> detects that there is no group for the given kobject:
>
> WARNING: CPU: 0 PID: 4 at fs/sysfs/group.c:214 sysfs_remove_group+0xc6/0xd0()
> sysfs group ffffffff81c6f1e0 not found for kobject 'host7'
> Modules linked in:
> CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 3.12.0+ #13
> Hardware name: /D33217CK, BIOS GKPPT10H.86A.0042.2013.0422.1439 04/22/2013
> Workqueue: kacpi_hotplug acpi_hotplug_work_fn
> 0000000000000009 ffff8801002459b0 ffffffff817daab1 ffff8801002459f8
> ffff8801002459e8 ffffffff810436b8 0000000000000000 ffffffff81c6f1e0
> ffff88006d440358 ffff88006d440188 ffff88006e8b4c28 ffff880100245a48
> Call Trace:
> [<ffffffff817daab1>] dump_stack+0x45/0x56
> [<ffffffff810436b8>] warn_slowpath_common+0x78/0xa0
> [<ffffffff81043727>] warn_slowpath_fmt+0x47/0x50
> [<ffffffff811ae526>] sysfs_remove_group+0xc6/0xd0
> [<ffffffff81432f7e>] dpm_sysfs_remove+0x3e/0x50
> [<ffffffff8142a0d0>] device_del+0x40/0x1b0
> [<ffffffff8142a24d>] device_unregister+0xd/0x20
> [<ffffffff8144131a>] scsi_remove_host+0xba/0x110
> [<ffffffff8145f526>] ata_host_detach+0xc6/0x100
> [<ffffffff8145f578>] ata_pci_remove_one+0x18/0x20
> [<ffffffff812e8f48>] pci_device_remove+0x28/0x60
> [<ffffffff8142d854>] __device_release_driver+0x64/0xd0
> [<ffffffff8142d8de>] device_release_driver+0x1e/0x30
> [<ffffffff8142d257>] bus_remove_device+0xf7/0x140
> [<ffffffff8142a1b1>] device_del+0x121/0x1b0
> [<ffffffff812e43d4>] pci_stop_bus_device+0x94/0xa0
> [<ffffffff812e437b>] pci_stop_bus_device+0x3b/0xa0
> [<ffffffff812e437b>] pci_stop_bus_device+0x3b/0xa0
> [<ffffffff812e44dd>] pci_stop_and_remove_bus_device+0xd/0x20
> [<ffffffff812fc743>] trim_stale_devices+0x73/0xe0
> [<ffffffff812fc78b>] trim_stale_devices+0xbb/0xe0
> [<ffffffff812fc78b>] trim_stale_devices+0xbb/0xe0
> [<ffffffff812fcb6e>] acpiphp_check_bridge+0x7e/0xd0
> [<ffffffff812fd90d>] hotplug_event+0xcd/0x160
> [<ffffffff812fd9c5>] hotplug_event_work+0x25/0x60
> [<ffffffff81316749>] acpi_hotplug_work_fn+0x17/0x22
> [<ffffffff8105cf3a>] process_one_work+0x17a/0x430
> [<ffffffff8105db29>] worker_thread+0x119/0x390
> [<ffffffff81063a5d>] kthread+0xcd/0xf0
> [<ffffffff817eb33c>] ret_from_fork+0x7c/0xb0
So, we do have cases where the parent is removed before the child. I
suppose the parent pci bridge is removed already? AFAICS this
shouldn't break anything but people did seem to expect the removals to
be ordered from child to parent. Bjorn, is this something you expect
to happened?
> I'm not 100% sure that this is the correct solution. It seem to fix my case
> but I might be missing something as I'm not that familiar with sysfs.
Yeah, looks okay to me for now. One nit at the end tho.
I find requiring removal of each sysfs attribute when the whole node
is going away rather weird. It forced us to have extra code which
does whole bunch of hash table lookups and deletion operations and the
only thing that achieved was either triggering warning if somebody did
it in the wrong order or spuriously, or leaking memory if somebody
forgot some without any way to find out about them.
Now, all those are harmlessly unnecessary and we're adding more logic
to suppress warnings on specific cases. In the longer term, we
probably just wanna drop all the unnecessary removal logics and
warnings.
> + /*
> + * Sysfs directories are now removed recursively by
> + * sysfs_remove_dir(). This means that this function can be called
> + * multiple times on the same group. If the parent directory is
> + * already removed we don't do anything here.
> + */
The function won't be called multiple times but may be called on a
group whose kobj whose sysfs entry is already removed in which case
all its groups are guaranteed to be already removed.
Can you please update the comment to reflect the above?
With that,
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
next prev parent reply other threads:[~2013-11-20 6:18 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-19 13:09 Mika Westerberg
2013-11-19 13:28 ` Rafael J. Wysocki
2013-11-20 6:18 ` Tejun Heo [this message]
2013-11-20 9:56 ` [PATCH v2] " Mika Westerberg
2013-11-22 15:43 ` [PATCH] " Bjorn Helgaas
2013-11-22 16:02 ` Tejun Heo
2013-11-25 10:29 ` James Bottomley
2013-11-25 12:43 ` Rafael J. Wysocki
2013-11-22 22:43 ` Rafael J. Wysocki
2013-11-23 22:56 ` Rafael J. Wysocki
2013-11-23 22:53 ` Greg Kroah-Hartman
2013-11-23 23:12 ` Rafael J. Wysocki
2013-11-23 23:07 ` Greg Kroah-Hartman
2013-11-23 23:36 ` Rafael J. Wysocki
2013-11-24 1:09 ` Rafael J. Wysocki
2013-11-24 15:05 ` Tejun Heo
2013-11-25 10:11 ` Mika Westerberg
2013-11-25 10:41 ` Rafael J. Wysocki
2013-11-25 23:51 ` Gwendal Grignou
2013-11-25 12:19 ` [PATCH] ATA: Fix port removal ordering Rafael J. Wysocki
2013-11-27 1:58 ` Rafael J. Wysocki
2013-11-27 4:34 ` Jingoo Han
2013-11-27 18:56 ` Tejun Heo
2013-11-24 0:17 ` [PATCH] PCI: Move device_del() from pci_stop_dev() to pci_destroy_dev() Rafael J. Wysocki
2013-11-25 4:54 ` Yinghai Lu
2013-11-25 4:58 ` Yinghai Lu
2013-11-25 11:23 ` Rafael J. Wysocki
2013-11-25 19:48 ` Yinghai Lu
2013-11-25 11:22 ` Rafael J. Wysocki
2013-11-25 19:45 ` Yinghai Lu
2013-11-25 20:57 ` Rafael J. Wysocki
2013-11-25 9:47 ` Mika Westerberg
2013-11-25 11:24 ` Rafael J. Wysocki
2013-11-25 21:59 ` Bjorn Helgaas
2013-11-25 22:19 ` Rafael J. Wysocki
2013-11-28 0:41 ` Jingoo Han
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=20131120061830.GA16081@mtj.dyndns.org \
--to=tj@kernel.org \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®