Re: [PATCH v2 09/15] NTB: ntb_test: Update ntb_tool link tests

On Tue, Dec 05, 2017 at 01:26:29PM -0500, Jon Mason wrote: > On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote: > > Link Up and Down methods are used to change NTB link settings on > > local side only for multi-port devices. Link is considered up > >

Re: [PATCH v2 09/15] NTB: ntb_test: Update ntb_tool link tests

On Tue, Dec 05, 2017 at 01:26:29PM -0500, Jon Mason wrote: > On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote: > > Link Up and Down methods are used to change NTB link settings on > > local side only for multi-port devices. Link is considered up > > only if both sides local and peer set it up.

[PATCH net-next v2 3/5] net: dsa: mv88e6xxx: setup global upstream port

Move the setup of the global upstream port within the mv88e6xxx_setup_upstream_port function. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 29 - 1 file changed, 16 insertions(+), 13 deletions(-) diff --git

[PATCH net-next v2 3/5] net: dsa: mv88e6xxx: setup global upstream port

Move the setup of the global upstream port within the mv88e6xxx_setup_upstream_port function. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 29 - 1 file changed, 16 insertions(+), 13 deletions(-) diff --git a/drivers/net/dsa/mv88e6xxx/chip.c

[PATCH net-next v2 2/5] net: dsa: mv88e6xxx: helper to setup upstream port

Add a helper function to setup the upstream port of a given port. This is the port used to reach the dedicated CPU port. This function will be extended later to setup the global upstream port as well. Signed-off-by: Vivien Didelot ---

[PATCH net-next v2 2/5] net: dsa: mv88e6xxx: helper to setup upstream port

Add a helper function to setup the upstream port of a given port. This is the port used to reach the dedicated CPU port. This function will be extended later to setup the global upstream port as well. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 27

[PATCH net-next v2 0/5] net: dsa: use per-port upstream port

An upstream port is a local switch port used to reach a CPU port. DSA still considers a unique CPU port in the whole switch fabric and thus return a unique upstream port for a given switch. This is wrong in a multiple CPU ports environment. We are now switching to using the dedicated CPU port

[PATCH net-next v2 0/5] net: dsa: use per-port upstream port

An upstream port is a local switch port used to reach a CPU port. DSA still considers a unique CPU port in the whole switch fabric and thus return a unique upstream port for a given switch. This is wrong in a multiple CPU ports environment. We are now switching to using the dedicated CPU port

[PATCH net-next v2 4/5] net: dsa: assign a CPU port to DSA port

DSA ports also need to have a dedicated CPU port assigned to them, because they need to know where to egress frames targeting the CPU, e.g. To_Cpu frames received on a Marvell Tag port. Signed-off-by: Vivien Didelot --- net/dsa/dsa2.c | 2 +- 1 file changed,

[PATCH net-next v2 4/5] net: dsa: assign a CPU port to DSA port

DSA ports also need to have a dedicated CPU port assigned to them, because they need to know where to egress frames targeting the CPU, e.g. To_Cpu frames received on a Marvell Tag port. Signed-off-by: Vivien Didelot --- net/dsa/dsa2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH net-next v2 5/5] net: dsa: return per-port upstream port

The current dsa_upstream_port() helper still assumes a unique CPU port in the whole switch fabric. This is becoming wrong, as every port in the fabric has its dedicated CPU port, thus every port has an upstream port. Add a port argument to the dsa_upstream_port() helper and fetch its CPU port

[PATCH net-next v2 1/5] net: dsa: mv88e6xxx: egress floods all DSA ports

The mv88e6xxx driver currently assumes a single CPU port in the fabric and thus floods frames with unknown DA on a single DSA port, the one that is one hop closer to the CPU port. With multiple CPU ports in mind, this isn't true anymore because CPU ports could be found behind both DSA ports of a

[PATCH net-next v2 5/5] net: dsa: return per-port upstream port

The current dsa_upstream_port() helper still assumes a unique CPU port in the whole switch fabric. This is becoming wrong, as every port in the fabric has its dedicated CPU port, thus every port has an upstream port. Add a port argument to the dsa_upstream_port() helper and fetch its CPU port

[PATCH net-next v2 1/5] net: dsa: mv88e6xxx: egress floods all DSA ports

The mv88e6xxx driver currently assumes a single CPU port in the fabric and thus floods frames with unknown DA on a single DSA port, the one that is one hop closer to the CPU port. With multiple CPU ports in mind, this isn't true anymore because CPU ports could be found behind both DSA ports of a

Re: [PATCH] ocfs2: use get_task_comm

On Tue, Dec 5, 2017 at 12:27 PM, Arnd Bergmann wrote: > On Tue, Dec 5, 2017 at 8:19 PM, Kees Cook wrote: >> On Tue, Dec 5, 2017 at 7:20 AM, Arnd Bergmann wrote: >>> While reviewing all callers of get_task_comm(), I stumbled >>> over this one

Re: [PATCH] ocfs2: use get_task_comm

On Tue, Dec 5, 2017 at 12:27 PM, Arnd Bergmann wrote: > On Tue, Dec 5, 2017 at 8:19 PM, Kees Cook wrote: >> On Tue, Dec 5, 2017 at 7:20 AM, Arnd Bergmann wrote: >>> While reviewing all callers of get_task_comm(), I stumbled >>> over this one that claimed it was not exported, when in fact >>> it

Re: [PATCH] leds: blinkm: avoid uninitialized data use

Hi Arnd, Thanks for the patch. On 12/04/2017 03:45 PM, Arnd Bergmann wrote: > gcc-8 reports missing error handling in blinkm_detect, when blinkm() > fails, tmpargs[] is uninitialized: > > drivers/leds/leds-blinkm.c: In function 'blinkm_detect': > drivers/leds/leds-blinkm.c:555:6: error:

Re: [PATCH] leds: blinkm: avoid uninitialized data use

Hi Arnd, Thanks for the patch. On 12/04/2017 03:45 PM, Arnd Bergmann wrote: > gcc-8 reports missing error handling in blinkm_detect, when blinkm() > fails, tmpargs[] is uninitialized: > > drivers/leds/leds-blinkm.c: In function 'blinkm_detect': > drivers/leds/leds-blinkm.c:555:6: error:

Re: [PATCH V11 3/5] printk: hash addresses printed with %p

From: Geert Uytterhoeven Date: Tue, 5 Dec 2017 21:20:57 +0100 > Hi Tobin, > > On Wed, Nov 29, 2017 at 3:05 AM, Tobin C. Harding wrote: >> Currently there exist approximately 14 000 places in the kernel where >> addresses are being printed using an unadorned

Re: [PATCH V11 3/5] printk: hash addresses printed with %p

From: Geert Uytterhoeven Date: Tue, 5 Dec 2017 21:20:57 +0100 > Hi Tobin, > > On Wed, Nov 29, 2017 at 3:05 AM, Tobin C. Harding wrote: >> Currently there exist approximately 14 000 places in the kernel where >> addresses are being printed using an unadorned %p. This potentially >> leaks

Re: [PATCH 1/2] [RFC] kbuild: add macro for controlling warnings to linux/compiler.h

On Tue, Dec 5, 2017 at 8:25 PM, Kees Cook wrote: > I like this. I wonder if it would be a good idea to add an additional > argument that forces documentation of the reason for adding a diag > marking? Something like: > > __diag_warn(GCC_7, vla, "No VLAs should be used in

Re: [PATCH 1/2] [RFC] kbuild: add macro for controlling warnings to linux/compiler.h

On Tue, Dec 5, 2017 at 8:25 PM, Kees Cook wrote: > I like this. I wonder if it would be a good idea to add an additional > argument that forces documentation of the reason for adding a diag > marking? Something like: > > __diag_warn(GCC_7, vla, "No VLAs should be used in this code"); This would

[PATCH 4/4] uwb/i1480/dfu/usb: Delete two error messages for a failed memory allocation in i1480_usb_probe()

From: Markus Elfring Date: Tue, 5 Dec 2017 21:07:47 +0100 Omit extra messages for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 4/4] uwb/i1480/dfu/usb: Delete two error messages for a failed memory allocation in i1480_usb_probe()

From: Markus Elfring Date: Tue, 5 Dec 2017 21:07:47 +0100 Omit extra messages for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/uwb/i1480/dfu/usb.c | 4 +--- 1 file changed, 1 insertion(+), 3

[PATCH 3/4] uwb/i1480/dfu/mac: Delete an error message for a failed memory allocation in fw_hdrs_load()

From: Markus Elfring Date: Tue, 5 Dec 2017 21:00:03 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

Re: [PATCH v2 06/15] NTB: ntb_perf: Add full multi-port NTB API support

On Tue, Dec 05, 2017 at 01:21:24PM -0500, Jon Mason wrote: > On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote: > > NTB API has been updated to support multi-port devices like IDT > > 89HPESx series or Microsemi Switchtec. Message registers > >

[PATCH 3/4] uwb/i1480/dfu/mac: Delete an error message for a failed memory allocation in fw_hdrs_load()

From: Markus Elfring Date: Tue, 5 Dec 2017 21:00:03 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/uwb/i1480/dfu/mac.c | 4 +--- 1 file changed, 1 insertion(+),

Re: [PATCH v2 06/15] NTB: ntb_perf: Add full multi-port NTB API support

On Tue, Dec 05, 2017 at 01:21:24PM -0500, Jon Mason wrote: > On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote: > > NTB API has been updated to support multi-port devices like IDT > > 89HPESx series or Microsemi Switchtec. Message registers > > functionality has also been added to new API. In

Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()

On Tue, Dec 05, 2017 at 08:57:52PM +0100, Peter Zijlstra wrote: > On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote: > > > > WRITE_ONCE(obj->val, 1); > > > > smp_wmb(); > > > > WRITE_ONCE(*foo, obj); > > > > > > I believe Peter was instead suggesting: > > > > > >

Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()

On Tue, Dec 05, 2017 at 08:57:52PM +0100, Peter Zijlstra wrote: > On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote: > > > > WRITE_ONCE(obj->val, 1); > > > > smp_wmb(); > > > > WRITE_ONCE(*foo, obj); > > > > > > I believe Peter was instead suggesting: > > > > > >

[PATCH 2/4] uwb: Delete an error message for a failed memory allocation in whcrc_probe()

From: Markus Elfring Date: Tue, 5 Dec 2017 20:43:31 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 2/4] uwb: Delete an error message for a failed memory allocation in whcrc_probe()

From: Markus Elfring Date: Tue, 5 Dec 2017 20:43:31 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/uwb/whc-rc.c | 5 ++--- 1 file changed, 2 insertions(+), 3

Re: [PATCH] checkpatch: warn for use of %px

On Tue, Dec 05, 2017 at 07:27:18AM -0800, Joe Perches wrote: > On Tue, 2017-12-05 at 20:44 +1100, Tobin C. Harding wrote: > > On Mon, Dec 04, 2017 at 11:24:24PM -0800, Joe Perches wrote: > > > On Tue, 2017-12-05 at 08:17 +1100, Tobin C. Harding wrote: > > > > Usage of the new %px specifier

Re: [PATCH] checkpatch: warn for use of %px

On Tue, Dec 05, 2017 at 07:27:18AM -0800, Joe Perches wrote: > On Tue, 2017-12-05 at 20:44 +1100, Tobin C. Harding wrote: > > On Mon, Dec 04, 2017 at 11:24:24PM -0800, Joe Perches wrote: > > > On Tue, 2017-12-05 at 08:17 +1100, Tobin C. Harding wrote: > > > > Usage of the new %px specifier

Re: [PATCH] ocfs2: use get_task_comm

On Tue, Dec 5, 2017 at 8:19 PM, Kees Cook wrote: > On Tue, Dec 5, 2017 at 7:20 AM, Arnd Bergmann wrote: >> While reviewing all callers of get_task_comm(), I stumbled >> over this one that claimed it was not exported, when in fact >> it is. Accessing

[PATCH 1/4] uwb: Delete an error message for a failed memory allocation in hwarc_probe()

From: Markus Elfring Date: Tue, 5 Dec 2017 20:30:50 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

Re: [PATCH] ocfs2: use get_task_comm

On Tue, Dec 5, 2017 at 8:19 PM, Kees Cook wrote: > On Tue, Dec 5, 2017 at 7:20 AM, Arnd Bergmann wrote: >> While reviewing all callers of get_task_comm(), I stumbled >> over this one that claimed it was not exported, when in fact >> it is. Accessing task->comm directly is not safe, so better >>

[PATCH 1/4] uwb: Delete an error message for a failed memory allocation in hwarc_probe()

From: Markus Elfring Date: Tue, 5 Dec 2017 20:30:50 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/uwb/hwa-rc.c | 5 ++--- 1 file changed, 2 insertions(+), 3

[PATCH 0/4] UWB: Adjustments for four function implementations

From: Markus Elfring Date: Tue, 5 Dec 2017 21:17:55 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (4): Delete an error message for a failed memory allocation in hwarc_probe() Delete an error message for

[PATCH 0/4] UWB: Adjustments for four function implementations

From: Markus Elfring Date: Tue, 5 Dec 2017 21:17:55 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (4): Delete an error message for a failed memory allocation in hwarc_probe() Delete an error message for a failed memory allocation in

Re: [PATCH V11 3/5] printk: hash addresses printed with %p

Hi Tobin, On Wed, Nov 29, 2017 at 3:05 AM, Tobin C. Harding wrote: > Currently there exist approximately 14 000 places in the kernel where > addresses are being printed using an unadorned %p. This potentially > leaks sensitive information regarding the Kernel layout in memory.

Re: [PATCH V11 3/5] printk: hash addresses printed with %p

Hi Tobin, On Wed, Nov 29, 2017 at 3:05 AM, Tobin C. Harding wrote: > Currently there exist approximately 14 000 places in the kernel where > addresses are being printed using an unadorned %p. This potentially > leaks sensitive information regarding the Kernel layout in memory. Many > of these

Re: [PATCH v2] drivers:mtd:spi-nor:checkup FSR error bits

Le 04/12/2017 à 14:27, Bean Huo (beanhuo) a écrit : > Hi, Cyrille > >> Hi Bean, >> >> Le 04/12/2017 à 13:34, Bean Huo (beanhuo) a écrit : >>> For Micron spi nor device, when erase/program operation fails, >>> especially the failure results from intending to modify protected >>> space, spi-nor

Re: [PATCH v2] drivers:mtd:spi-nor:checkup FSR error bits

Le 04/12/2017 à 14:27, Bean Huo (beanhuo) a écrit : > Hi, Cyrille > >> Hi Bean, >> >> Le 04/12/2017 à 13:34, Bean Huo (beanhuo) a écrit : >>> For Micron spi nor device, when erase/program operation fails, >>> especially the failure results from intending to modify protected >>> space, spi-nor

[PATCH 2/2] net: macb: kill useless use of list_empty()

The list_for_each_entry() macro already handles the case where the list is empty (by not executing the loop body). It's not necessary to handle this case specially, so stop doing so. Cc: Rafal Ozieblo Signed-off-by: Julia Cartwright --- This is an additional

[PATCH 2/2] net: macb: kill useless use of list_empty()

The list_for_each_entry() macro already handles the case where the list is empty (by not executing the loop body). It's not necessary to handle this case specially, so stop doing so. Cc: Rafal Ozieblo Signed-off-by: Julia Cartwright --- This is an additional cleanup patch found when looking at

Re: [PATCH] HID: elecom: rewrite report fixup for EX-G and future mice

On Mon, Dec 04, 2017 at 08:55:50PM +, Tomasz Kramkowski wrote: > +static void mouse_button_fixup(struct hid_device *hdev, > +__u8 *rdesc, unsigned int *rsize, > +int nbuttons) I've just remembered what has been bugging me yesterday when

Re: [PATCH] HID: elecom: rewrite report fixup for EX-G and future mice

On Mon, Dec 04, 2017 at 08:55:50PM +, Tomasz Kramkowski wrote: > +static void mouse_button_fixup(struct hid_device *hdev, > +__u8 *rdesc, unsigned int *rsize, > +int nbuttons) I've just remembered what has been bugging me yesterday when

[PATCH 1/2] net: macb: reduce scope of rx_fs_lock-protected regions

Commit ae8223de3df5 ("net: macb: Added support for RX filtering") introduces a lock, rx_fs_lock which is intended to protect the list of rx_flow items and synchronize access to the hardware rx filtering registers. However, the region protected by this lock is overscoped, unnecessarily including

[PATCH 1/2] net: macb: reduce scope of rx_fs_lock-protected regions

Commit ae8223de3df5 ("net: macb: Added support for RX filtering") introduces a lock, rx_fs_lock which is intended to protect the list of rx_flow items and synchronize access to the hardware rx filtering registers. However, the region protected by this lock is overscoped, unnecessarily including

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

On Tue, Dec 5, 2017 at 12:09 PM, Russell King - ARM Linux wrote: > On Tue, Dec 05, 2017 at 11:35:59AM -0800, Kees Cook wrote: >> We don't _need_ to, but they're all contiguous, so the ro_perms array >> used by set_kernel_text_*() is actually only a single entry: >> >>

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

On Tue, Dec 5, 2017 at 12:09 PM, Russell King - ARM Linux wrote: > On Tue, Dec 05, 2017 at 11:35:59AM -0800, Kees Cook wrote: >> We don't _need_ to, but they're all contiguous, so the ro_perms array >> used by set_kernel_text_*() is actually only a single entry: >> >> static struct section_perm

Re: [RFC PATCH 1/6] drm: Add Content Protection property

Hi Pavel, On 5 December 2017 at 17:34, Pavel Machek wrote: > Yes, so... This patch makes it more likely to see machines with locked > down kernels, preventing developers from working with systems their > own, running hardware. That is evil, and direct threat to Free > software

Re: [RFC PATCH 1/6] drm: Add Content Protection property

Hi Pavel, On 5 December 2017 at 17:34, Pavel Machek wrote: > Yes, so... This patch makes it more likely to see machines with locked > down kernels, preventing developers from working with systems their > own, running hardware. That is evil, and direct threat to Free > software movement. > >

Re: [PATCH v3 net-next] net/tcp: trace all TCP/IP state transition with tcp_set_state tracepoint

From: Yafang Shao Date: Tue, 5 Dec 2017 14:12:42 + > } > > +/* For tcp_set_state tracepoint */ > +void sk_state_store(struct sock *sk, int newstate); > + > void sock_enable_timestamp(struct sock *sk, int flag); > int sock_get_timestamp(struct sock *, struct

Re: [PATCH v3 net-next] net/tcp: trace all TCP/IP state transition with tcp_set_state tracepoint

From: Yafang Shao Date: Tue, 5 Dec 2017 14:12:42 + > } > > +/* For tcp_set_state tracepoint */ > +void sk_state_store(struct sock *sk, int newstate); > + > void sock_enable_timestamp(struct sock *sk, int flag); > int sock_get_timestamp(struct sock *, struct timeval __user *); > int

Re: [PATCH 0/2] Switchtec Updates

On Wed, Nov 29, 2017 at 10:28:42AM -0700, Logan Gunthorpe wrote: > Hi Bjorn, > > Blease accept the following two patches. The first adds a couple more > device IDs for the Switchtec driver. The second adds a new event type > for it to report. > > Thanks, > > Logan > > Kelvin Cao (1): >

Re: [PATCH 0/2] Switchtec Updates

On Wed, Nov 29, 2017 at 10:28:42AM -0700, Logan Gunthorpe wrote: > Hi Bjorn, > > Blease accept the following two patches. The first adds a couple more > device IDs for the Switchtec driver. The second adds a new event type > for it to report. > > Thanks, > > Logan > > Kelvin Cao (1): >

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

On Tue, Dec 05, 2017 at 11:35:59AM -0800, Kees Cook wrote: > We don't _need_ to, but they're all contiguous, so the ro_perms array > used by set_kernel_text_*() is actually only a single entry: > > static struct section_perm ro_perms[] = { > /* Make kernel code and rodata RX (set RO). */

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

On Tue, Dec 05, 2017 at 11:35:59AM -0800, Kees Cook wrote: > We don't _need_ to, but they're all contiguous, so the ro_perms array > used by set_kernel_text_*() is actually only a single entry: > > static struct section_perm ro_perms[] = { > /* Make kernel code and rodata RX (set RO). */

Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()

On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote: > On Tue, Dec 05, 2017 at 11:33:39AM -0800, Paul E. McKenney wrote: > > On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: [ . . . ] > > > and this barrier is no longer paired with anything until > > > you

Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()

On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote: > On Tue, Dec 05, 2017 at 11:33:39AM -0800, Paul E. McKenney wrote: > > On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: [ . . . ] > > > and this barrier is no longer paired with anything until > > > you

Re: [PATCH v1] PCI: Remove PCI_REASSIGN_ALL_RSRC use on arm and arm64

On Thu, Nov 30, 2017 at 02:15:05PM -0600, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > On arm, PCI_REASSIGN_ALL_RSRC is used only in pcibios_assign_all_busses(), > which helps decide whether to reconfigure bridge bus numbers. It has > nothing to do with BAR assignments.

Re: [PATCH v1] PCI: Remove PCI_REASSIGN_ALL_RSRC use on arm and arm64

On Thu, Nov 30, 2017 at 02:15:05PM -0600, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > On arm, PCI_REASSIGN_ALL_RSRC is used only in pcibios_assign_all_busses(), > which helps decide whether to reconfigure bridge bus numbers. It has > nothing to do with BAR assignments. On arm64 and powerpc,

Re: [PATCH tip/core/rcu 16/21] drivers/infiniband: Remove now-redundant smp_read_barrier_depends()

On Tue, Dec 05, 2017 at 08:08:32AM -0700, Jason Gunthorpe wrote: > > commit c389c98ec5f4a7aa4c36853e89801eb5ea81870e > > Author: Paul E. McKenney > > Date: Mon Nov 27 09:04:22 2017 -0800 > > > > drivers/infiniband: Remove now-redundant smp_read_barrier_depends()

Re: [PATCH tip/core/rcu 16/21] drivers/infiniband: Remove now-redundant smp_read_barrier_depends()

On Tue, Dec 05, 2017 at 08:08:32AM -0700, Jason Gunthorpe wrote: > > commit c389c98ec5f4a7aa4c36853e89801eb5ea81870e > > Author: Paul E. McKenney > > Date: Mon Nov 27 09:04:22 2017 -0800 > > > > drivers/infiniband: Remove now-redundant smp_read_barrier_depends() > > > > The

Re: [PATCH] dt: bindings: as3645a: Fix the example node

+Sakari driver maintainer On 12/05/2017 07:36 AM, Dan Murphy wrote: > Fix the address-cells and size-cells example node > to reflect to the correct representation. > > Signed-off-by: Dan Murphy > --- > Documentation/devicetree/bindings/leds/ams,as3645a.txt | 4 ++-- > 1 file

Re: [PATCH] dt: bindings: as3645a: Fix the example node

+Sakari driver maintainer On 12/05/2017 07:36 AM, Dan Murphy wrote: > Fix the address-cells and size-cells example node > to reflect to the correct representation. > > Signed-off-by: Dan Murphy > --- > Documentation/devicetree/bindings/leds/ams,as3645a.txt | 4 ++-- > 1 file changed, 2

Re: [PATCH v2 05/15] NTB: ntb_tool: Add full multi-port NTB API support

On Tue, Dec 05, 2017 at 01:03:25PM -0500, Jon Mason wrote: > On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote: > > NTB API has been updated to support multi-port devices like IDT > > 89HPESx series or Microsemi Switchtec. Message registers > >

Re: [PATCH v2 05/15] NTB: ntb_tool: Add full multi-port NTB API support

On Tue, Dec 05, 2017 at 01:03:25PM -0500, Jon Mason wrote: > On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote: > > NTB API has been updated to support multi-port devices like IDT > > 89HPESx series or Microsemi Switchtec. Message registers > > functionality has also been added to new API. In

Re: [PATCH 2/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks

Hi, On Mon, Dec 04, 2017 at 01:19:12PM +0800, Chen-Yu Tsai wrote: > On the A64, the MMC module clocks are fixed in the new timing mode, > i.e. they do not have a bit to select the mode. These clocks have > a 2x divider somewhere between the clock and the MMC module. > > To be consistent with

Re: [PATCH 2/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks

Hi, On Mon, Dec 04, 2017 at 01:19:12PM +0800, Chen-Yu Tsai wrote: > On the A64, the MMC module clocks are fixed in the new timing mode, > i.e. they do not have a bit to select the mode. These clocks have > a 2x divider somewhere between the clock and the MMC module. > > To be consistent with

Re: [PATCH v6 5/6] leds: lp8860: Update the LED label generation

Jacek On 12/05/2017 01:56 PM, Jacek Anaszewski wrote: > Dan, > > On 12/04/2017 02:11 PM, Dan Murphy wrote: >> Jacek >> >> On 12/03/2017 07:57 AM, Jacek Anaszewski wrote: >>> Dan, >>> >>> On 12/01/2017 05:56 PM, Dan Murphy wrote: Fix the LED label generation for the LP8860 to conform

Re: [PATCH v6 5/6] leds: lp8860: Update the LED label generation

Jacek On 12/05/2017 01:56 PM, Jacek Anaszewski wrote: > Dan, > > On 12/04/2017 02:11 PM, Dan Murphy wrote: >> Jacek >> >> On 12/03/2017 07:57 AM, Jacek Anaszewski wrote: >>> Dan, >>> >>> On 12/01/2017 05:56 PM, Dan Murphy wrote: Fix the LED label generation for the LP8860 to conform

Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()

On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote: > > > WRITE_ONCE(obj->val, 1); > > > smp_wmb(); > > > WRITE_ONCE(*foo, obj); > > > > I believe Peter was instead suggesting: > > > > WRITE_ONCE(obj->val, 1); > > smp_store_release(foo, obj); > > Isn't that more expensive

Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()

On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote: > > > WRITE_ONCE(obj->val, 1); > > > smp_wmb(); > > > WRITE_ONCE(*foo, obj); > > > > I believe Peter was instead suggesting: > > > > WRITE_ONCE(obj->val, 1); > > smp_store_release(foo, obj); > > Isn't that more expensive

Re: [PATCH v6 5/6] leds: lp8860: Update the LED label generation

Dan, On 12/04/2017 02:11 PM, Dan Murphy wrote: > Jacek > > On 12/03/2017 07:57 AM, Jacek Anaszewski wrote: >> Dan, >> >> On 12/01/2017 05:56 PM, Dan Murphy wrote: >>> Fix the LED label generation for the LP8860 to >>> conform with the >>> >>> Documentation/devicetree/bindings/leds/common.txt >>>

Re: general protection fault in show_timer

On Thu, Nov 30, 2017 at 4:57 AM, Thomas Gleixner wrote: > On Thu, 30 Nov 2017, Alexey Dobriyan wrote: > >> [cc security@] >> 100% oops with interrupts disabled by nobody >> or kernel memory read >> [nods] >> you named the bug already >> >> "notify" directly comes from

Re: [PATCH v6 5/6] leds: lp8860: Update the LED label generation

Dan, On 12/04/2017 02:11 PM, Dan Murphy wrote: > Jacek > > On 12/03/2017 07:57 AM, Jacek Anaszewski wrote: >> Dan, >> >> On 12/01/2017 05:56 PM, Dan Murphy wrote: >>> Fix the LED label generation for the LP8860 to >>> conform with the >>> >>> Documentation/devicetree/bindings/leds/common.txt >>>

Re: general protection fault in show_timer

On Thu, Nov 30, 2017 at 4:57 AM, Thomas Gleixner wrote: > On Thu, 30 Nov 2017, Alexey Dobriyan wrote: > >> [cc security@] >> 100% oops with interrupts disabled by nobody >> or kernel memory read >> [nods] >> you named the bug already >> >> "notify" directly comes from userspace struct

Re: [PATCH net-next 0/5] net: dsa: use per-port upstream port

Hi David, David Miller writes: > From: Vivien Didelot > Date: Mon, 4 Dec 2017 12:34:52 -0500 > >> An upstream port is a local switch port used to reach a CPU port. >> >> DSA still considers a unique CPU port in the whole switch fabric

Re: [PATCH net-next 0/5] net: dsa: use per-port upstream port

Hi David, David Miller writes: > From: Vivien Didelot > Date: Mon, 4 Dec 2017 12:34:52 -0500 > >> An upstream port is a local switch port used to reach a CPU port. >> >> DSA still considers a unique CPU port in the whole switch fabric and >> thus return a unique upstream port for a given

Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()

On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: > On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote: > > On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote: > > > > > I don't see WRITE_ONCE inserting any barriers, release or > > > write. > > > >

Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()

On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: > On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote: > > On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote: > > > > > I don't see WRITE_ONCE inserting any barriers, release or > > > write. > > > >

Re: [kernel-hardening][PATCH v3 0/3] arm: Makes ptdump resuable and add WX page checking

On Mon, Dec 4, 2017 at 6:24 AM, Jinbum Park wrote: > Hi, > > Page table dumping code for arm64-x86 is reusable, > and they have function for WX page checking. > But arm doesn't have that. > > This path series are to makes ptdump reusable, > and add WX page checking for arm.

Re: [kernel-hardening][PATCH v3 0/3] arm: Makes ptdump resuable and add WX page checking

On Mon, Dec 4, 2017 at 6:24 AM, Jinbum Park wrote: > Hi, > > Page table dumping code for arm64-x86 is reusable, > and they have function for WX page checking. > But arm doesn't have that. > > This path series are to makes ptdump reusable, > and add WX page checking for arm. > This is heavily

Re: [PATCH 5/7] ntb_hw_switchtec: Expand PFF CSR registers

On Tue, Dec 5, 2017 at 2:40 PM, Logan Gunthorpe wrote: > > > On 05/12/17 12:12 PM, Jon Mason wrote: >> >> It sucks that we don't already have a struct for PCI config space we >> can reuse here. If you find the time, it would be good to add in the >> future to reduce

Re: [PATCH 5/7] ntb_hw_switchtec: Expand PFF CSR registers

On Tue, Dec 5, 2017 at 2:40 PM, Logan Gunthorpe wrote: > > > On 05/12/17 12:12 PM, Jon Mason wrote: >> >> It sucks that we don't already have a struct for PCI config space we >> can reuse here. If you find the time, it would be good to add in the >> future to reduce duplicate code here and in

Re: [kernel-hardening][PATCH v3 2/3] arm: mm: dump: make the page table dumping seq_file optional

On Mon, Dec 4, 2017 at 6:26 AM, Jinbum Park wrote: > This patch makes the page table dumping seq_file optional. > It makes the page table dumping code usable for other cases. > > This patch refers below commit of arm64. > (ae5d1cf358a5 > ("arm64: dump: Make the page table

Re: [kernel-hardening][PATCH v3 2/3] arm: mm: dump: make the page table dumping seq_file optional

On Mon, Dec 4, 2017 at 6:26 AM, Jinbum Park wrote: > This patch makes the page table dumping seq_file optional. > It makes the page table dumping code usable for other cases. > > This patch refers below commit of arm64. > (ae5d1cf358a5 > ("arm64: dump: Make the page table dumping seq_file

Re: [PATCH v2 04/15] NTB: ntb_pp: Add full multi-port NTB API support

On Tue, Dec 05, 2017 at 12:02:13PM -0500, Jon Mason wrote: > On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote: > > NTB API has been updated to support multi-port devices like IDT > > 89HPESx series or Microsemi Switchtec. Message registers > >

Re: [PATCH v2 04/15] NTB: ntb_pp: Add full multi-port NTB API support

On Tue, Dec 05, 2017 at 12:02:13PM -0500, Jon Mason wrote: > On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote: > > NTB API has been updated to support multi-port devices like IDT > > 89HPESx series or Microsemi Switchtec. Message registers > > functionality has also been added to new API. In

Re: [kernel-hardening][PATCH v3 1/3] arm: mm: dump: make page table dumping reusable

On Mon, Dec 4, 2017 at 6:25 AM, Jinbum Park wrote: > This patch refactors the arm page table dumping code, > so multiple tables may be registered with the framework. > > This patch refers below commits of arm64. > (4674fdb9f149 ("arm64: mm: dump: make page table dumping

Re: [PATCH/RFC] DT: leds: Fix 'label' property description and add 'colour' property

Hi Pavel, On 12/04/2017 11:43 AM, Pavel Machek wrote: > Hi! > >> Label property was imposed a uniqueness requirement, which was erroneous, >> since ePAPR defines it to "a human readable string describing a device". >> >> Also the binding description misleadingly suggested direct usage of label

Re: [kernel-hardening][PATCH v3 1/3] arm: mm: dump: make page table dumping reusable

On Mon, Dec 4, 2017 at 6:25 AM, Jinbum Park wrote: > This patch refactors the arm page table dumping code, > so multiple tables may be registered with the framework. > > This patch refers below commits of arm64. > (4674fdb9f149 ("arm64: mm: dump: make page table dumping reusable")) >

Re: [PATCH/RFC] DT: leds: Fix 'label' property description and add 'colour' property

Hi Pavel, On 12/04/2017 11:43 AM, Pavel Machek wrote: > Hi! > >> Label property was imposed a uniqueness requirement, which was erroneous, >> since ePAPR defines it to "a human readable string describing a device". >> >> Also the binding description misleadingly suggested direct usage of label

Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()

On Tue, Dec 05, 2017 at 11:33:39AM -0800, Paul E. McKenney wrote: > On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: > > On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote: > > > On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote: > > > > > > > I

Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()

On Tue, Dec 05, 2017 at 11:33:39AM -0800, Paul E. McKenney wrote: > On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: > > On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote: > > > On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote: > > > > > > > I

[RFC PATCH v3 3/7] ktask: add /proc/sys/debug/ktask_max_threads

Adds a proc file to control the maximum number of ktask threads in use for any one job. Its primary use is to aid in debugging. Signed-off-by: Daniel Jordan Reviewed-by: Steve Sistare Cc: Aaron Lu Cc: Andrew Morton

[RFC PATCH v3 3/7] ktask: add /proc/sys/debug/ktask_max_threads

Adds a proc file to control the maximum number of ktask threads in use for any one job. Its primary use is to aid in debugging. Signed-off-by: Daniel Jordan Reviewed-by: Steve Sistare Cc: Aaron Lu Cc: Andrew Morton Cc: Dave Hansen Cc: Mel Gorman Cc: Michal Hocko Cc: Mike Kravetz Cc:

<    5   6   7   8   9   10   11   12   13   14   >