[rcu:rcu/next 42/42] kernel/rcu/tree_plugin.h:820:2: note: in expansion of macro 'pr_info'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next head: 07180bfca95f9819250887160a5ccc53119967a7 commit: 07180bfca95f9819250887160a5ccc53119967a7 [42/42] EXP rcu: Add ->qsmask to assertion config: x86_64-randconfig-x013-201806 (attached as .config)

[rcu:rcu/next 42/42] kernel/rcu/tree_plugin.h:820:2: note: in expansion of macro 'pr_info'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next head: 07180bfca95f9819250887160a5ccc53119967a7 commit: 07180bfca95f9819250887160a5ccc53119967a7 [42/42] EXP rcu: Add ->qsmask to assertion config: x86_64-randconfig-x013-201806 (attached as .config)

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

2018-02-16 7:11 GMT+00:00 Cyrill Gorcunov : > On Thu, Feb 15, 2018 at 11:29:42PM +, Andy Lutomirski wrote: > ... >> >>> +bool pti_handle_segment_not_present(long error_code) >> >>> +{ >> >>> + if (!static_cpu_has(X86_FEATURE_PTI)) >> >>> + return false;

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

2018-02-16 7:11 GMT+00:00 Cyrill Gorcunov : > On Thu, Feb 15, 2018 at 11:29:42PM +, Andy Lutomirski wrote: > ... >> >>> +bool pti_handle_segment_not_present(long error_code) >> >>> +{ >> >>> + if (!static_cpu_has(X86_FEATURE_PTI)) >> >>> + return false; >> >>> + >> >>> +

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

On Fri, Feb 16, 2018 at 09:09:30PM +, Luck, Tony wrote: > > That said, I'm not sure how many non-root users run the toolkit to > > extract their EFI certificates or check on the secure boot status of > > the system, but I suspect it might be non-zero: I can see the tinfoil > > hat people

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

On Fri, Feb 16, 2018 at 09:09:30PM +, Luck, Tony wrote: > > That said, I'm not sure how many non-root users run the toolkit to > > extract their EFI certificates or check on the secure boot status of > > the system, but I suspect it might be non-zero: I can see the tinfoil > > hat people

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

On Fri, Feb 16, 2018 at 2:02 PM Luck, Tony wrote: > > If the default is 600 then it makes sense to allow a privileged service to > > selectively make certain variables world readable at runtime. > As soon as you make one variable world readable you are vulnerable to > a

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

On Fri, Feb 16, 2018 at 2:02 PM Luck, Tony wrote: > > If the default is 600 then it makes sense to allow a privileged service to > > selectively make certain variables world readable at runtime. > As soon as you make one variable world readable you are vulnerable to > a local user launching a

Re: [PATCH 1/3] Kconfig: disable PROFILE_ALL_BRANCHES for compile testing

On Fri, 16 Feb 2018 22:41:11 +0100 Arnd Bergmann wrote: > This can easily double the time for compiling a driver but does not > provide any benefit for the compile tester, so it's better left disabled. > > In addition, any 'inline' function that is not also 'static' and that >

Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description

On 02/16/18 12:33, Taras Kondratiuk wrote: > Many of the Linux security/integrity features are dependent on file > metadata, stored as extended attributes (xattrs), for making decisions. > These features need to be initialized during initcall and enabled as > early as possible for complete

Re: [PATCH 1/3] Kconfig: disable PROFILE_ALL_BRANCHES for compile testing

On Fri, 16 Feb 2018 22:41:11 +0100 Arnd Bergmann wrote: > This can easily double the time for compiling a driver but does not > provide any benefit for the compile tester, so it's better left disabled. > > In addition, any 'inline' function that is not also 'static' and that > contains an 'if'

Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description

On 02/16/18 12:33, Taras Kondratiuk wrote: > Many of the Linux security/integrity features are dependent on file > metadata, stored as extended attributes (xattrs), for making decisions. > These features need to be initialized during initcall and enabled as > early as possible for complete

RE: [PATCH 0/2] efivars: reading variables can generate SMIs

> If the default is 600 then it makes sense to allow a privileged service to > selectively make certain variables world readable at runtime. As soon as you make one variable world readable you are vulnerable to a local user launching a DoS attack by reading that variable over and over generating

RE: [PATCH 0/2] efivars: reading variables can generate SMIs

> If the default is 600 then it makes sense to allow a privileged service to > selectively make certain variables world readable at runtime. As soon as you make one variable world readable you are vulnerable to a local user launching a DoS attack by reading that variable over and over generating

Re: [PATCH 03/11] fs: Allow superblock owner to change ownership of inodes

Miklos Szeredi writes: > On Fri, Dec 22, 2017 at 3:32 PM, Dongsu Park wrote: >> From: Eric W. Biederman >> >> Allow users with CAP_SYS_CHOWN over the superblock of a filesystem to >> chown files. Ordinarily the

Re: [PATCH 03/11] fs: Allow superblock owner to change ownership of inodes

Miklos Szeredi writes: > On Fri, Dec 22, 2017 at 3:32 PM, Dongsu Park wrote: >> From: Eric W. Biederman >> >> Allow users with CAP_SYS_CHOWN over the superblock of a filesystem to >> chown files. Ordinarily the capable_wrt_inode_uidgid check is >> sufficient to allow access to files but when

Re: [PATCH v21 1/5] xbitmap: Introduce xbitmap

On Fri, Feb 16, 2018 at 11:45:51PM +0200, Andy Shevchenko wrote: > Now, the question about test case. Why do you heavily use BUG_ON? > Isn't resulting statistics enough? No. If any of those tests fail, we want to stop dead. They'll lead to horrendous bugs throughout the kernel if they're wrong.

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

On Fri, Feb 16, 2018 at 1:45 PM Andy Lutomirski wrote: > I'm going to go out on a limb and suggest that the fact that > unprivileged users can read efi variables at all is a mistake > regardless of SMI issues. Why? They should never contain sensitive material. > Also, chmod()

Re: [PATCH v21 1/5] xbitmap: Introduce xbitmap

On Fri, Feb 16, 2018 at 11:45:51PM +0200, Andy Shevchenko wrote: > Now, the question about test case. Why do you heavily use BUG_ON? > Isn't resulting statistics enough? No. If any of those tests fail, we want to stop dead. They'll lead to horrendous bugs throughout the kernel if they're wrong.

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

On Fri, Feb 16, 2018 at 1:45 PM Andy Lutomirski wrote: > I'm going to go out on a limb and suggest that the fact that > unprivileged users can read efi variables at all is a mistake > regardless of SMI issues. Why? They should never contain sensitive material. > Also, chmod() just shouldn't

Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description

On Fri, 16 Feb 2018, Rob Landley wrote: On 02/16/2018 02:59 PM, H. Peter Anvin wrote: On 02/16/18 12:33, Taras Kondratiuk wrote: Many of the Linux security/integrity features are dependent on file metadata, stored as extended attributes (xattrs), for making decisions. These features need

Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description

On Fri, 16 Feb 2018, Rob Landley wrote: On 02/16/2018 02:59 PM, H. Peter Anvin wrote: On 02/16/18 12:33, Taras Kondratiuk wrote: Many of the Linux security/integrity features are dependent on file metadata, stored as extended attributes (xattrs), for making decisions. These features need

Re: [PATCH v5 00/11] FUSE mounts from non-init user namespaces

Miklos Szeredi writes: > On Fri, Dec 22, 2017 at 3:32 PM, Dongsu Park wrote: > >> Patches 1-2 deal with an additional flag of lookup_bdev() to check for >> additional inode permission. > > fuse_blk is less suitable for unprivileged mounting than plain

Re: [PATCH v5 00/11] FUSE mounts from non-init user namespaces

Miklos Szeredi writes: > On Fri, Dec 22, 2017 at 3:32 PM, Dongsu Park wrote: > >> Patches 1-2 deal with an additional flag of lookup_bdev() to check for >> additional inode permission. > > fuse_blk is less suitable for unprivileged mounting than plain fuse. > fusermount doesn't allow mounting

Re: [PATCH 08/11] fuse: Support fuse filesystems outside of init_user_ns

Miklos Szeredi writes: > On Mon, Feb 12, 2018 at 5:35 PM, Eric W. Biederman > wrote: >> Miklos Szeredi writes: >> >>> On Fri, Dec 22, 2017 at 3:32 PM, Dongsu Park wrote: From: Seth Forshee

Re: [PATCH 08/11] fuse: Support fuse filesystems outside of init_user_ns

Miklos Szeredi writes: > On Mon, Feb 12, 2018 at 5:35 PM, Eric W. Biederman > wrote: >> Miklos Szeredi writes: >> >>> On Fri, Dec 22, 2017 at 3:32 PM, Dongsu Park wrote: From: Seth Forshee In order to support mounts from namespaces other than init_user_ns, fuse must

Re: [RFC PATCH] usb: hcd: complete URBs in threaded-IRQ context instead of tasklet

On Fri, 16 Feb 2018, Sebastian Andrzej Siewior wrote: > On 2018-02-16 13:29:01 [-0500], Alan Stern wrote: > > We originally used tasklets because we didn't want to incur the delays > > associated with running in a process context. It seems odd to be > > reversing that decision now. > > The

Re: [RFC PATCH] usb: hcd: complete URBs in threaded-IRQ context instead of tasklet

On Fri, 16 Feb 2018, Sebastian Andrzej Siewior wrote: > On 2018-02-16 13:29:01 [-0500], Alan Stern wrote: > > We originally used tasklets because we didn't want to incur the delays > > associated with running in a process context. It seems odd to be > > reversing that decision now. > > The

[PATCH 2/2] Staging: gdm724x: LTE: Fix argument list not aligned with parenthesis.

Fix coding style warning from checkpatch.pl. Signed-off-by: Quytelda Kahja --- drivers/staging/gdm724x/gdm_lte.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/gdm724x/gdm_lte.c b/drivers/staging/gdm724x/gdm_lte.c index

[PATCH 2/2] Staging: gdm724x: LTE: Fix argument list not aligned with parenthesis.

Fix coding style warning from checkpatch.pl. Signed-off-by: Quytelda Kahja --- drivers/staging/gdm724x/gdm_lte.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/gdm724x/gdm_lte.c b/drivers/staging/gdm724x/gdm_lte.c index ff3fed9c4a81..26a81fdd0044 100644

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

On Fri, Feb 16, 2018 at 9:09 PM, Luck, Tony wrote: >> That said, I'm not sure how many non-root users run the toolkit to >> extract their EFI certificates or check on the secure boot status of >> the system, but I suspect it might be non-zero: I can see the tinfoil >> hat

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

On Fri, Feb 16, 2018 at 9:09 PM, Luck, Tony wrote: >> That said, I'm not sure how many non-root users run the toolkit to >> extract their EFI certificates or check on the secure boot status of >> the system, but I suspect it might be non-zero: I can see the tinfoil >> hat people wanting at least

Re: [PATCH v21 1/5] xbitmap: Introduce xbitmap

On Fri, Feb 16, 2018 at 8:30 PM, Matthew Wilcox wrote: > On Fri, Feb 16, 2018 at 07:44:50PM +0200, Andy Shevchenko wrote: >> On Tue, Jan 9, 2018 at 1:10 PM, Wei Wang wrote: >> > From: Matthew Wilcox >> > >> > The eXtensible

Re: [PATCH v21 1/5] xbitmap: Introduce xbitmap

On Fri, Feb 16, 2018 at 8:30 PM, Matthew Wilcox wrote: > On Fri, Feb 16, 2018 at 07:44:50PM +0200, Andy Shevchenko wrote: >> On Tue, Jan 9, 2018 at 1:10 PM, Wei Wang wrote: >> > From: Matthew Wilcox >> > >> > The eXtensible Bitmap is a sparse bitmap representation which is >> > efficient for

[PATCH 3/3] Kconfig: add a default allrandom.config

Building randconfig kernels frequently leads to build errors from drivers that have additional build dependencies, or that we don't want to build for compile-testing for some other reason. We already have a couple of compile-time options that can deal with this problem, but the complete set is

[PATCH 2/3] Kconfig: improve handling for all{rand,yes,no,}.config fragments

The kernel currently supports two methods of dealing with config fragments in the tree: a) Running "make foo.config" looks for arch/$(ARCH)/configs/foo.config and kernel/configs/foo.config, and applies the defaults from those files on top of the current configuration. b) Running

[PATCH 3/3] Kconfig: add a default allrandom.config

Building randconfig kernels frequently leads to build errors from drivers that have additional build dependencies, or that we don't want to build for compile-testing for some other reason. We already have a couple of compile-time options that can deal with this problem, but the complete set is

[PATCH 2/3] Kconfig: improve handling for all{rand,yes,no,}.config fragments

The kernel currently supports two methods of dealing with config fragments in the tree: a) Running "make foo.config" looks for arch/$(ARCH)/configs/foo.config and kernel/configs/foo.config, and applies the defaults from those files on top of the current configuration. b) Running

[PATCH 4/4] soc: ti: Add pm33xx driver for basic suspend support

AM335x and AM437x support various low power modes as documented in section 8.1.4.3 of the AM335x Technical Reference Manual and section 6.4.3 of the AM437x Technical Reference Manual. DeepSleep0 mode offers the lowest power mode with limited wakeup sources without a system reboot and is mapped as

[PATCH 4/4] soc: ti: Add pm33xx driver for basic suspend support

AM335x and AM437x support various low power modes as documented in section 8.1.4.3 of the AM335x Technical Reference Manual and section 6.4.3 of the AM437x Technical Reference Manual. DeepSleep0 mode offers the lowest power mode with limited wakeup sources without a system reboot and is mapped as

[PATCH 1/3] Kconfig: disable PROFILE_ALL_BRANCHES for compile testing

This can easily double the time for compiling a driver but does not provide any benefit for the compile tester, so it's better left disabled. In addition, any 'inline' function that is not also 'static' and that contains an 'if' causes a warning like include/linux/string.h:212:2: note: in

[PATCH 1/3] Kconfig: disable PROFILE_ALL_BRANCHES for compile testing

This can easily double the time for compiling a driver but does not provide any benefit for the compile tester, so it's better left disabled. In addition, any 'inline' function that is not also 'static' and that contains an 'if' causes a warning like include/linux/string.h:212:2: note: in

[PATCH 1/4] ARM: OMAP2+: Introduce low-level suspend code for AM33XX

In preparation for suspend-resume support for AM33XX, add the assembly file with the code which is copied to internal memory (OCMC RAM) during bootup and runs from there. As part of the low power entry (DeepSleep0 mode in AM33XX TRM), the code running from OCMC RAM does the following 1. Calls

[PATCH 1/4] ARM: OMAP2+: Introduce low-level suspend code for AM33XX

In preparation for suspend-resume support for AM33XX, add the assembly file with the code which is copied to internal memory (OCMC RAM) during bootup and runs from there. As part of the low power entry (DeepSleep0 mode in AM33XX TRM), the code running from OCMC RAM does the following 1. Calls

[PATCH 0/4] ARM: OMAP2+: AM33XX/AM43XX: Add suspend-resume support

Hi, This series contains the remaining code to enable suspend to mem and standby on am335x and am437x platforms. All dependencies have been merged and this is just a rebase on v4.16-rc1. For this to work on am437x-gp-evm this bug fix patch [1] is required but suspend works fine on am335x platforms

[PATCH 0/4] ARM: OMAP2+: AM33XX/AM43XX: Add suspend-resume support

Hi, This series contains the remaining code to enable suspend to mem and standby on am335x and am437x platforms. All dependencies have been merged and this is just a rebase on v4.16-rc1. For this to work on am437x-gp-evm this bug fix patch [1] is required but suspend works fine on am335x platforms

[PATCH 3/4] ARM: OMAP2+: pm33xx-core: Add platform code needed for PM

Most of the PM code needed for am335x and am437x can be moved into a module under drivers but some core code must remain in mach-omap2 at the moment. This includes some internal clockdomain APIs and low-level ARM APIs which are also not exported for use by modules. Implement a few functions that

[PATCH 3/4] ARM: OMAP2+: pm33xx-core: Add platform code needed for PM

Most of the PM code needed for am335x and am437x can be moved into a module under drivers but some core code must remain in mach-omap2 at the moment. This includes some internal clockdomain APIs and low-level ARM APIs which are also not exported for use by modules. Implement a few functions that

[PATCH 0/3] fixing the last failures in randconfig builds

I've recently done some build testing on 4.14-stable and to my surprise found only a handful of bugfixes were required to build all x86 and arm64 randconfig output without any warnings using gcc-7.2.1. I have submitted the remaining trivial patches now, and this is the non-trivial remaining part,

[PATCH 0/3] fixing the last failures in randconfig builds

I've recently done some build testing on 4.14-stable and to my surprise found only a handful of bugfixes were required to build all x86 and arm64 randconfig output without any warnings using gcc-7.2.1. I have submitted the remaining trivial patches now, and this is the non-trivial remaining part,

[PATCH 2/4] ARM: OMAP2+: Introduce low-level suspend code for AM43XX

Although similar to AM33XX, introduce a new low-level asm file for suspend containing new context save and restore paths for EMIF and l2 cache disabling and enabling. Signed-off-by: Dave Gerlach --- arch/arm/mach-omap2/sleep43xx.S | 393

[PATCH 2/4] ARM: OMAP2+: Introduce low-level suspend code for AM43XX

Although similar to AM33XX, introduce a new low-level asm file for suspend containing new context save and restore paths for EMIF and l2 cache disabling and enabling. Signed-off-by: Dave Gerlach --- arch/arm/mach-omap2/sleep43xx.S | 393 1 file changed,

[PATCH] Staging: gdm724x: LTE: Fix trailing open parenthesis code style issue.

Fix a coding style problem causing warnings from checkpatch.pl. Signed-off-by: Quytelda Kahja --- drivers/staging/gdm724x/gdm_lte.c | 50 ++- 1 file changed, 28 insertions(+), 22 deletions(-) diff --git

[PATCH] Staging: gdm724x: LTE: Fix trailing open parenthesis code style issue.

Fix a coding style problem causing warnings from checkpatch.pl. Signed-off-by: Quytelda Kahja --- drivers/staging/gdm724x/gdm_lte.c | 50 ++- 1 file changed, 28 insertions(+), 22 deletions(-) diff --git a/drivers/staging/gdm724x/gdm_lte.c

Re: [PATCH][V2] net: dsa: mv88e6xxx: avoid unintended sign extension on a 16 bit shift

From: Colin King Date: Fri, 16 Feb 2018 16:55:05 + > From: Colin Ian King > > The shifting of timehi by 16 bits to the left will be promoted to > a 32 bit signed int and then sign-extended to an u64. If the top bit > of timehi is set then

Re: [PATCH][V2] net: dsa: mv88e6xxx: avoid unintended sign extension on a 16 bit shift

From: Colin King Date: Fri, 16 Feb 2018 16:55:05 + > From: Colin Ian King > > The shifting of timehi by 16 bits to the left will be promoted to > a 32 bit signed int and then sign-extended to an u64. If the top bit > of timehi is set then all then all the upper bits of ns end up as also >

Re: [RFC PATCH] ptr_ring: linked list fallback

From: "Michael S. Tsirkin" Date: Fri, 16 Feb 2018 09:40:54 +0200 > So pointer rings work fine, but they have a problem: > make them too small and not enough entries fit. > Make them too large and you start flushing your cache > and running out of memory. > > This is a new idea

Re: [RFC PATCH] ptr_ring: linked list fallback

From: "Michael S. Tsirkin" Date: Fri, 16 Feb 2018 09:40:54 +0200 > So pointer rings work fine, but they have a problem: > make them too small and not enough entries fit. > Make them too large and you start flushing your cache > and running out of memory. > > This is a new idea of mine: a ring

Re: [PATCH v2 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

Hi Lina, On Thu, Feb 15, 2018 at 9:34 AM, Lina Iyer wrote: > Add controller driver for QCOM SoCs that have hardware based shared > resource management. The hardware IP known as RSC (Resource State > Coordinator) houses multiple Direct Resource Voter (DRV) for different >

[PATCH 2/3] nospec: Allow index argument to have const-qualified type

From: Rasmus Villemoes The last expression in a statement expression need not be a bare variable, quoting gcc docs The last thing in the compound statement should be an expression followed by a semicolon; the value of this subexpression serves as the value of the

[PATCH 3/3] nospec: Include asm/barrier.h dependency

The nospec.h header expects the per-architecture header file asm/barrier.h to optionally define array_index_mask_nospec(). Include that dependency to prevent inadvertent fallback to the default array_index_mask_nospec() implementation. The default implementation may not provide a full mitigation

[PATCH 2/3] nospec: Allow index argument to have const-qualified type

From: Rasmus Villemoes The last expression in a statement expression need not be a bare variable, quoting gcc docs The last thing in the compound statement should be an expression followed by a semicolon; the value of this subexpression serves as the value of the entire construct. and we

[PATCH 3/3] nospec: Include asm/barrier.h dependency

The nospec.h header expects the per-architecture header file asm/barrier.h to optionally define array_index_mask_nospec(). Include that dependency to prevent inadvertent fallback to the default array_index_mask_nospec() implementation. The default implementation may not provide a full mitigation

Re: [PATCH v2 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

Hi Lina, On Thu, Feb 15, 2018 at 9:34 AM, Lina Iyer wrote: > Add controller driver for QCOM SoCs that have hardware based shared > resource management. The hardware IP known as RSC (Resource State > Coordinator) houses multiple Direct Resource Voter (DRV) for different > execution levels. A DRV

[PATCH 1/3] nospec: Kill array_index_nospec_mask_check()

There are multiple problems with the dynamic sanity checking in array_index_nospec_mask_check(): * It causes unnecessary overhead in the 32-bit case since integer sized @index values will no longer cause the check to be compiled away like in the 64-bit case. * In the 32-bit case it may

[PATCH 0/3] nospec: Various fix-ups for include/linux/nospec.h

Hi Ingo, Here is a small pile of cleanups and fixes for nospec.h after inspection from Linus, Rasmus, and Christian. Full changelogs below: These have received a build success notification from 0day across 126 configs. --- Dan Williams (2): nospec: Kill array_index_nospec_mask_check()

[PATCH 0/3] nospec: Various fix-ups for include/linux/nospec.h

Hi Ingo, Here is a small pile of cleanups and fixes for nospec.h after inspection from Linus, Rasmus, and Christian. Full changelogs below: These have received a build success notification from 0day across 126 configs. --- Dan Williams (2): nospec: Kill array_index_nospec_mask_check()

[PATCH 1/3] nospec: Kill array_index_nospec_mask_check()

There are multiple problems with the dynamic sanity checking in array_index_nospec_mask_check(): * It causes unnecessary overhead in the 32-bit case since integer sized @index values will no longer cause the check to be compiled away like in the 64-bit case. * In the 32-bit case it may

Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description

On 02/16/2018 02:59 PM, H. Peter Anvin wrote: > On 02/16/18 12:33, Taras Kondratiuk wrote: >> Many of the Linux security/integrity features are dependent on file >> metadata, stored as extended attributes (xattrs), for making decisions. >> These features need to be initialized during initcall and

Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description

On 02/16/2018 02:59 PM, H. Peter Anvin wrote: > On 02/16/18 12:33, Taras Kondratiuk wrote: >> Many of the Linux security/integrity features are dependent on file >> metadata, stored as extended attributes (xattrs), for making decisions. >> These features need to be initialized during initcall and

Re: [PATCH v4] rtc: isl12026: Add driver.

On Fri, Feb 16, 2018 at 11:19 PM, David Daney wrote: > On 02/16/2018 12:13 PM, Andy Shevchenko wrote: >> On Fri, Feb 16, 2018 at 9:44 PM, David Daney >> wrote: >>> +config RTC_DRV_ISL12026 >>> + tristate "Intersil ISL12026" >> depends on

Re: [PATCH v4] rtc: isl12026: Add driver.

On Fri, Feb 16, 2018 at 11:19 PM, David Daney wrote: > On 02/16/2018 12:13 PM, Andy Shevchenko wrote: >> On Fri, Feb 16, 2018 at 9:44 PM, David Daney >> wrote: >>> +config RTC_DRV_ISL12026 >>> + tristate "Intersil ISL12026" >> depends on OF > It doesn't depend on CONFIG_OF, it builds

Re: [PATCH net] rxrpc: Work around usercopy check

From: David Howells Date: Thu, 15 Feb 2018 22:59:00 + > Due to a check recently added to copy_to_user(), it's now not permitted to > copy from slab-held data to userspace unless the slab is whitelisted. This > affects rxrpc_recvmsg() when it attempts to place an

Re: [PATCH net] rxrpc: Work around usercopy check

From: David Howells Date: Thu, 15 Feb 2018 22:59:00 + > Due to a check recently added to copy_to_user(), it's now not permitted to > copy from slab-held data to userspace unless the slab is whitelisted. This > affects rxrpc_recvmsg() when it attempts to place an RXRPC_USER_CALL_ID > control

Re: [PATCH v4] rtc: isl12026: Add driver.

On 02/16/2018 12:13 PM, Andy Shevchenko wrote: On Fri, Feb 16, 2018 at 9:44 PM, David Daney wrote: The ISL12026 is a combination RTC and EEPROM device with I2C interface. The standard RTC driver interface is provided. The EEPROM is accessed via the NVMEM interface via

Re: [PATCH v4] rtc: isl12026: Add driver.

On 02/16/2018 12:13 PM, Andy Shevchenko wrote: On Fri, Feb 16, 2018 at 9:44 PM, David Daney wrote: The ISL12026 is a combination RTC and EEPROM device with I2C interface. The standard RTC driver interface is provided. The EEPROM is accessed via the NVMEM interface via the "eeprom0" directory

Re: [PATCH v3 2/6] vfio/type1: Check reserve region conflict and update iova list

On Thu, 15 Feb 2018 09:45:00 + Shameer Kolothum wrote: > This retrieves the reserved regions associated with dev group and > checks for conflicts with any existing dma mappings. Also update > the iova list excluding the reserved regions. > >

Re: [PATCH v3 2/6] vfio/type1: Check reserve region conflict and update iova list

On Thu, 15 Feb 2018 09:45:00 + Shameer Kolothum wrote: > This retrieves the reserved regions associated with dev group and > checks for conflicts with any existing dma mappings. Also update > the iova list excluding the reserved regions. > > Signed-off-by: Shameer Kolothum > --- >

RE: [char-misc 4.16] mei: set device client to the disconnected state upon suspend.

> > On Wed, Feb 14, 2018 at 02:03:29PM +0200, Tomas Winkler wrote: > > This fixes regression introduced by > > commit 8d52af6795c0 ("mei: speed up the power down flow") > > In the future, put: > Fixes: 8d52af6795c0 ("mei: speed up the power down flow") > > in your signed-off-by area so

RE: [char-misc 4.16] mei: set device client to the disconnected state upon suspend.

> > On Wed, Feb 14, 2018 at 02:03:29PM +0200, Tomas Winkler wrote: > > This fixes regression introduced by > > commit 8d52af6795c0 ("mei: speed up the power down flow") > > In the future, put: > Fixes: 8d52af6795c0 ("mei: speed up the power down flow") > > in your signed-off-by area so

Re: [PATCH 0/3] Improve and extend checkpatch.pl Kconfig help text checks

On Fri, 2018-02-16 at 21:22 +0100, Ulf Magnusson wrote: > Hello, > > This patchset contains some improvements for the Kconfig help text check in > scripts/checkconfig.pl: Seems sensible enough to me. Signed-off-by: Joe Perches > - Commits 1 and 2 make the check more robust

Re: [PATCH 0/3] Improve and extend checkpatch.pl Kconfig help text checks

On Fri, 2018-02-16 at 21:22 +0100, Ulf Magnusson wrote: > Hello, > > This patchset contains some improvements for the Kconfig help text check in > scripts/checkconfig.pl: Seems sensible enough to me. Signed-off-by: Joe Perches > - Commits 1 and 2 make the check more robust by checking

RE: [PATCH 0/2] efivars: reading variables can generate SMIs

> That said, I'm not sure how many non-root users run the toolkit to > extract their EFI certificates or check on the secure boot status of > the system, but I suspect it might be non-zero: I can see the tinfoil > hat people wanting at least to check the secure boot status when they > log in.

RE: [PATCH 0/2] efivars: reading variables can generate SMIs

> That said, I'm not sure how many non-root users run the toolkit to > extract their EFI certificates or check on the secure boot status of > the system, but I suspect it might be non-zero: I can see the tinfoil > hat people wanting at least to check the secure boot status when they > log in.

[PATCH v2 5/9] lib/vsprintf: Move pointer_string() upper

As preparatory patch to further clean up. No functional change. Signed-off-by: Andy Shevchenko --- lib/vsprintf.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index

[PATCH v2 5/9] lib/vsprintf: Move pointer_string() upper

As preparatory patch to further clean up. No functional change. Signed-off-by: Andy Shevchenko --- lib/vsprintf.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index c789d265311b..87dbced51b1a 100644 ---

[PATCH v2 9/9] lib/vsprintf: Mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Andy Shevchenko --- lib/vsprintf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index

[PATCH v2 9/9] lib/vsprintf: Mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Andy Shevchenko --- lib/vsprintf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index a49da00b79e7..28d7aca6a805 100644 ---

[PATCH v2 3/9] lib/vsprintf: Make strspec global

There are places where default specification to print strings is in use. Make it global and convert existing users. Signed-off-by: Andy Shevchenko --- lib/vsprintf.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git

[PATCH v2 3/9] lib/vsprintf: Make strspec global

There are places where default specification to print strings is in use. Make it global and convert existing users. Signed-off-by: Andy Shevchenko --- lib/vsprintf.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index

[PATCH v2 6/9] lib/vsprintf: Deduplicate pointer_string()

There is an exact code at the end of ptr_to_id(). Replace it by calling pointer_string() directly. This is followup to the commit ad67b74d2469 ("printk: hash addresses printed with %p"). Cc: Tobin C. Harding Signed-off-by: Andy Shevchenko ---

[PATCH v2 2/9] lib/vsprintf: Make dec_spec global

There are places where default specification to print decimal numbers is in use. Make it global and convert existing users. Signed-off-by: Andy Shevchenko --- lib/vsprintf.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff

[PATCH v2 6/9] lib/vsprintf: Deduplicate pointer_string()

There is an exact code at the end of ptr_to_id(). Replace it by calling pointer_string() directly. This is followup to the commit ad67b74d2469 ("printk: hash addresses printed with %p"). Cc: Tobin C. Harding Signed-off-by: Andy Shevchenko --- lib/vsprintf.c | 27 +++

[PATCH v2 2/9] lib/vsprintf: Make dec_spec global

There are places where default specification to print decimal numbers is in use. Make it global and convert existing users. Signed-off-by: Andy Shevchenko --- lib/vsprintf.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/lib/vsprintf.c

[PATCH v2 1/9] lib/test_printf: Mark big constant with ULL

Sparse complains that constant is so bit for unsigned long on 64-bit architecture. lib/test_printf.c:217:54: warning: constant 0x0123456789ab is so big it is unsigned long lib/test_printf.c:246:54: warning: constant 0x0123456789ab is so big it is unsigned long To satisfy everyone, mark

[PATCH v2 7/9] lib/vsprintf: Replace space with '_' before crng is ready

From: Shunyong Yang Before crng is ready, output of "%p" composes of "(ptrval)" and left padding spaces for alignment as no random address can be generated. This seems a little strange when default string width is larger than strlen("(ptrval)"). For example, when

[PATCH v2 1/9] lib/test_printf: Mark big constant with ULL

Sparse complains that constant is so bit for unsigned long on 64-bit architecture. lib/test_printf.c:217:54: warning: constant 0x0123456789ab is so big it is unsigned long lib/test_printf.c:246:54: warning: constant 0x0123456789ab is so big it is unsigned long To satisfy everyone, mark

[PATCH v2 7/9] lib/vsprintf: Replace space with '_' before crng is ready

From: Shunyong Yang Before crng is ready, output of "%p" composes of "(ptrval)" and left padding spaces for alignment as no random address can be generated. This seems a little strange when default string width is larger than strlen("(ptrval)"). For example, when irq domain names are built with

[PATCH v2 8/9] lib/vsprintf: Remove useless NULL checks

The pointer can't be NULL since it's first what has been done in the pointer(). Remove useless checks. Note we leave check for !CONFIG_HAVE_CLK to make compiler to optimize code away when possible. Cc: Petr Mladek Signed-off-by: Andy Shevchenko

[PATCH v2 8/9] lib/vsprintf: Remove useless NULL checks

The pointer can't be NULL since it's first what has been done in the pointer(). Remove useless checks. Note we leave check for !CONFIG_HAVE_CLK to make compiler to optimize code away when possible. Cc: Petr Mladek Signed-off-by: Andy Shevchenko --- lib/vsprintf.c | 13 + 1 file

<    1   2   3   4   5   6   7   8   9   10   >