Re: [PATCH 10/10] softirq: Remove __ARCH_SET_SOFTIRQ_PENDING

On Thu, 29 Mar 2018 20:08:36 +0200 Peter Zijlstra wrote: > On Thu, Mar 29, 2018 at 04:53:43PM +0200, Martin Schwidefsky wrote: > > The lowcore optimization for softirq_pending field is not really needed, > > just nice to have. But if there is a strong reason to make a

Re: [PATCH 10/10] softirq: Remove __ARCH_SET_SOFTIRQ_PENDING

On Thu, 29 Mar 2018 20:08:36 +0200 Peter Zijlstra wrote: > On Thu, Mar 29, 2018 at 04:53:43PM +0200, Martin Schwidefsky wrote: > > The lowcore optimization for softirq_pending field is not really needed, > > just nice to have. But if there is a strong reason to make a common > > definition for

Re: [GIT PULL] Andes(nds32) Port for Linux 4.17

2018-04-03 0:04 GMT+08:00 Linus Torvalds : > On Sun, Apr 1, 2018 at 11:01 PM, Greentime Hu wrote: >> >> This tag contains the core nds32 Linux port(including interrupt controller >> driver and timer driver), which has been through 7 rounds of

Re: [GIT PULL] Andes(nds32) Port for Linux 4.17

2018-04-03 0:04 GMT+08:00 Linus Torvalds : > On Sun, Apr 1, 2018 at 11:01 PM, Greentime Hu wrote: >> >> This tag contains the core nds32 Linux port(including interrupt controller >> driver and timer driver), which has been through 7 rounds of review on >> mailing >> list. > > Can I get an

Re: [PATCH v8 42/42] ARM: dts: da850: Add clocks

On Monday 02 April 2018 09:45 PM, David Lechner wrote: > On 04/02/2018 06:12 AM, Sekhar Nori wrote: >> On Friday 16 March 2018 10:50 PM, David Lechner wrote: >>> On 03/15/2018 09:52 PM, David Lechner wrote: This adds clock provider nodes for da850 and wires them up to all of the

Re: [PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel

On 4/2/2018 12:12 PM, Jiri Pirko wrote: Fri, Mar 30, 2018 at 05:11:29PM CEST, and...@lunn.ch wrote: Please see: http://patchwork.ozlabs.org/project/netdev/list/?series=36524 I bevieve that the solution in the patchset could be used for your usecase too. Hi Jiri

Re: [PATCH v8 42/42] ARM: dts: da850: Add clocks

On Monday 02 April 2018 09:45 PM, David Lechner wrote: > On 04/02/2018 06:12 AM, Sekhar Nori wrote: >> On Friday 16 March 2018 10:50 PM, David Lechner wrote: >>> On 03/15/2018 09:52 PM, David Lechner wrote: This adds clock provider nodes for da850 and wires them up to all of the

Re: [PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel

On 4/2/2018 12:12 PM, Jiri Pirko wrote: Fri, Mar 30, 2018 at 05:11:29PM CEST, and...@lunn.ch wrote: Please see: http://patchwork.ozlabs.org/project/netdev/list/?series=36524 I bevieve that the solution in the patchset could be used for your usecase too. Hi Jiri

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

Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/rxrpc/call_object.c: In function 'rxrpc_rcu_destroy_call': net/rxrpc/call_object.c:661:3: error: implicit declaration of function 'wake_up_atomic_t'; did you mean 'wake_up_bit'?

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

Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: net/rxrpc/call_object.c: In function 'rxrpc_rcu_destroy_call': net/rxrpc/call_object.c:661:3: error: implicit declaration of function 'wake_up_atomic_t'; did you mean 'wake_up_bit'?

Re: [PATCH v5 06/12] PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs properly

On Tuesday 03 April 2018 01:07 AM, Niklas Cassel wrote: > On Thu, Mar 29, 2018 at 03:17:11PM +0530, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Wednesday 28 March 2018 05:20 PM, Niklas Cassel wrote: >>> Since a 64-bit BAR consists of a BAR pair, we need to write to both >>> BARs in the BAR

Re: [PATCH v5 06/12] PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs properly

On Tuesday 03 April 2018 01:07 AM, Niklas Cassel wrote: > On Thu, Mar 29, 2018 at 03:17:11PM +0530, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Wednesday 28 March 2018 05:20 PM, Niklas Cassel wrote: >>> Since a 64-bit BAR consists of a BAR pair, we need to write to both >>> BARs in the BAR

[PATCH] drm/sti: Depend on OF rather than selecting it

Commit cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure") reworked some code inside of this driver and made it select CONFIG_OF. This results in the entire OF layer being enabled when building an allmodconfig on ia64. OF on ia64 is completely unsupported so this isn't a great

[PATCH] drm/sti: Depend on OF rather than selecting it

Commit cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure") reworked some code inside of this driver and made it select CONFIG_OF. This results in the entire OF layer being enabled when building an allmodconfig on ia64. OF on ia64 is completely unsupported so this isn't a great

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 04/03, Chao Yu wrote: > On 2018/3/31 0:30, Jaegeuk Kim wrote: > > Change log from v1: > > - add more description > > > > This fixes xfstests/generic/392. > > > > The failure was caused by different times between 1) one marked in the last > > fsync(2) call and 2) the other given by

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 04/03, Chao Yu wrote: > On 2018/3/31 0:30, Jaegeuk Kim wrote: > > Change log from v1: > > - add more description > > > > This fixes xfstests/generic/392. > > > > The failure was caused by different times between 1) one marked in the last > > fsync(2) call and 2) the other given by

Re: [f2fs-dev] [PATCH v3] f2fs: remain written times to update inode during fsync

Change log from v2: - update do_read_inode Change log from v1: - add more description This fixes xfstests/generic/392. The failure was caused by different times between 1) one marked in the last fsync(2) call and 2) the other given by roll-forward recovery after power-cut. The reason was that

Re: [f2fs-dev] [PATCH v3] f2fs: remain written times to update inode during fsync

Change log from v2: - update do_read_inode Change log from v1: - add more description This fixes xfstests/generic/392. The failure was caused by different times between 1) one marked in the last fsync(2) call and 2) the other given by roll-forward recovery after power-cut. The reason was that

Re: [PATCH v3 0/2] ASoC: topology: Improve parsing hw_configs

On 04/03/18 02:57, Pierre-Louis Bossart wrote: > > > On 04/02/2018 04:17 PM, Kirill Marinushkin wrote: >> Hello Pierre-Louis, >> >> I explicitly clarified with Takashi: to have this patch series merged, we >> need a >> tag "Reviewed-by" from you. > I am fine with the changes, but maybe while we

Re: [PATCH v3 0/2] ASoC: topology: Improve parsing hw_configs

On 04/03/18 02:57, Pierre-Louis Bossart wrote: > > > On 04/02/2018 04:17 PM, Kirill Marinushkin wrote: >> Hello Pierre-Louis, >> >> I explicitly clarified with Takashi: to have this patch series merged, we >> need a >> tag "Reviewed-by" from you. > I am fine with the changes, but maybe while we

Re: [PATCH][RESEND] ASoC: Intel: atom: fix ACPI/PCI Kconfig

On Mon, Apr 02, 2018 at 12:06:14PM -0500, Pierre-Louis Bossart wrote: > The split between ACPI and PCI platforms generated issues with randconfig: > > with SND_SST_ATOM_HIFI2_PLATFORM_PCI=y and > SND_SST_ATOM_HIFI2_PLATFORM=m, we get this module link failure: > > ERROR: "sst_context_init" >

[GIT PULL] xfs: new features for 4.17

Hi Linus, Here's the first round of fixes for XFS for 4.17. The biggest new features this time around are the addition of lazytime support, further enhancement of the on-disk inode metadata verifiers, and a patch to smooth over some of the AGFL padding problems that have intermittently plagued

Re: [PATCH][RESEND] ASoC: Intel: atom: fix ACPI/PCI Kconfig

On Mon, Apr 02, 2018 at 12:06:14PM -0500, Pierre-Louis Bossart wrote: > The split between ACPI and PCI platforms generated issues with randconfig: > > with SND_SST_ATOM_HIFI2_PLATFORM_PCI=y and > SND_SST_ATOM_HIFI2_PLATFORM=m, we get this module link failure: > > ERROR: "sst_context_init" >

[GIT PULL] xfs: new features for 4.17

Hi Linus, Here's the first round of fixes for XFS for 4.17. The biggest new features this time around are the addition of lazytime support, further enhancement of the on-disk inode metadata verifiers, and a patch to smooth over some of the AGFL padding problems that have intermittently plagued

[PATCH v1] mm: consider non-anonymous thp as unmovable page

My testing for the latest kernel supporting thp migration found out an infinite loop in offlining the memory block that is filled with shmem thps. We can get out of the loop with a signal, but kernel should return with failure in this case. What happens in the loop is that scan_movable_pages()

[PATCH v1] mm: consider non-anonymous thp as unmovable page

My testing for the latest kernel supporting thp migration found out an infinite loop in offlining the memory block that is filled with shmem thps. We can get out of the loop with a signal, but kernel should return with failure in this case. What happens in the loop is that scan_movable_pages()

linux-next: manual merge of the selinux tree with the security tree

Hi Paul, Today's linux-next merge of the selinux tree got a conflict in: include/linux/lsm_hooks.h between commit: 22402b0b736d ("security: convert security hooks to use hlist") from the security tree and commit: 72e89f50084c ("security: Add support for SCTP security hooks") from the

linux-next: manual merge of the selinux tree with the security tree

Hi Paul, Today's linux-next merge of the selinux tree got a conflict in: include/linux/lsm_hooks.h between commit: 22402b0b736d ("security: convert security hooks to use hlist") from the security tree and commit: 72e89f50084c ("security: Add support for SCTP security hooks") from the

Re: WARNING: bad unlock balance in xfs_iunlock

On Mon, Apr 02, 2018 at 07:01:02PM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +) > Merge branch 'ras-core-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > syzbot

Re: WARNING: bad unlock balance in xfs_iunlock

On Mon, Apr 02, 2018 at 07:01:02PM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +) > Merge branch 'ras-core-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > syzbot

Re: [PATCH 4/5] powerpc/pm: add sleep and deep sleep on QorIQ SoCs

Hi Ran, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on powerpc/next] [also build test WARNING on v4.16 next-20180329] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 4/5] powerpc/pm: add sleep and deep sleep on QorIQ SoCs

Hi Ran, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on powerpc/next] [also build test WARNING on v4.16 next-20180329] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [GIT PULL] remove in-kernel calls to syscalls

On Mon, Apr 2, 2018 at 12:04 PM, Dominik Brodowski wrote: > > This patchset removes all in-kernel calls to syscall functions in the > kernel with the exception of arch/. Ok, this finished off my arch updates for today, I'll probably move on to driver pulls tomorrow.

Re: [GIT PULL] remove in-kernel calls to syscalls

On Mon, Apr 2, 2018 at 12:04 PM, Dominik Brodowski wrote: > > This patchset removes all in-kernel calls to syscall functions in the > kernel with the exception of arch/. Ok, this finished off my arch updates for today, I'll probably move on to driver pulls tomorrow. Anyway, it's in my tree,

Re: [PATCH v4 13/14] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu

On 03-04-18, 08:11, Sricharan R wrote: > Right, i was adding a similar one for krait cores [1]. There is code common > in the > init sequence across both (little). Do you suggest to make them common ? It may make sense as we are talking about one SoC family here :) -- viresh

Re: [PATCH v4 13/14] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu

On 03-04-18, 08:11, Sricharan R wrote: > Right, i was adding a similar one for krait cores [1]. There is code common > in the > init sequence across both (little). Do you suggest to make them common ? It may make sense as we are talking about one SoC family here :) -- viresh

Re: [PATCH v2 2/2] cpufreq: ti-cpufreq: Use devres managed API in probe()

On 02-04-18, 11:49, Suman Anna wrote: > The ti_cpufreq_probe() function uses regular kzalloc to allocate > the ti_cpufreq_data structure and kfree for freeing this memory > on failures. Simplify this code by using the devres managed > API. > > Cc: Zumeng Chen >

Re: [PATCH v2 2/2] cpufreq: ti-cpufreq: Use devres managed API in probe()

On 02-04-18, 11:49, Suman Anna wrote: > The ti_cpufreq_probe() function uses regular kzalloc to allocate > the ti_cpufreq_data structure and kfree for freeing this memory > on failures. Simplify this code by using the devres managed > API. > > Cc: Zumeng Chen > Signed-off-by: Suman Anna > --- >

Re: [PATCH v2 1/2] cpufreq: ti-cpufreq: Fix an incorrect error return value

On 02-04-18, 11:49, Suman Anna wrote: > Commit 05829d9431df ("cpufreq: ti-cpufreq: kfree opp_data when > failure") has fixed a memory leak in the failure path, however > the patch returned a positive value on get_cpu_device() failure > instead of the previous negative value. Fix this incorrect

Re: [PATCH v2 1/2] cpufreq: ti-cpufreq: Fix an incorrect error return value

On 02-04-18, 11:49, Suman Anna wrote: > Commit 05829d9431df ("cpufreq: ti-cpufreq: kfree opp_data when > failure") has fixed a memory leak in the failure path, however > the patch returned a positive value on get_cpu_device() failure > instead of the previous negative value. Fix this incorrect

Re: WARNING in refcount_dec

No. Only the first crash (WARNING in refcount_dec) is reproduced by the attached reproducer. The second crash (kernel bug at af_packet.c:3107) is reproduced by another reproducer. We reported it here. http://lkml.iu.edu/hypermail/linux/kernel/1803.3/05324.html On Sun, Apr 1, 2018 at 4:38 PM,

Re: WARNING in refcount_dec

No. Only the first crash (WARNING in refcount_dec) is reproduced by the attached reproducer. The second crash (kernel bug at af_packet.c:3107) is reproduced by another reproducer. We reported it here. http://lkml.iu.edu/hypermail/linux/kernel/1803.3/05324.html On Sun, Apr 1, 2018 at 4:38 PM,

Re: [GIT PULL] arch: remove obsolete architecture ports

On Mon, Apr 2, 2018 at 12:17 AM, Arnd Bergmann wrote: > > The series is rather long and conflicts in trivial ways with lots > of subsystem trees. You probably want to pull it either really > early in the merge window or really late. Ok, I've been pulling arch updates, so it went

Re: [GIT PULL] arch: remove obsolete architecture ports

On Mon, Apr 2, 2018 at 12:17 AM, Arnd Bergmann wrote: > > The series is rather long and conflicts in trivial ways with lots > of subsystem trees. You probably want to pull it either really > early in the merge window or really late. Ok, I've been pulling arch updates, so it went in now. Side

Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

On Tue, Apr 03, 2018 at 01:41:26PM +1000, NeilBrown wrote: > > Do we really need a rhashtable_walk_peek() interface? > I imagine that a seqfile ->start function can do: > > if (*ppos == 0 && last_pos != 0) { > rhashtable_walk_exit(); > rhashtable_walk_enter(, ); > last_pos

Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

On Tue, Apr 03, 2018 at 01:41:26PM +1000, NeilBrown wrote: > > Do we really need a rhashtable_walk_peek() interface? > I imagine that a seqfile ->start function can do: > > if (*ppos == 0 && last_pos != 0) { > rhashtable_walk_exit(); > rhashtable_walk_enter(, ); > last_pos

Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

On Fri, Mar 30 2018, Herbert Xu wrote: > On Thu, Mar 29, 2018 at 06:52:34PM +0200, Andreas Gruenbacher wrote: >> >> Should rhashtable_walk_peek be kept around even if there are no more >> users? I have my doubts. > > Absolutely. All netlink dumps using rhashtable_walk_next are buggy > and need

Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

On Fri, Mar 30 2018, Herbert Xu wrote: > On Thu, Mar 29, 2018 at 06:52:34PM +0200, Andreas Gruenbacher wrote: >> >> Should rhashtable_walk_peek be kept around even if there are no more >> users? I have my doubts. > > Absolutely. All netlink dumps using rhashtable_walk_next are buggy > and need

[RESEND PATCH] x86/boot/KASLR: Extend movable_node option for KASLR

The movable_node option is a boot-time switch to make sure the physical NUMA nodes can be hot-added/removed when ACPI table can't be parsed to provide the memory hotplug information. As we all know, there is always one node, called "home node", which can't be movabled and the kernel image resides

[RESEND PATCH] x86/boot/KASLR: Extend movable_node option for KASLR

The movable_node option is a boot-time switch to make sure the physical NUMA nodes can be hot-added/removed when ACPI table can't be parsed to provide the memory hotplug information. As we all know, there is always one node, called "home node", which can't be movabled and the kernel image resides

Re: [PATCH] list_debug: Print unmangled addresses

On Sun, Apr 01, 2018 at 03:32:37PM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > The entire point of printing the pointers in list_debug is to see if > there's any useful information in them (eg poison values, ASCII, etc); > obscuring them to see if they compare

Re: [PATCH] list_debug: Print unmangled addresses

On Sun, Apr 01, 2018 at 03:32:37PM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > The entire point of printing the pointers in list_debug is to see if > there's any useful information in them (eg poison values, ASCII, etc); > obscuring them to see if they compare equal makes them much

Re: [PATCH AUTOSEL for 4.15 058/124] ipv6: Set nexthop flags during route creation

On Mon, Mar 19, 2018 at 08:04:34PM +0200, Ido Schimmel wrote: >On Mon, Mar 19, 2018 at 03:48:00PM +, Sasha Levin wrote: >> From: Ido Schimmel >> >> [ Upstream commit 5609b80a37f69f796548339e675256188b29c17d ] >> >> It is valid to install routes with a nexthop device that

Re: [PATCH AUTOSEL for 4.15 058/124] ipv6: Set nexthop flags during route creation

On Mon, Mar 19, 2018 at 08:04:34PM +0200, Ido Schimmel wrote: >On Mon, Mar 19, 2018 at 03:48:00PM +, Sasha Levin wrote: >> From: Ido Schimmel >> >> [ Upstream commit 5609b80a37f69f796548339e675256188b29c17d ] >> >> It is valid to install routes with a nexthop device that does not have a >>

Re: [PATCH AUTOSEL for 4.15 070/124] netfilter: core: only allow one nat hook per hook point

On Mon, Mar 19, 2018 at 04:56:49PM +0100, Florian Westphal wrote: >Sasha Levin wrote: >> From: Florian Westphal >> >> [ Upstream commit f92b40a8b2645af38bd6814651c59c1e690db53d ] > >This patch is broken and a fix is not in any tree yet. Removed for

Re: [PATCH AUTOSEL for 4.15 070/124] netfilter: core: only allow one nat hook per hook point

On Mon, Mar 19, 2018 at 04:56:49PM +0100, Florian Westphal wrote: >Sasha Levin wrote: >> From: Florian Westphal >> >> [ Upstream commit f92b40a8b2645af38bd6814651c59c1e690db53d ] > >This patch is broken and a fix is not in any tree yet. Removed for now, thanks!

Re: [PATCH AUTOSEL for 4.15 104/124] clk: fix reentrancy of clk_enable() on UP systems

On Mon, Mar 19, 2018 at 10:55:16AM -0500, David Lechner wrote: >On 03/19/2018 10:48 AM, Sasha Levin wrote: >>From: David Lechner >> >>[ Upstream commit a12aa8a68dfef5de181f2e555aa950a0ab05411f ] >> >>Reentrant calls to clk_enable() are not working on UP systems. This is

Re: [PATCH AUTOSEL for 4.15 104/124] clk: fix reentrancy of clk_enable() on UP systems

On Mon, Mar 19, 2018 at 10:55:16AM -0500, David Lechner wrote: >On 03/19/2018 10:48 AM, Sasha Levin wrote: >>From: David Lechner >> >>[ Upstream commit a12aa8a68dfef5de181f2e555aa950a0ab05411f ] >> >>Reentrant calls to clk_enable() are not working on UP systems. This is >>caused by the fact

Re: [PATCH AUTOSEL for 4.15 050/124] ACPICA: Recognize the Windows 10 version 1607 and 1703 OSI strings

On Mon, Mar 26, 2018 at 09:12:03AM +, mario.limoncie...@dell.com wrote: >> -Original Message- >> From: Sasha Levin [mailto:alexander.le...@microsoft.com] >> Sent: Monday, March 19, 2018 10:48 AM >> To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org >> Cc: Limonciello, Mario

Re: [PATCH AUTOSEL for 4.15 050/124] ACPICA: Recognize the Windows 10 version 1607 and 1703 OSI strings

On Mon, Mar 26, 2018 at 09:12:03AM +, mario.limoncie...@dell.com wrote: >> -Original Message- >> From: Sasha Levin [mailto:alexander.le...@microsoft.com] >> Sent: Monday, March 19, 2018 10:48 AM >> To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org >> Cc: Limonciello, Mario ; Bob

Re: [PATCH 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

On Mon, 02 Apr 2018 05:31:22 PDT (-0700), alan...@andestech.com wrote: This implements the baseline PMU for RISC-V platforms. To ease future PMU portings, a guide is also written, containing perf concepts, arch porting practices and some hints. Changes in v2: - Fix the bug reported by Alex,

Re: [PATCH 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

On Mon, 02 Apr 2018 05:31:22 PDT (-0700), alan...@andestech.com wrote: This implements the baseline PMU for RISC-V platforms. To ease future PMU portings, a guide is also written, containing perf concepts, arch porting practices and some hints. Changes in v2: - Fix the bug reported by Alex,

linux-next: manual merge of the net-next tree with the pci tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/ethernet/mellanox/mlx5/core/en_main.c between commit: 2907938d2375 ("net/mlx5e: Use pcie_bandwidth_available() to compute bandwidth") from the pci tree and commit: 0608d4dbaf4e ("net/mlx5e: Unify slow

linux-next: manual merge of the net-next tree with the pci tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/ethernet/mellanox/mlx5/core/en_main.c between commit: 2907938d2375 ("net/mlx5e: Use pcie_bandwidth_available() to compute bandwidth") from the pci tree and commit: 0608d4dbaf4e ("net/mlx5e: Unify slow

Re: KASAN: use-after-free Read in alloc_pid

On Mon, Apr 02, 2018 at 06:00:57PM -0500, Eric W. Biederman wrote: > syzbot writes: > > > Hello, > > > > syzbot hit the following crash on upstream commit > > 9dd2326890d89a5179967c947dab2bab34d7ddee (Fri Mar 30 17:29:47 2018 +) > >

Re: KASAN: use-after-free Read in alloc_pid

On Mon, Apr 02, 2018 at 06:00:57PM -0500, Eric W. Biederman wrote: > syzbot writes: > > > Hello, > > > > syzbot hit the following crash on upstream commit > > 9dd2326890d89a5179967c947dab2bab34d7ddee (Fri Mar 30 17:29:47 2018 +) > > Merge tag 'ceph-for-4.16-rc8' of

Re: [PATCH v5 1/5] mm: page_alloc: remain memblock_next_valid_pfn() on arm and arm64

On 4/2/2018 3:53 PM, Ard Biesheuvel Wrote: On 2 April 2018 at 09:49, Jia He wrote: On 4/2/2018 2:55 PM, Ard Biesheuvel Wrote: On 2 April 2018 at 04:30, Jia He wrote: Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where

Re: [PATCH v5 1/5] mm: page_alloc: remain memblock_next_valid_pfn() on arm and arm64

On 4/2/2018 3:53 PM, Ard Biesheuvel Wrote: On 2 April 2018 at 09:49, Jia He wrote: On 4/2/2018 2:55 PM, Ard Biesheuvel Wrote: On 2 April 2018 at 04:30, Jia He wrote: Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where possible") optimized the loop in

KASAN: use-after-free Read in uprobe_perf_close

Hello, syzbot hit the following crash on upstream commit 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +) Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip syzbot dashboard link:

KASAN: use-after-free Read in uprobe_perf_close

Hello, syzbot hit the following crash on upstream commit 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +) Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip syzbot dashboard link:

KASAN: use-after-free Read in cma_cancel_operation

Hello, syzbot hit the following crash on upstream commit 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +) Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip syzbot dashboard link:

KASAN: use-after-free Read in cma_cancel_operation

Hello, syzbot hit the following crash on upstream commit 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +) Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip syzbot dashboard link:

Re: [GIT PULL] arch: remove obsolete architecture ports

On Mon, 02 Apr 2018 00:17:30 PDT (-0700), Arnd Bergmann wrote: - openrisc, risc-v and nds32 are still in the process of finishing their support or getting it added to mainline gcc in the first place. They all have patched gcc-7.3 ports that work to some degree, but complete upstream

Re: [GIT PULL] arch: remove obsolete architecture ports

On Mon, 02 Apr 2018 00:17:30 PDT (-0700), Arnd Bergmann wrote: - openrisc, risc-v and nds32 are still in the process of finishing their support or getting it added to mainline gcc in the first place. They all have patched gcc-7.3 ports that work to some degree, but complete upstream

Re: [PATCH] f2fs: make assignment of t->dentry_bitmap more readable

On 2018/4/2 20:22, Yunlong Song wrote: > In make_dentry_ptr_block, it is confused with "&" for t->dentry_bitmap > but without "&" for t->dentry, so delete "&" to make code more readable. > > Signed-off-by: Yunlong Song Reviewed-by: Chao Yu Thanks,

Re: [PATCH] f2fs: make assignment of t->dentry_bitmap more readable

On 2018/4/2 20:22, Yunlong Song wrote: > In make_dentry_ptr_block, it is confused with "&" for t->dentry_bitmap > but without "&" for t->dentry, so delete "&" to make code more readable. > > Signed-off-by: Yunlong Song Reviewed-by: Chao Yu Thanks,

Re: [PATCH v4 13/14] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu

Hi Viresh, On 4/2/2018 8:37 PM, Sricharan R wrote: > Hi Viresh, > > On 4/2/2018 3:00 PM, Viresh Kumar wrote: >> +Sricharan, >> >> On 30-03-18, 00:26, Ilia Lin wrote: >>> In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996 >>> that have KRYO processors, the CPU ferequencies

Re: [PATCH v4 13/14] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu

Hi Viresh, On 4/2/2018 8:37 PM, Sricharan R wrote: > Hi Viresh, > > On 4/2/2018 3:00 PM, Viresh Kumar wrote: >> +Sricharan, >> >> On 30-03-18, 00:26, Ilia Lin wrote: >>> In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996 >>> that have KRYO processors, the CPU ferequencies

Re: [PATCH] f2fs: truncate preallocated blocks in error case

On 2018/3/31 9:57, Jaegeuk Kim wrote: > If write is failed, we must deallocate the blocks that we couldn't write. > > Cc: sta...@vger.kernel.org > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,

Re: [PATCH] f2fs: truncate preallocated blocks in error case

On 2018/3/31 9:57, Jaegeuk Kim wrote: > If write is failed, we must deallocate the blocks that we couldn't write. > > Cc: sta...@vger.kernel.org > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,

[PATCH] usb: serial: option: add HP LT4220 support

This patch adds support for HP LT4220. Signed-off-by: Edward Chang --- drivers/usb/serial/option.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index 2d8d915..a8988d5 100644 ---

[PATCH] usb: serial: option: add HP LT4220 support

This patch adds support for HP LT4220. Signed-off-by: Edward Chang --- drivers/usb/serial/option.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index 2d8d915..a8988d5 100644 --- a/drivers/usb/serial/option.c +++

Re: [PATCH 0/2] rhashtable_walk fixes

From: NeilBrown Date: Tue, 03 Apr 2018 12:23:40 +1000 > I'm sorry if I've caused some confusion, but I didn't think that I was > submitting patches to you and know nothing about your two trees. > I was submitting patches to Thomas and Herbert, the registered > maintainers of

Re: [PATCH 0/2] rhashtable_walk fixes

From: NeilBrown Date: Tue, 03 Apr 2018 12:23:40 +1000 > I'm sorry if I've caused some confusion, but I didn't think that I was > submitting patches to you and know nothing about your two trees. > I was submitting patches to Thomas and Herbert, the registered > maintainers of rhashtable. I

linux-next: manual merge of the pci tree with Linus' tree

Hi Bjorn, Today's linux-next merge of the pci tree got a conflict in: drivers/pci/quirks.c between commit: 7dcf688d4c78 ("PCI/cxgb4: Extend T3 PCI quirk to T4+ devices") from Linus' tree and commit: 996058573b22 ("PCI/VPD: Move VPD quirks to vpd.c") from the pci tree. I fixed it up

linux-next: manual merge of the pci tree with Linus' tree

Hi Bjorn, Today's linux-next merge of the pci tree got a conflict in: drivers/pci/quirks.c between commit: 7dcf688d4c78 ("PCI/cxgb4: Extend T3 PCI quirk to T4+ devices") from Linus' tree and commit: 996058573b22 ("PCI/VPD: Move VPD quirks to vpd.c") from the pci tree. I fixed it up

Re: [GIT PULL] f2fs update for 4.16-rc1

Hi all, Ping? On Wed, 14 Mar 2018 10:17:04 +1100 Stephen Rothwell wrote: > > On Thu, 1 Feb 2018 09:25:51 +1100 Stephen Rothwell > wrote: > > > > On Tue, 30 Jan 2018 16:25:35 -0800 Jaegeuk Kim wrote: > > > > > > On 01/31,

Re: [GIT PULL] f2fs update for 4.16-rc1

Hi all, Ping? On Wed, 14 Mar 2018 10:17:04 +1100 Stephen Rothwell wrote: > > On Thu, 1 Feb 2018 09:25:51 +1100 Stephen Rothwell > wrote: > > > > On Tue, 30 Jan 2018 16:25:35 -0800 Jaegeuk Kim wrote: > > > > > > On 01/31, Stephen Rothwell wrote: > > > > > > > > On Tue, 30 Jan 2018

Re: [PATCH v5 3/3] RDMA/qedr: eliminate duplicate barriers on weakly-ordered archs #2

On 3/22/2018 12:26 PM, Sinan Kaya wrote: > @@ -860,7 +860,7 @@ static void doorbell_cq(struct qedr_cq *cq, u32 cons, u8 > flags) > wmb(); > cq->db.data.agg_flags = flags; > cq->db.data.value = cpu_to_le32(cons); > - writeq(cq->db.raw, cq->db_addr); > +

Re: [PATCH v5 3/3] RDMA/qedr: eliminate duplicate barriers on weakly-ordered archs #2

On 3/22/2018 12:26 PM, Sinan Kaya wrote: > @@ -860,7 +860,7 @@ static void doorbell_cq(struct qedr_cq *cq, u32 cons, u8 > flags) > wmb(); > cq->db.data.agg_flags = flags; > cq->db.data.value = cpu_to_le32(cons); > - writeq(cq->db.raw, cq->db_addr); > +

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 2018/3/31 0:30, Jaegeuk Kim wrote: > Change log from v1: > - add more description > > This fixes xfstests/generic/392. > > The failure was caused by different times between 1) one marked in the last > fsync(2) call and 2) the other given by roll-forward recovery after power-cut. > The reason

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 2018/3/31 0:30, Jaegeuk Kim wrote: > Change log from v1: > - add more description > > This fixes xfstests/generic/392. > > The failure was caused by different times between 1) one marked in the last > fsync(2) call and 2) the other given by roll-forward recovery after power-cut. > The reason

Re: linux-next: build failure after merge of the vfs tree

Hi Al, On Mon, 19 Mar 2018 17:06:27 +1100 Stephen Rothwell wrote: > > After merging the vfs tree, today's linux-next build (x86_64 allnoconfig) > failed like this: > > fs/super.c: In function 'do_thaw_all_callback': > fs/super.c:942:3: error: implicit declaration of

Re: linux-next: build failure after merge of the vfs tree

Hi Al, On Mon, 19 Mar 2018 17:06:27 +1100 Stephen Rothwell wrote: > > After merging the vfs tree, today's linux-next build (x86_64 allnoconfig) > failed like this: > > fs/super.c: In function 'do_thaw_all_callback': > fs/super.c:942:3: error: implicit declaration of function >

Re: [PATCH 0/2] rhashtable_walk fixes

On Fri, Mar 30 2018, David Miller wrote: > From: NeilBrown > Date: Thu, 29 Mar 2018 12:19:09 +1100 > >> These two patches apply on top of my previous "rhashtable: reset iter >> when rhashtable_walk_start sees new table" patch. >> >> The first fixes a bug that I found in

Re: [PATCH 0/2] rhashtable_walk fixes

On Fri, Mar 30 2018, David Miller wrote: > From: NeilBrown > Date: Thu, 29 Mar 2018 12:19:09 +1100 > >> These two patches apply on top of my previous "rhashtable: reset iter >> when rhashtable_walk_start sees new table" patch. >> >> The first fixes a bug that I found in rhltable_insert(). >>

Re: [PATCH net] net: dsa: mt7530: Use NULL instead of plain integer

On Mon, 2018-04-02 at 16:24 -0700, Florian Fainelli wrote: > We would be passing 0 instead of NULL as the rsp argument to > mt7530_fdb_cmd(), fix that. > Acked-by: Sean Wang BTW, does the part of the commit message should be updated with "passing NULL instead of 0"? >

Re: [PATCH net] net: dsa: mt7530: Use NULL instead of plain integer

On Mon, 2018-04-02 at 16:24 -0700, Florian Fainelli wrote: > We would be passing 0 instead of NULL as the rsp argument to > mt7530_fdb_cmd(), fix that. > Acked-by: Sean Wang BTW, does the part of the commit message should be updated with "passing NULL instead of 0"? > Fixes: b8f126a8d543

linux-next: manual merge of the pci tree with the asm-generic tree

Hi all, Today's linux-next merge of the pci tree got a conflict in: arch/cris/arch-v32/drivers/pci/bios.c between commits: c690eddc2f3b ("CRIS: Drop support for the CRIS port") fd8773f9f544 ("arch: remove frv port") 739d875dd698 ("mn10300: Remove the architecture") from the

linux-next: manual merge of the pci tree with the asm-generic tree

Hi all, Today's linux-next merge of the pci tree got a conflict in: arch/cris/arch-v32/drivers/pci/bios.c between commits: c690eddc2f3b ("CRIS: Drop support for the CRIS port") fd8773f9f544 ("arch: remove frv port") 739d875dd698 ("mn10300: Remove the architecture") from the

  1   2   3   4   5   6   7   8   9   10   >