Re: [PATCH] audit: add containerid support for IMA-audit

On 2018-03-08 13:02, Mimi Zohar wrote: > On Thu, 2018-03-08 at 06:21 -0500, Richard Guy Briggs wrote: > > On 2018-03-05 09:24, Mimi Zohar wrote: > > > On Mon, 2018-03-05 at 08:50 -0500, Richard Guy Briggs wrote: > > > > On 2018-03-05 08:43, Mimi Zohar wrote: > > > > > Hi Richard, > > > > > > > >

Re: [PATCH] audit: add containerid support for IMA-audit

On 2018-03-08 13:02, Mimi Zohar wrote: > On Thu, 2018-03-08 at 06:21 -0500, Richard Guy Briggs wrote: > > On 2018-03-05 09:24, Mimi Zohar wrote: > > > On Mon, 2018-03-05 at 08:50 -0500, Richard Guy Briggs wrote: > > > > On 2018-03-05 08:43, Mimi Zohar wrote: > > > > > Hi Richard, > > > > > > > >

Re: Dell Inc. XPS 13 9343/0TM99H fails to boot v4.16-rc5

On Mon, Mar 12, 2018 at 10:42:01PM +, mario.limoncie...@dell.com wrote: > > > > -Original Message- > > From: Dominik Brodowski [mailto:li...@dominikbrodowski.net] > > Sent: Tuesday, March 13, 2018 2:54 AM > > To: dvh...@infradead.org; Limonciello, Mario >

Re: Dell Inc. XPS 13 9343/0TM99H fails to boot v4.16-rc5

On Mon, Mar 12, 2018 at 10:42:01PM +, mario.limoncie...@dell.com wrote: > > > > -Original Message- > > From: Dominik Brodowski [mailto:li...@dominikbrodowski.net] > > Sent: Tuesday, March 13, 2018 2:54 AM > > To: dvh...@infradead.org; Limonciello, Mario > > Cc:

Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

On 1/11/2018 6:07 PM, Peter Zijlstra wrote: Sorry for the huge delay on this, but I'll have to postpone further. Still busy with meltdown/spectre stuff. Could you review the patch? -- Thanks, Byungchul

Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

On 1/11/2018 6:07 PM, Peter Zijlstra wrote: Sorry for the huge delay on this, but I'll have to postpone further. Still busy with meltdown/spectre stuff. Could you review the patch? -- Thanks, Byungchul

Re: [PATCH v2 1/1] net: check before dereferencing netdev_ops during busy poll

On 03/12/2018 10:32 PM, Josh Elsasser wrote: init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll. Avoid this by ensuring

RE: [PATCH v4 2/6] staging: fsl-dpaa2/ethsw: Add Freescale DPAA2 Ethernet Switch driver

> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Monday, March 12, 2018 4:37 PM > To: Razvan Stefanescu > Cc: gre...@linuxfoundation.org; de...@driverdev.osuosl.org; linux- > ker...@vger.kernel.org; net...@vger.kernel.org; Alexander

Re: [PATCH v2 1/1] net: check before dereferencing netdev_ops during busy poll

On 03/12/2018 10:32 PM, Josh Elsasser wrote: init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll. Avoid this by ensuring

RE: [PATCH v4 2/6] staging: fsl-dpaa2/ethsw: Add Freescale DPAA2 Ethernet Switch driver

> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Monday, March 12, 2018 4:37 PM > To: Razvan Stefanescu > Cc: gre...@linuxfoundation.org; de...@driverdev.osuosl.org; linux- > ker...@vger.kernel.org; net...@vger.kernel.org; Alexander Graf > ; a...@arndb.de;

Re: [RFC PATCH 00/35] remove in-kernel syscall invocations

* Dominik Brodowski wrote: > On Mon, Mar 12, 2018 at 08:32:56AM +0100, Ingo Molnar wrote: > > > > * Dominik Brodowski wrote: > > > > > I'm a bit more unsure about these remaining patches. They use inline stubs > > > named ksys_xyzzy()

Re: [RFC PATCH 00/35] remove in-kernel syscall invocations

* Dominik Brodowski wrote: > On Mon, Mar 12, 2018 at 08:32:56AM +0100, Ingo Molnar wrote: > > > > * Dominik Brodowski wrote: > > > > > I'm a bit more unsure about these remaining patches. They use inline stubs > > > named ksys_xyzzy() which (mostly) call fs-internal functions. Another > > >

linux-next: build failure after merge of the drm tree

Hi all, After merging the drm tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c: In function 'smu7_notify_link_speed_change_after_state_change': drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:3830:7:

linux-next: build failure after merge of the drm tree

Hi all, After merging the drm tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c: In function 'smu7_notify_link_speed_change_after_state_change': drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:3830:7:

Re: [RFC PATCH 35/35] syscalls: do not call sys_close() within the kernel

* Dominik Brodowski wrote: > On Mon, Mar 12, 2018 at 08:37:19AM +0100, Ingo Molnar wrote: > > > > * Dominik Brodowski wrote: > > > > > --- a/fs/open.c > > > +++ b/fs/open.c > > > @@ -1200,7 +1200,7 @@ SYSCALL_DEFINE1(close, unsigned

Re: [RFC PATCH 35/35] syscalls: do not call sys_close() within the kernel

* Dominik Brodowski wrote: > On Mon, Mar 12, 2018 at 08:37:19AM +0100, Ingo Molnar wrote: > > > > * Dominik Brodowski wrote: > > > > > --- a/fs/open.c > > > +++ b/fs/open.c > > > @@ -1200,7 +1200,7 @@ SYSCALL_DEFINE1(close, unsigned int, fd) > > > > > > return retval; > > > } > > >

Re: [PATCH v2 2/2] clk: aspeed: Prevent reset if clock is enabled

On Fri, Mar 9, 2018 at 7:27 AM, Eddie James wrote: > According to the Aspeed specification, the reset and enable sequence > should be done when the clock is stopped. The specification doesn't > define behavior if the reset is done while the clock is enabled. > > From

Re: [PATCH v2 2/2] clk: aspeed: Prevent reset if clock is enabled

On Fri, Mar 9, 2018 at 7:27 AM, Eddie James wrote: > According to the Aspeed specification, the reset and enable sequence > should be done when the clock is stopped. The specification doesn't > define behavior if the reset is done while the clock is enabled. > > From testing on the AST2500, the

Re: [PATCH v3] powerpc/kernel/sysfs: Export ldbar spr to sysfs

Hi, On Tuesday 06 March 2018 04:35 PM, Michael Ellerman wrote: Anju T Sudhakar writes: diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c index 4437c70..caefb64 100644 --- a/arch/powerpc/kernel/sysfs.c +++ b/arch/powerpc/kernel/sysfs.c @@ -757,6

Re: [PATCH v3] powerpc/kernel/sysfs: Export ldbar spr to sysfs

Hi, On Tuesday 06 March 2018 04:35 PM, Michael Ellerman wrote: Anju T Sudhakar writes: diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c index 4437c70..caefb64 100644 --- a/arch/powerpc/kernel/sysfs.c +++ b/arch/powerpc/kernel/sysfs.c @@ -757,6 +759,9 @@ static int

Re: [PATCH v2 1/2] clk: aspeed: Fix is_enabled for certain clocks

On Fri, Mar 9, 2018 at 7:27 AM, Eddie James wrote: > Some of the Aspeed clocks are disabled by setting the relevant bit in > the "clock stop control" register to one, while others are disabled by > setting their bit to zero. The driver already uses a flag per gate to

Re: [PATCH v2 1/2] clk: aspeed: Fix is_enabled for certain clocks

On Fri, Mar 9, 2018 at 7:27 AM, Eddie James wrote: > Some of the Aspeed clocks are disabled by setting the relevant bit in > the "clock stop control" register to one, while others are disabled by > setting their bit to zero. The driver already uses a flag per gate to > identify this behavior,

Hello

Good day dear, i hope this mail meets you well? I know this may seem inappropriate so i ask for your forgiveness but i wish to get to know you better, if I may be so bold. I consider myself an easy-going man, adventurous, honest and fun loving person but I am currently looking for a

Hello

Good day dear, i hope this mail meets you well? I know this may seem inappropriate so i ask for your forgiveness but i wish to get to know you better, if I may be so bold. I consider myself an easy-going man, adventurous, honest and fun loving person but I am currently looking for a

[PATCH v2 1/1] net: check before dereferencing netdev_ops during busy poll

init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll. Avoid this by ensuring napi->dev->netdev_ops is valid before following the pointer,

[PATCH v2 1/1] net: check before dereferencing netdev_ops during busy poll

init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll. Avoid this by ensuring napi->dev->netdev_ops is valid before following the pointer,

[PATCH 0/1] net: avoid a kernel panic during sk_busy_loop

V2: just check napi->dev->netdev_ops instead of getting clever with the netdev registration state. Original cover letter: Hi Dave, I stumbled across a reproducible kernel panic while playing around with busy_poll on a Linux 4.9.86 kernel. There's an unfortunate interaction between

[PATCH 0/1] net: avoid a kernel panic during sk_busy_loop

V2: just check napi->dev->netdev_ops instead of getting clever with the netdev registration state. Original cover letter: Hi Dave, I stumbled across a reproducible kernel panic while playing around with busy_poll on a Linux 4.9.86 kernel. There's an unfortunate interaction between

RE: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

Kan -- sorry for my late-night typo. My description for "hubless" should have said "a single segment/domain" rather than single bus. > "hubless" -- equivalent to "glueless" or "white box" where our BIOS sets > things up with a single bus for all sockets. single segment/domain

RE: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

Kan -- sorry for my late-night typo. My description for "hubless" should have said "a single segment/domain" rather than single bus. > "hubless" -- equivalent to "glueless" or "white box" where our BIOS sets > things up with a single bus for all sockets. single segment/domain

Re: [PATCH] arm: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

On 03/13/2018 01:53 PM, Jinbum Park wrote: > To enable UBSAN on arm, ARCH_HAS_UBSAN_SANITIZE_ALL is needed to be selected. > > Basic test has passed on Raspberry Pi2, Raspbian jessi lite with > CONFIG_UBSAN_SANITIZE_ALL, CONFIG_UBSAN_NULL. This patch had been already sent from Seungwoo.

Re: [PATCH] arm: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

On 03/13/2018 01:53 PM, Jinbum Park wrote: > To enable UBSAN on arm, ARCH_HAS_UBSAN_SANITIZE_ALL is needed to be selected. > > Basic test has passed on Raspberry Pi2, Raspbian jessi lite with > CONFIG_UBSAN_SANITIZE_ALL, CONFIG_UBSAN_NULL. This patch had been already sent from Seungwoo.

Re: [PATCH 1/1] net: check dev->reg_state before deref of napi netdev_ops

On Mon, Mar 12, 2018 at 4:17 PM, Cong Wang wrote: > On Sun, Mar 11, 2018 at 12:22 PM, Josh Elsasser wrote: >> init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads >> to a NULL pointer dereference when sk_busy_loop fires against an

Re: [PATCH 1/1] net: check dev->reg_state before deref of napi netdev_ops

On Mon, Mar 12, 2018 at 4:17 PM, Cong Wang wrote: > On Sun, Mar 11, 2018 at 12:22 PM, Josh Elsasser wrote: >> init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads >> to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi >> wireless adapter and checks

Re: [PATCH v2] exec: Set file unwritable before LSM check

On Fri, 9 Mar 2018, Kees Cook wrote: > The LSM check should happen after the file has been confirmed to be > unchanging. Without this, we could have a race between the Time of Check > (the call to security_kernel_read_file() which could read the file and > make access policy decisions) and the

Re: [PATCH v2] exec: Set file unwritable before LSM check

On Fri, 9 Mar 2018, Kees Cook wrote: > The LSM check should happen after the file has been confirmed to be > unchanging. Without this, we could have a race between the Time of Check > (the call to security_kernel_read_file() which could read the file and > make access policy decisions) and the

Re: [PATCH] arm: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

On 03/13/2018 01:53 PM, Jinbum Park wrote: > To enable UBSAN on arm, ARCH_HAS_UBSAN_SANITIZE_ALL is needed to be selected. > > Basic test has passed on Raspberry Pi2, Raspbian jessi lite with > CONFIG_UBSAN_SANITIZE_ALL, CONFIG_UBSAN_NULL. > > Signed-off-by: Jinbum Park >

Re: [PATCH] arm: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

On 03/13/2018 01:53 PM, Jinbum Park wrote: > To enable UBSAN on arm, ARCH_HAS_UBSAN_SANITIZE_ALL is needed to be selected. > > Basic test has passed on Raspberry Pi2, Raspbian jessi lite with > CONFIG_UBSAN_SANITIZE_ALL, CONFIG_UBSAN_NULL. > > Signed-off-by: Jinbum Park > --- >

[PATCH v10] mmc: Export host capabilities to debugfs.

This patch exports the host capabilities to debugfs This idea of sharing host capabilities over debugfs came up from Abbas Raza Earlier discussions: https://lkml.org/lkml/2018/3/5/357 https://www.spinics.net/lists/linux-mmc/msg48219.html Reviewed-by: Andy Shevchenko

[PATCH v10] mmc: Export host capabilities to debugfs.

This patch exports the host capabilities to debugfs This idea of sharing host capabilities over debugfs came up from Abbas Raza Earlier discussions: https://lkml.org/lkml/2018/3/5/357 https://www.spinics.net/lists/linux-mmc/msg48219.html Reviewed-by: Andy Shevchenko Signed-off-by: Harish Jenny

RE: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

Thanks, Kan -- your patch looks good, and cleaner than the previous method! Tonight, I've tested it on our in-house simulator for the following configurations. The simulator has been matching hardware well for this issue -- we'll do more testing on real hardware, but I'm confident you have it

RE: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

Thanks, Kan -- your patch looks good, and cleaner than the previous method! Tonight, I've tested it on our in-house simulator for the following configurations. The simulator has been matching hardware well for this issue -- we'll do more testing on real hardware, but I'm confident you have it

[PATCH] arm: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

To enable UBSAN on arm, ARCH_HAS_UBSAN_SANITIZE_ALL is needed to be selected. Basic test has passed on Raspberry Pi2, Raspbian jessi lite with CONFIG_UBSAN_SANITIZE_ALL, CONFIG_UBSAN_NULL. Signed-off-by: Jinbum Park --- arch/arm/Kconfig | 1 +

[PATCH] arm: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

To enable UBSAN on arm, ARCH_HAS_UBSAN_SANITIZE_ALL is needed to be selected. Basic test has passed on Raspberry Pi2, Raspbian jessi lite with CONFIG_UBSAN_SANITIZE_ALL, CONFIG_UBSAN_NULL. Signed-off-by: Jinbum Park --- arch/arm/Kconfig | 1 + arch/arm/boot/compressed/Makefile

Re: [PATCH v3 20/20] mt7601u: use request_firmware_cache() to address cache on reboot

On Sat, 10 Mar 2018 06:15:01 -0800, Luis R. Rodriguez wrote: > request_firmware_cache() will ensure the firmware is available on resume > from suspend if on reboot the device retains the firmware. > > This optimization is in place given otherwise on reboot we have to > reload the firmware, the

Re: [PATCH v3 20/20] mt7601u: use request_firmware_cache() to address cache on reboot

On Sat, 10 Mar 2018 06:15:01 -0800, Luis R. Rodriguez wrote: > request_firmware_cache() will ensure the firmware is available on resume > from suspend if on reboot the device retains the firmware. > > This optimization is in place given otherwise on reboot we have to > reload the firmware, the

[PATCH 2/2] dh key: get rid of stack array allocation

Similarly to the previous patch, we would like to get rid of stack allocated arrays: https://lkml.org/lkml/2018/3/7/621 In this case, we can also use a malloc style approach to free the temporary buffer, being careful to also use kzfree to free them (indeed, at least one of these has a

[PATCH 2/2] dh key: get rid of stack array allocation

Similarly to the previous patch, we would like to get rid of stack allocated arrays: https://lkml.org/lkml/2018/3/7/621 In this case, we can also use a malloc style approach to free the temporary buffer, being careful to also use kzfree to free them (indeed, at least one of these has a

[PATCH 1/2] big key: get rid of stack array allocation

We're interested in getting rid of all of the stack allocated arrays in the kernel [1]. This patch removes one in keys by switching to malloc/free. Note that we use kzalloc, to avoid leaking the nonce. I'm not sure this is really necessary, but extra paranoia seems prudent. Manually tested using

[PATCH 1/2] big key: get rid of stack array allocation

We're interested in getting rid of all of the stack allocated arrays in the kernel [1]. This patch removes one in keys by switching to malloc/free. Note that we use kzalloc, to avoid leaking the nonce. I'm not sure this is really necessary, but extra paranoia seems prudent. Manually tested using

Re: [PATCH 2/2] watchdog: aspeed: Allow configuring for alternate boot

On Sat, Mar 10, 2018 at 8:28 AM, Eddie James wrote: > From: Milton Miller > > Allow the device tree to specify a watchdog to fallover to > the alternate boot source. > > The aspeeed watchdog can set a latch directing flash chip select 0 to > chip

Re: [PATCH 2/2] watchdog: aspeed: Allow configuring for alternate boot

On Sat, Mar 10, 2018 at 8:28 AM, Eddie James wrote: > From: Milton Miller > > Allow the device tree to specify a watchdog to fallover to > the alternate boot source. > > The aspeeed watchdog can set a latch directing flash chip select 0 to > chip select 1, allowing boot from an alternate media

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds wrote: > On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton > wrote: >> >> Replacing the __builtin_choose_expr() with ?: works of course. > > Hmm. That sounds like the right thing to do. We were

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds wrote: > On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton > wrote: >> >> Replacing the __builtin_choose_expr() with ?: works of course. > > Hmm. That sounds like the right thing to do. We were so myopically > staring at the __builtin_choose_expr()

Re: [PATCH ghak21 V2 2/4] audit: link denied should not directly generate PATH record

On 2018-03-13 02:22, kbuild test robot wrote: > Hi Richard, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.16-rc5 next-20180309] > [if your patch is applied to the wrong git tree, please drop us a note to > help

Re: [PATCH ghak21 V2 2/4] audit: link denied should not directly generate PATH record

On 2018-03-13 02:22, kbuild test robot wrote: > Hi Richard, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.16-rc5 next-20180309] > [if your patch is applied to the wrong git tree, please drop us a note to > help

linux-next: manual merge of the staging tree with the vfs tree

Hi Greg, Today's linux-next merge of the staging tree got conflicts in: drivers/staging/lustre/lnet/libcfs/linux/linux-curproc.c drivers/staging/lustre/lnet/libcfs/linux/linux-prim.c between commit: 304ec482f562 ("get rid of pointless includes of fs_struct.h") from the vfs tree and

linux-next: manual merge of the staging tree with the vfs tree

Hi Greg, Today's linux-next merge of the staging tree got conflicts in: drivers/staging/lustre/lnet/libcfs/linux/linux-curproc.c drivers/staging/lustre/lnet/libcfs/linux/linux-prim.c between commit: 304ec482f562 ("get rid of pointless includes of fs_struct.h") from the vfs tree and

RE: [PATCH] dma-mapping: move dma configuration to bus infrastructure

> -Original Message- > From: Sinan Kaya [mailto:ok...@codeaurora.org] > Sent: Monday, March 12, 2018 22:14 > To: Nipun Gupta ; h...@lst.de; > robin.mur...@arm.com; li...@armlinux.org.uk; gre...@linuxfoundation.org; > m.szyprow...@samsung.com; bhelg...@google.com >

RE: [PATCH] dma-mapping: move dma configuration to bus infrastructure

> -Original Message- > From: Sinan Kaya [mailto:ok...@codeaurora.org] > Sent: Monday, March 12, 2018 22:14 > To: Nipun Gupta ; h...@lst.de; > robin.mur...@arm.com; li...@armlinux.org.uk; gre...@linuxfoundation.org; > m.szyprow...@samsung.com; bhelg...@google.com > Cc:

Re: Timing performance regression 4.15 to 4.16-rc1

On Sun, Mar 11, 2018 at 02:02:03PM +0100, Zdenek Kabelac wrote: > Hi > > I've noticed quite some drop of performance (around 15% in some cases) where > execution of lvm2 tests took longer time - and while tests itself should not > really load CPU system - the overall running time just got

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

Al Viro writes: > On Tue, Mar 13, 2018 at 12:37:51AM +, Al Viro wrote: >> On Mon, Mar 12, 2018 at 06:52:31PM -0500, Eric W. Biederman wrote: >> >> > Ah. I see now there is now the s_roots list that handles >> > that bit of strangeness. >> > >> > So one path is to

Re: Timing performance regression 4.15 to 4.16-rc1

On Sun, Mar 11, 2018 at 02:02:03PM +0100, Zdenek Kabelac wrote: > Hi > > I've noticed quite some drop of performance (around 15% in some cases) where > execution of lvm2 tests took longer time - and while tests itself should not > really load CPU system - the overall running time just got

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

Al Viro writes: > On Tue, Mar 13, 2018 at 12:37:51AM +, Al Viro wrote: >> On Mon, Mar 12, 2018 at 06:52:31PM -0500, Eric W. Biederman wrote: >> >> > Ah. I see now there is now the s_roots list that handles >> > that bit of strangeness. >> > >> > So one path is to simply remove the

Re: [RESEND PATCH v3 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

Hi Thierry Reding, On Monday, March 12, 2018 05:21 PM, Thierry Reding wrote: On Mon, Dec 04, 2017 at 03:17:48PM +0800, Lin Huang wrote: Refactor Innolux P079ZCA panel driver, let it support multi panel. Signed-off-by: Lin Huang --- Changes in v2: - Change regulator

Re: [RESEND PATCH v3 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

Hi Thierry Reding, On Monday, March 12, 2018 05:21 PM, Thierry Reding wrote: On Mon, Dec 04, 2017 at 03:17:48PM +0800, Lin Huang wrote: Refactor Innolux P079ZCA panel driver, let it support multi panel. Signed-off-by: Lin Huang --- Changes in v2: - Change regulator property name to meet the

Re: [PATCH v12 0/6] Address error and recovery for AER and DPC

On 3/12/2018 7:26 PM, Keith Busch wrote: > On Mon, Mar 12, 2018 at 02:47:30PM -0500, Bjorn Helgaas wrote: >> [+cc Alex] >> >> On Mon, Mar 12, 2018 at 08:25:51AM -0600, Keith Busch wrote: >>> On Sun, Mar 11, 2018 at 11:03:58PM -0400, Sinan Kaya wrote: On 3/11/2018 6:03 PM, Bjorn Helgaas wrote:

Re: [PATCH v12 0/6] Address error and recovery for AER and DPC

On 3/12/2018 7:26 PM, Keith Busch wrote: > On Mon, Mar 12, 2018 at 02:47:30PM -0500, Bjorn Helgaas wrote: >> [+cc Alex] >> >> On Mon, Mar 12, 2018 at 08:25:51AM -0600, Keith Busch wrote: >>> On Sun, Mar 11, 2018 at 11:03:58PM -0400, Sinan Kaya wrote: On 3/11/2018 6:03 PM, Bjorn Helgaas wrote:

Re: [PATCH v4 3/3 update] mm/free_pcppages_bulk: prefetch buddy while not holding lock

On Mon, Mar 12, 2018 at 10:32:32AM -0700, Dave Hansen wrote: > On 03/09/2018 12:24 AM, Aaron Lu wrote: > > + /* > > +* We are going to put the page back to the global > > +* pool, prefetch its buddy to speed up later access > > +

Re: [PATCH v4 2/3] mm/free_pcppages_bulk: do not hold lock when picking pages to free

On Mon, Mar 12, 2018 at 03:22:53PM +0100, Vlastimil Babka wrote: > On 03/01/2018 07:28 AM, Aaron Lu wrote: > > When freeing a batch of pages from Per-CPU-Pages(PCP) back to buddy, > > the zone->lock is held and then pages are chosen from PCP's migratetype > > list. While there is actually no need

Re: [PATCH v4 3/3 update] mm/free_pcppages_bulk: prefetch buddy while not holding lock

On Mon, Mar 12, 2018 at 10:32:32AM -0700, Dave Hansen wrote: > On 03/09/2018 12:24 AM, Aaron Lu wrote: > > + /* > > +* We are going to put the page back to the global > > +* pool, prefetch its buddy to speed up later access > > +

Re: [PATCH v4 2/3] mm/free_pcppages_bulk: do not hold lock when picking pages to free

On Mon, Mar 12, 2018 at 03:22:53PM +0100, Vlastimil Babka wrote: > On 03/01/2018 07:28 AM, Aaron Lu wrote: > > When freeing a batch of pages from Per-CPU-Pages(PCP) back to buddy, > > the zone->lock is held and then pages are chosen from PCP's migratetype > > list. While there is actually no need

[RFC/PATCH] risc-v: Fix issue ignoring CONFIG_CMDLINE_OVERRIDE

Fix issue where CONFIG_CMDLINE_OVERRIDE is being ignored. Signed-off-by: Trung Tran Signed-off-by: Moritz Fischer --- Hi all, not sure this is the right fix, hopefully someone can chime in and come up with the correct solution. Thanks, Moritz ---

[RFC/PATCH] risc-v: Fix issue ignoring CONFIG_CMDLINE_OVERRIDE

Fix issue where CONFIG_CMDLINE_OVERRIDE is being ignored. Signed-off-by: Trung Tran Signed-off-by: Moritz Fischer --- Hi all, not sure this is the right fix, hopefully someone can chime in and come up with the correct solution. Thanks, Moritz --- arch/riscv/kernel/setup.c | 6 ++ 1

Re: [PATCH v2 2/2] mfd: rk808: Add restart functionality

Hi, Daniel：         On Rockchip platforms, we always use CRU to restart system. From your patch, I think you would like to support restart by CRU or PMIC, right ?         I think restart by PMIC is not accepted, because PMIC restart means all regualtors are reset (voltage drops to 0mv and

Re: [PATCH v2 2/2] mfd: rk808: Add restart functionality

Hi, Daniel：         On Rockchip platforms, we always use CRU to restart system. From your patch, I think you would like to support restart by CRU or PMIC, right ?         I think restart by PMIC is not accepted, because PMIC restart means all regualtors are reset (voltage drops to 0mv and

Re: [PATCH] video: fbdev: via: remove VLA usage

On 03/09/2018 05:02 AM, Emil Velikov wrote: On 9 March 2018 at 10:59, Eric Engestrom wrote: On Thursday, 2018-03-08 11:39:49 -0600, Gustavo A. R. Silva wrote: In preparation to enabling -Wvla, remove VLA usage. Also, fixed as part of the directive to remove all

Re: [PATCH] video: fbdev: via: remove VLA usage

On 03/09/2018 05:02 AM, Emil Velikov wrote: On 9 March 2018 at 10:59, Eric Engestrom wrote: On Thursday, 2018-03-08 11:39:49 -0600, Gustavo A. R. Silva wrote: In preparation to enabling -Wvla, remove VLA usage. Also, fixed as part of the directive to remove all VLAs from the kernel:

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 3/12/2018 3:35 PM, Logan Gunthorpe wrote: > +int pci_p2pdma_add_client(struct list_head *head, struct device *dev) It feels like code tried to be a generic p2pdma provider first. Then got converted to PCI, yet all dev parameters are still struct device. Maybe, dev parameter should also be

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 3/12/2018 3:35 PM, Logan Gunthorpe wrote: > +int pci_p2pdma_add_client(struct list_head *head, struct device *dev) It feels like code tried to be a generic p2pdma provider first. Then got converted to PCI, yet all dev parameters are still struct device. Maybe, dev parameter should also be

Re: [PATCH] perf stat: Add support for s390 transaction counters

Thomas Richter writes: > Right now there is only hard coded support for x86. That's not true. There is support for generic transaction events in perf. As far as I can tell your events would map 1:1 to the generic tx-* events. -Andi

Re: [PATCH] perf stat: Add support for s390 transaction counters

Thomas Richter writes: > Right now there is only hard coded support for x86. That's not true. There is support for generic transaction events in perf. As far as I can tell your events would map 1:1 to the generic tx-* events. -Andi

Re: [PATCH 1/2] rtc: s5m: Move enum from rtc.h to rtc-s5m.c

On 03/11/2018 11:39 AM, Krzysztof Kozlowski wrote: On Sat, Mar 10, 2018 at 7:27 AM, Gustavo A. R. Silva wrote: Move this enum to rtc-s5m.c once it is meaningless to others drivers [1]. [1] https://marc.info/?l=linux-rtc=152060068925948=2 Instead of external link

Re: [PATCH 1/2] rtc: s5m: Move enum from rtc.h to rtc-s5m.c

On 03/11/2018 11:39 AM, Krzysztof Kozlowski wrote: On Sat, Mar 10, 2018 at 7:27 AM, Gustavo A. R. Silva wrote: Move this enum to rtc-s5m.c once it is meaningless to others drivers [1]. [1] https://marc.info/?l=linux-rtc=152060068925948=2 Instead of external link (which might or might not

[PATCH v2] netfilter: nf_tables: remove VLA usage

In preparation to enabling -Wvla, remove VLA and replace it with dynamic memory allocation. >From a security viewpoint, the use of Variable Length Arrays can be a vector for stack overflow attacks. Also, in general, as the code evolves it is easy to lose track of how big a VLA can get. Thus, we

[PATCH v2] netfilter: nf_tables: remove VLA usage

In preparation to enabling -Wvla, remove VLA and replace it with dynamic memory allocation. >From a security viewpoint, the use of Variable Length Arrays can be a vector for stack overflow attacks. Also, in general, as the code evolves it is easy to lose track of how big a VLA can get. Thus, we

linux-next: manual merge of the tip tree with the arm-soc tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/bus/arm-cci.c between commit: 3de6be7a3dd8 ("drivers/bus: Split Arm CCI driver") from the arm-soc tree and commit: 8343aae66167 ("perf/core: Remove perf_event::group_entry") from the tip tree. I fixed it up

linux-next: manual merge of the tip tree with the arm-soc tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/bus/arm-cci.c between commit: 3de6be7a3dd8 ("drivers/bus: Split Arm CCI driver") from the arm-soc tree and commit: 8343aae66167 ("perf/core: Remove perf_event::group_entry") from the tip tree. I fixed it up

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

Hi Thomas, At 03/09/2018 11:08 PM, Thomas Gleixner wrote: [...] I'm not sure if there is a clear indicator whether physcial hotplug is supported or not, but the ACPI folks (x86) and architecture maintainers +cc Rafael should be able to answer that question. I have a machine which says:

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

Hi Thomas, At 03/09/2018 11:08 PM, Thomas Gleixner wrote: [...] I'm not sure if there is a clear indicator whether physcial hotplug is supported or not, but the ACPI folks (x86) and architecture maintainers +cc Rafael should be able to answer that question. I have a machine which says:

Re: [PATCH] net: hns: use put_device() if device_register fail

On Monday 12 March 2018 10:59 PM, Richard Weinberger wrote: On Mon, Mar 12, 2018 at 5:27 PM, arvindY wrote: On Monday 12 March 2018 08:13 PM, David Miller wrote: From: Arvind Yadav Date: Fri, 9 Mar 2018 16:11:17 +0530 if

Re: [PATCH] net: hns: use put_device() if device_register fail

On Monday 12 March 2018 10:59 PM, Richard Weinberger wrote: On Mon, Mar 12, 2018 at 5:27 PM, arvindY wrote: On Monday 12 March 2018 08:13 PM, David Miller wrote: From: Arvind Yadav Date: Fri, 9 Mar 2018 16:11:17 +0530 if device_register() returned an error! Always use put_device() to

Re: [PATCH][drm-next] drm/i915/gvt: fix spelling mistake: "destoried" -> "destroyed"

On 2018.03.12 12:43:58 +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in gvt_err error message text. > > Signed-off-by: Colin Ian King > --- Thanks Colin, will pick up. > drivers/gpu/drm/i915/gvt/gtt.c

Re: [PATCH][drm-next] drm/i915/gvt: fix spelling mistake: "destoried" -> "destroyed"

On 2018.03.12 12:43:58 +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in gvt_err error message text. > > Signed-off-by: Colin Ian King > --- Thanks Colin, will pick up. > drivers/gpu/drm/i915/gvt/gtt.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH] device_handler: remove VLAs

Stephen, > In preparation to enabling -Wvla, remove VLAs and replace them with > fixed-length arrays instead. > > scsi_dh_{alua,emc,rdac} use variable-length array declarations to > store command blocks, with the appropriate size as determined by > COMMAND_SIZE. This patch replaces these with

Re: [PATCH] device_handler: remove VLAs

Stephen, > In preparation to enabling -Wvla, remove VLAs and replace them with > fixed-length arrays instead. > > scsi_dh_{alua,emc,rdac} use variable-length array declarations to > store command blocks, with the appropriate size as determined by > COMMAND_SIZE. This patch replaces these with

Re: [PATCH] scsi: eata: drop VLA in reorder()

Linus, > That said, I wonder if the solution to this particular driver is > "delete it". Because the hardware is truly ancient and nobody sane > would use it any more. I'm not aware of anybody actively using these anymore. They are mid-nineties vintage with an M68K processor onboard. I ran a

Re: [PATCH] scsi: eata: drop VLA in reorder()

Linus, > That said, I wonder if the solution to this particular driver is > "delete it". Because the hardware is truly ancient and nobody sane > would use it any more. I'm not aware of anybody actively using these anymore. They are mid-nineties vintage with an M68K processor onboard. I ran a

[PATCH v2] kbuild: check for pkg-config on make {menu,n,g,x}config

From: Randy Dunlap Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure that other required files are present, but none of these check that pkg-config itself is present. Add a check for all 4 of these targets. Fixes kernel bugzilla #77511:

[PATCH v2] kbuild: check for pkg-config on make {menu,n,g,x}config

From: Randy Dunlap Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure that other required files are present, but none of these check that pkg-config itself is present. Add a check for all 4 of these targets. Fixes kernel bugzilla #77511:

  1   2   3   4   5   6   7   8   9   10   >