Re: [PATCH 10/10] [RFC] w1_netlink.h: add support for nested structs

Hi 26.09.2017, 20:59, "Mauro Carvalho Chehab" : > Describe nested struct/union fields > > NOTE: This is a pure test patch, meant to validate if the > parsing logic for nested structs is working properly. > > I've no idea if the random text I added there is correct! It

Re: [PATCH 10/10] [RFC] w1_netlink.h: add support for nested structs

Hi 26.09.2017, 20:59, "Mauro Carvalho Chehab" : > Describe nested struct/union fields > > NOTE: This is a pure test patch, meant to validate if the > parsing logic for nested structs is working properly. > > I've no idea if the random text I added there is correct! It looks correct, although I

Re: [PATCH] w1: keep balance of mutex locks and refcnts

Hi Alex 29.09.2017, 23:23, "Alexey Khoroshilov" : > w1_therm_eeprom() and w1_DS18B20_precision() decrement THERM_REFCNT > on error paths, while they did not increment it yet. > > read_therm() unlocks bus mutex on some error paths, > while it is not acquired. > > The patch

Re: [PATCH] w1: keep balance of mutex locks and refcnts

Hi Alex 29.09.2017, 23:23, "Alexey Khoroshilov" : > w1_therm_eeprom() and w1_DS18B20_precision() decrement THERM_REFCNT > on error paths, while they did not increment it yet. > > read_therm() unlocks bus mutex on some error paths, > while it is not acquired. > > The patch makes sure all the

Re: [PATCH for-next 3/4] RDMA/hns: Update the IRRL table chunk size in hip08

On Sat, Sep 30, 2017 at 05:29:00PM +0800, Wei Hu (Xavier) wrote: > As the increase of the IRRL specification in hip08, the IRRL table > chunk size needs to be updated. > This patch updates the IRRL table chunk size to 256k for hip08. > > Signed-off-by: Wei Hu (Xavier) >

Re: [PATCH for-next 3/4] RDMA/hns: Update the IRRL table chunk size in hip08

On Sat, Sep 30, 2017 at 05:29:00PM +0800, Wei Hu (Xavier) wrote: > As the increase of the IRRL specification in hip08, the IRRL table > chunk size needs to be updated. > This patch updates the IRRL table chunk size to 256k for hip08. > > Signed-off-by: Wei Hu (Xavier) > Signed-off-by: Shaobo Xu

ERROR: "__cmpxchg_u64" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!

Hi Jacob, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: a8c964eacb21288b2dbfa9d80cee5968a3b8fb21 commit: 841c950d67c6facde32a8644ced20c04aebb7dd8 i40e/i40evf: use cmpxchg64 when updating private flags in ethtool

ERROR: "__cmpxchg_u64" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!

Hi Jacob, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: a8c964eacb21288b2dbfa9d80cee5968a3b8fb21 commit: 841c950d67c6facde32a8644ced20c04aebb7dd8 i40e/i40evf: use cmpxchg64 when updating private flags in ethtool

Re: [PATCH net-next 0/3] support changing steering policies in tuntap

On Thu, Sep 28, 2017 at 12:09:05PM -0400, Willem de Bruijn wrote: > Programming from the guest is > indeed different. I don't fully understand that use case. Generally programming host BPF from guest is a clear win - think DOS protection. Guest runs logic to detect dos attacks, then passes the

Re: [PATCH net-next 0/3] support changing steering policies in tuntap

On Thu, Sep 28, 2017 at 12:09:05PM -0400, Willem de Bruijn wrote: > Programming from the guest is > indeed different. I don't fully understand that use case. Generally programming host BPF from guest is a clear win - think DOS protection. Guest runs logic to detect dos attacks, then passes the

Re: [PATCH v16 5/5] virtio-balloon: VIRTIO_BALLOON_F_CTRL_VQ

On Sat, Sep 30, 2017 at 12:05:54PM +0800, Wei Wang wrote: > Add a new vq, ctrl_vq, to handle commands between the host and guest. > With this feature, we will be able to have the control plane and data > plane separated. In other words, the control related commands of each > feature will be sent

Re: [PATCH v16 5/5] virtio-balloon: VIRTIO_BALLOON_F_CTRL_VQ

On Sat, Sep 30, 2017 at 12:05:54PM +0800, Wei Wang wrote: > Add a new vq, ctrl_vq, to handle commands between the host and guest. > With this feature, we will be able to have the control plane and data > plane separated. In other words, the control related commands of each > feature will be sent

Re: [PATCH net-next v2 0/7] net: dsa: change dsa_ptr for a dsa_port

From: Vivien Didelot Date: Fri, 29 Sep 2017 17:19:14 -0400 > With DSA, a master net_device is physically wired to a dedicated CPU > switch port. For interaction with the DSA layer, the struct net_device > contains a dsa_ptr, which currently points to a

Re: [PATCH net-next v2 0/7] net: dsa: change dsa_ptr for a dsa_port

From: Vivien Didelot Date: Fri, 29 Sep 2017 17:19:14 -0400 > With DSA, a master net_device is physically wired to a dedicated CPU > switch port. For interaction with the DSA layer, the struct net_device > contains a dsa_ptr, which currently points to a dsa_switch_tree object. > > This is only

Re: [PATCH] net: hns3: fix null pointer dereference before null check

From: Colin King Date: Fri, 29 Sep 2017 20:51:23 +0100 > From: Colin Ian King > > pointer ndev is being dereferenced with the call to netif_running > before it is being null checked. Re-order the code to only dereference > ndev after it has

Re: [PATCH] net: hns3: fix null pointer dereference before null check

From: Colin King Date: Fri, 29 Sep 2017 20:51:23 +0100 > From: Colin Ian King > > pointer ndev is being dereferenced with the call to netif_running > before it is being null checked. Re-order the code to only dereference > ndev after it has been null checked. > > Detected by CoverityScan,

Re: [PATCH][net-next] net_sched: remove redundant assignment to ret

From: Colin King Date: Fri, 29 Sep 2017 15:01:16 +0100 > From: Colin Ian King > > The assignment of -EINVAL to variable ret is redundant as it > is being overwritten on the following error exit paths or > to the return value from the

Re: [PATCH][net-next] net_sched: remove redundant assignment to ret

From: Colin King Date: Fri, 29 Sep 2017 15:01:16 +0100 > From: Colin Ian King > > The assignment of -EINVAL to variable ret is redundant as it > is being overwritten on the following error exit paths or > to the return value from the following call to basic_set_parms. > Fix this up by removing

Re: [PATCH][net-next] net: ipmr: make function ipmr_notifier_init static

From: Colin King Date: Fri, 29 Sep 2017 14:34:22 +0100 > From: Colin Ian King > > The function ipmr_notifier_init is local to the source and does > not need to be in global scope, so make it static. > > Cleans up sparse warning: > warning:

Re: [PATCH][net-next] net: ipmr: make function ipmr_notifier_init static

From: Colin King Date: Fri, 29 Sep 2017 14:34:22 +0100 > From: Colin Ian King > > The function ipmr_notifier_init is local to the source and does > not need to be in global scope, so make it static. > > Cleans up sparse warning: > warning: symbol 'ipmr_notifier_init' was not declared. Should

Re: [PATCH net-next] Revert "net: dsa: bcm_sf2: Defer port enabling to calling port_enable"

From: Florian Fainelli Date: Thu, 28 Sep 2017 11:19:06 -0700 > This reverts commit e85ec74ace29 ("net: dsa: bcm_sf2: Defer port > enabling to calling port_enable") because this now makes an unbind > followed by a bind to fail connecting to the ingrated PHY. > > What this

Re: [PATCH net-next] Revert "net: dsa: bcm_sf2: Defer port enabling to calling port_enable"

From: Florian Fainelli Date: Thu, 28 Sep 2017 11:19:06 -0700 > This reverts commit e85ec74ace29 ("net: dsa: bcm_sf2: Defer port > enabling to calling port_enable") because this now makes an unbind > followed by a bind to fail connecting to the ingrated PHY. > > What this patch missed is that we

Re: [RESEND RFC PATCH 0/7] sun8i H3 HDMI glue driver for DW HDMI

On 01/10/17 04:56, Jernej Škrabec wrote: > Hi, > > Dne sobota, 30. september 2017 ob 13:58:03 CEST je Alexey Kardashevskiy > napisal(a): >> On 21/09/17 06:01, Jernej Skrabec wrote: >>> [added media mailing list due to CEC question] >>> >>> This patch series adds a HDMI glue driver for Allwinner

Re: [RESEND RFC PATCH 0/7] sun8i H3 HDMI glue driver for DW HDMI

On 01/10/17 04:56, Jernej Škrabec wrote: > Hi, > > Dne sobota, 30. september 2017 ob 13:58:03 CEST je Alexey Kardashevskiy > napisal(a): >> On 21/09/17 06:01, Jernej Skrabec wrote: >>> [added media mailing list due to CEC question] >>> >>> This patch series adds a HDMI glue driver for Allwinner

Re: [RFC PATCH 3/3] fs: detect that the i_rwsem has already been taken exclusively

Linus Torvalds writes: > On Thu, Sep 28, 2017 at 6:53 PM, Mimi Zohar wrote: >> >> The locking issue isn't with validating the file hash, but with the >> setxattr, chmod, chown syscalls. Each of these syscalls takes the >> i_rwsem

Re: [RFC PATCH 3/3] fs: detect that the i_rwsem has already been taken exclusively

Linus Torvalds writes: > On Thu, Sep 28, 2017 at 6:53 PM, Mimi Zohar wrote: >> >> The locking issue isn't with validating the file hash, but with the >> setxattr, chmod, chown syscalls. Each of these syscalls takes the >> i_rwsem exclusively before IMA (or EVM) is called. > > Read my email

[PATCH v2] kvm/x86: Handle async PF in RCU read-side critical sections

Sasha Levin reported a WARNING: | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 | rcu_preempt_note_context_switch kernel/rcu/tree_plugin.h:329 [inline] | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 | rcu_note_context_switch+0x16c/0x2210 kernel/rcu/tree.c:458 ... | CPU: 0

[PATCH v2] kvm/x86: Handle async PF in RCU read-side critical sections

Sasha Levin reported a WARNING: | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 | rcu_preempt_note_context_switch kernel/rcu/tree_plugin.h:329 [inline] | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 | rcu_note_context_switch+0x16c/0x2210 kernel/rcu/tree.c:458 ... | CPU: 0

Loan

UNSECURED BUSINESS/PERSONAL LOAN BY LOAN CAPITAL FINANCE - NO COLLATERAL - MINIMUM DOCUMENTATION - BUSINESS LOAN UP TO FIVE(5) MILLION US DOLLARS CONTACT US TODAY VIA EMAIL: financecapital...@mail.com

Loan

UNSECURED BUSINESS/PERSONAL LOAN BY LOAN CAPITAL FINANCE - NO COLLATERAL - MINIMUM DOCUMENTATION - BUSINESS LOAN UP TO FIVE(5) MILLION US DOLLARS CONTACT US TODAY VIA EMAIL: financecapital...@mail.com

[PATCH] mn10300: Use is_vmalloc_addr

To is_vmalloc_addr() to check if an address is a vmalloc address instead of checking VMALLOC_START and VMALLOC_END manually. Signed-off-by: Min-Hua Chen --- arch/mn10300/kernel/gdb-stub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] mn10300: Use is_vmalloc_addr

To is_vmalloc_addr() to check if an address is a vmalloc address instead of checking VMALLOC_START and VMALLOC_END manually. Signed-off-by: Min-Hua Chen --- arch/mn10300/kernel/gdb-stub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mn10300/kernel/gdb-stub.c

Re: [PATCH] kvm/x86: Handle async PF in RCU read-side critical sections

On Sat, Sep 30, 2017 at 05:15:15PM +, Paul E. McKenney wrote: > On Sat, Sep 30, 2017 at 07:41:56AM +0800, Boqun Feng wrote: > > On Fri, Sep 29, 2017 at 04:43:39PM +, Paul E. McKenney wrote: > > > On Fri, Sep 29, 2017 at 04:53:57PM +0200, Paolo Bonzini wrote: > > > > On 29/09/2017 13:01,

Re: [PATCH] kvm/x86: Handle async PF in RCU read-side critical sections

On Sat, Sep 30, 2017 at 05:15:15PM +, Paul E. McKenney wrote: > On Sat, Sep 30, 2017 at 07:41:56AM +0800, Boqun Feng wrote: > > On Fri, Sep 29, 2017 at 04:43:39PM +, Paul E. McKenney wrote: > > > On Fri, Sep 29, 2017 at 04:53:57PM +0200, Paolo Bonzini wrote: > > > > On 29/09/2017 13:01,

[PATCH] perf: tools: Install strace group definitions without executable bit

The install command sets executable permission by default, but these definitions aren't executables. Signed-off-by: Ben Hutchings --- tools/perf/Makefile.perf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Makefile.perf

[PATCH] perf: tools: Install strace group definitions without executable bit

The install command sets executable permission by default, but these definitions aren't executables. Signed-off-by: Ben Hutchings --- tools/perf/Makefile.perf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index

Re: [PATCHv2] mm: Account pud page tables

Hi Kirill, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc2] [cannot apply to next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCHv2] mm: Account pud page tables

Hi Kirill, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc2] [cannot apply to next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] kbuild: clang: remove crufty HOSTCFLAGS

On Sat, Sep 30, 2017 at 04:14:50PM -0700, Nick Desaulniers wrote: > On Thu, Sep 28, 2017 at 07:52:35PM +0900, Masahiro Yamada wrote: > > 2017-09-26 11:28 GMT+09:00 Nick Desaulniers : > > > HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ > > > +

Re: [PATCH] kbuild: clang: remove crufty HOSTCFLAGS

On Sat, Sep 30, 2017 at 04:14:50PM -0700, Nick Desaulniers wrote: > On Thu, Sep 28, 2017 at 07:52:35PM +0900, Masahiro Yamada wrote: > > 2017-09-26 11:28 GMT+09:00 Nick Desaulniers : > > > HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ > > > + $(call

Re: [PATCHv2] mm: Account pud page tables

Hi Kirill, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc2] [cannot apply to next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCHv2] mm: Account pud page tables

Hi Kirill, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc2] [cannot apply to next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 3/3] ignore_this_patch: Fixing compilation error on Peter's tree

Hi Rohit, [auto build test ERROR on tip/sched/core] [also build test ERROR on v4.14-rc2 next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 3/3] ignore_this_patch: Fixing compilation error on Peter's tree

Hi Rohit, [auto build test ERROR on tip/sched/core] [also build test ERROR on v4.14-rc2 next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [RESEND PATCH] fs: add RWF_APPEND

On 09/29/2017 07:07 AM, Jürg Billeter wrote: > This is the per-I/O equivalent of O_APPEND to support atomic append > operations on any open file. > > If a file is opened with O_APPEND, pwrite() ignores the offset and > always appends data to the end of the file. RWF_APPEND enables atomic >

Re: [RESEND PATCH] fs: add RWF_APPEND

On 09/29/2017 07:07 AM, Jürg Billeter wrote: > This is the per-I/O equivalent of O_APPEND to support atomic append > operations on any open file. > > If a file is opened with O_APPEND, pwrite() ignores the offset and > always appends data to the end of the file. RWF_APPEND enables atomic >

Re: [kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options

On Sun, Oct 01, 2017 at 11:06:44AM +1100, Tobin C. Harding wrote: > Version 2 of Greg's patch series with changes made as suggested by comments > to V1. Patch set tested by setting /proc/sys/kernel/kptr_restrict and inserting the following module #include #include #define DRIVER_AUTHOR

Re: [kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options

On Sun, Oct 01, 2017 at 11:06:44AM +1100, Tobin C. Harding wrote: > Version 2 of Greg's patch series with changes made as suggested by comments > to V1. Patch set tested by setting /proc/sys/kernel/kptr_restrict and inserting the following module #include #include #define DRIVER_AUTHOR

[kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

Set the initial value of kptr_restrict to the maximum setting rather than the minimum setting, to ensure that early boot logging is not leaking information. Signed-off-by: Tobin C. Harding --- lib/vsprintf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[kernel-hardening] [RFC V2 2/6] lib: vsprintf: whitelist stack traces

Use the %pP functionality to explicitly allow kernel pointers to be logged for stack traces. Signed-off-by: Tobin C. Harding --- arch/arm64/kernel/traps.c | 4 ++-- kernel/printk/printk.c| 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git

[kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

Set the initial value of kptr_restrict to the maximum setting rather than the minimum setting, to ensure that early boot logging is not leaking information. Signed-off-by: Tobin C. Harding --- lib/vsprintf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/vsprintf.c

[kernel-hardening] [RFC V2 2/6] lib: vsprintf: whitelist stack traces

Use the %pP functionality to explicitly allow kernel pointers to be logged for stack traces. Signed-off-by: Tobin C. Harding --- arch/arm64/kernel/traps.c | 4 ++-- kernel/printk/printk.c| 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/traps.c

[kernel-hardening] [RFC V2 6/6] drivers: uio: un-restrict sysfs pointers for UIO

The address and size on the UIO devices are required by userspace to function properly. Let's un-restrict these by adding the 'P' modifier to %pa. Signed-off-by: Tobin C. Harding --- drivers/uio/uio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[kernel-hardening] [RFC V2 3/6] lib: vsprintf: physical address kernel pointer filtering options

Add the kptr_restrict setting of 4 which results in %pa and %p[rR] values being cleansed. Address types printed with %pa are replaced by zeros. Resources printed with %p[rR] have the starting address replaced by zeros, resource size is still shown. Signed-off-by: Tobin C. Harding

[kernel-hardening] [RFC V2 6/6] drivers: uio: un-restrict sysfs pointers for UIO

The address and size on the UIO devices are required by userspace to function properly. Let's un-restrict these by adding the 'P' modifier to %pa. Signed-off-by: Tobin C. Harding --- drivers/uio/uio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/uio/uio.c

[kernel-hardening] [RFC V2 3/6] lib: vsprintf: physical address kernel pointer filtering options

Add the kptr_restrict setting of 4 which results in %pa and %p[rR] values being cleansed. Address types printed with %pa are replaced by zeros. Resources printed with %p[rR] have the starting address replaced by zeros, resource size is still shown. Signed-off-by: Tobin C. Harding ---

[kernel-hardening] [RFC V2 5/6] lib: vsprintf: add "%paP", "%papP", and "%padP" specifiers

Add %papP and %padP for address types that need to always be shown regardless of kptr restrictions. Add %paP is a synonym for %papP, this is inline with current implementation (%pa is a synonym for %pap). Signed-off-by: Tobin C. Harding --- Documentation/printk-formats.txt | 19

[kernel-hardening] [RFC V2 5/6] lib: vsprintf: add "%paP", "%papP", and "%padP" specifiers

Add %papP and %padP for address types that need to always be shown regardless of kptr restrictions. Add %paP is a synonym for %papP, this is inline with current implementation (%pa is a synonym for %pap). Signed-off-by: Tobin C. Harding --- Documentation/printk-formats.txt | 19

[kernel-hardening] [RFC V2 1/6] lib: vsprintf: additional kernel pointer filtering options

Add the kptr_restrict setting of 3 which results in both %p and %pK values being replaced by zeros. Add an additional %pP value inspired by the Grsecurity option which explicitly whitelists pointers for output. Amend scripts/checkpatch.pl to handle %pP. This patch is based on work by William

[kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options

Version 2 of Greg's patch series with changes made as suggested by comments to V1. Applies on top of Linus' current development tree a8c964eacb21288b2dbfa9d80cee5968a3b8fb21 V1 cover letter: Here's a short patch series from Chris Fries and Dave Weinstein that implements some new restrictions

[kernel-hardening] [RFC V2 1/6] lib: vsprintf: additional kernel pointer filtering options

Add the kptr_restrict setting of 3 which results in both %p and %pK values being replaced by zeros. Add an additional %pP value inspired by the Grsecurity option which explicitly whitelists pointers for output. Amend scripts/checkpatch.pl to handle %pP. This patch is based on work by William

[kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options

Version 2 of Greg's patch series with changes made as suggested by comments to V1. Applies on top of Linus' current development tree a8c964eacb21288b2dbfa9d80cee5968a3b8fb21 V1 cover letter: Here's a short patch series from Chris Fries and Dave Weinstein that implements some new restrictions

Re: [PATCH] drm: of: always initialize panel in drm_of_find_panel_or_bridge()

On Mon, Sep 25, 2017 at 12:30 PM, Dan Carpenter wrote: > The callers expect "panel" to be initialized, but that isn't true if we > return -ENODEV. It causes bugs like: > > drivers/gpu/drm/tve200/tve200_drv.c:83 tve200_modeset_init() > error: uninitialized

Re: [PATCH] drm: of: always initialize panel in drm_of_find_panel_or_bridge()

On Mon, Sep 25, 2017 at 12:30 PM, Dan Carpenter wrote: > The callers expect "panel" to be initialized, but that isn't true if we > return -ENODEV. It causes bugs like: > > drivers/gpu/drm/tve200/tve200_drv.c:83 tve200_modeset_init() > error: uninitialized symbol 'panel'. > >

Re: [PATCH V7 2/2] scsi: Align block queue to dma_get_cache_alignment()

Hi Huacai, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc2 next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH V7 2/2] scsi: Align block queue to dma_get_cache_alignment()

Hi Huacai, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc2 next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] KVM: VMX: check match table

On Wed, Sep 27, 2017 at 02:36:03PM +0200, Paolo Bonzini wrote: > On 26/09/2017 19:12, Josh Triplett wrote: > > Does this make any other checks redundant and removable? > > It would make sense to place it in cpu_has_kvm_support instead cpu_has_kvm_support() or cpu_has_vmx()? >, and the same in

Re: [PATCH] KVM: VMX: check match table

On Wed, Sep 27, 2017 at 02:36:03PM +0200, Paolo Bonzini wrote: > On 26/09/2017 19:12, Josh Triplett wrote: > > Does this make any other checks redundant and removable? > > It would make sense to place it in cpu_has_kvm_support instead cpu_has_kvm_support() or cpu_has_vmx()? >, and the same in

Re: [PATCH] kbuild: clang: remove crufty HOSTCFLAGS

On Thu, Sep 28, 2017 at 07:52:35PM +0900, Masahiro Yamada wrote: > 2017-09-26 11:28 GMT+09:00 Nick Desaulniers : > > HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ > > + $(call hostcc-option,-fno-delete-null-pointer-checks) \ > >

Re: [PATCH] kbuild: clang: remove crufty HOSTCFLAGS

On Thu, Sep 28, 2017 at 07:52:35PM +0900, Masahiro Yamada wrote: > 2017-09-26 11:28 GMT+09:00 Nick Desaulniers : > > HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ > > + $(call hostcc-option,-fno-delete-null-pointer-checks) \ > >

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Sat, Sep 30, 2017 at 10:57:38AM +0800, Bob Liu wrote: > On 2017/9/27 0:16, Jerome Glisse wrote: > > On Tue, Sep 26, 2017 at 05:56:26PM +0800, Bob Liu wrote: > >> On Tue, Sep 12, 2017 at 7:36 AM, Jerome Glisse wrote: > >>> On Sun, Sep 10, 2017 at 07:22:58AM +0800, Bob Liu

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Sat, Sep 30, 2017 at 10:57:38AM +0800, Bob Liu wrote: > On 2017/9/27 0:16, Jerome Glisse wrote: > > On Tue, Sep 26, 2017 at 05:56:26PM +0800, Bob Liu wrote: > >> On Tue, Sep 12, 2017 at 7:36 AM, Jerome Glisse wrote: > >>> On Sun, Sep 10, 2017 at 07:22:58AM +0800, Bob Liu wrote: > On Wed,

Re: [PATCH v3] Staging: rtl8723bs: Remove unnecessary comments.

On Sat, Sep 30, 2017 at 07:41:11PM +0530, Shreeya Patel wrote: > Remove unnecessary comments which are there > to explain why call to memset is in comments. Both of the > comments are not needed as they are not very useful. > > > Signed-off-by: Shreeya Patel > ---

Re: [PATCH v3] Staging: rtl8723bs: Remove unnecessary comments.

On Sat, Sep 30, 2017 at 07:41:11PM +0530, Shreeya Patel wrote: > Remove unnecessary comments which are there > to explain why call to memset is in comments. Both of the > comments are not needed as they are not very useful. > > > Signed-off-by: Shreeya Patel > --- > Changes in v2: > -Remove

Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

On Sat, Sep 30, 2017 at 04:17:39PM -0500, Brijesh Singh wrote: > I will take a closure look at this patch on Monday but at a glance I am > not sure if patch is addressing our main issue. We were trying to limit > the SEV feature exposure from the host OS. The current logic is: > > 1. Check

Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

On Sat, Sep 30, 2017 at 04:17:39PM -0500, Brijesh Singh wrote: > I will take a closure look at this patch on Monday but at a glance I am > not sure if patch is addressing our main issue. We were trying to limit > the SEV feature exposure from the host OS. The current logic is: > > 1. Check

Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

On 9/30/17 6:56 AM, Borislav Petkov wrote: ... > Ok, I went and simplified this whole code path a bit because it was > needlessly a bit too complex. Below is the result, only compile-tested. > > Brijesh, Tom, guys, please check my logic, I might've missed a case. I will take a closure look at

Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

On 9/30/17 6:56 AM, Borislav Petkov wrote: ... > Ok, I went and simplified this whole code path a bit because it was > needlessly a bit too complex. Below is the result, only compile-tested. > > Brijesh, Tom, guys, please check my logic, I might've missed a case. I will take a closure look at

Re: [PATCH v3 2/8] platform/x86: dell-smbios: Introduce a WMI-ACPI interface

On Saturday 30 September 2017 22:01:04 mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Pali Rohár [mailto:pali.ro...@gmail.com] > > Sent: Friday, September 29, 2017 2:36 AM > > To: Limonciello, Mario > > Cc: dvh...@infradead.org;

Re: [PATCH v3 2/8] platform/x86: dell-smbios: Introduce a WMI-ACPI interface

On Saturday 30 September 2017 22:01:04 mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Pali Rohár [mailto:pali.ro...@gmail.com] > > Sent: Friday, September 29, 2017 2:36 AM > > To: Limonciello, Mario > > Cc: dvh...@infradead.org; andy.shevche...@gmail.com; linux- > >

Re: [v1] iov_iter: fix page_copy_sane for compound pages

On Sat, Sep 30, 2017 at 12:24 PM, Thiago Macieira wrote: > On Tuesday, 29 August 2017 11:20:32 PDT Petar Penkov wrote: >> Issue is that if the data crosses a page boundary inside a compound >> page, this check will incorrectly trigger a WARN_ON. >> >> To fix this,

Re: [v1] iov_iter: fix page_copy_sane for compound pages

On Sat, Sep 30, 2017 at 12:24 PM, Thiago Macieira wrote: > On Tuesday, 29 August 2017 11:20:32 PDT Petar Penkov wrote: >> Issue is that if the data crosses a page boundary inside a compound >> page, this check will incorrectly trigger a WARN_ON. >> >> To fix this, compute the order using the head

Re: [PATCH] staging: iio: trigger: Move header file content to source file

On Tue, 26 Sep 2017 23:56:15 +0530 Harsha Sharma wrote: > The contents of the header file are used only by this single source file. > Moved content into iio-trig-bfin-timer.c and removed iio-trig-bfin-timer.h > > Signed-off-by: Harsha Sharma

Re: [PATCH] staging: iio: trigger: Move header file content to source file

On Tue, 26 Sep 2017 23:56:15 +0530 Harsha Sharma wrote: > The contents of the header file are used only by this single source file. > Moved content into iio-trig-bfin-timer.c and removed iio-trig-bfin-timer.h > > Signed-off-by: Harsha Sharma Hmm. This one again. Sometimes you need to not

Re: [PATCH 0/8] pinctrl: meson: clean pin offsets

Jerome Brunet writes: > The initial goal of this series was move to TEST_N pin from the EE > controller to AO controller, where it belongs. This meant modify the > EE_OFF value. > > This offset is a quirk we brought from the vendor driver when it was > initially merged.

Re: [PATCH 0/8] pinctrl: meson: clean pin offsets

Jerome Brunet writes: > The initial goal of this series was move to TEST_N pin from the EE > controller to AO controller, where it belongs. This meant modify the > EE_OFF value. > > This offset is a quirk we brought from the vendor driver when it was > initially merged.

Re: [PATCH 0/8] pinctrl: meson: clean pin offsets

Jerome Brunet writes: > The initial goal of this series was move to TEST_N pin from the EE > controller to AO controller, where it belongs. This meant modify the > EE_OFF value. > > This offset is a quirk we brought from the vendor driver when it was > initially merged. There no reason to keep

Re: [PATCH 0/8] pinctrl: meson: clean pin offsets

Jerome Brunet writes: > The initial goal of this series was move to TEST_N pin from the EE > controller to AO controller, where it belongs. This meant modify the > EE_OFF value. > > This offset is a quirk we brought from the vendor driver when it was > initially merged. There no reason to keep

Re: [PATCH v3 4/4] iio: light: vl6180: Correct ALS scale for non-default gain/integration time

On Sun, 24 Sep 2017 23:59:20 +0200 Stefan Brüns wrote: > The reported scale was only correct for the default settings of 100 ms > integration time and gain 1. > > This aligns the reported scale with the behaviour of any other IIO driver > and the documented ABI,

Re: [PATCH v3 4/4] iio: light: vl6180: Correct ALS scale for non-default gain/integration time

On Sun, 24 Sep 2017 23:59:20 +0200 Stefan Brüns wrote: > The reported scale was only correct for the default settings of 100 ms > integration time and gain 1. > > This aligns the reported scale with the behaviour of any other IIO driver > and the documented ABI, but may require userspace

Re: [PATCH v3 3/4] iio: light: vl6180: Cleanup als_gain lookup, avoid register readback

On Sun, 24 Sep 2017 23:59:19 +0200 Stefan Brüns wrote: > Instead of manually iterating the array of allowed gain values, use > find_closest. Storing the current gain setting avoids accessing the > hardware on each query. > > Signed-off-by: Stefan Brüns

Re: [PATCH v3 3/4] iio: light: vl6180: Cleanup als_gain lookup, avoid register readback

On Sun, 24 Sep 2017 23:59:19 +0200 Stefan Brüns wrote: > Instead of manually iterating the array of allowed gain values, use > find_closest. Storing the current gain setting avoids accessing the > hardware on each query. > > Signed-off-by: Stefan Brüns > Applied to the togreg branch of

Re: [PATCH v3 2/4] iio: light: vl6180: Avoid readback of integration time register

On Sun, 24 Sep 2017 23:59:18 +0200 Stefan Brüns wrote: > Instead of reading the value from the register on each query, store the > set value. > > Signed-off-by: Stefan Brüns Applied to the togreg branch of iio.git and pushed out as

Re: [PATCH v3 2/4] iio: light: vl6180: Avoid readback of integration time register

On Sun, 24 Sep 2017 23:59:18 +0200 Stefan Brüns wrote: > Instead of reading the value from the register on each query, store the > set value. > > Signed-off-by: Stefan Brüns Applied to the togreg branch of iio.git and pushed out as testing. Jonathan > > --- > > Changes in v3: > - Use

Re: [PATCH v3 1/4] iio: light: vl6180: Move range check to integration time setter, cleanup

On Sun, 24 Sep 2017 23:59:17 +0200 Stefan Brüns wrote: > This improves code uniformity (range checks for als_gain are also done > in the setter). Also unmangle rounding and calculation of register value. > > The calculated integration time it_ms is required in the

Re: [PATCH v3 1/4] iio: light: vl6180: Move range check to integration time setter, cleanup

On Sun, 24 Sep 2017 23:59:17 +0200 Stefan Brüns wrote: > This improves code uniformity (range checks for als_gain are also done > in the setter). Also unmangle rounding and calculation of register value. > > The calculated integration time it_ms is required in the next patch of > the series. >

Re: [lkp-robot] [blk] 47e0fb461f: BUG:unable_to_handle_kernel

On Thu, Sep 21, 2017 at 12:02 AM, NeilBrown wrote: > > I think it is crashing in > static inline bool ata_is_host_link(const struct ata_link *link) > { > return link == >ap->link || link == link->ap->slave_link; > } Yes. The code is 1a: 8b 3amov

Re: [lkp-robot] [blk] 47e0fb461f: BUG:unable_to_handle_kernel

On Thu, Sep 21, 2017 at 12:02 AM, NeilBrown wrote: > > I think it is crashing in > static inline bool ata_is_host_link(const struct ata_link *link) > { > return link == >ap->link || link == link->ap->slave_link; > } Yes. The code is 1a: 8b 3amov(%edx),%edi 1c: 8d

Re: [v1] iov_iter: fix page_copy_sane for compound pages

On Tuesday, 29 August 2017 11:20:32 PDT Petar Penkov wrote: > Issue is that if the data crosses a page boundary inside a compound > page, this check will incorrectly trigger a WARN_ON. > > To fix this, compute the order using the head of the compound page and > adjust the offset to be relative to

Re: [v1] iov_iter: fix page_copy_sane for compound pages

On Tuesday, 29 August 2017 11:20:32 PDT Petar Penkov wrote: > Issue is that if the data crosses a page boundary inside a compound > page, this check will incorrectly trigger a WARN_ON. > > To fix this, compute the order using the head of the compound page and > adjust the offset to be relative to

  1   2   3   4   5   >