Re: [GIT PULL] perf fixes

On Sat, Oct 20, 2018 at 10:10:39AM +0200, Ingo Molnar wrote: > Greg, > > Please pull the latest perf-urgent-for-linus git tree from: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > perf-urgent-for-linus Now merged, thanks. greg k-h

Re: [GIT PULL] x86 fixes

On Sat, Oct 20, 2018 at 10:54:25AM +0200, Ingo Molnar wrote: > Greg, > > Please pull the latest x86-urgent-for-linus git tree from: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > x86-urgent-for-linus Now merged, thanks. greg k-h

[PATCH 0/2] modpost: skip section mismatch warnings on ELF local symbols by default

modpost: skip section mismatch warnings on ELF local symbols by default modpost, by default, reports section mismatch warnings on ELF local symbols. This caused false positive warnings to be reported for a local symbol name that would otherwise be elided by matching against a name pattern. This

[PATCH 2/2] modpost: skip ELF local symbols by default during section mismatch check

During development of a serial console driver with a RISC-V toolchain, the following modpost warning appeared: WARNING: vmlinux.o(.data+0x19b10): Section mismatch in reference from the variable .LANCHOR1 to the function .init.text:sifive_serial_console_setup() The variable .LANCHOR1

[PATCH 1/2] modpost: add switch to skip symbol exclusions likely to generate false positives

modpost uses symbol name whitelist patterns to determine whether symbols should be excluded from section mismatch tests. Since ELF local symbols, empty symbol names, and ARM toolchain "magic" symbols have autogenerated symbol names, they can trigger false positive warnings for section mismatches,

[PATCH 0/2] modpost: skip section mismatch warnings on ELF local symbols by default

modpost: skip section mismatch warnings on ELF local symbols by default modpost, by default, reports section mismatch warnings on ELF local symbols. This caused false positive warnings to be reported for a local symbol name that would otherwise be elided by matching against a name pattern. This

[PATCH 2/2] modpost: skip ELF local symbols by default during section mismatch check

During development of a serial console driver with a RISC-V toolchain, the following modpost warning appeared: WARNING: vmlinux.o(.data+0x19b10): Section mismatch in reference from the variable .LANCHOR1 to the function .init.text:sifive_serial_console_setup() The variable .LANCHOR1

[PATCH 1/2] modpost: add switch to skip symbol exclusions likely to generate false positives

modpost uses symbol name whitelist patterns to determine whether symbols should be excluded from section mismatch tests. Since ELF local symbols, empty symbol names, and ARM toolchain "magic" symbols have autogenerated symbol names, they can trigger false positive warnings for section mismatches,

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On Sat, Oct 20, 2018 at 12:48:26PM +0100, Al Viro wrote: > Not just refcounting; it's that fs_pin is really intended to have ->kill() > triggered only once. If you look at the pin_kill() (which is where the > livelock happened) More specifically, it's group_pin_kill() assuming that by the time

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On Sat, Oct 20, 2018 at 12:48:26PM +0100, Al Viro wrote: > Not just refcounting; it's that fs_pin is really intended to have ->kill() > triggered only once. If you look at the pin_kill() (which is where the > livelock happened) More specifically, it's group_pin_kill() assuming that by the time

[PATCH] jffs2: ensure wbuf_verify is valid before using it.

Now MTD emulated by UBI volumn doesn't allocate wbuf_verify in jffs2_ubivol_setup(), because UBI can do the verifcation itself, so when CONFIG_JFFS2_FS_WBUF_VERIFY is enabled and a MTD device emulated by UBI volumn is used, a Oops will occur as show in the following trace: general protection

[PATCH] jffs2: ensure wbuf_verify is valid before using it.

Now MTD emulated by UBI volumn doesn't allocate wbuf_verify in jffs2_ubivol_setup(), because UBI can do the verifcation itself, so when CONFIG_JFFS2_FS_WBUF_VERIFY is enabled and a MTD device emulated by UBI volumn is used, a Oops will occur as show in the following trace: general protection

Re: Linux 4.18.16

diff --git a/Makefile b/Makefile index 968eb96a0553..034dd990b0ae 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 VERSION = 4 PATCHLEVEL = 18 -SUBLEVEL = 15 +SUBLEVEL = 16 EXTRAVERSION = NAME = Merciless Moray diff --git a/arch/arc/Makefile

Linux 4.18.16

I'm announcing the release of the 4.18.16 kernel. All users of the 4.18 kernel series must upgrade. The updated 4.18.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.18.y and can be browsed at the normal kernel.org git web

Re: Linux 4.14.78

diff --git a/Makefile b/Makefile index 16d1a18496fb..89574ee68d6b 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 VERSION = 4 PATCHLEVEL = 14 -SUBLEVEL = 77 +SUBLEVEL = 78 EXTRAVERSION = NAME = Petit Gorille diff --git a/arch/arc/Makefile

Re: Linux 4.18.16

diff --git a/Makefile b/Makefile index 968eb96a0553..034dd990b0ae 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 VERSION = 4 PATCHLEVEL = 18 -SUBLEVEL = 15 +SUBLEVEL = 16 EXTRAVERSION = NAME = Merciless Moray diff --git a/arch/arc/Makefile

Linux 4.18.16

I'm announcing the release of the 4.18.16 kernel. All users of the 4.18 kernel series must upgrade. The updated 4.18.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.18.y and can be browsed at the normal kernel.org git web

Re: Linux 4.14.78

diff --git a/Makefile b/Makefile index 16d1a18496fb..89574ee68d6b 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 VERSION = 4 PATCHLEVEL = 14 -SUBLEVEL = 77 +SUBLEVEL = 78 EXTRAVERSION = NAME = Petit Gorille diff --git a/arch/arc/Makefile

Linux 4.9.135

I'm announcing the release of the 4.9.135 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser:

Linux 4.14.78

I'm announcing the release of the 4.14.78 kernel. All users of the 4.14 kernel series must upgrade. The updated 4.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y and can be browsed at the normal kernel.org git web

Linux 4.9.135

I'm announcing the release of the 4.9.135 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser:

Linux 4.14.78

I'm announcing the release of the 4.14.78 kernel. All users of the 4.14 kernel series must upgrade. The updated 4.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y and can be browsed at the normal kernel.org git web

Linux 4.4.162

I'm announcing the release of the 4.4.162 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser:

Re: Linux 4.9.135

diff --git a/Makefile b/Makefile index 46135e4333e6..3678e4d19ebc 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ VERSION = 4 PATCHLEVEL = 9 -SUBLEVEL = 134 +SUBLEVEL = 135 EXTRAVERSION = NAME = Roaring Lionus diff --git a/arch/arc/Makefile b/arch/arc/Makefile index

Re: Linux 4.4.162

diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index b5d79761ac97..410c044166e2 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -8,6 +8,7 @@ Required properties:

Linux 4.4.162

I'm announcing the release of the 4.4.162 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser:

Re: Linux 4.9.135

diff --git a/Makefile b/Makefile index 46135e4333e6..3678e4d19ebc 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ VERSION = 4 PATCHLEVEL = 9 -SUBLEVEL = 134 +SUBLEVEL = 135 EXTRAVERSION = NAME = Roaring Lionus diff --git a/arch/arc/Makefile b/arch/arc/Makefile index

Re: Linux 4.4.162

diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index b5d79761ac97..410c044166e2 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -8,6 +8,7 @@ Required properties:

Re: [PATCH v2 1/3] mfd: upboard: Add UP2 platform controller driver

On Fri, Oct 19, 2018 at 8:26 PM Dan O'Donovan wrote: > > From: Javier Arteaga > > UP Squared (UP2) is a x86 SBC from AAEON based on Intel Apollo Lake. It > features a MAX 10 FPGA that routes lines from both SoC and on-board > devices to two I/O headers: > >

Re: [PATCH v2 1/3] mfd: upboard: Add UP2 platform controller driver

On Fri, Oct 19, 2018 at 8:26 PM Dan O'Donovan wrote: > > From: Javier Arteaga > > UP Squared (UP2) is a x86 SBC from AAEON based on Intel Apollo Lake. It > features a MAX 10 FPGA that routes lines from both SoC and on-board > devices to two I/O headers: > >

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On Sat, Oct 20, 2018 at 12:06:32PM +0100, Alan Jenkins wrote: > You posted an analysis of a GPF, where you showed the reference count was > clearly one less than it should have been.  You narrowed this down to a step > where you connected an unmounted mount (MNT_UMOUNT) to a mounted mount.  So >

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On Sat, Oct 20, 2018 at 12:06:32PM +0100, Alan Jenkins wrote: > You posted an analysis of a GPF, where you showed the reference count was > clearly one less than it should have been.  You narrowed this down to a step > where you connected an unmounted mount (MNT_UMOUNT) to a mounted mount.  So >

Memory management issue in 4.18.15

Hello, I have a workload, which creates lots of cache pages. Before 4.18.15, the behavior was very stable: pagecache is constantly growing until it consumes all the free memory, and then kswapd is balancing it around low watermark. After 4.18.15, once in a while khugepaged is waking up and

Memory management issue in 4.18.15

Hello, I have a workload, which creates lots of cache pages. Before 4.18.15, the behavior was very stable: pagecache is constantly growing until it consumes all the free memory, and then kswapd is balancing it around low watermark. After 4.18.15, once in a while khugepaged is waking up and

Re: [PATCH v2 3/3] pinctrl: upboard: Add UP2 pinctrl and gpio driver

On Fri, Oct 19, 2018 at 8:24 PM Dan O'Donovan wrote: > > From: Javier Arteaga > > The UP2 board features a Raspberry Pi compatible pin header (HAT) and a > board-specific expansion connector (EXHAT). Both expose assorted > functions from either the SoC (such as GPIO, I2C, SPI, UART...) or other

Re: [PATCH v2 3/3] pinctrl: upboard: Add UP2 pinctrl and gpio driver

On Fri, Oct 19, 2018 at 8:24 PM Dan O'Donovan wrote: > > From: Javier Arteaga > > The UP2 board features a Raspberry Pi compatible pin header (HAT) and a > board-specific expansion connector (EXHAT). Both expose assorted > functions from either the SoC (such as GPIO, I2C, SPI, UART...) or other

Re: [PATCH v2 2/3] leds: upboard: Add LED support

On Fri, Oct 19, 2018 at 8:27 PM Dan O'Donovan wrote: > > From: Javier Arteaga > > Allow userspace to use the on-board LEDs as "upboard::". > +#include > +#include > +#include > +#include > +#include > +#include > +#include For better maintenance keep this ordered. > + adev =

Re: [PATCH v2 2/3] leds: upboard: Add LED support

On Fri, Oct 19, 2018 at 8:27 PM Dan O'Donovan wrote: > > From: Javier Arteaga > > Allow userspace to use the on-board LEDs as "upboard::". > +#include > +#include > +#include > +#include > +#include > +#include > +#include For better maintenance keep this ordered. > + adev =

[PATCH 1/3] staging: rtl8188eu: simplify odm_evm_db_to_percentage()

Use clamp() to simplify code in odm_evm_db_to_percentage(). Signed-off-by: Michael Straube --- drivers/staging/rtl8188eu/hal/odm_hwconfig.c | 13 ++--- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/drivers/staging/rtl8188eu/hal/odm_hwconfig.c

[PATCH 1/3] staging: rtl8188eu: simplify odm_evm_db_to_percentage()

Use clamp() to simplify code in odm_evm_db_to_percentage(). Signed-off-by: Michael Straube --- drivers/staging/rtl8188eu/hal/odm_hwconfig.c | 13 ++--- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/drivers/staging/rtl8188eu/hal/odm_hwconfig.c

[PATCH 3/3] staging: rtl8188eu: rename variable isCCKrate - style

Rename the variable isCCKrate to avoid CamelCase. isCCKrate -> is_cck_rate Signed-off-by: Michael Straube --- drivers/staging/rtl8188eu/hal/odm_hwconfig.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/staging/rtl8188eu/hal/odm_hwconfig.c

[PATCH 2/3] staging: rtl8188eu: rename variable Max_spatial_stream - style

Rename the variable Max_spatial_stream to avoid CamelCase. Max_spatial_stream -> max_spatial_stream Signed-off-by: Michael Straube --- drivers/staging/rtl8188eu/hal/odm_hwconfig.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCH 3/3] staging: rtl8188eu: rename variable isCCKrate - style

Rename the variable isCCKrate to avoid CamelCase. isCCKrate -> is_cck_rate Signed-off-by: Michael Straube --- drivers/staging/rtl8188eu/hal/odm_hwconfig.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/staging/rtl8188eu/hal/odm_hwconfig.c

[PATCH 2/3] staging: rtl8188eu: rename variable Max_spatial_stream - style

Rename the variable Max_spatial_stream to avoid CamelCase. Max_spatial_stream -> max_spatial_stream Signed-off-by: Michael Straube --- drivers/staging/rtl8188eu/hal/odm_hwconfig.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 19/10/2018 23:36, David Howells wrote: Alan Jenkins wrote: # open_tree_clone 3 The reason EBUSY is returned is because propagate_mount_busy() is called by do_umount() with refcnt == 2, but mnt_count == 3: umount-3577 M=f8898a34 u=3 0x555 sp=__x64_sys_umount+0x12/0x15 the

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 19/10/2018 23:36, David Howells wrote: Alan Jenkins wrote: # open_tree_clone 3 The reason EBUSY is returned is because propagate_mount_busy() is called by do_umount() with refcnt == 2, but mnt_count == 3: umount-3577 M=f8898a34 u=3 0x555 sp=__x64_sys_umount+0x12/0x15 the

[PATCH] jffs2: fix invocations of dbg_xattr() for dead jffs2_xattr_ref

When jffs2_xattr_ref is dead, xref->ic or xref->xd will be invalid because these fields will be reused as xref->ino or xref->xid, so access xref->ic->ino or xref->xd->xid will lead to Oops. Fix the problem by checking whether or not it is a dead xref. Signed-off-by: Hou Tao ---

[RFC PATCH] jffs2: make the overwritten xattr invisible after remount

For xattr modification, we do not write a new jffs2_raw_xref with delete marker into flash, so if a xattr is modified then removed, and the old xref & xdatum are not erased by GC, after reboot or remount, the new xattr xref will be dead but the old xattr xref will be alive, and we will get the

[PATCH] jffs2: fix invocations of dbg_xattr() for dead jffs2_xattr_ref

When jffs2_xattr_ref is dead, xref->ic or xref->xd will be invalid because these fields will be reused as xref->ino or xref->xid, so access xref->ic->ino or xref->xd->xid will lead to Oops. Fix the problem by checking whether or not it is a dead xref. Signed-off-by: Hou Tao ---

[RFC PATCH] jffs2: make the overwritten xattr invisible after remount

For xattr modification, we do not write a new jffs2_raw_xref with delete marker into flash, so if a xattr is modified then removed, and the old xref & xdatum are not erased by GC, after reboot or remount, the new xattr xref will be dead but the old xattr xref will be alive, and we will get the

[PATCH] mm,oom: Use timeout based back off.

This patch changes the OOM killer to wait for either (A) __mmput() of the OOM victim's mm completes or (B) the OOM reaper gives up waiting for (A) because memory pages used by the OOM victim's mm did not decrease for one second in order to mitigate at least three problems (1) an

[PATCH] mm,oom: Use timeout based back off.

This patch changes the OOM killer to wait for either (A) __mmput() of the OOM victim's mm completes or (B) the OOM reaper gives up waiting for (A) because memory pages used by the OOM victim's mm did not decrease for one second in order to mitigate at least three problems (1) an

[PATCH] platform/x86: touchscreen_dmi: Add min-x and min-y settings for various models

Add min-x and min-y settings now that we've support for this and for some models also update the width/height settings with slighly more accurate values. This fixes touches along the edges registering at the wrong coordinates. While at it also set max-fingers to 10 in a couple of cases where the

[PATCH] platform/x86: touchscreen_dmi: Add min-x and min-y settings for various models

Add min-x and min-y settings now that we've support for this and for some models also update the width/height settings with slighly more accurate values. This fixes touches along the edges registering at the wrong coordinates. While at it also set max-fingers to 10 in a couple of cases where the

[PATCH v3 2/2] tty: serial: add driver for the SiFive UART

Add a serial driver for the SiFive UART, found on SiFive FU540 devices (among others). The underlying serial IP block is relatively basic, and currently does not support serial break detection. Further information on the IP block can be found in the documentation and Chisel sources:

[PATCH v3 2/2] tty: serial: add driver for the SiFive UART

Add a serial driver for the SiFive UART, found on SiFive FU540 devices (among others). The underlying serial IP block is relatively basic, and currently does not support serial break detection. Further information on the IP block can be found in the documentation and Chisel sources:

[PATCH v3 0/2] tty: serial: add DT bindings and serial driver for the SiFive FU540 UART

This series adds a serial driver, with console support, for the UART IP block present on the SiFive FU540 SoC. The programming model is straightforward, but unique. Boot-tested on a SiFive FU540 HiFive-U board (with appropriate patches to the DT data). The patches in this series can also be

[PATCH v3 0/2] tty: serial: add DT bindings and serial driver for the SiFive FU540 UART

This series adds a serial driver, with console support, for the UART IP block present on the SiFive FU540 SoC. The programming model is straightforward, but unique. Boot-tested on a SiFive FU540 HiFive-U board (with appropriate patches to the DT data). The patches in this series can also be

[PATCH v3 1/2] dt-bindings: serial: add documentation for the SiFive UART driver

Add DT binding documentation for the Linux driver for the SiFive asynchronous serial IP block. Cc: linux-ser...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-ri...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman Cc: Rob Herring Cc: Mark Rutland Cc: Palmer

[PATCH v3 1/2] dt-bindings: serial: add documentation for the SiFive UART driver

Add DT binding documentation for the Linux driver for the SiFive asynchronous serial IP block. Cc: linux-ser...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-ri...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman Cc: Rob Herring Cc: Mark Rutland Cc: Palmer

[PATCH -tip] kprobes/x86: Use preempt_enable() in optimized_callback()

Since commit a19b2e3d7839 ("kprobes/x86: Remove IRQ disabling from ftrace-based/optimized kprobes”) removes local_irq_save/restore() from optimized_callback(), the handler does not protected against reschedule interrupt. If it is able to be preempted (rescheduled) by such interrupt, we don't need

[PATCH -tip] kprobes/x86: Use preempt_enable() in optimized_callback()

Since commit a19b2e3d7839 ("kprobes/x86: Remove IRQ disabling from ftrace-based/optimized kprobes”) removes local_irq_save/restore() from optimized_callback(), the handler does not protected against reschedule interrupt. If it is able to be preempted (rescheduled) by such interrupt, we don't need

[PATCH] MIPS: Ensure ELF appended dtb is relocated

This fixes booting with the combination of CONFIG_RELOCATABLE=y and CONFIG_MIPS_ELF_APPENDED_DTB=y. Sections that appear after the relocation table are not relocated on system boot (except .bss, which has special handling). With CONFIG_MIPS_ELF_APPENDED_DTB, the dtb is part of the vmlinux ELF,

[PATCH] MIPS: Ensure ELF appended dtb is relocated

This fixes booting with the combination of CONFIG_RELOCATABLE=y and CONFIG_MIPS_ELF_APPENDED_DTB=y. Sections that appear after the relocation table are not relocated on system boot (except .bss, which has special handling). With CONFIG_MIPS_ELF_APPENDED_DTB, the dtb is part of the vmlinux ELF,

Re: [RFC v4 PATCH 2/5] mm/__free_one_page: skip merge for order-0 page unless compaction failed

On Fri, Oct 19, 2018 at 08:00:53AM -0700, Daniel Jordan wrote: > On Fri, Oct 19, 2018 at 09:54:35AM +0100, Mel Gorman wrote: > > On Fri, Oct 19, 2018 at 01:57:03PM +0800, Aaron Lu wrote: > > > > > > > > I don't think this is the right way of thinking about it because it's > > > > possible to have

Re: [RFC v4 PATCH 2/5] mm/__free_one_page: skip merge for order-0 page unless compaction failed

On Fri, Oct 19, 2018 at 08:00:53AM -0700, Daniel Jordan wrote: > On Fri, Oct 19, 2018 at 09:54:35AM +0100, Mel Gorman wrote: > > On Fri, Oct 19, 2018 at 01:57:03PM +0800, Aaron Lu wrote: > > > > > > > > I don't think this is the right way of thinking about it because it's > > > > possible to have

[GIT PULL] x86 fixes

Greg, Please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus # HEAD: 485734f3fc77c1eb77ffe138c027b9a4bf0178f3 x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels It's 4 misc fixes, 3 build

[GIT PULL] x86 fixes

Greg, Please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus # HEAD: 485734f3fc77c1eb77ffe138c027b9a4bf0178f3 x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels It's 4 misc fixes, 3 build

[GIT PULL] scheduler fixes

Greg, Please pull the latest sched-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-urgent-for-linus # HEAD: 9845c49cc9bbb317a0bc9e9cf78d8e09d54c9af0 sched/fair: Fix the min_vruntime update logic in dequeue_entity() Two fixes: a

[GIT PULL] scheduler fixes

Greg, Please pull the latest sched-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-urgent-for-linus # HEAD: 9845c49cc9bbb317a0bc9e9cf78d8e09d54c9af0 sched/fair: Fix the min_vruntime update logic in dequeue_entity() Two fixes: a

Re: [PATCH v1] x86/microcode: Handle negative microcode revisions

On Fri, Oct 19, 2018 at 05:11:37PM -0700, Andi Kleen wrote: > From: Andi Kleen > > The Intel ucode revision space is unsigned. Inside Intel there are special s/ucode/microcode/g > microcodes that have the highest bit set, and they are considered to have s/microcodes/microcode revisions/g > a

Re: [PATCH v1] x86/microcode: Handle negative microcode revisions

On Fri, Oct 19, 2018 at 05:11:37PM -0700, Andi Kleen wrote: > From: Andi Kleen > > The Intel ucode revision space is unsigned. Inside Intel there are special s/ucode/microcode/g > microcodes that have the highest bit set, and they are considered to have s/microcodes/microcode revisions/g > a

perf handling of unknown symbols...

I was able to, I think, track down why I get unknown symbols with perf top. It happens for processes that start up while perf is running. It's due to races if a process changes it's address space really quickly while perf is processing all of the events. If we are probing procfs and/or sysfs

perf handling of unknown symbols...

I was able to, I think, track down why I get unknown symbols with perf top. It happens for processes that start up while perf is running. It's due to races if a process changes it's address space really quickly while perf is processing all of the events. If we are probing procfs and/or sysfs

Re: [PATCH v2 1/2] x86/cpufeature: Add facility to match microcode revisions

On Fri, 19 Oct 2018, Andi Kleen wrote: > > > + u32 min_ucode; > > > +}; > > > + > > > +const struct x86_ucode_id *x86_match_ucode(const struct x86_ucode_id > > > *match) > > > > What's the point of returning the struct pointer? Shouldn't it be enough to > > make it return bool? Also the

Re: [PATCH v2 1/2] x86/cpufeature: Add facility to match microcode revisions

On Fri, 19 Oct 2018, Andi Kleen wrote: > > > + u32 min_ucode; > > > +}; > > > + > > > +const struct x86_ucode_id *x86_match_ucode(const struct x86_ucode_id > > > *match) > > > > What's the point of returning the struct pointer? Shouldn't it be enough to > > make it return bool? Also the

[GIT PULL] perf fixes

Greg, Please pull the latest perf-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-urgent-for-linus # HEAD: 20e8e72d0fa8e26202932c30d592bade73fdc701 Merge tag 'perf-urgent-for-mingo-4.19-20181017' of

[GIT PULL] perf fixes

Greg, Please pull the latest perf-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-urgent-for-linus # HEAD: 20e8e72d0fa8e26202932c30d592bade73fdc701 Merge tag 'perf-urgent-for-mingo-4.19-20181017' of

Re: in_compat_syscall() returns from kernel thread for X86_32.

> On Oct 19, 2018, at 11:02 PM, Andreas Dilger wrote: > >> On Oct 18, 2018, at 11:26 AM, Andy Lutomirski wrote: >> >>> On Wed, Oct 17, 2018 at 9:36 PM NeilBrown wrote: >>> On Wed, Oct 17 2018, Andy Lutomirski wrote: > On Wed, Oct 17, 2018 at 6:48 PM NeilBrown wrote: >

Re: in_compat_syscall() returns from kernel thread for X86_32.

> On Oct 19, 2018, at 11:02 PM, Andreas Dilger wrote: > >> On Oct 18, 2018, at 11:26 AM, Andy Lutomirski wrote: >> >>> On Wed, Oct 17, 2018 at 9:36 PM NeilBrown wrote: >>> On Wed, Oct 17 2018, Andy Lutomirski wrote: > On Wed, Oct 17, 2018 at 6:48 PM NeilBrown wrote: >

Re: [PATCH v2 0/2] i2c-omap: Enable i2c-omap driver for AM654 SoCs

On 28-Sep-18 10:55 AM, Vignesh R wrote: > Couple of patches to enable i2c-omap driver to be used with TI's new > AM654 platforms. > > > Vignesh R (2): > dt-bindings: i2c-omap: Add new compatible for AM654 SoCs > i2c: busses: Kconfig: Enable I2C_OMAP for ARCH_K3 > >

Re: [PATCH v2 0/2] i2c-omap: Enable i2c-omap driver for AM654 SoCs

On 28-Sep-18 10:55 AM, Vignesh R wrote: > Couple of patches to enable i2c-omap driver to be used with TI's new > AM654 platforms. > > > Vignesh R (2): > dt-bindings: i2c-omap: Add new compatible for AM654 SoCs > i2c: busses: Kconfig: Enable I2C_OMAP for ARCH_K3 > >

Re: [PATCH 0/3] [GIT PULL] tracing: A few small fixes to synthetic events

On Fri, Oct 19, 2018 at 09:29:58PM -0400, Steven Rostedt wrote: > > Linus (aka Greg), > > Masami found some issues with the creation of synthetic events. > The first two patches fix handling of unsigned type, and handling > of a space before an ending semi-colon. > > The third patch adds a

Re: [PATCH 0/3] [GIT PULL] tracing: A few small fixes to synthetic events

On Fri, Oct 19, 2018 at 09:29:58PM -0400, Steven Rostedt wrote: > > Linus (aka Greg), > > Masami found some issues with the creation of synthetic events. > The first two patches fix handling of unsigned type, and handling > of a space before an ending semi-colon. > > The third patch adds a

Re: [git pull] Input updates for v4.19-rc8

On Fri, Oct 19, 2018 at 10:45:08AM -0700, Dmitry Torokhov wrote: > Hi Greg, > > Please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus > > to receive updates for the input subsystem. Just an addition to elan > touchpad driver ACPI table. Now merged,

Re: [git pull] Input updates for v4.19-rc8

On Fri, Oct 19, 2018 at 10:45:08AM -0700, Dmitry Torokhov wrote: > Hi Greg, > > Please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus > > to receive updates for the input subsystem. Just an addition to elan > touchpad driver ACPI table. Now merged,

Re: [PATCH 4.18 00/53] 4.18.16-stable review

On Fri, Oct 19, 2018 at 02:43:12PM -0600, Shuah Khan wrote: > On 10/18/2018 11:53 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.18.16 release. > > There are 53 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.18 00/53] 4.18.16-stable review

On Fri, Oct 19, 2018 at 02:43:12PM -0600, Shuah Khan wrote: > On 10/18/2018 11:53 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.18.16 release. > > There are 53 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.18 00/53] 4.18.16-stable review

On Fri, Oct 19, 2018 at 08:50:29AM -0700, Guenter Roeck wrote: > On Thu, Oct 18, 2018 at 07:53:53PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.18.16 release. > > There are 53 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH 4.18 00/53] 4.18.16-stable review

On Fri, Oct 19, 2018 at 08:50:29AM -0700, Guenter Roeck wrote: > On Thu, Oct 18, 2018 at 07:53:53PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.18.16 release. > > There are 53 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH 0/6] Tracing register accesses with pstore and dynamic debug

On 10/20/2018 10:55 AM, Joel Fernandes wrote: On Sun, Sep 09, 2018 at 01:57:01AM +0530, Sai Prakash Ranjan wrote: Hi, This patch series adds Event tracing support to pstore and is continuation to the RFC patch introduced to add a new tracing facility for register accesses called Register Trace

Re: [PATCH 0/6] Tracing register accesses with pstore and dynamic debug

On 10/20/2018 10:55 AM, Joel Fernandes wrote: On Sun, Sep 09, 2018 at 01:57:01AM +0530, Sai Prakash Ranjan wrote: Hi, This patch series adds Event tracing support to pstore and is continuation to the RFC patch introduced to add a new tracing facility for register accesses called Register Trace

Re: in_compat_syscall() returns from kernel thread for X86_32.

On Oct 18, 2018, at 11:26 AM, Andy Lutomirski wrote: > > On Wed, Oct 17, 2018 at 9:36 PM NeilBrown wrote: >> >> On Wed, Oct 17 2018, Andy Lutomirski wrote: >> >>> On Wed, Oct 17, 2018 at 6:48 PM NeilBrown wrote: Was: Re: [tip:x86/asm] x86/entry: Rename is_{ia32,x32}_task()

Re: in_compat_syscall() returns from kernel thread for X86_32.

On Oct 18, 2018, at 11:26 AM, Andy Lutomirski wrote: > > On Wed, Oct 17, 2018 at 9:36 PM NeilBrown wrote: >> >> On Wed, Oct 17 2018, Andy Lutomirski wrote: >> >>> On Wed, Oct 17, 2018 at 6:48 PM NeilBrown wrote: Was: Re: [tip:x86/asm] x86/entry: Rename is_{ia32,x32}_task()

<    1   2   3