[PATCH V2] perf/x86: fix spurious NMI with PEBS Load Latency event

From: Kan Liang Spurious NMIs will be observed when applying the following command. while true ; do sudo perf record -b -a -e "cpu/umask=0x01,event=0xcd,ldlat=0x80/pp,cpu/umask=0x03,event=0x0/, cpu/umask=0x02,event=0x0/,cycles,branches,cache-misses, cache-references" -- sleep 10 ;

Re: [PATCH v2] x86/boot: Support uncompressed kernel

On Tue, Apr 4, 2017 at 1:52 AM, Chao Peng wrote: > Compressed kernel has its own drawback: decompressing takes time. Even > though the time is short enough to ignore for most cases but for cases when > time is critical decompressing time still matters. > > The patch adds a 'CONFIG_KERNEL_RAW'

Re: [PATCH] mm: Add additional consistency check

On Tue, 4 Apr 2017, Michal Hocko wrote: > Yes, but we do not have to blow the kernel, right? Why cannot we simply > leak that memory? Because it is a serious bug to attempt to free a non slab object using slab operations. This is often the result of memory corruption, coding errs etc. The system

Re: [PATCH] mm: Add additional consistency check

On Tue, 4 Apr 2017, Michal Hocko wrote: > Yes, but we do not have to blow the kernel, right? Why cannot we simply > leak that memory? Because it is a serious bug to attempt to free a non slab object using slab operations. This is often the result of memory corruption, coding errs etc. The system

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master (fwd)

On 3/30/17 4:39 PM, Julia Lawall wrote: Is master on line 514 allocated with kmalloc, or the devm call on line 522? Hi Julia, Its allocated with the devm call on line 522. The kfree on line 514 wouldn't be necessary in that case - will remove. Thanks for pointing that out. Chris

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master (fwd)

On 3/30/17 4:39 PM, Julia Lawall wrote: Is master on line 514 allocated with kmalloc, or the devm call on line 522? Hi Julia, Its allocated with the devm call on line 522. The kfree on line 514 wouldn't be necessary in that case - will remove. Thanks for pointing that out. Chris

Re: dwc2_hc_chhltd_intr_dma - ChHltd set errors?

On Tue, Apr 4, 2017 at 12:38 AM, Felipe Balbi wrote: > > Hi, > > Minas Harutyunyan writes: >>> We've noticed that when using usb ethernet adapters on HiKey, we >>> occasionally see errors like: >>> >>> dwc2

Re: dwc2_hc_chhltd_intr_dma - ChHltd set errors?

On Tue, Apr 4, 2017 at 12:38 AM, Felipe Balbi wrote: > > Hi, > > Minas Harutyunyan writes: >>> We've noticed that when using usb ethernet adapters on HiKey, we >>> occasionally see errors like: >>> >>> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set, >>>

Re: [PATCH 0/2] pci-hyperv: Some miscellaneous fixes

On Fri, Mar 24, 2017 at 11:06:40AM -0700, k...@exchange.microsoft.com wrote: > From: K. Y. Srinivasan > > Some miscellaneous fixes. > > K. Y. Srinivasan (2): > pci-hyperv: Fix a bug in specifying CPU affinity > pci-hyperv: Fix an atomic bug > >

Re: [PATCH 0/2] pci-hyperv: Some miscellaneous fixes

On Fri, Mar 24, 2017 at 11:06:40AM -0700, k...@exchange.microsoft.com wrote: > From: K. Y. Srinivasan > > Some miscellaneous fixes. > > K. Y. Srinivasan (2): > pci-hyperv: Fix a bug in specifying CPU affinity > pci-hyperv: Fix an atomic bug > > drivers/pci/host/pci-hyperv.c | 13

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Tue, Apr 04, 2017 at 07:54:36PM +0200, Mike Galbraith wrote: > On Tue, 2017-04-04 at 19:40 +0200, Mike Galbraith wrote: > > On Tue, 2017-04-04 at 18:30 +0300, Michael S. Tsirkin wrote: > > > > > I couldn't reproduce it - let's make sure we are using the > > > same tree. Could you pls try > > >

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Tue, Apr 04, 2017 at 07:54:36PM +0200, Mike Galbraith wrote: > On Tue, 2017-04-04 at 19:40 +0200, Mike Galbraith wrote: > > On Tue, 2017-04-04 at 18:30 +0300, Michael S. Tsirkin wrote: > > > > > I couldn't reproduce it - let's make sure we are using the > > > same tree. Could you pls try > > >

Re: [PATCH 4/8] x86/intel_rct/mba: Add MBA structures and initialize MBA

Apologies, unrelated to MBA. Resent later with a changed subject line. On Tue, Apr 4, 2017 at 1:50 PM, Shivappa Vikas wrote: > > > > On Mon, 3 Apr 2017, Tracy Smith wrote: > >> Hi All, >> >> No JTAG available and need to understand why Linux 4.8.3 doesn't boot on a >>

Re: [PATCH 4/8] x86/intel_rct/mba: Add MBA structures and initialize MBA

Apologies, unrelated to MBA. Resent later with a changed subject line. On Tue, Apr 4, 2017 at 1:50 PM, Shivappa Vikas wrote: > > > > On Mon, 3 Apr 2017, Tracy Smith wrote: > >> Hi All, >> >> No JTAG available and need to understand why Linux 4.8.3 doesn't boot on a >> x86_64 corei7-64. Hangs at

[PATCH] ASoC: cs53l30: Set .of_match_table to OF device ID table

The driver has an OF device ID table but the struct i2c_driver .of_match_table field is not set. Signed-off-by: Javier Martinez Canillas --- sound/soc/codecs/cs53l30.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/cs53l30.c

[PATCH] ASoC: cs53l30: Set .of_match_table to OF device ID table

The driver has an OF device ID table but the struct i2c_driver .of_match_table field is not set. Signed-off-by: Javier Martinez Canillas --- sound/soc/codecs/cs53l30.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/cs53l30.c b/sound/soc/codecs/cs53l30.c index

[PATCH 1/9] bio-integrity: Do not allocate integrity context for bio w/o data

If bio has no data, such as ones from blkdev_issue_flush(), then we have nothing to protect. This patch prevent bugon like follows: kfree_debugcheck: out of range ptr ac1fa1d106742a5ah kernel BUG at mm/slab.c:2773! invalid opcode: [#1] SMP Modules linked in: bcache CPU: 0 PID: 4428 Comm:

[PATCH 1/9] bio-integrity: Do not allocate integrity context for bio w/o data

If bio has no data, such as ones from blkdev_issue_flush(), then we have nothing to protect. This patch prevent bugon like follows: kfree_debugcheck: out of range ptr ac1fa1d106742a5ah kernel BUG at mm/slab.c:2773! invalid opcode: [#1] SMP Modules linked in: bcache CPU: 0 PID: 4428 Comm:

[PATCH 3/9] bio-integrity: bio_integrity_advance must update integrity seed

SCSI drivers do care about bip_seed so we must update it accordingly. Signed-off-by: Dmitry Monakhov --- block/bio-integrity.c | 1 + 1 file changed, 1 insertion(+) diff --git a/block/bio-integrity.c b/block/bio-integrity.c index b5009a8..82a6ffb 100644 ---

[PATCH 3/9] bio-integrity: bio_integrity_advance must update integrity seed

SCSI drivers do care about bip_seed so we must update it accordingly. Signed-off-by: Dmitry Monakhov --- block/bio-integrity.c | 1 + 1 file changed, 1 insertion(+) diff --git a/block/bio-integrity.c b/block/bio-integrity.c index b5009a8..82a6ffb 100644 --- a/block/bio-integrity.c +++

Re: [PATCH] sched: Fix numabalancing to work with isolated cpus

On Tue, 2017-04-04 at 22:57 +0530, Srikar Dronamraju wrote: > > The isolated cpus are part of the cpus allowed list. In the above > case, > numabalancing ends up scheduling some of these tasks on isolated > cpus. > > To avoid this, please check for isolated cpus before choosing a > target > cpu.

[PATCH 4/9] bio-integrity: fix interface for bio_integrity_trim v2

bio_integrity_trim inherent it's interface from bio_trim and accept offset and size, but this API is error prone because data offset must always be insync with bio's data offset. That is why we have integrity update hook in bio_advance() So only meaningful values are: offset == 0, sectors ==

Re: [PATCH] sched: Fix numabalancing to work with isolated cpus

On Tue, 2017-04-04 at 22:57 +0530, Srikar Dronamraju wrote: > > The isolated cpus are part of the cpus allowed list. In the above > case, > numabalancing ends up scheduling some of these tasks on isolated > cpus. > > To avoid this, please check for isolated cpus before choosing a > target > cpu.

[PATCH 4/9] bio-integrity: fix interface for bio_integrity_trim v2

bio_integrity_trim inherent it's interface from bio_trim and accept offset and size, but this API is error prone because data offset must always be insync with bio's data offset. That is why we have integrity update hook in bio_advance() So only meaningful values are: offset == 0, sectors ==

[PATCH 8/9] bio: add bvec_iter rewind API

Some ->bi_end_io handlers (for example: pi_verify or decrypt handlers) need to know original data vector, but after bio traverse io-stack it may be advanced, splited and relocated many times so it is hard to guess original iterator. Let's add 'bi_done' conter which accounts number of bytes

[PATCH 8/9] bio: add bvec_iter rewind API

Some ->bi_end_io handlers (for example: pi_verify or decrypt handlers) need to know original data vector, but after bio traverse io-stack it may be advanced, splited and relocated many times so it is hard to guess original iterator. Let's add 'bi_done' conter which accounts number of bytes

[PATCH 7/9] Guard bvec iteration logic v3

Currently if some one try to advance bvec beyond it's size we simply dump WARN_ONCE and continue to iterate beyond bvec array boundaries. This simply means that we endup dereferencing/corrupting random memory region. Sane reaction would be to propagate error back to calling context But

[PATCH 7/9] Guard bvec iteration logic v3

Currently if some one try to advance bvec beyond it's size we simply dump WARN_ONCE and continue to iterate beyond bvec array boundaries. This simply means that we endup dereferencing/corrupting random memory region. Sane reaction would be to propagate error back to calling context But

[PATCH 6/9] T10: Move opencoded contants to common header

Signed-off-by: Dmitry Monakhov --- block/t10-pi.c | 9 +++-- drivers/scsi/lpfc/lpfc_scsi.c| 5 +++-- drivers/scsi/qla2xxx/qla_isr.c | 8 drivers/target/target_core_sbc.c | 2 +- include/linux/t10-pi.h | 2 ++ 5 files changed,

[PATCH 6/9] T10: Move opencoded contants to common header

Signed-off-by: Dmitry Monakhov --- block/t10-pi.c | 9 +++-- drivers/scsi/lpfc/lpfc_scsi.c| 5 +++-- drivers/scsi/qla2xxx/qla_isr.c | 8 drivers/target/target_core_sbc.c | 2 +- include/linux/t10-pi.h | 2 ++ 5 files changed, 13 insertions(+), 13

[PATCH 9/9] bio-integrity: Restore original iterator on verify stage

Currently ->verify_fn not woks at all because at the moment it is called bio->bi_iter.bi_size == 0, so we do not iterate integrity bvecs at all. In order to perform verification we need to know original data vector, with new bvec rewind API this is trivial. testcase:

[PATCH 5/9] bio-integrity: fold bio_integrity_enabled to bio_integrity_prep

Currently all integrity prep hooks are open-coded, and if prepare fails we ignore it's code and fail bio with EIO. Let's return real error to upper layer, so later caller may react accordingly. In fact no one want to use bio_integrity_prep() w/o bio_integrity_enabled, so it is reasonable to fold

[PATCH 9/9] bio-integrity: Restore original iterator on verify stage

Currently ->verify_fn not woks at all because at the moment it is called bio->bi_iter.bi_size == 0, so we do not iterate integrity bvecs at all. In order to perform verification we need to know original data vector, with new bvec rewind API this is trivial. testcase:

[PATCH 5/9] bio-integrity: fold bio_integrity_enabled to bio_integrity_prep

Currently all integrity prep hooks are open-coded, and if prepare fails we ignore it's code and fail bio with EIO. Let's return real error to upper layer, so later caller may react accordingly. In fact no one want to use bio_integrity_prep() w/o bio_integrity_enabled, so it is reasonable to fold

[PATCH 0/9] block: T10/DIF Fixes and cleanups v3

This patch set fix various problems spotted during T10/DIF integrity machinery testing. TOC: ## Fix various bugs in T10/DIF/DIX infrastructure 0001-bio-integrity-Do-not-allocate-integrity-context-for 0002-bio-integrity-bio_trim-should-truncate-integrity-vec

[PATCH 0/9] block: T10/DIF Fixes and cleanups v3

This patch set fix various problems spotted during T10/DIF integrity machinery testing. TOC: ## Fix various bugs in T10/DIF/DIX infrastructure 0001-bio-integrity-Do-not-allocate-integrity-context-for 0002-bio-integrity-bio_trim-should-truncate-integrity-vec

[PATCH 2/9] bio-integrity: bio_trim should truncate integrity vector accordingly

Reviewed-by: Christoph Hellwig Signed-off-by: Dmitry Monakhov --- block/bio.c | 4 1 file changed, 4 insertions(+) diff --git a/block/bio.c b/block/bio.c index e75878f..fa84323 100644 --- a/block/bio.c +++ b/block/bio.c @@ -1907,6 +1907,10 @@ void

[PATCH 2/9] bio-integrity: bio_trim should truncate integrity vector accordingly

Reviewed-by: Christoph Hellwig Signed-off-by: Dmitry Monakhov --- block/bio.c | 4 1 file changed, 4 insertions(+) diff --git a/block/bio.c b/block/bio.c index e75878f..fa84323 100644 --- a/block/bio.c +++ b/block/bio.c @@ -1907,6 +1907,10 @@ void bio_trim(struct bio *bio, int offset, int

Re: [PATCH v6 2/4] x86/syscalls: Specific usage of verify_pre_usermode_state

On Tue, Apr 04, 2017 at 11:27:07AM -0700, H. Peter Anvin wrote: > Finally, I can't really believe I'm the only person for whom "Specific > usage of verity_pre_usermode_state" is completely opaque. No, you're not. I'm missing the usual layout of the commit message "Problem is A, we need to do B,

Re: [PATCH v6 2/4] x86/syscalls: Specific usage of verify_pre_usermode_state

On Tue, Apr 04, 2017 at 11:27:07AM -0700, H. Peter Anvin wrote: > Finally, I can't really believe I'm the only person for whom "Specific > usage of verity_pre_usermode_state" is completely opaque. No, you're not. I'm missing the usual layout of the commit message "Problem is A, we need to do B,

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Tue, 4 Apr 2017, Tom Zanussi wrote: > Yes, in a previous project, I had been working toward getting a < 1M > system to boot on Galileo hardware (which it did, but using more than > that - the Galileo2 has 256MB, but it was the target hardware at the > time, and I was hoping eventually to be

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Tue, 4 Apr 2017, Tom Zanussi wrote: > Yes, in a previous project, I had been working toward getting a < 1M > system to boot on Galileo hardware (which it did, but using more than > that - the Galileo2 has 256MB, but it was the target hardware at the > time, and I was hoping eventually to be

Re: net/ipv4: use-after-free in ipv4_mtu

On Tue, Apr 4, 2017 at 7:50 AM, Andrey Konovalov wrote: > > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit a71c9a1c779f2499fb2afc0553e543f18aff6edf (4.11-rc5). > > Unfortunately it's not reproducible. > >

Re: net/ipv4: use-after-free in ipv4_mtu

On Tue, Apr 4, 2017 at 7:50 AM, Andrey Konovalov wrote: > > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit a71c9a1c779f2499fb2afc0553e543f18aff6edf (4.11-rc5). > > Unfortunately it's not reproducible. > >

Re: [PATCH 4/8] x86/intel_rct/mba: Add MBA structures and initialize MBA

On Mon, 3 Apr 2017, Tracy Smith wrote: Hi All, No JTAG available and need to understand why Linux 4.8.3 doesn't boot on a x86_64 corei7-64. Hangs at the typical "Starting kernel" location after the last message of the U-boot. The bootcmd is given below. Do you see the issue when you

Re: [PATCH 4/8] x86/intel_rct/mba: Add MBA structures and initialize MBA

On Mon, 3 Apr 2017, Tracy Smith wrote: Hi All, No JTAG available and need to understand why Linux 4.8.3 doesn't boot on a x86_64 corei7-64. Hangs at the typical "Starting kernel" location after the last message of the U-boot. The bootcmd is given below. Do you see the issue when you

Re: [PATCH v6 2/4] x86/syscalls: Specific usage of verify_pre_usermode_state

On 04/04/17 10:47, Thomas Garnier wrote: > diff --git a/arch/x86/include/asm/pgtable_64_types.h > b/arch/x86/include/asm/pgtable_64_types.h > index 516593e66bd6..12fa851c7fa8 100644 > --- a/arch/x86/include/asm/pgtable_64_types.h > +++ b/arch/x86/include/asm/pgtable_64_types.h > @@ -78,4 +78,15

Re: [PATCH v6 2/4] x86/syscalls: Specific usage of verify_pre_usermode_state

On 04/04/17 10:47, Thomas Garnier wrote: > diff --git a/arch/x86/include/asm/pgtable_64_types.h > b/arch/x86/include/asm/pgtable_64_types.h > index 516593e66bd6..12fa851c7fa8 100644 > --- a/arch/x86/include/asm/pgtable_64_types.h > +++ b/arch/x86/include/asm/pgtable_64_types.h > @@ -78,4 +78,15

Re: [PATCH 2/4] arm64: hugetlbpages: Correctly handle swap entries in huge_pte_offset()

Hi Mark, Mark Rutland writes: > Hi Punit, > > On Thu, Mar 30, 2017 at 05:38:47PM +0100, Punit Agrawal wrote: >> huge_pte_offset() does not correctly handle poisoned or migration page >> table entries. > > What exactly does it do wrong? > > Judging by the patch, we return

Re: [PATCH 2/4] arm64: hugetlbpages: Correctly handle swap entries in huge_pte_offset()

Hi Mark, Mark Rutland writes: > Hi Punit, > > On Thu, Mar 30, 2017 at 05:38:47PM +0100, Punit Agrawal wrote: >> huge_pte_offset() does not correctly handle poisoned or migration page >> table entries. > > What exactly does it do wrong? > > Judging by the patch, we return NULL in some cases we

[PATCH 3/3] arm64: allwinner: a64: enable EHCI0/OHCI0 controller for Pine64

The upper USB port of Pine64 board is connected to the SoC's USB0 port, which can now switch from the MUSB controller to the EHCI/OHCI pair. Enable the EHCI/OHCI pair in the Pine64 device tree. Signed-off-by: Icenowy Zheng ---

[PATCH 3/3] arm64: allwinner: a64: enable EHCI0/OHCI0 controller for Pine64

The upper USB port of Pine64 board is connected to the SoC's USB0 port, which can now switch from the MUSB controller to the EHCI/OHCI pair. Enable the EHCI/OHCI pair in the Pine64 device tree. Signed-off-by: Icenowy Zheng --- arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 8 1

[PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts

As we added USB0 route auto switching support for A64, add related device tree parts to the A64 DTSI file (EHCI0/OHCI0 controllers and the pmu0 memory area for PHY). Signed-off-by: Icenowy Zheng --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 1

[PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts

As we added USB0 route auto switching support for A64, add related device tree parts to the A64 DTSI file (EHCI0/OHCI0 controllers and the pmu0 memory area for PHY). Signed-off-by: Icenowy Zheng --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 1 file changed, 24

[PATCH 1/3] phy: sun4i-usb: enable PHY0 dual route switching for A64 USB PHY

Allwinner A64 SoC features a switchable PHY0 like the one in H3, which can switch between a MUSB controller and a pair of OHCI/EHCI controller. Enable PHY0 route auto switching for A64. Signed-off-by: Icenowy Zheng --- drivers/phy/phy-sun4i-usb.c | 1 + 1 file changed, 1

[PATCH 1/3] phy: sun4i-usb: enable PHY0 dual route switching for A64 USB PHY

Allwinner A64 SoC features a switchable PHY0 like the one in H3, which can switch between a MUSB controller and a pair of OHCI/EHCI controller. Enable PHY0 route auto switching for A64. Signed-off-by: Icenowy Zheng --- drivers/phy/phy-sun4i-usb.c | 1 + 1 file changed, 1 insertion(+) diff

Re: [PATCH 0/2] ARM: dts: keystone: Add support for new K2G evm

On 04/04/2017 10:33 AM, Santosh Shilimkar wrote: > On 4/3/2017 9:44 AM, santosh.shilim...@oracle.com wrote: >> Hi Franklin, >> >> On 3/30/17 8:29 AM, Franklin S Cooper Jr wrote: >>> This patchset adds support for new K2G Industrial Communication Engine >>> evm. For now only a bare minimal dts

Re: [PATCH 0/2] ARM: dts: keystone: Add support for new K2G evm

On 04/04/2017 10:33 AM, Santosh Shilimkar wrote: > On 4/3/2017 9:44 AM, santosh.shilim...@oracle.com wrote: >> Hi Franklin, >> >> On 3/30/17 8:29 AM, Franklin S Cooper Jr wrote: >>> This patchset adds support for new K2G Industrial Communication Engine >>> evm. For now only a bare minimal dts

[RFC PATCH] kernel: sched: Provide a pointer to the valid CPU mask

In commit 4b53a3412d66 ("sched/core: Remove the tsk_nr_cpus_allowed() wrapper") the tsk_nr_cpus_allowed() wrapper was removed. There was not much difference in !RT but in RT we used this to implement migrate_disable(). Within a migrate_disable() section the CPU mask is restricted to single CPU

[RFC PATCH] kernel: sched: Provide a pointer to the valid CPU mask

In commit 4b53a3412d66 ("sched/core: Remove the tsk_nr_cpus_allowed() wrapper") the tsk_nr_cpus_allowed() wrapper was removed. There was not much difference in !RT but in RT we used this to implement migrate_disable(). Within a migrate_disable() section the CPU mask is restricted to single CPU

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Tue, 2017-04-04 at 21:00 +0300, Michael S. Tsirkin wrote: > And just making double sure, the 1st version that has the issue > is 5c34d002dcc7, isn't it? I'm asking because subject says so > but then goes on to list subject from another commit. > This one is: > > virtio_pci: remove struct

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, Mar 30, 2017 at 10:41:37AM +1100, Dave Chinner wrote: > On Wed, Mar 29, 2017 at 01:54:31PM -0400, Jeff Layton wrote: > > On Wed, 2017-03-29 at 13:15 +0200, Jan Kara wrote: > > > On Tue 21-03-17 14:46:53, Jeff Layton wrote: > > > > On Tue, 2017-03-21 at 14:30 -0400, J. Bruce Fields wrote: >

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Tue, 2017-04-04 at 21:00 +0300, Michael S. Tsirkin wrote: > And just making double sure, the 1st version that has the issue > is 5c34d002dcc7, isn't it? I'm asking because subject says so > but then goes on to list subject from another commit. > This one is: > > virtio_pci: remove struct

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, Mar 30, 2017 at 10:41:37AM +1100, Dave Chinner wrote: > On Wed, Mar 29, 2017 at 01:54:31PM -0400, Jeff Layton wrote: > > On Wed, 2017-03-29 at 13:15 +0200, Jan Kara wrote: > > > On Tue 21-03-17 14:46:53, Jeff Layton wrote: > > > > On Tue, 2017-03-21 at 14:30 -0400, J. Bruce Fields wrote: >

[PATCH v4 3/6] ARM: dts: sun4i: Add can0_pins_a pinctrl settings

The A10 SoC has an on-board CAN controller. This patch adds the pinctrl settings for pins PH20 and PH21. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel ---

[PATCH v4 0/6] ARM: dts: sunxi: Add CAN node and can0_pins_a pinctrl settings

The Allwinner A10/A20 SoCs have an on-board CAN (Controller Area Network) controller. This patch adds the CAN core to the SoC's include files, sun4i-a10.dtsi and sun7i-a20.dtsi. On linux-can mailing list was a discussion about updating the device tree bindings https://lkml.org/lkml/2015/9/17/220

[PATCH v4 3/6] ARM: dts: sun4i: Add can0_pins_a pinctrl settings

The A10 SoC has an on-board CAN controller. This patch adds the pinctrl settings for pins PH20 and PH21. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel --- arch/arm/boot/dts/sun4i-a10.dtsi | 5 + 1 file

[PATCH v4 0/6] ARM: dts: sunxi: Add CAN node and can0_pins_a pinctrl settings

The Allwinner A10/A20 SoCs have an on-board CAN (Controller Area Network) controller. This patch adds the CAN core to the SoC's include files, sun4i-a10.dtsi and sun7i-a20.dtsi. On linux-can mailing list was a discussion about updating the device tree bindings https://lkml.org/lkml/2015/9/17/220

[PATCH v4 6/6] ARM: dts: sun7i: Add can0_pins_a pinctrl settings

The A20 SoC has an on-board CAN controller. This patch adds the pinctrl settings for pins PH20 and PH21. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel ---

[PATCH v4 6/6] ARM: dts: sun7i: Add can0_pins_a pinctrl settings

The A20 SoC has an on-board CAN controller. This patch adds the pinctrl settings for pins PH20 and PH21. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel --- arch/arm/boot/dts/sun7i-a20.dtsi | 5 + 1 file

[PATCH v4 5/6] ARM: dts: sun7i: Add CAN node

The A20 SoC has an on-board CAN controller. This patch adds the device node. The CAN controller is inherited from the A10 SoC and uses the same driver. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel

[PATCH v4 5/6] ARM: dts: sun7i: Add CAN node

The A20 SoC has an on-board CAN controller. This patch adds the device node. The CAN controller is inherited from the A10 SoC and uses the same driver. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel ---

[PATCH v4 4/6] ARM: dts: sun7i: fix device node ordering

This patch changes the device node position of ps20 and ps21 to fix ordering by rising physical address. From uart7: serial@01c29c00 i2c0: i2c@01c2ac00 i2c1: i2c@01c2b000 i2c2: i2c@01c2b400 i2c3: i2c@01c2b800 i2c4: i2c@01c2c000 gmac: ethernet@01c5 hstimer@01c6 gic:

[PATCH v4 4/6] ARM: dts: sun7i: fix device node ordering

This patch changes the device node position of ps20 and ps21 to fix ordering by rising physical address. From uart7: serial@01c29c00 i2c0: i2c@01c2ac00 i2c1: i2c@01c2b000 i2c2: i2c@01c2b400 i2c3: i2c@01c2b800 i2c4: i2c@01c2c000 gmac: ethernet@01c5 hstimer@01c6 gic:

Re: pull-request: wireless-drivers-next 2017-04-03

From: Kalle Valo Date: Tue, 04 Apr 2017 20:48:35 +0300 > David Miller writes: > >> From: Kalle Valo >> Date: Mon, 03 Apr 2017 14:26:10 +0300 >> >>> here few really small fixes. I'm hoping this to be the last pull request >>> for

[PATCH v4 1/6] ARM: dts: sun4i: fix device node ordering

This patch changes the device node position of ps20 and ps21 to fix ordering by rising physical address. From uart7: serial@01c29c00 i2c0: i2c@01c2ac00 i2c1: i2c@01c2b000 i2c2: i2c@01c2b400 ps20: ps2@01c2a000 ps21: ps2@01c2a400 to uart7: serial@01c29c00 ps20: ps2@01c2a000 ps21: ps2@01c2a400

Re: pull-request: wireless-drivers-next 2017-04-03

From: Kalle Valo Date: Tue, 04 Apr 2017 20:48:35 +0300 > David Miller writes: > >> From: Kalle Valo >> Date: Mon, 03 Apr 2017 14:26:10 +0300 >> >>> here few really small fixes. I'm hoping this to be the last pull request >>> for 4.11. >>> >>> Please let me if there are any problems. >> >>

[PATCH v4 1/6] ARM: dts: sun4i: fix device node ordering

This patch changes the device node position of ps20 and ps21 to fix ordering by rising physical address. From uart7: serial@01c29c00 i2c0: i2c@01c2ac00 i2c1: i2c@01c2b000 i2c2: i2c@01c2b400 ps20: ps2@01c2a000 ps21: ps2@01c2a400 to uart7: serial@01c29c00 ps20: ps2@01c2a000 ps21: ps2@01c2a400

[PATCH v4 2/6] ARM: dts: sun4i: Add CAN node

The A10 SoC has an on-board CAN controller. This patch adds the device node. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel --- arch/arm/boot/dts/sun4i-a10.dtsi | 8 1 file

[PATCH v4 2/6] ARM: dts: sun4i: Add CAN node

The A10 SoC has an on-board CAN controller. This patch adds the device node. This patch is adapted from the description in Documentation/devicetree/bindings/net/can/sun4i_can.txt Signed-off-by: Patrick Menschel --- arch/arm/boot/dts/sun4i-a10.dtsi | 8 1 file changed, 8 insertions(+)

Re: [PATCH v6 2/4] x86/syscalls: Specific usage of verify_pre_usermode_state

On 04/04/17 10:47, Thomas Garnier wrote: > Implement specific usage of verify_pre_usermode_state for user-mode > returns for x86. > > Signed-off-by: Thomas Garnier > > + /* > + * If address limit is not based on user-mode, jump to slow path for > + *

Re: [PATCH v6 2/4] x86/syscalls: Specific usage of verify_pre_usermode_state

On 04/04/17 10:47, Thomas Garnier wrote: > Implement specific usage of verify_pre_usermode_state for user-mode > returns for x86. > > Signed-off-by: Thomas Garnier > > + /* > + * If address limit is not based on user-mode, jump to slow path for > + * additional security checks. >

[RFC net-next] bpf: taint loading !is_gpl programs

The eBPF framework is used for more than just socket level filtering. It can also provide tracing, and even change the way packets coming into the system look. Most of the eBPF callable symbols are available to non-gpl programs, and this includes helper functions which modify packets. This

[RFC net-next] bpf: taint loading !is_gpl programs

The eBPF framework is used for more than just socket level filtering. It can also provide tracing, and even change the way packets coming into the system look. Most of the eBPF callable symbols are available to non-gpl programs, and this includes helper functions which modify packets. This

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Tue, 4 Apr 2017, Andy Shevchenko wrote: > On Tue, Apr 4, 2017 at 8:59 PM, Tom Zanussi > wrote: > > On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote: > >> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi > >> wrote: > >> > On Tue,

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, Mar 30, 2017 at 02:35:32PM -0400, Jeff Layton wrote: > On Thu, 2017-03-30 at 12:12 -0400, J. Bruce Fields wrote: > > On Thu, Mar 30, 2017 at 07:11:48AM -0400, Jeff Layton wrote: > > > On Thu, 2017-03-30 at 08:47 +0200, Jan Kara wrote: > > > > Because if above is acceptable we could make

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Tue, 4 Apr 2017, Andy Shevchenko wrote: > On Tue, Apr 4, 2017 at 8:59 PM, Tom Zanussi > wrote: > > On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote: > >> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi > >> wrote: > >> > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote: > > >>

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, Mar 30, 2017 at 02:35:32PM -0400, Jeff Layton wrote: > On Thu, 2017-03-30 at 12:12 -0400, J. Bruce Fields wrote: > > On Thu, Mar 30, 2017 at 07:11:48AM -0400, Jeff Layton wrote: > > > On Thu, 2017-03-30 at 08:47 +0200, Jan Kara wrote: > > > > Because if above is acceptable we could make

Re: [PATCH] dt-bindings: display: rk3288-mipi-dsi: add reset property

On Tue, Apr 04, 2017 at 02:15:13PM +0100, John Keeping wrote: > Hi Sean, > > On Sun, 12 Mar 2017 07:06:59 -0500, Rob Herring wrote: > > > On Fri, Mar 03, 2017 at 11:39:45AM +, John Keeping wrote: > > > This reset is required in order to fully reset the internal state of the > > > MIPI

Re: [PATCH] dt-bindings: display: rk3288-mipi-dsi: add reset property

On Tue, Apr 04, 2017 at 02:15:13PM +0100, John Keeping wrote: > Hi Sean, > > On Sun, 12 Mar 2017 07:06:59 -0500, Rob Herring wrote: > > > On Fri, Mar 03, 2017 at 11:39:45AM +, John Keeping wrote: > > > This reset is required in order to fully reset the internal state of the > > > MIPI

Re: [PATCH 0/6] mm: make movable onlining suck less

On Tue, Apr 04, 2017 at 06:44:53PM +0200, Michal Hocko wrote: Thanks for your testing! This is highly appreciated. Can I assume your Tested-by? Of course! Not quite done, though. I think I found another edge case. You get an oops when removing all of a node's memory: __nr_to_section

Re: [PATCH 0/6] mm: make movable onlining suck less

On Tue, Apr 04, 2017 at 06:44:53PM +0200, Michal Hocko wrote: Thanks for your testing! This is highly appreciated. Can I assume your Tested-by? Of course! Not quite done, though. I think I found another edge case. You get an oops when removing all of a node's memory: __nr_to_section

Re: [PATCH] drivers/staging/lustre: Replacing 'unsigned' with 'unsigned int'

On Tue, Apr 04, 2017 at 03:14:03PM +0530, Pushkar Jambhlekar wrote: > Replacing 'unsigned' with 'unsigned int' Why? You need to explain why you do something, not just say what you did (that should be obvious if you read the patch...) thanks, greg k-h

Re: [PATCH] drivers/staging/lustre: Replacing 'unsigned' with 'unsigned int'

On Tue, Apr 04, 2017 at 03:14:03PM +0530, Pushkar Jambhlekar wrote: > Replacing 'unsigned' with 'unsigned int' Why? You need to explain why you do something, not just say what you did (that should be obvious if you read the patch...) thanks, greg k-h

Re: [PATCH v6 1/4] dt-bindings: phy: Add support for QUSB2 phy

On 03/20, Vivek Gautam wrote: > diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt > b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt > new file mode 100644 > index ..a6d19acde9e0 > --- /dev/null > +++

Re: [PATCH v6 1/4] dt-bindings: phy: Add support for QUSB2 phy

On 03/20, Vivek Gautam wrote: > diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt > b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt > new file mode 100644 > index ..a6d19acde9e0 > --- /dev/null > +++

Re: [PATCH] padata: avoid race in reordering

On Tue, Apr 04, 2017 at 01:53:15PM +0200, Jason A. Donenfeld wrote: > Herbert applied this to his tree. It's probably a good stable > candidate, since it's a two line change to fix a race condition. > > On Fri, Mar 24, 2017 at 3:16 PM, Herbert Xu > wrote: > > Jason

Re: [PATCH] padata: avoid race in reordering

On Tue, Apr 04, 2017 at 01:53:15PM +0200, Jason A. Donenfeld wrote: > Herbert applied this to his tree. It's probably a good stable > candidate, since it's a two line change to fix a race condition. > > On Fri, Mar 24, 2017 at 3:16 PM, Herbert Xu > wrote: > > Jason A. Donenfeld wrote: > >>

Re: [PATCH] perf/x86: fix spurious NMI with PEBS Load Latency event

On Tue, Apr 4, 2017 at 10:52 AM, wrote: > From: Kan Liang > > Spurious NMIs will be observed when applying the following command. >while true ; do sudo perf record -b -a -e >"cpu/umask=0x01,event=0xcd,ldlat=0x80/pp,cpu/umask=0x03,event=0x0/, >

Re: [PATCH] perf/x86: fix spurious NMI with PEBS Load Latency event

On Tue, Apr 4, 2017 at 10:52 AM, wrote: > From: Kan Liang > > Spurious NMIs will be observed when applying the following command. >while true ; do sudo perf record -b -a -e >"cpu/umask=0x01,event=0xcd,ldlat=0x80/pp,cpu/umask=0x03,event=0x0/, >

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