Re: kmod: add a sanity check on module loading
+++ Luis R. Rodriguez [06/01/17 21:36 +0100]: On Tue, Jan 03, 2017 at 10:34:53AM +1030, Rusty Russell wrote: "Luis R. Rodriguez" writes: > Right, out of ~350 request_module() calls (not included try requests) > only ~46 check the return value. Hence a validation check, and come to > think of it, *this* was the issue that originally had me believing > that in some places we might end up in a null deref --if those open > coded request_module() calls assume the driver is loaded there could > be many places where a NULL is inevitable. Yes, assuming success == module loade is simply a bug. I wrote try_then_request_module() to attempt to encapsulate the correct logic into a single place; maybe we need other helpers to cover (most of?) the remaining cases? I see... OK so indeed we have a few possible changes to kernel given the above: a) Add SmPL rule to nag about incorrect uses of request_module() which never check for the return value, and fix 86% of calls (304 call sites) which are buggy b) Add a new API call, perhaps request_module_assert() which would BUG_ON() if the requested module didn't load, and change the callers which do not check for the return value to this. It is probably not a good idea to panic/BUG() because a requested module didn't load. IMO callers should already be accounting for the fact that request_module() doesn't provide these guarantees. I haven't looked yet to see if the majority of these callers actually do the the responsible thing, though. Make request_module() do the assert and changing all proper callers of request_module() to a new API call which *does* let you check for the return value is another option but tasteless. b) seems to be what you allude to, and while it may seem also of bad taste, in practice it may be hard to get callers to properly check for the return value. I actually just favor a) even though its more work. > Granted, I agree they > should be fixed, we could add a grammar rule to start nagging at > driver developers for started, but it does beg the question also of > what a tightly knit validation for modprobe might look like, and hence > this patch and now the completed not-yet-posted alias work. I really think aliases-in-kernel is too heavy a hammer, but a warning when modprobe "succeeds" and the module still isn't found would be a Good Thing. OK -- such a warning can really only happen if we had alias support though. So one option is to add this and alias parsing support as a debug option. Hm, I see what you're saying.. To clarify the problem (if anyone was confused, as I was..): we can verify a module is loaded by using find_module_all() and looking at its state. However, find_module_all() operates on real module names, and we can't verify a module has successfully loaded if all we have is the name of the alias (eg, "fs-*" aliases in get_fs_type), because we have no alias->real_module_name mappings in the kernel. However, in Rusty's sample get_fs_type WARN() code, we indirectly validated request_module()'s work by verifying that the file_system_type has actually registered, which is what should happen if a filesystem module successfully loads. So in this case, the caller (get_fs_type) indirectly checks if the service it requested is now available, which is what I *thought* callers were supposed to do in the first place (and we didn't need the help of aliases to do that). I think the main question we have to answer is, should the burden of validation be on the callers, or on request_module? I am currently leaning towards the former, but I'm still thinking. > Would it be worthy as a kconfig kmod debugging aide for now? I can > follow up with a semantic patch to nag about checking the return value > of request_module(), and we can have 0-day then also complain about > new invalid uses. Yeah, a warning about this would be win for sure. OK will work on such SmPL patch into the next patch series for this patch set. BTW, I wrote the original "check-for-module-before-loading" in module-init-tools, but I'm starting to wonder if it was a premature optimization. Have you thought about simply removing it and always trying to load the module? If it doesn't slow things down, perhaps simplicity FTW? I've given this some thought as I tried to blow up request_module() with the new kmod stress test driver and given the small changes I made -- I'm of the mind set it should be based on numbers: if a change improves the time it takes to load modules while also not regressing all the other test cases then we should go with it. The only issue is we don't yet have enough test cases to cover the typical distribution setup: load tons of modules, and only sometimes try to load a few of the same modules. The early module-init-tools check seems fair gain to me given a bounce back to the kernel and back to userspace should incur a bit more work than just checking for a few files on the filesystem. As I noted though, I can't prove this for m
Re: kmod: add a sanity check on module loading
+++ Rusty Russell [03/01/17 10:34 +1030]: "Luis R. Rodriguez" writes: Maybe a similar hack for try_then_request_module(), but many places seem to open-code request_module() so it's not as trivial... Hi Luis, Jessica (who is the main module maintainer now), Back from break, sorry about delay. Right, out of ~350 request_module() calls (not included try requests) only ~46 check the return value. Hence a validation check, and come to think of it, *this* was the issue that originally had me believing that in some places we might end up in a null deref --if those open coded request_module() calls assume the driver is loaded there could be many places where a NULL is inevitable. Yes, assuming success == module loade is simply a bug. I wrote try_then_request_module() to attempt to encapsulate the correct logic into a single place; maybe we need other helpers to cover (most of?) the remaining cases? Granted, I agree they should be fixed, we could add a grammar rule to start nagging at driver developers for started, but it does beg the question also of what a tightly knit validation for modprobe might look like, and hence this patch and now the completed not-yet-posted alias work. I really think aliases-in-kernel is too heavy a hammer, but a warning when modprobe "succeeds" and the module still isn't found would be a Good Thing. I was under the impression that aliases were a userspace concern. i.e., we let kmod tools take care of alias resolution and bookkeeping. I'm getting the feeling we're bending over backwards here to accommodate buggy/untrustworthy userspace (modprobe). If I understand correctly, we're performing this validation work - we're proposing to make the kernel alias-aware - because we can't even trust modprobe's return value, and the proposal is to double check this work ourselves in-kernel. But I thought that request_module() wasn't written to provide these "module is now live and loaded" guarantees in the first place. This seems to be documented in kernel/kmod.c - "Callers must check that the service they requested is now available not blindly invoke it." Isn't it the caller's responsibility to (indirectly) validate request_module's work, to check that the service they want is now there? If a caller doesn't do this, then this is a bug on their side. If it is crucial for get_fs_type() to not fail, then perhaps we should be tightening get_fs_type() instead, be that WARNing if the requested filesystem is still not there (as suggested earlier), or maybe even trying the request again. Would it be worthy as a kconfig kmod debugging aide for now? I can follow up with a semantic patch to nag about checking the return value of request_module(), and we can have 0-day then also complain about new invalid uses. Yeah, a warning about this would be win for sure. BTW, I wrote the original "check-for-module-before-loading" in module-init-tools, but I'm starting to wonder if it was a premature optimization. Have you thought about simply removing it and always trying to load the module? If it doesn't slow things down, perhaps simplicity FTW? Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kmod: provide wrappers for kmod_concurrent inc/dec
On Wed, Dec 21, 2016 at 08:48:06PM -0800, Jessica Yu wrote:
> +++ Luis R. Rodriguez [16/12/16 09:05 +0100]:
> > On Thu, Dec 15, 2016 at 01:46:25PM +0100, Petr Mladek wrote:
> > > On Thu 2016-12-08 22:08:59, Luis R. Rodriguez wrote:
> > > > On Thu, Dec 08, 2016 at 12:29:42PM -0800, Kees Cook wrote:
> > > > > On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez
> > > > > wrote:
> > > > > > kmod_concurrent is used as an atomic counter for enabling
> > > > > > the allowed limit of modprobe calls, provide wrappers for it
> > > > > > to enable this to be expanded on more easily. This will be done
> > > > > > later.
> > > > > >
> > > > > > Signed-off-by: Luis R. Rodriguez
> > > > > > ---
> > > > > > kernel/kmod.c | 27 +--
> > > > > > 1 file changed, 21 insertions(+), 6 deletions(-)
> > > > > >
> > > > > > diff --git a/kernel/kmod.c b/kernel/kmod.c
> > > > > > index cb6f7ca7b8a5..049d7eabda38 100644
> > > > > > --- a/kernel/kmod.c
> > > > > > +++ b/kernel/kmod.c
> > > > > > @@ -108,6 +111,20 @@ static int call_modprobe(char *module_name,
> > > > > > int wait)
> > > > > > return -ENOMEM;
> > > > > > }
> > > > > >
> > > > > > +static int kmod_umh_threads_get(void)
> > > > > > +{
> > > > > > + atomic_inc(&kmod_concurrent);
> > >
> > > This approach might actually cause false failures. If we
> > > are on the limit and more processes do this increment
> > > in parallel, it makes the number bigger that it should be.
> >
> > This approach is *exactly* what the existing code does :P
> > I just provided wrappers. I agree with the old approach though,
> > reason is it acts as a lock in for the bump.
>
> I think what Petr meant was that we could run into false failures when
> multiple
> atomic increments happen between the first increment and the subsequent
> atomic_read.
>
> Say max_modprobes is 64 -
>
> atomic_inc(&kmod_concurrent); // thread 1: kmod_concurrent is 63
>atomic_inc(&kmod_concurrent); // thread 2: kmod_concurrent is 64
> atomic_inc(&kmod_concurrent); // thread 3: kmod_concurrent is
> 65
> if (atomic_read(&kmod_concurrent) < max_modprobes) // if all threads
> read 65 here, then all will error out
> return 0; // when the first
> two should have succeeded (false failures)
> atomic_dec(&kmod_concurrent);
> return -ENOMEM;
>
> But yeah, I think this issue was already in the existing kmod code..
Ah right, but the code was very simple and there is only one operation
in between which we'd race against given the old code just incremented
first nd immediately checked for the limit. The more code we have the
more chances for what you describe to happen.
I've added another change into my series, a clutch, its at the end of this
email. With this we change we check for the limit right away and put on
hold any items reaching the limit, while other requests passing the limit
will be bumped. We have then:
if (!kmod_concurrent_sane()) {
pr_warn_ratelimited("request_module: kmod_concurrent (%u) close
to critical levels (max_modprobes: %u) for module %s\n, backing off for a bit",
atomic_read(&kmod_concurrent),
max_modprobes, module_name);
wait_event_interruptible(kmod_wq, kmod_concurrent_sane());
}
ret = kmod_umh_threads_get();
if (ret) {
pr_err_ratelimited("%s: module \"%s\" reached limit (%u) of
concurrent modprobe calls\n",
__func__, module_name, max_modprobes);
return ret;
}
The same race you describe is possible -- but we now would at least use
a clutch immediately as we approach the limit. Maybe it makes sense to
post a new series after I fold the alias code and sanity check into a
debug kconfig option ?
Luis
commit 95c2283cf99e2a48b84dc766d5fa547f046e
Author: Luis R. Rodriguez
Date: Thu Dec 15 23:24:22 2016 -0600
kmod: add a clutch around 1/4 of modprobe thread limit
If we reach the limit of modprobe_limit threads running the next
request_module() call will fail. The original reason for adding
a kill was to do away with possible issues with in old circumstances
which would create a recursive series of request_module() calls.
We can do better than just be super aggressive and reject calls
once we've reached the limit by adding a clutch so that if we're
1/4th of the way close to the limit we make these new calls wait
until pending threads complete.
There is still a chance you
Re: [PATCH v2 4/7] x86: put msr-index.h in uapi
On Fri, Jan 6, 2017 at 11:43 AM, Nicolas Dichtel wrote: > This header file is exported, thus move it to uapi. Just hint for the future: -M (move) -C (copy) -D (delete) [though this is NOT for applying] -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 10/10] kmod: add a sanity check on module loading
On Tue, Jan 03, 2017 at 10:34:53AM +1030, Rusty Russell wrote: > "Luis R. Rodriguez" writes: > > Right, out of ~350 request_module() calls (not included try requests) > > only ~46 check the return value. Hence a validation check, and come to > > think of it, *this* was the issue that originally had me believing > > that in some places we might end up in a null deref --if those open > > coded request_module() calls assume the driver is loaded there could > > be many places where a NULL is inevitable. > > Yes, assuming success == module loade is simply a bug. I wrote > try_then_request_module() to attempt to encapsulate the correct logic > into a single place; maybe we need other helpers to cover (most of?) the > remaining cases? I see... OK so indeed we have a few possible changes to kernel given the above: a) Add SmPL rule to nag about incorrect uses of request_module() which never check for the return value, and fix 86% of calls (304 call sites) which are buggy b) Add a new API call, perhaps request_module_assert() which would BUG_ON() if the requested module didn't load, and change the callers which do not check for the return value to this. Make request_module() do the assert and changing all proper callers of request_module() to a new API call which *does* let you check for the return value is another option but tasteless. b) seems to be what you allude to, and while it may seem also of bad taste, in practice it may be hard to get callers to properly check for the return value. I actually just favor a) even though its more work. > > Granted, I agree they > > should be fixed, we could add a grammar rule to start nagging at > > driver developers for started, but it does beg the question also of > > what a tightly knit validation for modprobe might look like, and hence > > this patch and now the completed not-yet-posted alias work. > > I really think aliases-in-kernel is too heavy a hammer, but a warning > when modprobe "succeeds" and the module still isn't found would be > a Good Thing. OK -- such a warning can really only happen if we had alias support though. So one option is to add this and alias parsing support as a debug option. > > Would it be worthy as a kconfig kmod debugging aide for now? I can > > follow up with a semantic patch to nag about checking the return value > > of request_module(), and we can have 0-day then also complain about > > new invalid uses. > > Yeah, a warning about this would be win for sure. OK will work on such SmPL patch into the next patch series for this patch set. > BTW, I wrote the original "check-for-module-before-loading" in > module-init-tools, but I'm starting to wonder if it was a premature > optimization. Have you thought about simply removing it and always > trying to load the module? If it doesn't slow things down, perhaps > simplicity FTW? I've given this some thought as I tried to blow up request_module() with the new kmod stress test driver and given the small changes I made -- I'm of the mind set it should be based on numbers: if a change improves the time it takes to load modules while also not regressing all the other test cases then we should go with it. The only issue is we don't yet have enough test cases to cover the typical distribution setup: load tons of modules, and only sometimes try to load a few of the same modules. The early module-init-tools check seems fair gain to me given a bounce back to the kernel and back to userspace should incur a bit more work than just checking for a few files on the filesystem. As I noted though, I can't prove this for most cases for now, but its a hunch. So I'd advocate leaving the "check-for-module-before-loading" on kmod for now. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/livepatch: remove the limitation for schedule() patching
On Fri, Jan 06, 2017 at 03:00:45PM +0100, Miroslav Benes wrote:
> The Limitations section of the documentation describes the impossibility
> to livepatch anything that is inlined to __schedule() function. This had
> been true till 4.9 kernel came. Thanks to commit 0100301bfdf5
> ("sched/x86: Rewrite the switch_to() code") from Brian Gerst there is
> __switch_to_asm function now (implemented in assembly) called properly
> from context_switch(). RIP is thus saved on the stack and a task would
> return to proper version of __schedule() et al. functions.
>
> Of course __switch_to_asm() is not patchable for the reason described in
> the section. But there is no __fentry__ call and I cannot imagine a
> reason to do it anyway.
>
> Therefore, remove the paragraphs from the section.
>
> Signed-off-by: Miroslav Benes
Acked-by: Josh Poimboeuf
> ---
> FWIW, I also tested this to be sure on top of the consistency model
> patch set. I patched schedule() function which calls __schedule() (it is
> impossible to patch it directly due to notrace attribute). It works well
> except...
>
> 1. the patching process does not finish, because many tasks sleep in
> schedule. STOP/CONT signal does not help. I'll investigate.
>
> 2. reversion of the process does not work as expected. The kernel
> crashes after the removal of the module. A task very likely slept in
> schedule and was not migrated properly. It might be because of the races
> in klp_reverse_transition() described by Petr, or might be somewhere
> else. I'll look into it.
Hm, will be interesting to see the cause of this...
--
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/06/2017 10:18 AM, Khalid Aziz wrote: On 01/06/2017 10:54 AM, Rob Gardner wrote: On 01/06/2017 09:10 AM, Khalid Aziz wrote: On 01/06/2017 10:02 AM, David Miller wrote: From: Dave Hansen Date: Fri, 6 Jan 2017 08:55:03 -0800 Actually, that reminds me... How does your code interface with ksm? Or is there no interaction needed since you're always working on virtual addresses? This reminds me, I consider this feature potentially extremely useful for kernel debugging. So I would like to make sure we don't implement anything in a way which would preclude that in the long term. I agree and please do point out if I have made any implementation decisions that could preclude that. Thanks, Khalid Khalid, I have already pointed out an implementation decision that interferes with the potential for kernel debugging with ADI: lazy clearing of version tags. This does not preclude kernel debugging. If kernel debugging ends up requiring tags be cleared whenever a page is freed, we can add that code as part of kernel debugging support code and enable it conditionally only when kernel is being debugged. Forcing every task to incur the large cost of clearing tags on every "free" all the time is just not an acceptable cost only to support kernel debugging. It should be a dynamic switch to be toggled on only when debugging kernel. PSTATE.mcde being set is not enough to trigger a trap. It is easy enough to clear TTE.mcd before block initialization of a page and avoid a trap due to tag mismatch, or just use physical address with block initialization. We can evaluate all of these options when we get to implementing kernel debugging using ADI. I didn't say it precludes kernel debugging, just that it interferes, and there will be additional work to do if we want kernel debugging capability with ADI. Rob Thanks, Khalid Details: when memory is "freed" the version tags are left alone, as it is an expensive operation to go through the memory and clear the tag for each cache line. So this is done lazily whenever memory is "allocated". More specifically, the first time a user process touches freshly allocated memory, a fault occurs and the kernel then clears the page. In the NG4 and M7 variants of clear_user_page, the block init store ASI is used to optimize, and it has the side effect of clearing the ADI tag for the cache line. BUT only if pstate.mcde is clear. If pstate.mcde is set, then instead of the ADI tag being cleared, the tag is *checked*, and if there is a mismatch between the version in the virtual address and the version in memory, then you'll get a trap and panic. Therefore, with this design, you cannot have pstate.mcde enabled while in the kernel (in general). To solve this you have to check the state of pstate.mcde (or just turn it off) before doing any block init store in clear_user_page, memset, memcpy, etc. Rob -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/06/2017 10:54 AM, Rob Gardner wrote: On 01/06/2017 09:10 AM, Khalid Aziz wrote: On 01/06/2017 10:02 AM, David Miller wrote: From: Dave Hansen Date: Fri, 6 Jan 2017 08:55:03 -0800 Actually, that reminds me... How does your code interface with ksm? Or is there no interaction needed since you're always working on virtual addresses? This reminds me, I consider this feature potentially extremely useful for kernel debugging. So I would like to make sure we don't implement anything in a way which would preclude that in the long term. I agree and please do point out if I have made any implementation decisions that could preclude that. Thanks, Khalid Khalid, I have already pointed out an implementation decision that interferes with the potential for kernel debugging with ADI: lazy clearing of version tags. This does not preclude kernel debugging. If kernel debugging ends up requiring tags be cleared whenever a page is freed, we can add that code as part of kernel debugging support code and enable it conditionally only when kernel is being debugged. Forcing every task to incur the large cost of clearing tags on every "free" all the time is just not an acceptable cost only to support kernel debugging. It should be a dynamic switch to be toggled on only when debugging kernel. PSTATE.mcde being set is not enough to trigger a trap. It is easy enough to clear TTE.mcd before block initialization of a page and avoid a trap due to tag mismatch, or just use physical address with block initialization. We can evaluate all of these options when we get to implementing kernel debugging using ADI. Thanks, Khalid Details: when memory is "freed" the version tags are left alone, as it is an expensive operation to go through the memory and clear the tag for each cache line. So this is done lazily whenever memory is "allocated". More specifically, the first time a user process touches freshly allocated memory, a fault occurs and the kernel then clears the page. In the NG4 and M7 variants of clear_user_page, the block init store ASI is used to optimize, and it has the side effect of clearing the ADI tag for the cache line. BUT only if pstate.mcde is clear. If pstate.mcde is set, then instead of the ADI tag being cleared, the tag is *checked*, and if there is a mismatch between the version in the virtual address and the version in memory, then you'll get a trap and panic. Therefore, with this design, you cannot have pstate.mcde enabled while in the kernel (in general). To solve this you have to check the state of pstate.mcde (or just turn it off) before doing any block init store in clear_user_page, memset, memcpy, etc. Rob -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/06/2017 09:10 AM, Khalid Aziz wrote: On 01/06/2017 10:02 AM, David Miller wrote: From: Dave Hansen Date: Fri, 6 Jan 2017 08:55:03 -0800 Actually, that reminds me... How does your code interface with ksm? Or is there no interaction needed since you're always working on virtual addresses? This reminds me, I consider this feature potentially extremely useful for kernel debugging. So I would like to make sure we don't implement anything in a way which would preclude that in the long term. I agree and please do point out if I have made any implementation decisions that could preclude that. Thanks, Khalid Khalid, I have already pointed out an implementation decision that interferes with the potential for kernel debugging with ADI: lazy clearing of version tags. Details: when memory is "freed" the version tags are left alone, as it is an expensive operation to go through the memory and clear the tag for each cache line. So this is done lazily whenever memory is "allocated". More specifically, the first time a user process touches freshly allocated memory, a fault occurs and the kernel then clears the page. In the NG4 and M7 variants of clear_user_page, the block init store ASI is used to optimize, and it has the side effect of clearing the ADI tag for the cache line. BUT only if pstate.mcde is clear. If pstate.mcde is set, then instead of the ADI tag being cleared, the tag is *checked*, and if there is a mismatch between the version in the virtual address and the version in memory, then you'll get a trap and panic. Therefore, with this design, you cannot have pstate.mcde enabled while in the kernel (in general). To solve this you have to check the state of pstate.mcde (or just turn it off) before doing any block init store in clear_user_page, memset, memcpy, etc. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/06/2017 10:02 AM, David Miller wrote: From: Dave Hansen Date: Fri, 6 Jan 2017 08:55:03 -0800 Actually, that reminds me... How does your code interface with ksm? Or is there no interaction needed since you're always working on virtual addresses? This reminds me, I consider this feature potentially extremely useful for kernel debugging. So I would like to make sure we don't implement anything in a way which would preclude that in the long term. I agree and please do point out if I have made any implementation decisions that could preclude that. Thanks, Khalid -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/06/2017 09:55 AM, Dave Hansen wrote: On 01/06/2017 08:22 AM, Khalid Aziz wrote: On 01/06/2017 08:36 AM, Dave Hansen wrote: On 01/06/2017 07:32 AM, Khalid Aziz wrote: I agree with you on simplicity first. Subpage granularity is complex, but the architecture allows for subpage granularity. Maybe the right approach is to support this at page granularity first for swappable pages and then expand to subpage granularity in a subsequent patch? Pages locked in memory can already use subpage granularity with my patch. What do you mean by "locked in memory"? mlock()'d memory can still be migrated around and still requires "swap" ptes, for instance. You are right. Page migration can invalidate subpage granularity even for locked pages. Is it possible to use cpusets to keep a task and its memory locked on a single node? It's going to be hard to impossible to guarantee. mlock() doesn't guarantee that things won't change physical addresses. You'd have to change that guarantee or chase all the things in the kernel that might change physical addresses (compaction, ksm, etc...). Actually, that reminds me... How does your code interface with ksm? Or is there no interaction needed since you're always working on virtual addresses? Yes, version tags are interpreted at virtual address level. -- Khalid -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
From: Dave Hansen Date: Fri, 6 Jan 2017 08:55:03 -0800 > Actually, that reminds me... How does your code interface with ksm? Or > is there no interaction needed since you're always working on virtual > addresses? This reminds me, I consider this feature potentially extremely useful for kernel debugging. So I would like to make sure we don't implement anything in a way which would preclude that in the long term. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/06/2017 08:22 AM, Khalid Aziz wrote: > On 01/06/2017 08:36 AM, Dave Hansen wrote: >> On 01/06/2017 07:32 AM, Khalid Aziz wrote: >>> I agree with you on simplicity first. Subpage granularity is complex, >>> but the architecture allows for subpage granularity. Maybe the right >>> approach is to support this at page granularity first for swappable >>> pages and then expand to subpage granularity in a subsequent patch? >>> Pages locked in memory can already use subpage granularity with my >>> patch. >> >> What do you mean by "locked in memory"? mlock()'d memory can still be >> migrated around and still requires "swap" ptes, for instance. > > You are right. Page migration can invalidate subpage granularity even > for locked pages. Is it possible to use cpusets to keep a task and its > memory locked on a single node? It's going to be hard to impossible to guarantee. mlock() doesn't guarantee that things won't change physical addresses. You'd have to change that guarantee or chase all the things in the kernel that might change physical addresses (compaction, ksm, etc...). Actually, that reminds me... How does your code interface with ksm? Or is there no interaction needed since you're always working on virtual addresses? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
From: Khalid Aziz Date: Fri, 6 Jan 2017 09:22:13 -0700 > On 01/06/2017 08:36 AM, Dave Hansen wrote: >> On 01/06/2017 07:32 AM, Khalid Aziz wrote: >>> I agree with you on simplicity first. Subpage granularity is complex, >>> but the architecture allows for subpage granularity. Maybe the right >>> approach is to support this at page granularity first for swappable >>> pages and then expand to subpage granularity in a subsequent patch? >>> Pages locked in memory can already use subpage granularity with my >>> patch. >> >> What do you mean by "locked in memory"? mlock()'d memory can still be >> migrated around and still requires "swap" ptes, for instance. > > You are right. Page migration can invalidate subpage granularity even > for locked pages. Is it possible to use cpusets to keep a task and its > memory locked on a single node? Just wondering if there are limited > cases where subpage granularity could work without supporting subpage > granularity for tags in swap. It still sounds like the right thing to > do is to get a reliable implementation in place with page size > granularity and then add the complexity of subpage granularity. It sounds to me, in all of this, that if the kernel manages the movement of the pages, it thus must handle making sure the tags move around with that page as well. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/06/2017 08:36 AM, Dave Hansen wrote: On 01/06/2017 07:32 AM, Khalid Aziz wrote: I agree with you on simplicity first. Subpage granularity is complex, but the architecture allows for subpage granularity. Maybe the right approach is to support this at page granularity first for swappable pages and then expand to subpage granularity in a subsequent patch? Pages locked in memory can already use subpage granularity with my patch. What do you mean by "locked in memory"? mlock()'d memory can still be migrated around and still requires "swap" ptes, for instance. You are right. Page migration can invalidate subpage granularity even for locked pages. Is it possible to use cpusets to keep a task and its memory locked on a single node? Just wondering if there are limited cases where subpage granularity could work without supporting subpage granularity for tags in swap. It still sounds like the right thing to do is to get a reliable implementation in place with page size granularity and then add the complexity of subpage granularity. Thanks, Khalid -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
Christopher Covington wrote: > Also, since this can't be changed via the menu, why bother putting it in? I put it in in response to review comments asking for the magic number to be clarified by a #define or variable. I could not find a suitably shared header between the files in question, so I used the Kconfig machinery to generate the #define. I don't think that's the right approach. Kconfigs are not an alternative to header files. Is the ASID configurable? If you just put some text after the "int" then it because a menu option that the user can select and change. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
Christopher Covington wrote: > Looks like you've made an unrelated whitespace change that affected the entire table, > not just the line you're adding. I'm making space for "QCOM_FALKOR_ERRATUM_1003". Ok, but you're also shrinking the other columns. I think a better solution is to make the macro shorter. QCOM_ERRATUM_FLK1003? -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
On 01/03/2017 10:55 AM, Mark Rutland wrote: > Hi, > > On Thu, Dec 29, 2016 at 05:43:32PM -0500, Christopher Covington wrote: >> +config QCOM_FALKOR_E1003_RESERVED_ASID >> +int >> +default 1 >> +depends on QCOM_FALKOR_ERRATUM_1003 >> + > > I don't think this needs to be configurable, so let's drop this into a > header, e.g. drop: > > #define FALKOR_RESERVED_ASID 1 > > ... in , protecting the rest with an ifndef > __ASSEMBLY__ guard. Will do, thanks for the concrete suggestion. > [...] > >> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003 >> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003 >> +mrs x2, ttbr0_el1 // get cuurent TTBR0_EL1 >> +mov x3, #CONFIG_QCOM_FALKOR_ERRATUM_1003// reserved ASID > > Wrong macro? That's not the ASID. Oops, thanks for spotting. Cov -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
On 12/29/2016 06:08 PM, Timur Tabi wrote: > On 12/29/2016 04:43 PM, Christopher Covington wrote: >> +config QCOM_FALKOR_E1003_RESERVED_ASID >> +int >> +default 1 >> +depends on QCOM_FALKOR_ERRATUM_1003 > > Also, since this can't be changed via the menu, why bother putting it in? I put it in in response to review comments asking for the magic number to be clarified by a #define or variable. I could not find a suitably shared header between the files in question, so I used the Kconfig machinery to generate the #define. Cov -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
On 12/29/2016 06:02 PM, Timur Tabi wrote: > On 12/29/2016 04:43 PM, Christopher Covington wrote: >> -| Implementor| Component | Erratum ID | Kconfig >>| >> -++-+-+-+ >> -| ARM| Cortex-A53 | #826319 | ARM64_ERRATUM_826319 >>| >> -| ARM| Cortex-A53 | #827319 | ARM64_ERRATUM_827319 >>| >> -| ARM| Cortex-A53 | #824069 | ARM64_ERRATUM_824069 >>| >> -| ARM| Cortex-A53 | #819472 | ARM64_ERRATUM_819472 >>| >> -| ARM| Cortex-A53 | #845719 | ARM64_ERRATUM_845719 >>| >> -| ARM| Cortex-A53 | #843419 | ARM64_ERRATUM_843419 >>| >> -| ARM| Cortex-A57 | #832075 | ARM64_ERRATUM_832075 >>| >> -| ARM| Cortex-A57 | #852523 | N/A >>| >> -| ARM| Cortex-A57 | #834220 | ARM64_ERRATUM_834220 >>| >> -| ARM| Cortex-A72 | #853709 | N/A >>| >> -| ARM| MMU-500 | #841119,#826419 | N/A >>| >> -|| | | >>| >> -| Cavium | ThunderX ITS| #22375, #24313 | CAVIUM_ERRATUM_22375 >>| >> -| Cavium | ThunderX ITS| #23144 | CAVIUM_ERRATUM_23144 >>| >> -| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 >>| >> -| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 >>| >> -| Cavium | ThunderX SMMUv2 | #27704 | N/A | >> -|| | | >>| >> -| Freescale/NXP | LS2080A/LS1043A | A-008585| FSL_ERRATUM_A008585 >>| >> +| Implementor | Component | Erratum ID | Kconfig >>| >> ++---+-+-+--+ >> +| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 >>| >> +| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 >>| >> +| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 >>| >> +| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 >>| >> +| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 >>| >> +| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 >>| >> +| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 >>| >> +| ARM | Cortex-A57 | #852523 | N/A >>| >> +| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 >>| >> +| ARM | Cortex-A72 | #853709 | N/A >>| >> +| ARM | MMU-500 | #841119,#826419 | N/A >>| >> +| | | | >>| >> +| Cavium| ThunderX ITS| #22375, #24313 | CAVIUM_ERRATUM_22375 >>| >> +| Cavium| ThunderX ITS| #23144 | CAVIUM_ERRATUM_23144 >>| >> +| Cavium| ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 >>| >> +| Cavium| ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 >>| >> +| Cavium| ThunderX SMMUv2 | #27704 | N/A >>| >> +| | | | >>| >> +| Freescale/NXP | LS2080A/LS1043A | A-008585| FSL_ERRATUM_A008585 >>| >> +| Qualcomm | Falkor v1 | E1003 | >> QCOM_FALKOR_ERRATUM_1003 | > > Looks like you've made an unrelated whitespace change that affected the > entire table, > not just the line you're adding. I'm making space for "QCOM_FALKOR_ERRATUM_1003". Cov -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/06/2017 07:32 AM, Khalid Aziz wrote: > I agree with you on simplicity first. Subpage granularity is complex, > but the architecture allows for subpage granularity. Maybe the right > approach is to support this at page granularity first for swappable > pages and then expand to subpage granularity in a subsequent patch? > Pages locked in memory can already use subpage granularity with my patch. What do you mean by "locked in memory"? mlock()'d memory can still be migrated around and still requires "swap" ptes, for instance. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/06/2017 02:19 AM, Michal Hocko wrote: On Thu 05-01-17 13:30:10, Khalid Aziz wrote: [...] It is very tempting to restrict tags to PAGE_SIZE granularity since it makes code noticeably simpler and that is indeed going to be the majority of cases. Sooner or later somebody would want to use multiple tags per page though. I didn't get to read the patch throughly yet but I am really confused by this statement. The api is mprotect based which makes it ineherently PAGE_SIZE granular. How do you want to achieve cache line granularity with this API? And I would really vote for simplicity first... Subpage granularity sounds way too tricky... Hi Michal, ADI can be enabled for subsets of a task's address space. It takes three steps to enable ADI completely: 1. Enable the task to use ADI by setting PSTATE.mcde bit. This is the master switch for ADI. mprotect() does this in my patch. Granularity for this operation is entire address space for the task. 2. Set TTE.mcd bit for each page translation for the pages one wants ADI enabled on. mprotect() does this as well in my patch. Granularity for this operation is per page. 3. Set version tag for the addresses task wants to enable ADI on using "stxa" instruction. This is done entirely in userspace with no assistance or intervention needed from the kernel. Granularity for this operation is cache line size which is 64 bytes on Sparc M7. I agree with you on simplicity first. Subpage granularity is complex, but the architecture allows for subpage granularity. Maybe the right approach is to support this at page granularity first for swappable pages and then expand to subpage granularity in a subsequent patch? Pages locked in memory can already use subpage granularity with my patch. Thanks, Khalid -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/livepatch: remove the limitation for schedule() patching
On Fri, 6 Jan 2017, Petr Mladek wrote:
> On Fri 2017-01-06 15:00:45, Miroslav Benes wrote:
> > The Limitations section of the documentation describes the impossibility
> > to livepatch anything that is inlined to __schedule() function. This had
> > been true till 4.9 kernel came. Thanks to commit 0100301bfdf5
> > ("sched/x86: Rewrite the switch_to() code") from Brian Gerst there is
> > __switch_to_asm function now (implemented in assembly) called properly
> > from context_switch(). RIP is thus saved on the stack and a task would
> > return to proper version of __schedule() et al. functions.
> >
> > Of course __switch_to_asm() is not patchable for the reason described in
> > the section. But there is no __fentry__ call and I cannot imagine a
> > reason to do it anyway.
> >
> > Therefore, remove the paragraphs from the section.
> >
> > Signed-off-by: Miroslav Benes
>
> It is great to get a feature for free ;-)
>
> Reviewed-by: Petr Mladek
>
> Best Regards,
> Petr
>
> ---
> > FWIW, I also tested this to be sure on top of the consistency model
> > patch set. I patched schedule() function which calls __schedule() (it is
> > impossible to patch it directly due to notrace attribute). It works well
> > except...
> >
> > 1. the patching process does not finish, because many tasks sleep in
> > schedule. STOP/CONT signal does not help. I'll investigate.
>
> Are these userspace processes or kthreads? Kthreads would cause
> problems because they do not handle signals.
Userspace processes, but I take it back. Stupid typo in my script. It
works as expected. Kthreads sleeping in schedule() are of course there and
a signal does not help.
Miroslav
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/livepatch: remove the limitation for schedule() patching
On Fri 2017-01-06 15:00:45, Miroslav Benes wrote:
> The Limitations section of the documentation describes the impossibility
> to livepatch anything that is inlined to __schedule() function. This had
> been true till 4.9 kernel came. Thanks to commit 0100301bfdf5
> ("sched/x86: Rewrite the switch_to() code") from Brian Gerst there is
> __switch_to_asm function now (implemented in assembly) called properly
> from context_switch(). RIP is thus saved on the stack and a task would
> return to proper version of __schedule() et al. functions.
>
> Of course __switch_to_asm() is not patchable for the reason described in
> the section. But there is no __fentry__ call and I cannot imagine a
> reason to do it anyway.
>
> Therefore, remove the paragraphs from the section.
>
> Signed-off-by: Miroslav Benes
It is great to get a feature for free ;-)
Reviewed-by: Petr Mladek
Best Regards,
Petr
---
> FWIW, I also tested this to be sure on top of the consistency model
> patch set. I patched schedule() function which calls __schedule() (it is
> impossible to patch it directly due to notrace attribute). It works well
> except...
>
> 1. the patching process does not finish, because many tasks sleep in
> schedule. STOP/CONT signal does not help. I'll investigate.
Are these userspace processes or kthreads? Kthreads would cause
problems because they do not handle signals.
> 2. reversion of the process does not work as expected. The kernel
> crashes after the removal of the module. A task very likely slept in
> schedule and was not migrated properly. It might be because of the races
> in klp_reverse_transition() described by Petr, or might be somewhere
> else. I'll look into it.
I hope that I will be able to do another dive into the consistency
model patchset the following week.
Best Regards,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation/livepatch: remove the limitation for schedule() patching
The Limitations section of the documentation describes the impossibility
to livepatch anything that is inlined to __schedule() function. This had
been true till 4.9 kernel came. Thanks to commit 0100301bfdf5
("sched/x86: Rewrite the switch_to() code") from Brian Gerst there is
__switch_to_asm function now (implemented in assembly) called properly
from context_switch(). RIP is thus saved on the stack and a task would
return to proper version of __schedule() et al. functions.
Of course __switch_to_asm() is not patchable for the reason described in
the section. But there is no __fentry__ call and I cannot imagine a
reason to do it anyway.
Therefore, remove the paragraphs from the section.
Signed-off-by: Miroslav Benes
---
FWIW, I also tested this to be sure on top of the consistency model
patch set. I patched schedule() function which calls __schedule() (it is
impossible to patch it directly due to notrace attribute). It works well
except...
1. the patching process does not finish, because many tasks sleep in
schedule. STOP/CONT signal does not help. I'll investigate.
2. reversion of the process does not work as expected. The kernel
crashes after the removal of the module. A task very likely slept in
schedule and was not migrated properly. It might be because of the races
in klp_reverse_transition() described by Petr, or might be somewhere
else. I'll look into it.
Documentation/livepatch/livepatch.txt | 19 ---
1 file changed, 19 deletions(-)
diff --git a/Documentation/livepatch/livepatch.txt
b/Documentation/livepatch/livepatch.txt
index f5967316deb9..7f04e13ec53d 100644
--- a/Documentation/livepatch/livepatch.txt
+++ b/Documentation/livepatch/livepatch.txt
@@ -329,25 +329,6 @@ See Documentation/ABI/testing/sysfs-kernel-livepatch for
more details.
by "notrace".
- + Anything inlined into __schedule() can not be patched.
-
-The switch_to macro is inlined into __schedule(). It switches the
-context between two processes in the middle of the macro. It does
-not save RIP in x86_64 version (contrary to 32-bit version). Instead,
-the currently used __schedule()/switch_to() handles both processes.
-
-Now, let's have two different tasks. One calls the original
-__schedule(), its registers are stored in a defined order and it
-goes to sleep in the switch_to macro and some other task is restored
-using the original __schedule(). Then there is the second task which
-calls patched__schedule(), it goes to sleep there and the first task
-is picked by the patched__schedule(). Its RSP is restored and now
-the registers should be restored as well. But the order is different
-in the new patched__schedule(), so...
-
-There is work in progress to remove this limitation.
-
-
+ Livepatch modules can not be removed.
The current implementation just redirects the functions at the very
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/18] arm64: ilp32: introduce binfmt_ilp32.c
On Thu, Dec 22, 2016 at 12:26:40AM +0530, Yury Norov wrote: > On Mon, Dec 05, 2016 at 03:38:01PM +, Catalin Marinas wrote: > > On Fri, Oct 21, 2016 at 11:33:09PM +0300, Yury Norov wrote: > > > binfmt_ilp32.c is needed to handle ILP32 binaries > > > > > > Signed-off-by: Yury Norov > > > Signed-off-by: Bamvor Zhang Jian > > > --- > > > arch/arm64/include/asm/elf.h | 6 +++ > > > arch/arm64/kernel/Makefile | 1 + > > > arch/arm64/kernel/binfmt_ilp32.c | 97 > > > > > > 3 files changed, 104 insertions(+) > > > create mode 100644 arch/arm64/kernel/binfmt_ilp32.c > > > > > > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h > > > index f259fe8..be29dde 100644 > > > --- a/arch/arm64/include/asm/elf.h > > > +++ b/arch/arm64/include/asm/elf.h > > > @@ -175,10 +175,16 @@ extern int arch_setup_additional_pages(struct > > > linux_binprm *bprm, > > > > > > #define COMPAT_ELF_ET_DYN_BASE (2 * TASK_SIZE_32 / 3) > > > > > > +#ifndef USE_AARCH64_GREG > > > /* AArch32 registers. */ > > > #define COMPAT_ELF_NGREG 18 > > > typedef unsigned int compat_elf_greg_t; > > > typedef compat_elf_greg_t > > > compat_elf_gregset_t[COMPAT_ELF_NGREG]; > > > +#else /* AArch64 registers for AARCH64/ILP32 */ > > > +#define COMPAT_ELF_NGREG ELF_NGREG > > > +#define compat_elf_greg_telf_greg_t > > > +#define compat_elf_gregset_t elf_gregset_t > > > +#endif > > > > I think you only need compat_elf_gregset_t definition here and leave the > > other two undefined. > > I checked everything here again, and found that almost all compat defines > may be moved to corresponding binfmt files. If everything is OK, I'll > incorporate next patch to the series It seems fine at a quick look but I'll have to see the final patch. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64
On Sun, Dec 18, 2016 at 12:38:23PM +0530, Yury Norov wrote: > On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote: > > This series enables aarch64 with ilp32 mode, and as supporting work, > > introduces ARCH_32BIT_OFF_T configuration option that is enabled for > > existing 32-bit architectures but disabled for new arches (so 64-bit > > off_t is is used by new userspace). > > > > This version is based on kernel v4.9-rc1. It works with glibc-2.24, > > and tested with LTP. > > Hi Arnd, Catalin > > For last few days I'm trying to rebase this series on current master, > and I see significant conflicts and regressions. In fact, every time > I rebase on next rc1, I feel like I play a roulette. > > This is not a significant problem now because it's almost for sure > that this series will not get into 4.10, for reasons not related to > kernel code. And I have time to deal with regressions. But in general, > I'd like to try my patches on top of other candidates for next merge > window. I cannot read all emails in LKML, but I can easily detect > problems and join to the discussion at early stage if I see any problem. > > This is probably a noob question, and there are well-known branches, > like Andrew Morton's one. But at this stage it's very important to > have this series prepared for merge, and I'd prefer to ask about it. I'm not entirely sure what the question is. For development, you could base your series on a final release, e.g. 4.9. For reviews and especially if you are targeting a certain merging window, it's useful to rebase your patches on a fairly recent -rc, e.g. 4.10-rc3. I would entirely skip any non-tagged kernel states (like middle of the merging window) or out of tree branches. There may be a case to rebase on some other developer's branch but only if there is a dependency that can't be avoided and usually with prior agreement from both the respective developer (as not to rebase the branch) and the involved maintainers. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
On Fri, Jan 06, 2017 at 02:10:03AM +0530, Yury Norov wrote: > On Wed, Dec 07, 2016 at 09:40:13PM +0100, Arnd Bergmann wrote: > > On Wednesday, December 7, 2016 4:59:13 PM CET Catalin Marinas wrote: > > > On Tue, Dec 06, 2016 at 11:55:08AM +0530, Yury Norov wrote: > > > > On Mon, Dec 05, 2016 at 04:34:23PM +, Catalin Marinas wrote: > > > > > On Fri, Oct 21, 2016 at 11:33:15PM +0300, Yury Norov wrote: > > > > > > New aarch32 ptrace syscall handler is introduced to avoid run-time > > > > > > detection of the task type. > > > > > > > > > > What's wrong with the run-time detection? If it's just to avoid a > > > > > negligible overhead, I would rather keep the code simpler by avoiding > > > > > duplicating the generic compat_sys_ptrace(). > > > > > > > > Nothing wrong. This is how Arnd asked me to do. You already asked this > > > > question: http://lkml.iu.edu/hypermail/linux/kernel/1604.3/00930.html > > > > > > Hmm, I completely forgot about this ;). There is still an advantage to > > > doing run-time checking if we avoid touching core code (less acks to > > > gather and less code duplication). > > > > > > Let's see what Arnd says but the initial patch looked simpler. > > > > I don't currently have either version of the patch in my inbox > > (the archive is on a different machine), but in general I'd still > > think it's best to avoid the runtime check for aarch64-ilp32 > > altogether. I'd have to look at the overall kernel source to > > see if it's worth avoiding one or two instances though, or > > if there are an overwhelming number of other checks that we > > can't avoid at all. > > > > Regarding ptrace, I notice that arch/tile doesn't even use > > the compat entry point for its ilp32 user space on 64-bit > > kernels, it just calls the regular 64-bit one. Would that > > help here? > > ILP32 tasks has unique context that is not like aarch64 or aarch32, > so we have to have unique ptrace handler. I prepared the patch for > ptrace with runtime ABI detection, as Catalin said, see there: > https://github.com/norov/linux/commit/1f66dc22a4450b192e83458f2c3cc0e79f53e670 > > If it's OK, I'd like to update submission. This looks better to me (and even better if you no longer need to touch the generic ptrace code). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/7] x86: put msr-index.h in uapi
On Fri, Jan 06, 2017 at 10:43:56AM +0100, Nicolas Dichtel wrote: > This header file is exported, thus move it to uapi. It should rather not be exported - please remove it from arch/x86/include/uapi/asm/Kbuild instead. Thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] Makefile.headersinst: remove destination-y option
This option was added in commit c7bb349e7c25 ("kbuild: introduce destination-y
for exported headers") but never used in-tree.
Signed-off-by: Nicolas Dichtel
---
Documentation/kbuild/makefiles.txt | 23 ---
scripts/Makefile.headersinst | 2 +-
2 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/Documentation/kbuild/makefiles.txt
b/Documentation/kbuild/makefiles.txt
index 9b9c4797fc55..37b525d329ae 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -46,9 +46,8 @@ This document describes the Linux kernel Makefiles.
=== 7 Kbuild syntax for exported headers
--- 7.1 header-y
--- 7.2 genhdr-y
- --- 7.3 destination-y
- --- 7.4 generic-y
- --- 7.5 generated-y
+ --- 7.3 generic-y
+ --- 7.4 generated-y
=== 8 Kbuild Variables
=== 9 Makefile language
@@ -1295,21 +1294,7 @@ See subsequent chapter for the syntax of the Kbuild file.
#include/linux/Kbuild
genhdr-y += version.h
- --- 7.3 destination-y
-
- When an architecture has a set of exported headers that needs to be
- exported to a different directory destination-y is used.
- destination-y specifies the destination directory for all exported
- headers in the file where it is present.
-
- Example:
- #arch/xtensa/platforms/s6105/include/platform/Kbuild
- destination-y := include/linux
-
- In the example above all exported headers in the Kbuild file
- will be located in the directory "include/linux" when exported.
-
- --- 7.4 generic-y
+ --- 7.3 generic-y
If an architecture uses a verbatim copy of a header from
include/asm-generic then this is listed in the file
@@ -1336,7 +1321,7 @@ See subsequent chapter for the syntax of the Kbuild file.
Example: termios.h
#include
- --- 7.5 generated-y
+ --- 7.4 generated-y
If an architecture generates other header files alongside generic-y
wrappers, and not included in genhdr-y, then generated-y specifies
diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 3e20d03432d2..876b42cfede4 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -14,7 +14,7 @@ kbuild-file := $(srctree)/$(obj)/Kbuild
include $(kbuild-file)
# called may set destination dir (when installing to asm/)
-_dst := $(if $(destination-y),$(destination-y),$(if $(dst),$(dst),$(obj)))
+_dst := $(if $(dst),$(dst),$(obj))
old-kbuild-file := $(srctree)/$(subst uapi/,,$(obj))/Kbuild
ifneq ($(wildcard $(old-kbuild-file)),)
--
2.8.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/7] h8300: put bitsperlong.h in uapi
This header file is exported, thus move it to uapi. Signed-off-by: Nicolas Dichtel --- arch/h8300/include/asm/bitsperlong.h | 10 +- arch/h8300/include/uapi/asm/bitsperlong.h | 14 ++ 2 files changed, 15 insertions(+), 9 deletions(-) create mode 100644 arch/h8300/include/uapi/asm/bitsperlong.h diff --git a/arch/h8300/include/asm/bitsperlong.h b/arch/h8300/include/asm/bitsperlong.h index e140e46729ac..c0a8e2ee531e 100644 --- a/arch/h8300/include/asm/bitsperlong.h +++ b/arch/h8300/include/asm/bitsperlong.h @@ -1,14 +1,6 @@ #ifndef __ASM_H8300_BITS_PER_LONG #define __ASM_H8300_BITS_PER_LONG -#include - -#if !defined(__ASSEMBLY__) -/* h8300-unknown-linux required long */ -#define __kernel_size_t __kernel_size_t -typedef unsigned long __kernel_size_t; -typedef long __kernel_ssize_t; -typedef long __kernel_ptrdiff_t; -#endif +#include #endif /* __ASM_H8300_BITS_PER_LONG */ diff --git a/arch/h8300/include/uapi/asm/bitsperlong.h b/arch/h8300/include/uapi/asm/bitsperlong.h new file mode 100644 index ..e56cf72369b6 --- /dev/null +++ b/arch/h8300/include/uapi/asm/bitsperlong.h @@ -0,0 +1,14 @@ +#ifndef _UAPI_ASM_H8300_BITS_PER_LONG +#define _UAPI_ASM_H8300_BITS_PER_LONG + +#include + +#if !defined(__ASSEMBLY__) +/* h8300-unknown-linux required long */ +#define __kernel_size_t __kernel_size_t +typedef unsigned long __kernel_size_t; +typedef long __kernel_ssize_t; +typedef long __kernel_ptrdiff_t; +#endif + +#endif /* _UAPI_ASM_H8300_BITS_PER_LONG */ -- 2.8.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/7] Makefile.headersinst: cleanup input files
After the last four patches, all exported headers are under uapi/, thus input-files2 are not needed anymore. The side effect is that input-files1-name is exactly header-y. Note also that unput-files3-name is genhdr-y. Signed-off-by: Nicolas Dichtel --- scripts/Makefile.headersinst | 34 +++--- 1 file changed, 11 insertions(+), 23 deletions(-) diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst index 1106d6ca3a38..3e20d03432d2 100644 --- a/scripts/Makefile.headersinst +++ b/scripts/Makefile.headersinst @@ -40,31 +40,20 @@ wrapper-files := $(filter $(header-y), $(generic-y)) srcdir:= $(srctree)/$(obj) gendir:= $(objtree)/$(gen) -oldsrcdir := $(srctree)/$(subst /uapi,,$(obj)) - # all headers files for this dir header-y := $(filter-out $(generic-y), $(header-y)) all-files := $(header-y) $(genhdr-y) $(wrapper-files) output-files := $(addprefix $(installdir)/, $(all-files)) -input-files1 := $(foreach hdr, $(header-y), \ - $(if $(wildcard $(srcdir)/$(hdr)), \ - $(wildcard $(srcdir)/$(hdr))) \ - ) -input-files1-name := $(notdir $(input-files1)) -input-files2 := $(foreach hdr, $(header-y), \ - $(if $(wildcard $(srcdir)/$(hdr)),, \ - $(if $(wildcard $(oldsrcdir)/$(hdr)), \ - $(wildcard $(oldsrcdir)/$(hdr)), \ - $(error Missing UAPI file $(srcdir)/$(hdr))) \ - )) -input-files2-name := $(notdir $(input-files2)) -input-files3 := $(foreach hdr, $(genhdr-y), \ - $(if $(wildcard $(gendir)/$(hdr)), \ - $(wildcard $(gendir)/$(hdr)), \ - $(error Missing generated UAPI file $(gendir)/$(hdr)) \ - )) -input-files3-name := $(notdir $(input-files3)) +# Check that all expected files exist +$(foreach hdr, $(header-y), \ + $(if $(wildcard $(srcdir)/$(hdr)),, \ + $(error Missing UAPI file $(srcdir)/$(hdr)) \ + )) +$(foreach hdr, $(genhdr-y), \ + $(if $(wildcard $(gendir)/$(hdr)),, \ + $(error Missing generated UAPI file $(gendir)/$(hdr)) \ + )) # Work out what needs to be removed oldheaders:= $(patsubst $(installdir)/%,%,$(wildcard $(installdir)/*.h)) @@ -78,9 +67,8 @@ printdir = $(patsubst $(INSTALL_HDR_PATH)/%/,%,$(dir $@)) quiet_cmd_install = INSTALL $(printdir) ($(words $(all-files))\ file$(if $(word 2, $(all-files)),s)) cmd_install = \ -$(CONFIG_SHELL) $< $(installdir) $(srcdir) $(input-files1-name); \ -$(CONFIG_SHELL) $< $(installdir) $(oldsrcdir) $(input-files2-name); \ -$(CONFIG_SHELL) $< $(installdir) $(gendir) $(input-files3-name); \ +$(CONFIG_SHELL) $< $(installdir) $(srcdir) $(header-y); \ +$(CONFIG_SHELL) $< $(installdir) $(gendir) $(genhdr-y); \ for F in $(wrapper-files); do \ echo "\#include " > $(installdir)/$$F;\ done; \ -- 2.8.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/7] x86: put msr-index.h in uapi
This header file is exported, thus move it to uapi. Signed-off-by: Nicolas Dichtel --- arch/x86/include/asm/msr-index.h | 694 + arch/x86/include/uapi/asm/msr-index.h | 698 ++ 2 files changed, 699 insertions(+), 693 deletions(-) create mode 100644 arch/x86/include/uapi/asm/msr-index.h diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h index 710273c617b8..1baa0628da74 100644 --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -1,698 +1,6 @@ #ifndef _ASM_X86_MSR_INDEX_H #define _ASM_X86_MSR_INDEX_H -/* - * CPU model specific register (MSR) numbers. - * - * Do not add new entries to this file unless the definitions are shared - * between multiple compilation units. - */ - -/* x86-64 specific MSRs */ -#define MSR_EFER 0xc080 /* extended feature register */ -#define MSR_STAR 0xc081 /* legacy mode SYSCALL target */ -#define MSR_LSTAR 0xc082 /* long mode SYSCALL target */ -#define MSR_CSTAR 0xc083 /* compat mode SYSCALL target */ -#define MSR_SYSCALL_MASK 0xc084 /* EFLAGS mask for syscall */ -#define MSR_FS_BASE0xc100 /* 64bit FS base */ -#define MSR_GS_BASE0xc101 /* 64bit GS base */ -#define MSR_KERNEL_GS_BASE 0xc102 /* SwapGS GS shadow */ -#define MSR_TSC_AUX0xc103 /* Auxiliary TSC */ - -/* EFER bits: */ -#define _EFER_SCE 0 /* SYSCALL/SYSRET */ -#define _EFER_LME 8 /* Long mode enable */ -#define _EFER_LMA 10 /* Long mode active (read-only) */ -#define _EFER_NX 11 /* No execute enable */ -#define _EFER_SVME 12 /* Enable virtualization */ -#define _EFER_LMSLE13 /* Long Mode Segment Limit Enable */ -#define _EFER_FFXSR14 /* Enable Fast FXSAVE/FXRSTOR */ - -#define EFER_SCE (1<<_EFER_SCE) -#define EFER_LME (1<<_EFER_LME) -#define EFER_LMA (1<<_EFER_LMA) -#define EFER_NX(1<<_EFER_NX) -#define EFER_SVME (1<<_EFER_SVME) -#define EFER_LMSLE (1<<_EFER_LMSLE) -#define EFER_FFXSR (1<<_EFER_FFXSR) - -/* Intel MSRs. Some also available on other CPUs */ - -#define MSR_PPIN_CTL 0x004e -#define MSR_PPIN 0x004f - -#define MSR_IA32_PERFCTR0 0x00c1 -#define MSR_IA32_PERFCTR1 0x00c2 -#define MSR_FSB_FREQ 0x00cd -#define MSR_PLATFORM_INFO 0x00ce - -#define MSR_NHM_SNB_PKG_CST_CFG_CTL0x00e2 -#define NHM_C3_AUTO_DEMOTE (1UL << 25) -#define NHM_C1_AUTO_DEMOTE (1UL << 26) -#define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25) -#define SNB_C1_AUTO_UNDEMOTE (1UL << 27) -#define SNB_C3_AUTO_UNDEMOTE (1UL << 28) - -#define MSR_MTRRcap0x00fe -#define MSR_IA32_BBL_CR_CTL0x0119 -#define MSR_IA32_BBL_CR_CTL3 0x011e - -#define MSR_IA32_SYSENTER_CS 0x0174 -#define MSR_IA32_SYSENTER_ESP 0x0175 -#define MSR_IA32_SYSENTER_EIP 0x0176 - -#define MSR_IA32_MCG_CAP 0x0179 -#define MSR_IA32_MCG_STATUS0x017a -#define MSR_IA32_MCG_CTL 0x017b -#define MSR_IA32_MCG_EXT_CTL 0x04d0 - -#define MSR_OFFCORE_RSP_0 0x01a6 -#define MSR_OFFCORE_RSP_1 0x01a7 -#define MSR_TURBO_RATIO_LIMIT 0x01ad -#define MSR_TURBO_RATIO_LIMIT1 0x01ae -#define MSR_TURBO_RATIO_LIMIT2 0x01af - -#define MSR_LBR_SELECT 0x01c8 -#define MSR_LBR_TOS0x01c9 -#define MSR_LBR_NHM_FROM 0x0680 -#define MSR_LBR_NHM_TO 0x06c0 -#define MSR_LBR_CORE_FROM 0x0040 -#define MSR_LBR_CORE_TO0x0060 - -#define MSR_LBR_INFO_0 0x0dc0 /* ... 0xddf for _31 */ -#define LBR_INFO_MISPRED BIT_ULL(63) -#define LBR_INFO_IN_TX BIT_ULL(62) -#define LBR_INFO_ABORT BIT_ULL(61) -#define LBR_INFO_CYCLES0x - -#define MSR_IA32_PEBS_ENABLE 0x03f1 -#define MSR_IA32_DS_AREA 0x0600 -#define MSR_IA32_PERF_CAPABILITIES 0x0345 -#define MSR_PEBS_LD_LAT_THRESHOLD 0x03f6 - -#define MSR_IA32_RTIT_CTL 0x0570 -#define MSR_IA32_RTIT_STATUS 0x0571 -#define MSR_IA32_RTIT_ADDR0_A 0x0580 -#define MSR_IA32_RTIT_ADDR0_B 0x0581 -#define MSR_IA32_RTIT_ADDR1_A 0x0582 -#define MSR_IA32_RTIT_ADDR1_B 0x0583 -#define MSR_IA32_RTIT_ADDR2_A 0x0584 -#define MSR_IA32_RTIT_ADDR2_B 0x0585 -#define MSR_IA32_RTIT_ADDR3_A 0x
[PATCH v2 0/7] uapi: export all headers under uapi directories
Here is the v2 of this series. The first 5 patches are just cleanup: some exported headers were still under a non-uapi directory. The patch 6 was spotted by code review: there is no in-tree user of this functionality. The last patch remove the use of header-y. Now all files under an uapi directory are exported. asm is a bit special, most of architectures export asm//include/uapi/asm only, but there is two exceptions: - cris which exports arch/cris/include/uapi/arch-v[10|32]; - tile which exports arch/tile/include/uapi/arch. Because I don't know if the output of 'make headers_install_all' can be changed, I introduce subdir-y in Kbuild file. The headers_install_all target copies all asm//include/uapi/asm to usr/include/asm- but arch/cris/include/uapi/arch-v[10|32] and arch/tile/include/uapi/arch are not prefixed (they are put asis in usr/include/). If it's acceptable to modify the output of 'make headers_install_all' to export asm headers in usr/include/asm-/asm, then I could remove this new subdir-y and exports everything under arch//include/uapi/. Note also that exported files for asm are a mix of files listed by: - include/uapi/asm-generic/Kbuild.asm; - arch/x86/include/uapi/asm/Kbuild; - arch/x86/include/asm/Kbuild. This complicates a lot the processing (arch/x86/include/asm/Kbuild is also used by scripts/Makefile.asm-generic). This series has been tested with a 'make headers_install' on x86 and a 'make headers_install_all'. I've checked the result of both commands. This patch is built against linus tree. I don't know if it should be made against antoher tree. Comments are welcomed, Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/7] uapi: export all headers under uapi directories
Regularly, when a new header is created in include/uapi/, the developer forgets to add it in the corresponding Kbuild file. This error is usually detected after the release is out. In fact, all headers under uapi directories should be exported, thus it's useless to have an exhaustive list. After this patch, the following files, which were not exported, are now exported (with make headers_install_all): asm-unicore32/shmparam.h asm-unicore32/ucontext.h asm-hexagon/shmparam.h asm-mips/ucontext.h asm-mips/hwcap.h asm-mips/reg.h drm/vgem_drm.h drm/armada_drm.h drm/omap_drm.h drm/etnaviv_drm.h asm-tile/shmparam.h asm-blackfin/shmparam.h asm-blackfin/ucontext.h asm-powerpc/perf_regs.h rdma/qedr-abi.h asm-parisc/kvm_para.h asm-openrisc/shmparam.h asm-nios2/kvm_para.h asm-nios2/ucontext.h asm-sh/kvm_para.h asm-sh/ucontext.h asm-xtensa/kvm_para.h asm-avr32/kvm_para.h asm-m32r/kvm_para.h asm-h8300/shmparam.h asm-h8300/ucontext.h asm-metag/kvm_para.h asm-metag/shmparam.h asm-metag/ucontext.h asm-m68k/kvm_para.h asm-m68k/shmparam.h linux/bcache.h linux/kvm.h linux/kvm_para.h linux/kfd_ioctl.h linux/cryptouser.h linux/kcm.h linux/kcov.h linux/seg6_iptunnel.h linux/stm.h linux/genwqe linux/genwqe/.install linux/genwqe/genwqe_card.h linux/genwqe/..install.cmd linux/seg6.h linux/cifs linux/cifs/.install linux/cifs/cifs_mount.h linux/cifs/..install.cmd linux/auto_dev-ioctl.h Thanks to Julien Floret for the tip to get all subdirs with a pure makefile command. Signed-off-by: Nicolas Dichtel --- Documentation/kbuild/makefiles.txt | 41 ++- arch/alpha/include/uapi/asm/Kbuild | 41 --- arch/arc/include/uapi/asm/Kbuild| 3 - arch/arm/include/uapi/asm/Kbuild| 17 - arch/arm64/include/uapi/asm/Kbuild | 18 -- arch/avr32/include/uapi/asm/Kbuild | 20 -- arch/blackfin/include/uapi/asm/Kbuild | 17 - arch/c6x/include/uapi/asm/Kbuild| 8 - arch/cris/include/uapi/arch-v10/arch/Kbuild | 5 - arch/cris/include/uapi/arch-v32/arch/Kbuild | 3 - arch/cris/include/uapi/asm/Kbuild | 43 +-- arch/frv/include/uapi/asm/Kbuild| 33 -- arch/h8300/include/uapi/asm/Kbuild | 28 -- arch/hexagon/include/asm/Kbuild | 3 - arch/hexagon/include/uapi/asm/Kbuild| 13 - arch/ia64/include/uapi/asm/Kbuild | 45 --- arch/m32r/include/uapi/asm/Kbuild | 31 -- arch/m68k/include/uapi/asm/Kbuild | 24 -- arch/metag/include/uapi/asm/Kbuild | 8 - arch/microblaze/include/uapi/asm/Kbuild | 32 -- arch/mips/include/uapi/asm/Kbuild | 37 --- arch/mn10300/include/uapi/asm/Kbuild| 32 -- arch/nios2/include/uapi/asm/Kbuild | 4 +- arch/openrisc/include/asm/Kbuild| 3 - arch/openrisc/include/uapi/asm/Kbuild | 8 - arch/parisc/include/uapi/asm/Kbuild | 28 -- arch/powerpc/include/uapi/asm/Kbuild| 45 --- arch/s390/include/uapi/asm/Kbuild | 52 --- arch/score/include/asm/Kbuild | 4 - arch/score/include/uapi/asm/Kbuild | 32 -- arch/sh/include/uapi/asm/Kbuild | 23 -- arch/sparc/include/uapi/asm/Kbuild | 48 --- arch/tile/include/asm/Kbuild| 3 - arch/tile/include/uapi/arch/Kbuild | 17 - arch/tile/include/uapi/asm/Kbuild | 19 +- arch/unicore32/include/uapi/asm/Kbuild | 6 - arch/x86/include/uapi/asm/Kbuild| 59 arch/xtensa/include/uapi/asm/Kbuild | 23 -- include/Kbuild | 2 - include/asm-generic/Kbuild.asm | 1 - include/scsi/fc/Kbuild | 0 include/uapi/Kbuild | 15 - include/uapi/asm-generic/Kbuild | 36 --- include/uapi/asm-generic/Kbuild.asm | 62 ++-- include/uapi/drm/Kbuild | 22 -- include/uapi/linux/Kbuild | 482 include/uapi/linux/android/Kbuild | 2 - include/uapi/linux/byteorder/Kbuild | 3 - include/uapi/linux/caif/Kbuild | 3 - include/uapi/linux/can/Kbuild | 6 - include/uapi/linux/dvb/Kbuild | 9 - include/uapi/linux/hdlc/Kbuild | 2 - include/uapi/linux/hsi/Kbuild | 2 - include/uapi/linux/iio/Kbuild | 3 - include/uapi/linux/isdn/Kbuild | 2 - include/uapi/linux/mmc/Kbuild | 2 - include/uapi/linux/netfilter/Kbuild | 89 - include/uapi/linux/netfilter/ipset/Kbuild | 5 - include/uapi/linux/netfilter_arp/Kbuild | 3 - include/uapi/linux/netfilter_bridge/Kbuild | 18 -- include/uapi/linux/netfilter_ipv4/Kbuild| 10 - include/uapi/linux/netfilter_ipv6/Kbuild| 13 - include/uapi/linux/nfsd/Kbuild | 6 - include/uapi/linux/raid/Kbuild | 3 - include/uapi/linux/spi/Kbuild
[PATCH v2 3/7] nios2: put setup.h in uapi
This header file is exported, thus move it to uapi. Signed-off-by: Nicolas Dichtel --- arch/nios2/include/asm/setup.h | 2 +- arch/nios2/include/uapi/asm/setup.h | 6 ++ 2 files changed, 7 insertions(+), 1 deletion(-) create mode 100644 arch/nios2/include/uapi/asm/setup.h diff --git a/arch/nios2/include/asm/setup.h b/arch/nios2/include/asm/setup.h index dcbf8cf1a344..d49e9e91bf55 100644 --- a/arch/nios2/include/asm/setup.h +++ b/arch/nios2/include/asm/setup.h @@ -19,7 +19,7 @@ #ifndef _ASM_NIOS2_SETUP_H #define _ASM_NIOS2_SETUP_H -#include +#include #ifndef __ASSEMBLY__ #ifdef __KERNEL__ diff --git a/arch/nios2/include/uapi/asm/setup.h b/arch/nios2/include/uapi/asm/setup.h new file mode 100644 index ..8d8285997ba8 --- /dev/null +++ b/arch/nios2/include/uapi/asm/setup.h @@ -0,0 +1,6 @@ +#ifndef _UAPI_ASM_NIOS2_SETUP_H +#define _UAPI_ASM_NIOS2_SETUP_H + +#include + +#endif /* _UAPI_ASM_NIOS2_SETUP_H */ -- 2.8.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7] arm: put types.h in uapi
This header file is exported, thus move it to uapi. Signed-off-by: Nicolas Dichtel --- arch/arm/include/asm/types.h | 36 +-- arch/arm/include/uapi/asm/types.h | 40 +++ 2 files changed, 41 insertions(+), 35 deletions(-) create mode 100644 arch/arm/include/uapi/asm/types.h diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h index a53cdb8f068c..c48fee3d7b3b 100644 --- a/arch/arm/include/asm/types.h +++ b/arch/arm/include/asm/types.h @@ -1,40 +1,6 @@ #ifndef _ASM_TYPES_H #define _ASM_TYPES_H -#include - -/* - * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as - * unambiguous on ARM as you would expect. For the types below, there is a - * difference on ARM between GCC built for bare metal ARM, GCC built for glibc - * and the kernel itself, which results in build errors if you try to build with - * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h' - * in order to use NEON intrinsics) - * - * As the typedefs for these types in 'stdint.h' are based on builtin defines - * supplied by GCC, we can tweak these to align with the kernel's idea of those - * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same - * source file (provided that -ffreestanding is used). - * - *int32_t uint32_t uintptr_t - * bare metal GCC longunsigned long unsigned int - * glibc GCC int unsigned int unsigned int - * kernel int unsigned int unsigned long - */ - -#ifdef __INT32_TYPE__ -#undef __INT32_TYPE__ -#define __INT32_TYPE__ int -#endif - -#ifdef __UINT32_TYPE__ -#undef __UINT32_TYPE__ -#define __UINT32_TYPE__unsigned int -#endif - -#ifdef __UINTPTR_TYPE__ -#undef __UINTPTR_TYPE__ -#define __UINTPTR_TYPE__ unsigned long -#endif +#include #endif /* _ASM_TYPES_H */ diff --git a/arch/arm/include/uapi/asm/types.h b/arch/arm/include/uapi/asm/types.h new file mode 100644 index ..9435a42f575e --- /dev/null +++ b/arch/arm/include/uapi/asm/types.h @@ -0,0 +1,40 @@ +#ifndef _UAPI_ASM_TYPES_H +#define _UAPI_ASM_TYPES_H + +#include + +/* + * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as + * unambiguous on ARM as you would expect. For the types below, there is a + * difference on ARM between GCC built for bare metal ARM, GCC built for glibc + * and the kernel itself, which results in build errors if you try to build with + * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h' + * in order to use NEON intrinsics) + * + * As the typedefs for these types in 'stdint.h' are based on builtin defines + * supplied by GCC, we can tweak these to align with the kernel's idea of those + * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same + * source file (provided that -ffreestanding is used). + * + *int32_t uint32_t uintptr_t + * bare metal GCC longunsigned long unsigned int + * glibc GCC int unsigned int unsigned int + * kernel int unsigned int unsigned long + */ + +#ifdef __INT32_TYPE__ +#undef __INT32_TYPE__ +#define __INT32_TYPE__ int +#endif + +#ifdef __UINT32_TYPE__ +#undef __UINT32_TYPE__ +#define __UINT32_TYPE__unsigned int +#endif + +#ifdef __UINTPTR_TYPE__ +#undef __UINTPTR_TYPE__ +#define __UINTPTR_TYPE__ unsigned long +#endif + +#endif /* _UAPI_ASM_TYPES_H */ -- 2.8.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On Thu 05-01-17 13:30:10, Khalid Aziz wrote: [...] > It is very tempting to restrict tags to PAGE_SIZE granularity since it makes > code noticeably simpler and that is indeed going to be the majority of > cases. Sooner or later somebody would want to use multiple tags per page > though. I didn't get to read the patch throughly yet but I am really confused by this statement. The api is mprotect based which makes it ineherently PAGE_SIZE granular. How do you want to achieve cache line granularity with this API? And I would really vote for simplicity first... Subpage granularity sounds way too tricky... -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
