[PATCH 1/4] staging:r8188eu: Remove struct pkt_file from set_qos()

Struct pkt_file is a base to simple wrapper for skb_copy_bits(). Use skb_copy_bits() without wrappers. Signed-off-by: Ivan Safonov --- drivers/staging/rtl8188eu/core/rtw_xmit.c | 26 ++ 1 file changed, 10 insertions(+), 16 deletions(-) diff --git

[PATCH 2/4] staging:r8188eu: Remove struct pkt_file from update_attrib()

Struct pkt_file is a base to simple wrapper for skb_copy_bits(). Do not use struct pkt_file in update_attrib(). Signed-off-by: Ivan Safonov --- drivers/staging/rtl8188eu/core/rtw_xmit.c | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git

[PATCH 1/4] staging:r8188eu: Remove struct pkt_file from set_qos()

Struct pkt_file is a base to simple wrapper for skb_copy_bits(). Use skb_copy_bits() without wrappers. Signed-off-by: Ivan Safonov --- drivers/staging/rtl8188eu/core/rtw_xmit.c | 26 ++ 1 file changed, 10 insertions(+), 16 deletions(-) diff --git

[PATCH 2/4] staging:r8188eu: Remove struct pkt_file from update_attrib()

Struct pkt_file is a base to simple wrapper for skb_copy_bits(). Do not use struct pkt_file in update_attrib(). Signed-off-by: Ivan Safonov --- drivers/staging/rtl8188eu/core/rtw_xmit.c | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git

[PATCH 3/4] staging:r8188eu: Remove struct pkt_file from rtw_xmitframe_coalesce()

Struct pkt_file is a base to simple wrapper for skb_copy_bits(). Eliminate struct pkt_file usage in rtw_xmitframe_coalesce(). Signed-off-by: Ivan Safonov --- drivers/staging/rtl8188eu/core/rtw_xmit.c | 17 + 1 file changed, 5 insertions(+), 12 deletions(-)

[PATCH 3/4] staging:r8188eu: Remove struct pkt_file from rtw_xmitframe_coalesce()

Struct pkt_file is a base to simple wrapper for skb_copy_bits(). Eliminate struct pkt_file usage in rtw_xmitframe_coalesce(). Signed-off-by: Ivan Safonov --- drivers/staging/rtl8188eu/core/rtw_xmit.c | 17 + 1 file changed, 5 insertions(+), 12 deletions(-) diff --git

[PATCH 4/4] staging:r8188eu: Remove unused struct pkt_file

Struct pkt_file is unused now, so remove it and correponding functions. Signed-off-by: Ivan Safonov --- drivers/staging/rtl8188eu/include/xmit_osdep.h | 13 - drivers/staging/rtl8188eu/os_dep/xmit_linux.c | 37 -- 2 files changed, 50

[PATCH 4/4] staging:r8188eu: Remove unused struct pkt_file

Struct pkt_file is unused now, so remove it and correponding functions. Signed-off-by: Ivan Safonov --- drivers/staging/rtl8188eu/include/xmit_osdep.h | 13 - drivers/staging/rtl8188eu/os_dep/xmit_linux.c | 37 -- 2 files changed, 50 deletions(-) diff --git

Re: [PATCH] ARM: dts: imx: Add support for Advantech DMS-BA16

On Mon, Feb 05, 2018 at 02:45:14AM +0800, Ken Lin wrote: > Add support for Advantech DMS-BA16 board, which use > the Advantech BA-16 module. > > Signed-off-by: Ken Lin > --- > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/imx6q-dms-ba16.dts | 154 >

Re: [PATCH] ARM: dts: imx: Add support for Advantech DMS-BA16

On Mon, Feb 05, 2018 at 02:45:14AM +0800, Ken Lin wrote: > Add support for Advantech DMS-BA16 board, which use > the Advantech BA-16 module. > > Signed-off-by: Ken Lin > --- > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/imx6q-dms-ba16.dts | 154 >

Re: [PATCH] pvcalls-back: do not return error on inet_accept EAGAIN

On 02/02/2018 08:34 PM, Stefano Stabellini wrote: When the client sends a regular blocking accept request, the backend is expected to return only when the accept is completed, simulating a blocking behavior, or return an error. Specifically, on EAGAIN from inet_accept, the backend shouldn't

Re: [PATCH] pvcalls-back: do not return error on inet_accept EAGAIN

On 02/02/2018 08:34 PM, Stefano Stabellini wrote: When the client sends a regular blocking accept request, the backend is expected to return only when the accept is completed, simulating a blocking behavior, or return an error. Specifically, on EAGAIN from inet_accept, the backend shouldn't

Re: [PULL REQUEST] i2c for 4.16

On Sat, Feb 3, 2018 at 2:30 PM, Wolfram Sang wrote: > > There was a small merge conflict in MAINTAINERS in linux-next, but that > should be easy to fix. Well, that one wouldn't have happened at all if the i2c people knew how to sort things.. It also grew a few other

Re: [PULL REQUEST] i2c for 4.16

On Sat, Feb 3, 2018 at 2:30 PM, Wolfram Sang wrote: > > There was a small merge conflict in MAINTAINERS in linux-next, but that > should be easy to fix. Well, that one wouldn't have happened at all if the i2c people knew how to sort things.. It also grew a few other conflicts since linux-next,

Re: [PATCH] xen: hypercall: fix out-of-bounds memcpy

On 02/04/2018 10:35 AM, Arnd Bergmann wrote: On Sat, Feb 3, 2018 at 6:08 PM, Boris Ostrovsky wrote: On 02/03/2018 10:12 AM, Arnd Bergmann wrote: On Sat, Feb 3, 2018 at 12:33 AM, Boris Ostrovsky wrote: On 02/02/2018 10:32 AM, Arnd

Re: [PATCH] xen: hypercall: fix out-of-bounds memcpy

On 02/04/2018 10:35 AM, Arnd Bergmann wrote: On Sat, Feb 3, 2018 at 6:08 PM, Boris Ostrovsky wrote: On 02/03/2018 10:12 AM, Arnd Bergmann wrote: On Sat, Feb 3, 2018 at 12:33 AM, Boris Ostrovsky wrote: On 02/02/2018 10:32 AM, Arnd Bergmann wrote: The legacy hypercall handlers were

[PATCH] ARM: dts: imx: Add support for Advantech DMS-BA16

Add support for Advantech DMS-BA16 board, which use the Advantech BA-16 module. Signed-off-by: Ken Lin --- arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/imx6q-dms-ba16.dts | 154 +++ 2 files changed, 155 insertions(+)

[PATCH] ARM: dts: imx: Add support for Advantech DMS-BA16

Add support for Advantech DMS-BA16 board, which use the Advantech BA-16 module. Signed-off-by: Ken Lin --- arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/imx6q-dms-ba16.dts | 154 +++ 2 files changed, 155 insertions(+) create mode 100644

Re: [PATCH 1/2] ARM: kvm: fix building with gcc-8

Hi Arnd, On Fri, Feb 02, 2018 at 04:07:34PM +0100, Arnd Bergmann wrote: > In banked-sr.c, we use a top-level '__asm__(".arch_extension virt")' > statement to allow compilation of a multi-CPU kernel for ARMv6 > and older ARMv7-A that don't normally support access to the banked > registers. > >

Re: [PATCH 1/2] ARM: kvm: fix building with gcc-8

Hi Arnd, On Fri, Feb 02, 2018 at 04:07:34PM +0100, Arnd Bergmann wrote: > In banked-sr.c, we use a top-level '__asm__(".arch_extension virt")' > statement to allow compilation of a multi-CPU kernel for ARMv6 > and older ARMv7-A that don't normally support access to the banked > registers. > >

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 23 Jan 2018, Ingo Molnar wrote: > * David Woodhouse wrote: > > > > On SkyLake this would add an overhead of maybe 2-3 cycles per function > > > call and  > > > obviously all this code and data would be very cache hot. Given that the > > > average  > > > number of

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 23 Jan 2018, Ingo Molnar wrote: > * David Woodhouse wrote: > > > > On SkyLake this would add an overhead of maybe 2-3 cycles per function > > > call and  > > > obviously all this code and data would be very cache hot. Given that the > > > average  > > > number of function calls per

Re: [PATCH 1/3] x86/entry: Clear extra registers beyond syscall arguments for 64bit kernels

On Sun, Feb 4, 2018 at 9:42 AM, Dan Williams wrote: > On Sun, Feb 4, 2018 at 5:01 AM, Brian Gerst wrote: >> >> Now that the fast syscall path is gone, all regs (except RSP >> obviously) are dead after being saved to pt_regs. > > They're saved, but not

Re: [PATCH 1/3] x86/entry: Clear extra registers beyond syscall arguments for 64bit kernels

On Sun, Feb 4, 2018 at 9:42 AM, Dan Williams wrote: > On Sun, Feb 4, 2018 at 5:01 AM, Brian Gerst wrote: >> >> Now that the fast syscall path is gone, all regs (except RSP >> obviously) are dead after being saved to pt_regs. > > They're saved, but not dead afaics. Actually, they _are_ dead with

Re: [PATCH v3 12/18] arm64: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling

On Thu, Feb 01, 2018 at 11:46:51AM +, Marc Zyngier wrote: > We want SMCCC_ARCH_WORKAROUND_1 to be fast. As fast as possible. > So let's intercept it as early as we can by testing for the > function call number as soon as we've identified a HVC call > coming from the guest. Hmmm. How often is

Re: [PATCH v3 12/18] arm64: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling

On Thu, Feb 01, 2018 at 11:46:51AM +, Marc Zyngier wrote: > We want SMCCC_ARCH_WORKAROUND_1 to be fast. As fast as possible. > So let's intercept it as early as we can by testing for the > function call number as soon as we've identified a HVC call > coming from the guest. Hmmm. How often is

Re: [PATCH v3 11/18] arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support

On Thu, Feb 01, 2018 at 11:46:50AM +, Marc Zyngier wrote: > A new feature of SMCCC 1.1 is that it offers firmware-based CPU > workarounds. In particular, SMCCC_ARCH_WORKAROUND_1 provides > BP hardening for CVE-2017-5715. > > If the host has some mitigation for this issue, report that > we

Re: [PATCH v3 11/18] arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support

On Thu, Feb 01, 2018 at 11:46:50AM +, Marc Zyngier wrote: > A new feature of SMCCC 1.1 is that it offers firmware-based CPU > workarounds. In particular, SMCCC_ARCH_WORKAROUND_1 provides > BP hardening for CVE-2017-5715. > > If the host has some mitigation for this issue, report that > we

Re: [PATCH v3 10/18] arm/arm64: KVM: Turn kvm_psci_version into a static inline

On Thu, Feb 01, 2018 at 11:46:49AM +, Marc Zyngier wrote: > We're about to need kvm_psci_version in HYP too. So let's turn it > into a static inline, and pass the kvm structure as a second > parameter (so that HYP can do a kern_hyp_va on it). > Reviewed-by: Christoffer Dall

Re: [PATCH v3 10/18] arm/arm64: KVM: Turn kvm_psci_version into a static inline

On Thu, Feb 01, 2018 at 11:46:49AM +, Marc Zyngier wrote: > We're about to need kvm_psci_version in HYP too. So let's turn it > into a static inline, and pass the kvm structure as a second > parameter (so that HYP can do a kern_hyp_va on it). > Reviewed-by: Christoffer Dall >

Re: [PATCH v3 09/18] arm/arm64: KVM: Advertise SMCCC v1.1

On Thu, Feb 01, 2018 at 11:46:48AM +, Marc Zyngier wrote: > The new SMC Calling Convention (v1.1) allows for a reduced overhead > when calling into the firmware, and provides a new feature discovery > mechanism. > > Make it visible to KVM guests. > Reviewed-by: Christoffer Dall

Re: [PATCH v3 09/18] arm/arm64: KVM: Advertise SMCCC v1.1

On Thu, Feb 01, 2018 at 11:46:48AM +, Marc Zyngier wrote: > The new SMC Calling Convention (v1.1) allows for a reduced overhead > when calling into the firmware, and provides a new feature discovery > mechanism. > > Make it visible to KVM guests. > Reviewed-by: Christoffer Dall >

Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"

Hi Akira, On Mon, Feb 05, 2018 at 01:14:10AM +0900, Akira Yokosawa wrote: > Hi Paul, > CC: Andrea > > This is intentionally off the list, as I was not cc'd in the thread. > If you think it is worthwhile, could you help me join the thread by > forwarding the following part as a reply to your

Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"

Hi Akira, On Mon, Feb 05, 2018 at 01:14:10AM +0900, Akira Yokosawa wrote: > Hi Paul, > CC: Andrea > > This is intentionally off the list, as I was not cc'd in the thread. > If you think it is worthwhile, could you help me join the thread by > forwarding the following part as a reply to your

Re: [PATCH v2] iio: accel: bmc150: Check for a second ACPI device for BOSC0200

Andy, The information is in kernel bug 198671. Steve On 01/30/2018 04:20 PM, Andy Shevchenko wrote: On Tue, Jan 30, 2018 at 10:12 PM, Andy Shevchenko wrote: On Tue, Jan 30, 2018 at 9:27 PM, Steven Presser wrote: On 01/30/2018 02:05 PM,

Re: [PATCH v2] iio: accel: bmc150: Check for a second ACPI device for BOSC0200

Andy, The information is in kernel bug 198671. Steve On 01/30/2018 04:20 PM, Andy Shevchenko wrote: On Tue, Jan 30, 2018 at 10:12 PM, Andy Shevchenko wrote: On Tue, Jan 30, 2018 at 9:27 PM, Steven Presser wrote: On 01/30/2018 02:05 PM, Andy Shevchenko wrote: On Tue, Jan 30, 2018 at

[PATCH] Fix a typo in Documentation/device-mapper/dm-zoned.txt

A trivial patch to fix a typo in Documentation/device-mapper/dm-zoned.txt Fix 'convnetional' to 'conventional' Signed-off-by: Donghyeon Oh Cc: Jiri Kosina Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org diff --git

[PATCH] Fix a typo in Documentation/device-mapper/dm-zoned.txt

A trivial patch to fix a typo in Documentation/device-mapper/dm-zoned.txt Fix 'convnetional' to 'conventional' Signed-off-by: Donghyeon Oh Cc: Jiri Kosina Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org diff --git a/Documentation/device-mapper/dm-zoned.txt

Re: [PATCH v2] iio: accel: bmc150: Check for a second ACPI device for BOSC0200

All, I had a chance to sit back down with the machine.  I didn't take it all the way apart - there are pieces that I'm afraid of breaking without directions on how to properly disassemble them. However, I did recover an exact chip ID - the chips in use are BMA255s [1].  Rather than take the

Re: [PATCH v2] iio: accel: bmc150: Check for a second ACPI device for BOSC0200

All, I had a chance to sit back down with the machine.  I didn't take it all the way apart - there are pieces that I'm afraid of breaking without directions on how to properly disassemble them. However, I did recover an exact chip ID - the chips in use are BMA255s [1].  Rather than take the

[PATCH v3 3/7] ARM: dts: imx6dl-icore: Add LVDS node

Add ampire,am-800480aytzqw-00h LVDS support by using timings from panel-simple. Signed-off-by: Jagan Teki --- Changes for v3, v2: - none arch/arm/boot/dts/imx6dl-icore.dts | 28 1 file changed, 28 insertions(+) diff --git

[PATCH v3 3/7] ARM: dts: imx6dl-icore: Add LVDS node

Add ampire,am-800480aytzqw-00h LVDS support by using timings from panel-simple. Signed-off-by: Jagan Teki --- Changes for v3, v2: - none arch/arm/boot/dts/imx6dl-icore.dts | 28 1 file changed, 28 insertions(+) diff --git a/arch/arm/boot/dts/imx6dl-icore.dts

[PATCH v3 5/7] ARM: dts: imx6q-icore-ofcap12: Switch LVDS timings from panel-simple

Switch to use koe_tx31d200vm0baa LVDS timings from panel-simple instead hard coding the same in dts. Signed-off-by: Jagan Teki --- Changes for v3, v2: - none arch/arm/boot/dts/imx6q-icore-ofcap12.dts | 31 +-- 1 file changed, 17

[PATCH v3 5/7] ARM: dts: imx6q-icore-ofcap12: Switch LVDS timings from panel-simple

Switch to use koe_tx31d200vm0baa LVDS timings from panel-simple instead hard coding the same in dts. Signed-off-by: Jagan Teki --- Changes for v3, v2: - none arch/arm/boot/dts/imx6q-icore-ofcap12.dts | 31 +-- 1 file changed, 17 insertions(+), 14 deletions(-) diff

[PATCH v3 6/7] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual OpenFrame Cap 7 initial support

i.CoreM6 Quad/Dual OpenFrame modules are "system on modules plus openframe display carriers" which are good solution for develop user friendly graphic user interface. ofcap 7 general features: CPU NXP Freescale i.MX6Q rev1.5 at 792 MHz RAM 1GB, 32, 64 bit, DDR3-800/1066 NAND

[PATCH v3 2/7] ARM: dts: imx6q-icore: Switch LVDS timings from panel-simple

Switch to use ampire,am-800480aytzqw-00h LVDS timings from panel-simple instead hard coding the same in dts. Signed-off-by: Jagan Teki --- Changes for v3, v2: - none arch/arm/boot/dts/imx6q-icore.dts| 31 +--

[PATCH v3 4/7] drm/panel: simple: Add support for KEO TX31D200VM0BAA

This adds support for the Kaohsiung Opto-Electronics., TX31D200VM0BAA 12.3" HSXGA LVDS panel, which can be supported by the simple panel driver. Signed-off-by: Jagan Teki Reviewed-by: Rob Herring --- Changes for v3: - collect Rob reiew tag Changes

[PATCH v3 2/7] ARM: dts: imx6q-icore: Switch LVDS timings from panel-simple

Switch to use ampire,am-800480aytzqw-00h LVDS timings from panel-simple instead hard coding the same in dts. Signed-off-by: Jagan Teki --- Changes for v3, v2: - none arch/arm/boot/dts/imx6q-icore.dts| 31 +-- arch/arm/boot/dts/imx6qdl-icore.dtsi | 2 +- 2 files

[PATCH v3 4/7] drm/panel: simple: Add support for KEO TX31D200VM0BAA

This adds support for the Kaohsiung Opto-Electronics., TX31D200VM0BAA 12.3" HSXGA LVDS panel, which can be supported by the simple panel driver. Signed-off-by: Jagan Teki Reviewed-by: Rob Herring --- Changes for v3: - collect Rob reiew tag Changes for v2: - Updated binding info about optional

[PATCH v3 6/7] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual OpenFrame Cap 7 initial support

i.CoreM6 Quad/Dual OpenFrame modules are "system on modules plus openframe display carriers" which are good solution for develop user friendly graphic user interface. ofcap 7 general features: CPU NXP Freescale i.MX6Q rev1.5 at 792 MHz RAM 1GB, 32, 64 bit, DDR3-800/1066 NAND

[PATCH v3 7/7] ARM: dts: imx6q: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit support

i.CoreM6 1.5 is an another i.CoreM6 QDL cpu modules which can be connected to EDIMM starter kit design with eMMC and MIPI-CSI interfaces suitable for Android and video capture application. notable features: CPU NXP i.MX6 S/DL/D/Q, Up to 4 x Cortex-A9@800MHz Memory

[PATCH v3 0/7] ARM: dts: imx6q: engicam LVDS panel changes

Series adda LVDS panel attributes on panel drivers instead of defining them in dts nodes, and also added new icorem6 engicam boards. Jagan Teki (7): drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H ARM: dts: imx6q-icore: Switch LVDS timings from panel-simple ARM: dts:

[PATCH v3 7/7] ARM: dts: imx6q: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit support

i.CoreM6 1.5 is an another i.CoreM6 QDL cpu modules which can be connected to EDIMM starter kit design with eMMC and MIPI-CSI interfaces suitable for Android and video capture application. notable features: CPU NXP i.MX6 S/DL/D/Q, Up to 4 x Cortex-A9@800MHz Memory

[PATCH v3 0/7] ARM: dts: imx6q: engicam LVDS panel changes

Series adda LVDS panel attributes on panel drivers instead of defining them in dts nodes, and also added new icorem6 engicam boards. Jagan Teki (7): drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H ARM: dts: imx6q-icore: Switch LVDS timings from panel-simple ARM: dts:

[PATCH 1/2] GCC release 8 support for gcc-plugins

GCC requires another #include to get the gcc-plugins to build cleanly. Signed-off-by: Valdis Kletnieks diff --git a/scripts/gcc-plugins/gcc-common.h b/scripts/gcc-plugins/gcc-common.h index ffd1dfaa1cc1..f46750053377 100644 --- a/scripts/gcc-plugins/gcc-common.h +++

[PATCH v3 1/7] drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H

This adds support for the Ampire AM-800480AYTZQW-00H 7.0" WGA LCD, which can be supported by the simple panel driver. Signed-off-by: Jagan Teki Reviewed-by: Rob Herring --- Changes for v3: - collect Rob reiew tag Changes for v2: - Updated binding

[PATCH 1/2] GCC release 8 support for gcc-plugins

GCC requires another #include to get the gcc-plugins to build cleanly. Signed-off-by: Valdis Kletnieks diff --git a/scripts/gcc-plugins/gcc-common.h b/scripts/gcc-plugins/gcc-common.h index ffd1dfaa1cc1..f46750053377 100644 --- a/scripts/gcc-plugins/gcc-common.h +++

[PATCH v3 1/7] drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H

This adds support for the Ampire AM-800480AYTZQW-00H 7.0" WGA LCD, which can be supported by the simple panel driver. Signed-off-by: Jagan Teki Reviewed-by: Rob Herring --- Changes for v3: - collect Rob reiew tag Changes for v2: - Updated binding info about optional properties, node and

[PATCH v2 1/3] x86/entry: Clear extra registers beyond syscall arguments for 64bit kernels

At entry userspace may have populated the extra registers outside the syscall calling convention with values that could be useful in a speculative execution attack. Clear them to minimize the kernel's attack surface. Note, this only clears the extra registers and not the unused registers for

[PATCH v2 1/3] x86/entry: Clear extra registers beyond syscall arguments for 64bit kernels

At entry userspace may have populated the extra registers outside the syscall calling convention with values that could be useful in a speculative execution attack. Clear them to minimize the kernel's attack surface. Note, this only clears the extra registers and not the unused registers for

[PATCH v2 2/3] x86/entry: Clear registers for 64bit exceptions/interrupts

From: Andi Kleen Clear the 'extra' registers on entering the 64bit kernel for exceptions and interrupts. The common registers are not cleared since they are likely clobbered well before they can be exploited in a speculative execution attack. Signed-off-by: Andi Kleen

[PATCH v2 2/3] x86/entry: Clear registers for 64bit exceptions/interrupts

From: Andi Kleen Clear the 'extra' registers on entering the 64bit kernel for exceptions and interrupts. The common registers are not cleared since they are likely clobbered well before they can be exploited in a speculative execution attack. Signed-off-by: Andi Kleen Signed-off-by: Dan

[PATCH v2 0/3] x86/entry: Clear registers to sanitize speculative usages

Changes since v1 [1]: * Move CLEAR_REGS_EXTRA_NOSPEC before TRACE_IRQS_OFF to protect tracing users (Andy) [1]: https://lkml.org/lkml/2018/2/3/397 --- At entry userspace may have populated callee saved registers with values that could be useful in a speculative execution attack. Clear them to

[PATCH v2 3/3] x86/entry: Clear registers for compat syscalls

From: Andi Kleen At entry userspace may have populated registers with values that could be useful in a speculative execution attack. Clear them to minimize the kernel's attack surface. [djbw: rename the macro, only clear the extra registers] Cc: Thomas Gleixner

[PATCH v2 0/3] x86/entry: Clear registers to sanitize speculative usages

Changes since v1 [1]: * Move CLEAR_REGS_EXTRA_NOSPEC before TRACE_IRQS_OFF to protect tracing users (Andy) [1]: https://lkml.org/lkml/2018/2/3/397 --- At entry userspace may have populated callee saved registers with values that could be useful in a speculative execution attack. Clear them to

[PATCH v2 3/3] x86/entry: Clear registers for compat syscalls

From: Andi Kleen At entry userspace may have populated registers with values that could be useful in a speculative execution attack. Clear them to minimize the kernel's attack surface. [djbw: rename the macro, only clear the extra registers] Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter

[PATCH] Fix a typo in Documentation/device-mapper/dm-zoned.txt

A trivial patch to fix a typo in Documentation/device-mapper/dm-zoned.txt Fix 'convnetional' to 'conventional' Signed-off-by: Donghyeon Oh Cc: Jiri Kosina Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org diff --git

[PATCH] Fix a typo in Documentation/device-mapper/dm-zoned.txt

A trivial patch to fix a typo in Documentation/device-mapper/dm-zoned.txt Fix 'convnetional' to 'conventional' Signed-off-by: Donghyeon Oh Cc: Jiri Kosina Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org diff --git a/Documentation/device-mapper/dm-zoned.txt

[PATCH] Fix a typo in Documentation/device-mapper/dm-integrity.txt

A trivial patch to fix a typo in Documentation/device-mapper/dm-integrity.txt Fix 'nubmers' to 'numbers' Signed-off-by: Donghyeon Oh Cc: Jiri Kosina Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org diff --git

[PATCH] Fix a typo in Documentation/device-mapper/dm-integrity.txt

A trivial patch to fix a typo in Documentation/device-mapper/dm-integrity.txt Fix 'nubmers' to 'numbers' Signed-off-by: Donghyeon Oh Cc: Jiri Kosina Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org diff --git a/Documentation/device-mapper/dm-integrity.txt

[PATCH] vsprintf: avoid misleading "(null)" for %px

Like %pK already does, print "" instead. This confused people -- the convention is that "(null)" means you tried to dereference a null pointer as opposed to printing the address. Signed-off-by: Adam Borowski --- lib/vsprintf.c | 2 +- 1 file changed, 1

[PATCH] vsprintf: avoid misleading "(null)" for %px

Like %pK already does, print "" instead. This confused people -- the convention is that "(null)" means you tried to dereference a null pointer as opposed to printing the address. Signed-off-by: Adam Borowski --- lib/vsprintf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH 1/3] x86/entry: Clear extra registers beyond syscall arguments for 64bit kernels

On Sun, Feb 4, 2018 at 5:01 AM, Brian Gerst wrote: > On Sat, Feb 3, 2018 at 6:21 PM, Dan Williams wrote: >> At entry userspace may have populated the extra registers outside the >> syscall calling convention with values that could be useful in a >>

Re: [PATCH 1/3] x86/entry: Clear extra registers beyond syscall arguments for 64bit kernels

On Sun, Feb 4, 2018 at 5:01 AM, Brian Gerst wrote: > On Sat, Feb 3, 2018 at 6:21 PM, Dan Williams wrote: >> At entry userspace may have populated the extra registers outside the >> syscall calling convention with values that could be useful in a >> speculative execution attack. Clear them to

Re: [RFC 1/3] seccomp: add a return code to trap to userspace

On Sun, Feb 4, 2018 at 10:49 AM, Tycho Andersen wrote: > This patch introduces a means for syscalls matched in seccomp to notify > some other task that a particular filter has been triggered. Neat! > > The motivation for this is primarily for use with containers. For example, >

Re: [RFC 1/3] seccomp: add a return code to trap to userspace

On Sun, Feb 4, 2018 at 10:49 AM, Tycho Andersen wrote: > This patch introduces a means for syscalls matched in seccomp to notify > some other task that a particular filter has been triggered. Neat! > > The motivation for this is primarily for use with containers. For example, > if a container

[PATCH 2/2] GCC release 8 support for gcc-plugins

For reasons totally beyond my understanding, gcc 8 changed the order of two structure member, which leads to an error: HOSTCXX -fPIC scripts/gcc-plugins/latent_entropy_plugin.o scripts/gcc-plugins/latent_entropy_plugin.c:269:1: error: designator order for field

[PATCH 2/2] GCC release 8 support for gcc-plugins

For reasons totally beyond my understanding, gcc 8 changed the order of two structure member, which leads to an error: HOSTCXX -fPIC scripts/gcc-plugins/latent_entropy_plugin.o scripts/gcc-plugins/latent_entropy_plugin.c:269:1: error: designator order for field

Re: [PATCH AUTOSEL for 4.14 065/110] led: core: Fix brightness setting when setting delay_off=0

On Sun 2018-02-04 15:49:06, Sasha Levin wrote: > On Sun, Feb 04, 2018 at 10:05:31AM +0100, Pavel Machek wrote: > >On Sun 2018-02-04 00:30:36, Sasha Levin wrote: > >> On Sat, Feb 03, 2018 at 09:35:26PM +0100, Pavel Machek wrote: > >> >On Sat 2018-02-03 18:00:59, Sasha Levin wrote: > >> >> From:

Re: [PATCH AUTOSEL for 4.14 065/110] led: core: Fix brightness setting when setting delay_off=0

On Sun 2018-02-04 15:49:06, Sasha Levin wrote: > On Sun, Feb 04, 2018 at 10:05:31AM +0100, Pavel Machek wrote: > >On Sun 2018-02-04 00:30:36, Sasha Levin wrote: > >> On Sat, Feb 03, 2018 at 09:35:26PM +0100, Pavel Machek wrote: > >> >On Sat 2018-02-03 18:00:59, Sasha Levin wrote: > >> >> From:

Re: [PATCH 00/18] [ANNOUNCE] Dynamically created function based events

On Sun, Feb 04, 2018 at 12:57:47PM +0900, Masami Hiramatsu wrote: > > > I based some of the code from kprobes too. But I wanted this to be > > simpler, and as such, not as powerful as kprobes. More of a "poor mans" > > kprobe ;-) Where you are limited to functions and their arguments. If > > you

Re: [PATCH net 1/1 v1] rtnetlink: require unique netns identifier

On 2/4/18 5:11 AM, Christian Brauner wrote: > On Sat, Feb 03, 2018 at 11:17:01AM -0800, Stephen Hemminger wrote: >> On Sat, 3 Feb 2018 14:29:04 +0100 >> Christian Brauner wrote: >> >>> +static int rtnl_ensure_unique_netns_attr(const struct sock *sk, >>> +

Re: [PATCH 00/18] [ANNOUNCE] Dynamically created function based events

On Sun, Feb 04, 2018 at 12:57:47PM +0900, Masami Hiramatsu wrote: > > > I based some of the code from kprobes too. But I wanted this to be > > simpler, and as such, not as powerful as kprobes. More of a "poor mans" > > kprobe ;-) Where you are limited to functions and their arguments. If > > you

Re: [PATCH net 1/1 v1] rtnetlink: require unique netns identifier

On 2/4/18 5:11 AM, Christian Brauner wrote: > On Sat, Feb 03, 2018 at 11:17:01AM -0800, Stephen Hemminger wrote: >> On Sat, 3 Feb 2018 14:29:04 +0100 >> Christian Brauner wrote: >> >>> +static int rtnl_ensure_unique_netns_attr(const struct sock *sk, >>> +

Re: [PATCH AUTOSEL for 4.14 065/110] led: core: Fix brightness setting when setting delay_off=0

> > > >> *** if brightness=0, led off > > > >> *** else apply brightness if next timer <--- timer is stop, and will > > > >> never apply new setting > > > >> ** otherwise set led_set_brightness_nosleep > > > >> > > > >> To fix that, when we delete the timer, we should clear LED_BLINK_SW. > > > >

Re: [PATCH AUTOSEL for 4.14 065/110] led: core: Fix brightness setting when setting delay_off=0

> > > >> *** if brightness=0, led off > > > >> *** else apply brightness if next timer <--- timer is stop, and will > > > >> never apply new setting > > > >> ** otherwise set led_set_brightness_nosleep > > > >> > > > >> To fix that, when we delete the timer, we should clear LED_BLINK_SW. > > > >

[PATCH 5/6] Pmalloc: self-test

Add basic self-test functionality for pmalloc. Signed-off-by: Igor Stoppa --- mm/Kconfig| 9 mm/Makefile | 1 + mm/pmalloc-selftest.c | 61 +++ mm/pmalloc-selftest.h | 26

[PATCH 6/6] Documentation for Pmalloc

Detailed documentation about the protectable memory allocator. Signed-off-by: Igor Stoppa --- Documentation/core-api/index.rst | 1 + Documentation/core-api/pmalloc.rst | 114 + 2 files changed, 115 insertions(+) create mode

[PATCH 5/6] Pmalloc: self-test

Add basic self-test functionality for pmalloc. Signed-off-by: Igor Stoppa --- mm/Kconfig| 9 mm/Makefile | 1 + mm/pmalloc-selftest.c | 61 +++ mm/pmalloc-selftest.h | 26 ++ 4 files changed, 97

[PATCH 6/6] Documentation for Pmalloc

Detailed documentation about the protectable memory allocator. Signed-off-by: Igor Stoppa --- Documentation/core-api/index.rst | 1 + Documentation/core-api/pmalloc.rst | 114 + 2 files changed, 115 insertions(+) create mode 100644

[PATCH v3] Add delay-init quirk for Corsair K70 RGB keyboards

Following on from this patch: https://lkml.org/lkml/2017/11/3/516, Corsair K70 RGB keyboards also require the DELAY_INIT quirk to start correctly at boot. Device ids found here: usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13 usb 3-3: New USB device strings: Mfr=1, Product=2,

[PATCH v3] Add delay-init quirk for Corsair K70 RGB keyboards

Following on from this patch: https://lkml.org/lkml/2017/11/3/516, Corsair K70 RGB keyboards also require the DELAY_INIT quirk to start correctly at boot. Device ids found here: usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13 usb 3-3: New USB device strings: Mfr=1, Product=2,

[PATCH 4/6] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

[PATCH 4/6] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

[PATCH 3/6] struct page: add field for vm_struct

When a page is used for virtual memory, it is often necessary to obtian a handler to the corresponding vm_struct, which refers to the virtually continuous area generated when invoking vmalloc. The struct page has a "mapping" field, which can be re-used, to store a pointer to the parent area. This

[PATCH 3/6] struct page: add field for vm_struct

When a page is used for virtual memory, it is often necessary to obtian a handler to the corresponding vm_struct, which refers to the virtually continuous area generated when invoking vmalloc. The struct page has a "mapping" field, which can be re-used, to store a pointer to the parent area. This

[PATCH 1/6] genalloc: track beginning of allocations

The genalloc library is only capable of tracking if a certain unit of allocation is in use or not. It is not capable of discerning where the memory associated to an allocation request begins and where it ends. The reason is that units of allocations are tracked by using a bitmap, where each bit

[PATCH 2/6] genalloc: selftest

Introduce a set of macros for writing concise test cases for genalloc. The test cases are meant to provide regression testing, when working on new functionality for genalloc. Primarily they are meant to confirm that the various allocation strategy will continue to work as expected. The

[PATCH 1/6] genalloc: track beginning of allocations

The genalloc library is only capable of tracking if a certain unit of allocation is in use or not. It is not capable of discerning where the memory associated to an allocation request begins and where it ends. The reason is that units of allocations are tracked by using a bitmap, where each bit

[PATCH 2/6] genalloc: selftest

Introduce a set of macros for writing concise test cases for genalloc. The test cases are meant to provide regression testing, when working on new functionality for genalloc. Primarily they are meant to confirm that the various allocation strategy will continue to work as expected. The

<    1   2   3   4   5   6   7   8   9   >