On Wed, 24 Oct 2012 10:06:36 +0100
"David Laight" wrote:
> > Looks the problem is worse than above, not only bitfields are affected, the
> > adjacent fields might be involved too, see:
> >
> >http://lwn.net/Articles/478657/
>
> Not mentioned in there is that even with x86/amd64 give
> Looks the problem is worse than above, not only bitfields are affected, the
> adjacent fields might be involved too, see:
>
>http://lwn.net/Articles/478657/
Not mentioned in there is that even with x86/amd64 given
a struct with the following adjacent fields:
char a;
On Tue, 23 Oct 2012, Ming Lei wrote:
> With the problem of non-SMP-safe bitfields access, the power.lock should
> be held, but that is not enough to prevent children from being probed or
> disconnected. Looks another lock is still needed. I think a global lock
> is OK in the infrequent path.
Agre
On Tue, Oct 23, 2012 at 10:46 PM, Alan Stern wrote:
> On Tue, 23 Oct 2012, Ming Lei wrote:
>
>> On Mon, Oct 22, 2012 at 10:33 PM, Alan Stern
>> wrote:
>> >
>> > Tail recursion should be implemented as a loop, not as an explicit
>> > recursion. That is, the function should be:
>> >
>> > void pm_
On Tue, 23 Oct 2012, Ming Lei wrote:
> On Mon, Oct 22, 2012 at 10:33 PM, Alan Stern
> wrote:
> >
> > Tail recursion should be implemented as a loop, not as an explicit
> > recursion. That is, the function should be:
> >
> > void pm_runtime_set_memalloc_noio(struct device *dev, bool enable)
> >
On Mon, Oct 22, 2012 at 10:33 PM, Alan Stern wrote:
>
> Tail recursion should be implemented as a loop, not as an explicit
> recursion. That is, the function should be:
>
> void pm_runtime_set_memalloc_noio(struct device *dev, bool enable)
> {
> do {
> dev->power.memalloc_
On Mon, 22 Oct 2012, Ming Lei wrote:
> +void pm_runtime_set_memalloc_noio(struct device *dev, bool enable)
> +{
> + dev->power.memalloc_noio_resume = enable;
> +
> + if (!dev->parent)
> + return;
> +
> + if (enable) {
> + pm_runtime_set_memalloc_noio(dev->parent
7 matches
Mail list logo
