From: Alan Stern <stern@rowland.harvard.edu>
To: Ming Lei <ming.lei@canonical.com>
Cc: linux-kernel@vger.kernel.org, Oliver Neukum <oneukum@suse.de>,
Minchan Kim <minchan@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>, Jens Axboe <axboe@kernel.dk>,
"David S. Miller" <davem@davemloft.net>,
Andrew Morton <akpm@linux-foundation.org>,
netdev@vger.kernel.org, linux-usb@vger.kernel.org,
linux-pm@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH v2 2/6] PM / Runtime: introduce pm_runtime_set_memalloc_noio()
Date: Tue, 23 Oct 2012 14:16:21 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.44L0.1210231402040.1635-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <CACVXFVN+=XH_f5BmRkXeagTNowz0o0-Pd7GcxCneO0FSq8xqEw@mail.gmail.com>
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.
Agreed.
> Got it, thanks for your detailed explanation.
>
> 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/
Linus made it clear (in various emails at the time) that the kernel
requires the compiler not to do the sort of things discussed in that
article. But even the restrictions he wanted would not prevent
adjacent bitfields from interfering with each other.
Alan Stern
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-10-23 18:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 8:33 [RFC PATCH v2 0/6] solve deadlock caused by memory allocation with I/O Ming Lei
2012-10-22 8:33 ` [RFC PATCH v2 1/6] mm: teach mm by current context info to not do I/O during memory allocation Ming Lei
2012-10-22 8:33 ` [RFC PATCH v2 2/6] PM / Runtime: introduce pm_runtime_set_memalloc_noio() Ming Lei
2012-10-22 14:33 ` Alan Stern
2012-10-23 9:08 ` Ming Lei
2012-10-23 14:46 ` Alan Stern
2012-10-23 15:18 ` Ming Lei
2012-10-23 18:16 ` Alan Stern [this message]
2012-10-24 9:06 ` David Laight
2012-10-24 12:26 ` Alan Cox
2012-10-22 8:33 ` [RFC PATCH v2 3/6] block/genhd.c: apply pm_runtime_set_memalloc_noio on block devices Ming Lei
2012-10-22 8:33 ` [RFC PATCH v2 4/6] net/core: apply pm_runtime_set_memalloc_noio on network devices Ming Lei
2012-10-22 19:18 ` Alan Stern
2012-10-23 8:42 ` Ming Lei
2012-10-22 8:33 ` [RFC PATCH v2 5/6] PM / Runtime: force memory allocation with no I/O during runtime_resume callbcack Ming Lei
2012-10-22 8:33 ` [RFC PATCH v2 6/6] USB: forbid memory allocation with I/O during bus reset Ming Lei
2012-10-22 14:37 ` Alan Stern
2012-10-23 8:44 ` Ming Lei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.44L0.1210231402040.1635-100000@iolanthe.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=minchan@kernel.org \
--cc=ming.lei@canonical.com \
--cc=netdev@vger.kernel.org \
--cc=oneukum@suse.de \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox