linux-kernel - Sysfs and suicidal attributes

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.0707081015430.5323-100000@netrider.rowland.org>
Date:	Sun, 8 Jul 2007 10:31:21 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Tejun Heo <htejun@...il.com>
cc:	Cornelia Huck <cornelia.huck@...ibm.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Sysfs and suicidal attributes

Tejun:

You remember the problem we faced with "suicidal" sysfs attributes and 
the device_schedule_callback() routine that fixes it?

Well, it turns out that this approach may confict with suspend/resume
processing.  In brief, it's not a good idea to unregister devices while
a suspend is in progress, but on the other hand it's not a good idea to
block keventd waiting until the suspend is over.

There are some ways around this such as using a different workqueue, 
one that could safely be blocked during the suspend.  But I had another 
thought.

I haven't paid much attention to your sysfs updates.  Is it still true
that calls to show/store methods are mutually exclusive with attribute
unregistration?  Assuming the answer is Yes, would it be possible to
bypass that mutual exclusion in certain explicit cases?  Here's what I
have in mind:

	The user writes to an attribute file.

	The sysfs core calls the attribute's store method.

	The method tells the sysfs core to pretend that the call
	temporarily doesn't exist, or has completed, or something
	like that.

	The method safely unregisters the attribute file, with no
	mutual exclusion problems and no deadlock.  Of course, the
	unregistration will still block until all _other_ method
	calls for this attribute are complete.

	The method tells the sysfs core to stop pretending and
	go back to its normal state.

	The method returns, and the sysfs core takes whatever actions
	are needed to fully release the attribute file.

The idea is that there could be a way to allow unregistration while a 
method is still running, if the method specifically requests it.  If we 
could do this then device_schedule_callback() would be unnecessary.

What do you think?

Alan Stern

-
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/