Re: [PATCH 1/1] gianfar: fix a flooded alignment reports because of padding issue.

On 12/05/2017 12:06 AM, Claudiu Manoil wrote: -Original Message- From: Zumeng Chen [mailto:zumeng.c...@gmail.com] Sent: Monday, December 04, 2017 5:22 AM To: net...@vger.kernel.org; linux-kernel@vger.kernel.org Cc: Claudiu Manoil ; da...@davemloft.net Subject:

Re: [PATCH 1/1] gianfar: fix a flooded alignment reports because of padding issue.

On 12/05/2017 12:06 AM, Claudiu Manoil wrote: -Original Message- From: Zumeng Chen [mailto:zumeng.c...@gmail.com] Sent: Monday, December 04, 2017 5:22 AM To: net...@vger.kernel.org; linux-kernel@vger.kernel.org Cc: Claudiu Manoil ; da...@davemloft.net Subject: [PATCH 1/1] gianfar: fix a

Re: [PATCH net-next V3] tun: add eBPF based queue selection method

On Mon, Dec 4, 2017 at 4:31 AM, Jason Wang wrote: > This patch introduces an eBPF based queue selection method. With this, > the policy could be offloaded to userspace completely through a new > ioctl TUNSETSTEERINGEBPF. > > Signed-off-by: Jason Wang >

Re: [PATCH net-next V3] tun: add eBPF based queue selection method

On Mon, Dec 4, 2017 at 4:31 AM, Jason Wang wrote: > This patch introduces an eBPF based queue selection method. With this, > the policy could be offloaded to userspace completely through a new > ioctl TUNSETSTEERINGEBPF. > > Signed-off-by: Jason Wang > --- > +static u16

Re: [PATCH v3 0/3] perf tools: perf tools: Clarify overwrite and backward, bugfix

On Mon, Dec 04, 2017 at 04:51:04PM +, Wang Nan wrote: > Simplify patch 1/3 following Namhyung's suggestion. > > Context adjustment for patch 2 and 3. > > Wang Nan (3): > perf mmap: Fix perf backward recording > perf tools: Don't discard prev in backward mode > perf tools: Replace

Re: [PATCH v3 0/3] perf tools: perf tools: Clarify overwrite and backward, bugfix

On Mon, Dec 04, 2017 at 04:51:04PM +, Wang Nan wrote: > Simplify patch 1/3 following Namhyung's suggestion. > > Context adjustment for patch 2 and 3. > > Wang Nan (3): > perf mmap: Fix perf backward recording > perf tools: Don't discard prev in backward mode > perf tools: Replace

Re: [PATCH v2 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER)

On 11/30/2017 08:39 AM, Will Deacon wrote: Hi again, This is version two of the patches previously posted here: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/542751.html Changes since v1 include: * Based on v4.15-rc1 * Trampoline moved into FIXMAP area *

Re: [PATCH v2 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER)

On 11/30/2017 08:39 AM, Will Deacon wrote: Hi again, This is version two of the patches previously posted here: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/542751.html Changes since v1 include: * Based on v4.15-rc1 * Trampoline moved into FIXMAP area *

Re: Regression in e1000e since Kernel 4.14.3

On 04.12.2017 23:10, rwar...@gmx.de wrote: Hallo someone and I got an regression with e1000e since kernel 4.14.3 and it seems there is 4.14.4 on the way without a fix. bug report is here: https://bugzilla.kernel.org/show_bug.cgi?id=198047 ( added stable and netdev to CC ) Yes I have a

Re: Regression in e1000e since Kernel 4.14.3

On 04.12.2017 23:10, rwar...@gmx.de wrote: Hallo someone and I got an regression with e1000e since kernel 4.14.3 and it seems there is 4.14.4 on the way without a fix. bug report is here: https://bugzilla.kernel.org/show_bug.cgi?id=198047 ( added stable and netdev to CC ) Yes I have a

Re: [PATCH 4.14 00/95] 4.14.4-stable review

On Mon, Dec 04, 2017 at 04:59:24PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.4 release. > There are 95 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.14 00/95] 4.14.4-stable review

On Mon, Dec 04, 2017 at 04:59:24PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.4 release. > There are 95 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.9 00/38] 4.9.67-stable review

On Mon, Dec 04, 2017 at 04:59:40PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.67 release. > There are 38 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.9 00/38] 4.9.67-stable review

On Mon, Dec 04, 2017 at 04:59:40PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.67 release. > There are 38 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.4 00/27] 4.4.104-stable review

On Mon, Dec 04, 2017 at 04:59:25PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.104 release. > There are 27 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.4 00/27] 4.4.104-stable review

On Mon, Dec 04, 2017 at 04:59:25PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.104 release. > There are 27 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 3.18 00/12] 3.18.86-stable review

On Mon, Dec 04, 2017 at 04:59:14PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.86 release. > There are 12 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 3.18 00/12] 3.18.86-stable review

On Mon, Dec 04, 2017 at 04:59:14PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.86 release. > There are 12 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH] doc: update 'unique identifiers'

On Mon, Dec 04, 2017 at 01:51:42PM -0800, Kees Cook wrote: > On Mon, Dec 4, 2017 at 1:44 PM, Tobin C. Harding wrote: > > On Mon, Dec 04, 2017 at 01:28:45PM -0800, Kees Cook wrote: > >> On Mon, Dec 4, 2017 at 1:22 PM, Tobin C. Harding wrote: > >> > Advice about what

Re: [PATCH] doc: update 'unique identifiers'

On Mon, Dec 04, 2017 at 01:51:42PM -0800, Kees Cook wrote: > On Mon, Dec 4, 2017 at 1:44 PM, Tobin C. Harding wrote: > > On Mon, Dec 04, 2017 at 01:28:45PM -0800, Kees Cook wrote: > >> On Mon, Dec 4, 2017 at 1:22 PM, Tobin C. Harding wrote: > >> > Advice about what to use as a unique identifier

running leaking_addresses.pl

Hi, Recently scripts/leaking_addresses.pl was merged into the mainline with the hope of catching leaking kernel addresses. Would it be in scope for this script to be run by the kbuild test robot? Excuse my very little knowledge of the kbuild test robot but would this lead to the script being run

running leaking_addresses.pl

Hi, Recently scripts/leaking_addresses.pl was merged into the mainline with the hope of catching leaking kernel addresses. Would it be in scope for this script to be run by the kbuild test robot? Excuse my very little knowledge of the kbuild test robot but would this lead to the script being run

Re: [PATCH v2] ima: log message to module appraisal error

On Mon, 2017-12-04 at 18:23 -0200, Bruno E. O. Meneguele wrote: > Simple but useful message log to the user in case of module appraise is > forced and fails due to the lack of file descriptor, that might be > caused by kmod calls to compressed modules. [] > diff --git

Re: [PATCH v2] ima: log message to module appraisal error

On Mon, 2017-12-04 at 18:23 -0200, Bruno E. O. Meneguele wrote: > Simple but useful message log to the user in case of module appraise is > forced and fails due to the lack of file descriptor, that might be > caused by kmod calls to compressed modules. [] > diff --git

Re: [linux-sunxi] [PATCH 0/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks

On 04/12/17 05:19, Chen-Yu Tsai wrote: > Hi, > > This is a small fix to get MMC performance up to proper speeds on the Maybe a small fix for a skilled developer, but a giant leap for all users ;-) MMC performance goes from: (4.15-rc1) SD: Timing buffered disk reads: 36 MB in 3.17 seconds =

Re: [linux-sunxi] [PATCH 0/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks

On 04/12/17 05:19, Chen-Yu Tsai wrote: > Hi, > > This is a small fix to get MMC performance up to proper speeds on the Maybe a small fix for a skilled developer, but a giant leap for all users ;-) MMC performance goes from: (4.15-rc1) SD: Timing buffered disk reads: 36 MB in 3.17 seconds =

Re: [linux-sunxi] [PATCH 2/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks

On 04/12/17 05:19, Chen-Yu Tsai wrote: > On the A64, the MMC module clocks are fixed in the new timing mode, > i.e. they do not have a bit to select the mode. These clocks have > a 2x divider somewhere between the clock and the MMC module. > > To be consistent with other SoCs supporting the new

Re: [linux-sunxi] [PATCH 2/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks

On 04/12/17 05:19, Chen-Yu Tsai wrote: > On the A64, the MMC module clocks are fixed in the new timing mode, > i.e. they do not have a bit to select the mode. These clocks have > a 2x divider somewhere between the clock and the MMC module. > > To be consistent with other SoCs supporting the new

Re: [patch 27/60] x86/cpufeatures: Add X86_BUG_CPU_INSECURE

On Mon, Dec 04, 2017 at 03:07:33PM +0100, Thomas Gleixner wrote: > From: Thomas Gleixner > > Many x86 CPUs leak information to user space due to missing isolation of > user space and kernel space page tables. There are many well documented > ways to exploit that. > > The

Re: [linux-sunxi] [PATCH 1/2] clk: sunxi-ng: Support fixed post-dividers on MP style clocks

Hi Chen-Yu, On 04/12/17 05:19, Chen-Yu Tsai wrote: > On the A64, the MMC module clocks are fixed in the new timing mode, > i.e. they do not have a bit to select the mode. These clocks have > a 2x divider somewhere between the clock and the MMC module. > > To be consistent with other SoCs

Re: [patch 27/60] x86/cpufeatures: Add X86_BUG_CPU_INSECURE

On Mon, Dec 04, 2017 at 03:07:33PM +0100, Thomas Gleixner wrote: > From: Thomas Gleixner > > Many x86 CPUs leak information to user space due to missing isolation of > user space and kernel space page tables. There are many well documented > ways to exploit that. > > The upcoming software

Re: [linux-sunxi] [PATCH 1/2] clk: sunxi-ng: Support fixed post-dividers on MP style clocks

Hi Chen-Yu, On 04/12/17 05:19, Chen-Yu Tsai wrote: > On the A64, the MMC module clocks are fixed in the new timing mode, > i.e. they do not have a bit to select the mode. These clocks have > a 2x divider somewhere between the clock and the MMC module. > > To be consistent with other SoCs

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On 05.12.2017 01:59, Jeff Moyer wrote: > Kirill Tkhai writes: > >> On 05.12.2017 00:52, Tejun Heo wrote: >>> Hello, Kirill. >>> >>> On Tue, Dec 05, 2017 at 12:44:00AM +0300, Kirill Tkhai wrote: > Can you please explain how this is a fundamental resource which can't

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On 05.12.2017 01:59, Jeff Moyer wrote: > Kirill Tkhai writes: > >> On 05.12.2017 00:52, Tejun Heo wrote: >>> Hello, Kirill. >>> >>> On Tue, Dec 05, 2017 at 12:44:00AM +0300, Kirill Tkhai wrote: > Can you please explain how this is a fundamental resource which can't > be controlled

[PATCH 1/2] dm-unstripe: unstripe of IO across RAID 0

This device mapper module remaps and unstripes IO so it lands solely on a single drive in a RAID 0. In a 4 drive RAID 0 the mapper exposes 1/4th of the LBA range as a virtual drive. Each IO to that virtual drive will land on only one of the 4 drives, selected by the user. As an example: Intel

[PATCH 2/2] dm unstripe: Add documentation for unstripe target

Signed-off-by: Scott Bauer --- Documentation/device-mapper/dm-unstripe.txt | 82 + 1 file changed, 82 insertions(+) create mode 100644 Documentation/device-mapper/dm-unstripe.txt diff --git a/Documentation/device-mapper/dm-unstripe.txt

[PATCH 2/2] dm unstripe: Add documentation for unstripe target

Signed-off-by: Scott Bauer --- Documentation/device-mapper/dm-unstripe.txt | 82 + 1 file changed, 82 insertions(+) create mode 100644 Documentation/device-mapper/dm-unstripe.txt diff --git a/Documentation/device-mapper/dm-unstripe.txt

[PATCH 1/2] dm-unstripe: unstripe of IO across RAID 0

This device mapper module remaps and unstripes IO so it lands solely on a single drive in a RAID 0. In a 4 drive RAID 0 the mapper exposes 1/4th of the LBA range as a virtual drive. Each IO to that virtual drive will land on only one of the 4 drives, selected by the user. As an example: Intel

Re: [patch 51/60] x86/mm: Allow flushing for future ASID switches

On Mon, Dec 04, 2017 at 02:54:46PM -0800, Andy Lutomirski wrote: > On Mon, Dec 4, 2017 at 2:47 PM, Peter Zijlstra wrote: > > As is __flush_tlb_single() does user and __flush_tlb_one() does > > user+kernel. > > Yep. A one-liner above the function to that effect would make

Re: [patch 51/60] x86/mm: Allow flushing for future ASID switches

On Mon, Dec 04, 2017 at 02:54:46PM -0800, Andy Lutomirski wrote: > On Mon, Dec 4, 2017 at 2:47 PM, Peter Zijlstra wrote: > > As is __flush_tlb_single() does user and __flush_tlb_one() does > > user+kernel. > > Yep. A one-liner above the function to that effect would make it > *way* clearer

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On 05.12.2017 02:02, Tejun Heo wrote: > Hello, Kirill. > > On Tue, Dec 05, 2017 at 01:49:42AM +0300, Kirill Tkhai wrote: >>> If the only reason is kernel memory consumption protection, the only >>> thing we need to do is making sure that memory used for aio commands >>> are accounted against

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On 05.12.2017 02:02, Tejun Heo wrote: > Hello, Kirill. > > On Tue, Dec 05, 2017 at 01:49:42AM +0300, Kirill Tkhai wrote: >>> If the only reason is kernel memory consumption protection, the only >>> thing we need to do is making sure that memory used for aio commands >>> are accounted against

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Hello, Kirill. On Tue, Dec 05, 2017 at 01:49:42AM +0300, Kirill Tkhai wrote: > > If the only reason is kernel memory consumption protection, the only > > thing we need to do is making sure that memory used for aio commands > > are accounted against cgroup kernel memory consumption and > >

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Hello, Kirill. On Tue, Dec 05, 2017 at 01:49:42AM +0300, Kirill Tkhai wrote: > > If the only reason is kernel memory consumption protection, the only > > thing we need to do is making sure that memory used for aio commands > > are accounted against cgroup kernel memory consumption and > >

Re: [PATCH] cgroup/cpuset: fix circular locking dependency

On Mon, Dec 04, 2017 at 02:58:25PM -0800, Tejun Heo wrote: > Hello, again. > > On Mon, Dec 04, 2017 at 12:22:19PM -0800, Tejun Heo wrote: > > Hello, > > > > On Mon, Dec 04, 2017 at 10:44:49AM +0530, Prateek Sood wrote: > > > Any feedback/suggestion for this patch? > > > > Sorry about the delay.

Re: [PATCH] cgroup/cpuset: fix circular locking dependency

On Mon, Dec 04, 2017 at 02:58:25PM -0800, Tejun Heo wrote: > Hello, again. > > On Mon, Dec 04, 2017 at 12:22:19PM -0800, Tejun Heo wrote: > > Hello, > > > > On Mon, Dec 04, 2017 at 10:44:49AM +0530, Prateek Sood wrote: > > > Any feedback/suggestion for this patch? > > > > Sorry about the delay.

Re: [PATCH v2 4/8] clocksource: owl: Prepare S700

Hi Daniel, Am 14.11.2017 um 00:34 schrieb Andreas Färber: > Actions S700 has two 2Hz timers like S500, and four TIMx timers like S900. > > Signed-off-by: Andreas Färber > --- > v1 -> v2: > * Adopted TIMER_OF_DECLARE() (Daniel) > > drivers/clocksource/owl-timer.c | 1 + >

Re: [PATCH v2 4/8] clocksource: owl: Prepare S700

Hi Daniel, Am 14.11.2017 um 00:34 schrieb Andreas Färber: > Actions S700 has two 2Hz timers like S500, and four TIMx timers like S900. > > Signed-off-by: Andreas Färber > --- > v1 -> v2: > * Adopted TIMER_OF_DECLARE() (Daniel) > > drivers/clocksource/owl-timer.c | 1 + > 1 file changed, 1

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Kirill Tkhai writes: > On 05.12.2017 00:52, Tejun Heo wrote: >> Hello, Kirill. >> >> On Tue, Dec 05, 2017 at 12:44:00AM +0300, Kirill Tkhai wrote: Can you please explain how this is a fundamental resource which can't be controlled otherwise? >>> >>> Currently,

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Kirill Tkhai writes: > On 05.12.2017 00:52, Tejun Heo wrote: >> Hello, Kirill. >> >> On Tue, Dec 05, 2017 at 12:44:00AM +0300, Kirill Tkhai wrote: Can you please explain how this is a fundamental resource which can't be controlled otherwise? >>> >>> Currently, aio_nr and aio_max_nr

linux-next: manual merge of the net-next tree with Linus' tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/can/flexcan.c between commit: 29c64b17a0bc ("can: flexcan: fix VF610 state transition issue") from Linus' tree and commit: 99b7668c04b2 ("can: flexcan: adding platform specific details for LS1021A")

linux-next: manual merge of the net-next tree with Linus' tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/can/flexcan.c between commit: 29c64b17a0bc ("can: flexcan: fix VF610 state transition issue") from Linus' tree and commit: 99b7668c04b2 ("can: flexcan: adding platform specific details for LS1021A")

Re: [PATCH] cgroup/cpuset: fix circular locking dependency

Hello, again. On Mon, Dec 04, 2017 at 12:22:19PM -0800, Tejun Heo wrote: > Hello, > > On Mon, Dec 04, 2017 at 10:44:49AM +0530, Prateek Sood wrote: > > Any feedback/suggestion for this patch? > > Sorry about the delay. I'm a bit worried because it feels like we're > chasing a squirrel. I'll

Re: [PATCH] cgroup/cpuset: fix circular locking dependency

Hello, again. On Mon, Dec 04, 2017 at 12:22:19PM -0800, Tejun Heo wrote: > Hello, > > On Mon, Dec 04, 2017 at 10:44:49AM +0530, Prateek Sood wrote: > > Any feedback/suggestion for this patch? > > Sorry about the delay. I'm a bit worried because it feels like we're > chasing a squirrel. I'll

Re: [PATCH] rtlwifi: rtl818x: remove redundant check for cck_power > 15

On Tue, 14/11/17, Colin King wrote: > From: Colin Ian King > cck_poweri cannot be greated than 15 as > is derived from the bottom 4 bits > from riv->channels[channel - > 1].hw_value & 0xf. 

Re: [PATCH tip/core/rcu 01/21] doc: READ_ONCE() now implies smp_barrier_depends()

On Mon, Dec 04, 2017 at 10:39:05PM +, David Howells wrote: > Peter Zijlstra wrote: > > > > Good point! How about as shown in the updated patch below? > > > > Humm, I thought the idea was to completely remove read_barrier_depends > > from the lkmm and

Re: [PATCH] rtlwifi: rtl818x: remove redundant check for cck_power > 15

On Tue, 14/11/17, Colin King wrote: > From: Colin Ian King > cck_poweri cannot be greated than 15 as > is derived from the bottom 4 bits > from riv->channels[channel - > 1].hw_value & 0xf.  Hence the check for it > being greater than 15 is

Re: [PATCH tip/core/rcu 01/21] doc: READ_ONCE() now implies smp_barrier_depends()

On Mon, Dec 04, 2017 at 10:39:05PM +, David Howells wrote: > Peter Zijlstra wrote: > > > > Good point! How about as shown in the updated patch below? > > > > Humm, I thought the idea was to completely remove read_barrier_depends > > from the lkmm and memory-barriers.txt, making it an Alpha

Re: [patch 51/60] x86/mm: Allow flushing for future ASID switches

On Mon, Dec 4, 2017 at 2:47 PM, Peter Zijlstra wrote: > On Mon, Dec 04, 2017 at 02:22:54PM -0800, Andy Lutomirski wrote: > >> > +static inline void invalidate_pcid_other(void) >> > +{ >> > + /* >> > +* With global pages, all of the shared kenel page tables >> >

Re: [patch 51/60] x86/mm: Allow flushing for future ASID switches

On Mon, Dec 4, 2017 at 2:47 PM, Peter Zijlstra wrote: > On Mon, Dec 04, 2017 at 02:22:54PM -0800, Andy Lutomirski wrote: > >> > +static inline void invalidate_pcid_other(void) >> > +{ >> > + /* >> > +* With global pages, all of the shared kenel page tables >> > +* are set as

Re: [patch 55/60] x86/mm: Use INVPCID for __native_flush_tlb_single()

On Mon, Dec 04, 2017 at 02:25:43PM -0800, Andy Lutomirski wrote: > On Mon, Dec 4, 2017 at 6:08 AM, Thomas Gleixner wrote: > > From: Dave Hansen > > > > This uses INVPCID to shoot down individual lines of the user mapping > > instead of marking the

Re: [patch 55/60] x86/mm: Use INVPCID for __native_flush_tlb_single()

On Mon, Dec 04, 2017 at 02:25:43PM -0800, Andy Lutomirski wrote: > On Mon, Dec 4, 2017 at 6:08 AM, Thomas Gleixner wrote: > > From: Dave Hansen > > > > This uses INVPCID to shoot down individual lines of the user mapping > > instead of marking the entire user map as invalid. This > >

Re: [patch 00/60] x86/kpti: Kernel Page Table Isolation (was KAISER)

On 12/04/2017 01:18 PM, Thomas Gleixner wrote: > On Mon, 4 Dec 2017, Linus Torvalds wrote: >> On Mon, Dec 4, 2017 at 6:07 AM, Thomas Gleixner wrote: >>> Kernel Page Table Isolation, prefix kpti_ >>> >>>Linus, your call :) >> I think you probably chose the right name

Re: [patch 00/60] x86/kpti: Kernel Page Table Isolation (was KAISER)

On 12/04/2017 01:18 PM, Thomas Gleixner wrote: > On Mon, 4 Dec 2017, Linus Torvalds wrote: >> On Mon, Dec 4, 2017 at 6:07 AM, Thomas Gleixner wrote: >>> Kernel Page Table Isolation, prefix kpti_ >>> >>>Linus, your call :) >> I think you probably chose the right name here. The alternatives

Re: [patch 47/60] x86/ldt: Map LDT entries into fixmap

On Mon, 4 Dec 2017, Andy Lutomirski wrote: > On Mon, Dec 4, 2017 at 6:07 AM, Thomas Gleixner wrote: > > From: Thomas Gleixner > > > > LDT is not really commonly used on 64bit so the overhead of populating the > > fixmap entries on context switch for the

Re: [patch 47/60] x86/ldt: Map LDT entries into fixmap

On Mon, 4 Dec 2017, Andy Lutomirski wrote: > On Mon, Dec 4, 2017 at 6:07 AM, Thomas Gleixner wrote: > > From: Thomas Gleixner > > > > LDT is not really commonly used on 64bit so the overhead of populating the > > fixmap entries on context switch for the rare LDT syscall users is a > >

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

On Tue, 2017-12-05 at 06:45 +0800, Ming Lei wrote: > On Mon, Dec 04, 2017 at 03:09:20PM +, Bart Van Assche wrote: > > On Sun, 2017-12-03 at 00:31 +0800, Ming Lei wrote: > > > Fixes: 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for > > > blk-mq") > > > > It might be safer to

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

On Tue, 2017-12-05 at 06:45 +0800, Ming Lei wrote: > On Mon, Dec 04, 2017 at 03:09:20PM +, Bart Van Assche wrote: > > On Sun, 2017-12-03 at 00:31 +0800, Ming Lei wrote: > > > Fixes: 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for > > > blk-mq") > > > > It might be safer to

[tip:x86/urgent] x86/power: Fix some ordering bugs in __restore_processor_context()

Commit-ID: cdf577209aad4cdbe3455d3efa6cf631f838c55d Gitweb: https://git.kernel.org/tip/cdf577209aad4cdbe3455d3efa6cf631f838c55d Author: Andy Lutomirski AuthorDate: Thu, 30 Nov 2017 07:57:57 -0800 Committer: Thomas Gleixner CommitDate: Mon, 4 Dec

[tip:x86/urgent] x86/power: Fix some ordering bugs in __restore_processor_context()

Commit-ID: cdf577209aad4cdbe3455d3efa6cf631f838c55d Gitweb: https://git.kernel.org/tip/cdf577209aad4cdbe3455d3efa6cf631f838c55d Author: Andy Lutomirski AuthorDate: Thu, 30 Nov 2017 07:57:57 -0800 Committer: Thomas Gleixner CommitDate: Mon, 4 Dec 2017 23:41:42 +0100 x86/power: Fix some

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On 05.12.2017 00:52, Tejun Heo wrote: > Hello, Kirill. > > On Tue, Dec 05, 2017 at 12:44:00AM +0300, Kirill Tkhai wrote: >>> Can you please explain how this is a fundamental resource which can't >>> be controlled otherwise? >> >> Currently, aio_nr and aio_max_nr are global. In case of containers

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On 05.12.2017 00:52, Tejun Heo wrote: > Hello, Kirill. > > On Tue, Dec 05, 2017 at 12:44:00AM +0300, Kirill Tkhai wrote: >>> Can you please explain how this is a fundamental resource which can't >>> be controlled otherwise? >> >> Currently, aio_nr and aio_max_nr are global. In case of containers

Re: [patch 51/60] x86/mm: Allow flushing for future ASID switches

On Mon, Dec 04, 2017 at 02:22:54PM -0800, Andy Lutomirski wrote: > > +static inline void invalidate_pcid_other(void) > > +{ > > + /* > > +* With global pages, all of the shared kenel page tables > > +* are set as _PAGE_GLOBAL. We have no shared nonglobals > > +* and

Re: [patch 51/60] x86/mm: Allow flushing for future ASID switches

On Mon, Dec 04, 2017 at 02:22:54PM -0800, Andy Lutomirski wrote: > > +static inline void invalidate_pcid_other(void) > > +{ > > + /* > > +* With global pages, all of the shared kenel page tables > > +* are set as _PAGE_GLOBAL. We have no shared nonglobals > > +* and

Re: boot failure in 4.15-rc2 with afs in the trace

Christoph Hellwig wrote: > [1.501264] BUG: unable to handle kernel NULL pointer dereference at > 6714cfcb > [1.502335] IP: rxrpc_release+0xd5/0x1c0 Is it fixed by current Linus? In particular commit c501256406fb19c306504ee1fe41a4ea208d4245: rxrpc:

Re: boot failure in 4.15-rc2 with afs in the trace

Christoph Hellwig wrote: > [1.501264] BUG: unable to handle kernel NULL pointer dereference at > 6714cfcb > [1.502335] IP: rxrpc_release+0xd5/0x1c0 Is it fixed by current Linus? In particular commit c501256406fb19c306504ee1fe41a4ea208d4245: rxrpc: Use correct netns

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

On Mon, Dec 04, 2017 at 03:09:20PM +, Bart Van Assche wrote: > On Sun, 2017-12-03 at 00:31 +0800, Ming Lei wrote: > > Fixes: 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for > > blk-mq") > > It might be safer to revert commit 0df21c86bdbf instead of trying to fix all > issues

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

On Mon, Dec 04, 2017 at 03:09:20PM +, Bart Van Assche wrote: > On Sun, 2017-12-03 at 00:31 +0800, Ming Lei wrote: > > Fixes: 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for > > blk-mq") > > It might be safer to revert commit 0df21c86bdbf instead of trying to fix all > issues

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

On Monday, December 4, 2017 11:38:54 PM CET Thomas Gleixner wrote: > On Mon, 4 Dec 2017, Linus Torvalds wrote: > > > On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki > > wrote: > > > > > > So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the > > > systems I

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

On Monday, December 4, 2017 11:38:54 PM CET Thomas Gleixner wrote: > On Mon, 4 Dec 2017, Linus Torvalds wrote: > > > On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki > > wrote: > > > > > > So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the > > > systems I have tested, so it

Re: maxcpus confusion

On 12/04/2017 01:02 PM, Heiko Carstens wrote: > On Fri, Dec 01, 2017 at 12:58:47PM -0800, Randy Dunlap wrote: >> Hi, >> >> I used "maxcpus=1" on a recent x86 boot (4.15-rc1) and got 4 CPUs (all of >> them AFAICT). When I use "nr_cpus=1", I do get a hard limit of one CPU. >> >> >> A few boot log

Re: maxcpus confusion

On 12/04/2017 01:02 PM, Heiko Carstens wrote: > On Fri, Dec 01, 2017 at 12:58:47PM -0800, Randy Dunlap wrote: >> Hi, >> >> I used "maxcpus=1" on a recent x86 boot (4.15-rc1) and got 4 CPUs (all of >> them AFAICT). When I use "nr_cpus=1", I do get a hard limit of one CPU. >> >> >> A few boot log

Re: [patch 26/60] x86/cpufeature: Make cpu bugs sticky

On Mon, Dec 04, 2017 at 03:07:32PM +0100, Thomas Gleixner wrote: > From: Thomas Gleixner > > There is currently no way to force CPU bug bits like CPU feature bits. That > makes it impossible to set a bug bit once at boot and have it stick for all > upcoming CPUs. > > Extend

Re: [patch 26/60] x86/cpufeature: Make cpu bugs sticky

On Mon, Dec 04, 2017 at 03:07:32PM +0100, Thomas Gleixner wrote: > From: Thomas Gleixner > > There is currently no way to force CPU bug bits like CPU feature bits. That > makes it impossible to set a bug bit once at boot and have it stick for all > upcoming CPUs. > > Extend the force set/clear

Re: [PATCH 1/3] dt-bindings: pwm: update bindings for the Meson-AXG

On Mon, Dec 04, 2017 at 02:00:16PM +0800, Yixun Lan wrote: > From: Jian Hu > > Update the doc to explicitly support Meson-AXG > > Signed-off-by: Jian Hu > Signed-off-by: Yixun Lan > --- >

Re: [PATCH 1/3] dt-bindings: pwm: update bindings for the Meson-AXG

On Mon, Dec 04, 2017 at 02:00:16PM +0800, Yixun Lan wrote: > From: Jian Hu > > Update the doc to explicitly support Meson-AXG > > Signed-off-by: Jian Hu > Signed-off-by: Yixun Lan > --- > Documentation/devicetree/bindings/pwm/pwm-meson.txt | 2 ++ > 1 file changed, 2 insertions(+)

Re: [PATCH tip/core/rcu 01/21] doc: READ_ONCE() now implies smp_barrier_depends()

Peter Zijlstra wrote: > > Good point! How about as shown in the updated patch below? > > Humm, I thought the idea was to completely remove read_barrier_depends > from the lkmm and memory-barriers.txt, making it an Alpha implementation > detail. memory-barriers.txt

Re: [PATCH tip/core/rcu 01/21] doc: READ_ONCE() now implies smp_barrier_depends()

Peter Zijlstra wrote: > > Good point! How about as shown in the updated patch below? > > Humm, I thought the idea was to completely remove read_barrier_depends > from the lkmm and memory-barriers.txt, making it an Alpha implementation > detail. memory-barriers.txt explains how the barriers

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

On Mon, 4 Dec 2017, Linus Torvalds wrote: > On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki wrote: > > > > So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the > > systems I have tested, so it is probably safe to assume it to be > > broken everywhere. > >

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

On Mon, 4 Dec 2017, Linus Torvalds wrote: > On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki wrote: > > > > So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the > > systems I have tested, so it is probably safe to assume it to be > > broken everywhere. > > Oh, it's definitely

Re: [patch 51/60] x86/mm: Allow flushing for future ASID switches

On Mon, Dec 4, 2017 at 2:34 PM, Dave Hansen wrote: > On 12/04/2017 02:22 PM, Andy Lutomirski wrote: >>> + >>> + this_cpu_write(cpu_tlbstate.invalidate_other, true); >> >> Why do we need this extra variable instead of just looping over all >> other ASIDs and

Re: [patch 51/60] x86/mm: Allow flushing for future ASID switches

On Mon, Dec 4, 2017 at 2:34 PM, Dave Hansen wrote: > On 12/04/2017 02:22 PM, Andy Lutomirski wrote: >>> + >>> + this_cpu_write(cpu_tlbstate.invalidate_other, true); >> >> Why do we need this extra variable instead of just looping over all >> other ASIDs and invalidating them? It would be

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki wrote: > > So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the > systems I have tested, so it is probably safe to assume it to be > broken everywhere. Oh, it's definitely not broken everywhere, because I use

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki wrote: > > So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the > systems I have tested, so it is probably safe to assume it to be > broken everywhere. Oh, it's definitely not broken everywhere, because I use it myself, and was

Re: [PATCH v6 4/6] dt: bindings: lp8860: Update the bindings to the standard

On Sun, Dec 03, 2017 at 02:27:20PM +0100, Jacek Anaszewski wrote: > Dan, > > On 12/01/2017 05:56 PM, Dan Murphy wrote: > > Update the lp8860 dt binding to the LED standard where > > the LED should have a child node and also adding a > > LED trigger entry. > > > > Signed-off-by: Dan Murphy

Re: [PATCH v6 4/6] dt: bindings: lp8860: Update the bindings to the standard

On Sun, Dec 03, 2017 at 02:27:20PM +0100, Jacek Anaszewski wrote: > Dan, > > On 12/01/2017 05:56 PM, Dan Murphy wrote: > > Update the lp8860 dt binding to the LED standard where > > the LED should have a child node and also adding a > > LED trigger entry. > > > > Signed-off-by: Dan Murphy > >

Re: [patch 51/60] x86/mm: Allow flushing for future ASID switches

On 12/04/2017 02:22 PM, Andy Lutomirski wrote: >> + >> + this_cpu_write(cpu_tlbstate.invalidate_other, true); > > Why do we need this extra variable instead of just looping over all > other ASIDs and invalidating them? It would be something like: > > for (i = 1; i <

Re: [patch 51/60] x86/mm: Allow flushing for future ASID switches

On 12/04/2017 02:22 PM, Andy Lutomirski wrote: >> + >> + this_cpu_write(cpu_tlbstate.invalidate_other, true); > > Why do we need this extra variable instead of just looping over all > other ASIDs and invalidating them? It would be something like: > > for (i = 1; i <

Re: [patch 56/60] x86/mm/kpti: Disable native VSYSCALL

On Mon, Dec 4, 2017 at 6:08 AM, Thomas Gleixner wrote: > From: Dave Hansen > > The KERNEL_PAGE_TABLE_ISOLATION code attempts to "poison" the user > portion of the kernel page tables. It detects entries that it wants that it > wants to poison in

Re: [patch 56/60] x86/mm/kpti: Disable native VSYSCALL

On Mon, Dec 4, 2017 at 6:08 AM, Thomas Gleixner wrote: > From: Dave Hansen > > The KERNEL_PAGE_TABLE_ISOLATION code attempts to "poison" the user > portion of the kernel page tables. It detects entries that it wants that it > wants to poison in two ways: > > * Looking for addresses >=

<    1   2   3   4   5   6   7   8   9   10   >