linux-kernel - Re: [RFC][PATCH 2/2] Convert several sysdev users to using struct syscore

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]

Message-ID: <20110311203305.GA21045@suse.de>
Date:	Fri, 11 Mar 2011 12:33:05 -0800
From:	Greg KH <gregkh@...e.de>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	LKML <linux-kernel@...r.kernel.org>, Len Brown <lenb@...nel.org>,
	Kay Sievers <kay.sievers@...e.de>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Linux PM mailing list <linux-pm@...ts.linux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, mingo@...hat.com,
	tglx@...utronix.de
Subject: Re: [RFC][PATCH 2/2] Convert several sysdev users to using struct
 syscore_ops

On Fri, Mar 11, 2011 at 09:29:24PM +0100, Rafael J. Wysocki wrote:
> I thought about two different possible ways forward:
> 
> (1) Push [1/2] and the patches converting things that x86 depends on first,
>     followed perhaps by a patch introducing something like
>     CONFIG_ARCH_NO_SYSDEV_OPS that would simply disable
>     sysdev_{suspend|resume|shutdown}() (x86 would set it).  The other arches
>     might then be converted over time.
> 
> (2) Prepare patches converting everything that can be converted in the tree
>     and push them all in one shot.
> 
> The advantage of (1) is that we can start making changes RSN and the
> advantage of (2) seems to be that we may avoid some potential suspend/resume
> ordering issues on non-x86 architectures that may arise in principle if some
> subsystems are converted to using struct syscore_ops while the others are
> not (syscore_suspend() is executed after sysdev_suspend(), so if we move
> something from the latter to the former, it may end up being executed after
> things that it was executed before previously).
> 
> Please let me know what your opinion is.

Hm, I would prefer (1) as that lets us get this moving sooner, and "flag
days" are never good to have.  If there are problems that arise because
of it, as you have noted, it will be simple just to convert the parts
that were using the "old" methods to the new ones to fix the issue,
right?

thanks,

greg k-h
--
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/