Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

On 03/09/18 at 03:46pm, Dave Young wrote: > Hi AKASHI, > > On 03/09/18 at 04:18pm, AKASHI Takahiro wrote: > > Dave, > > > > On Fri, Mar 09, 2018 at 02:44:12PM +0800, Dave Young wrote: > > > On 03/09/18 at 02:02pm, Dave Young wrote: > > > > On 03/08/18 at 09:05am, Dave Young wrote: > > > > > [Cc

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

On 03/09/18 at 03:46pm, Dave Young wrote: > Hi AKASHI, > > On 03/09/18 at 04:18pm, AKASHI Takahiro wrote: > > Dave, > > > > On Fri, Mar 09, 2018 at 02:44:12PM +0800, Dave Young wrote: > > > On 03/09/18 at 02:02pm, Dave Young wrote: > > > > On 03/08/18 at 09:05am, Dave Young wrote: > > > > > [Cc

Re: [linux-sunxi] [PATCH v3 06/16] drm/sun4i: Release exclusive clock lock when disabling TCON

Hi, On Fri, Mar 09, 2018 at 07:19:33AM +0100, Jernej Škrabec wrote: > Hi, > > Dne petek, 09. marec 2018 ob 01:44:55 CET je Ondřej Jirman napisal(a): > > Hi, > > > > I've debugged this further and it seems that the code has incorrect > > assumptions. See docs for mode_set_nofb. > > > >

Re: [linux-sunxi] [PATCH v3 06/16] drm/sun4i: Release exclusive clock lock when disabling TCON

Hi, On Fri, Mar 09, 2018 at 07:19:33AM +0100, Jernej Škrabec wrote: > Hi, > > Dne petek, 09. marec 2018 ob 01:44:55 CET je Ondřej Jirman napisal(a): > > Hi, > > > > I've debugged this further and it seems that the code has incorrect > > assumptions. See docs for mode_set_nofb. > > > >

Re: [PATCH 06/12] x86: efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store

* Ard Biesheuvel wrote: > From: Jia-Ju Bai > > The function kzalloc here is not called in atomic context. > If nonblocking in efi_query_variable_store is true, > namely it is in atomic context, efi_query_variable_store will return before >

Re: [PATCH 06/12] x86: efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store

* Ard Biesheuvel wrote: > From: Jia-Ju Bai > > The function kzalloc here is not called in atomic context. > If nonblocking in efi_query_variable_store is true, > namely it is in atomic context, efi_query_variable_store will return before > this kzalloc is called. > Thus GFP_ATOMIC is not

Re: [PATCH 12/12] efi: make const array 'apple' static

On 9 March 2018 at 07:47, Ingo Molnar wrote: > > * Ard Biesheuvel wrote: > >> From: Colin Ian King >> >> Don't populate the const read-only array 'buf' on the stack but instead >> make it static. Makes the object code

Re: [PATCH 12/12] efi: make const array 'apple' static

On 9 March 2018 at 07:47, Ingo Molnar wrote: > > * Ard Biesheuvel wrote: > >> From: Colin Ian King >> >> Don't populate the const read-only array 'buf' on the stack but instead >> make it static. Makes the object code smaller by 64 bytes: >> >> Before: >>text data bss dec

Re: [PATCH 12/12] efi: make const array 'apple' static

* Ard Biesheuvel wrote: > From: Colin Ian King > > Don't populate the const read-only array 'buf' on the stack but instead > make it static. Makes the object code smaller by 64 bytes: > > Before: >text data bss dec

Re: [PATCH 12/12] efi: make const array 'apple' static

* Ard Biesheuvel wrote: > From: Colin Ian King > > Don't populate the const read-only array 'buf' on the stack but instead > make it static. Makes the object code smaller by 64 bytes: > > Before: >text data bss dec hex filename >9264 1 169281

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

Hi AKASHI, On 03/09/18 at 04:18pm, AKASHI Takahiro wrote: > Dave, > > On Fri, Mar 09, 2018 at 02:44:12PM +0800, Dave Young wrote: > > On 03/09/18 at 02:02pm, Dave Young wrote: > > > On 03/08/18 at 09:05am, Dave Young wrote: > > > > [Cc Andrew] > > > > > > > > On 03/06/18 at 07:22pm, AKASHI

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

Hi AKASHI, On 03/09/18 at 04:18pm, AKASHI Takahiro wrote: > Dave, > > On Fri, Mar 09, 2018 at 02:44:12PM +0800, Dave Young wrote: > > On 03/09/18 at 02:02pm, Dave Young wrote: > > > On 03/08/18 at 09:05am, Dave Young wrote: > > > > [Cc Andrew] > > > > > > > > On 03/06/18 at 07:22pm, AKASHI

Re: [PATCH 12/12] efi: make const array 'apple' static

On 9 March 2018 at 07:43, Ard Biesheuvel wrote: > On 8 March 2018 at 11:05, Joe Perches wrote: >> On Thu, 2018-03-08 at 08:00 +, Ard Biesheuvel wrote: >>> From: Colin Ian King >>> >>> Don't populate the const read-only

Re: [PATCH 12/12] efi: make const array 'apple' static

On 9 March 2018 at 07:43, Ard Biesheuvel wrote: > On 8 March 2018 at 11:05, Joe Perches wrote: >> On Thu, 2018-03-08 at 08:00 +, Ard Biesheuvel wrote: >>> From: Colin Ian King >>> >>> Don't populate the const read-only array 'buf' on the stack but instead >>> make it static. Makes the

Re: [PATCH 12/12] efi: make const array 'apple' static

On 8 March 2018 at 11:05, Joe Perches wrote: > On Thu, 2018-03-08 at 08:00 +, Ard Biesheuvel wrote: >> From: Colin Ian King >> >> Don't populate the const read-only array 'buf' on the stack but instead >> make it static. Makes the object code

Re: [PATCH 12/12] efi: make const array 'apple' static

On 8 March 2018 at 11:05, Joe Perches wrote: > On Thu, 2018-03-08 at 08:00 +, Ard Biesheuvel wrote: >> From: Colin Ian King >> >> Don't populate the const read-only array 'buf' on the stack but instead >> make it static. Makes the object code smaller by 64 bytes: >> >> Before: >>text

Re: [PATCH 07/12] efi: Use efi_mm in x86 as well as ARM

* Ard Biesheuvel wrote: > From: Sai Praneeth > > Presently, only ARM uses mm_struct to manage efi page tables and efi > runtime region mappings. As this is the preferred approach, let's make > this data structure common across

Re: [PATCH 07/12] efi: Use efi_mm in x86 as well as ARM

* Ard Biesheuvel wrote: > From: Sai Praneeth > > Presently, only ARM uses mm_struct to manage efi page tables and efi > runtime region mappings. As this is the preferred approach, let's make > this data structure common across architectures. Specially, for x86, > using this data structure

Re: [PATCH 0/5] kbuild: always define KBUILD_MODNAME, and clean-up/fix modname

The series build successfully on upstream in my: make allyesconfig and allmodconfig, so, Tested-by: Cao jin -- Sincerely, Cao jin On 03/08/2018 09:04 AM, Masahiro Yamada wrote: > > 3/5 takes into account '-m' case for multi-used-m. > > 2/5 is necessary beforehand

Re: [PATCH 0/5] kbuild: always define KBUILD_MODNAME, and clean-up/fix modname

The series build successfully on upstream in my: make allyesconfig and allmodconfig, so, Tested-by: Cao jin -- Sincerely, Cao jin On 03/08/2018 09:04 AM, Masahiro Yamada wrote: > > 3/5 takes into account '-m' case for multi-used-m. > > 2/5 is necessary beforehand because 3/5 would cause a

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

On Fri, Mar 09, 2018 at 09:00:08AM +0200, Artem Bityutskiy wrote: > On Fri, 2018-03-09 at 09:24 +0800, Ming Lei wrote: > > Hi Thomas, > > > > On Fri, Mar 09, 2018 at 12:20:09AM +0100, Thomas Gleixner wrote: > > > On Thu, 8 Mar 2018, Ming Lei wrote: > > > > Actually, it isn't a real fix, the real

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

On Fri, Mar 09, 2018 at 09:00:08AM +0200, Artem Bityutskiy wrote: > On Fri, 2018-03-09 at 09:24 +0800, Ming Lei wrote: > > Hi Thomas, > > > > On Fri, Mar 09, 2018 at 12:20:09AM +0100, Thomas Gleixner wrote: > > > On Thu, 8 Mar 2018, Ming Lei wrote: > > > > Actually, it isn't a real fix, the real

x86 performance monitor counters save/restore on context switch

Mr. Rostedt and others interested reading on the LKML, I hope that this is the proper venue to ask this (longwinded) question. If it is not, I apologize for the SPAM and wasting everyone's time and bits. I am emailing to ask for clarification about the "policy" of saving and restoring x86

x86 performance monitor counters save/restore on context switch

Mr. Rostedt and others interested reading on the LKML, I hope that this is the proper venue to ask this (longwinded) question. If it is not, I apologize for the SPAM and wasting everyone's time and bits. I am emailing to ask for clarification about the "policy" of saving and restoring x86

Re: [GIT PULL 00/54] perf/core improvements and fixes

Merge branch 'perf/urgent' into perf/core, to resolve conflict (2018-03-07 > 09:23:12 +0100) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo-4.17-20180308 > > for you

Re: [GIT PULL 00/54] perf/core improvements and fixes

rgent' into perf/core, to resolve conflict (2018-03-07 > 09:23:12 +0100) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo-4.17-20180308 > > for you to fetch changes up to 2427b432e6

Re: [PATCH v2 2/6] drm/i915: Move DP modeset retry work into intel_dp

On Thu, Mar 08, 2018 at 06:41:22PM -0500, Lyude Paul wrote: > While having the modeset_retry_work in intel_connector makes sense with > SST, this paradigm doesn't make a whole ton of sense when it comes to > MST since we have to deal with multiple connectors. In most cases, it's > more useful to

Re: [PATCH v2 2/6] drm/i915: Move DP modeset retry work into intel_dp

On Thu, Mar 08, 2018 at 06:41:22PM -0500, Lyude Paul wrote: > While having the modeset_retry_work in intel_connector makes sense with > SST, this paradigm doesn't make a whole ton of sense when it comes to > MST since we have to deal with multiple connectors. In most cases, it's > more useful to

Re: [PATCH] KVM/X86: Check input sreg values before loading vcpu

Hi Radim: Thanks for your review. On 3/9/2018 12:15 AM, rkrc...@redhat.com wrote: > 2018-02-27 06:57+, Tianyu Lan: >> From: Lan Tianyu >> >> This patch is to check sreg value first and then load vcpu in order >> to avoid redundant loading/putting vcpu. >> >>

Re: [PATCH] KVM/X86: Check input sreg values before loading vcpu

Hi Radim: Thanks for your review. On 3/9/2018 12:15 AM, rkrc...@redhat.com wrote: > 2018-02-27 06:57+, Tianyu Lan: >> From: Lan Tianyu >> >> This patch is to check sreg value first and then load vcpu in order >> to avoid redundant loading/putting vcpu. >> >> Signed-off-by: Lan Tianyu

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

Dave, On Fri, Mar 09, 2018 at 02:44:12PM +0800, Dave Young wrote: > On 03/09/18 at 02:02pm, Dave Young wrote: > > On 03/08/18 at 09:05am, Dave Young wrote: > > > [Cc Andrew] > > > > > > On 03/06/18 at 07:22pm, AKASHI Takahiro wrote: > > > > This is a preparatory patch set for adding kexec_file

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

Dave, On Fri, Mar 09, 2018 at 02:44:12PM +0800, Dave Young wrote: > On 03/09/18 at 02:02pm, Dave Young wrote: > > On 03/08/18 at 09:05am, Dave Young wrote: > > > [Cc Andrew] > > > > > > On 03/06/18 at 07:22pm, AKASHI Takahiro wrote: > > > > This is a preparatory patch set for adding kexec_file

Re: [PATCH v8 4/5] iommu/arm-smmu: Add the device_link between masters and smmu

On Thu, Mar 8, 2018 at 10:29 AM, Vivek Gautam wrote: > On Wed, Mar 7, 2018 at 6:17 PM, Robin Murphy wrote: >> On 02/03/18 10:10, Vivek Gautam wrote: >>> >>> From: Sricharan R >>> >>> Finally add the device link between

Re: [PATCH v8 4/5] iommu/arm-smmu: Add the device_link between masters and smmu

On Thu, Mar 8, 2018 at 10:29 AM, Vivek Gautam wrote: > On Wed, Mar 7, 2018 at 6:17 PM, Robin Murphy wrote: >> On 02/03/18 10:10, Vivek Gautam wrote: >>> >>> From: Sricharan R >>> >>> Finally add the device link between the master device and >>> smmu, so that the smmu gets runtime

irqdesc: Why the "__ref" is needed in __irq_alloc_descs() ?

Hi Maintainers, I have a question about "__ref" in Linux kernel. When I looked into the __irq_alloc_descs(), I found it tagged a "__ref" mark, but I didn't find that it referenced code or data from init section. So, I confuse why the "__ref" is needed in __irq_alloc_descs()? any other

irqdesc: Why the "__ref" is needed in __irq_alloc_descs() ?

Hi Maintainers, I have a question about "__ref" in Linux kernel. When I looked into the __irq_alloc_descs(), I found it tagged a "__ref" mark, but I didn't find that it referenced code or data from init section. So, I confuse why the "__ref" is needed in __irq_alloc_descs()? any other

Re: [PATCH 1/6] drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT

On Thu, Mar 08, 2018 at 06:24:15PM -0500, Lyude Paul wrote: > Signed-off-by: Lyude Paul > Cc: Manasi Navare > Cc: Ville Syrjälä Reviewed-by: Manasi Navare > --- >

Re: [PATCH 1/6] drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT

On Thu, Mar 08, 2018 at 06:24:15PM -0500, Lyude Paul wrote: > Signed-off-by: Lyude Paul > Cc: Manasi Navare > Cc: Ville Syrjälä Reviewed-by: Manasi Navare > --- > drivers/gpu/drm/i915/intel_dp.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c

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

On Fri, 2018-03-09 at 09:24 +0800, Ming Lei wrote: > Hi Thomas, > > On Fri, Mar 09, 2018 at 12:20:09AM +0100, Thomas Gleixner wrote: > > On Thu, 8 Mar 2018, Ming Lei wrote: > > > Actually, it isn't a real fix, the real one is in the following > > > two: > > > > > > 0c20244d458e scsi:

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

On Fri, 2018-03-09 at 09:24 +0800, Ming Lei wrote: > Hi Thomas, > > On Fri, Mar 09, 2018 at 12:20:09AM +0100, Thomas Gleixner wrote: > > On Thu, 8 Mar 2018, Ming Lei wrote: > > > Actually, it isn't a real fix, the real one is in the following > > > two: > > > > > > 0c20244d458e scsi:

[PATCH RESEND 1/2] clk: stm32: END_PRIMARY_CLK should be declare after CLK_SYSCLK

From: Gabriel Fernandez Update of END_PRIMARY_CLK was missed, it should be after CLK_SYSCLK hsi and sysclk are overwritten by gpioa and gpiob. Signed-off-by: Gabriel Fernandez Tested-by: Philippe Cornu Reviewed-by: Rob

[PATCH RESEND 1/2] clk: stm32: END_PRIMARY_CLK should be declare after CLK_SYSCLK

From: Gabriel Fernandez Update of END_PRIMARY_CLK was missed, it should be after CLK_SYSCLK hsi and sysclk are overwritten by gpioa and gpiob. Signed-off-by: Gabriel Fernandez Tested-by: Philippe Cornu Reviewed-by: Rob Herring --- include/dt-bindings/clock/stm32fx-clock.h | 6 +++--- 1 file

[PATCH RESEND 2/2] clk: stm32: Add DSI clock for STM32F469 Board

From: Gabriel Fernandez This patch adds DSI clock for STM32F469 board Signed-off-by: Gabriel Fernandez --- drivers/clk/clk-stm32f4.c | 11 ++- include/dt-bindings/clock/stm32fx-clock.h | 3 ++- 2 files changed, 12

[PATCH RESEND 2/2] clk: stm32: Add DSI clock for STM32F469 Board

From: Gabriel Fernandez This patch adds DSI clock for STM32F469 board Signed-off-by: Gabriel Fernandez --- drivers/clk/clk-stm32f4.c | 11 ++- include/dt-bindings/clock/stm32fx-clock.h | 3 ++- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git

[PATCH RESEND 0/2] Add dsi clock for stm32f469 board

From: Gabriel Fernandez This patch-set adds the dsi clock for stm32f469 board. Gabriel Fernandez (2): clk: stm32: END_PRIMARY_CLK should be declare after CLK_SYSCLK clk: stm32: Add DSI clock for STM32F469 Board drivers/clk/clk-stm32f4.c | 11

[PATCH RESEND 0/2] Add dsi clock for stm32f469 board

From: Gabriel Fernandez This patch-set adds the dsi clock for stm32f469 board. Gabriel Fernandez (2): clk: stm32: END_PRIMARY_CLK should be declare after CLK_SYSCLK clk: stm32: Add DSI clock for STM32F469 Board drivers/clk/clk-stm32f4.c | 11 ++-

Re: [PATCH] rcu: exp: Fix "must hold exp_mutex" comments for QS reporting functions

On Thu, Mar 08, 2018 at 07:42:55AM -0800, Paul E. McKenney wrote: > On Thu, Mar 08, 2018 at 04:30:06PM +0800, Boqun Feng wrote: > > On Thu, Mar 08, 2018 at 12:54:29PM +0800, Boqun Feng wrote: > > > On Wed, Mar 07, 2018 at 08:30:17PM -0800, Paul E. McKenney wrote: > > > [...] > > > > > > > > > >

Re: [PATCH] rcu: exp: Fix "must hold exp_mutex" comments for QS reporting functions

On Thu, Mar 08, 2018 at 07:42:55AM -0800, Paul E. McKenney wrote: > On Thu, Mar 08, 2018 at 04:30:06PM +0800, Boqun Feng wrote: > > On Thu, Mar 08, 2018 at 12:54:29PM +0800, Boqun Feng wrote: > > > On Wed, Mar 07, 2018 at 08:30:17PM -0800, Paul E. McKenney wrote: > > > [...] > > > > > > > > > >

[RFC] rtmutex: Make rt_mutex_futex_unlock() safe at irq-off callsites

When running rcutorture with TREE03 config, CONFIG_PROVE_LOCKING=y, and kernel cmdline argument "rcutorture.gp_exp=1", lockdep reported a HARDIRQ-safe->HARDIRQ-unsafe deadlock: | [ 467.250290] | [ 467.250825] WARNING: inconsistent lock state | [ 467.251341]

[RFC] rtmutex: Make rt_mutex_futex_unlock() safe at irq-off callsites

When running rcutorture with TREE03 config, CONFIG_PROVE_LOCKING=y, and kernel cmdline argument "rcutorture.gp_exp=1", lockdep reported a HARDIRQ-safe->HARDIRQ-unsafe deadlock: | [ 467.250290] | [ 467.250825] WARNING: inconsistent lock state | [ 467.251341]

[PATCH net 3/3] vhost_net: examine pointer types during un-producing

After commit fc72d1d54dd9 ("tuntap: XDP transmission"), we can actually queueing XDP pointers in the pointer ring, so we should examine the pointer type before freeing the pointer. Fixes: fc72d1d54dd9 ("tuntap: XDP transmission") Reported-by: Michael S. Tsirkin Acked-by: Michael

[PATCH net 2/3] vhost_net: keep private_data and rx_ring synced

We get pointer ring from the exported sock, this means we should keep rx_ring and vq->private synced during both vq stop and backend set, otherwise we may see stale rx_ring. Fixes: c67df11f6e480 ("vhost_net: try batch dequing from skb array") Signed-off-by: Michael S. Tsirkin

[PATCH net 3/3] vhost_net: examine pointer types during un-producing

After commit fc72d1d54dd9 ("tuntap: XDP transmission"), we can actually queueing XDP pointers in the pointer ring, so we should examine the pointer type before freeing the pointer. Fixes: fc72d1d54dd9 ("tuntap: XDP transmission") Reported-by: Michael S. Tsirkin Acked-by: Michael S. Tsirkin

[PATCH net 2/3] vhost_net: keep private_data and rx_ring synced

We get pointer ring from the exported sock, this means we should keep rx_ring and vq->private synced during both vq stop and backend set, otherwise we may see stale rx_ring. Fixes: c67df11f6e480 ("vhost_net: try batch dequing from skb array") Signed-off-by: Michael S. Tsirkin Signed-off-by:

[PATCH net 1/3] vhost_net: initialize rx_ring in vhost_net_open()

From: Alexander Potapenko KMSAN reported a use of uninit memory in vhost_net_buf_unproduce() while trying to access n->vqs[VHOST_NET_VQ_TX].rx_ring: == BUG: KMSAN: use of uninitialized memory in

[PATCH net 0/3] Several fixes for vhost_net ptr_ring usage

Hi: This small series try to fix several bugs of ptr_ring usage in vhost_net. Please review. Thanks Alexander Potapenko (1): vhost_net: initialize rx_ring in vhost_net_open() Jason Wang (2): vhost_net: keep private_data and rx_ring synced vhost_net: examine pointer types during

[PATCH net 0/3] Several fixes for vhost_net ptr_ring usage

Hi: This small series try to fix several bugs of ptr_ring usage in vhost_net. Please review. Thanks Alexander Potapenko (1): vhost_net: initialize rx_ring in vhost_net_open() Jason Wang (2): vhost_net: keep private_data and rx_ring synced vhost_net: examine pointer types during

[PATCH net 1/3] vhost_net: initialize rx_ring in vhost_net_open()

From: Alexander Potapenko KMSAN reported a use of uninit memory in vhost_net_buf_unproduce() while trying to access n->vqs[VHOST_NET_VQ_TX].rx_ring: == BUG: KMSAN: use of uninitialized memory in vhost_net_buf_unproduce+0x7bb/0x9a0

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

On 03/09/18 at 02:02pm, Dave Young wrote: > On 03/08/18 at 09:05am, Dave Young wrote: > > [Cc Andrew] > > > > On 03/06/18 at 07:22pm, AKASHI Takahiro wrote: > > > This is a preparatory patch set for adding kexec_file support on arm64. > > > > > > It was originally included in a arm64 patch

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

On 03/09/18 at 02:02pm, Dave Young wrote: > On 03/08/18 at 09:05am, Dave Young wrote: > > [Cc Andrew] > > > > On 03/06/18 at 07:22pm, AKASHI Takahiro wrote: > > > This is a preparatory patch set for adding kexec_file support on arm64. > > > > > > It was originally included in a arm64 patch

[lkp-robot] [hugetlbfs] 49977c3afc: BUG_hugetlbfs_inode_cache(Not_tainted):Objects_remaining_in_hugetlbfs_inode_cache_on__kmem_cache_shutdown()

FYI, we noticed the following commit (built with gcc-6): commit: 49977c3afcdd2d94237d4bf6866d3515c60762be ("hugetlbfs: Convert to fs_context") https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git mount-context in testcase: trinity with following parameters: runtime: 300s

[lkp-robot] [hugetlbfs] 49977c3afc: BUG_hugetlbfs_inode_cache(Not_tainted):Objects_remaining_in_hugetlbfs_inode_cache_on__kmem_cache_shutdown()

FYI, we noticed the following commit (built with gcc-6): commit: 49977c3afcdd2d94237d4bf6866d3515c60762be ("hugetlbfs: Convert to fs_context") https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git mount-context in testcase: trinity with following parameters: runtime: 300s

[PATCH] rsi: Remove stack VLA usage

The kernel would like to have all stack VLA usage removed[1]. rsi uses a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size is defined using a magic number. We can use a pre-processor defined constant and declare the array to maximum size. We add a check before accessing the

[PATCH] rsi: Remove stack VLA usage

The kernel would like to have all stack VLA usage removed[1]. rsi uses a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size is defined using a magic number. We can use a pre-processor defined constant and declare the array to maximum size. We add a check before accessing the

Re: [PATCH 4/4] video: Remove stack VLA usage

I sent a patch for this six hours ago: https://patchwork.kernel.org/patch/10268591/ -- Gustavo On 03/09/2018 12:11 AM, Tycho Andersen wrote: On Thu, Mar 08, 2018 at 10:01:07PM -0800, Joe Perches wrote: On Fri, 2018-03-09 at 16:50 +1100, Tobin C. Harding wrote: The kernel would like to have

Re: [PATCH 4/4] video: Remove stack VLA usage

I sent a patch for this six hours ago: https://patchwork.kernel.org/patch/10268591/ -- Gustavo On 03/09/2018 12:11 AM, Tycho Andersen wrote: On Thu, Mar 08, 2018 at 10:01:07PM -0800, Joe Perches wrote: On Fri, 2018-03-09 at 16:50 +1100, Tobin C. Harding wrote: The kernel would like to have

Re: [alsa-devel] [BUG] Kernel crash on Allwinner H3 due to sound core changes

Hi, Dne petek, 09. marec 2018 ob 00:49:18 CET je Kuninori Morimoto napisal(a): > Hi Mark,Jernej > > > > Ahh.. indeed. Good catch ! > > > How about to add such flag ? > > > This is just idea. No tested, No compiled, but can help you ? > > > > I think this makes sense as a patch. We might want

Re: [alsa-devel] [BUG] Kernel crash on Allwinner H3 due to sound core changes

Hi, Dne petek, 09. marec 2018 ob 00:49:18 CET je Kuninori Morimoto napisal(a): > Hi Mark,Jernej > > > > Ahh.. indeed. Good catch ! > > > How about to add such flag ? > > > This is just idea. No tested, No compiled, but can help you ? > > > > I think this makes sense as a patch. We might want

[git pull] drm fixes for 4.16-rc5

Hi Linus, There are a small set of sun4i and i915 fixes: sun4i: divide by zero, clock and LVDS fixes i915: 1 fix for perf and a 1 race fix However amdgpu is a bit more than we are normally comfortable with at this point, however it does fix a lot of display issues with the new DC code which

[git pull] drm fixes for 4.16-rc5

Hi Linus, There are a small set of sun4i and i915 fixes: sun4i: divide by zero, clock and LVDS fixes i915: 1 fix for perf and a 1 race fix However amdgpu is a bit more than we are normally comfortable with at this point, however it does fix a lot of display issues with the new DC code which

Re: [PATCH 4/4] video: Remove stack VLA usage

On Fri, Mar 09, 2018 at 12:16:21AM -0600, Gustavo A. R. Silva wrote: > > I sent a patch for this six hours ago: > > https://patchwork.kernel.org/patch/10268591/ > > -- > Gustavo lol, I knew there would be a race on to fix these :) And you got it right, bonus points. Let's drop this one then.

Re: [PATCH 4/4] video: Remove stack VLA usage

On Fri, Mar 09, 2018 at 12:16:21AM -0600, Gustavo A. R. Silva wrote: > > I sent a patch for this six hours ago: > > https://patchwork.kernel.org/patch/10268591/ > > -- > Gustavo lol, I knew there would be a race on to fix these :) And you got it right, bonus points. Let's drop this one then.

[PATCH] f2fs: remove unneeded set_cold_node()

When setting COLD_BIT_SHIFT flag in node block, we only need to call set_cold_node() in new_node_page() and recover_inode_page() during node page initialization. So remove unneeded set_cold_node() in other places. Signed-off-by: Chao Yu --- fs/f2fs/dir.c | 2 --

[PATCH] f2fs: remove unneeded set_cold_node()

When setting COLD_BIT_SHIFT flag in node block, we only need to call set_cold_node() in new_node_page() and recover_inode_page() during node page initialization. So remove unneeded set_cold_node() in other places. Signed-off-by: Chao Yu --- fs/f2fs/dir.c | 2 -- fs/f2fs/inode.c | 1 -

Re: [PATCH] f2fs: avoid selinux denial on CAP_SYS_RESOURCE

On 2018/3/9 12:49, Jaegeuk Kim wrote: > This fixes CAP_SYS_RESOURCE denial of selinux when using resgid. A little confusion, if capable(CAP_SYS_RESOURCE) is false, we still have chance to return true for below resuid & resgid cases, right? Thanks, > > Signed-off-by: Jaegeuk Kim

Re: [PATCH] f2fs: avoid selinux denial on CAP_SYS_RESOURCE

On 2018/3/9 12:49, Jaegeuk Kim wrote: > This fixes CAP_SYS_RESOURCE denial of selinux when using resgid. A little confusion, if capable(CAP_SYS_RESOURCE) is false, we still have chance to return true for below resuid & resgid cases, right? Thanks, > > Signed-off-by: Jaegeuk Kim > --- >

Re: [PATCH net] vhost_net: examine pointer types during un-producing

On 2018年03月09日 11:16, Jason Wang wrote: After commit 761876c857cb ("tap: XDP support"), we can actually queueing XDP pointers in the pointer ring, so we should examine the pointer type before freeing the pointer. Fixes: 761876c857cb ("tap: XDP support") Oops, the commit is wrong, let me

Re: [PATCH net] vhost_net: examine pointer types during un-producing

On 2018年03月09日 11:16, Jason Wang wrote: After commit 761876c857cb ("tap: XDP support"), we can actually queueing XDP pointers in the pointer ring, so we should examine the pointer type before freeing the pointer. Fixes: 761876c857cb ("tap: XDP support") Oops, the commit is wrong, let me

[PATCH] staging: vchiq_arm: Clear VLA warning

The kernel would like to have all stack VLA usage removed[1]. The array here is fixed (declared with a const variable) but it appears like VLA to the compiler. We can use a pre-processor define to quiet the compiler. [1]: https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Tobin C. Harding

[PATCH] staging: vchiq_arm: Clear VLA warning

The kernel would like to have all stack VLA usage removed[1]. The array here is fixed (declared with a const variable) but it appears like VLA to the compiler. We can use a pre-processor define to quiet the compiler. [1]: https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Tobin C. Harding ---

Re: [linux-sunxi] [PATCH v3 06/16] drm/sun4i: Release exclusive clock lock when disabling TCON

Hi, Dne petek, 09. marec 2018 ob 01:44:55 CET je Ondřej Jirman napisal(a): > Hi, > > I've debugged this further and it seems that the code has incorrect > assumptions. See docs for mode_set_nofb. > > https://elixir.bootlin.com/linux/v4.16-rc4/source/include/drm/drm_modeset_he >

Re: [linux-sunxi] [PATCH v3 06/16] drm/sun4i: Release exclusive clock lock when disabling TCON

Hi, Dne petek, 09. marec 2018 ob 01:44:55 CET je Ondřej Jirman napisal(a): > Hi, > > I've debugged this further and it seems that the code has incorrect > assumptions. See docs for mode_set_nofb. > > https://elixir.bootlin.com/linux/v4.16-rc4/source/include/drm/drm_modeset_he >

Re: [PATCH 4/4] video: Remove stack VLA usage

On Thu, Mar 08, 2018 at 10:01:07PM -0800, Joe Perches wrote: > On Fri, 2018-03-09 at 16:50 +1100, Tobin C. Harding wrote: > > The kernel would like to have all stack VLA usage removed[1]. The > > arrays are fixed here (declared with a const variable) but they appear > > like VLAs to the compiler.

Re: [PATCH 4/4] video: Remove stack VLA usage

On Thu, Mar 08, 2018 at 10:01:07PM -0800, Joe Perches wrote: > On Fri, 2018-03-09 at 16:50 +1100, Tobin C. Harding wrote: > > The kernel would like to have all stack VLA usage removed[1]. The > > arrays are fixed here (declared with a const variable) but they appear > > like VLAs to the compiler.

[PATCH v2] usb: Remove stack VLA usage

The kernel would like to have all stack VLA usage removed[1]. We already have a pre-processor constant defined MAX_SGLEN. We can use this instead of the variable param-sglen. [1]: https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Tobin C. Harding --- drivers/usb/misc/usbtest.c

[PATCH v2] usb: Remove stack VLA usage

The kernel would like to have all stack VLA usage removed[1]. We already have a pre-processor constant defined MAX_SGLEN. We can use this instead of the variable param-sglen. [1]: https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Tobin C. Harding --- drivers/usb/misc/usbtest.c | 5 - 1

Re: [PATCH] vfio-mdev/samples: change RDI interrupt condition

Thanks for fixing it. Patch looks good to me. +Alex to pull this patch. Reviewed by: Kirti Wankhede Thanks, Kirti On 3/8/2018 12:38 PM, Shunyong Yang wrote: > When FIFO mode is enabled, the receive data available interrupt > (UART_IIR_RDI in code) should be triggered

Re: [PATCH] vfio-mdev/samples: change RDI interrupt condition

Thanks for fixing it. Patch looks good to me. +Alex to pull this patch. Reviewed by: Kirti Wankhede Thanks, Kirti On 3/8/2018 12:38 PM, Shunyong Yang wrote: > When FIFO mode is enabled, the receive data available interrupt > (UART_IIR_RDI in code) should be triggered when the number of data >

Re: [PATCH 3/4] usb: Remove stack VLA usage

On Fri, Mar 09, 2018 at 04:55:35PM +1100, Tobin C. Harding wrote: > Signed-off-by: Tobin C. Harding > --- Please drop this. To much on github not writing proper commit logs :( v2 to come. thanks, Tobin.

Re: [PATCH 3/4] usb: Remove stack VLA usage

On Fri, Mar 09, 2018 at 04:55:35PM +1100, Tobin C. Harding wrote: > Signed-off-by: Tobin C. Harding > --- Please drop this. To much on github not writing proper commit logs :( v2 to come. thanks, Tobin.

[PATCH v2] perf machine: Fix load kernel symbol with '-k' option

On Hikey arm64 octa A53 platform, when use command './perf report -v -k vmlinux --stdio' it outputs below error info, and it skips to load kernel symbol and doesn't print symbol for event: Failed to open [kernel.kallsyms]_text, continuing without symbols. The regression is introduced by commit

[PATCH v2] perf machine: Fix load kernel symbol with '-k' option

On Hikey arm64 octa A53 platform, when use command './perf report -v -k vmlinux --stdio' it outputs below error info, and it skips to load kernel symbol and doesn't print symbol for event: Failed to open [kernel.kallsyms]_text, continuing without symbols. The regression is introduced by commit

Re: [PATCH 4/4] video: Remove stack VLA usage

On Thu, Mar 08, 2018 at 10:01:07PM -0800, Joe Perches wrote: > On Fri, 2018-03-09 at 16:50 +1100, Tobin C. Harding wrote: > > The kernel would like to have all stack VLA usage removed[1]. The > > arrays are fixed here (declared with a const variable) but they appear > > like VLAs to the compiler.

Re: [PATCH 4/4] video: Remove stack VLA usage

On Thu, Mar 08, 2018 at 10:01:07PM -0800, Joe Perches wrote: > On Fri, 2018-03-09 at 16:50 +1100, Tobin C. Harding wrote: > > The kernel would like to have all stack VLA usage removed[1]. The > > arrays are fixed here (declared with a const variable) but they appear > > like VLAs to the compiler.

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

On 03/08/18 at 09:05am, Dave Young wrote: > [Cc Andrew] > > On 03/06/18 at 07:22pm, AKASHI Takahiro wrote: > > This is a preparatory patch set for adding kexec_file support on arm64. > > > > It was originally included in a arm64 patch set[1], but Philipp is also > > working on their kexec_file

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

On 03/08/18 at 09:05am, Dave Young wrote: > [Cc Andrew] > > On 03/06/18 at 07:22pm, AKASHI Takahiro wrote: > > This is a preparatory patch set for adding kexec_file support on arm64. > > > > It was originally included in a arm64 patch set[1], but Philipp is also > > working on their kexec_file

Re: [PATCH] perf machine: Fix load kernel symbol with '-k' option

Hi Mathieu, On Wed, Mar 07, 2018 at 02:09:24PM -0700, Mathieu Poirier wrote: > Hi Leo, > > On 27 February 2018 at 00:17, Leo Yan wrote: > > On Hikey arm64 octa A53 platform, when use command './perf report -v > > -k vmlinux --stdio' it outputs below error info, and it skips

Re: [PATCH 4/4] video: Remove stack VLA usage

On Fri, 2018-03-09 at 16:50 +1100, Tobin C. Harding wrote: > The kernel would like to have all stack VLA usage removed[1]. The > arrays are fixed here (declared with a const variable) but they appear > like VLAs to the compiler. We can use a pre-processor define to fix the > warning. [] > diff

Re: [PATCH] perf machine: Fix load kernel symbol with '-k' option

Hi Mathieu, On Wed, Mar 07, 2018 at 02:09:24PM -0700, Mathieu Poirier wrote: > Hi Leo, > > On 27 February 2018 at 00:17, Leo Yan wrote: > > On Hikey arm64 octa A53 platform, when use command './perf report -v > > -k vmlinux --stdio' it outputs below error info, and it skips to load > > kernel

Re: [PATCH 4/4] video: Remove stack VLA usage

On Fri, 2018-03-09 at 16:50 +1100, Tobin C. Harding wrote: > The kernel would like to have all stack VLA usage removed[1]. The > arrays are fixed here (declared with a const variable) but they appear > like VLAs to the compiler. We can use a pre-processor define to fix the > warning. [] > diff

  1   2   3   4   5   6   7   8   9   10   >