PROBLEM: kernel causes udev to spin up floppy drive permanently without disk inserted

[1.] One line summary of the problem: The linux kernel causes udev to spin up floppy drive permanently without disk inserted [2.] Full description of the problem/report: Using a SCSI floppy drive (possibly the same for a USDB floppy drive). Boot is very p[2.] Full description of the

PROBLEM: kernel causes udev to spin up floppy drive permanently without disk inserted

[1.] One line summary of the problem: The linux kernel causes udev to spin up floppy drive permanently without disk inserted [2.] Full description of the problem/report: Using a SCSI floppy drive (possibly the same for a USDB floppy drive). Boot is very p[2.] Full description of the

Re: [RFT PATCH v3 6/6] uvcvideo: Move decode processing to process context

Hi Guennadi, Thanks for your review and time on this. I certainly appreciate the extra eyes here! On 12/01/18 09:37, Guennadi Liakhovetski wrote: > Hi Kieran, > > On Fri, 12 Jan 2018, Kieran Bingham wrote: > >> Newer high definition cameras, and cameras with multiple lenses such as >> the

Re: [RFT PATCH v3 6/6] uvcvideo: Move decode processing to process context

Hi Guennadi, Thanks for your review and time on this. I certainly appreciate the extra eyes here! On 12/01/18 09:37, Guennadi Liakhovetski wrote: > Hi Kieran, > > On Fri, 12 Jan 2018, Kieran Bingham wrote: > >> Newer high definition cameras, and cameras with multiple lenses such as >> the

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On (01/12/18 13:55), Petr Mladek wrote: [..] > > I'm not fixing console_unlock(), I'm fixing printk(). BTW, all my > > kernels are CONFIG_PREEMPT (I'm a RT guy), my mind thinks more about > > PREEMPT kernels than !PREEMPT ones. > > I would say that the patch improves also console_unlock() but

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On (01/12/18 13:55), Petr Mladek wrote: [..] > > I'm not fixing console_unlock(), I'm fixing printk(). BTW, all my > > kernels are CONFIG_PREEMPT (I'm a RT guy), my mind thinks more about > > PREEMPT kernels than !PREEMPT ones. > > I would say that the patch improves also console_unlock() but

Re: BUG: unable to handle kernel paging request in check_memory_region

On Fri, Jan 12, 2018 at 11:58 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > c92a9a461dff6140c539c61e457aa97df29517d6 > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC) 7.1.1

Re: BUG: unable to handle kernel paging request in check_memory_region

On Fri, Jan 12, 2018 at 11:58 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > c92a9a461dff6140c539c61e457aa97df29517d6 > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

[PATCH] EDAC, mv64x60: Remove some code duplication

Reorder the error handling code in order to release the resources in reverse order than allocation. Introduce a new 'release_group' label in the error handling path and use it to void some code duplication. Signed-off-by: Christophe JAILLET ---

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On (01/12/18 07:21), Steven Rostedt wrote: [..] > Yep, but I'm still not convinced you are seeing an issue with a single > printk. what do you mean by this? > An OOM does not do everything in one printk, it calls hundreds. > Having hundreds of printks is an issue, especially in critical

[PATCH] EDAC, mv64x60: Remove some code duplication

Reorder the error handling code in order to release the resources in reverse order than allocation. Introduce a new 'release_group' label in the error handling path and use it to void some code duplication. Signed-off-by: Christophe JAILLET --- drivers/edac/mv64x60_edac.c | 7 --- 1 file

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On (01/12/18 07:21), Steven Rostedt wrote: [..] > Yep, but I'm still not convinced you are seeing an issue with a single > printk. what do you mean by this? > An OOM does not do everything in one printk, it calls hundreds. > Having hundreds of printks is an issue, especially in critical

Re: general protection fault in __bpf_map_put

On Wed, Jan 10, 2018 at 1:58 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > b4464bcab38d3f7fe995a7cb960eeac6889bec08 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1

Re: general protection fault in __bpf_map_put

On Wed, Jan 10, 2018 at 1:58 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > b4464bcab38d3f7fe995a7cb960eeac6889bec08 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection

On 18-01-12 15:07:12, David Herrmann wrote: > Hi Andy > > On Fri, Jan 12, 2018 at 2:50 PM, Andy Shevchenko > wrote: > > On Fri, Jan 12, 2018 at 1:04 PM, David Herrmann > > wrote: > >> Cc: Matthew Thode > > > > Shouldn't be

Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection

On 18-01-12 15:07:12, David Herrmann wrote: > Hi Andy > > On Fri, Jan 12, 2018 at 2:50 PM, Andy Shevchenko > wrote: > > On Fri, Jan 12, 2018 at 1:04 PM, David Herrmann > > wrote: > >> Cc: Matthew Thode > > > > Shouldn't be Suggested-by or even Signed-off-by? > > The patch is different

Re: [PATCH] usb: xhci-mtk: fix semicolon.cocci warnings

On Sat, 2018-01-13 at 01:46 +0800, kbuild test robot wrote: > From: Fengguang Wu > > drivers/usb/host/xhci-mtk.c:311:2-3: Unneeded semicolon > > > Remove unneeded semicolon. > > Generated by: scripts/coccinelle/misc/semicolon.cocci > > Fixes: a2ecc4df9f84 ("usb:

Re: [PATCH] usb: xhci-mtk: fix semicolon.cocci warnings

On Sat, 2018-01-13 at 01:46 +0800, kbuild test robot wrote: > From: Fengguang Wu > > drivers/usb/host/xhci-mtk.c:311:2-3: Unneeded semicolon > > > Remove unneeded semicolon. > > Generated by: scripts/coccinelle/misc/semicolon.cocci > > Fixes: a2ecc4df9f84 ("usb: xhci-mtk: supports remote

Re: Yet another KPTI regression with 4.14.x series in a VM

On Fri, Jan 12, 2018 at 10:08:20PM -0800, Andy Lutomirski wrote: > In fact, it looks like this code is totally bogus and has never been > correct at all. Even in: > > commit 4b1d5ae3b103eda43f9d0f85c355bb6995b03a30 > Author: Peter Zijlstra > Date: Mon Dec 4 15:07:59 2017

Re: Yet another KPTI regression with 4.14.x series in a VM

On Fri, Jan 12, 2018 at 10:08:20PM -0800, Andy Lutomirski wrote: > In fact, it looks like this code is totally bogus and has never been > correct at all. Even in: > > commit 4b1d5ae3b103eda43f9d0f85c355bb6995b03a30 > Author: Peter Zijlstra > Date: Mon Dec 4 15:07:59 2017 +0100 > >

Re: [PATCH] usb: mtu3: fix semicolon.cocci warnings

On Sat, 2018-01-13 at 01:18 +0800, kbuild test robot wrote: > From: Fengguang Wu > > drivers/usb/mtu3/mtu3_host.c:58:2-3: Unneeded semicolon > > > Remove unneeded semicolon. > > Generated by: scripts/coccinelle/misc/semicolon.cocci > > Fixes: f0ede2c6282b ("usb:

Re: [PATCH] usb: mtu3: fix semicolon.cocci warnings

On Sat, 2018-01-13 at 01:18 +0800, kbuild test robot wrote: > From: Fengguang Wu > > drivers/usb/mtu3/mtu3_host.c:58:2-3: Unneeded semicolon > > > Remove unneeded semicolon. > > Generated by: scripts/coccinelle/misc/semicolon.cocci > > Fixes: f0ede2c6282b ("usb: mtu3: supports remote wakeup

Re: [PATCH] selftests/x86: Add test_vsyscall

On Fri, Jan 12, 2018 at 4:57 AM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> tools/testing/selftests/x86/Makefile| 2 +- >> tools/testing/selftests/x86/test_vsyscall.c | 500 >> >> 2 files changed, 501

Re: [PATCH] selftests/x86: Add test_vsyscall

On Fri, Jan 12, 2018 at 4:57 AM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> tools/testing/selftests/x86/Makefile| 2 +- >> tools/testing/selftests/x86/test_vsyscall.c | 500 >> >> 2 files changed, 501 insertions(+), 1 deletion(-) >> create mode

Re: [PATCH] selftests/x86: Add test_vsyscall

Add missing cc's. Duh On Thu, Jan 11, 2018 at 5:16 PM, Andy Lutomirski wrote: > This tests that the vsyscall entries do what they're expected to do. > It also confirms that attempts to read the vsyscall page behave as > expected. > > If changes are made to the vsyscall code or

Re: [PATCH] selftests/x86: Add test_vsyscall

Add missing cc's. Duh On Thu, Jan 11, 2018 at 5:16 PM, Andy Lutomirski wrote: > This tests that the vsyscall entries do what they're expected to do. > It also confirms that attempts to read the vsyscall page behave as > expected. > > If changes are made to the vsyscall code or its memory map

Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl

On Thu, Jan 11, 2018 at 9:03 PM, Dave Hansen wrote: > On 01/11/2018 07:01 PM, Raj, Ashok wrote: >> On Thu, Jan 11, 2018 at 06:20:13PM -0800, Andy Lutomirski wrote: >>> On Thu, Jan 11, 2018 at 5:52 PM, Raj, Ashok wrote: > > What's wrong with

Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl

On Thu, Jan 11, 2018 at 9:03 PM, Dave Hansen wrote: > On 01/11/2018 07:01 PM, Raj, Ashok wrote: >> On Thu, Jan 11, 2018 at 06:20:13PM -0800, Andy Lutomirski wrote: >>> On Thu, Jan 11, 2018 at 5:52 PM, Raj, Ashok wrote: > > What's wrong with native_read_msr()? Yes, i think i

Linux kernel driver "r8169" for Realtek PCIE Gigabit network card is very unstable

Dear Linux kernel developers, Previously I have installed ipfire firewall appliance. The Linux kernel driver "e1000e" for Intel onboard Gigabit Network Card is very stable. I get consistently high download and high upload speeds. I used the onboard Intel Gigabit NIC for the WAN (RED) connection.

Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl

On Thu, Jan 11, 2018 at 7:01 PM, Raj, Ashok wrote: > On Thu, Jan 11, 2018 at 06:20:13PM -0800, Andy Lutomirski wrote: >> On Thu, Jan 11, 2018 at 5:52 PM, Raj, Ashok wrote: >> >> >> >> What's wrong with native_read_msr()? >> > >> > Yes, i think i should

Linux kernel driver "r8169" for Realtek PCIE Gigabit network card is very unstable

Dear Linux kernel developers, Previously I have installed ipfire firewall appliance. The Linux kernel driver "e1000e" for Intel onboard Gigabit Network Card is very stable. I get consistently high download and high upload speeds. I used the onboard Intel Gigabit NIC for the WAN (RED) connection.

Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl

On Thu, Jan 11, 2018 at 7:01 PM, Raj, Ashok wrote: > On Thu, Jan 11, 2018 at 06:20:13PM -0800, Andy Lutomirski wrote: >> On Thu, Jan 11, 2018 at 5:52 PM, Raj, Ashok wrote: >> >> >> >> What's wrong with native_read_msr()? >> > >> > Yes, i think i should have added to msr.h. The names didn't read

Re: pci/setup-bus: Delete an error message for a failed memory allocation in add_to_list()

>> Omit an extra message for a memory allocation failure in this function. > > If this is an "extra" message, I assume there's some other message? > Can you mention where that is in the changelog? * Would you like to get a more detailed commit description? * Are you looking for a reminder on

Re: pci/setup-bus: Delete an error message for a failed memory allocation in add_to_list()

>> Omit an extra message for a memory allocation failure in this function. > > If this is an "extra" message, I assume there's some other message? > Can you mention where that is in the changelog? * Would you like to get a more detailed commit description? * Are you looking for a reminder on

Re: Yet another KPTI regression with 4.14.x series in a VM

On Fri, Jan 12, 2018 at 1:51 PM, Thomas Gleixner wrote: > On Fri, 12 Jan 2018, Laura Abbott wrote: > > Cc+ Andy > > I'm almost crashed out by now. Andy might have an idea. I'll look again > tomorrow with brain awake. > >> On 01/12/2018 10:51 AM, Thomas Gleixner wrote: >> > On

Re: Yet another KPTI regression with 4.14.x series in a VM

On Fri, Jan 12, 2018 at 1:51 PM, Thomas Gleixner wrote: > On Fri, 12 Jan 2018, Laura Abbott wrote: > > Cc+ Andy > > I'm almost crashed out by now. Andy might have an idea. I'll look again > tomorrow with brain awake. > >> On 01/12/2018 10:51 AM, Thomas Gleixner wrote: >> > On Fri, 12 Jan 2018,

Re: [PATCH] security/Kconfig: Replace pagetable-isolation.txt reference with pti.txt

On Fri, Jan 12, 2018 at 05:19:32PM -0800, Dave Hansen wrote: > On 01/12/2018 03:24 PM, W. Trevor King wrote: > >> If you're going to patch this, please send an update to -tip that > >> corrects the filename. > > > > Here you go :). > > Feel free to add my Acked-by. And please send to

Re: [PATCH] security/Kconfig: Replace pagetable-isolation.txt reference with pti.txt

On Fri, Jan 12, 2018 at 05:19:32PM -0800, Dave Hansen wrote: > On 01/12/2018 03:24 PM, W. Trevor King wrote: > >> If you're going to patch this, please send an update to -tip that > >> corrects the filename. > > > > Here you go :). > > Feel free to add my Acked-by. And please send to

[PATCH] staging: lustre: lmv: prefer kstrto to single variable sscanf

A kstrto should be preferred for a single variable instead of sscanf to convert string to the the required datatype. Issue reported by checkpatch.pl Signed-off-by: Sumit Pundir --- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 14 -- 1 file changed, 8

[PATCH] staging: lustre: lmv: prefer kstrto to single variable sscanf

A kstrto should be preferred for a single variable instead of sscanf to convert string to the the required datatype. Issue reported by checkpatch.pl Signed-off-by: Sumit Pundir --- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-)

Re: KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

On Sat, Jan 13, 2018 at 12:02:26PM +0800, Baoquan He wrote: >On 01/12/18 at 01:52pm, Luiz Capitulino wrote: >> On Fri, 12 Jan 2018 10:47:53 +0800 >> Chao Fan wrote: >> >> > On Fri, Jan 12, 2018 at 10:31:52AM +0800, Baoquan He wrote: >> > >On 01/11/18 at 10:04am, Kees

Re: KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

On Sat, Jan 13, 2018 at 12:02:26PM +0800, Baoquan He wrote: >On 01/12/18 at 01:52pm, Luiz Capitulino wrote: >> On Fri, 12 Jan 2018 10:47:53 +0800 >> Chao Fan wrote: >> >> > On Fri, Jan 12, 2018 at 10:31:52AM +0800, Baoquan He wrote: >> > >On 01/11/18 at 10:04am, Kees Cook wrote: >> > >> On

RE: Applied "ASoC: hdac_hdmi: Ensuring proper setting of output widget power state" to the asoc tree

> I've dropped this because it caused a conflict with the topic/hdac-hdmi > branch - can you please check what's going on there? I'm working on inputs from Takashi and Pierre. After much of testing I'll share the revision patch which waits until actual state reaches target state (similar is

RE: Applied "ASoC: hdac_hdmi: Ensuring proper setting of output widget power state" to the asoc tree

> I've dropped this because it caused a conflict with the topic/hdac-hdmi > branch - can you please check what's going on there? I'm working on inputs from Takashi and Pierre. After much of testing I'll share the revision patch which waits until actual state reaches target state (similar is

Re: [PATCH] bcache: btree.c: Fix GC thread exit in case of cache device failure and unregister

On Sat, 13 Jan 2018 12:06:26 +0800 Coly Li wrote: > On 12/01/2018 11:24 PM, Pavel Vazharov wrote: > > There was a possibility for infinite do-while loop inside the GC thread > > function in case of total failure of the caching device. I was able to > > reproduce it 3 times

Re: [PATCH] bcache: btree.c: Fix GC thread exit in case of cache device failure and unregister

On Sat, 13 Jan 2018 12:06:26 +0800 Coly Li wrote: > On 12/01/2018 11:24 PM, Pavel Vazharov wrote: > > There was a possibility for infinite do-while loop inside the GC thread > > function in case of total failure of the caching device. I was able to > > reproduce it 3 times simulating

Re: overlayfs non-persistent inodes

On Sat, Jan 13, 2018 at 2:19 AM, Niklas Cassel wrote: > Hello Miklos, Amir > > We are having some problems with inotify + overlayfs. > > If we start to monitor a directory on an overlayfs, > and get into a low memory situation, or if > /proc/sys/vm/drop_caches is called

Re: overlayfs non-persistent inodes

On Sat, Jan 13, 2018 at 2:19 AM, Niklas Cassel wrote: > Hello Miklos, Amir > > We are having some problems with inotify + overlayfs. > > If we start to monitor a directory on an overlayfs, > and get into a low memory situation, or if > /proc/sys/vm/drop_caches is called explicitly, > our inotify

Re: [PATCH v6 22/24] mm: Speculative page fault handler return VMA

On Fri, Jan 12, 2018 at 11:02:51AM -0800, Matthew Wilcox wrote: > On Fri, Jan 12, 2018 at 06:26:06PM +0100, Laurent Dufour wrote: > > @@ -1354,7 +1354,10 @@ extern int handle_mm_fault(struct vm_area_struct > > *vma, unsigned long address, > > unsigned int flags); > > #ifdef

Re: [PATCH v6 22/24] mm: Speculative page fault handler return VMA

On Fri, Jan 12, 2018 at 11:02:51AM -0800, Matthew Wilcox wrote: > On Fri, Jan 12, 2018 at 06:26:06PM +0100, Laurent Dufour wrote: > > @@ -1354,7 +1354,10 @@ extern int handle_mm_fault(struct vm_area_struct > > *vma, unsigned long address, > > unsigned int flags); > > #ifdef

Re: [PATCH] bcache: io.c: Fix check against error_limit in case of io errors

On Sat, 13 Jan 2018 11:40:54 +0800 Coly Li wrote: > On 12/01/2018 10:07 PM, Pavel Vazharov wrote: > > The actual sysfs io_error_limit value is left shifted IO_ERROR_SHIFT > > times before it is stored in the error_limit. > > This fixes the un-registering of the cache set when the

Re: [PATCH] bcache: io.c: Fix check against error_limit in case of io errors

On Sat, 13 Jan 2018 11:40:54 +0800 Coly Li wrote: > On 12/01/2018 10:07 PM, Pavel Vazharov wrote: > > The actual sysfs io_error_limit value is left shifted IO_ERROR_SHIFT > > times before it is stored in the error_limit. > > This fixes the un-registering of the cache set when the io_errors reach

Re: [PATCH] bcache: btree.c: Fix GC thread exit in case of cache device failure and unregister

On 12/01/2018 11:24 PM, Pavel Vazharov wrote: > There was a possibility for infinite do-while loop inside the GC thread > function in case of total failure of the caching device. I was able to > reproduce it 3 times simulating disappearing of the caching device via > 'echo 1 >

Re: [PATCH] bcache: btree.c: Fix GC thread exit in case of cache device failure and unregister

On 12/01/2018 11:24 PM, Pavel Vazharov wrote: > There was a possibility for infinite do-while loop inside the GC thread > function in case of total failure of the caching device. I was able to > reproduce it 3 times simulating disappearing of the caching device via > 'echo 1 >

Re: KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

On 01/12/18 at 01:52pm, Luiz Capitulino wrote: > On Fri, 12 Jan 2018 10:47:53 +0800 > Chao Fan wrote: > > > On Fri, Jan 12, 2018 at 10:31:52AM +0800, Baoquan He wrote: > > >On 01/11/18 at 10:04am, Kees Cook wrote: > > >> On Thu, Jan 11, 2018 at 1:00 AM, Baoquan He

Re: KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

On 01/12/18 at 01:52pm, Luiz Capitulino wrote: > On Fri, 12 Jan 2018 10:47:53 +0800 > Chao Fan wrote: > > > On Fri, Jan 12, 2018 at 10:31:52AM +0800, Baoquan He wrote: > > >On 01/11/18 at 10:04am, Kees Cook wrote: > > >> On Thu, Jan 11, 2018 at 1:00 AM, Baoquan He wrote: > > >> > Hi Luiz, >

Re: [PATCH] bcache: io.c: Fix check against error_limit in case of io errors

On 12/01/2018 10:07 PM, Pavel Vazharov wrote: > The actual sysfs io_error_limit value is left shifted IO_ERROR_SHIFT > times before it is stored in the error_limit. > This fixes the un-registering of the cache set when the io_errors reach > the error_limit value. > > Signed-off-by: Pavel Vazharov

Re: [PATCH] bcache: io.c: Fix check against error_limit in case of io errors

On 12/01/2018 10:07 PM, Pavel Vazharov wrote: > The actual sysfs io_error_limit value is left shifted IO_ERROR_SHIFT > times before it is stored in the error_limit. > This fixes the un-registering of the cache set when the io_errors reach > the error_limit value. > > Signed-off-by: Pavel Vazharov

Re: [PATCH] Input: trackpoint - force 3 buttons if 0 button is reported

Will your patch go to stable kernel? If yes, that's fine.

Re: [PATCH] Input: trackpoint - force 3 buttons if 0 button is reported

Will your patch go to stable kernel? If yes, that's fine.

[GIT PULL] apparmor fix for 4.15-rc8

Linus, can you please pull the following regression fixes for apparmor. It fixes a couple bugs I have been working with Matthew Garrett on this week. Specifically a regression in the handling of a conflicting profile attachment and label match restrictions for ptrace when profiles are stacked.

[GIT PULL] apparmor fix for 4.15-rc8

Linus, can you please pull the following regression fixes for apparmor. It fixes a couple bugs I have been working with Matthew Garrett on this week. Specifically a regression in the handling of a conflicting profile attachment and label match restrictions for ptrace when profiles are stacked.

Re: [PATCH v1] x86/retpoline: Use lfence in the retpoline/RSB filling RSB macros

On 1/12/2018 7:53 PM, Dan Williams wrote: > On Fri, Jan 12, 2018 at 5:07 PM, Tom Lendacky wrote: >> The pause instruction is currently used in the retpoline and RSB filling >> macros as a speculation trap. The use of pause was originally suggested >> because it showed a

Re: [PATCH v1] x86/retpoline: Use lfence in the retpoline/RSB filling RSB macros

On 1/12/2018 7:53 PM, Dan Williams wrote: > On Fri, Jan 12, 2018 at 5:07 PM, Tom Lendacky wrote: >> The pause instruction is currently used in the retpoline and RSB filling >> macros as a speculation trap. The use of pause was originally suggested >> because it showed a very, very small

Re: [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks

On 01/12/2018 03:21 AM, Sekhar Nori wrote: On Monday 08 January 2018 07:47 AM, David Lechner wrote: +static unsigned long davinci_pll_clk_recalc(struct clk_hw *hw, + unsigned long parent_rate) +{ + struct davinci_pll_clk *pll =

Re: [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks

On 01/12/2018 03:21 AM, Sekhar Nori wrote: On Monday 08 January 2018 07:47 AM, David Lechner wrote: +static unsigned long davinci_pll_clk_recalc(struct clk_hw *hw, + unsigned long parent_rate) +{ + struct davinci_pll_clk *pll =

Re: [PATCH v1] x86/retpoline: Use lfence in the retpoline/RSB filling RSB macros

On Fri, Jan 12, 2018 at 5:07 PM, Tom Lendacky wrote: > The pause instruction is currently used in the retpoline and RSB filling > macros as a speculation trap. The use of pause was originally suggested > because it showed a very, very small difference in the amount of >

Re: [PATCH v1] x86/retpoline: Use lfence in the retpoline/RSB filling RSB macros

On Fri, Jan 12, 2018 at 5:07 PM, Tom Lendacky wrote: > The pause instruction is currently used in the retpoline and RSB filling > macros as a speculation trap. The use of pause was originally suggested > because it showed a very, very small difference in the amount of > cycles/time used to

Re: [PATCH bpf-next v5 0/5] Separate error injection table from kprobes

On Sat, Jan 13, 2018 at 02:53:33AM +0900, Masami Hiramatsu wrote: > Hi, > > Here are the 5th version of patches to moving error injection > table from kprobes. This version fixes a bug and update > fail-function to support multiple function error injection. > > Here is the previous version: > >

Re: [PATCH bpf-next v5 0/5] Separate error injection table from kprobes

On Sat, Jan 13, 2018 at 02:53:33AM +0900, Masami Hiramatsu wrote: > Hi, > > Here are the 5th version of patches to moving error injection > table from kprobes. This version fixes a bug and update > fail-function to support multiple function error injection. > > Here is the previous version: > >

Re: [PATCH 8/8] KVM: x86: add SPEC_CTRL and IBPB_SUPPORT to MSR and CPUID lists

On Tue, 9 Jan 2018, Paolo Bonzini wrote: > Expose them to userspace, now that guests can use them. > I am not adding cpufeatures here to avoid having a kernel > that shows spec_ctrl in /proc/cpuinfo and actually has no > support whatsoever for IBRS/IBPB. Keep the ugly special-casing > for now,

Re: [PATCH 8/8] KVM: x86: add SPEC_CTRL and IBPB_SUPPORT to MSR and CPUID lists

On Tue, 9 Jan 2018, Paolo Bonzini wrote: > Expose them to userspace, now that guests can use them. > I am not adding cpufeatures here to avoid having a kernel > that shows spec_ctrl in /proc/cpuinfo and actually has no > support whatsoever for IBRS/IBPB. Keep the ugly special-casing > for now,

[PATCH v5] perf tools: Add ARM Statistical Profiling Extensions (SPE) support

'perf record' and 'perf report --dump-raw-trace' supported in this release. Example usage: # perf record -e arm_spe/ts_enable=1,pa_enable=1/ dd if=/dev/zero of=/dev/null count=1 # perf report --dump-raw-trace Note that the perf.data file is portable, so the report can be run on another

[PATCH v5] perf tools: Add ARM Statistical Profiling Extensions (SPE) support

'perf record' and 'perf report --dump-raw-trace' supported in this release. Example usage: # perf record -e arm_spe/ts_enable=1,pa_enable=1/ dd if=/dev/zero of=/dev/null count=1 # perf report --dump-raw-trace Note that the perf.data file is portable, so the report can be run on another

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On Friday, January 12, 2018 2:46:12 PM CET Ulf Hansson wrote: > On 12 January 2018 at 02:55, Rafael J. Wysocki wrote: > > On Tue, Jan 9, 2018 at 7:08 AM, Ulf Hansson wrote: > >> On 3 January 2018 at 12:06, Rafael J. Wysocki wrote: >

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On Friday, January 12, 2018 2:46:12 PM CET Ulf Hansson wrote: > On 12 January 2018 at 02:55, Rafael J. Wysocki wrote: > > On Tue, Jan 9, 2018 at 7:08 AM, Ulf Hansson wrote: > >> On 3 January 2018 at 12:06, Rafael J. Wysocki wrote: > >>> From: Rafael J. Wysocki > >>> > >>> One of the

Re: [PATCH] security/Kconfig: Replace pagetable-isolation.txt reference with pti.txt

On 01/12/2018 03:24 PM, W. Trevor King wrote: > The reference landed with the config option in 385ce0ea (x86/mm/pti: > Add Kconfig, 2017-12-04), but the referenced file was not committed > then. It eventually landed in 01c9b17b (x86/Documentation: Add PTI > description, 2018-01-05) as pti.txt. >

Re: [PATCH] security/Kconfig: Replace pagetable-isolation.txt reference with pti.txt

On 01/12/2018 03:24 PM, W. Trevor King wrote: > The reference landed with the config option in 385ce0ea (x86/mm/pti: > Add Kconfig, 2017-12-04), but the referenced file was not committed > then. It eventually landed in 01c9b17b (x86/Documentation: Add PTI > description, 2018-01-05) as pti.txt. >

Re: [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks

On 01/12/2018 10:18 AM, Sekhar Nori wrote: On Friday 12 January 2018 08:55 PM, David Lechner wrote: PLL output on DA850 must never be below 300MHz or above 600MHz (see datasheet table "Allowed PLL Operating Conditions"). Does this take care of that? Thats one of the main reasons I recall I

Re: [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks

On 01/12/2018 10:18 AM, Sekhar Nori wrote: On Friday 12 January 2018 08:55 PM, David Lechner wrote: PLL output on DA850 must never be below 300MHz or above 600MHz (see datasheet table "Allowed PLL Operating Conditions"). Does this take care of that? Thats one of the main reasons I recall I

[PATCH v1] x86/retpoline: Use lfence in the retpoline/RSB filling RSB macros

The pause instruction is currently used in the retpoline and RSB filling macros as a speculation trap. The use of pause was originally suggested because it showed a very, very small difference in the amount of cycles/time used to execute the retpoline as compared to lfence. On AMD, the pause

[PATCH v1] x86/retpoline: Use lfence in the retpoline/RSB filling RSB macros

The pause instruction is currently used in the retpoline and RSB filling macros as a speculation trap. The use of pause was originally suggested because it showed a very, very small difference in the amount of cycles/time used to execute the retpoline as compared to lfence. On AMD, the pause

[PATCH v6 01/12] drivers: base: cacheinfo: move cache_setup_of_node()

In preparation for the next patch, and to aid in review of that patch, lets move cache_setup_of_node farther down in the module without any changes. Signed-off-by: Jeremy Linton --- drivers/base/cacheinfo.c | 80 1 file

[PATCH v6 01/12] drivers: base: cacheinfo: move cache_setup_of_node()

In preparation for the next patch, and to aid in review of that patch, lets move cache_setup_of_node farther down in the module without any changes. Signed-off-by: Jeremy Linton --- drivers/base/cacheinfo.c | 80 1 file changed, 40 insertions(+),

[PATCH v6 03/12] cacheinfo: rename of_node to fw_unique

Rename and change the type of of_node to indicate it is a generic pointer which is generally only used for comparison purposes. In a later patch we will apply an ACPI/PPTT "token" pointer in fw_unique so that the code which builds the shared cpu masks can be reused. Cc: Palmer Dabbelt

[PATCH v6 03/12] cacheinfo: rename of_node to fw_unique

Rename and change the type of of_node to indicate it is a generic pointer which is generally only used for comparison purposes. In a later patch we will apply an ACPI/PPTT "token" pointer in fw_unique so that the code which builds the shared cpu masks can be reused. Cc: Palmer Dabbelt Cc: Albert

[PATCH v6 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing

ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the properties of the caches in relation to other caches and processing units. Add the code to parse the cache hierarchy and

[PATCH v6 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing

ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the properties of the caches in relation to other caches and processing units. Add the code to parse the cache hierarchy and

[PATCH v6 06/12] ACPI: Enable PPTT support on ARM64

Now that we have a PPTT parser, in preparation for its use on arm64, lets build it. Signed-off-by: Jeremy Linton --- arch/arm64/Kconfig| 1 + drivers/acpi/Kconfig | 3 +++ drivers/acpi/Makefile | 1 + 3 files changed, 5 insertions(+) diff --git a/arch/arm64/Kconfig

[PATCH v6 06/12] ACPI: Enable PPTT support on ARM64

Now that we have a PPTT parser, in preparation for its use on arm64, lets build it. Signed-off-by: Jeremy Linton --- arch/arm64/Kconfig| 1 + drivers/acpi/Kconfig | 3 +++ drivers/acpi/Makefile | 1 + 3 files changed, 5 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig

[PATCH v6 04/12] arm64/acpi: Create arch specific cpu to acpi id helper

Its helpful to be able to lookup the acpi_processor_id associated with a logical cpu. Provide an arm64 helper to do this. Signed-off-by: Jeremy Linton --- arch/arm64/include/asm/acpi.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/include/asm/acpi.h

[PATCH v6 04/12] arm64/acpi: Create arch specific cpu to acpi id helper

Its helpful to be able to lookup the acpi_processor_id associated with a logical cpu. Provide an arm64 helper to do this. Signed-off-by: Jeremy Linton --- arch/arm64/include/asm/acpi.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/include/asm/acpi.h

[PATCH v6 07/12] drivers: base cacheinfo: Add support for ACPI based firmware tables

Add a entry to to struct cacheinfo to maintain a reference to the PPTT node which can be used to match identical caches across cores. Also stub out cache_setup_acpi() so that individual architectures can enable ACPI topology parsing. Signed-off-by: Jeremy Linton ---

[PATCH v6 07/12] drivers: base cacheinfo: Add support for ACPI based firmware tables

Add a entry to to struct cacheinfo to maintain a reference to the PPTT node which can be used to match identical caches across cores. Also stub out cache_setup_acpi() so that individual architectures can enable ACPI topology parsing. Signed-off-by: Jeremy Linton --- drivers/acpi/pptt.c |

[PATCH v6 08/12] arm64: Add support for ACPI based firmware tables

The /sys cache entries should support ACPI/PPTT generated cache topology information. Lets detect ACPI systems and call an arch specific cache_setup_acpi() routine to update the hardware probed cache topology. For arm64, if ACPI is enabled, determine the max number of cache levels and populate

[PATCH v6 10/12] arm64: topology: rename cluster_id

Lets match the name of the arm64 topology field to the kernel macro that uses it. Cc: Vincent Guittot Cc: Dietmar Eggemann Cc: Juri Lelli Signed-off-by: Jeremy Linton ---

[PATCH v6 09/12] ACPI/PPTT: Add topology parsing code

The PPTT can be used to determine the groupings of CPU's at given levels in the system. Lets add a few routines to the PPTT parsing code to return a unique id for each unique level in the processor hierarchy. This can then be matched to build thread/core/cluster/die/package/etc mappings for each

[PATCH v6 10/12] arm64: topology: rename cluster_id

Lets match the name of the arm64 topology field to the kernel macro that uses it. Cc: Vincent Guittot Cc: Dietmar Eggemann Cc: Juri Lelli Signed-off-by: Jeremy Linton --- arch/arm64/include/asm/topology.h | 4 ++-- arch/arm64/kernel/topology.c | 27 ++- 2 files

[PATCH v6 08/12] arm64: Add support for ACPI based firmware tables

The /sys cache entries should support ACPI/PPTT generated cache topology information. Lets detect ACPI systems and call an arch specific cache_setup_acpi() routine to update the hardware probed cache topology. For arm64, if ACPI is enabled, determine the max number of cache levels and populate

[PATCH v6 09/12] ACPI/PPTT: Add topology parsing code

The PPTT can be used to determine the groupings of CPU's at given levels in the system. Lets add a few routines to the PPTT parsing code to return a unique id for each unique level in the processor hierarchy. This can then be matched to build thread/core/cluster/die/package/etc mappings for each

  1   2   3   4   5   6   7   8   9   10   >