Re: [PATCH] mtd: nand: Add support for reading ooblayout from device tree

Hi Paul, On Fri, 11 May 2018 23:29:12 +0200 Paul Cercueil wrote: > By specifying the properties "mtd-oob-ecc" and "mtd-oob-free", it is > now possible to specify from devicetree where the ECC data is located > inside the OOB region. Why would we want to do that? I mean,

Re: [PATCH] mtd: nand: Add support for reading ooblayout from device tree

Hi Paul, On Fri, 11 May 2018 23:29:12 +0200 Paul Cercueil wrote: > By specifying the properties "mtd-oob-ecc" and "mtd-oob-free", it is > now possible to specify from devicetree where the ECC data is located > inside the OOB region. Why would we want to do that? I mean, ECC/free regions are

Re: [PATCH v2 03/12] arm: dts: mt7623: fix invalid memory node being generated

On Fri, 2018-05-11 at 17:03 +0200, Matthias Brugger wrote: > > On 04/11/2018 10:53 AM, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Below two wrong nodes in existing DTS files would cause a fail boot since > > in fact the address 0 is not the correct place

Re: [PATCH v2 03/12] arm: dts: mt7623: fix invalid memory node being generated

On Fri, 2018-05-11 at 17:03 +0200, Matthias Brugger wrote: > > On 04/11/2018 10:53 AM, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Below two wrong nodes in existing DTS files would cause a fail boot since > > in fact the address 0 is not the correct place the memory device locates

Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

On Fri, May 11, 2018 at 03:41:38PM -0700, Joel Fernandes wrote: > On Fri, May 11, 2018 at 09:17:46AM -0700, Paul E. McKenney wrote: > > On Fri, May 11, 2018 at 09:57:54PM +0900, Byungchul Park wrote: > > > Hello folks, > > > > > > I think I wrote the title in a misleading way. > > > > > > Please

Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

On Fri, May 11, 2018 at 03:41:38PM -0700, Joel Fernandes wrote: > On Fri, May 11, 2018 at 09:17:46AM -0700, Paul E. McKenney wrote: > > On Fri, May 11, 2018 at 09:57:54PM +0900, Byungchul Park wrote: > > > Hello folks, > > > > > > I think I wrote the title in a misleading way. > > > > > > Please

[PATCH 2/6] lustre: Use long long type to print inode time

Subsequent patches in the series convert inode timestamps to use struct timespec64 instead of struct timespec as part of solving the y2038 problem. Convert these print formats to use long long types to avoid warnings and errors on conversion. Signed-off-by: Deepa Dinamani

[PATCH 5/6] udf: Simplify calls to udf_disk_stamp_to_time

Subsequent patches in the series convert inode timestamps to use struct timespec64 instead of struct timespec as part of solving the y2038 problem. commit fd3cfad374d4 ("udf: Convert udf_disk_stamp_to_time() to use mktime64()") eliminated the NULL return condition from udf_disk_stamp_to_time().

[PATCH 6/6] vfs: change inode times to use struct timespec64

struct timespec is not y2038 safe. Transition vfs to use y2038 safe struct timespec64 instead. The change was made with the help of the following cocinelle script. This catches about 80% of the changes. All the header file and logic changes are included in the first 5 rules. The rest are trivial

[PATCH 2/6] lustre: Use long long type to print inode time

Subsequent patches in the series convert inode timestamps to use struct timespec64 instead of struct timespec as part of solving the y2038 problem. Convert these print formats to use long long types to avoid warnings and errors on conversion. Signed-off-by: Deepa Dinamani CC:

[PATCH 5/6] udf: Simplify calls to udf_disk_stamp_to_time

Subsequent patches in the series convert inode timestamps to use struct timespec64 instead of struct timespec as part of solving the y2038 problem. commit fd3cfad374d4 ("udf: Convert udf_disk_stamp_to_time() to use mktime64()") eliminated the NULL return condition from udf_disk_stamp_to_time().

[PATCH 6/6] vfs: change inode times to use struct timespec64

struct timespec is not y2038 safe. Transition vfs to use y2038 safe struct timespec64 instead. The change was made with the help of the following cocinelle script. This catches about 80% of the changes. All the header file and logic changes are included in the first 5 rules. The rest are trivial

[PATCH 3/6] ceph: make inode time prints to be long long

Subsequent patches in the series convert inode timestamps to use struct timespec64 instead of struct timespec as part of solving the y2038 problem. Convert these print formats to use long long types to avoid warnings and errors on conversion. Signed-off-by: Deepa Dinamani

[PATCH 1/6] fs: add timespec64_truncate()

As vfs moves to using struct timespec64 to represent times, update the argument to timespec_truncate() to use struct timespec64. Also change the name of the function. The rest of the implementation logic is the same. Move this to fs/inode.c instead of kernel/time/time.c as all the users of this

[PATCH 3/6] ceph: make inode time prints to be long long

Subsequent patches in the series convert inode timestamps to use struct timespec64 instead of struct timespec as part of solving the y2038 problem. Convert these print formats to use long long types to avoid warnings and errors on conversion. Signed-off-by: Deepa Dinamani Cc: z...@redhat.com

[PATCH 1/6] fs: add timespec64_truncate()

As vfs moves to using struct timespec64 to represent times, update the argument to timespec_truncate() to use struct timespec64. Also change the name of the function. The rest of the implementation logic is the same. Move this to fs/inode.c instead of kernel/time/time.c as all the users of this

[PATCH 4/6] fs: nfs: get rid of memcpys for inode times

Subsequent patches in the series convert inode timestamps to use struct timespec64 instead of struct timespec as part of solving the y2038 problem. This will lead to type mismatch for memcpys. Use regular assignments instead. Signed-off-by: Deepa Dinamani Cc:

[PATCH 4/6] fs: nfs: get rid of memcpys for inode times

Subsequent patches in the series convert inode timestamps to use struct timespec64 instead of struct timespec as part of solving the y2038 problem. This will lead to type mismatch for memcpys. Use regular assignments instead. Signed-off-by: Deepa Dinamani Cc: trond.mykleb...@primarydata.com ---

[PATCH 0/6] Transition vfs to 64-bit timestamps

The series aims to switch vfs timestamps to use struct timespec64. Currently vfs uses struct timespec, which is not y2038 safe. The series involves the following: 1. Add vfs helper functions for supporting struct timepec64 timestamps. 2. Cast prints of vfs timestamps to avoid warnings after the

[PATCH 0/6] Transition vfs to 64-bit timestamps

The series aims to switch vfs timestamps to use struct timespec64. Currently vfs uses struct timespec, which is not y2038 safe. The series involves the following: 1. Add vfs helper functions for supporting struct timepec64 timestamps. 2. Cast prints of vfs timestamps to avoid warnings after the

Re: [Ksummit-discuss] bug-introducing patches

Hi all, On Wed, 9 May 2018 20:47:27 +1000 Stephen Rothwell wrote: > > On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote: > > > > On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote: > > > On Wed, May 9, 2018 at 10:44 AM, Mark Brown

Re: [Ksummit-discuss] bug-introducing patches

Hi all, On Wed, 9 May 2018 20:47:27 +1000 Stephen Rothwell wrote: > > On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote: > > > > On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote: > > > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote: > > > > > > > > > I think this is

linux-next: a new pending-fixes branch

Hi all, As an outcome of some discussion, I have added a pending-fixes branch to linux-next. This branch contains Linus' tree merged with branches containing only fixes pending for the current release. The branch is a strict subset of linux-next each day (as so rebases like linux-next does).

linux-next: a new pending-fixes branch

Hi all, As an outcome of some discussion, I have added a pending-fixes branch to linux-next. This branch contains Linus' tree merged with branches containing only fixes pending for the current release. The branch is a strict subset of linux-next each day (as so rebases like linux-next does).

Re: [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions

On Sat, May 12, 2018 at 09:42:21AM +0900, Masami Hiramatsu wrote: > Hi Greg, > > Could you pick this series to stable? This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read:

Re: [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions

On Sat, May 12, 2018 at 09:42:21AM +0900, Masami Hiramatsu wrote: > Hi Greg, > > Could you pick this series to stable? This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read:

linux-next: added the vfs-fixes tree

Hi Al, As requested I have added the vfs-fixes tree (git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git#fixes) to linux-next from Monday. Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgement of your code. The purpose of

linux-next: added the vfs-fixes tree

Hi Al, As requested I have added the vfs-fixes tree (git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git#fixes) to linux-next from Monday. Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgement of your code. The purpose of

Re: [Ksummit-discuss] bug-introducing patches

Hi David, On Fri, 11 May 2018 10:47:01 +0200 David Sterba wrote: > > Please add > > git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git next-fixes Added from Monday (as btrfs-fixes). Thanks for adding your subsystem tree as a participant of linux-next. As you may

Re: [Ksummit-discuss] bug-introducing patches

Hi David, On Fri, 11 May 2018 10:47:01 +0200 David Sterba wrote: > > Please add > > git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git next-fixes Added from Monday (as btrfs-fixes). Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is

Re: linux-next: build warning after merge of the mac80211-next tree

Hi all, Just cc'ing the wireless list at Kalle's suggestion. On Wed, 9 May 2018 14:56:24 +1000 Stephen Rothwell wrote: > > Hi Johannes, > > After merging the mac80211-next tree, today's linux-next build (arm_multi > v7_defconfig) produced this warning: > >

Re: linux-next: build warning after merge of the mac80211-next tree

Hi all, Just cc'ing the wireless list at Kalle's suggestion. On Wed, 9 May 2018 14:56:24 +1000 Stephen Rothwell wrote: > > Hi Johannes, > > After merging the mac80211-next tree, today's linux-next build (arm_multi > v7_defconfig) produced this warning: > >

Re: linux-next: build warning after merge of the mac80211-next tree

Hi Kalle, On Fri, 11 May 2018 15:20:23 +0300 Kalle Valo wrote: > > Btw Stephen for mac80211 reports it would be a good idea to also cc > linux-wireless list, in case Johannes is not around etc. Thanks for the suggestion. Done. -- Cheers, Stephen Rothwell

Re: linux-next: build warning after merge of the mac80211-next tree

Hi Kalle, On Fri, 11 May 2018 15:20:23 +0300 Kalle Valo wrote: > > Btw Stephen for mac80211 reports it would be a good idea to also cc > linux-wireless list, in case Johannes is not around etc. Thanks for the suggestion. Done. -- Cheers, Stephen Rothwell pgpWmdiByugpz.pgp Description:

Fwd: KASAN: use-after-free Write in write_mem

-- Forwarded message -- From: Kyungtae Kim Date: Fri, May 11, 2018 at 11:38 AM Subject: KASAN: use-after-free Write in write_mem To: a...@arndb.de, gre...@linuxfoundation.org, linux-kernel@vger.kernel.org Cc: Byoungyoung Lee , DaeLyong

Fwd: KASAN: use-after-free Write in write_mem

-- Forwarded message -- From: Kyungtae Kim Date: Fri, May 11, 2018 at 11:38 AM Subject: KASAN: use-after-free Write in write_mem To: a...@arndb.de, gre...@linuxfoundation.org, linux-kernel@vger.kernel.org Cc: Byoungyoung Lee , DaeLyong Jeong We report the crash: "KASAN:

nios2 build: empty_zero_page ?

Hi, I bet this has come up before, but my search foo didn't find anything. When (cross) building nios2 allmodconfig, I am seeing this build error: ERROR: "empty_zero_page" [net/ceph/libceph.ko] undefined! ERROR: "empty_zero_page" [fs/exofs/exofs.ko] undefined! ERROR: "empty_zero_page"

nios2 build: empty_zero_page ?

Hi, I bet this has come up before, but my search foo didn't find anything. When (cross) building nios2 allmodconfig, I am seeing this build error: ERROR: "empty_zero_page" [net/ceph/libceph.ko] undefined! ERROR: "empty_zero_page" [fs/exofs/exofs.ko] undefined! ERROR: "empty_zero_page"

Re: [PATCH] rcu: trace: Remove Startedleaf from trace events comment

On Fri, May 11, 2018 at 06:29:57PM -0700, Joel Fernandes wrote: > On Fri, May 11, 2018 at 6:29 PM, Joel Fernandes (Google) > wrote: > > > > As part of the gp_seq clean up, the Startleaf condition doesn't occur > > anymore. Remove it from the comment in the trace event

Re: [PATCH] rcu: trace: Remove Startedleaf from trace events comment

On Fri, May 11, 2018 at 06:29:57PM -0700, Joel Fernandes wrote: > On Fri, May 11, 2018 at 6:29 PM, Joel Fernandes (Google) > wrote: > > > > As part of the gp_seq clean up, the Startleaf condition doesn't occur > > anymore. Remove it from the comment in the trace event file. > > Sorry, I meant

Re: [PATCH v2] rcu: Add comment documenting how rcu_seq_snap works

On 05/11/2018 07:20 PM, Joel Fernandes (Google) wrote: > rcu_seq_snap may be tricky for someone looking at it for the first time. > Lets document how it works with an example to make it easier. > > Signed-off-by: Joel Fernandes (Google) > --- > v2 changes: Corrections as

Re: [PATCH v2] rcu: Add comment documenting how rcu_seq_snap works

On 05/11/2018 07:20 PM, Joel Fernandes (Google) wrote: > rcu_seq_snap may be tricky for someone looking at it for the first time. > Lets document how it works with an example to make it easier. > > Signed-off-by: Joel Fernandes (Google) > --- > v2 changes: Corrections as suggested by Randy. > >

Re: Another NVMe failure, this time with AER info

On Sat, May 12, 2018 at 12:57 AM, Bjorn Helgaas wrote: > Andrew wrote: >> A friend of mine has a brand new LG laptop that has intermittent NVMe >> failures. They mostly happen during a suspend/resume cycle >> (apparently during suspend, not resume). Unlike the earlier >>

Re: Another NVMe failure, this time with AER info

On Sat, May 12, 2018 at 12:57 AM, Bjorn Helgaas wrote: > Andrew wrote: >> A friend of mine has a brand new LG laptop that has intermittent NVMe >> failures. They mostly happen during a suspend/resume cycle >> (apparently during suspend, not resume). Unlike the earlier >> Dell/Samsung issue, the

[PATCH v3 0/2] regulator: add QCOM RPMh regulator driver

This patch series adds a driver and device tree binding documentation for PMIC regulator control via Resource Power Manager-hardened (RPMh) on some Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block which contains several accelerators which are used to manage various

[PATCH v3 2/2] regulator: add QCOM RPMh regulator driver

Add the QCOM RPMh regulator driver to manage PMIC regulators which are controlled via RPMh on some Qualcomm Technologies, Inc. SoCs. RPMh is a hardware block which contains several accelerators which are used to manage various hardware resources that are shared between the processors of the SoC.

[PATCH v3 0/2] regulator: add QCOM RPMh regulator driver

This patch series adds a driver and device tree binding documentation for PMIC regulator control via Resource Power Manager-hardened (RPMh) on some Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block which contains several accelerators which are used to manage various

[PATCH v3 2/2] regulator: add QCOM RPMh regulator driver

Add the QCOM RPMh regulator driver to manage PMIC regulators which are controlled via RPMh on some Qualcomm Technologies, Inc. SoCs. RPMh is a hardware block which contains several accelerators which are used to manage various hardware resources that are shared between the processors of the SoC.

[PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings

Introduce bindings for RPMh regulator devices found on some Qualcomm Technlogies, Inc. SoCs. These devices allow a given processor within the SoC to make PMIC regulator requests which are aggregated within the RPMh hardware block along with requests from other processors in the SoC to determine

[PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings

Introduce bindings for RPMh regulator devices found on some Qualcomm Technlogies, Inc. SoCs. These devices allow a given processor within the SoC to make PMIC regulator requests which are aggregated within the RPMh hardware block along with requests from other processors in the SoC to determine

[PATCH v2] rcu: Add comment documenting how rcu_seq_snap works

rcu_seq_snap may be tricky for someone looking at it for the first time. Lets document how it works with an example to make it easier. Signed-off-by: Joel Fernandes (Google) --- v2 changes: Corrections as suggested by Randy. kernel/rcu/rcu.h | 24

[PATCH v2] rcu: Add comment documenting how rcu_seq_snap works

rcu_seq_snap may be tricky for someone looking at it for the first time. Lets document how it works with an example to make it easier. Signed-off-by: Joel Fernandes (Google) --- v2 changes: Corrections as suggested by Randy. kernel/rcu/rcu.h | 24 +++- 1 file changed, 23

[PATCH] rcu: Add comment documenting how rcu_seq_snap works

On 05/11/2018 05:33 PM, Joel Fernandes (Google) wrote: > rcu_seq_snap may be tricky for someone looking at it for the first time. > Lets document how it works with an example to make it easier. > > Signed-off-by: Joel Fernandes (Google) > --- > kernel/rcu/rcu.h | 23

[PATCH] rcu: Add comment documenting how rcu_seq_snap works

On 05/11/2018 05:33 PM, Joel Fernandes (Google) wrote: > rcu_seq_snap may be tricky for someone looking at it for the first time. > Lets document how it works with an example to make it easier. > > Signed-off-by: Joel Fernandes (Google) > --- > kernel/rcu/rcu.h | 23 ++- > 1

[PATCH 1/2] regulator: of: add property for allowed modes specification

Add a common device tree property for regulator nodes to support the specification of allowed operating modes. Signed-off-by: David Collins --- Documentation/devicetree/bindings/regulator/regulator.txt | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH 1/2] regulator: of: add property for allowed modes specification

Add a common device tree property for regulator nodes to support the specification of allowed operating modes. Signed-off-by: David Collins --- Documentation/devicetree/bindings/regulator/regulator.txt | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH 2/2] regulator: of: add support for allowed modes configuration

Add support for configuring the machine constraints valid_modes_mask element based on a list of allowed modes specified via a device tree property. Signed-off-by: David Collins --- drivers/regulator/of_regulator.c | 29 - 1 file changed, 28

[PATCH 0/2] regulator: of: add device tree property for allowed modes

There is currently no accepted way to configure constraints->valid_modes_mask for regulators defined in device tree. This patch series defines a new common regulator device tree property, regulator-allowed-modes, which can be used to specify the set of modes that the regulator is allowed to use.

[PATCH 2/2] regulator: of: add support for allowed modes configuration

Add support for configuring the machine constraints valid_modes_mask element based on a list of allowed modes specified via a device tree property. Signed-off-by: David Collins --- drivers/regulator/of_regulator.c | 29 - 1 file changed, 28 insertions(+), 1

[PATCH 0/2] regulator: of: add device tree property for allowed modes

There is currently no accepted way to configure constraints->valid_modes_mask for regulators defined in device tree. This patch series defines a new common regulator device tree property, regulator-allowed-modes, which can be used to specify the set of modes that the regulator is allowed to use.

Re: [PATCH] rcu: trace: Remove Startedleaf from trace events comment

On Fri, May 11, 2018 at 6:29 PM, Joel Fernandes (Google) wrote: > > As part of the gp_seq clean up, the Startleaf condition doesn't occur > anymore. Remove it from the comment in the trace event file. Sorry, I meant here Startedleaf. Let me know if you want me to resend

Re: [PATCH] rcu: trace: Remove Startedleaf from trace events comment

On Fri, May 11, 2018 at 6:29 PM, Joel Fernandes (Google) wrote: > > As part of the gp_seq clean up, the Startleaf condition doesn't occur > anymore. Remove it from the comment in the trace event file. Sorry, I meant here Startedleaf. Let me know if you want me to resend the patch. thanks, -

[PATCH] rcu: trace: Remove Startedleaf from trace events comment

As part of the gp_seq clean up, the Startleaf condition doesn't occur anymore. Remove it from the comment in the trace event file. Signed-off-by: Joel Fernandes (Google) --- include/trace/events/rcu.h | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH] rcu: trace: Remove Startedleaf from trace events comment

As part of the gp_seq clean up, the Startleaf condition doesn't occur anymore. Remove it from the comment in the trace event file. Signed-off-by: Joel Fernandes (Google) --- include/trace/events/rcu.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/trace/events/rcu.h

[RFC] crypto: Remove mcryptd

This patch attempts to remove the mcryptd interface and expose the sha1 multibuffer algorithm as a proper ahash to the inner algorithm. 1. Host the flusher helper in sha1_mb.c instead of mcryptd.c (need to change the names of these functions) 2. Remove unnecessary mcryptd structure

[RFC] crypto: Remove mcryptd

This patch attempts to remove the mcryptd interface and expose the sha1 multibuffer algorithm as a proper ahash to the inner algorithm. 1. Host the flusher helper in sha1_mb.c instead of mcryptd.c (need to change the names of these functions) 2. Remove unnecessary mcryptd structure

RE: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

>-Original Message- >From: Herbert Xu [mailto:herb...@gondor.apana.org.au] >Sent: Thursday, May 10, 2018 9:46 PM >To: Dey, Megha >Cc: linux-kernel@vger.kernel.org; linux-cry...@vger.kernel.org; >da...@davemloft.net >Subject: Re: [PATCH V8 1/5] crypto: Multi-buffer

RE: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

>-Original Message- >From: Herbert Xu [mailto:herb...@gondor.apana.org.au] >Sent: Thursday, May 10, 2018 9:46 PM >To: Dey, Megha >Cc: linux-kernel@vger.kernel.org; linux-cry...@vger.kernel.org; >da...@davemloft.net >Subject: Re: [PATCH V8 1/5] crypto: Multi-buffer encryption

Re: WARNING: bad unlock balance in xfs_iunlock

On Fri, May 11, 2018 at 10:59:53AM +0200, Dmitry Vyukov wrote: > On Thu, May 10, 2018 at 1:22 AM, Dave Chinner wrote: > > On Wed, May 09, 2018 at 10:43:05AM +0200, Dmitry Vyukov wrote: > >> Does "xfstests fuzzing infrastructure" use coverage-guidance? > > > > It's guided

Re: WARNING: bad unlock balance in xfs_iunlock

On Fri, May 11, 2018 at 10:59:53AM +0200, Dmitry Vyukov wrote: > On Thu, May 10, 2018 at 1:22 AM, Dave Chinner wrote: > > On Wed, May 09, 2018 at 10:43:05AM +0200, Dmitry Vyukov wrote: > >> Does "xfstests fuzzing infrastructure" use coverage-guidance? > > > > It's guided manually to fuzz a

Re: [PATCH 0/3] KVM: VMX: Allow to disable ioport intercept per-VM by userspace

2018-05-11 23:40 GMT+08:00 Konrad Rzeszutek Wilk : > On Mon, Apr 16, 2018 at 10:45:59PM -0700, Wanpeng Li wrote: >> Tim Shearer reported that "There is a guest which is running a packet >> forwarding app based on the DPDK (dpdk.org). The packet receive routine >> writes to

Re: [PATCH 0/3] KVM: VMX: Allow to disable ioport intercept per-VM by userspace

2018-05-11 23:40 GMT+08:00 Konrad Rzeszutek Wilk : > On Mon, Apr 16, 2018 at 10:45:59PM -0700, Wanpeng Li wrote: >> Tim Shearer reported that "There is a guest which is running a packet >> forwarding app based on the DPDK (dpdk.org). The packet receive routine >> writes to 0xc070 using glibc's

Re: KASAN: null-ptr-deref Read in rds_ib_get_mr

On 2018/5/12 0:58, Santosh Shilimkar wrote: On 5/11/2018 12:48 AM, Yanjun Zhu wrote: On 2018/5/11 13:20, DaeRyong Jeong wrote: We report the crash: KASAN: null-ptr-deref Read in rds_ib_get_mr Note that this bug is previously reported by syzkaller.

Re: KASAN: null-ptr-deref Read in rds_ib_get_mr

On 2018/5/12 0:58, Santosh Shilimkar wrote: On 5/11/2018 12:48 AM, Yanjun Zhu wrote: On 2018/5/11 13:20, DaeRyong Jeong wrote: We report the crash: KASAN: null-ptr-deref Read in rds_ib_get_mr Note that this bug is previously reported by syzkaller.

Re: [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions

Hi Greg, Could you pick this series to stable? Thank you, On Tue, 8 May 2018 12:25:03 +0100 Russell King - ARM Linux wrote: > On Fri, May 04, 2018 at 01:14:31PM +0900, Masami Hiramatsu wrote: > > Hi, > > > > This is the 3rd version of bugfix series for kprobes on arm.

Re: [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions

Hi Greg, Could you pick this series to stable? Thank you, On Tue, 8 May 2018 12:25:03 +0100 Russell King - ARM Linux wrote: > On Fri, May 04, 2018 at 01:14:31PM +0900, Masami Hiramatsu wrote: > > Hi, > > > > This is the 3rd version of bugfix series for kprobes on arm. > > This series fixes 4

[PATCH] rcu: Add comment documenting how rcu_seq_snap works

rcu_seq_snap may be tricky for someone looking at it for the first time. Lets document how it works with an example to make it easier. Signed-off-by: Joel Fernandes (Google) --- kernel/rcu/rcu.h | 23 ++- 1 file changed, 22 insertions(+), 1

[PATCH] rcu: Add comment documenting how rcu_seq_snap works

rcu_seq_snap may be tricky for someone looking at it for the first time. Lets document how it works with an example to make it easier. Signed-off-by: Joel Fernandes (Google) --- kernel/rcu/rcu.h | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git

Re: [GIT] Networking

On Fri, May 11, 2018 at 5:10 PM David Miller wrote: > I guess this is my reward for trying to break the monotony of > pull requests :-) I actually went back and checked a few older pull requests to see if this had been going on for a while and I just hadn't noticed. It

Re: [GIT] Networking

On Fri, May 11, 2018 at 5:10 PM David Miller wrote: > I guess this is my reward for trying to break the monotony of > pull requests :-) I actually went back and checked a few older pull requests to see if this had been going on for a while and I just hadn't noticed. It just took me by surprise

Re: [GIT] Networking

From: Linus Torvalds Date: Fri, 11 May 2018 14:25:59 -0700 > David, is there something you want to tell us? > > Drugs are bad, m'kay.. I guess this is my reward for trying to break the monotony of pull requests :-)

Re: [GIT] Networking

From: Linus Torvalds Date: Fri, 11 May 2018 14:25:59 -0700 > David, is there something you want to tell us? > > Drugs are bad, m'kay.. I guess this is my reward for trying to break the monotony of pull requests :-)

Re: [PATCH net] net: dsa: bcm_sf2: Fix RX_CLS_LOC_ANY overwrite for last rule

From: Florian Fainelli Date: Fri, 11 May 2018 16:38:02 -0700 > David, please discard that for now, the IPv4 part is correct, but I am > not fixing the bug correctly for the IPv6 part. v2 coming some time next > week. Thank you! Ok.

Re: [PATCH net] net: dsa: bcm_sf2: Fix RX_CLS_LOC_ANY overwrite for last rule

From: Florian Fainelli Date: Fri, 11 May 2018 16:38:02 -0700 > David, please discard that for now, the IPv4 part is correct, but I am > not fixing the bug correctly for the IPv6 part. v2 coming some time next > week. Thank you! Ok.

[PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early

The original intent in cacheinfo was that an architecture specific populate_cache_leaves() would probe the hardware and then cache_shared_cpu_map_setup() and cache_override_properties() would provide firmware help to extend/expand upon what was probed. Arm64 was really the only architecture that

[PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early

The original intent in cacheinfo was that an architecture specific populate_cache_leaves() would probe the hardware and then cache_shared_cpu_map_setup() and cache_override_properties() would provide firmware help to extend/expand upon what was probed. Arm64 was really the only architecture that

[PATCH v9 04/12] arm64/acpi: Create arch specific cpu to acpi id helper

Its helpful to be able to lookup the acpi_processor_id associated with a logical cpu. Provide an arm64 helper to do this. Signed-off-by: Jeremy Linton Tested-by: Ard Biesheuvel Tested-by: Vijaya Kumar K Tested-by:

[PATCH v9 04/12] arm64/acpi: Create arch specific cpu to acpi id helper

Its helpful to be able to lookup the acpi_processor_id associated with a logical cpu. Provide an arm64 helper to do this. Signed-off-by: Jeremy Linton Tested-by: Ard Biesheuvel Tested-by: Vijaya Kumar K Tested-by: Xiongfeng Wang Tested-by: Tomasz Nowicki Acked-by: Ard Biesheuvel ---

[PATCH v9 01/12] drivers: base: cacheinfo: move cache_setup_of_node()

In preparation for the next patch, and to aid in review of that patch, lets move cache_setup_of_node further down in the module without any changes. Signed-off-by: Jeremy Linton Tested-by: Ard Biesheuvel Tested-by: Vijaya Kumar K

[PATCH v9 01/12] drivers: base: cacheinfo: move cache_setup_of_node()

In preparation for the next patch, and to aid in review of that patch, lets move cache_setup_of_node further down in the module without any changes. Signed-off-by: Jeremy Linton Tested-by: Ard Biesheuvel Tested-by: Vijaya Kumar K Tested-by: Xiongfeng Wang Tested-by: Tomasz Nowicki

[PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing

ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the properties of the caches in relation to other caches and processing units. Add the code to parse the cache hierarchy and

[PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing

ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the properties of the caches in relation to other caches and processing units. Add the code to parse the cache hierarchy and

[PATCH v9 07/12] drivers: base cacheinfo: Add support for ACPI based firmware tables

Call ACPI cache parsing routines from base cacheinfo code if ACPI is enabled. Also stub out cache_setup_acpi and acpi_find_last_cache_level so that individual architectures can enable ACPI topology parsing. Signed-off-by: Jeremy Linton Tested-by: Ard Biesheuvel

[PATCH v9 07/12] drivers: base cacheinfo: Add support for ACPI based firmware tables

Call ACPI cache parsing routines from base cacheinfo code if ACPI is enabled. Also stub out cache_setup_acpi and acpi_find_last_cache_level so that individual architectures can enable ACPI topology parsing. Signed-off-by: Jeremy Linton Tested-by: Ard Biesheuvel Tested-by: Vijaya Kumar K

[PATCH v9 09/12] arm64: topology: rename cluster_id

The cluster concept isn't architecturally defined for arm64. Lets match the name of the arm64 topology field to the kernel macro that uses it. Signed-off-by: Jeremy Linton Tested-by: Ard Biesheuvel Tested-by: Vijaya Kumar K

[PATCH v9 09/12] arm64: topology: rename cluster_id

The cluster concept isn't architecturally defined for arm64. Lets match the name of the arm64 topology field to the kernel macro that uses it. Signed-off-by: Jeremy Linton Tested-by: Ard Biesheuvel Tested-by: Vijaya Kumar K Tested-by: Xiongfeng Wang Tested-by: Tomasz Nowicki Acked-by: Sudeep

[PATCH v9 08/12] arm64: Add support for ACPI based firmware tables

The /sys cache entries should support ACPI/PPTT generated cache topology information. For arm64, if ACPI is enabled, determine the max number of cache levels and populate them using the PPTT table if one is available. Signed-off-by: Jeremy Linton Tested-by: Ard Biesheuvel

[PATCH v9 08/12] arm64: Add support for ACPI based firmware tables

The /sys cache entries should support ACPI/PPTT generated cache topology information. For arm64, if ACPI is enabled, determine the max number of cache levels and populate them using the PPTT table if one is available. Signed-off-by: Jeremy Linton Tested-by: Ard Biesheuvel Tested-by: Vijaya

[PATCH v9 10/12] arm64: topology: enable ACPI/PPTT based CPU topology

Propagate the topology information from the PPTT tree to the cpu_topology array. We can get the thread id and core_id by assuming certain levels of the PPTT tree correspond to those concepts. The package_id is flagged in the tree and can be found by calling find_acpi_cpu_topology_package() which

[PATCH v9 10/12] arm64: topology: enable ACPI/PPTT based CPU topology

Propagate the topology information from the PPTT tree to the cpu_topology array. We can get the thread id and core_id by assuming certain levels of the PPTT tree correspond to those concepts. The package_id is flagged in the tree and can be found by calling find_acpi_cpu_topology_package() which

  1   2   3   4   5   6   7   8   9   10   >