* Re: Odd hang on suspend and shutdown
From: Linus Torvalds @ 2015-07-06 17:29 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: Tomas Winkler, Greg Kroah-Hartman, Linux API
In-Reply-To: <20150706165959.GB22015-nKCvNrh56OoJmsy6czSMtA@public.gmane.org>
On Mon, Jul 6, 2015 at 9:59 AM, Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>
> Ok, if you can suspend after this modprobe we're looking at some
> potential mei bus or mei core issues.
Just looking at the mei/bus.c code to match the driver, and it looks just odd.
Before the commit that breaks for me, it used to have this loop:
- while (id->name[0]) {
and now it has
+ while (uuid_le_cmp(NULL_UUID_LE, uuid_le_cast(id->uuid))) {
which seems to mean that together with my change to make a working
kernel (just removing the UUID entirely) means that now the
device_driver isn't matched against anything at all any more.
So I'm not sure "modprobe pn544_mei" ends up actually triggering
anything at all with my change to make it not lock up for me.
Linus
^ permalink raw reply
* RE: Odd hang on suspend and shutdown
From: Winkler, Tomas @ 2015-07-06 18:59 UTC (permalink / raw)
To: Linus Torvalds, Samuel Ortiz; +Cc: Greg Kroah-Hartman, Linux API
In-Reply-To: <CA+55aFxfENpyWSDxgaQhB1mBHE6zs=w=Mc0VEQLgdwSaCMX5eQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> >
> > I suppose you were not seeing this issue on e.g. a 4.1 kernel (assuming
> > this is not a brand new laptop) ?
>
> Nope, 4.1 is fine. This is my travel laptop for the last almost two
> years. Best laptop I've ever had (I like them small and light).
If this two years old that's probably not HSW, can you send out the exact HW info, mostly pci device ids are in interest.
>
> > If that's the case, is any of the pn544* kernel modules loaded when
> > running on top of a good kernel ?
>
> So it doesn't show up in lsmod, but presumably the module got loaded
> and then errored out or something. The mei and mei_me modules are
> loaded, nut no pn544_mei.
This should be loaded only if you have NFC on the board or it bailed out more cleanly before.
There is a file under debugfs mei0/meclients , if you can send out the dump we can see what we support on that platform.
>
> I'm not even sure why it's in my configuration, because I tend to try
> to keep those small, and my config was generated (long ago) with "make
> localmodconfig", but maybe there's something non-obvious that brought
> it in. Presumably that pn544 module was loaded at _some_ point in the
> past.
>
Frankly, if you are not using any of the pro or NFC you don't really need that loaded.
> I just tested, and loading it manually with "modprobe pn544_mei"
> doesn't seem to do anything bad. I can still suspend with a good
> kernel. So it's not just about loading the module, there's some other
> interaction going on.
The question if the module get bound to the NFC me client?
Thanks
Tomas
^ permalink raw reply
* RE: Odd hang on suspend and shutdown
From: Winkler, Tomas @ 2015-07-06 19:18 UTC (permalink / raw)
To: Linus Torvalds, Samuel Ortiz; +Cc: Greg Kroah-Hartman, Linux API
In-Reply-To: <CA+55aFwM8c3Zm0t0cEnbGS0d0rinzGwnX9uSxqKjff8K=ATaRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> On Mon, Jul 6, 2015 at 9:59 AM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> >
> > Ok, if you can suspend after this modprobe we're looking at some
> > potential mei bus or mei core issues.
>
> Just looking at the mei/bus.c code to match the driver, and it looks just odd.
The major part of the bus was rejected by Greg and I'm still waiting for him to like be me back and review the resend.
>
> Before the commit that breaks for me, it used to have this loop:
>
> - while (id->name[0]) {
>
> and now it has
>
> + while (uuid_le_cmp(NULL_UUID_LE, uuid_le_cast(id->uuid))) {
The is the major change in bus, instead of inventing names for each device
we do PnP by matching to UUIDs which are fetched from the parent mei device at initialization.
Looks like there is some conflict between UUID and the driver (pn544) that binds to it and probably didn't before.
I'll be smarter when we have the HW info.
>
> which seems to mean that together with my change to make a working
> kernel (just removing the UUID entirely) means that now the
> device_driver isn't matched against anything at all any more.
>
> So I'm not sure "modprobe pn544_mei" ends up actually triggering
> anything at all with my change to make it not lock up for me.
If you removed the UUID it would just be loaded, I guess
Thanks
Tomas
^ permalink raw reply
* Re: Odd hang on suspend and shutdown
From: Linus Torvalds @ 2015-07-06 19:40 UTC (permalink / raw)
To: Winkler, Tomas; +Cc: Samuel Ortiz, Greg Kroah-Hartman, Linux API
In-Reply-To: <5B8DA87D05A7694D9FA63FD143655C1B3D3E3474-Jy8z56yoSI8MvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Mon, Jul 6, 2015 at 11:59 AM, Winkler, Tomas <tomas.winkler-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>>
>> Nope, 4.1 is fine. This is my travel laptop for the last almost two
>> years. Best laptop I've ever had (I like them small and light).
>
> If this two years old that's probably not HSW, can you send out the exact HW info, mostly pci device ids are in interest.
Oh, it's Haswell. It's a i5-4200u. And no, it's not quite two years
old, but it's from fall-2013.
And it's literally all Intel (series 8 mobile chipset) with a intel
7260 wireless. A whole lot of 8086 there:
[torvalds@vaio ~]$ lspci -n
00:00.0 0600: 8086:0a04 (rev 09)
00:02.0 0300: 8086:0a16 (rev 09)
00:03.0 0403: 8086:0a0c (rev 09)
00:14.0 0c03: 8086:9c31 (rev 04)
00:16.0 0780: 8086:9c3a (rev 04)
00:1b.0 0403: 8086:9c20 (rev 04)
00:1c.0 0604: 8086:9c14 (rev e4)
00:1c.3 0604: 8086:9c16 (rev e4)
00:1d.0 0c03: 8086:9c26 (rev 04)
00:1f.0 0601: 8086:9c43 (rev 04)
00:1f.2 0106: 8086:9c03 (rev 04)
00:1f.3 0c05: 8086:9c22 (rev 04)
01:00.0 0280: 8086:08b1 (rev 6b)
> This should be loaded only if you have NFC on the board or it bailed out more cleanly before.
> There is a file under debugfs mei0/meclients , if you can send out the dump we can see what
> we support on that platform.
[torvalds@vaio ~]$ sudo cat /sys/kernel/debug/mei0/meclients
|id|fix| UUID |con|msg len|sb|refc|
0|42| 0|b638ab7e-94e2-4ea2-a552-d1c54b627f04| 1| 2048| 0| 2|
1|41| 0|fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1| 3| 15360| 0| 2|
2|40| 0|3c4852d6-d47b-4f46-b05e-b5edc1aa440e| 1| 4096| 0| 2|
3|39| 0|0bb17a78-2a8e-4c50-94d4-50266723775c| 1| 312| 0| 4|
4|38| 0|d2de1625-382d-417d-48a4-efabba8a1206| 5| 312| 0| 2|
5|37| 0|3c4852d6-d47b-4f46-b05e-b5edc1aa430a| 1| 4096| 0| 2|
6|36| 0|f908627d-13bf-4a04-b91f-a64e9245323d| 1| 12388| 0| 2|
7|35| 0|8c2f4425-77d6-4755-aca3-891fdbc66a58| 1| 1328| 0| 2|
8|34| 0|3893448c-eab6-4f4c-b23c-57c2c4658dfc| 2| 64| 0| 2|
9|33| 0|309dcde8-ccb1-4062-8f78-600115a34327| 1| 512| 0| 2|
10|32| 0|8e6a6715-9abc-4043-88ef-9e39c6f63e0f| 2| 2048| 0| 2|
11| 8| 1|bf3cb4da-4045-4f9b-838d-8cbcfb21a107| 0| 1328| 1| 2|
12| 7| 1|55213584-9a29-4916-badf-0fb7ed682aeb| 0| 2048| 1| 2|
13| 5| 1|fa8f55e8-ab22-42dd-b916-7dce39002574| 1| 4096| 1| 2|
> Frankly, if you are not using any of the pro or NFC you don't really need that loaded.
Yeah. Except I will not be releasing a kernel that I can tell is buggy
on my own hardware, so it really doesn't matter.
So that commit gets reverted unless somebody figures out what's wrong.
If *I* see problems from my very limited hardware testing, I guarantee
that others will see them too. And others will not be able to
necessarily bisect and test things, they'll just say "it hangs" and
maybe never try Linux any more than that.
So bugs I can see myself end up being stuff that I revert pretty much
immediately. I don't run odd hardware.
> The question if the module get bound to the NFC me client?
.. and how would that show up?
Linus
^ permalink raw reply
* Re: [GIT PULL] User namespace related fixes for v4.2
From: Seth Forshee @ 2015-07-06 20:47 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, Linux Containers, linux-fsdevel, Linux API,
Andy Lutomirski, Serge E. Hallyn, Richard Weinberger,
Kenton Varda, Michael Kerrisk-manpages, Stéphane Graber,
Eric Windisch, Greg Kroah-Hartman, Tejun Heo, Omar Sandoval,
Ivan Delalande
In-Reply-To: <878uazhapq.fsf@x220.int.ebiederm.org>
On Wed, Jul 01, 2015 at 03:41:37PM -0500, Eric W. Biederman wrote:
> This set of changes also starts enforcing the mount flags of fresh
> mounts of proc and sysfs are consistent with the existing mount of proc
> and sysfs. I expected this to be the boring part of the work but
> unfortunately unprivileged userspace winds up mounting fresh copies of
> proc and sysfs with noexec and nosuid clear when root set those flags on
> the previous mount of proc and sysfs. So for now only the atime,
> read-only and nodev attributes which userspace happens to keep
> consistent are enforced. Dealing with the noexec and nosuid attributes
> remains for another time.
Sorry to be the bearer of bad news, but I am seeing a regression in lxc
with 4.2-rc1 due to this change. lxc is doing a fresh mount of sysfs
that never specifies either read-only or nodev regardless of how sysfs
has been mounted previously, and this is causing me to see mount
failures because of the nodev check.
If I comment out only the nodev check then the mount works on my system,
but based on the code in lxc I don't think there's any guarantee at all
of this mount having flags consistent with previous mounts.
Seth
^ permalink raw reply
* RE: Odd hang on suspend and shutdown
From: Winkler, Tomas @ 2015-07-06 21:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Samuel Ortiz, Greg Kroah-Hartman, Linux API
In-Reply-To: <CA+55aFxjuufbJpn+MngBzO3QyaYQm_ZNsgQY3VqPpguVpzOk6A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> >> Nope, 4.1 is fine. This is my travel laptop for the last almost two
> >> years. Best laptop I've ever had (I like them small and light).
> >
> > If this two years old that's probably not HSW, can you send out the exact HW
> info, mostly pci device ids are in interest.
>
> Oh, it's Haswell. It's a i5-4200u. And no, it's not quite two years
> old, but it's from fall-2013.
Okay have similar machine, will dig into it tomorrow morning
>
> And it's literally all Intel (series 8 mobile chipset) with a intel
> 7260 wireless. A whole lot of 8086 there:
>
> [torvalds@vaio ~]$ lspci -n
> 00:00.0 0600: 8086:0a04 (rev 09)
> 00:02.0 0300: 8086:0a16 (rev 09)
> 00:03.0 0403: 8086:0a0c (rev 09)
> 00:14.0 0c03: 8086:9c31 (rev 04)
> 00:16.0 0780: 8086:9c3a (rev 04)
> 00:1b.0 0403: 8086:9c20 (rev 04)
> 00:1c.0 0604: 8086:9c14 (rev e4)
> 00:1c.3 0604: 8086:9c16 (rev e4)
> 00:1d.0 0c03: 8086:9c26 (rev 04)
> 00:1f.0 0601: 8086:9c43 (rev 04)
> 00:1f.2 0106: 8086:9c03 (rev 04)
> 00:1f.3 0c05: 8086:9c22 (rev 04)
> 01:00.0 0280: 8086:08b1 (rev 6b)
>
> > This should be loaded only if you have NFC on the board or it bailed out more
> cleanly before.
> > There is a file under debugfs mei0/meclients , if you can send out the dump we
> can see what
> > we support on that platform.
>
> [torvalds@vaio ~]$ sudo cat /sys/kernel/debug/mei0/meclients
> |id|fix| UUID |con|msg len|sb|refc|
> 0|42| 0|b638ab7e-94e2-4ea2-a552-d1c54b627f04| 1| 2048| 0| 2|
> 1|41| 0|fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1| 3| 15360| 0| 2|
> 2|40| 0|3c4852d6-d47b-4f46-b05e-b5edc1aa440e| 1| 4096| 0| 2|
> 3|39| 0|0bb17a78-2a8e-4c50-94d4-50266723775c| 1| 312| 0| 4|
The above is NFC.
>
> > Frankly, if you are not using any of the pro or NFC you don't really need that
> loaded.
>
> Yeah. Except I will not be releasing a kernel that I can tell is buggy
> on my own hardware, so it really doesn't matter.
> So that commit gets reverted unless somebody figures out what's wrong.
Oh no, there wasn't any intention to left it unaddressed, I hope very much someone is actually using it.
>
> If *I* see problems from my very limited hardware testing, I guarantee
> that others will see them too. And others will not be able to
> necessarily bisect and test things, they'll just say "it hangs" and
> maybe never try Linux any more than that.
>
> So bugs I can see myself end up being stuff that I revert pretty much
> immediately. I don't run odd hardware.
I hope we found the issue quickly now, the quick fix would be to enable the NFC only on ivy bridge.
>
> > The question if the module get bound to the NFC me client?
>
> .. and how would that show up?
>
I think w/o installing the whole neard stack it would be just watching udev events or open the dynamic debug in the kernel on mei_phy and pn544 modules.
What I know for sure is that NFC in current stage is just not functional on HSW so it should bail out at some point, of course it should not cause the regression either. It should be working on ivy bridge.
Tomas
^ permalink raw reply
* Re: [GIT PULL] User namespace related fixes for v4.2
From: Eric W. Biederman @ 2015-07-06 21:24 UTC (permalink / raw)
To: Seth Forshee
Cc: Linus Torvalds, Linux Containers, linux-fsdevel, Linux API,
Andy Lutomirski, Serge E. Hallyn, Richard Weinberger,
Kenton Varda, Michael Kerrisk-manpages, Stéphane Graber,
Eric Windisch, Greg Kroah-Hartman, Tejun Heo, Omar Sandoval,
Ivan Delalande
In-Reply-To: <20150706204748.GB22962@ubuntu-hedt>
On July 6, 2015 3:47:48 PM CDT, Seth Forshee <seth.forshee@canonical.com> wrote:
>On Wed, Jul 01, 2015 at 03:41:37PM -0500, Eric W. Biederman wrote:
>> This set of changes also starts enforcing the mount flags of fresh
>> mounts of proc and sysfs are consistent with the existing mount of
>proc
>> and sysfs. I expected this to be the boring part of the work but
>> unfortunately unprivileged userspace winds up mounting fresh copies
>of
>> proc and sysfs with noexec and nosuid clear when root set those flags
>on
>> the previous mount of proc and sysfs. So for now only the atime,
>> read-only and nodev attributes which userspace happens to keep
>> consistent are enforced. Dealing with the noexec and nosuid
>attributes
>> remains for another time.
>
>Sorry to be the bearer of bad news, but I am seeing a regression in lxc
>with 4.2-rc1 due to this change. lxc is doing a fresh mount of sysfs
>that never specifies either read-only or nodev regardless of how sysfs
>has been mounted previously, and this is causing me to see mount
>failures because of the nodev check.
>
>If I comment out only the nodev check then the mount works on my
>system,
>but based on the code in lxc I don't think there's any guarantee at all
>of this mount having flags consistent with previous mounts.
Seth you are testing your inprogress patchset that
modifies how nodev works aren't you?
In rc1 nodev is always forced on a mount in a user namespace.
There is a fairly easy fix to the nodev cleanup in your
patchset, but it takes a few lines of code change in
fs_fully_visible. Essentially after we get the better
nodev enforcement, fs_fully_visible does not need
to bother with nodev.
Eric
^ permalink raw reply
* Re: Odd hang on suspend and shutdown
From: Greg Kroah-Hartman @ 2015-07-06 22:17 UTC (permalink / raw)
To: Winkler, Tomas; +Cc: Linus Torvalds, Samuel Ortiz, Linux API
In-Reply-To: <5B8DA87D05A7694D9FA63FD143655C1B3D3E34A6-Jy8z56yoSI8MvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Mon, Jul 06, 2015 at 07:18:15PM +0000, Winkler, Tomas wrote:
> > On Mon, Jul 6, 2015 at 9:59 AM, Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> > >
> > > Ok, if you can suspend after this modprobe we're looking at some
> > > potential mei bus or mei core issues.
>
> >
> > Just looking at the mei/bus.c code to match the driver, and it looks just odd.
>
> The major part of the bus was rejected by Greg and I'm still waiting
> for him to like be me back and review the resend.
That's 4.3-rc1 work, not for 4.2, so if this is breaking boxes, I'm with
Linus, it should just be reverted for now.
I can't duplicate this here with my laptop, it's a few years old as
well, but no problems, so this must be device specific somehow.
thanks
greg k-h
^ permalink raw reply
* Re: [GIT PULL] User namespace related fixes for v4.2
From: Seth Forshee @ 2015-07-06 22:25 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, Linux Containers,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, Linux API, Andy Lutomirski,
Serge E. Hallyn, Richard Weinberger, Kenton Varda,
Michael Kerrisk-manpages, Stéphane Graber, Eric Windisch,
Greg Kroah-Hartman, Tejun Heo, Omar Sandoval, Ivan Delalande
In-Reply-To: <E81DECCD-9B19-4D42-BE43-5987DE7B05DB-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On Mon, Jul 06, 2015 at 04:24:00PM -0500, Eric W. Biederman wrote:
>
>
> On July 6, 2015 3:47:48 PM CDT, Seth Forshee <seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
> >On Wed, Jul 01, 2015 at 03:41:37PM -0500, Eric W. Biederman wrote:
> >> This set of changes also starts enforcing the mount flags of fresh
> >> mounts of proc and sysfs are consistent with the existing mount of
> >proc
> >> and sysfs. I expected this to be the boring part of the work but
> >> unfortunately unprivileged userspace winds up mounting fresh copies
> >of
> >> proc and sysfs with noexec and nosuid clear when root set those flags
> >on
> >> the previous mount of proc and sysfs. So for now only the atime,
> >> read-only and nodev attributes which userspace happens to keep
> >> consistent are enforced. Dealing with the noexec and nosuid
> >attributes
> >> remains for another time.
> >
> >Sorry to be the bearer of bad news, but I am seeing a regression in lxc
> >with 4.2-rc1 due to this change. lxc is doing a fresh mount of sysfs
> >that never specifies either read-only or nodev regardless of how sysfs
> >has been mounted previously, and this is causing me to see mount
> >failures because of the nodev check.
> >
> >If I comment out only the nodev check then the mount works on my
> >system,
> >but based on the code in lxc I don't think there's any guarantee at all
> >of this mount having flags consistent with previous mounts.
>
> Seth you are testing your inprogress patchset that
> modifies how nodev works aren't you?
>
> In rc1 nodev is always forced on a mount in a user namespace.
>
> There is a fairly easy fix to the nodev cleanup in your
> patchset, but it takes a few lines of code change in
> fs_fully_visible. Essentially after we get the better
> nodev enforcement, fs_fully_visible does not need
> to bother with nodev.
Drat, you're right. I built an unmodified 4.2-rc1 but I apparently I had
booted to the wrong kernel when I thought I was testing it. Without the
extra patches it's fine; sorry for the noise.
Seth
^ permalink raw reply
* Re: Odd hang on suspend and shutdown
From: Samuel Ortiz @ 2015-07-06 22:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tomas Winkler, Greg Kroah-Hartman, Linux API
In-Reply-To: <CA+55aFxfENpyWSDxgaQhB1mBHE6zs=w=Mc0VEQLgdwSaCMX5eQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jul 06, 2015 at 09:49:51AM -0700, Linus Torvalds wrote:
> On Mon, Jul 6, 2015 at 9:07 AM, Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> >
> > I suppose you were not seeing this issue on e.g. a 4.1 kernel (assuming
> > this is not a brand new laptop) ?
>
> Nope, 4.1 is fine. This is my travel laptop for the last almost two
> years. Best laptop I've ever had (I like them small and light).
>
> > If that's the case, is any of the pn544* kernel modules loaded when
> > running on top of a good kernel ?
>
> So it doesn't show up in lsmod, but presumably the module got loaded
> and then errored out or something. The mei and mei_me modules are
> loaded, nut no pn544_mei.
Oh, by 'good kernel' I meant a 4.1 one for example, sorry for the
confusion.
Not one where you removed the UUID from pn544/mei.c because thay will
essentially make sure the driver is never probed.
What I'm trying to rule out is that you never saw that issue on previous
kernels because the pn544 driver was not loaded at all, but this:
> I'm not even sure why it's in my configuration, because I tend to try
> to keep those small, and my config was generated (long ago) with "make
> localmodconfig", but maybe there's something non-obvious that brought
> it in. Presumably that pn544 module was loaded at _some_ point in the
> past.
seems to prove it has already been automatically loaded (and thus probed
because the loading happened as the NFC device was found on the MEI
bus).
The pn544 mei support was added with 3.10 iirc, so starting from there
your pn544* modules have been most likely automatically loaded.
Cheers,
Samuel.
^ permalink raw reply
* Re: Odd hang on suspend and shutdown
From: Samuel Ortiz @ 2015-07-06 22:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Winkler, Tomas, Greg Kroah-Hartman, Linux API
In-Reply-To: <CA+55aFxjuufbJpn+MngBzO3QyaYQm_ZNsgQY3VqPpguVpzOk6A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jul 06, 2015 at 12:40:10PM -0700, Linus Torvalds wrote:
> > The question if the module get bound to the NFC me client?
>
> .. and how would that show up?
If the pn544 probed correctly you will see a /sys/class/nfc/nfc0 entry.
Cheers,
Samuel.
^ permalink raw reply
* Re: Odd hang on suspend and shutdown
From: Samuel Ortiz @ 2015-07-06 22:38 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Winkler, Tomas, Linus Torvalds, Linux API
In-Reply-To: <20150706221736.GA3135-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Mon, Jul 06, 2015 at 03:17:36PM -0700, Greg Kroah-Hartman wrote:
> > The major part of the bus was rejected by Greg and I'm still waiting
> > for him to like be me back and review the resend.
>
> That's 4.3-rc1 work, not for 4.2, so if this is breaking boxes, I'm with
> Linus, it should just be reverted for now.
>
> I can't duplicate this here with my laptop, it's a few years old as
> well, but no problems, so this must be device specific somehow.
It's very much device specific as only few HSW based SKUs have NFC
enabled through the ME.
Cheers,
Samuel.
^ permalink raw reply
* Re: Odd hang on suspend and shutdown
From: Linus Torvalds @ 2015-07-06 23:06 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: Tomas Winkler, Greg Kroah-Hartman, Linux API
In-Reply-To: <20150706223133.GC22015-nKCvNrh56OoJmsy6czSMtA@public.gmane.org>
On Mon, Jul 6, 2015 at 3:31 PM, Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>
> The pn544 mei support was added with 3.10 iirc, so starting from there
> your pn544* modules have been most likely automatically loaded.
I no longer had a 4.1 kernel (with all the bisecting I had pruned away
old kernel builds), but booting into a distro kernel shows that in
4.0.6, the pn544 modules do get loaded, and suspend/resume works fine.
.. and that also explains why I had it enabled in my .config. It would
have been picked up by "make localmodconfig".
> If the pn544 probed correctly you will see a /sys/class/nfc/nfc0 entry.
Yes, that shows up in 4.0.6. It does not show up in my modified
4.2-rc1 kernel that dropped the UUID.
I'll go and test the plain revert case.
Linus
^ permalink raw reply
* Re: Odd hang on suspend and shutdown
From: Linus Torvalds @ 2015-07-07 0:04 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: Tomas Winkler, Greg Kroah-Hartman, Linux API
In-Reply-To: <CA+55aFwsrywW4fEt33BZFPSu5F0eAFB5YAY-zHUZ8-BLv1VcDg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jul 6, 2015 at 4:06 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
> I'll go and test the plain revert case.
So the "plain" revert ended up being more than a single revert, just
because there were multiple changes in that area. But after doing
this:
git revert b144ce2d3761
git revert 1d3ff76721fb
git revert be9b720a0ccb
git revert 007d64eb2232
git revert dbac993f6a6d
git revert d4b78c7290dd
git revert c93b76b34b4d
I have a working kernel that loads the pn544 thing automatically, and
shows it in /sys/class/nfc/, and suspend works.
So I'm back to the pre-merge-window behavior.
I'd be happy to do a more minimal revert, but the above was the
trivial "revert without any conflicts" set.
Linus
^ permalink raw reply
* Re: Odd hang on suspend and shutdown
From: Greg Kroah-Hartman @ 2015-07-07 4:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Samuel Ortiz, Tomas Winkler, Linux API
In-Reply-To: <CA+55aFxo064xa5m3KPjSJxQCrDL3H1QwuEcpCKMg0TL8C0aedQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jul 06, 2015 at 05:04:18PM -0700, Linus Torvalds wrote:
> On Mon, Jul 6, 2015 at 4:06 PM, Linus Torvalds
> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> >
> > I'll go and test the plain revert case.
>
> So the "plain" revert ended up being more than a single revert, just
> because there were multiple changes in that area. But after doing
> this:
>
> git revert b144ce2d3761
> git revert 1d3ff76721fb
> git revert be9b720a0ccb
> git revert 007d64eb2232
> git revert dbac993f6a6d
> git revert d4b78c7290dd
> git revert c93b76b34b4d
>
> I have a working kernel that loads the pn544 thing automatically, and
> shows it in /sys/class/nfc/, and suspend works.
>
> So I'm back to the pre-merge-window behavior.
I have no objection to just reverting all of these to get back to a
working system.
thanks,
greg k-h
^ permalink raw reply
* [RFCv3 0/5] enable migration of driver pages
From: Gioh Kim @ 2015-07-07 4:36 UTC (permalink / raw)
To: jlayton, bfields, vbabka, iamjoonsoo.kim, viro, mst, koct9i,
minchan, aquini, linux-fsdevel, virtualization, linux-kernel,
linux-api, linux-mm
Cc: gunho.lee, akpm, Gioh Kim
From: Gioh Kim <gurugio@hanmail.net>
Hello,
This series try to enable migration of non-LRU pages, such as driver's page.
My ARM-based platform occured severe fragmentation problem after long-term
(several days) test. Sometimes even order-3 page allocation failed. It has
memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing
and 20~30 memory is reserved for zram.
I found that many pages of GPU driver and zram are non-movable pages. So I
reported Minchan Kim, the maintainer of zram, and he made the internal
compaction logic of zram. And I made the internal compaction of GPU driver.
They reduced some fragmentation but they are not enough effective.
They are activated by its own interface, /sys, so they are not cooperative
with kernel compaction. If there is too much fragmentation and kernel starts
to compaction, zram and GPU driver cannot work with the kernel compaction.
This patch set combines 5 patches.
1. patch 1/5: get inode from anon_inodes
This patch adds new interface to create inode from anon_inodes.
2. patch 2/5: framework to isolate/migrate/putback page
Add isolatepage, putbackpage into address_space_operations
and wrapper function to call them
3. patch 3/5: apply the framework into balloon driver
The balloon driver is applied into the framework. It gets a inode
from anon_inodes and register operations in the inode.
Any other drivers can register operations via inode like this
to migrate it's pages.
4. patch 4/5: compaction/migration call the generic interfaces
Compaction and migration pages call the generic interfaces of the framework,
instead of calling balloon migration directly.
5. patch 5/5: remove direct calling of migration of driver pages
Non-lru pages are migrated with lru pages by move_to_new_page().
This patch set is tested:
- turn on Ubuntu 14.04 with 1G memory on qemu.
- do kernel building
- after several seconds check more than 512MB is used with free command
- command "balloon 512" in qemu monitor
- check hundreds MB of pages are migrated
My thanks to Konstantin Khlebnikov for his reviews of the v2 patch set.
Most of the changes were based on his feedback.
Changes since v2:
- change the name of page type from migratable page into mobile page
- get and lock page to isolate page
- add wrapper interfaces for page->mapping->a_ops->isolate/putback
- leave balloon pages marked as balloon
This patch-set is based on v4.1
Gioh Kim (5):
fs/anon_inodes: new interface to create new inode
mm/compaction: enable mobile-page migration
mm/balloon: apply mobile page migratable into balloon
mm/compaction: call generic migration callbacks
mm: remove direct calling of migration
drivers/virtio/virtio_balloon.c | 3 ++
fs/anon_inodes.c | 6 +++
fs/proc/page.c | 3 ++
include/linux/anon_inodes.h | 1 +
include/linux/balloon_compaction.h | 15 +++++--
include/linux/compaction.h | 76 ++++++++++++++++++++++++++++++++++
include/linux/fs.h | 2 +
include/linux/page-flags.h | 19 +++++++++
include/uapi/linux/kernel-page-flags.h | 1 +
mm/balloon_compaction.c | 71 ++++++++++---------------------
mm/compaction.c | 8 ++--
mm/migrate.c | 24 +++--------
12 files changed, 154 insertions(+), 75 deletions(-)
--
2.1.4
--
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>
^ permalink raw reply
* [RFCv3 1/5] fs/anon_inodes: new interface to create new inode
From: Gioh Kim @ 2015-07-07 4:36 UTC (permalink / raw)
To: jlayton, bfields, vbabka, iamjoonsoo.kim, viro, mst, koct9i,
minchan, aquini, linux-fsdevel, virtualization, linux-kernel,
linux-api, linux-mm
Cc: gunho.lee, akpm, Gioh Kim, Gioh Kim
In-Reply-To: <1436243785-24105-1-git-send-email-gioh.kim@lge.com>
From: Gioh Kim <gurugio@hanmail.net>
The anon_inodes has already complete interfaces to create manage
many anonymous inodes but don't have interface to get
new inode. Other sub-modules can create anonymous inode
without creating and mounting it's own pseudo filesystem.
Signed-off-by: Gioh Kim <gioh.kim@lge.com>
---
fs/anon_inodes.c | 6 ++++++
include/linux/anon_inodes.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 80ef38c..1d51f96 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -162,6 +162,12 @@ err_put_unused_fd:
}
EXPORT_SYMBOL_GPL(anon_inode_getfd);
+struct inode *anon_inode_new(void)
+{
+ return alloc_anon_inode(anon_inode_mnt->mnt_sb);
+}
+EXPORT_SYMBOL_GPL(anon_inode_new);
+
static int __init anon_inode_init(void)
{
anon_inode_mnt = kern_mount(&anon_inode_fs_type);
diff --git a/include/linux/anon_inodes.h b/include/linux/anon_inodes.h
index 8013a45..ddbd67f 100644
--- a/include/linux/anon_inodes.h
+++ b/include/linux/anon_inodes.h
@@ -15,6 +15,7 @@ struct file *anon_inode_getfile(const char *name,
void *priv, int flags);
int anon_inode_getfd(const char *name, const struct file_operations *fops,
void *priv, int flags);
+struct inode *anon_inode_new(void);
#endif /* _LINUX_ANON_INODES_H */
--
2.1.4
^ permalink raw reply related
* [RFCv3 2/5] mm/compaction: enable mobile-page migration
From: Gioh Kim @ 2015-07-07 4:36 UTC (permalink / raw)
To: jlayton, bfields, vbabka, iamjoonsoo.kim, viro, mst, koct9i,
minchan, aquini, linux-fsdevel, virtualization, linux-kernel,
linux-api, linux-mm
Cc: gunho.lee, akpm, Gioh Kim, Gioh Kim
In-Reply-To: <1436243785-24105-1-git-send-email-gioh.kim@lge.com>
From: Gioh Kim <gurugio@hanmail.net>
Add framework to register callback functions and check page mobility.
There are some modes for page isolation so that isolate interface
has arguments of page address and isolation mode while putback
interface has only page address as argument.
Signed-off-by: Gioh Kim <gioh.kim@lge.com>
---
fs/proc/page.c | 3 ++
include/linux/compaction.h | 76 ++++++++++++++++++++++++++++++++++
include/linux/fs.h | 2 +
include/linux/page-flags.h | 19 +++++++++
include/uapi/linux/kernel-page-flags.h | 1 +
5 files changed, 101 insertions(+)
diff --git a/fs/proc/page.c b/fs/proc/page.c
index 7eee2d8..a4f5a00 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -146,6 +146,9 @@ u64 stable_page_flags(struct page *page)
if (PageBalloon(page))
u |= 1 << KPF_BALLOON;
+ if (PageMobile(page))
+ u |= 1 << KPF_MOBILE;
+
u |= kpf_copy_bit(k, KPF_LOCKED, PG_locked);
u |= kpf_copy_bit(k, KPF_SLAB, PG_slab);
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index aa8f61c..c375a89 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -1,6 +1,9 @@
#ifndef _LINUX_COMPACTION_H
#define _LINUX_COMPACTION_H
+#include <linux/page-flags.h>
+#include <linux/pagemap.h>
+
/* Return values for compact_zone() and try_to_compact_pages() */
/* compaction didn't start as it was deferred due to past failures */
#define COMPACT_DEFERRED 0
@@ -51,6 +54,66 @@ extern void compaction_defer_reset(struct zone *zone, int order,
bool alloc_success);
extern bool compaction_restarting(struct zone *zone, int order);
+static inline bool mobile_page(struct page *page)
+{
+ return page->mapping && page->mapping->a_ops &&
+ (PageMobile(page) || PageBalloon(page));
+}
+
+static inline bool isolate_mobilepage(struct page *page, isolate_mode_t mode)
+{
+ bool ret;
+
+ /*
+ * Avoid burning cycles with pages that are yet under __free_pages(),
+ * or just got freed under us.
+ *
+ * In case we 'win' a race for a mobile page being freed under us and
+ * raise its refcount preventing __free_pages() from doing its job
+ * the put_page() at the end of this block will take care of
+ * release this page, thus avoiding a nasty leakage.
+ */
+ if (likely(get_page_unless_zero(page))) {
+ /*
+ * As mobile pages are not isolated from LRU lists, concurrent
+ * compaction threads can race against page migration functions
+ * as well as race against the releasing a page.
+ *
+ * In order to avoid having an already isolated mobile page
+ * being (wrongly) re-isolated while it is under migration,
+ * or to avoid attempting to isolate pages being released,
+ * lets be sure we have the page lock
+ * before proceeding with the mobile page isolation steps.
+ */
+ if (likely(trylock_page(page))) {
+ if (mobile_page(page) &&
+ page->mapping->a_ops->isolatepage) {
+ ret = page->mapping->a_ops->isolatepage(page,
+ mode);
+ unlock_page(page);
+ return ret;
+ }
+ unlock_page(page);
+ }
+ put_page(page);
+ }
+ return false;
+}
+
+static inline void putback_mobilepage(struct page *page)
+{
+ /*
+ * 'lock_page()' stabilizes the page and prevents races against
+ * concurrent isolation threads attempting to re-isolate it.
+ */
+ lock_page(page);
+ if (mobile_page(page) && page->mapping->a_ops->putbackpage) {
+ page->mapping->a_ops->putbackpage(page);
+ /* drop the extra ref count taken for mobile page isolation */
+ put_page(page);
+ }
+ unlock_page(page);
+}
#else
static inline unsigned long try_to_compact_pages(gfp_t gfp_mask,
unsigned int order, int alloc_flags,
@@ -83,6 +146,19 @@ static inline bool compaction_deferred(struct zone *zone, int order)
return true;
}
+static inline bool mobile_page(struct page *page)
+{
+ return false;
+}
+
+static inline bool isolate_mobilepage(struct page *page, isolate_mode_t mode)
+{
+ return false;
+}
+
+static inline void putback_mobilepage(struct page *page)
+{
+}
#endif /* CONFIG_COMPACTION */
#if defined(CONFIG_COMPACTION) && defined(CONFIG_SYSFS) && defined(CONFIG_NUMA)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 35ec87e..33c9aa5 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -395,6 +395,8 @@ struct address_space_operations {
*/
int (*migratepage) (struct address_space *,
struct page *, struct page *, enum migrate_mode);
+ bool (*isolatepage) (struct page *, isolate_mode_t);
+ void (*putbackpage) (struct page *);
int (*launder_page) (struct page *);
int (*is_partially_uptodate) (struct page *, unsigned long,
unsigned long);
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index f34e040..abef145 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -582,6 +582,25 @@ static inline void __ClearPageBalloon(struct page *page)
atomic_set(&page->_mapcount, -1);
}
+#define PAGE_MOBILE_MAPCOUNT_VALUE (-255)
+
+static inline int PageMobile(struct page *page)
+{
+ return atomic_read(&page->_mapcount) == PAGE_MOBILE_MAPCOUNT_VALUE;
+}
+
+static inline void __SetPageMobile(struct page *page)
+{
+ VM_BUG_ON_PAGE(atomic_read(&page->_mapcount) != -1, page);
+ atomic_set(&page->_mapcount, PAGE_MOBILE_MAPCOUNT_VALUE);
+}
+
+static inline void __ClearPageMobile(struct page *page)
+{
+ VM_BUG_ON_PAGE(!PageMobile(page), page);
+ atomic_set(&page->_mapcount, -1);
+}
+
/*
* If network-based swap is enabled, sl*b must keep track of whether pages
* were allocated from pfmemalloc reserves.
diff --git a/include/uapi/linux/kernel-page-flags.h b/include/uapi/linux/kernel-page-flags.h
index a6c4962..d50d9e8 100644
--- a/include/uapi/linux/kernel-page-flags.h
+++ b/include/uapi/linux/kernel-page-flags.h
@@ -33,6 +33,7 @@
#define KPF_THP 22
#define KPF_BALLOON 23
#define KPF_ZERO_PAGE 24
+#define KPF_MOBILE 25
#endif /* _UAPILINUX_KERNEL_PAGE_FLAGS_H */
--
2.1.4
--
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>
^ permalink raw reply related
* [RFCv3 3/5] mm/balloon: apply mobile page migratable into balloon
From: Gioh Kim @ 2015-07-07 4:36 UTC (permalink / raw)
To: jlayton, bfields, vbabka, iamjoonsoo.kim, viro, mst, koct9i,
minchan, aquini, linux-fsdevel, virtualization, linux-kernel,
linux-api, linux-mm
Cc: gunho.lee, akpm, Gioh Kim, Gioh Kim
In-Reply-To: <1436243785-24105-1-git-send-email-gioh.kim@lge.com>
From: Gioh Kim <gurugio@hanmail.net>
Apply mobile page migration into balloon driver.
The balloong driver has an anonymous inode that manages
address_space_operation for page migration.
Signed-off-by: Gioh Kim <gioh.kim@lge.com>
---
drivers/virtio/virtio_balloon.c | 3 ++
include/linux/balloon_compaction.h | 15 +++++++--
mm/balloon_compaction.c | 65 +++++++++++++-------------------------
mm/compaction.c | 2 +-
mm/migrate.c | 2 +-
5 files changed, 39 insertions(+), 48 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 82e80e0..ef5b9b5 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -30,6 +30,7 @@
#include <linux/balloon_compaction.h>
#include <linux/oom.h>
#include <linux/wait.h>
+#include <linux/anon_inodes.h>
/*
* Balloon device works in 4K page units. So each page is pointed to by
@@ -505,6 +506,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
balloon_devinfo_init(&vb->vb_dev_info);
#ifdef CONFIG_BALLOON_COMPACTION
vb->vb_dev_info.migratepage = virtballoon_migratepage;
+ vb->vb_dev_info.inode = anon_inode_new();
+ vb->vb_dev_info.inode->i_mapping->a_ops = &balloon_aops;
#endif
err = init_vqs(vb);
diff --git a/include/linux/balloon_compaction.h b/include/linux/balloon_compaction.h
index 9b0a15d..a9e0bde 100644
--- a/include/linux/balloon_compaction.h
+++ b/include/linux/balloon_compaction.h
@@ -48,6 +48,7 @@
#include <linux/migrate.h>
#include <linux/gfp.h>
#include <linux/err.h>
+#include <linux/fs.h>
/*
* Balloon device information descriptor.
@@ -62,6 +63,7 @@ struct balloon_dev_info {
struct list_head pages; /* Pages enqueued & handled to Host */
int (*migratepage)(struct balloon_dev_info *, struct page *newpage,
struct page *page, enum migrate_mode mode);
+ struct inode *inode;
};
extern struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info);
@@ -73,12 +75,16 @@ static inline void balloon_devinfo_init(struct balloon_dev_info *balloon)
spin_lock_init(&balloon->pages_lock);
INIT_LIST_HEAD(&balloon->pages);
balloon->migratepage = NULL;
+ balloon->inode = NULL;
}
#ifdef CONFIG_BALLOON_COMPACTION
-extern bool balloon_page_isolate(struct page *page);
+extern const struct address_space_operations balloon_aops;
+extern bool balloon_page_isolate(struct page *page,
+ isolate_mode_t mode);
extern void balloon_page_putback(struct page *page);
-extern int balloon_page_migrate(struct page *newpage,
+extern int balloon_page_migrate(struct address_space *mapping,
+ struct page *newpage,
struct page *page, enum migrate_mode mode);
/*
@@ -124,6 +130,7 @@ static inline void balloon_page_insert(struct balloon_dev_info *balloon,
struct page *page)
{
__SetPageBalloon(page);
+ page->mapping = balloon->inode->i_mapping;
SetPagePrivate(page);
set_page_private(page, (unsigned long)balloon);
list_add(&page->lru, &balloon->pages);
@@ -140,6 +147,7 @@ static inline void balloon_page_insert(struct balloon_dev_info *balloon,
static inline void balloon_page_delete(struct page *page)
{
__ClearPageBalloon(page);
+ page->mapping = NULL;
set_page_private(page, 0);
if (PagePrivate(page)) {
ClearPagePrivate(page);
@@ -191,7 +199,8 @@ static inline bool isolated_balloon_page(struct page *page)
return false;
}
-static inline bool balloon_page_isolate(struct page *page)
+static inline bool balloon_page_isolate(struct page *page,
+ isolate_mode_t mode)
{
return false;
}
diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
index fcad832..0dd0b0d 100644
--- a/mm/balloon_compaction.c
+++ b/mm/balloon_compaction.c
@@ -131,43 +131,16 @@ static inline void __putback_balloon_page(struct page *page)
}
/* __isolate_lru_page() counterpart for a ballooned page */
-bool balloon_page_isolate(struct page *page)
+bool balloon_page_isolate(struct page *page, isolate_mode_t mode)
{
/*
- * Avoid burning cycles with pages that are yet under __free_pages(),
- * or just got freed under us.
- *
- * In case we 'win' a race for a balloon page being freed under us and
- * raise its refcount preventing __free_pages() from doing its job
- * the put_page() at the end of this block will take care of
- * release this page, thus avoiding a nasty leakage.
+ * A ballooned page, by default, has PagePrivate set.
+ * Prevent concurrent compaction threads from isolating
+ * an already isolated balloon page by clearing it.
*/
- if (likely(get_page_unless_zero(page))) {
- /*
- * As balloon pages are not isolated from LRU lists, concurrent
- * compaction threads can race against page migration functions
- * as well as race against the balloon driver releasing a page.
- *
- * In order to avoid having an already isolated balloon page
- * being (wrongly) re-isolated while it is under migration,
- * or to avoid attempting to isolate pages being released by
- * the balloon driver, lets be sure we have the page lock
- * before proceeding with the balloon page isolation steps.
- */
- if (likely(trylock_page(page))) {
- /*
- * A ballooned page, by default, has PagePrivate set.
- * Prevent concurrent compaction threads from isolating
- * an already isolated balloon page by clearing it.
- */
- if (balloon_page_movable(page)) {
- __isolate_balloon_page(page);
- unlock_page(page);
- return true;
- }
- unlock_page(page);
- }
- put_page(page);
+ if (balloon_page_movable(page)) {
+ __isolate_balloon_page(page);
+ return true;
}
return false;
}
@@ -175,30 +148,28 @@ bool balloon_page_isolate(struct page *page)
/* putback_lru_page() counterpart for a ballooned page */
void balloon_page_putback(struct page *page)
{
- /*
- * 'lock_page()' stabilizes the page and prevents races against
- * concurrent isolation threads attempting to re-isolate it.
- */
- lock_page(page);
+ if (!isolated_balloon_page(page))
+ return;
if (__is_movable_balloon_page(page)) {
__putback_balloon_page(page);
- /* drop the extra ref count taken for page isolation */
- put_page(page);
} else {
WARN_ON(1);
dump_page(page, "not movable balloon page");
}
- unlock_page(page);
}
/* move_to_new_page() counterpart for a ballooned page */
-int balloon_page_migrate(struct page *newpage,
+int balloon_page_migrate(struct address_space *mapping,
+ struct page *newpage,
struct page *page, enum migrate_mode mode)
{
struct balloon_dev_info *balloon = balloon_page_device(page);
int rc = -EAGAIN;
+ if (!isolated_balloon_page(page))
+ return rc;
+
/*
* Block others from accessing the 'newpage' when we get around to
* establishing additional references. We should be the only one
@@ -218,4 +189,12 @@ int balloon_page_migrate(struct page *newpage,
unlock_page(newpage);
return rc;
}
+
+/* define the balloon_mapping->a_ops callback to allow balloon page migration */
+const struct address_space_operations balloon_aops = {
+ .migratepage = balloon_page_migrate,
+ .isolatepage = balloon_page_isolate,
+ .putbackpage = balloon_page_putback,
+};
+EXPORT_SYMBOL_GPL(balloon_aops);
#endif /* CONFIG_BALLOON_COMPACTION */
diff --git a/mm/compaction.c b/mm/compaction.c
index 018f08d..81bafaf 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -719,7 +719,7 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
*/
if (!PageLRU(page)) {
if (unlikely(balloon_page_movable(page))) {
- if (balloon_page_isolate(page)) {
+ if (balloon_page_isolate(page, isolate_mode)) {
/* Successfully isolated */
goto isolate_success;
}
diff --git a/mm/migrate.c b/mm/migrate.c
index f53838f..c94038e 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -852,7 +852,7 @@ static int __unmap_and_move(struct page *page, struct page *newpage,
* in order to avoid burning cycles at rmap level, and perform
* the page migration right away (proteced by page lock).
*/
- rc = balloon_page_migrate(newpage, page, mode);
+ rc = balloon_page_migrate(page->mapping, newpage, page, mode);
goto out_unlock;
}
--
2.1.4
--
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>
^ permalink raw reply related
* [RFCv3 4/5] mm: call generic migration callbacks
From: Gioh Kim @ 2015-07-07 4:36 UTC (permalink / raw)
To: jlayton, bfields, vbabka, iamjoonsoo.kim, viro, mst, koct9i,
minchan, aquini, linux-fsdevel, virtualization, linux-kernel,
linux-api, linux-mm
Cc: gunho.lee, akpm, Gioh Kim, Gioh Kim
In-Reply-To: <1436243785-24105-1-git-send-email-gioh.kim@lge.com>
From: Gioh Kim <gurugio@hanmail.net>
Compaction calls interfaces of mobile page migration
instead of calling balloon migration directly.
Signed-off-by: Gioh Kim <gioh.kim@lge.com>
---
mm/compaction.c | 8 ++++----
mm/migrate.c | 19 ++++++++++---------
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 81bafaf..60e4cbb 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -14,7 +14,7 @@
#include <linux/backing-dev.h>
#include <linux/sysctl.h>
#include <linux/sysfs.h>
-#include <linux/balloon_compaction.h>
+#include <linux/compaction.h>
#include <linux/page-isolation.h>
#include <linux/kasan.h>
#include "internal.h"
@@ -714,12 +714,12 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
/*
* Check may be lockless but that's ok as we recheck later.
- * It's possible to migrate LRU pages and balloon pages
+ * It's possible to migrate LRU pages and mobile pages
* Skip any other type of page
*/
if (!PageLRU(page)) {
- if (unlikely(balloon_page_movable(page))) {
- if (balloon_page_isolate(page, isolate_mode)) {
+ if (unlikely(mobile_page(page))) {
+ if (isolate_mobilepage(page, isolate_mode)) {
/* Successfully isolated */
goto isolate_success;
}
diff --git a/mm/migrate.c b/mm/migrate.c
index c94038e..e22be67 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -35,7 +35,7 @@
#include <linux/hugetlb.h>
#include <linux/hugetlb_cgroup.h>
#include <linux/gfp.h>
-#include <linux/balloon_compaction.h>
+#include <linux/compaction.h>
#include <linux/mmu_notifier.h>
#include <asm/tlbflush.h>
@@ -76,7 +76,7 @@ int migrate_prep_local(void)
* from where they were once taken off for compaction/migration.
*
* This function shall be used whenever the isolated pageset has been
- * built from lru, balloon, hugetlbfs page. See isolate_migratepages_range()
+ * built from lru, mobile, hugetlbfs page. See isolate_migratepages_range()
* and isolate_huge_page().
*/
void putback_movable_pages(struct list_head *l)
@@ -92,8 +92,8 @@ void putback_movable_pages(struct list_head *l)
list_del(&page->lru);
dec_zone_page_state(page, NR_ISOLATED_ANON +
page_is_file_cache(page));
- if (unlikely(isolated_balloon_page(page)))
- balloon_page_putback(page);
+ if (unlikely(mobile_page(page)))
+ putback_mobilepage(page);
else
putback_lru_page(page);
}
@@ -844,15 +844,16 @@ static int __unmap_and_move(struct page *page, struct page *newpage,
}
}
- if (unlikely(isolated_balloon_page(page))) {
+ if (unlikely(mobile_page(page))) {
/*
- * A ballooned page does not need any special attention from
+ * A mobile page does not need any special attention from
* physical to virtual reverse mapping procedures.
* Skip any attempt to unmap PTEs or to remap swap cache,
* in order to avoid burning cycles at rmap level, and perform
* the page migration right away (proteced by page lock).
*/
- rc = balloon_page_migrate(page->mapping, newpage, page, mode);
+ rc = page->mapping->a_ops->migratepage(page->mapping,
+ newpage, page, mode);
goto out_unlock;
}
@@ -960,8 +961,8 @@ out:
if (rc != MIGRATEPAGE_SUCCESS && put_new_page) {
ClearPageSwapBacked(newpage);
put_new_page(newpage, private);
- } else if (unlikely(__is_movable_balloon_page(newpage))) {
- /* drop our reference, page already in the balloon */
+ } else if (unlikely(mobile_page(newpage))) {
+ /* drop our reference */
put_page(newpage);
} else
putback_lru_page(newpage);
--
2.1.4
--
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>
^ permalink raw reply related
* [RFCv3 5/5] mm: remove direct calling of migration
From: Gioh Kim @ 2015-07-07 4:36 UTC (permalink / raw)
To: jlayton, bfields, vbabka, iamjoonsoo.kim, viro, mst, koct9i,
minchan, aquini, linux-fsdevel, virtualization, linux-kernel,
linux-api, linux-mm
Cc: gunho.lee, akpm, Gioh Kim, Gioh Kim
In-Reply-To: <1436243785-24105-1-git-send-email-gioh.kim@lge.com>
From: Gioh Kim <gurugio@hanmail.net>
Migration is completely generalized so that migrating mobile page
is processed with lru-pages in move_to_new_page.
Signed-off-by: Gioh Kim <gioh.kim@lge.com>
---
mm/balloon_compaction.c | 8 --------
mm/migrate.c | 13 -------------
2 files changed, 21 deletions(-)
diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
index 0dd0b0d..9d07ed9 100644
--- a/mm/balloon_compaction.c
+++ b/mm/balloon_compaction.c
@@ -170,13 +170,6 @@ int balloon_page_migrate(struct address_space *mapping,
if (!isolated_balloon_page(page))
return rc;
- /*
- * Block others from accessing the 'newpage' when we get around to
- * establishing additional references. We should be the only one
- * holding a reference to the 'newpage' at this point.
- */
- BUG_ON(!trylock_page(newpage));
-
if (WARN_ON(!__is_movable_balloon_page(page))) {
dump_page(page, "not movable balloon page");
unlock_page(newpage);
@@ -186,7 +179,6 @@ int balloon_page_migrate(struct address_space *mapping,
if (balloon && balloon->migratepage)
rc = balloon->migratepage(balloon, newpage, page, mode);
- unlock_page(newpage);
return rc;
}
diff --git a/mm/migrate.c b/mm/migrate.c
index e22be67..b82539b 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -844,19 +844,6 @@ static int __unmap_and_move(struct page *page, struct page *newpage,
}
}
- if (unlikely(mobile_page(page))) {
- /*
- * A mobile page does not need any special attention from
- * physical to virtual reverse mapping procedures.
- * Skip any attempt to unmap PTEs or to remap swap cache,
- * in order to avoid burning cycles at rmap level, and perform
- * the page migration right away (proteced by page lock).
- */
- rc = page->mapping->a_ops->migratepage(page->mapping,
- newpage, page, mode);
- goto out_unlock;
- }
-
/*
* Corner case handling:
* 1. When a new swap-cache page is read into, it is added to the LRU
--
2.1.4
--
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>
^ permalink raw reply related
* Re: [PATCH v3] ipc: Modify message queue accounting to not take kernel data structures into account
From: Davidlohr Bueso @ 2015-07-07 5:16 UTC (permalink / raw)
To: Marcus Gelderie
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Doug Ledford, lkml,
David Howells, Alexander Viro, John Duffy, Arto Bendiken,
Linux API, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <20150706154928.GA19828-W7fNxlbxG8VSq9BJjBFyUp/QNRX+jHPU@public.gmane.org>
On Mon, 2015-07-06 at 17:49 +0200, Marcus Gelderie wrote:
> A while back, the message queue implementation in the kernel was
> improved to use btrees to speed up retrieval of messages (commit
> d6629859b36). The patch introducing the improved kernel handling of
> message queues (using btrees) has, as a by-product, changed the
> meaning of the QSIZE field in the pseudo-file created for the queue.
> Before, this field reflected the size of the user-data in the queue.
> Since, it also takes kernel data structures into account. For
> example, if 13 bytes of user data are in the queue, on my machine the
> file reports a size of 61 bytes.
>
> There was some discussion on this topic before (for example
> https://lkml.org/lkml/2014/10/1/115). Commenting on a th lkml, Michael
> Kerrisk gave the following background (https://lkml.org/lkml/2015/6/16/74):
>
> The pseudofiles in the mqueue filesystem (usually mounted at
> /dev/mqueue) expose fields with metadata describing a message
> queue. One of these fields, QSIZE, as originally implemented,
> showed the total number of bytes of user data in all messages in
> the message queue, and this feature was documented from the
> beginning in the mq_overview(7) page. In 3.5, some other (useful)
> work happened to break the user-space API in a couple of places,
> including the value exposed via QSIZE, which now includes a measure
> of kernel overhead bytes for the queue, a figure that renders QSIZE
> useless for its original purpose, since there's no way to deduce
> the number of overhead bytes consumed by the implementation.
> (The other user-space breakage was subsequently fixed.)
Michael, this breakage was never finally documented in the manpage,
right? I took a look and there is no mention, but it was a quick look.
It's just that if this patch goes in, I'd hate ending up with something
like this in the manpage:
as of 3.5
<accounts for kernel overhead>
as of 4.3
<behavior reverted back to not include kernel overhead... *sigh*>
If there are changes to be made to the manpage, it should probably be
posted with this patch, methinks.
>
> This patch removes the accounting of kernel data structures in the
> queue. Reporting the size of these data-structures in the QSIZE field
> was a breaking change (see Michael's comment above). Without the QSIZE
> field reporting the total size of user-data in the queue, there is no
> way to deduce this number.
>
> It should be noted that the resource limit RLIMIT_MSGQUEUE is counted
> against the worst-case size of the queue (in both the old and the new
> implementation). Therefore, the kernel overhead accounting in QSIZE is
> not necessary to help the user understand the limitations RLIMIT imposes
> on the processes.
Also, I would suggest adding some comment in struct mqueue_inode_info
for future reference, ie:
- unsigned long qsize; /* size of queue in memory (sum of all msgs) */
+ /*
+ * Size of queue in memory (sum of all msgs). Accounts for
+ * only userspace overhead; ignoring any in-kernel rbtree nodes.
+ */
+ unsigned long qsize;
But no big deal in any case.
I think this is the right approach, but would still like to know if Doug
has any concerns about it.
Thanks,
Davidlohr
^ permalink raw reply
* [PATCH 0/5] coresight: Support context-ID tracing when PID namespace is enabled
From: Chunyan Zhang @ 2015-07-07 8:41 UTC (permalink / raw)
To: mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A,
serge.broslavsky-QSEj5FYQhm4dnm+yROfE0A,
zhang.lyra-Re5JQEeQqe8AvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
The Coresight ETM drivers already support context-ID tracing, but it won't
work when PID namespace is enabled. This is because when using PID
namespace a process id (ie. VPID) seen from the current namespace differs
from the id (ie. PID) seen by kernel.
This patch-set does add a translation between VPID and PID.
Chunyan Zhang (5):
coresight-etm3x: Change the name of the ctxid_val to ctxid_pid
coresight-etm4x: Change the name of the ctxid_val to ctxid_pid
Coresight: Add an interface for supporting ETM3/4 Context ID tracing
coresight-etm3x: Support context-ID tracing when PID namespace is
enabled
coresight-etm4x: Support context-ID tracing when PID namespace is
enabled
.../ABI/testing/sysfs-bus-coresight-devices-etm3x | 2 +-
.../ABI/testing/sysfs-bus-coresight-devices-etm4x | 2 +-
drivers/hwtracing/coresight/coresight-etm.h | 7 ++--
drivers/hwtracing/coresight/coresight-etm3x.c | 28 +++++++++-------
drivers/hwtracing/coresight/coresight-etm4x.c | 37 ++++++++++++++--------
drivers/hwtracing/coresight/coresight-etm4x.h | 7 ++--
include/linux/coresight.h | 20 ++++++++++++
7 files changed, 72 insertions(+), 31 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/5] coresight-etm3x: Change the name of the ctxid_val to ctxid_pid
From: Chunyan Zhang @ 2015-07-07 8:41 UTC (permalink / raw)
To: mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A,
serge.broslavsky-QSEj5FYQhm4dnm+yROfE0A,
zhang.lyra-Re5JQEeQqe8AvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1436258518-9339-1-git-send-email-zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
'ctxid_val' array was used to store the value of ETM context ID comparator
which actually stores the process ID to be traced, so using 'ctxid_pid' as
its name instead make it easier to understand.
This patch also changes the ABI, it is normally not allowed, but
fortunately it is a testing ABI and very new for now. Nevertheless,
if you don't think it should be changed, we could always add an alias
for userspace.
Signed-off-by: Chunyan Zhang <zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../ABI/testing/sysfs-bus-coresight-devices-etm3x | 2 +-
drivers/hwtracing/coresight/coresight-etm.h | 4 ++--
drivers/hwtracing/coresight/coresight-etm3x.c | 16 ++++++++--------
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
index b4d0b99..d72ca17 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
@@ -112,7 +112,7 @@ KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Description: (RW) Mask to apply to all the context ID comparator.
-What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_val
+What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_pid
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index 098ffbe..52af5f0 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -183,7 +183,7 @@
* @seq_13_event: event causing the transition from 1 to 3.
* @seq_curr_state: current value of the sequencer register.
* @ctxid_idx: index for the context ID registers.
- * @ctxid_val: value for the context ID to trigger on.
+ * @ctxid_pid: value for the context ID to trigger on.
* @ctxid_mask: mask applicable to all the context IDs.
* @sync_freq: Synchronisation frequency.
* @timestamp_event: Defines an event that requests the insertion
@@ -235,7 +235,7 @@ struct etm_drvdata {
u32 seq_13_event;
u32 seq_curr_state;
u8 ctxid_idx;
- u32 ctxid_val[ETM_MAX_CTXID_CMP];
+ u32 ctxid_pid[ETM_MAX_CTXID_CMP];
u32 ctxid_mask;
u32 sync_freq;
u32 timestamp_event;
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 018a00f..cfda302 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -238,7 +238,7 @@ static void etm_set_default(struct etm_drvdata *drvdata)
drvdata->seq_curr_state = 0x0;
drvdata->ctxid_idx = 0x0;
for (i = 0; i < drvdata->nr_ctxid_cmp; i++)
- drvdata->ctxid_val[i] = 0x0;
+ drvdata->ctxid_pid[i] = 0x0;
drvdata->ctxid_mask = 0x0;
}
@@ -289,7 +289,7 @@ static void etm_enable_hw(void *info)
for (i = 0; i < drvdata->nr_ext_out; i++)
etm_writel(drvdata, ETM_DEFAULT_EVENT_VAL, ETMEXTOUTEVRn(i));
for (i = 0; i < drvdata->nr_ctxid_cmp; i++)
- etm_writel(drvdata, drvdata->ctxid_val[i], ETMCIDCVRn(i));
+ etm_writel(drvdata, drvdata->ctxid_pid[i], ETMCIDCVRn(i));
etm_writel(drvdata, drvdata->ctxid_mask, ETMCIDCMR);
etm_writel(drvdata, drvdata->sync_freq, ETMSYNCFR);
/* No external input selected */
@@ -1386,20 +1386,20 @@ static ssize_t ctxid_idx_store(struct device *dev,
}
static DEVICE_ATTR_RW(ctxid_idx);
-static ssize_t ctxid_val_show(struct device *dev,
+static ssize_t ctxid_pid_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
unsigned long val;
struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
spin_lock(&drvdata->spinlock);
- val = drvdata->ctxid_val[drvdata->ctxid_idx];
+ val = drvdata->ctxid_pid[drvdata->ctxid_idx];
spin_unlock(&drvdata->spinlock);
return sprintf(buf, "%#lx\n", val);
}
-static ssize_t ctxid_val_store(struct device *dev,
+static ssize_t ctxid_pid_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t size)
{
@@ -1412,12 +1412,12 @@ static ssize_t ctxid_val_store(struct device *dev,
return ret;
spin_lock(&drvdata->spinlock);
- drvdata->ctxid_val[drvdata->ctxid_idx] = val;
+ drvdata->ctxid_pid[drvdata->ctxid_idx] = val;
spin_unlock(&drvdata->spinlock);
return size;
}
-static DEVICE_ATTR_RW(ctxid_val);
+static DEVICE_ATTR_RW(ctxid_pid);
static ssize_t ctxid_mask_show(struct device *dev,
struct device_attribute *attr, char *buf)
@@ -1609,7 +1609,7 @@ static struct attribute *coresight_etm_attrs[] = {
&dev_attr_seq_13_event.attr,
&dev_attr_seq_curr_state.attr,
&dev_attr_ctxid_idx.attr,
- &dev_attr_ctxid_val.attr,
+ &dev_attr_ctxid_pid.attr,
&dev_attr_ctxid_mask.attr,
&dev_attr_sync_freq.attr,
&dev_attr_timestamp_event.attr,
--
1.9.1
^ permalink raw reply related
* [PATCH 2/5] coresight-etm4x: Change the name of the ctxid_val to ctxid_pid
From: Chunyan Zhang @ 2015-07-07 8:41 UTC (permalink / raw)
To: mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A,
serge.broslavsky-QSEj5FYQhm4dnm+yROfE0A,
zhang.lyra-Re5JQEeQqe8AvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1436258518-9339-1-git-send-email-zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
'ctxid_val' array was used to store the value of ETM context ID comparator
which actually stores the process ID to be traced, so using 'ctxid_pid' as
its name instead make it easier to understand.
This patch also changes the ABI, it is normally not allowed, but
fortunately it is a testing ABI and very new for now. Nevertheless,
if you don't think it should be changed, we could always add an alias
for userspace.
Signed-off-by: Chunyan Zhang <zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../ABI/testing/sysfs-bus-coresight-devices-etm4x | 2 +-
drivers/hwtracing/coresight/coresight-etm4x.c | 20 ++++++++++----------
drivers/hwtracing/coresight/coresight-etm4x.h | 4 ++--
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
index 2fe2e3d..2355ed8 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
@@ -249,7 +249,7 @@ KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Description: (RW) Select which context ID comparator to work with.
-What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_val
+What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_pid
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index 1312e99..9afbda5 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -155,7 +155,7 @@ static void etm4_enable_hw(void *info)
drvdata->base + TRCACATRn(i));
}
for (i = 0; i < drvdata->numcidc; i++)
- writeq_relaxed(drvdata->ctxid_val[i],
+ writeq_relaxed(drvdata->ctxid_pid[i],
drvdata->base + TRCCIDCVRn(i));
writel_relaxed(drvdata->ctxid_mask0, drvdata->base + TRCCIDCCTLR0);
writel_relaxed(drvdata->ctxid_mask1, drvdata->base + TRCCIDCCTLR1);
@@ -507,7 +507,7 @@ static ssize_t reset_store(struct device *dev,
drvdata->ctxid_idx = 0x0;
for (i = 0; i < drvdata->numcidc; i++)
- drvdata->ctxid_val[i] = 0x0;
+ drvdata->ctxid_pid[i] = 0x0;
drvdata->ctxid_mask0 = 0x0;
drvdata->ctxid_mask1 = 0x0;
@@ -1815,7 +1815,7 @@ static ssize_t ctxid_idx_store(struct device *dev,
}
static DEVICE_ATTR_RW(ctxid_idx);
-static ssize_t ctxid_val_show(struct device *dev,
+static ssize_t ctxid_pid_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
@@ -1825,12 +1825,12 @@ static ssize_t ctxid_val_show(struct device *dev,
spin_lock(&drvdata->spinlock);
idx = drvdata->ctxid_idx;
- val = (unsigned long)drvdata->ctxid_val[idx];
+ val = (unsigned long)drvdata->ctxid_pid[idx];
spin_unlock(&drvdata->spinlock);
return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
}
-static ssize_t ctxid_val_store(struct device *dev,
+static ssize_t ctxid_pid_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t size)
{
@@ -1850,11 +1850,11 @@ static ssize_t ctxid_val_store(struct device *dev,
spin_lock(&drvdata->spinlock);
idx = drvdata->ctxid_idx;
- drvdata->ctxid_val[idx] = (u64)val;
+ drvdata->ctxid_pid[idx] = (u64)val;
spin_unlock(&drvdata->spinlock);
return size;
}
-static DEVICE_ATTR_RW(ctxid_val);
+static DEVICE_ATTR_RW(ctxid_pid);
static ssize_t ctxid_masks_show(struct device *dev,
struct device_attribute *attr,
@@ -1949,7 +1949,7 @@ static ssize_t ctxid_masks_store(struct device *dev,
*/
for (j = 0; j < 8; j++) {
if (maskbyte & 1)
- drvdata->ctxid_val[i] &= ~(0xFF << (j * 8));
+ drvdata->ctxid_pid[i] &= ~(0xFF << (j * 8));
maskbyte >>= 1;
}
/* Select the next ctxid comparator mask value */
@@ -2193,7 +2193,7 @@ static struct attribute *coresight_etmv4_attrs[] = {
&dev_attr_res_idx.attr,
&dev_attr_res_ctrl.attr,
&dev_attr_ctxid_idx.attr,
- &dev_attr_ctxid_val.attr,
+ &dev_attr_ctxid_pid.attr,
&dev_attr_ctxid_masks.attr,
&dev_attr_vmid_idx.attr,
&dev_attr_vmid_val.attr,
@@ -2514,7 +2514,7 @@ static void etm4_init_default_data(struct etmv4_drvdata *drvdata)
}
for (i = 0; i < drvdata->numcidc; i++)
- drvdata->ctxid_val[i] = 0x0;
+ drvdata->ctxid_pid[i] = 0x0;
drvdata->ctxid_mask0 = 0x0;
drvdata->ctxid_mask1 = 0x0;
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index e08e983..1e8fb36 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -265,7 +265,7 @@
* @addr_type: Current status of the comparator register.
* @ctxid_idx: Context ID index selector.
* @ctxid_size: Size of the context ID field to consider.
- * @ctxid_val: Value of the context ID comparator.
+ * @ctxid_pid: Value of the context ID comparator.
* @ctxid_mask0:Context ID comparator mask for comparator 0-3.
* @ctxid_mask1:Context ID comparator mask for comparator 4-7.
* @vmid_idx: VM ID index selector.
@@ -352,7 +352,7 @@ struct etmv4_drvdata {
u8 addr_type[ETM_MAX_SINGLE_ADDR_CMP];
u8 ctxid_idx;
u8 ctxid_size;
- u64 ctxid_val[ETMv4_MAX_CTXID_CMP];
+ u64 ctxid_pid[ETMv4_MAX_CTXID_CMP];
u32 ctxid_mask0;
u32 ctxid_mask1;
u8 vmid_idx;
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox