| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1243178448.4035.12.camel@poy> Date: Sun, 24 May 2009 17:20:48 +0200 From: Kay Sievers <kay.sievers@...y.org> To: "Eric W. Biederman" <ebiederm@...ssion.com> Cc: Andrew Morton <akpm@...ux-foundation.org>, Greg Kroah-Hartman <gregkh@...e.de>, linux-kernel@...r.kernel.org, Tejun Heo <tj@...nel.org>, Cornelia Huck <cornelia.huck@...ibm.com>, linux-fsdevel@...r.kernel.org, "Eric W. Biederman" <ebiederm@...stanetworks.com>, stern <stern@...land.harvard.edu> Subject: Re: [PATCH 25/20] sysfs: Only support removing emtpy sysfs directories. On Sun, 2009-05-24 at 07:17 -0700, Eric W. Biederman wrote: > Most of these look like attributes, for which the non-empty directory > removal was correct. Although I am puzzled by why we missed them. Yes, most of them are attributes. I have USB hubs here with lots of devices connected, setups I use for udev testing, so this might trigger things that usually don't happen. > host4/target4:0:0 worries me. I don't have my head wrapped around > what that is yet. But is looks like is a directory (which we currently > do not handle correctly), and even more it looks like that is quite > possibly two kobjects in a parent/child situation where the child > was not removed when the child was. > > It definitely warrants more investigation. It seems like a real bug. We get: dir: host5/target5:0:0 and we removed a parent from an active child, and the device path misses all its parents: 'target7:0:0' (ffff880124eb1158): fill_kobj_path: path = '/host7/target7:0:0' it gets cleaned up: 'target7:0:0': free name but it should still be fixed in the user. Adding Alan Stern, maybe he has an idea what's going on here. Note, that it is hard to reproduce, It only happens with a frequent connect/disconnects on a hub full of devices. But it still seems like a real bug in the USB device cleanup logic. At the end of this mail is the log of all files which did exist at cleanup. > Let's make the plan to investigate these, and see how hard it would be > to actually remove these with the current device/sysfs infrastructure. > > Fixing the users and adding back auto-deletion are the only two real options. Seems, we should remove non-directory files, which in most cases belong to the kobject itself, but the user's cleanup logic does not cover the removal of the created files. But I think, we should still warn, if we find a sub-directory inside a directory we are going to remove. Thanks, Kay attr: state0/name attr: state0/desc attr: state0/latency attr: state0/power attr: state0/usage attr: state0/time attr: state1/name attr: state1/desc attr: state1/latency attr: state1/power attr: state1/usage attr: state1/time attr: state2/name attr: state2/desc attr: state2/latency attr: state2/power attr: state2/usage attr: state2/time attr: state3/name attr: state3/desc attr: state3/latency attr: state3/power attr: state3/usage attr: state3/time attr: state0/name attr: state0/desc attr: state0/latency attr: state0/power attr: state0/usage attr: state0/time attr: state1/name attr: state1/desc attr: state1/latency attr: state1/power attr: state1/usage attr: state1/time attr: state2/name attr: state2/desc attr: state2/latency attr: state2/power attr: state2/usage attr: state2/time attr: state3/name attr: state3/desc attr: state3/latency attr: state3/power attr: state3/usage attr: state3/time battr: 0000:03:00.0/data attr: 0000:03:00.0/loading attr: pcmC1D0c/pcm_class attr: card1/id attr: card1/number attr: iosched/quantum attr: iosched/fifo_expire_sync attr: iosched/fifo_expire_async attr: iosched/back_seek_max attr: iosched/back_seek_penalty attr: iosched/slice_sync attr: iosched/slice_async attr: iosched/slice_async_rq attr: iosched/slice_idle attr: queue/nr_requests attr: queue/read_ahead_kb attr: queue/max_hw_sectors_kb attr: queue/max_sectors_kb attr: queue/scheduler attr: queue/hw_sector_size attr: queue/rotational attr: queue/nomerges attr: queue/rq_affinity attr: queue/iostats attr: 5:0:0:0/queue_depth attr: 5:0:0:0/queue_type attr: 5:0:0:0/max_sectors attr: iosched/quantum attr: iosched/fifo_expire_sync attr: iosched/fifo_expire_async attr: iosched/back_seek_max attr: iosched/back_seek_penalty attr: iosched/slice_sync attr: iosched/slice_async attr: iosched/slice_async_rq attr: iosched/slice_idle attr: queue/nr_requests attr: queue/read_ahead_kb attr: queue/max_hw_sectors_kb attr: queue/max_sectors_kb attr: queue/scheduler attr: queue/hw_sector_size attr: queue/rotational attr: queue/nomerges attr: queue/rq_affinity attr: queue/iostats attr: 5:0:0:1/queue_depth attr: 5:0:0:1/queue_type attr: 5:0:0:1/max_sectors dir: host5/target5:0:0 attr: pcmC1D0c/pcm_class attr: card1/id attr: card1/number attr: pcmC1D0c/pcm_class attr: card1/id attr: card1/number attr: iosched/quantum attr: iosched/fifo_expire_sync attr: iosched/fifo_expire_async attr: iosched/back_seek_max attr: iosched/back_seek_penalty attr: iosched/slice_sync attr: iosched/slice_async attr: iosched/slice_async_rq attr: iosched/slice_idle attr: queue/nr_requests attr: queue/read_ahead_kb attr: queue/max_hw_sectors_kb attr: queue/max_sectors_kb attr: queue/scheduler attr: queue/hw_sector_size attr: queue/rotational attr: queue/nomerges attr: queue/rq_affinity attr: queue/iostats attr: 6:0:0:0/queue_depth attr: 6:0:0:0/queue_type attr: 6:0:0:0/max_sectors attr: iosched/quantum attr: iosched/fifo_expire_sync attr: iosched/fifo_expire_async attr: iosched/back_seek_max attr: iosched/back_seek_penalty attr: iosched/slice_sync attr: iosched/slice_async attr: iosched/slice_async_rq attr: iosched/slice_idle attr: queue/nr_requests attr: queue/read_ahead_kb attr: queue/max_hw_sectors_kb attr: queue/max_sectors_kb attr: queue/scheduler attr: queue/hw_sector_size attr: queue/rotational attr: queue/nomerges attr: queue/rq_affinity attr: queue/iostats attr: 6:0:0:1/queue_depth attr: 6:0:0:1/queue_type attr: 6:0:0:1/max_sectors attr: pcmC1D0c/pcm_class attr: card1/id attr: card1/number attr: pcmC1D0c/pcm_class attr: card1/id attr: card1/number -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists