usb/net/ath6kl: GPF in ath6kl_usb_alloc_urb_from_pipe

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). usb 1-1: New USB device found, idVendor=0cf3, idProduct=9375 usb 1-1: New USB device strings: Mfr=2, Product=255, SerialNumber=8 usb 1-1: Product: a usb 1-1:

usb/net/prism2usb: warning in hfa384x_drvr_start/usb_submit_urb

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). It seems that the driver doesn't check the endpoint type provided in the USB descriptor. usb 1-1: BOGUS urb xfer, pipe 3 != type 1 [ cut here

usb/net/ar5523: warning in ar5523_submit_rx_cmd/usb_submit_urb

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). It seems that the driver doesn't check the endpoint type provided in the USB descriptor. usb 1-1: BOGUS urb xfer, pipe 3 != type 1 [ cut here

usb/net/ar5523: warning in ar5523_submit_rx_cmd/usb_submit_urb

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). It seems that the driver doesn't check the endpoint type provided in the USB descriptor. usb 1-1: BOGUS urb xfer, pipe 3 != type 1 [ cut here

Re: [PATCH] net: thunderx: mark expected switch fall-throughs in nicvf_main()

From: "Gustavo A. R. Silva" Date: Mon, 9 Oct 2017 11:44:53 -0500 > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Cc: Sunil Goutham > Cc: Robert Richter > Cc:

Re: [PATCH] net: thunderx: mark expected switch fall-throughs in nicvf_main()

From: "Gustavo A. R. Silva" Date: Mon, 9 Oct 2017 11:44:53 -0500 > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Cc: Sunil Goutham > Cc: Robert Richter > Cc: linux-arm-ker...@lists.infradead.org > Cc: net...@vger.kernel.org

Re: [PATCH] linux/types.h: Restore the ability to disable sparse endianness checks

On Mon, Oct 09, 2017 at 03:07:42PM +, Bart Van Assche wrote: > On Mon, 2017-10-09 at 16:22 +0300, Michael S. Tsirkin wrote: > > On Fri, Oct 06, 2017 at 10:23:53AM -0700, Bart Van Assche wrote: > > > The purpose of patch "linux/types.h: enable endian checks for all > > > sparse builds" was to

Re: [PATCH] linux/types.h: Restore the ability to disable sparse endianness checks

On Mon, Oct 09, 2017 at 03:07:42PM +, Bart Van Assche wrote: > On Mon, 2017-10-09 at 16:22 +0300, Michael S. Tsirkin wrote: > > On Fri, Oct 06, 2017 at 10:23:53AM -0700, Bart Van Assche wrote: > > > The purpose of patch "linux/types.h: enable endian checks for all > > > sparse builds" was to

[PATCH v2] arm64: Expose support for optional ARMv8-A features

ARMv8-A adds a few optional features for ARMv8.2 and ARMv8.3. Expose them to the userspace via HWCAPs and mrs emulation. SHA2-512 - Instruction support for SHA512 Has algorithm (e.g SHA512H, SHA512H2, SHA512U0, SHA512SU1) SHA3 - SHA3 crypto instructions (EOR3, RAX1, XAR, BCAX).

[PATCH v2] arm64: Expose support for optional ARMv8-A features

ARMv8-A adds a few optional features for ARMv8.2 and ARMv8.3. Expose them to the userspace via HWCAPs and mrs emulation. SHA2-512 - Instruction support for SHA512 Has algorithm (e.g SHA512H, SHA512H2, SHA512U0, SHA512SU1) SHA3 - SHA3 crypto instructions (EOR3, RAX1, XAR, BCAX).

Re: [PATCH] Input: synaptics-rmi4: Clean up redundant check

On Sun, Oct 08, 2017 at 11:26:51PM +0100, Christos Gkekas wrote: > Variable size_presence_reg·is unsigned so checking whether it is less > than zero is redundant. > > Signed-off-by: Christos Gkekas I'd rather we kept the check as it documents the valid range of values. >

Re: [PATCH] Input: synaptics-rmi4: Clean up redundant check

On Sun, Oct 08, 2017 at 11:26:51PM +0100, Christos Gkekas wrote: > Variable size_presence_reg·is unsigned so checking whether it is less > than zero is redundant. > > Signed-off-by: Christos Gkekas I'd rather we kept the check as it documents the valid range of values. > --- >

Re: [PATCH] Input: atmel_mxt_ts - Remove unnecessary byte_offset check

On Sun, Oct 08, 2017 at 08:41:16PM +0100, Nick Dyer wrote: > On Sun, Oct 08, 2017 at 07:44:18PM +0100, Christos Gkekas wrote: > > Variable byte_offset is unsigned so checking whether it is greater or > > equal to zero is redundant. > > > > Signed-off-by: Christos Gkekas >

Re: [PATCH] Input: atmel_mxt_ts - Remove unnecessary byte_offset check

On Sun, Oct 08, 2017 at 08:41:16PM +0100, Nick Dyer wrote: > On Sun, Oct 08, 2017 at 07:44:18PM +0100, Christos Gkekas wrote: > > Variable byte_offset is unsigned so checking whether it is greater or > > equal to zero is redundant. > > > > Signed-off-by: Christos Gkekas > > Yep - looks sensible

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

On Mon, Oct 09, 2017 at 07:02:31PM +0200, Borislav Petkov wrote: > From 29a6426c20f25b8df767356a04727cb113e8e784 Mon Sep 17 00:00:00 2001 > From: Andy Lutomirski > Date: Mon, 9 Oct 2017 09:50:49 -0700 > Subject: [PATCH] x86/mm: Flush more aggressively in lazy TLB mode > > Since

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

On Mon, Oct 09, 2017 at 07:02:31PM +0200, Borislav Petkov wrote: > From 29a6426c20f25b8df767356a04727cb113e8e784 Mon Sep 17 00:00:00 2001 > From: Andy Lutomirski > Date: Mon, 9 Oct 2017 09:50:49 -0700 > Subject: [PATCH] x86/mm: Flush more aggressively in lazy TLB mode > > Since commit

Re: [PATCH v2] isdn/gigaset: Convert timers to use timer_setup()

On Mon, Oct 9, 2017 at 2:15 AM, David Laight wrote: > From: Kees Cook >> Sent: 06 October 2017 20:40 > ... >> I'm in no rush for any specific change. There are about 900 call sites >> I'm making my way through, about 2/3rd are pretty trivial, and the >> less obvious is

Re: [PATCH v2] isdn/gigaset: Convert timers to use timer_setup()

On Mon, Oct 9, 2017 at 2:15 AM, David Laight wrote: > From: Kees Cook >> Sent: 06 October 2017 20:40 > ... >> I'm in no rush for any specific change. There are about 900 call sites >> I'm making my way through, about 2/3rd are pretty trivial, and the >> less obvious is what I've started sending

Re: [PATCH] input: atmel_mxt_ts: detect touchpad from devicetree

On 8 October 2017 at 21:56, Nick Dyer wrote: > On Wed, Oct 04, 2017 at 09:35:31PM +0200, Emil Renner Berthing wrote: >> The Samsung Chromebook Plus (rk3399-gru-kevin) has two of >> these controllers. One for the touchscreen and one for >> the touchpad. However the touchpad

[GIT PULL] Please pull NFS client changes

Hi Linus, The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff: Linux 4.14-rc3 (2017-10-01 14:54:54 -0700) are available in the git repository at: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.14-3 for you to fetch changes up to

Re: [PATCH] input: atmel_mxt_ts: detect touchpad from devicetree

On 8 October 2017 at 21:56, Nick Dyer wrote: > On Wed, Oct 04, 2017 at 09:35:31PM +0200, Emil Renner Berthing wrote: >> The Samsung Chromebook Plus (rk3399-gru-kevin) has two of >> these controllers. One for the touchscreen and one for >> the touchpad. However the touchpad doesn't have any >>

[GIT PULL] Please pull NFS client changes

Hi Linus, The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff: Linux 4.14-rc3 (2017-10-01 14:54:54 -0700) are available in the git repository at: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.14-3 for you to fetch changes up to

Re: [PATCH] skd: Use kmem_cache_free

On Mon, 2017-10-09 at 03:00 +0530, Himanshu Jha wrote: > Use kmem_cache_free instead of kfree for freeing the memory previously > allocated with kmem_cache_zalloc/kmem_cache_alloc/kmem_cache_node. > > Signed-off-by: Himanshu Jha > --- > drivers/block/skd_main.c | 2

Re: [PATCH] skd: Use kmem_cache_free

On Mon, 2017-10-09 at 03:00 +0530, Himanshu Jha wrote: > Use kmem_cache_free instead of kfree for freeing the memory previously > allocated with kmem_cache_zalloc/kmem_cache_alloc/kmem_cache_node. > > Signed-off-by: Himanshu Jha > --- > drivers/block/skd_main.c | 2 +- > 1 file changed, 1

Re: [PATCH] thunderbolt: Initialize Thunderbolt bus earlier

From: Mika Westerberg Date: Mon, 9 Oct 2017 16:22:34 +0300 > The 0day kbuild robot reports following crash: ... > The reason is that both Thunderbolt bus and thunderbolt-net are build > into the kernel image, and the latter is linked first because > drivers/net

Re: [PATCH] thunderbolt: Initialize Thunderbolt bus earlier

From: Mika Westerberg Date: Mon, 9 Oct 2017 16:22:34 +0300 > The 0day kbuild robot reports following crash: ... > The reason is that both Thunderbolt bus and thunderbolt-net are build > into the kernel image, and the latter is linked first because > drivers/net comes before

Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

On Mon, Oct 09, 2017 at 05:30:03PM +0100, Mark Brown wrote: >On Mon, Oct 09, 2017 at 04:23:21PM +, Levin, Alexander (Sasha Levin) wrote: > >> Okay, so something like [REVIEW automatic-patch-selection for 4.X] >> is sort of what you're suggesting? > >Yeah (perhaps a bit less verbose so some of

Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

On Mon, Oct 09, 2017 at 05:30:03PM +0100, Mark Brown wrote: >On Mon, Oct 09, 2017 at 04:23:21PM +, Levin, Alexander (Sasha Levin) wrote: > >> Okay, so something like [REVIEW automatic-patch-selection for 4.X] >> is sort of what you're suggesting? > >Yeah (perhaps a bit less verbose so some of

Re: [PATCH] nfp: convert nfp_eth_set_bit_config() into a macro

El Wed, Oct 04, 2017 at 07:13:26PM -0700 Manoj Gupta ha dit: > On Wed, Oct 4, 2017 at 7:06 PM, Jakub Kicinski > wrote: > > On Wed, 4 Oct 2017 18:50:04 -0700, Manoj Gupta wrote: > >> On Wed, Oct 4, 2017 at 5:56 PM, Jakub Kicinski wrote: > >> > On Wed, 4 Oct 2017

Re: [PATCH v2] netlink: do not set cb_running if dump's start() errs

From: "Jason A. Donenfeld" Date: Mon, 9 Oct 2017 14:14:51 +0200 > It turns out that multiple places can call netlink_dump(), which means > it's still possible to dereference partially initialized values in > dump() that were the result of a faulty returned start(). > > This

Re: [PATCH] nfp: convert nfp_eth_set_bit_config() into a macro

El Wed, Oct 04, 2017 at 07:13:26PM -0700 Manoj Gupta ha dit: > On Wed, Oct 4, 2017 at 7:06 PM, Jakub Kicinski > wrote: > > On Wed, 4 Oct 2017 18:50:04 -0700, Manoj Gupta wrote: > >> On Wed, Oct 4, 2017 at 5:56 PM, Jakub Kicinski wrote: > >> > On Wed, 4 Oct 2017 17:38:22 -0700, Manoj Gupta wrote:

Re: [PATCH v2] netlink: do not set cb_running if dump's start() errs

From: "Jason A. Donenfeld" Date: Mon, 9 Oct 2017 14:14:51 +0200 > It turns out that multiple places can call netlink_dump(), which means > it's still possible to dereference partially initialized values in > dump() that were the result of a faulty returned start(). > > This fixes the issue by

[PATCH] perf/x86/intel/uncore: fix memory leaks on allocation failures

From: Colin Ian King Currently if an allocation fails then the error return paths don't free up any currently allocated pmus[].boxes and pmus causing a memory leak. Add an error clean up exit path that frees these objects. Detected by CoverityScan, CID#711632

[PATCH] perf/x86/intel/uncore: fix memory leaks on allocation failures

From: Colin Ian King Currently if an allocation fails then the error return paths don't free up any currently allocated pmus[].boxes and pmus causing a memory leak. Add an error clean up exit path that frees these objects. Detected by CoverityScan, CID#711632 ("Resource Leak") Fixes:

Re: [RFC PATCH] mm: shm: round up tmpfs size to huge page size when huge=always

On Tue 10-10-17 00:43:31, Yang Shi wrote: > > > On 10/8/17 11:48 PM, Michal Hocko wrote: > > On Sun 08-10-17 15:56:51, Kirill A. Shutemov wrote: > > > On Sat, Oct 07, 2017 at 04:22:10AM +0800, Yang Shi wrote: > > > > When passing "huge=always" option for mounting tmpfs, THP is supposed to > > >

Re: [RFC PATCH] mm: shm: round up tmpfs size to huge page size when huge=always

On Tue 10-10-17 00:43:31, Yang Shi wrote: > > > On 10/8/17 11:48 PM, Michal Hocko wrote: > > On Sun 08-10-17 15:56:51, Kirill A. Shutemov wrote: > > > On Sat, Oct 07, 2017 at 04:22:10AM +0800, Yang Shi wrote: > > > > When passing "huge=always" option for mounting tmpfs, THP is supposed to > > >

Re: [PATCH 3.2 00/74] 3.2.94-rc1 review

On Mon, 2017-10-09 at 08:53 -0700, Guenter Roeck wrote: > On Mon, Oct 09, 2017 at 01:30:33PM +0100, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.94 release. > > There are 74 patches in this series, which will be posted as responses > > to this one. If anyone

Re: [PATCH 3.2 00/74] 3.2.94-rc1 review

On Mon, 2017-10-09 at 08:53 -0700, Guenter Roeck wrote: > On Mon, Oct 09, 2017 at 01:30:33PM +0100, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.94 release. > > There are 74 patches in this series, which will be posted as responses > > to this one. If anyone

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

On Mon, Oct 09, 2017 at 12:15:17PM -0500, Bjorn Helgaas wrote: > [+cc Rafael, linux-pm] > > Hi Jia-Ju, > > On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote: > > The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, > > which may sleep. > > The function call paths

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

On Mon, Oct 09, 2017 at 12:15:17PM -0500, Bjorn Helgaas wrote: > [+cc Rafael, linux-pm] > > Hi Jia-Ju, > > On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote: > > The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, > > which may sleep. > > The function call paths

Re: [PATCH] i2c: ismt: Separate I2C block read from SMBus block read

> So, I'll wait for his tests and then send it to Linus ASAP. I think it > should be in rc5. I've been able to confirm the regression my patch introduced, and the fix from Pontus. Doing a block read of the SPD EEPROM with my patch everything is shifted by a byte: [root@localhost ~]# i2cdump -y

Re: [PATCH] i2c: ismt: Separate I2C block read from SMBus block read

> So, I'll wait for his tests and then send it to Linus ASAP. I think it > should be in rc5. I've been able to confirm the regression my patch introduced, and the fix from Pontus. Doing a block read of the SPD EEPROM with my patch everything is shifted by a byte: [root@localhost ~]# i2cdump -y

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

Daniel Vetter writes: > I just figured that -modesetting would be the simplest domenstration > vehicle, since the vulkan patches don't look ready yet. I need fully > reviewed userspace before we can land any kernel stuff. Doing > the quick modesetting conversion would unblock.

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

Daniel Vetter writes: > I just figured that -modesetting would be the simplest domenstration > vehicle, since the vulkan patches don't look ready yet. I need fully > reviewed userspace before we can land any kernel stuff. Doing > the quick modesetting conversion would unblock. I've provided a

[PATCH linux-firmware 3/3] WHENCE: Add new qed firmware

Signed-off-by: Ben Hutchings --- WHENCE | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/WHENCE b/WHENCE index 2261a349f7cc..b2dc6a10abb2 100644 --- a/WHENCE +++ b/WHENCE @@ -2079,11 +2079,12 @@ File: qed/qed_init_values_zipped-8.7.3.0.bin File:

[PATCH linux-firmware 3/3] WHENCE: Add new qed firmware

Signed-off-by: Ben Hutchings --- WHENCE | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/WHENCE b/WHENCE index 2261a349f7cc..b2dc6a10abb2 100644 --- a/WHENCE +++ b/WHENCE @@ -2079,11 +2079,12 @@ File: qed/qed_init_values_zipped-8.7.3.0.bin File:

[PATCH linux-firmware 2/3] WHENCE: Add new radeon firmware

Signed-off-by: Ben Hutchings --- WHENCE | 2 ++ 1 file changed, 2 insertions(+) diff --git a/WHENCE b/WHENCE index 3010ec56583e..2261a349f7cc 100644 --- a/WHENCE +++ b/WHENCE @@ -1874,6 +1874,8 @@ File: radeon/mullins_sdma.bin File: radeon/mullins_sdma1.bin File:

[PATCH linux-firmware 2/3] WHENCE: Add new radeon firmware

Signed-off-by: Ben Hutchings --- WHENCE | 2 ++ 1 file changed, 2 insertions(+) diff --git a/WHENCE b/WHENCE index 3010ec56583e..2261a349f7cc 100644 --- a/WHENCE +++ b/WHENCE @@ -1874,6 +1874,8 @@ File: radeon/mullins_sdma.bin File: radeon/mullins_sdma1.bin File: radeon/mullins_uvd.bin File:

[PATCH linux-firmware 1/3] WHENCE: Fix syntax error for iwlwifi-8265-31.ucode entry

Signed-off-by: Ben Hutchings --- WHENCE | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/WHENCE b/WHENCE index 5278323c0a84..3010ec56583e 100644 --- a/WHENCE +++ b/WHENCE @@ -974,7 +974,7 @@ Version 22.391740.0 File: iwlwifi-8265-27.ucode Version

[PATCH linux-firmware 1/3] WHENCE: Fix syntax error for iwlwifi-8265-31.ucode entry

Signed-off-by: Ben Hutchings --- WHENCE | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/WHENCE b/WHENCE index 5278323c0a84..3010ec56583e 100644 --- a/WHENCE +++ b/WHENCE @@ -974,7 +974,7 @@ Version 22.391740.0 File: iwlwifi-8265-27.ucode Version 27.541033.0 -File

[PATCH] firmware: bluefield: add boot control driver

The Mellanox BlueField SoC firmware supports a safe upgrade mode as part of the flow where users put new firmware on the secondary eMMC boot partition (the one not currently in use), tell the eMMC to make the secondary boot partition primary, and reset. This driver is used to request that the

[PATCH] firmware: bluefield: add boot control driver

The Mellanox BlueField SoC firmware supports a safe upgrade mode as part of the flow where users put new firmware on the secondary eMMC boot partition (the one not currently in use), tell the eMMC to make the secondary boot partition primary, and reset. This driver is used to request that the

[PATCH linux-firmware 0/3] Add new files to WHENCE

Several recent commits added files but didn't add corresponding entries in WHENCE. As a reminder, 'make check' will check that all files are listed. I've committed and pushed the following changes. Ben. Ben Hutchings (3): WHENCE: Fix syntax error for iwlwifi-8265-31.ucode entry WHENCE: Add

[PATCH linux-firmware 0/3] Add new files to WHENCE

Several recent commits added files but didn't add corresponding entries in WHENCE. As a reminder, 'make check' will check that all files are listed. I've committed and pushed the following changes. Ben. Ben Hutchings (3): WHENCE: Fix syntax error for iwlwifi-8265-31.ucode entry WHENCE: Add

Re: [PATCH v2] net/core: Fix BUG to BUG_ON conditionals.

On Mon, Oct 09, 2017 at 11:37:59AM -0400, Tim Hansen wrote: > Fix BUG() calls to use BUG_ON(conditional) macros. > > This was found using make coccicheck M=net/core on linux next > tag next-2017092 > > Signed-off-by: Tim Hansen > --- > net/core/skbuff.c | 15

Re: [PATCH v2] net/core: Fix BUG to BUG_ON conditionals.

On Mon, Oct 09, 2017 at 11:37:59AM -0400, Tim Hansen wrote: > Fix BUG() calls to use BUG_ON(conditional) macros. > > This was found using make coccicheck M=net/core on linux next > tag next-2017092 > > Signed-off-by: Tim Hansen > --- > net/core/skbuff.c | 15 ++- > 1 file changed,

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

[+cc Rafael, linux-pm] Hi Jia-Ju, On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote: > The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, > which may sleep. > The function call paths are: > gma_power_begin (acquire the spinlock) (drivers/gpu/drm/gma500/power.c) >

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

[+cc Rafael, linux-pm] Hi Jia-Ju, On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote: > The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, > which may sleep. > The function call paths are: > gma_power_begin (acquire the spinlock) (drivers/gpu/drm/gma500/power.c) >

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

On Tue, Oct 03, 2017 at 03:48:46PM +0100, Mark Rutland wrote: > On Wed, Sep 20, 2017 at 04:17:11PM -0400, Pavel Tatashin wrote: > > During early boot, kasan uses vmemmap_populate() to establish its shadow > > memory. But, that interface is intended for struct pages use. > > > > Because of the

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

On Tue, Oct 03, 2017 at 03:48:46PM +0100, Mark Rutland wrote: > On Wed, Sep 20, 2017 at 04:17:11PM -0400, Pavel Tatashin wrote: > > During early boot, kasan uses vmemmap_populate() to establish its shadow > > memory. But, that interface is intended for struct pages use. > > > > Because of the

Re: [PATCH] IB/core: remove redundant check on prot_sg_cnt

On Mon, 2017-10-09 at 17:12 +0100, Colin King wrote: > From: Colin Ian King > > prot_sg_cnt cannot be zero as a previous check on ret (from which > prot_sg_cnt is assigned) returns -ENOMEM if is it zero. Since > it cannot be zero we can simplify the code by removing

Re: [PATCH] IB/core: remove redundant check on prot_sg_cnt

On Mon, 2017-10-09 at 17:12 +0100, Colin King wrote: > From: Colin Ian King > > prot_sg_cnt cannot be zero as a previous check on ret (from which > prot_sg_cnt is assigned) returns -ENOMEM if is it zero. Since > it cannot be zero we can simplify the code by removing the non > -zero check on

Re: [PATCH 2/2] MIPS: math-emu: Use preferred flavor of unsigned integer declarations

On Fri, Oct 06, 2017 at 07:29:01PM +0200, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fix occurences of unsigned integer declarations that are not > preferred by standards of checkpatch scripts. This removes > significant number of checkpatch

Re: [PATCH 2/2] MIPS: math-emu: Use preferred flavor of unsigned integer declarations

On Fri, Oct 06, 2017 at 07:29:01PM +0200, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fix occurences of unsigned integer declarations that are not > preferred by standards of checkpatch scripts. This removes > significant number of checkpatch warnings in math-emu > directory

Re: [PATCH, RFC] x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G

On Mon, Oct 09, 2017 at 09:54:53AM -0700, Dave Hansen wrote: > On 10/09/2017 09:09 AM, Kirill A. Shutemov wrote: > > Apart from trampoline itself we also need place to store top level page > > table in lower memory as we don't have a way to load 64-bit value into > > CR3 from 32-bit mode. We only

Re: [PATCH, RFC] x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G

On Mon, Oct 09, 2017 at 09:54:53AM -0700, Dave Hansen wrote: > On 10/09/2017 09:09 AM, Kirill A. Shutemov wrote: > > Apart from trampoline itself we also need place to store top level page > > table in lower memory as we don't have a way to load 64-bit value into > > CR3 from 32-bit mode. We only

Re: [RFC 1/2] ARM: dts: exynos: update the usbdrd phy and ref clk

On Mon, Oct 09, 2017 at 02:36:13AM +0530, Anand Moon wrote: > Hi Krzysztof, > > On 8 October 2017 at 21:17, Krzysztof Kozlowski wrote: > > On Sun, Oct 08, 2017 at 06:06:19PM +0530, Anand Moon wrote: > >> Hi Krzysztof, > >> > >> On 6 October 2017 at 12:08, Krzysztof Kozlowski

Re: [RFC 1/2] ARM: dts: exynos: update the usbdrd phy and ref clk

On Mon, Oct 09, 2017 at 02:36:13AM +0530, Anand Moon wrote: > Hi Krzysztof, > > On 8 October 2017 at 21:17, Krzysztof Kozlowski wrote: > > On Sun, Oct 08, 2017 at 06:06:19PM +0530, Anand Moon wrote: > >> Hi Krzysztof, > >> > >> On 6 October 2017 at 12:08, Krzysztof Kozlowski wrote: > >> > On

Re: [PATCH 3.2 00/74] 3.2.94-rc1 review

On Mon, Oct 09, 2017 at 01:30:33PM +0100, Ben Hutchings wrote: > This is the start of the stable review cycle for the 3.2.94 release. > There are 74 patches in this series, which will be posted as responses > to this one. If anyone has any issues with these being applied, please > let me know. >

Re: [PATCH 3.2 00/74] 3.2.94-rc1 review

On Mon, Oct 09, 2017 at 01:30:33PM +0100, Ben Hutchings wrote: > This is the start of the stable review cycle for the 3.2.94 release. > There are 74 patches in this series, which will be posted as responses > to this one. If anyone has any issues with these being applied, please > let me know. >

Re: [PATCH v2] netlink: do not set cb_running if dump's start() errs

On Mon, Oct 9, 2017 at 2:31 PM, Johannes Berg wrote: > > Reviewed-by: Johannes Berg Thanks for the review. Hopefully this can make it into 4.13.6 and 4.14-rc5.

Re: [PATCH v2] netlink: do not set cb_running if dump's start() errs

On Mon, Oct 9, 2017 at 2:31 PM, Johannes Berg wrote: > > Reviewed-by: Johannes Berg Thanks for the review. Hopefully this can make it into 4.13.6 and 4.14-rc5.

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

+ Johannes Hirte. On Mon, Oct 09, 2017 at 09:50:49AM -0700, Andy Lutomirski wrote: > Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way ... > There are two optimizations we should probably do on top of this. > > - In lazy mode, we should switch to init_mm when entering a long

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

+ Johannes Hirte. On Mon, Oct 09, 2017 at 09:50:49AM -0700, Andy Lutomirski wrote: > Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way ... > There are two optimizations we should probably do on top of this. > > - In lazy mode, we should switch to init_mm when entering a long

Re: [PATCH v2 2/2] KVM: VMX: Don't expose unrestricted_guest is enabled if ept is disabled

Looks great. On Mon, Oct 9, 2017 at 4:00 AM, Wanpeng Li wrote: > From: Wanpeng Li > > SDM mentioned: > > "If either the “unrestricted guest” VM-execution control or the “mode-based > execute control for EPT” VM- execution control is 1, the “enable

Re: [PATCH v2 2/2] KVM: VMX: Don't expose unrestricted_guest is enabled if ept is disabled

Looks great. On Mon, Oct 9, 2017 at 4:00 AM, Wanpeng Li wrote: > From: Wanpeng Li > > SDM mentioned: > > "If either the “unrestricted guest” VM-execution control or the “mode-based > execute control for EPT” VM- execution control is 1, the “enable EPT” > VM-execution control must also be

Re: [RFC 2/2] phy: exynos5-usbdrd: remove disable and enable of phy clk

On Mon, Oct 09, 2017 at 08:46:48PM +0530, Anand Moon wrote: > hi Krzysztof, > > On 9 October 2017 at 02:37, Anand Moon wrote: > > Hi Krzysztof, > > > > On 8 October 2017 at 21:20, Krzysztof Kozlowski wrote: > >> On Sun, Oct 08, 2017 at 06:11:12PM +0530,

Re: [RFC 2/2] phy: exynos5-usbdrd: remove disable and enable of phy clk

On Mon, Oct 09, 2017 at 08:46:48PM +0530, Anand Moon wrote: > hi Krzysztof, > > On 9 October 2017 at 02:37, Anand Moon wrote: > > Hi Krzysztof, > > > > On 8 October 2017 at 21:20, Krzysztof Kozlowski wrote: > >> On Sun, Oct 08, 2017 at 06:11:12PM +0530, Anand Moon wrote: > >>> Hi Krzysztof, >

Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

On Sat, 7 Oct 2017 18:35:40 +0900 Masami Hiramatsu wrote: > > The ftrace context > > == > > > > WARNING: The ability to add a callback to almost any function within the > > kernel comes with risks. A callback can be called from any context > > (normal,

Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

On Sat, 7 Oct 2017 18:35:40 +0900 Masami Hiramatsu wrote: > > The ftrace context > > == > > > > WARNING: The ability to add a callback to almost any function within the > > kernel comes with risks. A callback can be called from any context > > (normal, softirq, irq, and NMI).

Re: [PATCH] iommu/vt-d: Don't register bus-notifier under

On 2017-10-06 15:08, Joerg Roedel wrote: > Hey Jan, > > On Wed, Sep 27, 2017 at 04:19:15PM +0200, Jan Kiszka wrote: >> If we could drop the dmar_global_lock around bus_register_notifier in >> dmar_dev_scope_init, the issue above would likely be resolved. > > That is true. Can you please try this

Re: [PATCH] iommu/vt-d: Don't register bus-notifier under

On 2017-10-06 15:08, Joerg Roedel wrote: > Hey Jan, > > On Wed, Sep 27, 2017 at 04:19:15PM +0200, Jan Kiszka wrote: >> If we could drop the dmar_global_lock around bus_register_notifier in >> dmar_dev_scope_init, the issue above would likely be resolved. > > That is true. Can you please try this

Linux Foundation Technical Advisory Board Elections -- Call for nominations

Hello everyone, The Linux Foundation Technical Advisory Board (TAB) serves as the interface between the kernel development community and the Foundation. The TAB advises the Foundation on kernel-related matters, helps member companies learn to work with the community, and works to resolve

Linux Foundation Technical Advisory Board Elections -- Call for nominations

Hello everyone, The Linux Foundation Technical Advisory Board (TAB) serves as the interface between the kernel development community and the Foundation. The TAB advises the Foundation on kernel-related matters, helps member companies learn to work with the community, and works to resolve

Re: [PATCH, RFC] x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G

On 10/09/2017 09:09 AM, Kirill A. Shutemov wrote: > Apart from trampoline itself we also need place to store top level page > table in lower memory as we don't have a way to load 64-bit value into > CR3 from 32-bit mode. We only really need 8-bytes there as we only use > the very first entry of

Re: [PATCH, RFC] x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G

On 10/09/2017 09:09 AM, Kirill A. Shutemov wrote: > Apart from trampoline itself we also need place to store top level page > table in lower memory as we don't have a way to load 64-bit value into > CR3 from 32-bit mode. We only really need 8-bytes there as we only use > the very first entry of

Linux Foundation Technical Advisory Board Elections -- Call for nominations

Hello everyone, The Linux Foundation Technical Advisory Board (TAB) serves as the interface between the kernel development community and the Foundation. The TAB advises the Foundation on kernel-related matters, helps member companies learn to work with the community, and works to resolve

Linux Foundation Technical Advisory Board Elections -- Call for nominations

Hello everyone, The Linux Foundation Technical Advisory Board (TAB) serves as the interface between the kernel development community and the Foundation. The TAB advises the Foundation on kernel-related matters, helps member companies learn to work with the community, and works to resolve

Re: [PATCH 0/4] RCU: introduce noref debug

On Fri, 2017-10-06 at 09:34 -0700, Paul E. McKenney wrote: > On Fri, Oct 06, 2017 at 05:10:09PM +0200, Paolo Abeni wrote: > > Hi, > > > > On Fri, 2017-10-06 at 06:34 -0700, Paul E. McKenney wrote: > > > On Fri, Oct 06, 2017 at 02:57:45PM +0200, Paolo Abeni wrote: > > > > The networking subsystem

Re: [PATCH 0/4] RCU: introduce noref debug

On Fri, 2017-10-06 at 09:34 -0700, Paul E. McKenney wrote: > On Fri, Oct 06, 2017 at 05:10:09PM +0200, Paolo Abeni wrote: > > Hi, > > > > On Fri, 2017-10-06 at 06:34 -0700, Paul E. McKenney wrote: > > > On Fri, Oct 06, 2017 at 02:57:45PM +0200, Paolo Abeni wrote: > > > > The networking subsystem

[RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way lazy: when running a kernel thread (including the idle thread), the kernel keeps using the last user mm's page tables without attempting to maintain user TLB coherence at all. From a pure semantic perspective, this is fine --

[RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way lazy: when running a kernel thread (including the idle thread), the kernel keeps using the last user mm's page tables without attempting to maintain user TLB coherence at all. From a pure semantic perspective, this is fine --

Re: pull request: linux-firmware: update cxgb4 firmware

On Wed, 2017-09-27 at 20:54 +0530, Ganesh Goudar wrote: > Hi, > > Kindly pull the new firmware from the following URL. > git://git.chelsio.net/pub/git/linux-firmware.git for-upstream Pulled, thanks. Ben. > Thanks > Ganesh > > The following changes since commit

Re: pull request: linux-firmware: update cxgb4 firmware

On Wed, 2017-09-27 at 20:54 +0530, Ganesh Goudar wrote: > Hi, > > Kindly pull the new firmware from the following URL. > git://git.chelsio.net/pub/git/linux-firmware.git for-upstream Pulled, thanks. Ben. > Thanks > Ganesh > > The following changes since commit

Re: [PATCH net-next 0/7] A few cleanup for hns3 ethernet driver

From: Yunsheng Lin Date: Mon, 9 Oct 2017 15:43:54 +0800 > This patchset contains a few cleanup for hns3 ethernet driver. > No functional change intended. Series applied, thank you.

Re: [PATCH net-next 0/7] A few cleanup for hns3 ethernet driver

From: Yunsheng Lin Date: Mon, 9 Oct 2017 15:43:54 +0800 > This patchset contains a few cleanup for hns3 ethernet driver. > No functional change intended. Series applied, thank you.

Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

On Sat, 7 Oct 2017 14:24:53 +0900 Stafford Horne wrote: > Hello, > > Nice read, see some comments below Thanks. > > To enable tracing call: > > > > register_ftrace_function(); > > Maybe it would help to have a small section on 'The register function' > below to

Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

On Sat, 7 Oct 2017 14:24:53 +0900 Stafford Horne wrote: > Hello, > > Nice read, see some comments below Thanks. > > To enable tracing call: > > > > register_ftrace_function(); > > Maybe it would help to have a small section on 'The register function' > below to answer? > > Is it

[PATCH v3] irqchip/gicv3-its: Add missing changes to support 52bit physical address

The current ITS driver works fine as long as normal memory and GICR regions are located within the lower 48bit (>=0 && <2^48) physical address space. Some of the registers GICR_PEND/PROP, GICR_VPEND/VPROP and GITS_CBASER are handled properly but not all when configuring the hardware with 52bit

[PATCH v3] irqchip/gicv3-its: Add missing changes to support 52bit physical address

The current ITS driver works fine as long as normal memory and GICR regions are located within the lower 48bit (>=0 && <2^48) physical address space. Some of the registers GICR_PEND/PROP, GICR_VPEND/VPROP and GITS_CBASER are handled properly but not all when configuring the hardware with 52bit

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