Re: WARNING at arch/x86/kernel/alternative.c:707 text_poke+0x25d/0x270

On Tue, 16 May 2017 09:48:02 -0400 Steven Rostedt wrote: > Hi Masami, > > Thomas hit the following bug: > > [ 169.795937] trace_kprobe: Testing kprobe tracing: OK > [ 169.833031] rtc_cmos 00:00: setting system clock to 2017-05-16 13:19:26 > UTC (1494940766) > [

Re: [RFC/RFT PATCH v2 3/3] PCI/ACPI: Add ACPI pci_bus_find_numa_node() implementation

On 15.05.17 14:22:05, Lorenzo Pieralisi wrote: > The introduction of pci_bus_find_numa_node(pci_bus) allows at PCI > host bridge registration to detect the NUMA node for a given > struct pci_bus.dev. Implement an ACPI method that, through > the struct pci_bus.bridge ACPI companion, retrieve and

Re: [GIT PULL] Please pull NFS client fixes for 4.12

On Thu, 11 May 2017 13:10:03 + Trond Myklebust wrote: > If we suspect the existence of a load of potential time bombs in the > kernel due to missing checks, then the status quo is not good enough. > We should be working on tools to identify these code paths. > >

Re: [RFC/RFT PATCH v2 3/3] PCI/ACPI: Add ACPI pci_bus_find_numa_node() implementation

On 15.05.17 14:22:05, Lorenzo Pieralisi wrote: > The introduction of pci_bus_find_numa_node(pci_bus) allows at PCI > host bridge registration to detect the NUMA node for a given > struct pci_bus.dev. Implement an ACPI method that, through > the struct pci_bus.bridge ACPI companion, retrieve and

Re: [GIT PULL] Please pull NFS client fixes for 4.12

On Thu, 11 May 2017 13:10:03 + Trond Myklebust wrote: > If we suspect the existence of a load of potential time bombs in the > kernel due to missing checks, then the status quo is not good enough. > We should be working on tools to identify these code paths. > > Quite frankly, I'd love to

Re: WARNING at arch/x86/kernel/alternative.c:707 text_poke+0x25d/0x270

On Tue, 16 May 2017 09:48:02 -0400 Steven Rostedt wrote: > Hi Masami, > > Thomas hit the following bug: > > [ 169.795937] trace_kprobe: Testing kprobe tracing: OK > [ 169.833031] rtc_cmos 00:00: setting system clock to 2017-05-16 13:19:26 > UTC (1494940766) > [ 169.833986] PM: Hibernation

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Tue, May 16, 2017 at 4:23 PM, Stanislaw Gruszka wrote: > On Tue, May 16, 2017 at 01:55:17PM +0200, Stanislaw Gruszka wrote: >> On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: >> > From: Stanislaw Gruszka >> > Date: Mon, 15 May 2017

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Tue, May 16, 2017 at 4:23 PM, Stanislaw Gruszka wrote: > On Tue, May 16, 2017 at 01:55:17PM +0200, Stanislaw Gruszka wrote: >> On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: >> > From: Stanislaw Gruszka >> > Date: Mon, 15 May 2017 16:28:01 +0200 >> > >> > > On Mon, May 15, 2017

Re: [PATCH 06/21] VFS: Introduce a superblock configuration context [ver #3]

On Mon, May 15, 2017 at 5:19 PM, David Howells wrote: > Introduce a superblock configuration context concept to be used during > superblock creation for mount and superblock reconfiguration for remount. > This is allocated at the beginning of the mount procedure and into it

Re: [PATCH 06/21] VFS: Introduce a superblock configuration context [ver #3]

On Mon, May 15, 2017 at 5:19 PM, David Howells wrote: > Introduce a superblock configuration context concept to be used during > superblock creation for mount and superblock reconfiguration for remount. > This is allocated at the beginning of the mount procedure and into it is > placed: > > (1)

Re: [PATCH] ARM: dts: dra7: Add power hold and power controller properties to palmas

* Keerthy [170412 21:55]: > Add power hold and power controller properties to palmas node. > This is needed to shutdown pmic correctly on boards with > powerhold set. Applying into omap-for-v4.12/fixes. Thanks, Tony

Re: [PATCH] ARM: dts: dra7: Add power hold and power controller properties to palmas

* Keerthy [170412 21:55]: > Add power hold and power controller properties to palmas node. > This is needed to shutdown pmic correctly on boards with > powerhold set. Applying into omap-for-v4.12/fixes. Thanks, Tony

Re: drivers/net/hamradio: divide error in hdlcdrv_ioctl

On Tue, May 16, 2017 at 5:05 PM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6 (4.12-rc1). > > A reproducer and .config are attached. +syzkaller > >

Re: drivers/net/hamradio: divide error in hdlcdrv_ioctl

On Tue, May 16, 2017 at 5:05 PM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6 (4.12-rc1). > > A reproducer and .config are attached. +syzkaller > > divide error: [#1]

RE: [PATCH 1/2] PCI/portdrv: add support for different MSI interrupts for PCIe port services

Hi Christoph Many thanks for your comments > -Original Message- > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: 16 May 2017 13:07 > To: Gabriele Paoloni > Cc: bhelg...@google.com; helg...@kernel.org; Linuxarm; linux- > p...@vger.kernel.org; lu...@wunner.de;

RE: [PATCH 1/2] PCI/portdrv: add support for different MSI interrupts for PCIe port services

Hi Christoph Many thanks for your comments > -Original Message- > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: 16 May 2017 13:07 > To: Gabriele Paoloni > Cc: bhelg...@google.com; helg...@kernel.org; Linuxarm; linux- > p...@vger.kernel.org; lu...@wunner.de;

[GIT PULL] EDAC fix for 4.12

Hi Linus, please pull a single fix for amd64_edac. Thanks. --- The following changes since commit f8d5549df25e3961d6bd2ae36d3e0b08614660d9: EDAC, ghes: Do not enable it by default (2017-04-27 14:15:38 +0200) are available in the git repository at:

[GIT PULL] EDAC fix for 4.12

Hi Linus, please pull a single fix for amd64_edac. Thanks. --- The following changes since commit f8d5549df25e3961d6bd2ae36d3e0b08614660d9: EDAC, ghes: Do not enable it by default (2017-04-27 14:15:38 +0200) are available in the git repository at:

[PATCH] MAINTAINERS: update RTC mailing list

The RTC subsystem mailing list is moving to vger. Signed-off-by: Alexandre Belloni --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index f7d568b8f133..b3863ec142d7 100644 --- a/MAINTAINERS

[PATCH] MAINTAINERS: update RTC mailing list

The RTC subsystem mailing list is moving to vger. Signed-off-by: Alexandre Belloni --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index f7d568b8f133..b3863ec142d7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10447,7 +10447,7

Re: [RFC v1 2/3] interconnect: Add Qualcomm msm8916 interconnect provider driver

On 05/15/2017 07:01 PM, Geert Uytterhoeven wrote: > Hi Georgi, > > On Mon, May 15, 2017 at 5:35 PM, Georgi Djakov > wrote: >> --- /dev/null >> +++ b/drivers/interconnect/qcom/interconnect_msm8916.c > >> +struct qcom_interconnect_node { >> + struct

Re: [RFC v1 2/3] interconnect: Add Qualcomm msm8916 interconnect provider driver

On 05/15/2017 07:01 PM, Geert Uytterhoeven wrote: > Hi Georgi, > > On Mon, May 15, 2017 at 5:35 PM, Georgi Djakov > wrote: >> --- /dev/null >> +++ b/drivers/interconnect/qcom/interconnect_msm8916.c > >> +struct qcom_interconnect_node { >> + struct interconnect_node node; >> +

Re: [RFC/RFT PATCH v2 0/3] PCI: generic device NUMA node detection

On 15.05.17 14:22:02, Lorenzo Pieralisi wrote: > This patch series is v2 of a previous posting: > > v1 -> v2: > > - Added missing call to acpi_pci_bus_find_numa_node() > - Rebased against v4.12-rc1 > > v1: https://lkml.org/lkml/2017/4/26/211 > > On the ARM64 architecture, the arch specific PCI

Re: [RFC/RFT PATCH v2 0/3] PCI: generic device NUMA node detection

On 15.05.17 14:22:02, Lorenzo Pieralisi wrote: > This patch series is v2 of a previous posting: > > v1 -> v2: > > - Added missing call to acpi_pci_bus_find_numa_node() > - Rebased against v4.12-rc1 > > v1: https://lkml.org/lkml/2017/4/26/211 > > On the ARM64 architecture, the arch specific PCI

Re: [PATCH] scsi: sg: Fix mismatch in sg_get_rq_mark

On Tue, May 16, 2017 at 4:52 PM, wrote: > From: Firo Yang > > This bug was reported by Andrey Konovalov with syzkaller: > > Call Trace: > sg_finish_rem_req+0x2a6/0x320 drivers/scsi/sg.c:1839 > sg_new_read+0x3c/0x430 drivers/scsi/sg.c:567 >

Re: [PATCH] scsi: sg: Fix mismatch in sg_get_rq_mark

On Tue, May 16, 2017 at 4:52 PM, wrote: > From: Firo Yang > > This bug was reported by Andrey Konovalov with syzkaller: > > Call Trace: > sg_finish_rem_req+0x2a6/0x320 drivers/scsi/sg.c:1839 > sg_new_read+0x3c/0x430 drivers/scsi/sg.c:567 > sg_read+0x866/0x1830 drivers/scsi/sg.c:455 >

Re: [PATCH 2/4] thp: fix MADV_DONTNEED vs. numa balancing race

On 04/12/2017 03:33 PM, Vlastimil Babka wrote: > On 03/02/2017 04:10 PM, Kirill A. Shutemov wrote: >> In case prot_numa, we are under down_read(mmap_sem). It's critical >> to not clear pmd intermittently to avoid race with MADV_DONTNEED >> which is also under down_read(mmap_sem): >> >> CPU0:

Re: [PATCH 2/4] thp: fix MADV_DONTNEED vs. numa balancing race

On 04/12/2017 03:33 PM, Vlastimil Babka wrote: > On 03/02/2017 04:10 PM, Kirill A. Shutemov wrote: >> In case prot_numa, we are under down_read(mmap_sem). It's critical >> to not clear pmd intermittently to avoid race with MADV_DONTNEED >> which is also under down_read(mmap_sem): >> >> CPU0:

[PATCH] scsi: sg: Fix mismatch in sg_get_rq_mark

From: Firo Yang This bug was reported by Andrey Konovalov with syzkaller: Call Trace: sg_finish_rem_req+0x2a6/0x320 drivers/scsi/sg.c:1839 sg_new_read+0x3c/0x430 drivers/scsi/sg.c:567 sg_read+0x866/0x1830 drivers/scsi/sg.c:455 __vfs_read+0x5c3/0x750 fs/read_write.c:450

[PATCH] scsi: sg: Fix mismatch in sg_get_rq_mark

From: Firo Yang This bug was reported by Andrey Konovalov with syzkaller: Call Trace: sg_finish_rem_req+0x2a6/0x320 drivers/scsi/sg.c:1839 sg_new_read+0x3c/0x430 drivers/scsi/sg.c:567 sg_read+0x866/0x1830 drivers/scsi/sg.c:455 __vfs_read+0x5c3/0x750 fs/read_write.c:450 vfs_read+0x11e/0x350

Re: [PATCH v5 23/32] swiotlb: Add warnings for use of bounce buffers with SME

On Tue, Apr 18, 2017 at 04:20:19PM -0500, Tom Lendacky wrote: > Add warnings to let the user know when bounce buffers are being used for > DMA when SME is active. Since the bounce buffers are not in encrypted > memory, these notifications are to allow the user to determine some > appropriate

Re: [PATCH v5 23/32] swiotlb: Add warnings for use of bounce buffers with SME

On Tue, Apr 18, 2017 at 04:20:19PM -0500, Tom Lendacky wrote: > Add warnings to let the user know when bounce buffers are being used for > DMA when SME is active. Since the bounce buffers are not in encrypted > memory, these notifications are to allow the user to determine some > appropriate

[PATCH] powerpc: booke: fix boot crash due to null hugepd

From: Laurentiu Tudor On 32-bit book-e machines, hugepd_ok() does not take into account null hugepd values, causing this crash at boot: Unable to handle kernel paging request for data at address 0x8000 Faulting instruction address: 0xc00182a8 Oops: Kernel access of

[PATCH] powerpc: booke: fix boot crash due to null hugepd

From: Laurentiu Tudor On 32-bit book-e machines, hugepd_ok() does not take into account null hugepd values, causing this crash at boot: Unable to handle kernel paging request for data at address 0x8000 Faulting instruction address: 0xc00182a8 Oops: Kernel access of bad area, sig: 11 [#1]

Re: [PATCH V16 10/11] trace, ras: add ARM processor error trace event

On Mon, May 15, 2017 at 03:27:59PM -0600, Tyler Baicar wrote: > Currently there are trace events for the various RAS > errors with the exception of ARM processor type errors. > Add a new trace event for such errors so that the user > will know when they occur. These trace events are > consistent

Re: [PATCH V16 10/11] trace, ras: add ARM processor error trace event

On Mon, May 15, 2017 at 03:27:59PM -0600, Tyler Baicar wrote: > Currently there are trace events for the various RAS > errors with the exception of ARM processor type errors. > Add a new trace event for such errors so that the user > will know when they occur. These trace events are > consistent

Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

On Fri 2017-05-05 21:07:47, Greg KH wrote: > From: Chris Fries > > Add %paP and %padP for physical address that need to always be shown > regardless of kptr restrictions. > > Cc: William Roberts > Cc: Dave Weinstein >

Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

On Fri 2017-05-05 21:07:47, Greg KH wrote: > From: Chris Fries > > Add %paP and %padP for physical address that need to always be shown > regardless of kptr restrictions. > > Cc: William Roberts > Cc: Dave Weinstein > Signed-off-by: Chris Fries > Signed-off-by: Greg Kroah-Hartman > --- >

Re: [PATCH v2] perf report: fix off-by-one for non-activation frames

On Tue, May 16, 2017 at 10:59:51AM +0200, Milian Wolff wrote: > As the documentation for dwfl_frame_pc says, frames that > are no activation frames need to have their program counter > decremented by one to properly find the function of the caller. > > This fixes many cases where perf report

Re: [PATCH v2] perf report: fix off-by-one for non-activation frames

On Tue, May 16, 2017 at 10:59:51AM +0200, Milian Wolff wrote: > As the documentation for dwfl_frame_pc says, frames that > are no activation frames need to have their program counter > decremented by one to properly find the function of the caller. > > This fixes many cases where perf report

Re: [PATCH] perf/x86/intel/cqm: Make sure the head event of cache_groups always has valid RMID

On Thu, May 04, 2017 at 10:31:43AM +0800, Zefan Li wrote: > It is assumed that the head of cache_groups always has valid RMID, > which isn't true. > > When we deallocate RMID from conflicting events currently we don't > move them to the tail, and one of those events can happen to be in > the

Re: [PATCH] perf/x86/intel/cqm: Make sure the head event of cache_groups always has valid RMID

On Thu, May 04, 2017 at 10:31:43AM +0800, Zefan Li wrote: > It is assumed that the head of cache_groups always has valid RMID, > which isn't true. > > When we deallocate RMID from conflicting events currently we don't > move them to the tail, and one of those events can happen to be in > the

Re: [PATCH 5/5] mmc: cavium: Fix probing race with regulator

On Tue, May 16, 2017 at 8:38 AM, Jan Glauber wrote: > On Tue, May 16, 2017 at 08:07:50AM -0500, Rob Herring wrote: >> On Tue, May 16, 2017 at 4:36 AM, Jan Glauber wrote: >> > If the regulator probing is not yet finished this driver >> > might

Re: [PATCH 5/5] mmc: cavium: Fix probing race with regulator

On Tue, May 16, 2017 at 8:38 AM, Jan Glauber wrote: > On Tue, May 16, 2017 at 08:07:50AM -0500, Rob Herring wrote: >> On Tue, May 16, 2017 at 4:36 AM, Jan Glauber wrote: >> > If the regulator probing is not yet finished this driver >> > might catch a -EPROBE_DEFER. Returning after this condition

Re: [PATCH V16 09/11] ras: acpi / apei: generate trace event for unrecognized CPER section

On Mon, May 15, 2017 at 03:27:58PM -0600, Tyler Baicar wrote: > The UEFI spec includes non-standard section type support in the > Common Platform Error Record. This is defined in section N.2.3 of > UEFI version 2.5. > > Currently if the CPER section's type (UUID) does not match any > section type

Re: [PATCH V16 09/11] ras: acpi / apei: generate trace event for unrecognized CPER section

On Mon, May 15, 2017 at 03:27:58PM -0600, Tyler Baicar wrote: > The UEFI spec includes non-standard section type support in the > Common Platform Error Record. This is defined in section N.2.3 of > UEFI version 2.5. > > Currently if the CPER section's type (UUID) does not match any > section type

Re: [RFC PATCH] fs: ext4: don't trap kswapd and allocating tasks on ext4 inode IO

On Mon 15-05-17 11:46:34, Johannes Weiner wrote: > We have observed across several workloads situations where kswapd and > direct reclaimers get stuck in the inode shrinker of the ext4 / mount, > causing allocation latencies across tasks in the system, while there > are dozens of gigabytes of

Re: [RFC PATCH] fs: ext4: don't trap kswapd and allocating tasks on ext4 inode IO

On Mon 15-05-17 11:46:34, Johannes Weiner wrote: > We have observed across several workloads situations where kswapd and > direct reclaimers get stuck in the inode shrinker of the ext4 / mount, > causing allocation latencies across tasks in the system, while there > are dozens of gigabytes of

Re: [PATCH 42/48] clocksource/drivers: Add a new driver for the Atmel ARM TC blocks

On 16/05/2017 at 16:25:04 +0200, Daniel Lezcano wrote: > On 16/05/2017 13:59, Alexandre Belloni wrote: > > Hi Daniel, > > > > Almost one year later, I'm back on that topic. > > > > On 24/06/2016 at 12:07:01 +0200, Daniel Lezcano wrote: > >>> diff --git a/drivers/clocksource/Kconfig

Re: [PATCH 42/48] clocksource/drivers: Add a new driver for the Atmel ARM TC blocks

On 16/05/2017 at 16:25:04 +0200, Daniel Lezcano wrote: > On 16/05/2017 13:59, Alexandre Belloni wrote: > > Hi Daniel, > > > > Almost one year later, I'm back on that topic. > > > > On 24/06/2016 at 12:07:01 +0200, Daniel Lezcano wrote: > >>> diff --git a/drivers/clocksource/Kconfig

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On 05/16/2017 10:19 AM, Arnd Bergmann wrote: On Tue, May 16, 2017 at 3:44 PM, Jes Sorensen wrote: On 05/16/2017 07:55 AM, Stanislaw Gruszka wrote: On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: Passing return values by reference is and always has been

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On 05/16/2017 10:19 AM, Arnd Bergmann wrote: On Tue, May 16, 2017 at 3:44 PM, Jes Sorensen wrote: On 05/16/2017 07:55 AM, Stanislaw Gruszka wrote: On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: Passing return values by reference is and always has been a really poor way to

Re: [PATCH V16 08/11] efi: print unrecognized CPER section

On Mon, May 15, 2017 at 03:27:57PM -0600, Tyler Baicar wrote: > UEFI spec allows for non-standard section in Common Platform Error > Record. This is defined in section N.2.3 of UEFI version 2.5. > > Currently if the CPER section's type (UUID) does not match with > one of the section types that

Re: [PATCH V16 08/11] efi: print unrecognized CPER section

On Mon, May 15, 2017 at 03:27:57PM -0600, Tyler Baicar wrote: > UEFI spec allows for non-standard section in Common Platform Error > Record. This is defined in section N.2.3 of UEFI version 2.5. > > Currently if the CPER section's type (UUID) does not match with > one of the section types that

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, May 16, 2017 at 5:22 AM, Matt Brown wrote: > On 05/16/2017 05:01 AM, Peter Dolding wrote: >>> >>> >>> I could see a case being make for CAP_SYS_TTY_CONFIG. However I still >>> choose to do with CAP_SYS_ADMIN because it is already in use in the >>> TIOCSTI ioctl. >>> >>

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, May 16, 2017 at 5:22 AM, Matt Brown wrote: > On 05/16/2017 05:01 AM, Peter Dolding wrote: >>> >>> >>> I could see a case being make for CAP_SYS_TTY_CONFIG. However I still >>> choose to do with CAP_SYS_ADMIN because it is already in use in the >>> TIOCSTI ioctl. >>> >> Matt Brown don't

Re: [PATCH v5 22/32] x86, swiotlb: DMA support for memory encryption

On Tue, Apr 18, 2017 at 04:20:10PM -0500, Tom Lendacky wrote: > Since DMA addresses will effectively look like 48-bit addresses when the > memory encryption mask is set, SWIOTLB is needed if the DMA mask of the > device performing the DMA does not support 48-bits. SWIOTLB will be > initialized to

Re: [PATCH v5 22/32] x86, swiotlb: DMA support for memory encryption

On Tue, Apr 18, 2017 at 04:20:10PM -0500, Tom Lendacky wrote: > Since DMA addresses will effectively look like 48-bit addresses when the > memory encryption mask is set, SWIOTLB is needed if the DMA mask of the > device performing the DMA does not support 48-bits. SWIOTLB will be > initialized to

Re: [RFC][PATCH 0/5] perf/tracing/cpuhotplug: Fix locking order

On Tue, May 16, 2017 at 05:46:06AM -0700, Paul E. McKenney wrote: > On Tue, May 16, 2017 at 10:19:23AM +0200, Peter Zijlstra wrote: > > On Mon, May 15, 2017 at 11:40:43AM -0700, Paul E. McKenney wrote: > > > > > Given that you acquire the global pmus_lock when doing the > > > get_online_cpus(),

Re: [RFC][PATCH 0/5] perf/tracing/cpuhotplug: Fix locking order

On Tue, May 16, 2017 at 05:46:06AM -0700, Paul E. McKenney wrote: > On Tue, May 16, 2017 at 10:19:23AM +0200, Peter Zijlstra wrote: > > On Mon, May 15, 2017 at 11:40:43AM -0700, Paul E. McKenney wrote: > > > > > Given that you acquire the global pmus_lock when doing the > > > get_online_cpus(),

[PATCH 4.4-only] openvswitch: clear sender cpu before forwarding packets

Similar to commit c29390c6dfee ("xps: must clear sender_cpu before forwarding") the skb->sender_cpu needs to be cleared before forwarding packets. Fixes: 2bd82484bb4c ("xps: fix xps for stacked devices") Signed-off-by: Anoob Soman --- net/openvswitch/vport.c | 1 + 1

[PATCH 4.4-only] openvswitch: clear sender cpu before forwarding packets

Similar to commit c29390c6dfee ("xps: must clear sender_cpu before forwarding") the skb->sender_cpu needs to be cleared before forwarding packets. Fixes: 2bd82484bb4c ("xps: fix xps for stacked devices") Signed-off-by: Anoob Soman --- net/openvswitch/vport.c | 1 + 1 file changed, 1

Re: [PATCH 3/4] selftests/ftrace: Fix bashisms

On Mon, 15 May 2017 11:16:30 -0400 Steven Rostedt wrote: > > Masami's the original author of ftracetest. > > Masami, are you OK with this change? > > -- Steve > > > On Sun, 14 May 2017 01:01:03 +0530 > "Naveen N. Rao" wrote: > > > Fix

Re: [PATCH 3/4] selftests/ftrace: Fix bashisms

On Mon, 15 May 2017 11:16:30 -0400 Steven Rostedt wrote: > > Masami's the original author of ftracetest. > > Masami, are you OK with this change? > > -- Steve > > > On Sun, 14 May 2017 01:01:03 +0530 > "Naveen N. Rao" wrote: > > > Fix a few bashisms in ftrace selftests. Ah, what's a nice

Re: [PATCH 42/48] clocksource/drivers: Add a new driver for the Atmel ARM TC blocks

On 16/05/2017 13:59, Alexandre Belloni wrote: > Hi Daniel, > > Almost one year later, I'm back on that topic. > > On 24/06/2016 at 12:07:01 +0200, Daniel Lezcano wrote: >>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig >>> index 47352d25c15e..ff7f4022c749 100644 >>> ---

Re: [PATCH 42/48] clocksource/drivers: Add a new driver for the Atmel ARM TC blocks

On 16/05/2017 13:59, Alexandre Belloni wrote: > Hi Daniel, > > Almost one year later, I'm back on that topic. > > On 24/06/2016 at 12:07:01 +0200, Daniel Lezcano wrote: >>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig >>> index 47352d25c15e..ff7f4022c749 100644 >>> ---

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Tue, May 16, 2017 at 01:55:17PM +0200, Stanislaw Gruszka wrote: > On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: > > From: Stanislaw Gruszka > > Date: Mon, 15 May 2017 16:28:01 +0200 > > > > > On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote: >

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Tue, May 16, 2017 at 01:55:17PM +0200, Stanislaw Gruszka wrote: > On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: > > From: Stanislaw Gruszka > > Date: Mon, 15 May 2017 16:28:01 +0200 > > > > > On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote: > > >> With

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Tue, May 16, 2017 at 3:44 PM, Jes Sorensen wrote: > On 05/16/2017 07:55 AM, Stanislaw Gruszka wrote: >> >> On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: >>> >>> Passing return values by reference is and always has been a really >>> poor way to achieve

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On Tue, May 16, 2017 at 3:44 PM, Jes Sorensen wrote: > On 05/16/2017 07:55 AM, Stanislaw Gruszka wrote: >> >> On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: >>> >>> Passing return values by reference is and always has been a really >>> poor way to achieve what these functions are

Re: [PATCH v6 05/15] lockdep: Implement crossrelease feature

On Tue, Apr 25, 2017 at 02:40:44PM +0900, Byungchul Park wrote: > On Mon, Apr 24, 2017 at 12:17:47PM +0200, Peter Zijlstra wrote: > > My complaint is mostly about naming.. and "hist_gen_id" might be a > > better name. > > Ah, I also think the name, 'work_id', is not good... and frankly I am >

Re: [PATCH v6 05/15] lockdep: Implement crossrelease feature

On Tue, Apr 25, 2017 at 02:40:44PM +0900, Byungchul Park wrote: > On Mon, Apr 24, 2017 at 12:17:47PM +0200, Peter Zijlstra wrote: > > My complaint is mostly about naming.. and "hist_gen_id" might be a > > better name. > > Ah, I also think the name, 'work_id', is not good... and frankly I am >

[PATCHv5] arm64/cpufeature: don't use mutex in bringup path

Currently, cpus_set_cap() calls static_branch_enable_cpuslocked(), which must take the jump_label mutex. We call cpus_set_cap() in the secondary bringup path, from the idle thread where interrupts are disabled. Taking a mutex in this path "is a NONO" regardless of whether it's contended, and

[PATCHv5] arm64/cpufeature: don't use mutex in bringup path

Currently, cpus_set_cap() calls static_branch_enable_cpuslocked(), which must take the jump_label mutex. We call cpus_set_cap() in the secondary bringup path, from the idle thread where interrupts are disabled. Taking a mutex in this path "is a NONO" regardless of whether it's contended, and

Re: [PATCH] iommu: of: Fix check for returning EPROBE_DEFER

Hi, I have a few suggestions on how to make this commit message more readable: On Tue, May 16, 2017 at 10:54:13AM +0530, Sricharan R wrote: > While returning EPROBE_DEFER for iommu masters Add a comma at the end of this line > take in to account of iommu nodes that could be s/in to/into/ s/of

Re: [PATCH] iommu: of: Fix check for returning EPROBE_DEFER

Hi, I have a few suggestions on how to make this commit message more readable: On Tue, May 16, 2017 at 10:54:13AM +0530, Sricharan R wrote: > While returning EPROBE_DEFER for iommu masters Add a comma at the end of this line > take in to account of iommu nodes that could be s/in to/into/ s/of

Re: frv build failure in mainline kernel

On 05/16/2017 05:44 AM, David Howells wrote: Guenter Roeck wrote: I assume declaring both __jiffy_data and cacheline_aligned_in_smp attributes doesn't work ? You should be able to stack attributes, I think. Turns out not here because cacheline_aligned_in_smp

Re: frv build failure in mainline kernel

On 05/16/2017 05:44 AM, David Howells wrote: Guenter Roeck wrote: I assume declaring both __jiffy_data and cacheline_aligned_in_smp attributes doesn't work ? You should be able to stack attributes, I think. Turns out not here because cacheline_aligned_in_smp includes

Re: [PATCH v5 19/32] x86/mm: Add support to access persistent memory in the clear

On Tue, Apr 18, 2017 at 04:19:42PM -0500, Tom Lendacky wrote: > Persistent memory is expected to persist across reboots. The encryption > key used by SME will change across reboots which will result in corrupted > persistent memory. Persistent memory is handed out by block devices > through

Re: [PATCH v5 19/32] x86/mm: Add support to access persistent memory in the clear

On Tue, Apr 18, 2017 at 04:19:42PM -0500, Tom Lendacky wrote: > Persistent memory is expected to persist across reboots. The encryption > key used by SME will change across reboots which will result in corrupted > persistent memory. Persistent memory is handed out by block devices > through

Re: [PATCH 0/2] KVM: nVMX: nested EPT fixes

2017-05-11 13:23+0200, Paolo Bonzini: > These two patches fix a couple corner cases identified by the new > tests in vmx.flat. See the individual patches for more information. > > Paolo > > Paolo Bonzini (2): > KVM: nVMX: fix EPT permissions as reported in exit qualification > KVM: nVMX:

Re: [PATCH 0/2] KVM: nVMX: nested EPT fixes

2017-05-11 13:23+0200, Paolo Bonzini: > These two patches fix a couple corner cases identified by the new > tests in vmx.flat. See the individual patches for more information. > > Paolo > > Paolo Bonzini (2): > KVM: nVMX: fix EPT permissions as reported in exit qualification > KVM: nVMX:

Re: [PATCH 2/4] ftrace/instances: Clear function triggers when removing instances

On 2017/05/15 10:20PM, Steven Rostedt wrote: > On Sun, 14 May 2017 01:01:02 +0530 > "Naveen N. Rao" wrote: > [snip] > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > > index c4536c449021..3f2aed4ad1ed 100644 > > --- a/kernel/trace/trace.c > > +++

Re: [PATCH 2/4] ftrace/instances: Clear function triggers when removing instances

On 2017/05/15 10:20PM, Steven Rostedt wrote: > On Sun, 14 May 2017 01:01:02 +0530 > "Naveen N. Rao" wrote: > [snip] > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > > index c4536c449021..3f2aed4ad1ed 100644 > > --- a/kernel/trace/trace.c > > +++ b/kernel/trace/trace.c > > @@

Re: [PATCH] X86: don't report PAT on CPUs that don't support it

On 04/18/17 12:07, Mikulas Patocka wrote: > > However, on AMD K6-3 CPU, the processor initialization code never calls > pat_init() and so __pat_enabled stays 1 and the function pat_enabled() > returns true, even though the K6-3 CPU doesn't support PAT. > OK, now I'm wondering: are you actually

Re: [PATCH] X86: don't report PAT on CPUs that don't support it

On 04/18/17 12:07, Mikulas Patocka wrote: > > However, on AMD K6-3 CPU, the processor initialization code never calls > pat_init() and so __pat_enabled stays 1 and the function pat_enabled() > returns true, even though the K6-3 CPU doesn't support PAT. > OK, now I'm wondering: are you actually

Re: [PATCH] iommu/iova: Sort out rbtree limit_pfn handling

- Original Message - > From: "Robin Murphy" > Sent: Tuesday, May 16, 2017 6:26:48 AM > When walking the rbtree, the fact that iovad->start_pfn and limit_pfn > are both inclusive limits creates an ambiguity once limit_pfn reaches > the bottom of the address space and

Re: [PATCH] iommu/iova: Sort out rbtree limit_pfn handling

- Original Message - > From: "Robin Murphy" > Sent: Tuesday, May 16, 2017 6:26:48 AM > When walking the rbtree, the fact that iovad->start_pfn and limit_pfn > are both inclusive limits creates an ambiguity once limit_pfn reaches > the bottom of the address space and they overlap. Commit

WARNING at arch/x86/kernel/alternative.c:707 text_poke+0x25d/0x270

Hi Masami, Thomas hit the following bug: [ 169.795937] trace_kprobe: Testing kprobe tracing: OK [ 169.833031] rtc_cmos 00:00: setting system clock to 2017-05-16 13:19:26 UTC (1494940766) [ 169.833986] PM: Hibernation image not present or could not be loaded. [ 169.836222] Freeing unused

WARNING at arch/x86/kernel/alternative.c:707 text_poke+0x25d/0x270

Hi Masami, Thomas hit the following bug: [ 169.795937] trace_kprobe: Testing kprobe tracing: OK [ 169.833031] rtc_cmos 00:00: setting system clock to 2017-05-16 13:19:26 UTC (1494940766) [ 169.833986] PM: Hibernation image not present or could not be loaded. [ 169.836222] Freeing unused

Re: [PATCH] nvmem: core: Prevent memory leak when device is unregistered

On Mon, May 15, 2017 at 02:13:23PM +0300, Mika Westerberg wrote: > The nvmem_unregister() calls device_del() for the device but forgets to > call put_device() to actually release the device object which causes > that memory to be leaked. > > Fix this by calling device_unregister() for the device

Re: [PATCH] nvmem: core: Prevent memory leak when device is unregistered

On Mon, May 15, 2017 at 02:13:23PM +0300, Mika Westerberg wrote: > The nvmem_unregister() calls device_del() for the device but forgets to > call put_device() to actually release the device object which causes > that memory to be leaked. > > Fix this by calling device_unregister() for the device

Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

On Tue, May 16, 2017 at 02:44:48PM +0200, Marcin Wojtas wrote: > Russel, > > 2017-05-16 14:13 GMT+02:00 Russell King - ARM Linux : > > On Tue, May 16, 2017 at 01:52:17PM +0200, Thomas Petazzoni wrote: > >> Hello, > >> > >> On Tue, 16 May 2017 11:02:37 +0100, Russell King -

Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

On Tue, May 16, 2017 at 02:44:48PM +0200, Marcin Wojtas wrote: > Russel, > > 2017-05-16 14:13 GMT+02:00 Russell King - ARM Linux : > > On Tue, May 16, 2017 at 01:52:17PM +0200, Thomas Petazzoni wrote: > >> Hello, > >> > >> On Tue, 16 May 2017 11:02:37 +0100, Russell King - ARM Linux wrote: > >> >

[PATCH] nvmem: core: fix leaks on registration errors

Make sure to deregister and release the nvmem device and underlying memory on registration errors. Note that the private data must be freed using put_device() once the struct device has been initialised. Also note that there's a related reference leak in the deregistration function as reported

[PATCH] nvmem: core: fix leaks on registration errors

Make sure to deregister and release the nvmem device and underlying memory on registration errors. Note that the private data must be freed using put_device() once the struct device has been initialised. Also note that there's a related reference leak in the deregistration function as reported

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On 05/16/2017 07:55 AM, Stanislaw Gruszka wrote: On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: Passing return values by reference is and always has been a really poor way to achieve what these functions are doing. And frankly, whilst the tool could see what's going on here

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On 05/16/2017 07:55 AM, Stanislaw Gruszka wrote: On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote: Passing return values by reference is and always has been a really poor way to achieve what these functions are doing. And frankly, whilst the tool could see what's going on here

Re: kmemleak splat on copy_process()

Thanks for cc'ing me. The vmalloc allocations have always been tricky for kmemleak since there are 2-3 other memory locations with the same value as the vmalloc'ed object: vm_struct.addr and vmap_area.va_start; occasionally we have vmap_area.va_end pointing to the next vmap_area.va_start. To have

Re: kmemleak splat on copy_process()

Thanks for cc'ing me. The vmalloc allocations have always been tricky for kmemleak since there are 2-3 other memory locations with the same value as the vmalloc'ed object: vm_struct.addr and vmap_area.va_start; occasionally we have vmap_area.va_end pointing to the next vmap_area.va_start. To have

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