* Re: [PATCH v2] pci: export class IDs from pci_ids.h
From: Michael S. Tsirkin @ 2015-04-05 11:20 UTC (permalink / raw)
To: Greg KH
Cc: Bjorn Helgaas, linux-kernel, Jonathan Corbet, David S. Miller,
Hans Verkuil, Mauro Carvalho Chehab, Alexei Starovoitov,
stephen hemminger, Masahiro Yamada, linux-pci, linux-doc,
linux-api
In-Reply-To: <20150402215921.GA3942@kroah.com>
On Thu, Apr 02, 2015 at 11:59:21PM +0200, Greg KH wrote:
> On Thu, Apr 02, 2015 at 11:28:19PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Apr 02, 2015 at 03:53:47PM -0500, Bjorn Helgaas wrote:
> > > On Mon, Mar 30, 2015 at 01:33:28PM +0200, Michael S. Tsirkin wrote:
> > > > The basic class ID macros in pci_ids.h are pretty useful for userspace
> > > > using the pci sysfs interface, and they aren't fundamentally different
> > > > from the constants in pci_regs.h - both are defined in the
> > > > pci spec.
> > > >
> > > > At the moment userspace is forced to duplicate these macros
> > > > (e.g. QEMU does this, so do seabios, gpxe, and others), it is better to
> > > > expose them in /usr/include/linux/pci_ids.h so everyone can just include
> > > > this header.
> > >
> > > I agree that it would be nice for applications to get these definitions
> > > from a single place, but I'm not sure that include/uapi/linux/pci_ids.h
> > > needs to be that place.
> > >
> > > These constants are just copies of what's in the spec, and I don't think
> > > you're suggesting that the constants are necessary to use a kernel API.
> > >
> > > I know the kernel does provide access to values via sysfs "class" files,
> > > but the kernel is just passing the values through from the hardware.
> > > That's analogous to reading the class with setpci, and I don't think it
> > > leads to a requirement that the kernel export all the information about how
> > > to interpret the class values.
> > >
> > > I haven't looked at libpci or libudev, but it sounds like you think those
> > > are not good solutions. Is that because they don't currently have this
> > > information? People don't want to add dependencies on them?
> > >
> > > Bjorn
> >
> > People don't want to add dependencies on them.
>
> So you want us to create yet-a-third-location for these values?
I propose making this part of base Linux system headers, yes.
BTW it's not a third location actually. It would be a third location in a
library, but there are many other packages that duplicate this code.
Since we have this code around anyway, if we just export it, then
there's hope that with time all this duplicate code will go away, then
when e.g. a new value is added to spec, people will add it to linux and
everyone benefits. As I work on QEMU, I know QEMU will do it,
likely bios and gpxe too, I expect libpci/libudev to be no different.
> Both
> libpci and libudev are on all systems. And it's not a run-time
> dependancy you are talking about here, but a build-time one, which is
> quite different.
Yes: build-time dependencies annoy developers, run-time ones annoy users :)
In a sense build-time dependencies are more annoying as it's harder to
resolve them.
> Having a build-time dependancy on packages that ship
> with all Linux distributions seems acceptable to me.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH v2] pci: export class IDs from pci_ids.h
From: Michael S. Tsirkin @ 2015-04-05 12:05 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jonathan Corbet, David S. Miller, Hans Verkuil,
Mauro Carvalho Chehab, Alexei Starovoitov, stephen hemminger,
Masahiro Yamada,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA, Greg KH, Martin Mareš
In-Reply-To: <CAErSpo7Wtg2QTznd7RpqXrGO7BL7OekE89iH6CvuXsC6gyVXWg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 02, 2015 at 05:32:14PM -0500, Bjorn Helgaas wrote:
> [+cc Martin]
That's a good idea. Martin, could you please answer the following:
assuming that linux exported linux/pci_ids.h providing class
IDs that are currently in /usr/include/pci/header.h
in a header /usr/include/linux/pci_ids.h,
would libpci be open to replacing part of
/usr/include/pci/header.h with #include <linux/pci_ids.h>,
assuming that a solution for old systems that lack this
header is also provided?
> On Thu, Apr 2, 2015 at 4:28 PM, Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Thu, Apr 02, 2015 at 03:53:47PM -0500, Bjorn Helgaas wrote:
> >> On Mon, Mar 30, 2015 at 01:33:28PM +0200, Michael S. Tsirkin wrote:
> >> > The basic class ID macros in pci_ids.h are pretty useful for userspace
> >> > using the pci sysfs interface, and they aren't fundamentally different
> >> > from the constants in pci_regs.h - both are defined in the
> >> > pci spec.
> >> >
> >> > At the moment userspace is forced to duplicate these macros
> >> > (e.g. QEMU does this, so do seabios, gpxe, and others), it is better to
> >> > expose them in /usr/include/linux/pci_ids.h so everyone can just include
> >> > this header.
> >>
> >> I agree that it would be nice for applications to get these definitions
> >> from a single place, but I'm not sure that include/uapi/linux/pci_ids.h
> >> needs to be that place.
> >>
> >> These constants are just copies of what's in the spec, and I don't think
> >> you're suggesting that the constants are necessary to use a kernel API.
> >>
> >> I know the kernel does provide access to values via sysfs "class" files,
> >> but the kernel is just passing the values through from the hardware.
> >> That's analogous to reading the class with setpci, and I don't think it
> >> leads to a requirement that the kernel export all the information about how
> >> to interpret the class values.
> >>
> >> I haven't looked at libpci or libudev, but it sounds like you think those
> >> are not good solutions. Is that because they don't currently have this
> >> information? People don't want to add dependencies on them?
> >
> > People don't want to add dependencies on them.
>
> Why not? I'm not a user-space programmer, so it's not obvious to me
> what the problems with adding a dependency are. If a package provides
> functionality you want, it seems like a *good* thing to use it and
> depend on it rather than reimplementing the functionality yourself.
> The /usr/include/pci/header.h supplied by libpci-dev (on Ubuntu) looks
> like it has most or all of the constants you want.
>
> Bjorn
Well, so does libudev-devel according to Greg. Do you know why doesn't
libudev-devel include /usr/include/pci/header.h?
xorg has a copy too: /usr/include/xorg/xf86Pci.h
Why does not xorg include /usr/include/pci/header.h?
I think I know - I think that's because each extra dependency does
introduce overhead: it's another community to interact with to fix bugs
and add features, it's more portability and version skew headaches.
Besides, I'm guessing that the linux header is less likely to have bugs.
Consider PCI_CLASS_STORAGE_IDE:
pciutils]$ git grep PCI_CLASS_STORAGE_IDE
lib/header.h:#define PCI_CLASS_STORAGE_IDE 0x0101
$ git grep PCI_CLASS_STORAGE_IDE
arch/alpha/kernel/pci.c: if (dev->class >> 8 == PCI_CLASS_STORAGE_IDE) {
....
many more hits.
pciutils does nothing with this value itself, it's possible for a distro
to ship a wrong header, and no one will notice. OTOH Linux will break if
it's wrong. In fact there are 3 values libpci does appear to use
internally:
PCI_CLASS_BRIDGE_HOST
PCI_CLASS_DISPLAY_VGA
PCI_CLASS_BRIDGE_PCI
I'm guessing others are re-exported for the benefit of
applications using libpci.
--
MST
^ permalink raw reply
* Re: [PATCH v4 00/14] Add kdbus implementation
From: Eric W. Biederman @ 2015-04-05 12:09 UTC (permalink / raw)
To: David Herrmann, Andy Lutomirski
Cc: Tom Gundersen, Greg Kroah-Hartman, Arnd Bergmann,
One Thousand Gnomes, Jiri Kosina, Linux API,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Daniel Mack,
Djalal Harouni
In-Reply-To: <CANq1E4QSja-KhVL2p-d406uLJT600zMpK2UAcwsb0LkMwa8F7w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On April 3, 2015 6:51:34 AM CDT, David Herrmann <dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>Hi
>
>On Tue, Mar 31, 2015 at 8:29 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
>wrote:
>> On Tue, Mar 31, 2015 at 8:10 AM, Tom Gundersen <teg-B22kvLQNl6c@public.gmane.org> wrote:
>>> On Tue, Mar 31, 2015 at 3:58 PM, Andy Lutomirski
><luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
>>>>
>>>> IOW you're taking something that you dislike aspects of and shoving
>>>> most of it in the kernel. That guarantees us an API in the kernel
>>>> that even the creators don't really like. This is, IMO, very
>>>> unfortunate.
>>>
>>> This is a misrepresentation of what David wrote. We do want this API
>>> regardless of dbus1 compatibility, but compatibility is by itself a
>>> sufficient motivation. A further motivation is reliable
>introspection,
>>> since this meta-data allows listing current peers on the bus and
>>> showing their identities. That's hugely useful to make the bus
>>> transparent to admins.
>>
>> I've heard the following use cases for per-connection metadata:
>>
>> - Authenticating to dbus1 services.
>
>Not necessarily authentication, but we need to support the legacy API,
>for whatever reason it was used by old applications. But..
>
>> - Identifying connected users for admin diagnostics.
>>
>> I've heard the following use cases for per-message metadata:
>>
>> - Logging.
>>
>> - Authenticating to kdbus services that want this style of
>authentication.
>
>..please note that authentication on DBus has always been done with
>per-message metadata (see polkit history). However, this had to be
>reverted some years ago as it is racy (it used /proc for that, which
>can be exploited by exec'ing setuid binaries). However, the
>per-message metadata authentication worked very well for _years_
>(minus the race..), so this is already a well-established scheme. With
>kdbus we can finally implement this in a race-free manner.
>
>[...]
>> This is simply not okay for a modern interface, and in my opinion the
>> kernel should not carry code to support new APIs with weakly defined
>> security semantics. It's important that one be able to tell what the
>> security implications of one's code is without cross-referencing with
>> the implementation of the server's you're interacting with.
>
>Again, I disagree. Our concepts are established and used on UDS and
>DBus for decades.
>
>Yes, we provide two ways to retrieve metadata, but the kernel offers
>several more paths to gather that information. Just because those APIs
>are available does not mean they should be used for authentication. We
>mandate per-message metadata. If applications use per-connection
>metadata, /proc, netlink, or random data, they're doing it wrong.
>
>Furthermore, dbus provides pretty complete and straightforward
>libraries which hide that from you. If you use glib, qt or sd-bus, you
>don't even need to deal with all that.
>
>> To top that off, the kdbus policy mechanism has truly bizarre effects
>> with respect to services that have unique ids and well-known names.
>> That, too, is apparently for compatibility.
>>
>> This all feels to me like a total of about four people are going to
>> understand the tangle that is kdbus security, and that's bad. I
>think
>> that the kernel should insist that new security-critical mechanisms
>> make sense and be hard to misuse. The current design of kdbus, in
>> contrast, feel like it will be very hard to use correctly.
>
>Native kdbus clients are authenticated with their credentials at time
>of method call. Legacy clients will always have their credentials at
>time of connect in effect. No fallbacks, no choices. It's a simple
>question whether it's a legacy client or not.
>Sounds simple to me.
So I just took a slightly deeper look and the user namespace bits are wrong. Both in implementation
and in design.
Passing "capabilities" to user space for reasons of authentication is wrong and a maintenance nightmare. Further the capabilities maintainer Serge Hallyn has not been copied.
There are several other pieces of information in your meta data like cmdline that I have similar concerns about, but are I am less familiar with, and have looked at less.
Which leads my to conclude that in its current form kdbus is inappropriate for inclusion in the kernel.
The code is dangerously and inappropriately wrong and comes with a huge maintenance obligation to people outside of kdbus.
Nacked-by: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org
The only way I can see this code being responsibly merged is for all if the metadata to be thrown out. The basics merged and then one small piece at a time with copious review and explanation the metadata be added back in.
If you can not throw out the meta data the kdbus code is too broken in concept to warrant serious consideration.
Eric
^ permalink raw reply
* Re: [PATCH v4 00/14] Add kdbus implementation
From: Greg Kroah-Hartman @ 2015-04-05 13:46 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Herrmann, Andy Lutomirski, Tom Gundersen, Arnd Bergmann,
One Thousand Gnomes, Jiri Kosina, Linux API,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Daniel Mack,
Djalal Harouni
In-Reply-To: <FFF43E89-B796-4BDE-893A-5CC2AE77AED7-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On Sun, Apr 05, 2015 at 07:09:16AM -0500, Eric W. Biederman wrote:
>
>
> On April 3, 2015 6:51:34 AM CDT, David Herrmann <dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >Hi
> >
> >On Tue, Mar 31, 2015 at 8:29 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
> >wrote:
> >> On Tue, Mar 31, 2015 at 8:10 AM, Tom Gundersen <teg-B22kvLQNl6c@public.gmane.org> wrote:
> >>> On Tue, Mar 31, 2015 at 3:58 PM, Andy Lutomirski
> ><luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
> >>>>
> >>>> IOW you're taking something that you dislike aspects of and shoving
> >>>> most of it in the kernel. That guarantees us an API in the kernel
> >>>> that even the creators don't really like. This is, IMO, very
> >>>> unfortunate.
> >>>
> >>> This is a misrepresentation of what David wrote. We do want this API
> >>> regardless of dbus1 compatibility, but compatibility is by itself a
> >>> sufficient motivation. A further motivation is reliable
> >introspection,
> >>> since this meta-data allows listing current peers on the bus and
> >>> showing their identities. That's hugely useful to make the bus
> >>> transparent to admins.
> >>
> >> I've heard the following use cases for per-connection metadata:
> >>
> >> - Authenticating to dbus1 services.
> >
> >Not necessarily authentication, but we need to support the legacy API,
> >for whatever reason it was used by old applications. But..
> >
> >> - Identifying connected users for admin diagnostics.
> >>
> >> I've heard the following use cases for per-message metadata:
> >>
> >> - Logging.
> >>
> >> - Authenticating to kdbus services that want this style of
> >authentication.
> >
> >..please note that authentication on DBus has always been done with
> >per-message metadata (see polkit history). However, this had to be
> >reverted some years ago as it is racy (it used /proc for that, which
> >can be exploited by exec'ing setuid binaries). However, the
> >per-message metadata authentication worked very well for _years_
> >(minus the race..), so this is already a well-established scheme. With
> >kdbus we can finally implement this in a race-free manner.
> >
> >[...]
> >> This is simply not okay for a modern interface, and in my opinion the
> >> kernel should not carry code to support new APIs with weakly defined
> >> security semantics. It's important that one be able to tell what the
> >> security implications of one's code is without cross-referencing with
> >> the implementation of the server's you're interacting with.
> >
> >Again, I disagree. Our concepts are established and used on UDS and
> >DBus for decades.
> >
> >Yes, we provide two ways to retrieve metadata, but the kernel offers
> >several more paths to gather that information. Just because those APIs
> >are available does not mean they should be used for authentication. We
> >mandate per-message metadata. If applications use per-connection
> >metadata, /proc, netlink, or random data, they're doing it wrong.
> >
> >Furthermore, dbus provides pretty complete and straightforward
> >libraries which hide that from you. If you use glib, qt or sd-bus, you
> >don't even need to deal with all that.
> >
> >> To top that off, the kdbus policy mechanism has truly bizarre effects
> >> with respect to services that have unique ids and well-known names.
> >> That, too, is apparently for compatibility.
> >>
> >> This all feels to me like a total of about four people are going to
> >> understand the tangle that is kdbus security, and that's bad. I
> >think
> >> that the kernel should insist that new security-critical mechanisms
> >> make sense and be hard to misuse. The current design of kdbus, in
> >> contrast, feel like it will be very hard to use correctly.
> >
> >Native kdbus clients are authenticated with their credentials at time
> >of method call. Legacy clients will always have their credentials at
> >time of connect in effect. No fallbacks, no choices. It's a simple
> >question whether it's a legacy client or not.
> >Sounds simple to me.
>
> So I just took a slightly deeper look and the user namespace bits are wrong. Both in implementation
> and in design.
>
> Passing "capabilities" to user space for reasons of authentication is wrong and a maintenance nightmare. Further the capabilities maintainer Serge Hallyn has not been copied.
I don't understand, where are passed that are not already exported today
through /proc/ already? kdbus gathers this information in a race-free
way, unlike having to dig this out of proc and hope that nothing has
changed underneath you.
> There are several other pieces of information in your meta data like cmdline that I have similar concerns about, but are I am less familiar with, and have looked at less.
Again, cmdline is also exported today, why is passing that somehow not
acceptable?
> Which leads my to conclude that in its current form kdbus is inappropriate for inclusion in the kernel.
Ah, so we should also remove those fields from /proc/ today as well, and
just break all of userspace that relies on it today? Again, kdbus is
just doing the same thing that userspace is doing today, but in a
race-free manner.
> The code is dangerously and inappropriately wrong and comes with a huge maintenance obligation to people outside of kdbus.
How so? Please explain.
Oh, and please wrap your email properly, reading it this way is a
horrible experience, you know better than that...
greg k-h
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Milosz Tanski @ 2015-04-06 3:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, Jeremy Allison, LKML,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-aio-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Mel Gorman,
Volker Lendecke, Tejun Heo, Jeff Moyer, Theodore Ts'o,
Al Viro, Linux API, Michael Kerrisk,
linux-arch-u79uwXL29TY76Z2rM5mHXA, Dave Chinner
In-Reply-To: <20150403204209.75405f37.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
On Fri, Apr 3, 2015 at 11:42 PM, Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> On Mon, 30 Mar 2015 13:26:25 -0700 Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>> d) fincore() is more expensive
>
> Actually, I kinda take that back. fincore() will be faster than
> preadv2() in the case of a pagecache miss, and slower in the case of a
> pagecache hit.
>
> The breakpoint appears to be a hit rate of 30% - if fewer than 30% of
> queries find the page in pagecache, fincore() will be faster than
> preadv2().
In my application (motivation for this patch), web-serving
applications (familiar to me), and Samba I'm going to that the
majority of requests are going to be cached. Only some small
percentage will be uncached (say 20%). I'll add to that: a small
percentage but of a large number.
A lot of IO falls into zipfan / sequential pattern. And that makes
send to me a small number of frequently access files and large
streaming data (with read ahead).
>
> This is because for a pagecache miss, fincore() will be about twice as
> fast as preadv2(). For a pagecache hit, fincore()+pread() is 55%
> slower than preadv2(). If there are lots of misses, fincore() is
> faster overall.
>
>
>
>
> Minimal fincore() implementation is below. It doesn't implement the
> page_map!=NULL mode at all and will be slow for large areas - it needs
> to be taught about radix_tree_for_each_*(). But it's good enough for
> testing.
I'm glad you took the time to do this. It's simple, but your
implementation is much cleaner then the last round of fincore() from 3
years back.
>
> On a slow machine, in nanoseconds:
>
> null syscall: 528
> fincore (miss): 674
> fincore (hit): 729
> single byte pread: 1026
> single byte preadv: 1134
I'm not surprised, fincore() doesn't have to go through all the vfs /
fs machinery that pread or preadv do. By chance if you compare pread /
preadv with a larger read (say 4k) is the difference negligible.
>
> pread() is a bit faster than preadv() and samba uses pread(), so the
> implementations are:
>
> if (fincore(fd, NULL, offset, len) == len)
> pread();
> else
> punt();
>
> if (preadv2(fd, ..., offset, len) == len)
> ...
> else
> punt();
>
> fincore+pread, pagecache-hit: 1755ns
> fincore+pread, pagecache-miss: 674ns
> preadv(): 1134ns (preadv2() will be a little faster for misses)
>
>
>
> Now, a pagecache hit rate of 30% sounds high so one would think that
> fincore+pread is clearly ahead. But the pagecache hit rate in this
> code will actually be quite high, because of readahead.
>
> For a large linear read of a file which is perfectly laid out on disk
> and is fully *uncached*, the hit rates will be as good as 99.8%,
> because readahead is bringing in data in 2MB blobs.
>
> In practice I expect that fincore()+pread() will be slower for linear
> reads of medium to large files and faster for small files and seeky
> accesses.
>
> How much does all this matter? Not much. On a fast machine a
> single-byte pread() takes 240ns. So if your server thread is handling
> 25000 requests/sec, we're only talking 0.6% overhead.
>
> Note that we can trivially monitor the hit rate with either preadv2()
> or fincore()+pread(): just count how many times all the data is there
> versus how many times it isn't.
>
>
>
> Also, note that we can use *both* fincore() and preadv2() to detect the
> problematic page-just-disappeared race:
>
> if (fincore(fd, NULL, offset, len) == len) {
> if (preadv2(fd, offset, len) != len)
> printf("race just happened");
>
> It would be great if someone could apply the below, modify the
> preadv2() callsite as above and determine under what conditions (if
> any) the page-stealing race occurs.
>
>
Let me see what I can do.
>
> arch/x86/syscalls/syscall_64.tbl | 1
> include/linux/syscalls.h | 2
> mm/Makefile | 2
> mm/fincore.c | 65 +++++++++++++++++++++++++++++
> 4 files changed, 69 insertions(+), 1 deletion(-)
>
> diff -puN arch/x86/syscalls/syscall_64.tbl~fincore arch/x86/syscalls/syscall_64.tbl
> --- a/arch/x86/syscalls/syscall_64.tbl~fincore
> +++ a/arch/x86/syscalls/syscall_64.tbl
> @@ -331,6 +331,7 @@
> 322 64 execveat stub_execveat
> 323 64 preadv2 sys_preadv2
> 324 64 pwritev2 sys_pwritev2
> +325 common fincore sys_fincore
>
> #
> # x32-specific system call numbers start at 512 to avoid cache impact
> diff -puN include/linux/syscalls.h~fincore include/linux/syscalls.h
> --- a/include/linux/syscalls.h~fincore
> +++ a/include/linux/syscalls.h
> @@ -880,6 +880,8 @@ asmlinkage long sys_process_vm_writev(pi
> asmlinkage long sys_kcmp(pid_t pid1, pid_t pid2, int type,
> unsigned long idx1, unsigned long idx2);
> asmlinkage long sys_finit_module(int fd, const char __user *uargs, int flags);
> +asmlinkage long sys_fincore(int fd, unsigned char __user *page_map,
> + loff_t offset, size_t len);
> asmlinkage long sys_seccomp(unsigned int op, unsigned int flags,
> const char __user *uargs);
> asmlinkage long sys_getrandom(char __user *buf, size_t count,
> diff -puN mm/Makefile~fincore mm/Makefile
> --- a/mm/Makefile~fincore
> +++ a/mm/Makefile
> @@ -19,7 +19,7 @@ obj-y := filemap.o mempool.o oom_kill.
> readahead.o swap.o truncate.o vmscan.o shmem.o \
> util.o mmzone.o vmstat.o backing-dev.o \
> mm_init.o mmu_context.o percpu.o slab_common.o \
> - compaction.o vmacache.o \
> + compaction.o vmacache.o fincore.o \
> interval_tree.o list_lru.o workingset.o \
> debug.o $(mmu-y)
>
> diff -puN /dev/null mm/fincore.c
> --- /dev/null
> +++ a/mm/fincore.c
> @@ -0,0 +1,65 @@
> +#include <linux/syscalls.h>
> +#include <linux/pagemap.h>
> +#include <linux/file.h>
> +#include <linux/fs.h>
> +#include <linux/mm.h>
> +#include <linux/slab.h>
> +#include <linux/hugetlb.h>
> +
> +SYSCALL_DEFINE4(fincore, int, fd, unsigned char __user *, page_map,
> + loff_t, offset, size_t, len)
> +{
> + struct fd f;
> + struct address_space *mapping;
> + loff_t cur_off;
> + loff_t end;
> + pgoff_t pgoff;
> + long ret = 0;
> +
> + if (offset < 0 || (ssize_t)len <= 0)
> + return -EINVAL;
> +
> + f = fdget(fd);
> +
> + if (!f.file)
> + return -EBADF;
> +
> + if (is_file_hugepages(f.file)) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + if (!S_ISREG(file_inode(f.file)->i_mode)) {
> + ret = -EBADF;
> + goto out;
> + }
> +
> + end = min_t(loff_t, offset + len, i_size_read(file_inode(f.file)));
> + pgoff = offset >> PAGE_CACHE_SHIFT;
> + mapping = f.file->f_mapping;
> +
> + /*
> + * We probably need to do somethnig here to reduce the chance of the
> + * pages being reclaimed between fincore() and read(). eg,
> + * SetPageReferenced(page) or mark_page_accessed(page) or
> + * activate_page(page).
> + */
> + for (cur_off = offset; cur_off < end ; ) {
> + struct page *page;
> + loff_t end_of_coverage;
> +
> + page = find_get_page(mapping, pgoff);
> + if (!page || !PageUptodate(page))
> + break;
> + page_cache_release(page);
> +
> + pgoff++;
> + end_of_coverage = min_t(loff_t, pgoff << PAGE_CACHE_SHIFT, end);
> + ret += end_of_coverage - cur_off;
> + cur_off = (cur_off + PAGE_CACHE_SIZE) & PAGE_CACHE_MASK;
> + }
> +
> +out:
> + fdput(f);
> + return ret;
> +}
> _
>
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: milosz-B5zB6C1i6pkAvxtiuMwx3w@public.gmane.org
^ permalink raw reply
* Re: [PATCH v2 7/7] clone4: Add a CLONE_FD flag to get task exit notification via fd
From: Sergey Senozhatsky @ 2015-04-06 8:30 UTC (permalink / raw)
To: Josh Triplett
Cc: Al Viro, Andrew Morton, Andy Lutomirski, Ingo Molnar, Kees Cook,
Oleg Nesterov, Paul E. McKenney, H. Peter Anvin, Rik van Riel,
Thomas Gleixner, Michael Kerrisk, Thiago Macieira,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <fdec4b70c7cd34e2eacf6a0e41d36f606a696da1.1426376419.git.josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org>
On (03/15/15 01:00), Josh Triplett wrote:
[..]
> +
> +/* Handle the CLONE_FD case for copy_process. */
> +int clonefd_do_clone(u64 clone_flags, struct task_struct *p,
> + struct clone4_args *args, struct clonefd_setup *setup)
> +{
> + int flags;
> + struct file *file;
> + int fd;
> +
> + p->clonefd = !!(clone_flags & CLONE_FD);
> + if (!p->clonefd)
> + return 0;
> +
> + if (args->clonefd_flags & ~(O_CLOEXEC | O_NONBLOCK))
> + return -EINVAL;
> +
> + init_waitqueue_head(&p->clonefd_wqh);
> +
> + get_task_struct(p);
> + flags = O_RDONLY | FMODE_ATOMIC_POS | args->clonefd_flags;
> + file = anon_inode_getfile("[process]", &clonefd_fops, p, flags);
> + if (IS_ERR(file)) {
> + put_task_struct(p);
> + return PTR_ERR(file);
> + }
> +
> + fd = get_unused_fd_flags(flags);
> + if (fd < 0) {
+ put_task_struct(p); ?
> + fput(file);
> + return fd;
> + }
> +
> + setup->fd = fd;
> + setup->file = file;
> + return 0;
> +}
[..]
-ss
^ permalink raw reply
* Re: [PATCH v2 7/7] clone4: Add a CLONE_FD flag to get task exit notification via fd
From: Josh Triplett @ 2015-04-06 9:31 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Al Viro, Andrew Morton, Andy Lutomirski, Ingo Molnar, Kees Cook,
Oleg Nesterov, Paul E. McKenney, H. Peter Anvin, Rik van Riel,
Thomas Gleixner, Michael Kerrisk, Thiago Macieira,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20150406083035.GA16373@swordfish>
On Mon, Apr 06, 2015 at 05:30:35PM +0900, Sergey Senozhatsky wrote:
> On (03/15/15 01:00), Josh Triplett wrote:
> [..]
> > +
> > +/* Handle the CLONE_FD case for copy_process. */
> > +int clonefd_do_clone(u64 clone_flags, struct task_struct *p,
> > + struct clone4_args *args, struct clonefd_setup *setup)
> > +{
> > + int flags;
> > + struct file *file;
> > + int fd;
> > +
> > + p->clonefd = !!(clone_flags & CLONE_FD);
> > + if (!p->clonefd)
> > + return 0;
> > +
> > + if (args->clonefd_flags & ~(O_CLOEXEC | O_NONBLOCK))
> > + return -EINVAL;
> > +
> > + init_waitqueue_head(&p->clonefd_wqh);
> > +
> > + get_task_struct(p);
> > + flags = O_RDONLY | FMODE_ATOMIC_POS | args->clonefd_flags;
> > + file = anon_inode_getfile("[process]", &clonefd_fops, p, flags);
> > + if (IS_ERR(file)) {
> > + put_task_struct(p);
> > + return PTR_ERR(file);
> > + }
> > +
> > + fd = get_unused_fd_flags(flags);
> > + if (fd < 0) {
>
> + put_task_struct(p); ?
No, once anon_inode_getfile has succeeded, the file owns the reference
to the task_struct, so fput(file) will call the release function which
calls put_task_struct. Only the failure case for anon_inode_getfile
needs to call put_task_struct directly.
> > + fput(file);
> > + return fd;
> > + }
- Josh Triplett
^ permalink raw reply
* Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework
From: Matt Porter @ 2015-04-06 13:32 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
Greg Kroah-Hartman, s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Mark Brown, Kumar Gala, Maxime Ripard,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1427752679-17261-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, Mar 30, 2015 at 10:57:59PM +0100, Srinivas Kandagatla wrote:
> This patch adds bindings for simple eeprom framework which allows eeprom
> consumers to talk to eeprom providers to get access to eeprom cell data.
>
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> [Maxime Ripard: intial version of eeprom framework]
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/eeprom/eeprom.txt | 58 ++++++++++++++++++++++
> 1 file changed, 58 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
>
> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> new file mode 100644
> index 0000000..fb71d46
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> @@ -0,0 +1,58 @@
> += EEPROM Data Device Tree Bindings =
> +
> +This binding is intended to represent the location of hardware
> +configuration data stored in EEPROMs.
> +
> +On a significant proportion of boards, the manufacturer has stored
> +some data on an EEPROM-like device, for the OS to be able to retrieve
> +these information and act upon it. Obviously, the OS has to know
> +about where to retrieve these data from, and where they are stored on
> +the storage device.
Since this binding (and the kernel framework supporting it) describes
non-volatile memory devices other than EEPROMs (e.g. EFuses) it should
be named more generically like "nvmem".
> +
> +This document is here to document this.
> +
> += Data providers =
> +Contains bindings specific to provider drivers and data cells as children
> +to this node.
> +
> += Data cells =
> +These are the child nodes of the provider which contain data cell
> +information like offset and size in eeprom provider.
> +
> +Required properties:
> +reg: specifies the offset in byte within that storage device, and the length
> + in bytes of the data we care about.
> + There could be more then one offset-length pairs in this property.
> +
> +Optional properties:
> +As required by specific data parsers/interpreters.
The generic binding could really use a "read-only" property here as this
is a common hardware attribute for many nvmem devices. A serial EEPROM
commonly has a write protect pin which may be hard-wired such that the
hardware description should reflect that. An EFuse is typically blown with
the required information at manufacturing time (for an end product case)
and would be marked with the "read-only" flag.
Having this optional flag in the generic binding would allow the
framework to hint to consumers about the inability to write to the
provided region.
The framework sysfs attributes provide a userspace EEPROM consumer where
it would be useful information to know that a data provider region is
read only rather than having the exported writeable attribute simply
fail a write cycle. This would allow the consumer to be aware that a
failed write (if even attempted) is expected if the data provider
advertised itself as read-only.
-Matt
> +
> +For example:
> +
> + /* Provider */
> + qfprom: qfprom@00700000 {
> + compatible = "qcom,qfprom";
> + reg = <0x00700000 0x8000>;
> + ...
> +
> + /* Data cells */
> + tsens_calibration: calib@4404 {
> + reg = <0x4404 0x10>;
> + };
> +
> + serial_number: sn {
> + reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>;
> +
> + };
> + ...
> + };
> +
> += Data consumers =
> +Are device nodes which consume eeprom data cells.
> +
> +For example:
> +
> + tsens {
> + ...
> + calibration = <&tsens_calibration>;
> + };
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] sunrpc: eliminate RPC_DEBUG
From: Mark Salter @ 2015-04-06 13:46 UTC (permalink / raw)
To: Trond Myklebust, Anna Schumaker
Cc: Jeff Layton, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Mark Salter
Commit f895b252d4edf ("sunrpc: eliminate RPC_DEBUG") introduced
use of IS_ENABLED() in a uapi header which leads to a build
failure for userspace apps trying to use <linux/nfsd/debug.h>:
linux/nfsd/debug.h:18:15: error: missing binary operator before token "("
#if IS_ENABLED(CONFIG_SUNRPC_DEBUG)
^
Since this was only used to define NFSD_DEBUG if CONFIG_SUNRPC_DEBUG
is enabled, replace instances of NFSD_DEBUG with CONFIG_SUNRPC_DEBUG.
Signed-off-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
fs/lockd/svcsubs.c | 2 +-
fs/nfsd/nfs4state.c | 2 +-
fs/nfsd/nfsd.h | 2 +-
include/uapi/linux/nfsd/debug.h | 8 --------
4 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/fs/lockd/svcsubs.c b/fs/lockd/svcsubs.c
index 665ef5a..a563ddb 100644
--- a/fs/lockd/svcsubs.c
+++ b/fs/lockd/svcsubs.c
@@ -31,7 +31,7 @@
static struct hlist_head nlm_files[FILE_NRHASH];
static DEFINE_MUTEX(nlm_file_mutex);
-#ifdef NFSD_DEBUG
+#ifdef CONFIG_SUNRPC_DEBUG
static inline void nlm_debug_print_fh(char *msg, struct nfs_fh *f)
{
u32 *fhp = (u32*)f->data;
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 26e9baa..d42786e 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -1139,7 +1139,7 @@ hash_sessionid(struct nfs4_sessionid *sessionid)
return sid->sequence % SESSION_HASH_SIZE;
}
-#ifdef NFSD_DEBUG
+#ifdef CONFIG_SUNRPC_DEBUG
static inline void
dump_sessionid(const char *fn, struct nfs4_sessionid *sessionid)
{
diff --git a/fs/nfsd/nfsd.h b/fs/nfsd/nfsd.h
index 565c4da..cf98052 100644
--- a/fs/nfsd/nfsd.h
+++ b/fs/nfsd/nfsd.h
@@ -24,7 +24,7 @@
#include "export.h"
#undef ifdebug
-#ifdef NFSD_DEBUG
+#ifdef CONFIG_SUNRPC_DEBUG
# define ifdebug(flag) if (nfsd_debug & NFSDDBG_##flag)
#else
# define ifdebug(flag) if (0)
diff --git a/include/uapi/linux/nfsd/debug.h b/include/uapi/linux/nfsd/debug.h
index 0bf130a..28ec6c9 100644
--- a/include/uapi/linux/nfsd/debug.h
+++ b/include/uapi/linux/nfsd/debug.h
@@ -12,14 +12,6 @@
#include <linux/sunrpc/debug.h>
/*
- * Enable debugging for nfsd.
- * Requires RPC_DEBUG.
- */
-#if IS_ENABLED(CONFIG_SUNRPC_DEBUG)
-# define NFSD_DEBUG 1
-#endif
-
-/*
* knfsd debug flags
*/
#define NFSDDBG_SOCK 0x0001
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] sunrpc: eliminate RPC_DEBUG
From: Jeff Layton @ 2015-04-06 14:04 UTC (permalink / raw)
To: Mark Salter
Cc: Trond Myklebust, Anna Schumaker, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1428327960-22213-1-git-send-email-msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
nit: title should probably be "sunrpc: eliminate NFSD_DEBUG"
On Mon, 6 Apr 2015 09:46:00 -0400
Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> Commit f895b252d4edf ("sunrpc: eliminate RPC_DEBUG") introduced
> use of IS_ENABLED() in a uapi header which leads to a build
> failure for userspace apps trying to use <linux/nfsd/debug.h>:
>
> linux/nfsd/debug.h:18:15: error: missing binary operator before token "("
> #if IS_ENABLED(CONFIG_SUNRPC_DEBUG)
> ^
>
> Since this was only used to define NFSD_DEBUG if CONFIG_SUNRPC_DEBUG
> is enabled, replace instances of NFSD_DEBUG with CONFIG_SUNRPC_DEBUG.
>
> Signed-off-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> fs/lockd/svcsubs.c | 2 +-
> fs/nfsd/nfs4state.c | 2 +-
> fs/nfsd/nfsd.h | 2 +-
> include/uapi/linux/nfsd/debug.h | 8 --------
> 4 files changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/fs/lockd/svcsubs.c b/fs/lockd/svcsubs.c
> index 665ef5a..a563ddb 100644
> --- a/fs/lockd/svcsubs.c
> +++ b/fs/lockd/svcsubs.c
> @@ -31,7 +31,7 @@
> static struct hlist_head nlm_files[FILE_NRHASH];
> static DEFINE_MUTEX(nlm_file_mutex);
>
> -#ifdef NFSD_DEBUG
> +#ifdef CONFIG_SUNRPC_DEBUG
Technically, you should use #if IS_ENABLED(CONFIG_SUNRPC_DEBUG). That's
supposed to help the compiler do checking of the code inside the block
even when it's not defined.
In some cases though, that doesn't work correctly and you may need to
use plain-old #ifdef if not (particularly if there are symbols that
don't exist and are referenced inside the block when
CONFIG_SUNRPC_DEBUG isn't defined).
The CodingStyle document has a little blurb on this, fwiw...
> static inline void nlm_debug_print_fh(char *msg, struct nfs_fh *f)
> {
> u32 *fhp = (u32*)f->data;
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index 26e9baa..d42786e 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -1139,7 +1139,7 @@ hash_sessionid(struct nfs4_sessionid *sessionid)
> return sid->sequence % SESSION_HASH_SIZE;
> }
>
> -#ifdef NFSD_DEBUG
> +#ifdef CONFIG_SUNRPC_DEBUG
> static inline void
> dump_sessionid(const char *fn, struct nfs4_sessionid *sessionid)
> {
> diff --git a/fs/nfsd/nfsd.h b/fs/nfsd/nfsd.h
> index 565c4da..cf98052 100644
> --- a/fs/nfsd/nfsd.h
> +++ b/fs/nfsd/nfsd.h
> @@ -24,7 +24,7 @@
> #include "export.h"
>
> #undef ifdebug
> -#ifdef NFSD_DEBUG
> +#ifdef CONFIG_SUNRPC_DEBUG
> # define ifdebug(flag) if (nfsd_debug & NFSDDBG_##flag)
> #else
> # define ifdebug(flag) if (0)
> diff --git a/include/uapi/linux/nfsd/debug.h b/include/uapi/linux/nfsd/debug.h
> index 0bf130a..28ec6c9 100644
> --- a/include/uapi/linux/nfsd/debug.h
> +++ b/include/uapi/linux/nfsd/debug.h
> @@ -12,14 +12,6 @@
> #include <linux/sunrpc/debug.h>
>
> /*
> - * Enable debugging for nfsd.
> - * Requires RPC_DEBUG.
> - */
> -#if IS_ENABLED(CONFIG_SUNRPC_DEBUG)
> -# define NFSD_DEBUG 1
> -#endif
> -
> -/*
> * knfsd debug flags
> */
> #define NFSDDBG_SOCK 0x0001
Looks fine other than the two nits above...
Acked-by: Jeff Layton <jeff.layton-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework
From: Rob Herring @ 2015-04-06 14:11 UTC (permalink / raw)
To: Matt Porter
Cc: Srinivas Kandagatla,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Arnd Bergmann,
Greg Kroah-Hartman, Sascha Hauer, Stephen Boyd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Mark Brown, Kumar Gala, Maxime Ripard,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-msm
In-Reply-To: <20150406133208.GH30984@beef>
On Mon, Apr 6, 2015 at 8:32 AM, Matt Porter <mporter-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote:
> On Mon, Mar 30, 2015 at 10:57:59PM +0100, Srinivas Kandagatla wrote:
>> This patch adds bindings for simple eeprom framework which allows eeprom
>> consumers to talk to eeprom providers to get access to eeprom cell data.
>>
>> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> [Maxime Ripard: intial version of eeprom framework]
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> .../devicetree/bindings/eeprom/eeprom.txt | 58 ++++++++++++++++++++++
>> 1 file changed, 58 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
>>
>> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> new file mode 100644
>> index 0000000..fb71d46
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> @@ -0,0 +1,58 @@
>> += EEPROM Data Device Tree Bindings =
>> +
>> +This binding is intended to represent the location of hardware
>> +configuration data stored in EEPROMs.
>> +
>> +On a significant proportion of boards, the manufacturer has stored
>> +some data on an EEPROM-like device, for the OS to be able to retrieve
>> +these information and act upon it. Obviously, the OS has to know
>> +about where to retrieve these data from, and where they are stored on
>> +the storage device.
>
> Since this binding (and the kernel framework supporting it) describes
> non-volatile memory devices other than EEPROMs (e.g. EFuses) it should
> be named more generically like "nvmem".
>
>> +
>> +This document is here to document this.
>> +
>> += Data providers =
>> +Contains bindings specific to provider drivers and data cells as children
>> +to this node.
>> +
>> += Data cells =
>> +These are the child nodes of the provider which contain data cell
>> +information like offset and size in eeprom provider.
>> +
>> +Required properties:
>> +reg: specifies the offset in byte within that storage device, and the length
>> + in bytes of the data we care about.
>> + There could be more then one offset-length pairs in this property.
>> +
>> +Optional properties:
>> +As required by specific data parsers/interpreters.
>
> The generic binding could really use a "read-only" property here as this
> is a common hardware attribute for many nvmem devices. A serial EEPROM
> commonly has a write protect pin which may be hard-wired such that the
> hardware description should reflect that. An EFuse is typically blown with
> the required information at manufacturing time (for an end product case)
> and would be marked with the "read-only" flag.
>
> Having this optional flag in the generic binding would allow the
> framework to hint to consumers about the inability to write to the
> provided region.
This could get fairly complex if you wanted to describe grouping of WP
regions which could have different layout than the fields here. This
may be better left as a device property listing addr & size pairs.
However, there is the notion of s/w "read-only" which means the OS
should not allow write access. The MTD partition binding supports this
with the "read-only" property.
> The framework sysfs attributes provide a userspace EEPROM consumer where
> it would be useful information to know that a data provider region is
> read only rather than having the exported writeable attribute simply
> fail a write cycle. This would allow the consumer to be aware that a
> failed write (if even attempted) is expected if the data provider
> advertised itself as read-only.
You could distinguish with RW versus RO file attributes.
Rob
^ permalink raw reply
* Re: [PATCH] sunrpc: eliminate RPC_DEBUG
From: Mark Salter @ 2015-04-06 14:13 UTC (permalink / raw)
To: Jeff Layton
Cc: Trond Myklebust, Anna Schumaker, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150406100452.402754a6-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On Mon, 2015-04-06 at 10:04 -0400, Jeff Layton wrote:
> nit: title should probably be "sunrpc: eliminate NFSD_DEBUG"
*sigh*
Yes, of course. That is what I intended but not what I wrote.
>
> On Mon, 6 Apr 2015 09:46:00 -0400
> Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> > Commit f895b252d4edf ("sunrpc: eliminate RPC_DEBUG") introduced
> > use of IS_ENABLED() in a uapi header which leads to a build
> > failure for userspace apps trying to use <linux/nfsd/debug.h>:
> >
> > linux/nfsd/debug.h:18:15: error: missing binary operator before token "("
> > #if IS_ENABLED(CONFIG_SUNRPC_DEBUG)
> > ^
> >
> > Since this was only used to define NFSD_DEBUG if CONFIG_SUNRPC_DEBUG
> > is enabled, replace instances of NFSD_DEBUG with CONFIG_SUNRPC_DEBUG.
> >
> > Signed-off-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > ---
> > fs/lockd/svcsubs.c | 2 +-
> > fs/nfsd/nfs4state.c | 2 +-
> > fs/nfsd/nfsd.h | 2 +-
> > include/uapi/linux/nfsd/debug.h | 8 --------
> > 4 files changed, 3 insertions(+), 11 deletions(-)
> >
> > diff --git a/fs/lockd/svcsubs.c b/fs/lockd/svcsubs.c
> > index 665ef5a..a563ddb 100644
> > --- a/fs/lockd/svcsubs.c
> > +++ b/fs/lockd/svcsubs.c
> > @@ -31,7 +31,7 @@
> > static struct hlist_head nlm_files[FILE_NRHASH];
> > static DEFINE_MUTEX(nlm_file_mutex);
> >
> > -#ifdef NFSD_DEBUG
> > +#ifdef CONFIG_SUNRPC_DEBUG
>
> Technically, you should use #if IS_ENABLED(CONFIG_SUNRPC_DEBUG). That's
> supposed to help the compiler do checking of the code inside the block
> even when it's not defined.
>
> In some cases though, that doesn't work correctly and you may need to
> use plain-old #ifdef if not (particularly if there are symbols that
> don't exist and are referenced inside the block when
> CONFIG_SUNRPC_DEBUG isn't defined).
>
> The CodingStyle document has a little blurb on this, fwiw...
>
> > static inline void nlm_debug_print_fh(char *msg, struct nfs_fh *f)
> > {
> > u32 *fhp = (u32*)f->data;
> > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > index 26e9baa..d42786e 100644
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
> > @@ -1139,7 +1139,7 @@ hash_sessionid(struct nfs4_sessionid *sessionid)
> > return sid->sequence % SESSION_HASH_SIZE;
> > }
> >
> > -#ifdef NFSD_DEBUG
> > +#ifdef CONFIG_SUNRPC_DEBUG
> > static inline void
> > dump_sessionid(const char *fn, struct nfs4_sessionid *sessionid)
> > {
> > diff --git a/fs/nfsd/nfsd.h b/fs/nfsd/nfsd.h
> > index 565c4da..cf98052 100644
> > --- a/fs/nfsd/nfsd.h
> > +++ b/fs/nfsd/nfsd.h
> > @@ -24,7 +24,7 @@
> > #include "export.h"
> >
> > #undef ifdebug
> > -#ifdef NFSD_DEBUG
> > +#ifdef CONFIG_SUNRPC_DEBUG
> > # define ifdebug(flag) if (nfsd_debug & NFSDDBG_##flag)
> > #else
> > # define ifdebug(flag) if (0)
> > diff --git a/include/uapi/linux/nfsd/debug.h b/include/uapi/linux/nfsd/debug.h
> > index 0bf130a..28ec6c9 100644
> > --- a/include/uapi/linux/nfsd/debug.h
> > +++ b/include/uapi/linux/nfsd/debug.h
> > @@ -12,14 +12,6 @@
> > #include <linux/sunrpc/debug.h>
> >
> > /*
> > - * Enable debugging for nfsd.
> > - * Requires RPC_DEBUG.
> > - */
> > -#if IS_ENABLED(CONFIG_SUNRPC_DEBUG)
> > -# define NFSD_DEBUG 1
> > -#endif
> > -
> > -/*
> > * knfsd debug flags
> > */
> > #define NFSDDBG_SOCK 0x0001
>
> Looks fine other than the two nits above...
>
> Acked-by: Jeff Layton <jeff.layton-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
^ permalink raw reply
* Re: [PATCH] sunrpc: eliminate RPC_DEBUG
From: Arnd Bergmann @ 2015-04-06 14:38 UTC (permalink / raw)
To: Jeff Layton
Cc: Mark Salter, Trond Myklebust, Anna Schumaker,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150406100452.402754a6-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On Monday 06 April 2015 10:04:52 Jeff Layton wrote:
> > diff --git a/fs/lockd/svcsubs.c b/fs/lockd/svcsubs.c
> > index 665ef5a..a563ddb 100644
> > --- a/fs/lockd/svcsubs.c
> > +++ b/fs/lockd/svcsubs.c
> > @@ -31,7 +31,7 @@
> > static struct hlist_head nlm_files[FILE_NRHASH];
> > static DEFINE_MUTEX(nlm_file_mutex);
> >
> > -#ifdef NFSD_DEBUG
> > +#ifdef CONFIG_SUNRPC_DEBUG
>
> Technically, you should use #if IS_ENABLED(CONFIG_SUNRPC_DEBUG). That's
> supposed to help the compiler do checking of the code inside the block
> even when it's not defined.
You probably meant the right thing and wrote something else: you should use
'if (IS_ENABLED(CONFIG_SUNRPC_DEBUG)) { ... }' to get that effect, but that
only works within a function. '#if IS_ENABLED(CONFIG_SUNRPC_DEBUG)' is just
a nicer way to write '#if defined(CONFIG_SUNRPC_DEBUG) ||
defined(CONFIG_SUNRPC_DEBUG_MODULE)', which is harmless but pointless here
as the symbol would never be set to 'm'.
Arnd
^ permalink raw reply
* Re: [PATCH] sunrpc: eliminate RPC_DEBUG
From: Jeff Layton @ 2015-04-06 14:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Salter, Trond Myklebust, Anna Schumaker,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4110847.o7VvYRDU5Z@wuerfel>
On Mon, 06 Apr 2015 16:38:09 +0200
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Monday 06 April 2015 10:04:52 Jeff Layton wrote:
> > > diff --git a/fs/lockd/svcsubs.c b/fs/lockd/svcsubs.c
> > > index 665ef5a..a563ddb 100644
> > > --- a/fs/lockd/svcsubs.c
> > > +++ b/fs/lockd/svcsubs.c
> > > @@ -31,7 +31,7 @@
> > > static struct hlist_head nlm_files[FILE_NRHASH];
> > > static DEFINE_MUTEX(nlm_file_mutex);
> > >
> > > -#ifdef NFSD_DEBUG
> > > +#ifdef CONFIG_SUNRPC_DEBUG
> >
> > Technically, you should use #if IS_ENABLED(CONFIG_SUNRPC_DEBUG). That's
> > supposed to help the compiler do checking of the code inside the block
> > even when it's not defined.
>
> You probably meant the right thing and wrote something else: you should use
> 'if (IS_ENABLED(CONFIG_SUNRPC_DEBUG)) { ... }' to get that effect, but that
> only works within a function. '#if IS_ENABLED(CONFIG_SUNRPC_DEBUG)' is just
> a nicer way to write '#if defined(CONFIG_SUNRPC_DEBUG) ||
> defined(CONFIG_SUNRPC_DEBUG_MODULE)', which is harmless but pointless here
> as the symbol would never be set to 'm'.
>
> Arnd
Ahh ok, good to know. Then this patch is fine as-is then.
Thanks,
--
Jeff Layton <jlayton-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework
From: Matt Porter @ 2015-04-06 15:04 UTC (permalink / raw)
To: Rob Herring
Cc: Srinivas Kandagatla,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Arnd Bergmann,
Greg Kroah-Hartman, Sascha Hauer, Stephen Boyd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Mark Brown, Kumar Gala, Maxime Ripard,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-msm
In-Reply-To: <CAL_Jsq++9pyJMLXssgyz2WRU4e7ikT_6FwzWMo1fKS82FJvEyg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Apr 06, 2015 at 09:11:05AM -0500, Rob Herring wrote:
> On Mon, Apr 6, 2015 at 8:32 AM, Matt Porter <mporter-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote:
> > On Mon, Mar 30, 2015 at 10:57:59PM +0100, Srinivas Kandagatla wrote:
> >> This patch adds bindings for simple eeprom framework which allows eeprom
> >> consumers to talk to eeprom providers to get access to eeprom cell data.
> >>
> >> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> >> [Maxime Ripard: intial version of eeprom framework]
> >> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> ---
> >> .../devicetree/bindings/eeprom/eeprom.txt | 58 ++++++++++++++++++++++
> >> 1 file changed, 58 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> >> new file mode 100644
> >> index 0000000..fb71d46
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> >> @@ -0,0 +1,58 @@
> >> += EEPROM Data Device Tree Bindings =
> >> +
> >> +This binding is intended to represent the location of hardware
> >> +configuration data stored in EEPROMs.
> >> +
> >> +On a significant proportion of boards, the manufacturer has stored
> >> +some data on an EEPROM-like device, for the OS to be able to retrieve
> >> +these information and act upon it. Obviously, the OS has to know
> >> +about where to retrieve these data from, and where they are stored on
> >> +the storage device.
> >
> > Since this binding (and the kernel framework supporting it) describes
> > non-volatile memory devices other than EEPROMs (e.g. EFuses) it should
> > be named more generically like "nvmem".
> >
> >> +
> >> +This document is here to document this.
> >> +
> >> += Data providers =
> >> +Contains bindings specific to provider drivers and data cells as children
> >> +to this node.
> >> +
> >> += Data cells =
> >> +These are the child nodes of the provider which contain data cell
> >> +information like offset and size in eeprom provider.
> >> +
> >> +Required properties:
> >> +reg: specifies the offset in byte within that storage device, and the length
> >> + in bytes of the data we care about.
> >> + There could be more then one offset-length pairs in this property.
> >> +
> >> +Optional properties:
> >> +As required by specific data parsers/interpreters.
> >
> > The generic binding could really use a "read-only" property here as this
> > is a common hardware attribute for many nvmem devices. A serial EEPROM
> > commonly has a write protect pin which may be hard-wired such that the
> > hardware description should reflect that. An EFuse is typically blown with
> > the required information at manufacturing time (for an end product case)
> > and would be marked with the "read-only" flag.
> >
> > Having this optional flag in the generic binding would allow the
> > framework to hint to consumers about the inability to write to the
> > provided region.
>
> This could get fairly complex if you wanted to describe grouping of WP
> regions which could have different layout than the fields here. This
> may be better left as a device property listing addr & size pairs.
> However, there is the notion of s/w "read-only" which means the OS
> should not allow write access. The MTD partition binding supports this
> with the "read-only" property.
Yes, if the backing device has the capability to hw write protect
regions the exported fields overlap those then it does get ugly.
The MTD partition property was the inspiration here so perhaps it's
best to term this as a property indicating how the data region is
used in an implementation.
If it's left as a device property, then a binding with this property
would need to be defined for the Efuse, etc. cases..or a simple-nvmem
binding to handle the various OTP technologies.
> > The framework sysfs attributes provide a userspace EEPROM consumer where
> > it would be useful information to know that a data provider region is
> > read only rather than having the exported writeable attribute simply
> > fail a write cycle. This would allow the consumer to be aware that a
> > failed write (if even attempted) is expected if the data provider
> > advertised itself as read-only.
>
> You could distinguish with RW versus RO file attributes.
Right, that would be preferred, based on the what the data provider
advertises.
-Matt
^ permalink raw reply
* Re: [PATCH] sunrpc: eliminate RPC_DEBUG
From: J. Bruce Fields @ 2015-04-06 18:18 UTC (permalink / raw)
To: Jeff Layton
Cc: Arnd Bergmann, Mark Salter, Trond Myklebust, Anna Schumaker,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150406104536.63b01b09-08S845evdOaAjSkqwZiSMmfYqLom42DlXqFh9Ls21Oc@public.gmane.org>
On Mon, Apr 06, 2015 at 10:45:36AM -0400, Jeff Layton wrote:
> On Mon, 06 Apr 2015 16:38:09 +0200
> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>
> > On Monday 06 April 2015 10:04:52 Jeff Layton wrote:
> > > > diff --git a/fs/lockd/svcsubs.c b/fs/lockd/svcsubs.c
> > > > index 665ef5a..a563ddb 100644
> > > > --- a/fs/lockd/svcsubs.c
> > > > +++ b/fs/lockd/svcsubs.c
> > > > @@ -31,7 +31,7 @@
> > > > static struct hlist_head nlm_files[FILE_NRHASH];
> > > > static DEFINE_MUTEX(nlm_file_mutex);
> > > >
> > > > -#ifdef NFSD_DEBUG
> > > > +#ifdef CONFIG_SUNRPC_DEBUG
> > >
> > > Technically, you should use #if IS_ENABLED(CONFIG_SUNRPC_DEBUG). That's
> > > supposed to help the compiler do checking of the code inside the block
> > > even when it's not defined.
> >
> > You probably meant the right thing and wrote something else: you should use
> > 'if (IS_ENABLED(CONFIG_SUNRPC_DEBUG)) { ... }' to get that effect, but that
> > only works within a function. '#if IS_ENABLED(CONFIG_SUNRPC_DEBUG)' is just
> > a nicer way to write '#if defined(CONFIG_SUNRPC_DEBUG) ||
> > defined(CONFIG_SUNRPC_DEBUG_MODULE)', which is harmless but pointless here
> > as the symbol would never be set to 'm'.
> >
> > Arnd
>
> Ahh ok, good to know. Then this patch is fine as-is then.
Thanks, queueing up for 4.1 and stable.
--b.
^ permalink raw reply
* Re: [PATCH net-next] tc: bpf: add checksum helpers
From: David Miller @ 2015-04-06 20:42 UTC (permalink / raw)
To: ast; +Cc: daniel, jiri, jhs, linux-api, netdev
In-Reply-To: <1427933533-14394-1-git-send-email-ast@plumgrid.com>
From: Alexei Starovoitov <ast@plumgrid.com>
Date: Wed, 1 Apr 2015 17:12:13 -0700
> Commit 608cd71a9c7c ("tc: bpf: generalize pedit action") has added the
> possibility to mangle packet data to BPF programs in the tc pipeline.
> This patch adds two helpers bpf_l3_csum_replace() and bpf_l4_csum_replace()
> for fixing up the protocol checksums after the packet mangling.
>
> It also adds 'flags' argument to bpf_skb_store_bytes() helper to avoid
> unnecessary checksum recomputations when BPF programs adjusting l3/l4
> checksums and documents all three helpers in uapi header.
>
> Moreover, a sample program is added to show how BPF programs can make use
> of the mangle and csum helpers.
>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Applied, thanks.
^ permalink raw reply
* [GIT PULL] kselftest updates for 4.1-rc1
From: Shuah Khan @ 2015-04-06 20:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg Kroah-Hartman,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:KERNEL SELFTEST F...
Hi Linus,
Here is the pull request for Kselftest updates for 4.1-rc1
This is a milestone update in a sense. Several new tests and
install and packaging support is added in this update.
thanks,
-- Shuah
The following changes since commit 9eccca0843205f87c00404b663188b88eb248051:
Linux 4.0-rc3 (2015-03-08 16:09:09 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-4.1-rc1
for you to fetch changes up to 2bfd4d1f8c2bee8b0b8832be0c38d3916713625f:
ftracetest: Do not use usleep directly (2015-04-03 09:16:32 -0600)
----------------------------------------------------------------
linux-kselftest-4.1-rc1
This update adds install and packaging tools developed on top
of back-end shared logic enhancemnets to run and install tests.
In addition several timer tests are added.
- New timer tests from John Stultz
- rtc test from Prarit Bhargava
- Enhancements to un and install tests from Michael Ellerman
- Install and packaging tools from Shuah Khan
- Cross-compilation enablement from Tyler Baker
- A couple of bug fixes.
----------------------------------------------------------------
John Stultz (22):
selftests/timers: Cleanup Makefile to make it easier to add future
tests
selftests/timers: Quiet warning due to lack of return check on brk
selftests/timers: Add nanosleep test from timetest suite
selftests/timers: Add inconsistency-check test from timetests
selftests/timers: Add nsleep-lat test from timetest suite
selftests/timers: Add clock skew estimation test from timetest suite
selftests/timers: Add set-timer-lat test from timetest suite
selftests/timers: Add threaded time inconsistency test from
timetest suite
selftests/timers: Add mqueue latency test from the timetest suite
selftests/timers: Add adjtimex validation test from timetest suite
selftests/timers: Add alarmtimer-suspend test from timetests suite
selftests/timers: Add change_skew test from timetest suite
selftests/timers: Add skew_consistency test from the timetests suite
selftests/timers: Add clocksource-switch test from timetest suite
selftests/timers: Add leap-a-day test from timetest suite
selftests/timers: Add leapcrash test from the timetest suite
selftests/timers: Add set-tai from the timetest suite
selftests/timers: Add set-2038 test from timetest suite
MAINTAINERS: Add selftests/timers to the timekeeping maintainance list
kselftest/timers: Set default threadtest values to simplify
execution scripts
kselftests: timers: Reduce default runtime on inconsistency-check
and set-timer-lat
kselftests: timers: Make set-timer-lat fail more gracefully for
!CAP_WAKE_ALARM
Michael Ellerman (7):
selftests: Introduce minimal shared logic for running tests
selftests: Add install target
selftests/timers: Use shared logic to run and install tests
selftests: Add install support for the powerpc tests
selftests: Set CC using CROSS_COMPILE once in lib.mk
ftracetest: Cope properly with stack tracer not being enabled
ftracetest: Convert exit -1 to exit $FAIL
Namhyung Kim (1):
ftracetest: Do not use usleep directly
Prarit Bhargava (2):
Documentation, split up rtc.txt into documentation and test file
tools, update rtctest.c to verify passage of time
Shuah Khan (4):
selftests: Add kselftest install tool
selftests: Add tool to generate kselftest tar archive
selftests: change cpu on-off-test.sh name to be unique
selftests: Change memory on-off-test.sh name to be unique
Tyler Baker (5):
selftest/memfd: enable cross compilation
selftest/mount: enable cross compilation
selftest/memfd: include default header install path
selftest/ipc: enable cross compilation
selftest/mqueue: enable cross compilation
Zhang Zhen (1):
selftests/mount: Make git ignore all binaries in mount test suite
Documentation/rtc.txt | 264 +----------------
MAINTAINERS | 1 +
tools/testing/selftests/Makefile | 33 +++
tools/testing/selftests/breakpoints/Makefile | 5 +-
tools/testing/selftests/cpu-hotplug/Makefile | 7 +-
.../{on-off-test.sh => cpu-on-off-test.sh} | 0
tools/testing/selftests/efivarfs/Makefile | 7 +-
tools/testing/selftests/efivarfs/efivarfs.sh | 0
tools/testing/selftests/exec/Makefile | 9 +-
tools/testing/selftests/firmware/Makefile | 20 +-
tools/testing/selftests/firmware/fw_filesystem.sh | 0
tools/testing/selftests/firmware/fw_userhelper.sh | 0
tools/testing/selftests/ftrace/Makefile | 5 +-
.../selftests/ftrace/test.d/00basic/basic4.tc | 2 +-
.../selftests/ftrace/test.d/event/event-enable.tc | 15 +-
.../ftrace/test.d/event/subsystem-enable.tc | 15 +-
.../ftrace/test.d/event/toplevel-enable.tc | 15 +-
.../ftrace/test.d/ftrace/fgraph-filter-stack.tc | 6 +-
.../ftrace/test.d/ftrace/fgraph-filter.tc | 2 +-
.../ftrace/test.d/ftrace/func_profiler.tc | 2 +-
tools/testing/selftests/gen_kselftest_tar.sh | 55 ++++
tools/testing/selftests/ipc/Makefile | 11 +-
tools/testing/selftests/kcmp/Makefile | 6 +-
tools/testing/selftests/kselftest_install.sh | 37 +++
tools/testing/selftests/lib.mk | 35 +++
tools/testing/selftests/memfd/Makefile | 14 +-
tools/testing/selftests/memory-hotplug/Makefile | 9 +-
.../{on-off-test.sh => mem-on-off-test.sh} | 0
tools/testing/selftests/mount/.gitignore | 1 +
tools/testing/selftests/mount/Makefile | 15 +-
tools/testing/selftests/mqueue/Makefile | 22 +-
tools/testing/selftests/net/Makefile | 10 +-
tools/testing/selftests/net/run_afpackettests | 0
tools/testing/selftests/net/run_netsocktests | 0
tools/testing/selftests/powerpc/Makefile | 22 +-
tools/testing/selftests/powerpc/copyloops/Makefile | 15 +-
tools/testing/selftests/powerpc/mm/Makefile | 15 +-
tools/testing/selftests/powerpc/pmu/Makefile | 48 ++--
tools/testing/selftests/powerpc/pmu/ebb/Makefile | 13 +-
.../testing/selftests/powerpc/primitives/Makefile | 15 +-
.../testing/selftests/powerpc/stringloops/Makefile | 15 +-
tools/testing/selftests/powerpc/tm/Makefile | 15 +-
tools/testing/selftests/ptrace/Makefile | 5 +-
tools/testing/selftests/size/Makefile | 7 +-
tools/testing/selftests/sysctl/Makefile | 12 +-
tools/testing/selftests/sysctl/run_numerictests | 0
tools/testing/selftests/sysctl/run_stringtests | 0
tools/testing/selftests/timers/Makefile | 38 ++-
.../testing/selftests/timers/alarmtimer-suspend.c | 185 ++++++++++++
tools/testing/selftests/timers/change_skew.c | 107 +++++++
.../testing/selftests/timers/clocksource-switch.c | 179 ++++++++++++
.../testing/selftests/timers/inconsistency-check.c | 204 +++++++++++++
tools/testing/selftests/timers/leap-a-day.c | 319
+++++++++++++++++++++
tools/testing/selftests/timers/leapcrash.c | 120 ++++++++
tools/testing/selftests/timers/mqueue-lat.c | 124 ++++++++
tools/testing/selftests/timers/nanosleep.c | 174 +++++++++++
tools/testing/selftests/timers/nsleep-lat.c | 190 ++++++++++++
tools/testing/selftests/timers/posix_timers.c | 9 +-
tools/testing/selftests/timers/raw_skew.c | 154 ++++++++++
tools/testing/selftests/timers/rtctest.c | 271 +++++++++++++++++
tools/testing/selftests/timers/set-2038.c | 144 ++++++++++
tools/testing/selftests/timers/set-tai.c | 79 +++++
tools/testing/selftests/timers/set-timer-lat.c | 216 ++++++++++++++
tools/testing/selftests/timers/skew_consistency.c | 89 ++++++
tools/testing/selftests/timers/threadtest.c | 204 +++++++++++++
tools/testing/selftests/timers/valid-adjtimex.c | 202 +++++++++++++
tools/testing/selftests/user/Makefile | 5 +-
tools/testing/selftests/vm/Makefile | 7 +-
tools/testing/selftests/vm/run_vmtests | 0
69 files changed, 3366 insertions(+), 459 deletions(-)
rename tools/testing/selftests/cpu-hotplug/{on-off-test.sh =>
cpu-on-off-test.sh} (100%)
mode change 100644 => 100755
mode change 100644 => 100755 tools/testing/selftests/efivarfs/efivarfs.sh
mode change 100644 => 100755
tools/testing/selftests/firmware/fw_filesystem.sh
mode change 100644 => 100755
tools/testing/selftests/firmware/fw_userhelper.sh
create mode 100755 tools/testing/selftests/gen_kselftest_tar.sh
create mode 100755 tools/testing/selftests/kselftest_install.sh
create mode 100644 tools/testing/selftests/lib.mk
rename tools/testing/selftests/memory-hotplug/{on-off-test.sh =>
mem-on-off-test.sh} (100%)
mode change 100644 => 100755
create mode 100644 tools/testing/selftests/mount/.gitignore
mode change 100644 => 100755 tools/testing/selftests/net/run_afpackettests
mode change 100644 => 100755 tools/testing/selftests/net/run_netsocktests
mode change 100644 => 100755
tools/testing/selftests/sysctl/run_numerictests
mode change 100644 => 100755 tools/testing/selftests/sysctl/run_stringtests
create mode 100644 tools/testing/selftests/timers/alarmtimer-suspend.c
create mode 100644 tools/testing/selftests/timers/change_skew.c
create mode 100644 tools/testing/selftests/timers/clocksource-switch.c
create mode 100644 tools/testing/selftests/timers/inconsistency-check.c
create mode 100644 tools/testing/selftests/timers/leap-a-day.c
create mode 100644 tools/testing/selftests/timers/leapcrash.c
create mode 100644 tools/testing/selftests/timers/mqueue-lat.c
create mode 100644 tools/testing/selftests/timers/nanosleep.c
create mode 100644 tools/testing/selftests/timers/nsleep-lat.c
create mode 100644 tools/testing/selftests/timers/raw_skew.c
create mode 100644 tools/testing/selftests/timers/rtctest.c
create mode 100644 tools/testing/selftests/timers/set-2038.c
create mode 100644 tools/testing/selftests/timers/set-tai.c
create mode 100644 tools/testing/selftests/timers/set-timer-lat.c
create mode 100644 tools/testing/selftests/timers/skew_consistency.c
create mode 100644 tools/testing/selftests/timers/threadtest.c
create mode 100644 tools/testing/selftests/timers/valid-adjtimex.c
mode change 100644 => 100755 tools/testing/selftests/vm/run_vmtests
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply
* Re: [PATCH v5 10/15] serial: stm32-usart: Add STM32 USART Driver
From: Maxime Coquelin @ 2015-04-07 7:56 UTC (permalink / raw)
To: Joe Perches
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Philipp Zabel, Linus Walleij, Arnd Bergmann,
Stefan Agner, Peter Meerwald, Paul Bolle, Peter Hurley,
Andy Shevchenko, Chanwoo Choi, Russell King, Daniel Lezcano,
Jonathan Corbet, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Thomas Gleixner, Greg Kroah-Hartman
In-Reply-To: <1428083006.13180.35.camel@perches.com>
2015-04-03 19:43 GMT+02:00 Joe Perches <joe@perches.com>:
> On Fri, 2015-04-03 at 19:01 +0200, Maxime Coquelin wrote:
>> This drivers adds support to the STM32 USART controller, which is a
>> standard serial driver.
>
> trivia:
>
>> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> []
>> +static struct uart_ops stm32_uart_ops = {
>
> could be const
i would even say, should be const.
>
> and it could be updated in a separate patch later too.
>
Nope, I will send another version anyway, so it will be part of the v6.
Thanks for the review,
Maxime
^ permalink raw reply
* [PATCH] selftests/timers: Make git ignore all binaries in timers test suite
From: Zhang Zhen @ 2015-04-07 7:58 UTC (permalink / raw)
To: linux-api-u79uwXL29TY76Z2rM5mHXA; +Cc: shuahkh-JPH+aEBZ4P+UEJcrhfAQsw
In-Reply-To: <1428053591-67246-1-git-send-email-zhenzhang.zhang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
This patch includes the timers test binaries into the .gitignore
file listing in their respective directories. This will make sure
that git ignores all of these test binaries when displaying status.
Signed-off-by: Zhang Zhen <zhenzhang.zhang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
tools/testing/selftests/timers/.gitignore | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 tools/testing/selftests/timers/.gitignore
diff --git a/tools/testing/selftests/timers/.gitignore b/tools/testing/selftests/timers/.gitignore
new file mode 100644
index 0000000..ced9981
--- /dev/null
+++ b/tools/testing/selftests/timers/.gitignore
@@ -0,0 +1,18 @@
+alarmtimer-suspend
+change_skew
+clocksource-switch
+inconsistency-check
+leap-a-day
+leapcrash
+mqueue-lat
+nanosleep
+nsleep-lat
+posix_timers
+raw_skew
+rtctest
+set-2038
+set-tai
+set-timer-lat
+skew_consistency
+threadtest
+valid-adjtimex
--
1.8.5.5
.
^ permalink raw reply related
* Re: [PATCH v2 3/4] Add virtio gpu driver.
From: Gerd Hoffmann @ 2015-04-07 9:41 UTC (permalink / raw)
To: Marc-André Lureau
Cc: virtio-dev, Michael S. Tsirkin, open list:ABI/API, Rusty Russell,
open list, dri-devel, open list:VIRTIO CORE, NET..., David Airlie
In-Reply-To: <CAJ+F1CK3ibbn8e1-rUY4OUJuaCt_=JmuT00Fqx4YDD9M5zJv=A@mail.gmail.com>
On Do, 2015-04-02 at 17:52 +0200, Marc-André Lureau wrote:
> Perhaps that condition should be changed:
> + BUG_ON(size >= MAX_INLINE_CMD_SIZE);
Done.
thanks,
Gerd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [RFC v2 0/3] idle memory tracking
From: Vladimir Davydov @ 2015-04-07 11:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Minchan Kim, Johannes Weiner, Michal Hocko, Greg Thelen,
Michel Lespinasse, David Rientjes, Pavel Emelyanov,
Cyrill Gorcunov, Jonathan Corbet, linux-api, linux-doc, linux-mm,
cgroups, linux-kernel
Hi,
This patch set introduces a new user API for tracking user memory pages
that have not been used for a given period of time. The purpose of this
is to provide the userspace with the means of tracking a workload's
working set, i.e. the set of pages that are actively used by the
workload. Knowing the working set size can be useful for partitioning
the system more efficiently, e.g. by tuning memory cgroup limits
appropriately, or for job placement within a compute cluster.
The API consists of the new read-write proc file, /proc/kpageidle. For
each page this file contains a 64-bit number, which equals 1 if the page
is idle or 0 otherwise. The file is indexed by PFN. To set or clear a
page's Idle flag, one can write 1 or 0 respectively to this file at the
offset corresponding to the page. It is only possible to modify the Idle
flag for user pages (pages that are on an LRU list, to be more exact).
For other page types, the input is silently ignored. Writing to this
file beyond max PFN results in the ENXIO error.
A page's Idle flag is automatically cleared whenever the page is
accessed (via a page table entry or using the read(2) system call).
Thus by setting the Idle flag for pages of a particular workload, which
can be found e.g. by reading /proc/PID/pagemap, waiting for some time to
let the workload access its working set, and then reading the kpageidle
file, one can estimate the amount of pages that are not used by the
workload.
The reason to introduce the new API is that the current API provided by
the kernel, /proc/PID/{clear_refs,smaps} and friends, has two serious
drawbacks:
- it does not count unmapped file pages
- it affects the reclaimer logic
The new API attempts to overcome them both. For more details on this,
please see patch #3.
Apart from /proc/kpageidle, another new proc file is introduced,
/proc/kpagecgroup, which contains the inode number of the memory cgroup
each page is charged to. This file is needed to help estimating the
working set size per cgroup.
An example of using this new API for estimating the number of idle pages
in each memory cgroup is attached below.
Changes in v2:
- The main difference from v1 is the API change. In v1 the user can
only set the idle flag for all pages at once, and for clearing the
Idle flag on pages accessed via page tables /proc/PID/clear_refs
should be used.
The main drawback of the v1 approach, as noted by Minchan, is that on
big machines setting the idle flag for each pages can result in CPU
bursts, which would be especially frustrating if the user only wanted
to estimate the amount of idle pages for a particular process or VMA.
With the new API a more fine-grained approach is possible: one can
read a process's /proc/PID/pagemap and set/check the Idle flag only
for those pages of the process's address space he or she is
interested in.
Another good point about the v2 API is that it is possible to limit
/proc/kpage* scanning rate when the user wants to estimate the total
number of idle pages, which is unachievable with the v1 approach.
- Make /proc/kpagecgroup return the ino of the closest online ancestor
in case the cgroup a page is charged to is offline.
- Fix /proc/PID/clear_refs not clearing Young page flag.
- Rebase on top of v4.0-rc6-mmotm-2015-04-01-14-54
v1 can be found at: https://lwn.net/Articles/637190/
The patch set is organized as follows:
- patch 1 adds page_cgroup_ino() helper for the sake of
/proc/kpagecgroup
- patch 2 adds /proc/kpagecgroup, which reports cgroup ino each page is
charged to
- patch 3 implements the idle page tracking feature, including the
userspace API, /proc/kpageidle
---- SCRIPT FOR COUNTING IDLE PAGES PER CGROUP ----
#! /usr/bin/python
#
CGROUP_MOUNT = "/sys/fs/cgroup/memory"
import os
import stat
import errno
import struct
def set_idle():
pgidle = open("/proc/kpageidle", "wb")
while True:
try:
pgidle.write(struct.pack("Q", 1))
except IOError as e:
if e.errno == errno.ENXIO: break
raise
pgidle.close()
def count_idle():
pgflags = open("/proc/kpageflags", "rb")
pgcgroup = open("/proc/kpagecgroup", "rb")
pgidle = open("/proc/kpageidle", "rb")
nidle = {}
while True:
s = pgflags.read(8)
if len(s) != 8: break;
flags = struct.unpack('Q', s)[0]
cgino = struct.unpack('Q', pgcgroup.read(8))[0]
idle = struct.unpack('Q', pgidle.read(8))[0]
if not idle: continue
if (flags >> 18) & 1: continue # unevictable?
npages = 512 if (flags >> 22) & 1 else 1 # huge?
nidle[cgino] = nidle.get(cgino, 0) + npages
pgflags.close()
pgcgroup.close()
pgidle.close()
return nidle
print "Setting the idle flag for each page..."
set_idle()
raw_input("Wait until the workload accesses its working set, then press Enter")
print "Counting idle pages..."
nidle = count_idle()
for dir, subdirs, files in os.walk(CGROUP_MOUNT):
ino = os.stat(dir)[stat.ST_INO]
print dir + ": " + str(nidle.get(ino, 0))
---- END SCRIPT ----
Comments are more than welcome.
Thanks,
Vladimir Davydov (3):
memcg: add page_cgroup_ino helper
proc: add kpagecgroup file
proc: add kpageidle file
Documentation/vm/pagemap.txt | 21 ++++-
fs/proc/Kconfig | 5 +-
fs/proc/page.c | 202 ++++++++++++++++++++++++++++++++++++++++++
fs/proc/task_mmu.c | 4 +-
include/linux/memcontrol.h | 8 +-
include/linux/page-flags.h | 12 +++
mm/Kconfig | 12 +++
mm/debug.c | 4 +
mm/hwpoison-inject.c | 5 +-
mm/memcontrol.c | 73 +++++++--------
mm/memory-failure.c | 16 +---
mm/rmap.c | 7 ++
mm/swap.c | 2 +
13 files changed, 307 insertions(+), 64 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [RFC v2 1/3] memcg: add page_cgroup_ino helper
From: Vladimir Davydov @ 2015-04-07 11:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Minchan Kim, Johannes Weiner, Michal Hocko, Greg Thelen,
Michel Lespinasse, David Rientjes, Pavel Emelyanov,
Cyrill Gorcunov, Jonathan Corbet, linux-api, linux-doc, linux-mm,
cgroups, linux-kernel
In-Reply-To: <cover.1428401673.git.vdavydov@parallels.com>
Hwpoison allows to filter pages by memory cgroup ino. To ahieve that, it
calls try_get_mem_cgroup_from_page(), then mem_cgroup_css(), and finally
cgroup_ino() on the cgroup returned. This looks bulky. Since in the next
patch I need to get the ino of the memory cgroup a page is charged to
too, in this patch I introduce the page_cgroup_ino() helper.
Note that page_cgroup_ino() only considers those pages that are charged
to mem_cgroup->memory (i.e. page->mem_cgroup != NULL), and for others it
returns 0, while try_get_mem_cgroup_page(), used by hwpoison before, may
extract the cgroup from a swapcache readahead page too. Ignoring
swapcache readahead pages allows to call page_cgroup_ino() on unlocked
pages, which is nice. Hwpoison users will hardly see any difference.
Another difference between try_get_mem_cgroup_page() and
page_cgroup_ino() is that the latter works on pages charged to offline
memory cgroups, returning the inode number of the closest online
ancestor in this case, while the former does not, which is crucial for
the next patch.
Since try_get_mem_cgroup_page() is not used by anyone else, this patch
removes this function. Also, it makes hwpoison memcg filter depend on
CONFIG_MEMCG instead of CONFIG_MEMCG_SWAP (I've no idea why it was made
dependant on CONFIG_MEMCG_SWAP initially).
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
---
include/linux/memcontrol.h | 8 ++---
mm/hwpoison-inject.c | 5 +--
mm/memcontrol.c | 73 ++++++++++++++++++++++----------------------
mm/memory-failure.c | 16 ++--------
4 files changed, 42 insertions(+), 60 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 72dff5fb0d0c..9262a8407af7 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -91,7 +91,6 @@ bool mem_cgroup_is_descendant(struct mem_cgroup *memcg,
struct mem_cgroup *root);
bool task_in_mem_cgroup(struct task_struct *task, struct mem_cgroup *memcg);
-extern struct mem_cgroup *try_get_mem_cgroup_from_page(struct page *page);
extern struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p);
extern struct mem_cgroup *parent_mem_cgroup(struct mem_cgroup *memcg);
@@ -192,6 +191,8 @@ static inline void mem_cgroup_count_vm_event(struct mm_struct *mm,
void mem_cgroup_split_huge_fixup(struct page *head);
#endif
+unsigned long page_cgroup_ino(struct page *page);
+
#else /* CONFIG_MEMCG */
struct mem_cgroup;
@@ -252,11 +253,6 @@ static inline struct lruvec *mem_cgroup_page_lruvec(struct page *page,
return &zone->lruvec;
}
-static inline struct mem_cgroup *try_get_mem_cgroup_from_page(struct page *page)
-{
- return NULL;
-}
-
static inline bool mm_match_cgroup(struct mm_struct *mm,
struct mem_cgroup *memcg)
{
diff --git a/mm/hwpoison-inject.c b/mm/hwpoison-inject.c
index 329caf56df22..df63c3133d70 100644
--- a/mm/hwpoison-inject.c
+++ b/mm/hwpoison-inject.c
@@ -45,12 +45,9 @@ static int hwpoison_inject(void *data, u64 val)
/*
* do a racy check with elevated page count, to make sure PG_hwpoison
* will only be set for the targeted owner (or on a free page).
- * We temporarily take page lock for try_get_mem_cgroup_from_page().
* memory_failure() will redo the check reliably inside page lock.
*/
- lock_page(hpage);
err = hwpoison_filter(hpage);
- unlock_page(hpage);
if (err)
return 0;
@@ -123,7 +120,7 @@ static int pfn_inject_init(void)
if (!dentry)
goto fail;
-#ifdef CONFIG_MEMCG_SWAP
+#ifdef CONFIG_MEMCG
dentry = debugfs_create_u64("corrupt-filter-memcg", 0600,
hwpoison_dir, &hwpoison_filter_memcg);
if (!dentry)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 14c2f2017e37..87c7f852d45b 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2349,40 +2349,6 @@ static void cancel_charge(struct mem_cgroup *memcg, unsigned int nr_pages)
css_put_many(&memcg->css, nr_pages);
}
-/*
- * try_get_mem_cgroup_from_page - look up page's memcg association
- * @page: the page
- *
- * Look up, get a css reference, and return the memcg that owns @page.
- *
- * The page must be locked to prevent racing with swap-in and page
- * cache charges. If coming from an unlocked page table, the caller
- * must ensure the page is on the LRU or this can race with charging.
- */
-struct mem_cgroup *try_get_mem_cgroup_from_page(struct page *page)
-{
- struct mem_cgroup *memcg;
- unsigned short id;
- swp_entry_t ent;
-
- VM_BUG_ON_PAGE(!PageLocked(page), page);
-
- memcg = page->mem_cgroup;
- if (memcg) {
- if (!css_tryget_online(&memcg->css))
- memcg = NULL;
- } else if (PageSwapCache(page)) {
- ent.val = page_private(page);
- id = lookup_swap_cgroup_id(ent);
- rcu_read_lock();
- memcg = mem_cgroup_from_id(id);
- if (memcg && !css_tryget_online(&memcg->css))
- memcg = NULL;
- rcu_read_unlock();
- }
- return memcg;
-}
-
static void lock_page_lru(struct page *page, int *isolated)
{
struct zone *zone = page_zone(page);
@@ -2774,6 +2740,31 @@ void mem_cgroup_split_huge_fixup(struct page *head)
}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+/**
+ * page_cgroup_ino - return inode number of page's memcg
+ * @page: the page
+ *
+ * Look up the closest online ancestor of the memory cgroup @page is charged to
+ * and return its inode number. It is safe to call this function without taking
+ * a reference to the page.
+ */
+unsigned long page_cgroup_ino(struct page *page)
+{
+ struct mem_cgroup *memcg;
+ unsigned long ino = 0;
+
+ rcu_read_lock();
+ memcg = READ_ONCE(page->mem_cgroup);
+ while (memcg && !css_tryget_online(&memcg->css))
+ memcg = parent_mem_cgroup(memcg);
+ rcu_read_unlock();
+ if (memcg) {
+ ino = cgroup_ino(memcg->css.cgroup);
+ css_put(&memcg->css);
+ }
+ return ino;
+}
+
#ifdef CONFIG_MEMCG_SWAP
static void mem_cgroup_swap_statistics(struct mem_cgroup *memcg,
bool charge)
@@ -5482,8 +5473,18 @@ int mem_cgroup_try_charge(struct page *page, struct mm_struct *mm,
VM_BUG_ON_PAGE(!PageTransHuge(page), page);
}
- if (do_swap_account && PageSwapCache(page))
- memcg = try_get_mem_cgroup_from_page(page);
+ if (do_swap_account && PageSwapCache(page)) {
+ swp_entry_t ent = { .val = page_private(page), };
+ unsigned short id = lookup_swap_cgroup_id(ent);
+
+ VM_BUG_ON_PAGE(!PageLocked(page), page);
+
+ rcu_read_lock();
+ memcg = mem_cgroup_from_id(id);
+ if (memcg && !css_tryget_online(&memcg->css))
+ memcg = NULL;
+ rcu_read_unlock();
+ }
if (!memcg)
memcg = get_mem_cgroup_from_mm(mm);
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 441eff52d099..824fa3b5aff3 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -128,27 +128,15 @@ static int hwpoison_filter_flags(struct page *p)
* can only guarantee that the page either belongs to the memcg tasks, or is
* a freed page.
*/
-#ifdef CONFIG_MEMCG_SWAP
+#ifdef CONFIG_MEMCG
u64 hwpoison_filter_memcg;
EXPORT_SYMBOL_GPL(hwpoison_filter_memcg);
static int hwpoison_filter_task(struct page *p)
{
- struct mem_cgroup *mem;
- struct cgroup_subsys_state *css;
- unsigned long ino;
-
if (!hwpoison_filter_memcg)
return 0;
- mem = try_get_mem_cgroup_from_page(p);
- if (!mem)
- return -EINVAL;
-
- css = mem_cgroup_css(mem);
- ino = cgroup_ino(css->cgroup);
- css_put(css);
-
- if (ino != hwpoison_filter_memcg)
+ if (page_cgroup_ino(p) != hwpoison_filter_memcg)
return -EINVAL;
return 0;
--
1.7.10.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
* [RFC v2 2/3] proc: add kpagecgroup file
From: Vladimir Davydov @ 2015-04-07 11:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Minchan Kim, Johannes Weiner, Michal Hocko, Greg Thelen,
Michel Lespinasse, David Rientjes, Pavel Emelyanov,
Cyrill Gorcunov, Jonathan Corbet,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
cgroups-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1428401673.git.vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
/proc/kpagecgroup contains a 64-bit inode number of the memory cgroup
each page is charged to, indexed by PFN. Having this information is
useful for estimating a cgroup working set size.
The file is present if CONFIG_PROC_PAGE_MONITOR && CONFIG_MEMCG.
Signed-off-by: Vladimir Davydov <vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
---
Documentation/vm/pagemap.txt | 6 ++++-
fs/proc/Kconfig | 5 ++--
fs/proc/page.c | 53 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/Documentation/vm/pagemap.txt b/Documentation/vm/pagemap.txt
index 6fbd55ef6b45..1ddfa1367b03 100644
--- a/Documentation/vm/pagemap.txt
+++ b/Documentation/vm/pagemap.txt
@@ -5,7 +5,7 @@ pagemap is a new (as of 2.6.25) set of interfaces in the kernel that allow
userspace programs to examine the page tables and related information by
reading files in /proc.
-There are three components to pagemap:
+There are four components to pagemap:
* /proc/pid/pagemap. This file lets a userspace process find out which
physical frame each virtual page is mapped to. It contains one 64-bit
@@ -65,6 +65,10 @@ There are three components to pagemap:
23. BALLOON
24. ZERO_PAGE
+ * /proc/kpagecgroup. This file contains a 64-bit inode number of the
+ memory cgroup each page is charged to, indexed by PFN. Only available when
+ CONFIG_MEMCG is set.
+
Short descriptions to the page flags:
0. LOCKED
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf41d59..5021a2935bb9 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -69,5 +69,6 @@ config PROC_PAGE_MONITOR
help
Various /proc files exist to monitor process memory utilization:
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
- /proc/kpagecount, and /proc/kpageflags. Disabling these
- interfaces will reduce the size of the kernel by approximately 4kb.
+ /proc/kpagecount, /proc/kpageflags, and /proc/kpagecgroup.
+ Disabling these interfaces will reduce the size of the kernel
+ by approximately 4kb.
diff --git a/fs/proc/page.c b/fs/proc/page.c
index 7eee2d8b97d9..70d23245dd43 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -9,6 +9,7 @@
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
#include <linux/hugetlb.h>
+#include <linux/memcontrol.h>
#include <linux/kernel-page-flags.h>
#include <asm/uaccess.h>
#include "internal.h"
@@ -225,10 +226,62 @@ static const struct file_operations proc_kpageflags_operations = {
.read = kpageflags_read,
};
+#ifdef CONFIG_MEMCG
+static ssize_t kpagecgroup_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ u64 __user *out = (u64 __user *)buf;
+ struct page *ppage;
+ unsigned long src = *ppos;
+ unsigned long pfn;
+ ssize_t ret = 0;
+ u64 ino;
+
+ pfn = src / KPMSIZE;
+ count = min_t(unsigned long, count, (max_pfn * KPMSIZE) - src);
+ if (src & KPMMASK || count & KPMMASK)
+ return -EINVAL;
+
+ while (count > 0) {
+ if (pfn_valid(pfn))
+ ppage = pfn_to_page(pfn);
+ else
+ ppage = NULL;
+
+ if (ppage)
+ ino = page_cgroup_ino(ppage);
+ else
+ ino = 0;
+
+ if (put_user(ino, out)) {
+ ret = -EFAULT;
+ break;
+ }
+
+ pfn++;
+ out++;
+ count -= KPMSIZE;
+ }
+
+ *ppos += (char __user *)out - buf;
+ if (!ret)
+ ret = (char __user *)out - buf;
+ return ret;
+}
+
+static const struct file_operations proc_kpagecgroup_operations = {
+ .llseek = mem_lseek,
+ .read = kpagecgroup_read,
+};
+#endif /* CONFIG_MEMCG */
+
static int __init proc_page_init(void)
{
proc_create("kpagecount", S_IRUSR, NULL, &proc_kpagecount_operations);
proc_create("kpageflags", S_IRUSR, NULL, &proc_kpageflags_operations);
+#ifdef CONFIG_MEMCG
+ proc_create("kpagecgroup", S_IRUSR, NULL, &proc_kpagecgroup_operations);
+#endif
return 0;
}
fs_initcall(proc_page_init);
--
1.7.10.4
^ permalink raw reply related
* [RFC v2 3/3] proc: add kpageidle file
From: Vladimir Davydov @ 2015-04-07 11:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Minchan Kim, Johannes Weiner, Michal Hocko, Greg Thelen,
Michel Lespinasse, David Rientjes, Pavel Emelyanov,
Cyrill Gorcunov, Jonathan Corbet, linux-api, linux-doc, linux-mm,
cgroups, linux-kernel
In-Reply-To: <cover.1428401673.git.vdavydov@parallels.com>
Knowing the portion of memory that is not used by a certain application
or memory cgroup (idle memory) can be useful for partitioning the system
efficiently, e.g. by setting memory cgroup limits appropriately.
Currently, the only means to estimate the amount of idle memory provided
by the kernel is /proc/PID/{clear_refs,smaps}: the user can clear the
access bit for all pages mapped to a particular process by writing 1 to
clear_refs, wait for some time, and then count smaps:Referenced.
However, this method has two serious shortcomings:
- it does not count unmapped file pages
- it affects the reclaimer logic
To overcome these drawbacks, this patch introduces two new page flags,
Idle and Young, and a new proc file, /proc/kpageidle. A page's Idle flag
can only be set from userspace by writing to /proc/kpageidle at the
offset corresponding to the page, and it is cleared whenever the page is
accessed either through page tables (it is cleared in page_referenced()
in this case) or using the read(2) system call (mark_page_accessed()).
Thus by setting the Idle flag for pages of a particular workload, which
can be found e.g. by reading /proc/PID/pagemap, waiting for some time to
let the workload access its working set, and then reading the kpageidle
file, one can estimate the amount of pages that are not used by the
workload.
The Young page flag is used to avoid interference with the memory
reclaimer. A page's Young flag is set whenever the Access bit of a page
table entry pointing to the page is cleared by writing to kpageidle. If
page_referenced() is called on a Young page, it will add 1 to its return
value, therefore concealing the fact that the Access bit was cleared.
Since this new feature adds two extra page flags, it is made dependant
on 64BIT, where we have plenty of space for page flags. We could use
page_ext to accomodate new flags on 32BIT, but this is left for the
future work.
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
---
Documentation/vm/pagemap.txt | 17 ++++-
fs/proc/page.c | 149 ++++++++++++++++++++++++++++++++++++++++++
fs/proc/task_mmu.c | 4 +-
include/linux/page-flags.h | 12 ++++
mm/Kconfig | 12 ++++
mm/debug.c | 4 ++
mm/rmap.c | 7 ++
mm/swap.c | 2 +
8 files changed, 205 insertions(+), 2 deletions(-)
diff --git a/Documentation/vm/pagemap.txt b/Documentation/vm/pagemap.txt
index 1ddfa1367b03..2ab2d5b98e8d 100644
--- a/Documentation/vm/pagemap.txt
+++ b/Documentation/vm/pagemap.txt
@@ -5,7 +5,7 @@ pagemap is a new (as of 2.6.25) set of interfaces in the kernel that allow
userspace programs to examine the page tables and related information by
reading files in /proc.
-There are four components to pagemap:
+There are five components to pagemap:
* /proc/pid/pagemap. This file lets a userspace process find out which
physical frame each virtual page is mapped to. It contains one 64-bit
@@ -69,6 +69,21 @@ There are four components to pagemap:
memory cgroup each page is charged to, indexed by PFN. Only available when
CONFIG_MEMCG is set.
+ * /proc/kpageidle. For each page this file contains a 64-bit number, which
+ equals 1 if the page is idle or 0 otherwise. The file is indexed by PFN. To
+ set or clear a page's Idle flag, one can write 1 or 0 respectively to this
+ file at the offset corresponding to the page. It is only possible to modify
+ the Idle flag for user pages (pages that are on an LRU list, to be more
+ exact). For other page types, the input is silently ignored. Writing to this
+ file beyond max PFN results in the ENXIO error.
+
+ A page's Idle flag is automatically cleared whenever the page is accessed
+ (via a page table entry or using the read(2) system call). This makes this
+ file useful for tracking a workload's working set, i.e. the set of pages
+ that are actively used by the workload.
+
+ The file is only available when CONFIG_IDLE_PAGE_TRACKING is set.
+
Short descriptions to the page flags:
0. LOCKED
diff --git a/fs/proc/page.c b/fs/proc/page.c
index 70d23245dd43..974498a4c4b4 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -275,6 +275,151 @@ static const struct file_operations proc_kpagecgroup_operations = {
};
#endif /* CONFIG_MEMCG */
+#ifdef CONFIG_IDLE_PAGE_TRACKING
+static struct page *kpageidle_get_page(struct page *page)
+{
+ if (!page || page_count(page) == 0 || !PageLRU(page))
+ return NULL;
+ if (!get_page_unless_zero(page))
+ return NULL;
+ if (unlikely(!PageLRU(page))) {
+ put_page(page);
+ return NULL;
+ }
+ return page;
+}
+
+static void kpageidle_clear_refs(struct page *page)
+{
+ unsigned long dummy;
+
+ if (page_referenced(page, 0, NULL, &dummy, NULL))
+ SetPageYoung(page);
+}
+
+static u64 kpageidle_read_page_state(struct page *page)
+{
+ u64 state = 0;
+
+ page = kpageidle_get_page(page);
+ if (!page)
+ return 0;
+ if (PageIdle(page)) {
+ kpageidle_clear_refs(page);
+ if (PageIdle(page))
+ state = 1;
+ }
+ put_page(page);
+ return state;
+}
+
+static int kpageidle_write_page_state(struct page *page, u64 state)
+{
+ if (state != 0 && state != 1)
+ return -EINVAL;
+ page = kpageidle_get_page(page);
+ if (!page)
+ return 0;
+ if (state && !PageIdle(page)) {
+ kpageidle_clear_refs(page);
+ SetPageIdle(page);
+ } else if (!state && PageIdle(page))
+ ClearPageIdle(page);
+ put_page(page);
+ return 0;
+}
+
+static ssize_t kpageidle_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ u64 __user *out = (u64 __user *)buf;
+ struct page *ppage;
+ unsigned long src = *ppos;
+ unsigned long pfn;
+ ssize_t ret = 0;
+ u64 val;
+
+ pfn = src / KPMSIZE;
+ count = min_t(unsigned long, count, (max_pfn * KPMSIZE) - src);
+ if (src & KPMMASK || count & KPMMASK)
+ return -EINVAL;
+
+ while (count > 0) {
+ if (pfn_valid(pfn))
+ ppage = pfn_to_page(pfn);
+ else
+ ppage = NULL;
+
+ val = kpageidle_read_page_state(ppage);
+
+ if (put_user(val, out)) {
+ ret = -EFAULT;
+ break;
+ }
+
+ pfn++;
+ out++;
+ count -= KPMSIZE;
+ }
+
+ *ppos += (char __user *)out - buf;
+ if (!ret)
+ ret = (char __user *)out - buf;
+ return ret;
+}
+
+static ssize_t kpageidle_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ const u64 __user *in = (u64 __user *)buf;
+ struct page *ppage;
+ unsigned long src = *ppos;
+ unsigned long pfn;
+ ssize_t ret = 0;
+ u64 val;
+
+ pfn = src / KPMSIZE;
+ if (src & KPMMASK || count & KPMMASK)
+ return -EINVAL;
+
+ while (count > 0) {
+ if (pfn >= max_pfn) {
+ if ((char __user *)in == buf)
+ ret = -ENXIO;
+ break;
+ }
+ if (pfn_valid(pfn))
+ ppage = pfn_to_page(pfn);
+ else
+ ppage = NULL;
+
+ if (get_user(val, in)) {
+ ret = -EFAULT;
+ break;
+ }
+
+ ret = kpageidle_write_page_state(ppage, val);
+ if (ret)
+ break;
+
+ pfn++;
+ in++;
+ count -= KPMSIZE;
+ }
+
+ *ppos += (char __user *)in - buf;
+ if (!ret)
+ ret = (char __user *)in - buf;
+ return ret;
+}
+
+static const struct file_operations proc_kpageidle_operations = {
+ .llseek = mem_lseek,
+ .read = kpageidle_read,
+ .write = kpageidle_write,
+};
+#endif /* CONFIG_IDLE_PAGE_TRACKING */
+
static int __init proc_page_init(void)
{
proc_create("kpagecount", S_IRUSR, NULL, &proc_kpagecount_operations);
@@ -282,6 +427,10 @@ static int __init proc_page_init(void)
#ifdef CONFIG_MEMCG
proc_create("kpagecgroup", S_IRUSR, NULL, &proc_kpagecgroup_operations);
#endif
+#ifdef CONFIG_IDLE_PAGE_TRACKING
+ proc_create("kpageidle", S_IRUSR | S_IWUSR, NULL,
+ &proc_kpageidle_operations);
+#endif
return 0;
}
fs_initcall(proc_page_init);
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 6dee68d013ff..5ed5f707cac3 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -458,7 +458,7 @@ static void smaps_account(struct mem_size_stats *mss, struct page *page,
mss->resident += size;
/* Accumulate the size in pages that have been accessed. */
- if (young || PageReferenced(page))
+ if (young || PageYoung(page) || PageReferenced(page))
mss->referenced += size;
mapcount = page_mapcount(page);
if (mapcount >= 2) {
@@ -808,6 +808,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned long addr,
/* Clear accessed and referenced bits. */
pmdp_test_and_clear_young(vma, addr, pmd);
+ ClearPageYoung(page);
ClearPageReferenced(page);
out:
spin_unlock(ptl);
@@ -835,6 +836,7 @@ out:
/* Clear accessed and referenced bits. */
ptep_test_and_clear_young(vma, addr, pte);
+ ClearPageYoung(page);
ClearPageReferenced(page);
}
pte_unmap_unlock(pte - 1, ptl);
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 91b7f9b2b774..e53afb2738f8 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -109,6 +109,10 @@ enum pageflags {
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
PG_compound_lock,
#endif
+#ifdef CONFIG_IDLE_PAGE_TRACKING
+ PG_young,
+ PG_idle,
+#endif
__NR_PAGEFLAGS,
/* Filesystems */
@@ -363,6 +367,14 @@ PAGEFLAG_FALSE(HWPoison)
#define __PG_HWPOISON 0
#endif
+#ifdef CONFIG_IDLE_PAGE_TRACKING
+PAGEFLAG(Young, young, PF_HEAD)
+PAGEFLAG(Idle, idle, PF_HEAD)
+#else
+PAGEFLAG_FALSE(Young)
+PAGEFLAG_FALSE(Idle)
+#endif
+
/*
* On an anonymous page mapped into a user virtual memory area,
* page->mapping points to its anon_vma, not to a struct address_space;
diff --git a/mm/Kconfig b/mm/Kconfig
index 390214da4546..880dffd9fce1 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -635,3 +635,15 @@ config MAX_STACK_SIZE_MB
changed to a smaller value in which case that is used.
A sane initial value is 80 MB.
+
+config IDLE_PAGE_TRACKING
+ bool "Enable idle page tracking"
+ depends on 64BIT
+ select PROC_PAGE_MONITOR
+ help
+ This feature allows to estimate the amount of user pages that have
+ not been touched during a given period of time. This information can
+ be useful to tune memory cgroup limits and/or for job placement
+ within a compute cluster.
+
+ See Documentation/vm/pagemap.txt for more details.
diff --git a/mm/debug.c b/mm/debug.c
index 3eb3ac2fcee7..25d58478f59b 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -48,6 +48,10 @@ static const struct trace_print_flags pageflag_names[] = {
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
{1UL << PG_compound_lock, "compound_lock" },
#endif
+#ifdef CONFIG_IDLE_PAGE_TRACKING
+ {1UL << PG_young, "young" },
+ {1UL << PG_idle, "idle" },
+#endif
};
static void dump_flags(unsigned long flags,
diff --git a/mm/rmap.c b/mm/rmap.c
index dad23a43e42c..b6ead8a13185 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -799,6 +799,13 @@ static int page_referenced_one(struct page *page, struct vm_area_struct *vma,
if (referenced) {
pra->referenced++;
pra->vm_flags |= vma->vm_flags;
+ if (PageIdle(page))
+ ClearPageIdle(page);
+ }
+
+ if (PageYoung(page)) {
+ ClearPageYoung(page);
+ pra->referenced++;
}
if (dirty)
diff --git a/mm/swap.c b/mm/swap.c
index 8773de093171..bee91fab10fc 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -624,6 +624,8 @@ void mark_page_accessed(struct page *page)
} else if (!PageReferenced(page)) {
SetPageReferenced(page);
}
+ if (PageIdle(page))
+ ClearPageIdle(page);
}
EXPORT_SYMBOL(mark_page_accessed);
--
1.7.10.4
^ 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