Re: [PATCH v8 0/6] optimize memblock_next_valid_pfn and early_pfn_valid on arm and arm64

> I'm wondering, ain't simple enabling of config > DEFERRED_STRUCT_PAGE_INIT provide even better speed-up? If that is the > case then it seems like this series is not needed at all, right? > I am not sure why is this config optional. It looks like it could be > enabled by default or even

Re: [PATCH v8 0/6] optimize memblock_next_valid_pfn and early_pfn_valid on arm and arm64

> I'm wondering, ain't simple enabling of config > DEFERRED_STRUCT_PAGE_INIT provide even better speed-up? If that is the > case then it seems like this series is not needed at all, right? > I am not sure why is this config optional. It looks like it could be > enabled by default or even

Re: [PATCH] atm: zatm: Fix potential Spectre v1

From: "Gustavo A. R. Silva" Date: Thu, 3 May 2018 13:17:12 -0500 > pool can be indirectly controlled by user-space, hence leading to > a potential exploitation of the Spectre variant 1 vulnerability. > > This issue was detected with the help of Smatch: > >

Re: [PATCH] atm: zatm: Fix potential Spectre v1

From: "Gustavo A. R. Silva" Date: Thu, 3 May 2018 13:17:12 -0500 > pool can be indirectly controlled by user-space, hence leading to > a potential exploitation of the Spectre variant 1 vulnerability. > > This issue was detected with the help of Smatch: > > drivers/atm/zatm.c:1462 zatm_ioctl()

Re: [PATCH] net: atm: Fix potential Spectre v1

From: "Gustavo A. R. Silva" Date: Thu, 3 May 2018 13:45:58 -0500 > ioc_data.dev_num can be controlled by user-space, hence leading to > a potential exploitation of the Spectre variant 1 vulnerability. > > This issue was detected with the help of Smatch: >

Re: [PATCH] net: atm: Fix potential Spectre v1

From: "Gustavo A. R. Silva" Date: Thu, 3 May 2018 13:45:58 -0500 > ioc_data.dev_num can be controlled by user-space, hence leading to > a potential exploitation of the Spectre variant 1 vulnerability. > > This issue was detected with the help of Smatch: > net/atm/lec.c:702 lec_vcc_attach()

Re: [PATCH net-next] net: hns3: Add support of hardware rx-vlan-offload to HNS3 VF driver

From: Salil Mehta Date: Thu, 3 May 2018 17:28:11 +0100 > From: Yunsheng Lin > > This patch adds support of hardware rx-vlan-offload to VF driver. > VF uses mailbox to convey PF to configure the hardware. > > Signed-off-by: Yunsheng Lin

Re: [PATCH net-next] net: hns3: Add support of hardware rx-vlan-offload to HNS3 VF driver

From: Salil Mehta Date: Thu, 3 May 2018 17:28:11 +0100 > From: Yunsheng Lin > > This patch adds support of hardware rx-vlan-offload to VF driver. > VF uses mailbox to convey PF to configure the hardware. > > Signed-off-by: Yunsheng Lin > Signed-off-by: Peng Li > Signed-off-by: Salil Mehta

Re: [v8] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

Quoting Taniya Das (2018-05-04 03:02:38) > diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c > new file mode 100644 > index 000..944fe04 > --- /dev/null > +++ b/drivers/clk/qcom/clk-rpmh.c > @@ -0,0 +1,334 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c)

Re: [v8] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

Quoting Taniya Das (2018-05-04 03:02:38) > diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c > new file mode 100644 > index 000..944fe04 > --- /dev/null > +++ b/drivers/clk/qcom/clk-rpmh.c > @@ -0,0 +1,334 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c)

[PATCH] fuse: Ensure posix acls are translated outside of init_user_ns

Ensure the translation happens by failing to read or write posix acls when the filesystem has not indicated it supports posix acls. This ensures that modern cached posix acl support is available and used when dealing with posix acls. This is important because only that path has the code to

[PATCH] fuse: Ensure posix acls are translated outside of init_user_ns

Ensure the translation happens by failing to read or write posix acls when the filesystem has not indicated it supports posix acls. This ensures that modern cached posix acl support is available and used when dealing with posix acls. This is important because only that path has the code to

[PATCH] selftests: net: use TEST_PROGS_EXTENDED

When a script file that isn't generated uses the variable TEST_GEN_PROGS_EXTENDED and a 'make -C tools/testing/selftests clean' is performed the script file gets removed and git shows the file as deleted. For script files that isn't generated TEST_PROGS_EXTENDED should be used. Fixes:

[PATCH] selftests: net: use TEST_PROGS_EXTENDED

When a script file that isn't generated uses the variable TEST_GEN_PROGS_EXTENDED and a 'make -C tools/testing/selftests clean' is performed the script file gets removed and git shows the file as deleted. For script files that isn't generated TEST_PROGS_EXTENDED should be used. Fixes:

Re: [PATCH v2 07/10] PCI: Convert of_pci_get_host_bridge_resources() users to devm variant

On Thu, May 03, 2018 at 10:18:24AM +0300, Vladimir Zapolskiy wrote: > Hi Jan, > > On 04/30/2018 08:48 AM, Jan Kiszka wrote: > > From: Jan Kiszka > > > > Straightforward for all of them, no more leaks afterwards. > > > > CC: Jingoo Han > > CC: Joao

Re: [PATCH v2 07/10] PCI: Convert of_pci_get_host_bridge_resources() users to devm variant

On Thu, May 03, 2018 at 10:18:24AM +0300, Vladimir Zapolskiy wrote: > Hi Jan, > > On 04/30/2018 08:48 AM, Jan Kiszka wrote: > > From: Jan Kiszka > > > > Straightforward for all of them, no more leaks afterwards. > > > > CC: Jingoo Han > > CC: Joao Pinto > > CC: Lorenzo Pieralisi > >

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

Oleg Nesterov writes: > On 05/04, Eric W. Biederman wrote: >> >> Oleg Nesterov writes: >> >> > I'd vote for the change in exec_mmap(). This way mm_init_memcg() can just >> > nullify mm->memcg. >> >> There is at least one common path where we need the memory

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

Oleg Nesterov writes: > On 05/04, Eric W. Biederman wrote: >> >> Oleg Nesterov writes: >> >> > I'd vote for the change in exec_mmap(). This way mm_init_memcg() can just >> > nullify mm->memcg. >> >> There is at least one common path where we need the memory control group >> properly initialized

Re: Introduce atomic_dec_and_lock_irqsave()

On Fri, May 04, 2018 at 05:26:40PM +0100, Al Viro wrote: > On Fri, May 04, 2018 at 06:21:02PM +0200, Peter Zijlstra wrote: > > On Fri, May 04, 2018 at 06:07:26PM +0200, Sebastian Andrzej Siewior wrote: > > > > > do you intend to kill refcount_dec_and_lock() in the longterm? > > > > You meant to

Re: Introduce atomic_dec_and_lock_irqsave()

On Fri, May 04, 2018 at 05:26:40PM +0100, Al Viro wrote: > On Fri, May 04, 2018 at 06:21:02PM +0200, Peter Zijlstra wrote: > > On Fri, May 04, 2018 at 06:07:26PM +0200, Sebastian Andrzej Siewior wrote: > > > > > do you intend to kill refcount_dec_and_lock() in the longterm? > > > > You meant to

[PATCH v2] serial: sh-sci: Use spin_{try}lock_irqsave instead of open coding version

From: Daniel Wagner Commit 40f70c03e33a ("serial: sh-sci: add locking to console write function to avoid SMP lockup") copied the strategy to avoid locking problems in conjuncture with the console from the UART8250 driver. Instead using directly

[PATCH v2] serial: sh-sci: Use spin_{try}lock_irqsave instead of open coding version

From: Daniel Wagner Commit 40f70c03e33a ("serial: sh-sci: add locking to console write function to avoid SMP lockup") copied the strategy to avoid locking problems in conjuncture with the console from the UART8250 driver. Instead using directly spin_{try}lock_irqsave(), local_irq_save() followed

Re: [PATCH v1 0/2] Add QCOM video clock controller driver

Quoting Amit Nischal (2018-05-03 05:35:23) > Changes in v1: >https://lkml.org/lkml/2018/4/24/545 > Addressed below review comments given by Rob > - Change the compatible property as per ',-' format. > - Add header definitions for resets and power-domain cells. You didn't add any reset

Re: [PATCH v1 0/2] Add QCOM video clock controller driver

Quoting Amit Nischal (2018-05-03 05:35:23) > Changes in v1: >https://lkml.org/lkml/2018/4/24/545 > Addressed below review comments given by Rob > - Change the compatible property as per ',-' format. > - Add header definitions for resets and power-domain cells. You didn't add any reset

Re: rcu-bh design

On Fri, 04 May 2018 16:20:11 + Joel Fernandes wrote: > Hi Paul, everyone, > > I had some question(s) about rcu-bh design. > I am trying to understand the reasoning or need of it. I see that rcu-bh > will disable softirqs across read-side sections. But I am wondering why >

Re: rcu-bh design

On Fri, 04 May 2018 16:20:11 + Joel Fernandes wrote: > Hi Paul, everyone, > > I had some question(s) about rcu-bh design. > I am trying to understand the reasoning or need of it. I see that rcu-bh > will disable softirqs across read-side sections. But I am wondering why > this is needed.

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote: > pci_epf_test_write() is never called in atomic context. > > The call chain ending up at pci_epf_test_write() is: > [1] pci_epf_test_write() <- pci_epf_test_cmd_handler() > > pci_epf_test_cmd_handler() is set as a parameter of

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote: > pci_epf_test_write() is never called in atomic context. > > The call chain ending up at pci_epf_test_write() is: > [1] pci_epf_test_write() <- pci_epf_test_cmd_handler() > > pci_epf_test_cmd_handler() is set as a parameter of

Re: [RFC PATCH] Add /proc//numa_vamaps for numa node information

On 5/4/18 7:57 AM, Christopher Lameter wrote: On Thu, 3 May 2018, prakash.sangappa wrote: exact numa node from where the pages have been allocated. Cant you write a small script that scans the information in numa_maps and then displays the total pages per NUMA node and then a list of which

Re: [RFC PATCH] Add /proc//numa_vamaps for numa node information

On 5/4/18 7:57 AM, Christopher Lameter wrote: On Thu, 3 May 2018, prakash.sangappa wrote: exact numa node from where the pages have been allocated. Cant you write a small script that scans the information in numa_maps and then displays the total pages per NUMA node and then a list of which

Re: Introduce atomic_dec_and_lock_irqsave()

On Fri, May 04, 2018 at 06:21:02PM +0200, Peter Zijlstra wrote: > On Fri, May 04, 2018 at 06:07:26PM +0200, Sebastian Andrzej Siewior wrote: > > > do you intend to kill refcount_dec_and_lock() in the longterm? > > You meant to say atomic_dec_and_lock() ? Dunno if we ever get there, but >

Re: Introduce atomic_dec_and_lock_irqsave()

On Fri, May 04, 2018 at 06:21:02PM +0200, Peter Zijlstra wrote: > On Fri, May 04, 2018 at 06:07:26PM +0200, Sebastian Andrzej Siewior wrote: > > > do you intend to kill refcount_dec_and_lock() in the longterm? > > You meant to say atomic_dec_and_lock() ? Dunno if we ever get there, but >

Re: perf: fuzzer causes stack going in wrong direction warnings

On Fri, May 04, 2018 at 10:35:53AM -0400, Vince Weaver wrote: > On Wed, 2 May 2018, Josh Poimboeuf wrote: > > > After looking closer, I realized that at least some of these warnings > > are due to bad unwind hints in the entry code. Can you try this patch > > instead of the last one? > > with

Re: perf: fuzzer causes stack going in wrong direction warnings

On Fri, May 04, 2018 at 10:35:53AM -0400, Vince Weaver wrote: > On Wed, 2 May 2018, Josh Poimboeuf wrote: > > > After looking closer, I realized that at least some of these warnings > > are due to bad unwind hints in the entry code. Can you try this patch > > instead of the last one? > > with

Re: [PATCH v2 1/4] KVM: arm/arm64: Share common code in user_mem_abort()

Christoffer Dall writes: > On Tue, May 01, 2018 at 11:26:56AM +0100, Punit Agrawal wrote: >> The code for operations such as marking the pfn as dirty, and >> dcache/icache maintenance during stage 2 fault handling is duplicated >> between normal pages and PMD hugepages.

Re: [PATCH v2 1/4] KVM: arm/arm64: Share common code in user_mem_abort()

Christoffer Dall writes: > On Tue, May 01, 2018 at 11:26:56AM +0100, Punit Agrawal wrote: >> The code for operations such as marking the pfn as dirty, and >> dcache/icache maintenance during stage 2 fault handling is duplicated >> between normal pages and PMD hugepages. >> >> Instead of

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

On 05/04, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > > I'd vote for the change in exec_mmap(). This way mm_init_memcg() can just > > nullify mm->memcg. > > There is at least one common path where we need the memory control group > properly initialized so memory

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

On 05/04, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > > I'd vote for the change in exec_mmap(). This way mm_init_memcg() can just > > nullify mm->memcg. > > There is at least one common path where we need the memory control group > properly initialized so memory allocations don't

Re: [PATCH 01/30] gcc-plugins: fix build condition of SANCOV plugin

On Fri, May 4, 2018 at 7:21 AM, Masahiro Yamada wrote: > Hi Kees, > > > 2018-04-13 14:06 GMT+09:00 Masahiro Yamada : >> Since commit d677a4d60193 ("Makefile: support flag >> -fsanitizer-coverage=trace-cmp"), you miss to build the

Re: [PATCH 01/30] gcc-plugins: fix build condition of SANCOV plugin

On Fri, May 4, 2018 at 7:21 AM, Masahiro Yamada wrote: > Hi Kees, > > > 2018-04-13 14:06 GMT+09:00 Masahiro Yamada : >> Since commit d677a4d60193 ("Makefile: support flag >> -fsanitizer-coverage=trace-cmp"), you miss to build the SANCOV >> plugin under some circumstances. >> >> CONFIG_KCOV=y >>

Re: Introduce atomic_dec_and_lock_irqsave()

On Fri, May 04, 2018 at 06:07:26PM +0200, Sebastian Andrzej Siewior wrote: > do you intend to kill refcount_dec_and_lock() in the longterm? You meant to say atomic_dec_and_lock() ? Dunno if we ever get there, but typically dec_and_lock is fairly refcounty, but I suppose it is possible to have

Re: Introduce atomic_dec_and_lock_irqsave()

On Fri, May 04, 2018 at 06:07:26PM +0200, Sebastian Andrzej Siewior wrote: > do you intend to kill refcount_dec_and_lock() in the longterm? You meant to say atomic_dec_and_lock() ? Dunno if we ever get there, but typically dec_and_lock is fairly refcounty, but I suppose it is possible to have

rcu-bh design

Hi Paul, everyone, I had some question(s) about rcu-bh design. I am trying to understand the reasoning or need of it. I see that rcu-bh will disable softirqs across read-side sections. But I am wondering why this is needed. __do_softirq already disables softirq when a softirq handler is running.

rcu-bh design

Hi Paul, everyone, I had some question(s) about rcu-bh design. I am trying to understand the reasoning or need of it. I see that rcu-bh will disable softirqs across read-side sections. But I am wondering why this is needed. __do_softirq already disables softirq when a softirq handler is running.

Re: [v4.17-rcx] Lost IBPB, IBRS_FW support for spectre_v2 mitigation.

On Wed, May 02, 2018 at 02:20:52PM +0200, Thomas Gleixner wrote: > Thanks for confirming. Still need to find a way which is less fragile, but > that's probably too much of churn for rc4 > > At least I know exactly what's happening, so I can write a better changelog. > > Thanks for testing!

Re: [RFC PATCH] Add /proc//numa_vamaps for numa node information

On 5/4/18 4:12 AM, Michal Hocko wrote: On Thu 03-05-18 15:39:49, prakash.sangappa wrote: On 05/03/2018 11:03 AM, Christopher Lameter wrote: On Tue, 1 May 2018, Prakash Sangappa wrote: For analysis purpose it is useful to have numa node information corresponding mapped address ranges of

Re: [v4.17-rcx] Lost IBPB, IBRS_FW support for spectre_v2 mitigation.

On Wed, May 02, 2018 at 02:20:52PM +0200, Thomas Gleixner wrote: > Thanks for confirming. Still need to find a way which is less fragile, but > that's probably too much of churn for rc4 > > At least I know exactly what's happening, so I can write a better changelog. > > Thanks for testing!

Re: [RFC PATCH] Add /proc//numa_vamaps for numa node information

On 5/4/18 4:12 AM, Michal Hocko wrote: On Thu 03-05-18 15:39:49, prakash.sangappa wrote: On 05/03/2018 11:03 AM, Christopher Lameter wrote: On Tue, 1 May 2018, Prakash Sangappa wrote: For analysis purpose it is useful to have numa node information corresponding mapped address ranges of

KASAN: use-after-free Read in fuse_kill_sb_anon

Hello, syzbot found the following crash on: HEAD commit:150426981426 Merge tag 'linux-kselftest-4.17-rc4' of git:/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17f7b3e780 kernel config: https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27

KASAN: use-after-free Read in fuse_kill_sb_anon

Hello, syzbot found the following crash on: HEAD commit:150426981426 Merge tag 'linux-kselftest-4.17-rc4' of git:/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17f7b3e780 kernel config: https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27

Re: [v3] [media] Use common error handling code in 19 functions

> Adjust jump targets so that a bit of exception handling can be better > reused at the end of these functions. Why was this update suggestion rejected once more a moment ago? https://patchwork.linuxtv.org/patch/47827/

Re: [v3] [media] Use common error handling code in 19 functions

> Adjust jump targets so that a bit of exception handling can be better > reused at the end of these functions. Why was this update suggestion rejected once more a moment ago? https://patchwork.linuxtv.org/patch/47827/

Re: [PATCH v8 0/6] optimize memblock_next_valid_pfn and early_pfn_valid on arm and arm64

On Fri, May 4, 2018 at 4:45 AM, Jia He wrote: > Ping > > Sorry if I am a little bit verbose, but it can speedup the arm64 booting > time indeed. I'm wondering, ain't simple enabling of config DEFERRED_STRUCT_PAGE_INIT provide even better speed-up? If that is the case then it

Re: [PATCH] init/main.c: simplify repair_env_string

On Fri, 4 May 2018 11:40:35 -0400 Steven Rostedt wrote: > Cleaning out my INBOX, I stumbled across this old patch. > > On Fri, 15 Dec 2017 22:33:17 +0100 > Michal Suchanek wrote: > > > Quoting characters are now removed from the parameter so value > >

Re: [PATCH v8 0/6] optimize memblock_next_valid_pfn and early_pfn_valid on arm and arm64

On Fri, May 4, 2018 at 4:45 AM, Jia He wrote: > Ping > > Sorry if I am a little bit verbose, but it can speedup the arm64 booting > time indeed. I'm wondering, ain't simple enabling of config DEFERRED_STRUCT_PAGE_INIT provide even better speed-up? If that is the case then it seems like this

Re: [PATCH] init/main.c: simplify repair_env_string

On Fri, 4 May 2018 11:40:35 -0400 Steven Rostedt wrote: > Cleaning out my INBOX, I stumbled across this old patch. > > On Fri, 15 Dec 2017 22:33:17 +0100 > Michal Suchanek wrote: > > > Quoting characters are now removed from the parameter so value > > always follows directly after the NUL

Re: Introduce atomic_dec_and_lock_irqsave()

On 2018-05-04 17:54:46 [+0200], Peter Zijlstra wrote: > On Fri, May 04, 2018 at 05:45:28PM +0200, Sebastian Andrzej Siewior wrote: > > This series introduces atomic_dec_and_lock_irqsave() and converts a few > > users to use it. They were using local_irq_save() + > > atomic_dec_and_lock() before

Re: Introduce atomic_dec_and_lock_irqsave()

On 2018-05-04 17:54:46 [+0200], Peter Zijlstra wrote: > On Fri, May 04, 2018 at 05:45:28PM +0200, Sebastian Andrzej Siewior wrote: > > This series introduces atomic_dec_and_lock_irqsave() and converts a few > > users to use it. They were using local_irq_save() + > > atomic_dec_and_lock() before

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

On Sat, 5 May 2018 00:48:28 +0900 Masami Hiramatsu wrote: > So the syntax will be > > p[:EVENT] SYM[(CAST)|+OFFS] [FETCHARG] > > And here is an example; > > p:myevent vfs_read(void *file, char *buf, size_t count, void *pos) $arg1 $arg2 If we do this, why bother with

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

On Sat, 5 May 2018 00:48:28 +0900 Masami Hiramatsu wrote: > So the syntax will be > > p[:EVENT] SYM[(CAST)|+OFFS] [FETCHARG] > > And here is an example; > > p:myevent vfs_read(void *file, char *buf, size_t count, void *pos) $arg1 $arg2 If we do this, why bother with $arg1 $arg2? We could

[PATCH v5 01/14] thread_info: Add update_thread_flag() helpers

There are a number of bits of code sprinkled around the kernel to set a thread flag if a certain condition is true, and clear it otherwise. To help make those call sites terser and less cumbersome, this patch adds a new family of thread flag manipulators update*_thread_flag([...,] flag,

[PATCH v5 00/14] KVM: arm64: Optimise FPSIMD context switching

Note: Most of these patches are Arm-specific. People not Cc'd on the whole series can find it in the linux-arm-kernel archive [3]. This series aims to improve the way FPSIMD context is handled by KVM, building on the previous RFC v4 [1]. Patches 1-2 are picked from a separate RFC series [2]

[PATCH v5 01/14] thread_info: Add update_thread_flag() helpers

There are a number of bits of code sprinkled around the kernel to set a thread flag if a certain condition is true, and clear it otherwise. To help make those call sites terser and less cumbersome, this patch adds a new family of thread flag manipulators update*_thread_flag([...,] flag,

[PATCH v5 00/14] KVM: arm64: Optimise FPSIMD context switching

Note: Most of these patches are Arm-specific. People not Cc'd on the whole series can find it in the linux-arm-kernel archive [3]. This series aims to improve the way FPSIMD context is handled by KVM, building on the previous RFC v4 [1]. Patches 1-2 are picked from a separate RFC series [2]

Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

On Fri, May 4, 2018 at 8:35 AM, Linus Torvalds wrote: > On Fri, May 4, 2018 at 3:14 AM Matthew Wilcox wrote: > >> > In fact, the conversion I saw was buggy. You can *not* convert a > GFP_ATOMIC >> > user of kmalloc() to use kvmalloc. > >> Not

Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

On Fri, May 4, 2018 at 8:35 AM, Linus Torvalds wrote: > On Fri, May 4, 2018 at 3:14 AM Matthew Wilcox wrote: > >> > In fact, the conversion I saw was buggy. You can *not* convert a > GFP_ATOMIC >> > user of kmalloc() to use kvmalloc. > >> Not sure which conversion you're referring to; not one of

Re: [v2] mm: access to uninitialized struct page

: 4992.00 > clflush size : 64 > cache_alignment : 64 > address sizes : 39 bits physical, 48 bits virtual > power management: > >> >> Thank you, >> Pavel >> On Fri, May 4, 2018 at 4:27 AM Andrei Vagin <ava...@virtuozzo.com> wrote: >> >>>

Re: [v2] mm: access to uninitialized struct page

: 4992.00 > clflush size : 64 > cache_alignment : 64 > address sizes : 39 bits physical, 48 bits virtual > power management: > >> >> Thank you, >> Pavel >> On Fri, May 4, 2018 at 4:27 AM Andrei Vagin wrote: >> >>> Hello, >> >>>

Re: [PATCH 05/12] perf pmu: Fix pmu events parsing rule

On Thu, May 03, 2018 at 02:38:15PM +0300, Adrian Hunter wrote: SNIP > >>> index 7afeb80cc39e..d14464c42714 100644 > >>> --- a/tools/perf/util/parse-events.y > >>> +++ b/tools/perf/util/parse-events.y > >>> @@ -224,15 +224,15 @@ event_def: event_pmu | > >>> event_bpf_file > >>> > >>>

Re: [PATCH 05/12] perf pmu: Fix pmu events parsing rule

On Thu, May 03, 2018 at 02:38:15PM +0300, Adrian Hunter wrote: SNIP > >>> index 7afeb80cc39e..d14464c42714 100644 > >>> --- a/tools/perf/util/parse-events.y > >>> +++ b/tools/perf/util/parse-events.y > >>> @@ -224,15 +224,15 @@ event_def: event_pmu | > >>> event_bpf_file > >>> > >>>

Re: [v2] mm: access to uninitialized struct page

nk you, > Pavel > On Fri, May 4, 2018 at 4:27 AM Andrei Vagin <ava...@virtuozzo.com> wrote: > > > Hello, > > > We have a robot which runs criu tests on linux-next kernels. > > > All tests passed on 4.17.0-rc3-next-20180502. > > > But the 4.17.0

Re: [v2] mm: access to uninitialized struct page

nk you, > Pavel > On Fri, May 4, 2018 at 4:27 AM Andrei Vagin wrote: > > > Hello, > > > We have a robot which runs criu tests on linux-next kernels. > > > All tests passed on 4.17.0-rc3-next-20180502. > > > But the 4.17.0-rc3-next-20180504 kernel didn't bo

Re: [PATCH v2 1/2] usb: dwc2: alloc dma aligned buffer for isoc split in

Hi, On Wed, May 2, 2018 at 10:14 AM, wlf wrote: > It's a good way to allocate an extra 3 bytes in the original bounce buffer > for this unaligned > issue， it's similar to the tailroom of sk_buff. However, just as you said, > we'd better find > the special cases where we need

Re: [PATCH v2 1/2] usb: dwc2: alloc dma aligned buffer for isoc split in

Hi, On Wed, May 2, 2018 at 10:14 AM, wlf wrote: > It's a good way to allocate an extra 3 bytes in the original bounce buffer > for this unaligned > issue， it's similar to the tailroom of sk_buff. However, just as you said, > we'd better find > the special cases where we need an oversized bounce

Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

On Thursday, May 3, 2018 6:12 AM, Kiran Gunda wrote: If you really want someone to review your patch, please add more detailed explanations. 1. Please add 0th patch. 2. Please add what the difference is between V1 and V2 patches. If you cannot understand what I am saying, just ask another

Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

On Thursday, May 3, 2018 6:12 AM, Kiran Gunda wrote: If you really want someone to review your patch, please add more detailed explanations. 1. Please add 0th patch. 2. Please add what the difference is between V1 and V2 patches. If you cannot understand what I am saying, just ask another

Re: Introduce atomic_dec_and_lock_irqsave()

On Fri, May 04, 2018 at 05:45:28PM +0200, Sebastian Andrzej Siewior wrote: > This series introduces atomic_dec_and_lock_irqsave() and converts a few > users to use it. They were using local_irq_save() + > atomic_dec_and_lock() before that series. Should not all these users be converted to

Re: Introduce atomic_dec_and_lock_irqsave()

On Fri, May 04, 2018 at 05:45:28PM +0200, Sebastian Andrzej Siewior wrote: > This series introduces atomic_dec_and_lock_irqsave() and converts a few > users to use it. They were using local_irq_save() + > atomic_dec_and_lock() before that series. Should not all these users be converted to

[PATCH 1/2] ftrace: Have set_graph_* files have normal file modes

From: Chen LinX The set_graph_function and set_graph_notrace file mode should be 0644 instead of 0444 as they are writeable. Note, the mode appears to be ignored regardless, but they should at least look sane. Link:

[PATCH 1/2] ftrace: Have set_graph_* files have normal file modes

From: Chen LinX The set_graph_function and set_graph_notrace file mode should be 0644 instead of 0444 as they are writeable. Note, the mode appears to be ignored regardless, but they should at least look sane. Link:

[PATCH 0/2] [GIT PULL] tracing: Minor fixes

Linus, Some of the files in the tracing directory show file mode 0444 when they are writable by root. To fix the confusion, they should be 0644. Note, either case root can still write to them. Note, Zhengyuan asked why I never applied that patch (the first one is from 2014!). I simply forgot

[PATCH 0/2] [GIT PULL] tracing: Minor fixes

Linus, Some of the files in the tracing directory show file mode 0444 when they are writable by root. To fix the confusion, they should be 0644. Note, either case root can still write to them. Note, Zhengyuan asked why I never applied that patch (the first one is from 2014!). I simply forgot

[PATCH 2/2] tracing: Fix the file mode of stack tracer

From: Zhengyuan Liu It looks weird that the stack_trace_filter file can be written by root but shows that it does not have write permission by ll command. Link: http://lkml.kernel.org/r/1518054113-28096-1-git-send-email-liuzhengy...@kylinos.cn Signed-off-by: Zhengyuan

[PATCH 2/2] tracing: Fix the file mode of stack tracer

From: Zhengyuan Liu It looks weird that the stack_trace_filter file can be written by root but shows that it does not have write permission by ll command. Link: http://lkml.kernel.org/r/1518054113-28096-1-git-send-email-liuzhengy...@kylinos.cn Signed-off-by: Zhengyuan Liu Signed-off-by:

Re: [PATCH v4 00/14] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 04/05/18 08:27 AM, Christian König wrote: > Are you sure that this is more convenient? At least on first glance it > feels overly complicated. > > I mean what's the difference between the two approaches? > >     sum = pci_p2pdma_distance(target, [A, B, C, target]); > > and > >     sum

Re: [PATCH v4 00/14] Copy Offload in NVMe Fabrics with P2P PCI Memory

On 04/05/18 08:27 AM, Christian König wrote: > Are you sure that this is more convenient? At least on first glance it > feels overly complicated. > > I mean what's the difference between the two approaches? > >     sum = pci_p2pdma_distance(target, [A, B, C, target]); > > and > >     sum

[PATCH] mtd: spi-nor: add support for Microchip 25LC256

Added geometry description for Microchip 25LC256 memory. Signed-off-by: Radu Pirea --- drivers/mtd/devices/m25p80.c | 3 +++ drivers/mtd/spi-nor/spi-nor.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/mtd/devices/m25p80.c

[PATCH] mtd: spi-nor: add support for Microchip 25LC256

Added geometry description for Microchip 25LC256 memory. Signed-off-by: Radu Pirea --- drivers/mtd/devices/m25p80.c | 3 +++ drivers/mtd/spi-nor/spi-nor.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c index

Re: [PATCH] PCI: Check whether bridges allow access to extended config space

Le 04/05/2018 00:31, Bjorn Helgaas a écrit : > [+cc LKML] > > On Thu, May 03, 2018 at 12:40:27PM +, Gilles Buloz wrote: >> Subject:[PATCH] For exception at PCI probe due to bridge reporting UR >> >> Even if a device supports extended config access, no such access must be >> done to this

Re: [PATCH] PCI: Check whether bridges allow access to extended config space

Le 04/05/2018 00:31, Bjorn Helgaas a écrit : > [+cc LKML] > > On Thu, May 03, 2018 at 12:40:27PM +, Gilles Buloz wrote: >> Subject:[PATCH] For exception at PCI probe due to bridge reporting UR >> >> Even if a device supports extended config access, no such access must be >> done to this

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

Oleg Nesterov writes: > On 05/04, Eric W. Biederman wrote: >> >> Oleg Nesterov writes: >> >> > OK, what about exec() ? mm_init_memcg() initializes bprm->mm->memcg early >> > in >> > bprm_mm_init(). What if the execing task migrates before exec_mmap() ? >> >>

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

Oleg Nesterov writes: > On 05/04, Eric W. Biederman wrote: >> >> Oleg Nesterov writes: >> >> > OK, what about exec() ? mm_init_memcg() initializes bprm->mm->memcg early >> > in >> > bprm_mm_init(). What if the execing task migrates before exec_mmap() ? >> >> We need the the cgroup when the mm

[PATCH 3/5] kernel/user: Use irqsave variant of atomic_dec_and_lock()

From: Anna-Maria Gleixner The irqsave variant of atomic_dec_and_lock handles irqsave/restore when taking/releasing the spin lock. With this variant the call of local_irq_save/restore is no longer required. Signed-off-by: Anna-Maria Gleixner

[PATCH 3/5] kernel/user: Use irqsave variant of atomic_dec_and_lock()

From: Anna-Maria Gleixner The irqsave variant of atomic_dec_and_lock handles irqsave/restore when taking/releasing the spin lock. With this variant the call of local_irq_save/restore is no longer required. Signed-off-by: Anna-Maria Gleixner Signed-off-by: Sebastian Andrzej Siewior ---

[PATCH 2/5] mm/backing-dev: Use irqsave variant of atomic_dec_and_lock()

From: Anna-Maria Gleixner The irqsave variant of atomic_dec_and_lock handles irqsave/restore when taking/releasing the spin lock. With this variant the call of local_irq_save/restore is no longer required. Signed-off-by: Anna-Maria Gleixner

[PATCH 2/5] mm/backing-dev: Use irqsave variant of atomic_dec_and_lock()

From: Anna-Maria Gleixner The irqsave variant of atomic_dec_and_lock handles irqsave/restore when taking/releasing the spin lock. With this variant the call of local_irq_save/restore is no longer required. Signed-off-by: Anna-Maria Gleixner Signed-off-by: Sebastian Andrzej Siewior ---

[PATCH 5/5] drivers/md/raid5: Do not disable irq on release_inactive_stripe_list() call

From: Anna-Maria Gleixner There is no need to invoke release_inactive_stripe_list() with interrupts disabled. All call sites, except raid5_release_stripe(), unlock ->device_lock and enable interrupts before invoking the function. Make it consistent. Signed-off-by:

[PATCH 5/5] drivers/md/raid5: Do not disable irq on release_inactive_stripe_list() call

From: Anna-Maria Gleixner There is no need to invoke release_inactive_stripe_list() with interrupts disabled. All call sites, except raid5_release_stripe(), unlock ->device_lock and enable interrupts before invoking the function. Make it consistent. Signed-off-by: Anna-Maria Gleixner

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

On Thu, 3 May 2018 18:11:37 -0400 Steven Rostedt wrote: > On Wed, 25 Apr 2018 21:16:06 +0900 > Masami Hiramatsu wrote: > > > Hi, > > > > This is the 7th version of the fetch-arg improvement series. > > This includes variable changes on fetcharg

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

On Thu, 3 May 2018 18:11:37 -0400 Steven Rostedt wrote: > On Wed, 25 Apr 2018 21:16:06 +0900 > Masami Hiramatsu wrote: > > > Hi, > > > > This is the 7th version of the fetch-arg improvement series. > > This includes variable changes on fetcharg framework like, > > > > - Add fetcharg

<    3   4   5   6   7   8   9   10   11   12   >