linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 9 Jul 2007 17:26:23 +0200
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Tejun Heo <htejun@...il.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Sysfs and suicidal attributes

On Sun, 8 Jul 2007 10:31:21 -0400 (EDT),
Alan Stern <stern@...land.harvard.edu> wrote:

> There are some ways around this such as using a different workqueue, 
> one that could safely be blocked during the suspend.

This would be the simplest solution, I think.

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

Or add an ignore-for-now-flag to the buffer? It would need to be
processed in a second pass.

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

It would need to retain a reference to the buffer collection so it can
get rid of the formerly-ignored buffer.

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

I don't think that this is easy to get correct. Another workqueue looks
like a solution which is easy to get right, even if it may not seem so
nice.
-
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/