[PATCH v2 0/2] net: stmmac: dwmac-meson: 100M phy mode support for AXG SoC

Due to the dwmac glue layer register changed, we need to introduce a new compatible name for the Meson-AXG SoC to support for the RMII 100M ethernet PHY. Change since v1 at [1]: - implement set_phy_mode() for each SoC [1] https://lkml.kernel.org/r/20180426160508.29380-1-yixun@amlogic.com

[PATCH v2 1/2] dt-bindings: net: meson-dwmac: new compatible name for AXG SoC

We need to introduce a new compatible name for the Meson-AXG SoC in order to support the RMII 100M ethernet PHY, since the PRG_ETH0 register of the dwmac glue layer is changed from previous old SoC. Signed-off-by: Yixun Lan --- Documentation/devicetree/bindings/net/meson-dwmac.txt | 1 + 1 file

[PATCH v2 2/2] net: stmmac: dwmac-meson: extend phy mode setting

In the Meson-AXG SoC, the phy mode setting of PRG_ETH0 in the glue layer is extended from bit[0] to bit[2:0]. There is no problem if we configure it to the RGMII 1000M PHY mode, since the register setting is coincidentally compatible with previous one, but for the RMII 100M PHY mode, the

[PATCH v2 2/2] net: stmmac: dwmac-meson: extend phy mode setting

In the Meson-AXG SoC, the phy mode setting of PRG_ETH0 in the glue layer is extended from bit[0] to bit[2:0]. There is no problem if we configure it to the RGMII 1000M PHY mode, since the register setting is coincidentally compatible with previous one, but for the RMII 100M PHY mode, the

Re: [PATCH] documentation: core-api: rearrange a few kernel-api chapters and sections

On 04/27/2018 04:17 PM, Jonathan Corbet wrote: > On Thu, 26 Apr 2018 18:11:02 -0700 > Randy Dunlap wrote: > >> Rearrange some kernel-api chapters and sections to group them >> together better. >> >> - move Bit Operations from Basic C Library Functions to Basic >> Kernel

Re: [PATCH] documentation: core-api: rearrange a few kernel-api chapters and sections

On 04/27/2018 04:17 PM, Jonathan Corbet wrote: > On Thu, 26 Apr 2018 18:11:02 -0700 > Randy Dunlap wrote: > >> Rearrange some kernel-api chapters and sections to group them >> together better. >> >> - move Bit Operations from Basic C Library Functions to Basic >> Kernel Library Functions (now

Re: [PATCH] ARM64: dts: meson-axg: enable AP6255 wifi module

On 04/28/18 03:09, Kevin Hilman wrote: > Yixun Lan writes: > >> The Meson-AXG S400 board is shipped with AP6255 wifi module, >> which is actually using the brcmfmac 43455 driver. >> >> Signed-off-by: Yixun Lan >> --- >>

Re: [PATCH] ARM64: dts: meson-axg: enable AP6255 wifi module

On 04/28/18 03:09, Kevin Hilman wrote: > Yixun Lan writes: > >> The Meson-AXG S400 board is shipped with AP6255 wifi module, >> which is actually using the brcmfmac 43455 driver. >> >> Signed-off-by: Yixun Lan >> --- >> .../arm64/boot/dts/amlogic/meson-axg-s400.dts | 44 ++- >>

Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

On Fri, Apr 27, 2018 at 09:07:56PM -0400, Kevin Easton wrote: > On Fri, Apr 27, 2018 at 07:05:45PM +0300, Michael S. Tsirkin wrote: > > On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote: > > > The struct vhost_msg within struct vhost_msg_node is copied to userspace, > > > so it should

Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

On Fri, Apr 27, 2018 at 09:07:56PM -0400, Kevin Easton wrote: > On Fri, Apr 27, 2018 at 07:05:45PM +0300, Michael S. Tsirkin wrote: > > On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote: > > > The struct vhost_msg within struct vhost_msg_node is copied to userspace, > > > so it should

Re: [PATCH v7 0/7] clk: meson-axg: Add AO Cloclk and Reset driver

Hi Kevin On 04/28/18 02:49, Kevin Hilman wrote: > Hi Yixun, > > Yixun Lan writes: > >> On 04/27/2018 05:59 PM, Jerome Brunet wrote: > > [...] > >>> >>> Looks to be the problem indeed. But it is still an issue with how your >>> patchset >>> in organized. >>> >>> I

Re: [PATCH v7 0/7] clk: meson-axg: Add AO Cloclk and Reset driver

Hi Kevin On 04/28/18 02:49, Kevin Hilman wrote: > Hi Yixun, > > Yixun Lan writes: > >> On 04/27/2018 05:59 PM, Jerome Brunet wrote: > > [...] > >>> >>> Looks to be the problem indeed. But it is still an issue with how your >>> patchset >>> in organized. >>> >>> I can't merge this until

Poslal som vám e-mail

Poslal som vám e-mail

[PATCH v2] MAINTAINERS: add keyword for devicetree overlay notifiers

From: Frank Rowand Devicetree overlay notifiers have a chance to potentially get pointers into the overlay unflattened devicetree and overlay FDT. The only protection against these pointers being accessed after the underlying data has been released by kfree() is by source

[PATCH v2] MAINTAINERS: add keyword for devicetree overlay notifiers

From: Frank Rowand Devicetree overlay notifiers have a chance to potentially get pointers into the overlay unflattened devicetree and overlay FDT. The only protection against these pointers being accessed after the underlying data has been released by kfree() is by source code review of patches.

Re: [PATCH 2/2] bpf: btf: remove a couple conditions

On Fri, Apr 27, 2018 at 02:26:50PM -0700, Martin KaFai Lau wrote: > On Fri, Apr 27, 2018 at 11:31:36PM +0300, Dan Carpenter wrote: > > On Fri, Apr 27, 2018 at 10:21:17PM +0200, Daniel Borkmann wrote: > > > On 04/27/2018 09:39 PM, Dan Carpenter wrote: > > > > On Fri, Apr 27, 2018 at 10:55:46AM

Re: [PATCH 2/2] bpf: btf: remove a couple conditions

On Fri, Apr 27, 2018 at 02:26:50PM -0700, Martin KaFai Lau wrote: > On Fri, Apr 27, 2018 at 11:31:36PM +0300, Dan Carpenter wrote: > > On Fri, Apr 27, 2018 at 10:21:17PM +0200, Daniel Borkmann wrote: > > > On 04/27/2018 09:39 PM, Dan Carpenter wrote: > > > > On Fri, Apr 27, 2018 at 10:55:46AM

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

On 04/28/18 at 08:56am, Dave Young wrote: > On 04/27/18 at 04:12pm, Bjorn Helgaas wrote: > > [+cc Eric, Vivek, kexec list] > > > > On Fri, Apr 27, 2018 at 03:34:30PM -0400, Sinan Kaya wrote: > > > On 4/27/2018 3:22 PM, Bjorn Helgaas wrote: > > > > Sinan mooted the idea of using a "no-wait" path

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

On 04/28/18 at 08:56am, Dave Young wrote: > On 04/27/18 at 04:12pm, Bjorn Helgaas wrote: > > [+cc Eric, Vivek, kexec list] > > > > On Fri, Apr 27, 2018 at 03:34:30PM -0400, Sinan Kaya wrote: > > > On 4/27/2018 3:22 PM, Bjorn Helgaas wrote: > > > > Sinan mooted the idea of using a "no-wait" path

Re: [PATCH] MAINTAINERS: add keyword for devicetree overlay notifiers

Hi Rob, On 04/27/18 17:57, Frank Rowand wrote: > Hi Rob, > > I'm not sure how the extra "From:" of sony.com got into > this email. I'll have to dig into my scripts and/or > git configs to figure that out. The real "From:" is > the gmail.com one. Darn it... The real "From: is the sony.com

Re: [PATCH] MAINTAINERS: add keyword for devicetree overlay notifiers

Hi Rob, On 04/27/18 17:57, Frank Rowand wrote: > Hi Rob, > > I'm not sure how the extra "From:" of sony.com got into > this email. I'll have to dig into my scripts and/or > git configs to figure that out. The real "From:" is > the gmail.com one. Darn it... The real "From: is the sony.com

Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

On Fri, Apr 27, 2018 at 07:05:45PM +0300, Michael S. Tsirkin wrote: > On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote: > > The struct vhost_msg within struct vhost_msg_node is copied to userspace, > > so it should be allocated with kzalloc() to ensure all structure padding > > is

Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

On Fri, Apr 27, 2018 at 07:05:45PM +0300, Michael S. Tsirkin wrote: > On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote: > > The struct vhost_msg within struct vhost_msg_node is copied to userspace, > > so it should be allocated with kzalloc() to ensure all structure padding > > is

Re: [PATCH v1 4/4] mhi_bus: dev: uci: add user space interface driver

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

Re: [PATCH v1 4/4] mhi_bus: dev: uci: add user space interface driver

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

Re: BUG: /proc/kcore does not export direct-mapped memory on arm64 (and presumably some other architectures)

On 04/26/2018 02:16 PM, Kees Cook wrote: On Thu, Apr 26, 2018 at 12:31 PM, Dave Anderson wrote: While testing /proc/kcore as the live memory source for the crash utility, it fails on arm64. The failure on arm64 occurs because only the vmalloc/module space segments are

Re: BUG: /proc/kcore does not export direct-mapped memory on arm64 (and presumably some other architectures)

On 04/26/2018 02:16 PM, Kees Cook wrote: On Thu, Apr 26, 2018 at 12:31 PM, Dave Anderson wrote: While testing /proc/kcore as the live memory source for the crash utility, it fails on arm64. The failure on arm64 occurs because only the vmalloc/module space segments are exported in PT_LOAD

Re: [PATCH] MAINTAINERS: add keyword for devicetree overlay notifiers

Hi Rob, I'm not sure how the extra "From:" of sony.com got into this email. I'll have to dig into my scripts and/or git configs to figure that out. The real "From:" is the gmail.com one. -Frank On 04/27/18 17:50, frowand.l...@gmail.com wrote: > From: Frank Rowand > >

Re: [PATCH] MAINTAINERS: add keyword for devicetree overlay notifiers

Hi Rob, I'm not sure how the extra "From:" of sony.com got into this email. I'll have to dig into my scripts and/or git configs to figure that out. The real "From:" is the gmail.com one. -Frank On 04/27/18 17:50, frowand.l...@gmail.com wrote: > From: Frank Rowand > > From: Frank Rowand >

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

On 04/27/18 at 04:12pm, Bjorn Helgaas wrote: > [+cc Eric, Vivek, kexec list] > > On Fri, Apr 27, 2018 at 03:34:30PM -0400, Sinan Kaya wrote: > > On 4/27/2018 3:22 PM, Bjorn Helgaas wrote: > > > Sinan mooted the idea of using a "no-wait" path of sending the "don't > > > generate hotplug

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

On 04/27/18 at 04:12pm, Bjorn Helgaas wrote: > [+cc Eric, Vivek, kexec list] > > On Fri, Apr 27, 2018 at 03:34:30PM -0400, Sinan Kaya wrote: > > On 4/27/2018 3:22 PM, Bjorn Helgaas wrote: > > > Sinan mooted the idea of using a "no-wait" path of sending the "don't > > > generate hotplug

Re: ed74ae0342 ("blk-mq: Avoid that a completion can be ignored .."): BUG: kernel hang in test stage

On 4/24/18 3:00 PM, kernel test robot wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git > for-linus > > commit ed74ae03424684a6ad8a973c3fa727c6b4162432 > Author: Bart

Re: ed74ae0342 ("blk-mq: Avoid that a completion can be ignored .."): BUG: kernel hang in test stage

On 4/24/18 3:00 PM, kernel test robot wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git > for-linus > > commit ed74ae03424684a6ad8a973c3fa727c6b4162432 > Author: Bart

[PATCH] MAINTAINERS: add keyword for devicetree overlay notifiers

From: Frank Rowand From: Frank Rowand Devicetree overlay notifiers have a chance to potentially get pointers into the overlay unflattened devicetree and overlay FDT. The only protection against these pointers being accessed after the underlying

[PATCH] MAINTAINERS: add keyword for devicetree overlay notifiers

From: Frank Rowand From: Frank Rowand Devicetree overlay notifiers have a chance to potentially get pointers into the overlay unflattened devicetree and overlay FDT. The only protection against these pointers being accessed after the underlying data has been released by kfree() is by source

Re: [PATCH v4] bpf, x86_32: add eBPF JIT compiler for ia32

On 04/26/2018 12:12 PM, Wang YanQing wrote: [...] > +/* encode 'dst_reg' and 'src_reg' registers into x86_32 opcode 'byte' */ > +static u8 add_2reg(u8 byte, u32 dst_reg, u32 src_reg) > +{ > + return byte + dst_reg + (src_reg << 3); > +} > + > +static void jit_fill_hole(void *area, unsigned int

Re: [PATCH v4] bpf, x86_32: add eBPF JIT compiler for ia32

On 04/26/2018 12:12 PM, Wang YanQing wrote: [...] > +/* encode 'dst_reg' and 'src_reg' registers into x86_32 opcode 'byte' */ > +static u8 add_2reg(u8 byte, u32 dst_reg, u32 src_reg) > +{ > + return byte + dst_reg + (src_reg << 3); > +} > + > +static void jit_fill_hole(void *area, unsigned int

Re: [PATCH 2/2] kvm: nVMX: Introduce KVM_CAP_STATE

On 27/04/2018 17:19, Jim Mattson wrote: > > If the default treatment of SMIs and SMM (see Section 34.14) is > active, the VMX-preemption timer counts across an SMI to VMX non-root > operation, subsequent execution in SMM, and the return from SMM via > the RSM instruction. However, the timer can

Re: [PATCH 2/2] kvm: nVMX: Introduce KVM_CAP_STATE

On 27/04/2018 17:19, Jim Mattson wrote: > > If the default treatment of SMIs and SMM (see Section 34.14) is > active, the VMX-preemption timer counts across an SMI to VMX non-root > operation, subsequent execution in SMM, and the return from SMM via > the RSM instruction. However, the timer can

[RFC net-next 0/5] Support for PHY test modes

Hi all, This patch series adds support for specifying PHY test modes through ethtool and paves the ground for adding support for more complex test modes that might require data to be exchanged between user and kernel space. As an example, patches are included to add support for the IEEE

[RFC net-next 0/5] Support for PHY test modes

Hi all, This patch series adds support for specifying PHY test modes through ethtool and paves the ground for adding support for more complex test modes that might require data to be exchanged between user and kernel space. As an example, patches are included to add support for the IEEE

[RFC net-next 2/5] net: ethtool: Add UAPI for PHY test modes

Add the necessary UAPI changes to support querying the PHY tests modes implemented and optionally associated test specific data. This will be used as the foundation for supporting: - IEEE standard electrical test modes - cable diagnostics - packet tester Signed-off-by: Florian Fainelli

[RFC net-next 2/5] net: ethtool: Add UAPI for PHY test modes

Add the necessary UAPI changes to support querying the PHY tests modes implemented and optionally associated test specific data. This will be used as the foundation for supporting: - IEEE standard electrical test modes - cable diagnostics - packet tester Signed-off-by: Florian Fainelli ---

[RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

Add support for the 100BaseT2 and 1000BaseT standard test modes as defined by the IEEE 802.3-2012-Section two and three. We provide a set of helper functions for PHY drivers to either punt entirely onto genphy_* functions or if they desire, build additional tests on top of the standard ones

[RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

Add support for the 100BaseT2 and 1000BaseT standard test modes as defined by the IEEE 802.3-2012-Section two and three. We provide a set of helper functions for PHY drivers to either punt entirely onto genphy_* functions or if they desire, build additional tests on top of the standard ones

[RFC net-next 5/5] net: phy: broadcom: Add support for PHY test modes

Re-use the generic PHY library test modes for 100BaseT2 and 1000BaseT and advertise support for those through the newly added ethtool knobs. Signed-off-by: Florian Fainelli --- drivers/net/phy/bcm-phy-lib.c | 15 +-- drivers/net/phy/bcm7xxx.c | 3 +++ 2

[RFC net-next 5/5] net: phy: broadcom: Add support for PHY test modes

Re-use the generic PHY library test modes for 100BaseT2 and 1000BaseT and advertise support for those through the newly added ethtool knobs. Signed-off-by: Florian Fainelli --- drivers/net/phy/bcm-phy-lib.c | 15 +-- drivers/net/phy/bcm7xxx.c | 3 +++ 2 files changed, 12

[PATCH ethtool 2/2] ethtool: Add support for PHY test modes

Add two new commands: --get-phy-tests which allows fetching supported test modes by a given network device's PHY interface --set-phy-test which allows entering one of the modes listed before and pass an eventual set of test specific data Signed-off-by: Florian Fainelli

[RFC net-next 3/5] net: ethtool: Add plumbing to get/set PHY test modes

Implement the core ethtool changes to get/set PHY test modes, no driver implements that yet, but the internal API is defined and now allows it. We also provide the required helpers in PHYLIB in order to call the appropriate functions within the drivers. Signed-off-by: Florian Fainelli

[PATCH ethtool 1/2] ethtool-copy.h: Sync with net-next

This brings support for PHY test modes (not accepted yet) Signed-off-by: Florian Fainelli --- ethtool-copy.h | 23 +++ 1 file changed, 23 insertions(+) diff --git a/ethtool-copy.h b/ethtool-copy.h index 8cc61e9ab40b..42fb94129da5 100644 ---

[PATCH ethtool 2/2] ethtool: Add support for PHY test modes

Add two new commands: --get-phy-tests which allows fetching supported test modes by a given network device's PHY interface --set-phy-test which allows entering one of the modes listed before and pass an eventual set of test specific data Signed-off-by: Florian Fainelli --- ethtool.c | 115

[RFC net-next 3/5] net: ethtool: Add plumbing to get/set PHY test modes

Implement the core ethtool changes to get/set PHY test modes, no driver implements that yet, but the internal API is defined and now allows it. We also provide the required helpers in PHYLIB in order to call the appropriate functions within the drivers. Signed-off-by: Florian Fainelli ---

[PATCH ethtool 1/2] ethtool-copy.h: Sync with net-next

This brings support for PHY test modes (not accepted yet) Signed-off-by: Florian Fainelli --- ethtool-copy.h | 23 +++ 1 file changed, 23 insertions(+) diff --git a/ethtool-copy.h b/ethtool-copy.h index 8cc61e9ab40b..42fb94129da5 100644 --- a/ethtool-copy.h +++

[RFC net-next 1/5] net: phy: Pass stringset argument to ethtool operations

In preparation for returning a different type of strings other than ETH_SS_STATS update the PHY drivers, helpers and consumers of these functions. Signed-off-by: Florian Fainelli --- drivers/net/dsa/b53/b53_common.c | 4 ++-- drivers/net/phy/bcm-phy-lib.c| 12

[RFC net-next 1/5] net: phy: Pass stringset argument to ethtool operations

In preparation for returning a different type of strings other than ETH_SS_STATS update the PHY drivers, helpers and consumers of these functions. Signed-off-by: Florian Fainelli --- drivers/net/dsa/b53/b53_common.c | 4 ++-- drivers/net/phy/bcm-phy-lib.c| 12 +---

Re: [PATCH v1 1/4] mhi_bus: core: Add support for MHI host interface

Hi Sujeev, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc2 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v1 1/4] mhi_bus: core: Add support for MHI host interface

Hi Sujeev, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc2 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] drivers: net: replace UINT64_MAX with U64_MAX

From: Jisheng Zhang Date: Fri, 27 Apr 2018 16:18:58 +0800 > U64_MAX is well defined now while the UINT64_MAX is not, so we fall > back to drivers' own definition as below: > > #ifndef UINT64_MAX > #define UINT64_MAX (u64)(~((u64)0)) >

Re: [PATCH] drivers: net: replace UINT64_MAX with U64_MAX

From: Jisheng Zhang Date: Fri, 27 Apr 2018 16:18:58 +0800 > U64_MAX is well defined now while the UINT64_MAX is not, so we fall > back to drivers' own definition as below: > > #ifndef UINT64_MAX > #define UINT64_MAX (u64)(~((u64)0)) > #endif > > I believe this is

kselftest archives etc.

Hi, I was having trouble with the use of the gcc -no-pie option in tools/testing/selftests/x86: (option not supported) CFLAGS := -O2 -g -std=gnu99 -pthread -Wall -no-pie so I looked for an archive of linux-kselft...@vger.kernel.org. http://vger.kernel.org/vger-lists.html lists all mailing

kselftest archives etc.

Hi, I was having trouble with the use of the gcc -no-pie option in tools/testing/selftests/x86: (option not supported) CFLAGS := -O2 -g -std=gnu99 -pthread -Wall -no-pie so I looked for an archive of linux-kselft...@vger.kernel.org. http://vger.kernel.org/vger-lists.html lists all mailing

[PATCH] mm: provide a fallback for PAGE_KERNEL_RO for architectures

Some architectures do not define PAGE_KERNEL_RO, best we can do for them is to provide a fallback onto PAGE_KERNEL. Remove the hack from the firmware loader and move it onto the asm-generic header, and document while at it the affected architectures which do not have a PAGE_KERNEL_RO: o alpha

[PATCH] mm: provide a fallback for PAGE_KERNEL_RO for architectures

Some architectures do not define PAGE_KERNEL_RO, best we can do for them is to provide a fallback onto PAGE_KERNEL. Remove the hack from the firmware loader and move it onto the asm-generic header, and document while at it the affected architectures which do not have a PAGE_KERNEL_RO: o alpha

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

On Tue, Mar 13, 2018 at 12:12:51PM +1100, NeilBrown wrote: > > * selinux inode_doinit_with_dentry() (two call sites, very alike) > > I'm less sure about this one, but I think it probably wants > d_find_any_alias() as well. Like cap_inode_getsecurity() it only wants > a dentry so that

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

On Tue, Mar 13, 2018 at 12:12:51PM +1100, NeilBrown wrote: > > * selinux inode_doinit_with_dentry() (two call sites, very alike) > > I'm less sure about this one, but I think it probably wants > d_find_any_alias() as well. Like cap_inode_getsecurity() it only wants > a dentry so that

[PATCH] staging: luster: llite: fix a potential missing-check bug when copying lumv

In ll_dir_ioctl(), the object lumv3 is firstly copied from the user space using Its address, i.e., lumv1 = If the lmm_magic field of lumv3 is LOV_USER_MAGIV_V3, lumv3 will be modified by the second copy from the user space. The second copy is necessary, because the two versions (i.e.,

[PATCH] staging: luster: llite: fix a potential missing-check bug when copying lumv

In ll_dir_ioctl(), the object lumv3 is firstly copied from the user space using Its address, i.e., lumv1 = If the lmm_magic field of lumv3 is LOV_USER_MAGIV_V3, lumv3 will be modified by the second copy from the user space. The second copy is necessary, because the two versions (i.e.,

Re: INFO: rcu detected stall in blkdev_ioctl

syzbot has found reproducer for the following crash on upstream commit d8a332730e757129e70675679f2b2a03f1ecf65e (Fri Apr 27 17:39:38 2018 +) Merge tag 'char-misc-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc syzbot dashboard link:

Re: INFO: rcu detected stall in blkdev_ioctl

syzbot has found reproducer for the following crash on upstream commit d8a332730e757129e70675679f2b2a03f1ecf65e (Fri Apr 27 17:39:38 2018 +) Merge tag 'char-misc-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc syzbot dashboard link:

Re: copy_file_range and user space tools to do copy fastest

On Fri, Apr 27, 2018 at 01:45:40PM -0600, Andreas Dilger wrote: > On Apr 27, 2018, at 12:25 PM, Steve French wrote: > > > > Are there any user space tools (other than our test tools and xfs_io > > etc.) that support copy_file_range? Looks like at least cp and rsync > > and

Re: copy_file_range and user space tools to do copy fastest

On Fri, Apr 27, 2018 at 01:45:40PM -0600, Andreas Dilger wrote: > On Apr 27, 2018, at 12:25 PM, Steve French wrote: > > > > Are there any user space tools (other than our test tools and xfs_io > > etc.) that support copy_file_range? Looks like at least cp and rsync > > and dd don't. That

Re: [PATCH 2/4] fpga: manager: change api, don't use drvdata

On 04/27/2018 04:30 PM, Alan Tull wrote: > On Fri, Apr 27, 2018 at 1:26 PM, Florian Fainelli > wrote: >> On 04/26/2018 06:26 PM, Moritz Fischer wrote: >>> From: Alan Tull >>> >>> Change fpga_mgr_register to not set or use drvdata. This supports >>> the

Re: [PATCH 2/4] fpga: manager: change api, don't use drvdata

On 04/27/2018 04:30 PM, Alan Tull wrote: > On Fri, Apr 27, 2018 at 1:26 PM, Florian Fainelli > wrote: >> On 04/26/2018 06:26 PM, Moritz Fischer wrote: >>> From: Alan Tull >>> >>> Change fpga_mgr_register to not set or use drvdata. This supports >>> the case where a PCIe device has more than

Re: PROBLEM: error due to conflicting types during build of kselftests

On 04/20/2018 11:03 AM, Jeffrin Thalakkottoor wrote: > hello, > > the following is the error found... > --- > protection_keys.c:421:5: error: conflicting types for ‘pkey_set’ > int pkey_set(int pkey, unsigned long

Re: PROBLEM: error due to conflicting types during build of kselftests

On 04/20/2018 11:03 AM, Jeffrin Thalakkottoor wrote: > hello, > > the following is the error found... > --- > protection_keys.c:421:5: error: conflicting types for ‘pkey_set’ > int pkey_set(int pkey, unsigned long

Re: [PATCH] bpf: fix misaligned access for BPF_PROG_TYPE_PERF_EVENT program type on x86_32 platform

On 04/28/2018 12:48 AM, Alexei Starovoitov wrote: > On Thu, Apr 26, 2018 at 05:57:49PM +0800, Wang YanQing wrote: >> All the testcases for BPF_PROG_TYPE_PERF_EVENT program type in >> test_verifier(kselftest) report below errors on x86_32: >> " >> 172/p unpriv: spill/fill of different pointers ldx

Re: [PATCH] bpf: fix misaligned access for BPF_PROG_TYPE_PERF_EVENT program type on x86_32 platform

On 04/28/2018 12:48 AM, Alexei Starovoitov wrote: > On Thu, Apr 26, 2018 at 05:57:49PM +0800, Wang YanQing wrote: >> All the testcases for BPF_PROG_TYPE_PERF_EVENT program type in >> test_verifier(kselftest) report below errors on x86_32: >> " >> 172/p unpriv: spill/fill of different pointers ldx

Re: [PATCH 2/4] fpga: manager: change api, don't use drvdata

On Fri, Apr 27, 2018 at 1:26 PM, Florian Fainelli wrote: > On 04/26/2018 06:26 PM, Moritz Fischer wrote: >> From: Alan Tull >> >> Change fpga_mgr_register to not set or use drvdata. This supports >> the case where a PCIe device has more than one manager.

Re: [PATCH 2/4] fpga: manager: change api, don't use drvdata

On Fri, Apr 27, 2018 at 1:26 PM, Florian Fainelli wrote: > On 04/26/2018 06:26 PM, Moritz Fischer wrote: >> From: Alan Tull >> >> Change fpga_mgr_register to not set or use drvdata. This supports >> the case where a PCIe device has more than one manager. >> >> Add fpga_mgr_create/free

Re: [PATCH 1/2] kdump/x86: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

On 04/27/18 at 05:14pm, Dave Young wrote: > Hi, > > This is a resend of below patches: > http://lists.infradead.org/pipermail/kexec/2017-October/019569.html > > I dropped the original patch 1 since Baoquan is not happy with it. > For patch 2 (the 1st patch in this series), there is some

Re: [PATCH 1/2] kdump/x86: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

On 04/27/18 at 05:14pm, Dave Young wrote: > Hi, > > This is a resend of below patches: > http://lists.infradead.org/pipermail/kexec/2017-October/019569.html > > I dropped the original patch 1 since Baoquan is not happy with it. > For patch 2 (the 1st patch in this series), there is some

Re: [PATCH 0/7] docs/vm: update KSM documentation

On Tue, 24 Apr 2018 09:40:21 +0300 Mike Rapoport wrote: > These patches extend KSM documentation with high level design overview and > some details about reverse mappings and split the userspace interface > description to Documentation/admin-guide/mm. > > The

Re: [PATCH 0/7] docs/vm: update KSM documentation

On Tue, 24 Apr 2018 09:40:21 +0300 Mike Rapoport wrote: > These patches extend KSM documentation with high level design overview and > some details about reverse mappings and split the userspace interface > description to Documentation/admin-guide/mm. > > The description of some KSM sysfs

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

Hi, On Fri, Apr 27, 2018 at 2:54 PM, Matthias Kaehlcke wrote: >> > Am I getting something wrong here? >> >> The for_each_set_bit() should increment the 'i' and we would attempt to >> compare the first address in the request with the next command in the >> TCS cache. If they

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

Hi, On Fri, Apr 27, 2018 at 2:54 PM, Matthias Kaehlcke wrote: >> > Am I getting something wrong here? >> >> The for_each_set_bit() should increment the 'i' and we would attempt to >> compare the first address in the request with the next command in the >> TCS cache. If they don't match we repeat

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Fri, 27 Apr 2018, Michael S. Tsirkin wrote: > 2. Ability to control this from a separate config >option. > >It's still not that clear to me why is this such a >hard requirement. If a distro wants to force specific >boot time options, why isn't CONFIG_CMDLINE sufficient?

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Fri, 27 Apr 2018, Michael S. Tsirkin wrote: > 2. Ability to control this from a separate config >option. > >It's still not that clear to me why is this such a >hard requirement. If a distro wants to force specific >boot time options, why isn't CONFIG_CMDLINE sufficient?

Re: [PATCH] Documentation: driver-api: fix device_connection.rst kernel-doc error

On Thu, 26 Apr 2018 18:29:41 -0700 Randy Dunlap wrote: > Using incorrect :functions: syntax (extra space) causes an odd kernel-doc > warning, so fix that. > > Documentation/driver-api/device_connection.rst:42: ERROR: Error in > "kernel-doc" directive: Applied, thanks.

Re: [PATCH] Documentation: driver-api: fix device_connection.rst kernel-doc error

On Thu, 26 Apr 2018 18:29:41 -0700 Randy Dunlap wrote: > Using incorrect :functions: syntax (extra space) causes an odd kernel-doc > warning, so fix that. > > Documentation/driver-api/device_connection.rst:42: ERROR: Error in > "kernel-doc" directive: Applied, thanks. jon

Re: [PATCH] documentation: core-api: rearrange a few kernel-api chapters and sections

On Thu, 26 Apr 2018 18:11:02 -0700 Randy Dunlap wrote: > Rearrange some kernel-api chapters and sections to group them > together better. > > - move Bit Operations from Basic C Library Functions to Basic > Kernel Library Functions (now adjacent to Bitmap Operations

Re: [PATCH] documentation: core-api: rearrange a few kernel-api chapters and sections

On Thu, 26 Apr 2018 18:11:02 -0700 Randy Dunlap wrote: > Rearrange some kernel-api chapters and sections to group them > together better. > > - move Bit Operations from Basic C Library Functions to Basic > Kernel Library Functions (now adjacent to Bitmap Operations since > they are not

Re: FROM: "MRS PATRICIA WILLIAMS" linux-kernel@vger.kernel.org

FYI: About My Previous Message Hi, Am Mrs Patricia William, i just want to know if you receive my previous email i sent to you last three (3) days ago. Is your email still Active? If YES; please can you email me back, i have something very important to discuss with you. Awaits your reply

Re: FROM: "MRS PATRICIA WILLIAMS" linux-kernel@vger.kernel.org

FYI: About My Previous Message Hi, Am Mrs Patricia William, i just want to know if you receive my previous email i sent to you last three (3) days ago. Is your email still Active? If YES; please can you email me back, i have something very important to discuss with you. Awaits your reply

Re: [PATCH 0/7] docs/vm: start moving files do Documentation/admin-guide`

On Wed, 18 Apr 2018 11:07:43 +0300 Mike Rapoport wrote: > These pacthes begin categorizing memory management documentation. The > documents that describe userspace APIs and do not overload the reader with > implementation details can be moved to

Re: [PATCH 0/7] docs/vm: start moving files do Documentation/admin-guide`

On Wed, 18 Apr 2018 11:07:43 +0300 Mike Rapoport wrote: > These pacthes begin categorizing memory management documentation. The > documents that describe userspace APIs and do not overload the reader with > implementation details can be moved to Documentation/admin-guide, so let's > do it :)

[PATCH 3/3] pwm-sifive: add a driver for SiFive SoC PWM

SiFive SoCs can contain one or more PWM IP blocks. This adds a driver for them. Tested on the HiFive Unleashed. Signed-off-by: Wesley W. Terpstra --- drivers/pwm/Kconfig | 11 ++ drivers/pwm/Makefile | 1 + drivers/pwm/pwm-sifive.c | 259

[PATCH 3/3] pwm-sifive: add a driver for SiFive SoC PWM

SiFive SoCs can contain one or more PWM IP blocks. This adds a driver for them. Tested on the HiFive Unleashed. Signed-off-by: Wesley W. Terpstra --- drivers/pwm/Kconfig | 11 ++ drivers/pwm/Makefile | 1 + drivers/pwm/pwm-sifive.c | 259

[PATCH 0/3] SiFive SoC PWM driver

SiFive SoCs can contain one or more PWM IP blocks. This adds a driver for them. Tested on the HiFive Unleashed. This patch series is broken into three parts: The driver itself, in drivers/pwm The device tree binding description, in Documentation/devicetree/bindings The SiFive vendor prefix,

[PATCH 0/3] SiFive SoC PWM driver

SiFive SoCs can contain one or more PWM IP blocks. This adds a driver for them. Tested on the HiFive Unleashed. This patch series is broken into three parts: The driver itself, in drivers/pwm The device tree binding description, in Documentation/devicetree/bindings The SiFive vendor prefix,

<    1   2   3   4   5   6   7   8   9   10   >