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

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

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:

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

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

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:

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

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

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

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

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

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

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

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

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

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

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,

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

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|

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

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

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

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

[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

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

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

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

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

[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 +-

[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

[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 ---

[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

[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

[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

[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

[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