Re: [PATCH v3 2/4] KVM: X86: Fix loss of exception which has not yet injected

On Wed, Aug 23, 2017 at 10:21 PM, Wanpeng Li wrote: > From: Wanpeng Li > > vmx_complete_interrupts() assumes that the exception is always injected, > so it would be dropped by kvm_clear_exception_queue(). This patch separates > exception.pending from

Re: [PATCH v3 2/4] KVM: X86: Fix loss of exception which has not yet injected

On Wed, Aug 23, 2017 at 10:21 PM, Wanpeng Li wrote: > From: Wanpeng Li > > vmx_complete_interrupts() assumes that the exception is always injected, > so it would be dropped by kvm_clear_exception_queue(). This patch separates > exception.pending from exception.injected, exception.inject

Re: mmotm 2018-01-04-16-19 uploaded

On 01/05/2018 02:16 PM, Michal Hocko wrote: > On Fri 05-01-18 12:13:17, Anshuman Khandual wrote: >> On 01/05/2018 05:50 AM, a...@linux-foundation.org wrote: >>> The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to [...] >>> >>> This tree is partially included in linux-next. To

Re: mmotm 2018-01-04-16-19 uploaded

On 01/05/2018 02:16 PM, Michal Hocko wrote: > On Fri 05-01-18 12:13:17, Anshuman Khandual wrote: >> On 01/05/2018 05:50 AM, a...@linux-foundation.org wrote: >>> The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to [...] >>> >>> This tree is partially included in linux-next. To

Re: Fwd: Avoid speculative indirect calls in kernel

On Sat, Jan 06, 2018 at 10:04:26PM -0700, Kiernan Hager wrote: > On Thu, Jan 4, 2018 at 5:54 PM, Thomas Gleixner wrote: > > On Thu, 4 Jan 2018, Jon Masters wrote: > >> P.S. I've an internal document where I've been tracking "nice to haves" > >> for later, and one of them is

Re: Fwd: Avoid speculative indirect calls in kernel

On Sat, Jan 06, 2018 at 10:04:26PM -0700, Kiernan Hager wrote: > On Thu, Jan 4, 2018 at 5:54 PM, Thomas Gleixner wrote: > > On Thu, 4 Jan 2018, Jon Masters wrote: > >> P.S. I've an internal document where I've been tracking "nice to haves" > >> for later, and one of them is whether it makes sense

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 07:38:14PM -0800, Alexei Starovoitov wrote: > yep. plenty of unknowns and what's happening now is an overreaction. To be fair there's overreaction on both sides. The vast majority of users need to get a 100% safe system and will never notice any difference. A few of us

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 07:38:14PM -0800, Alexei Starovoitov wrote: > yep. plenty of unknowns and what's happening now is an overreaction. To be fair there's overreaction on both sides. The vast majority of users need to get a 100% safe system and will never notice any difference. A few of us

[PATCH v2 net-next] net: tracepoint: exposing sk_faimily in tracepoint inet_sock_set_state

As of now, there're two sk_family are traced with sock:inet_sock_set_state, which are AF_INET and AF_INET6. So the sk_family are exposed as well. Then we can conveniently use it to do the filter. Both sk_family and sk_protocol are showed in the printk message, so we need not expose them as

[PATCH v2 net-next] net: tracepoint: exposing sk_faimily in tracepoint inet_sock_set_state

As of now, there're two sk_family are traced with sock:inet_sock_set_state, which are AF_INET and AF_INET6. So the sk_family are exposed as well. Then we can conveniently use it to do the filter. Both sk_family and sk_protocol are showed in the printk message, so we need not expose them as

Re: [PATCH net-next] net: tracepoint: adding new tracepoint arguments in inet_sock_set_state

On Sun, Jan 7, 2018 at 1:46 AM, Song Liu wrote: > >> On Jan 5, 2018, at 12:09 AM, Yafang Shao wrote: >> >> On Fri, Jan 5, 2018 at 3:21 PM, Song Liu wrote: >>> On Jan 4, 2018, at 10:42 PM, Yafang Shao

Re: [PATCH net-next] net: tracepoint: adding new tracepoint arguments in inet_sock_set_state

On Sun, Jan 7, 2018 at 1:46 AM, Song Liu wrote: > >> On Jan 5, 2018, at 12:09 AM, Yafang Shao wrote: >> >> On Fri, Jan 5, 2018 at 3:21 PM, Song Liu wrote: >>> On Jan 4, 2018, at 10:42 PM, Yafang Shao wrote: sk->sk_protocol and sk->sk_family are exposed as tracepoint arguments.

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > 4.14-stable review patch. If anyone has any objections, please let me know. FYI, this broke kdump, or rather the makedumpfile part thereof.  Forward looking wreckage is par for the kdump course, but... > -- > >

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > 4.14-stable review patch. If anyone has any objections, please let me know. FYI, this broke kdump, or rather the makedumpfile part thereof.  Forward looking wreckage is par for the kdump course, but... > -- > >

Re: [RFCv2 2/4] Documentation: document nospec helpers

On 01/05/18 06:57, Mark Rutland wrote: > Document the rationale and usage of the new nospec*() helpers. > > Signed-off-by: Mark Rutland > Signed-off-by: Will Deacon > Cc: Dan Williams > Cc: Jonathan Corbet >

Re: [RFCv2 2/4] Documentation: document nospec helpers

On 01/05/18 06:57, Mark Rutland wrote: > Document the rationale and usage of the new nospec*() helpers. > > Signed-off-by: Mark Rutland > Signed-off-by: Will Deacon > Cc: Dan Williams > Cc: Jonathan Corbet > Cc: Peter Zijlstra > --- > Documentation/speculation.txt | 166 >

Fwd: Avoid speculative indirect calls in kernel

On Thu, Jan 4, 2018 at 5:54 PM, Thomas Gleixner wrote: > On Thu, 4 Jan 2018, Jon Masters wrote: >> P.S. I've an internal document where I've been tracking "nice to haves" >> for later, and one of them is whether it makes sense to tag binaries as >> "trusted" (e.g. extended

Fwd: Avoid speculative indirect calls in kernel

On Thu, Jan 4, 2018 at 5:54 PM, Thomas Gleixner wrote: > On Thu, 4 Jan 2018, Jon Masters wrote: >> P.S. I've an internal document where I've been tracking "nice to haves" >> for later, and one of them is whether it makes sense to tag binaries as >> "trusted" (e.g. extended attribute, label,

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 11:05:07PM +, Alan Cox wrote: > > Even if it would be practical the speed probably going to be in bytes per > > second, > > so to read anything meaningful an attack detection techniques (that people > > are actively working on) will be able to catch it. > > At the end

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 11:05:07PM +, Alan Cox wrote: > > Even if it would be practical the speed probably going to be in bytes per > > second, > > so to read anything meaningful an attack detection techniques (that people > > are actively working on) will be able to catch it. > > At the end

Re: [PATCH] [PATCH] virtio: make VIRTIO a menuconfig to ease disabling it all

On 01/03/18 01:49, Vincent Legoll wrote: > No need to get into the submenu to disable all VIRTIO-related > config entries. > > This makes it easier to disable all VIRTIO config options > without entering the submenu. It will also enable one > to see that en/dis-abled state from the outside menu.

Re: [PATCH] [PATCH] virtio: make VIRTIO a menuconfig to ease disabling it all

On 01/03/18 01:49, Vincent Legoll wrote: > No need to get into the submenu to disable all VIRTIO-related > config entries. > > This makes it easier to disable all VIRTIO config options > without entering the submenu. It will also enable one > to see that en/dis-abled state from the outside menu.

[PATCH 3/3] ARM: da8xx: remove con_id from USB clocks

There is only one clock each for "musb-da8xx" and "ohci-da8xx", so we do not the the con_id. Removing them will also prevent needing an unnecessary device tree property when device tree bindings are added for clocks. Signed-off-by: David Lechner ---

[PATCH 3/3] ARM: da8xx: remove con_id from USB clocks

There is only one clock each for "musb-da8xx" and "ohci-da8xx", so we do not the the con_id. Removing them will also prevent needing an unnecessary device tree property when device tree bindings are added for clocks. Signed-off-by: David Lechner --- arch/arm/mach-davinci/da830.c | 4 ++--

[PATCH 1/3] USB: musb: da8xx: remove clock con_id

There is only one clock for the DA8xx MUSB device, so we don't need the con_id, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner --- drivers/usb/musb/da8xx.c | 2 +- 1 file changed,

[PATCH 0/3] ARM: da8xx: remove con_id from USB clocks

This series removes unnecessary con_ids on da8xx USB clocks in preparation of adding device tree support for clocks on this platform. Note: this is a resend of "USB: musb: da8xx: remove clock con_id" and "USB: ohci: da8xx: remove clk con_id". I sent them before I realized that things break if

[PATCH 0/3] ARM: da8xx: remove con_id from USB clocks

This series removes unnecessary con_ids on da8xx USB clocks in preparation of adding device tree support for clocks on this platform. Note: this is a resend of "USB: musb: da8xx: remove clock con_id" and "USB: ohci: da8xx: remove clk con_id". I sent them before I realized that things break if

[PATCH 1/3] USB: musb: da8xx: remove clock con_id

There is only one clock for the DA8xx MUSB device, so we don't need the con_id, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner --- drivers/usb/musb/da8xx.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 2/3] USB: ohci: da8xx: remove clk con_id

The ohci-da8xx device only has one clock, so a con_id is not needed, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner --- drivers/usb/host/ohci-da8xx.c | 2 +- 1 file changed, 1

[PATCH 2/3] USB: ohci: da8xx: remove clk con_id

The ohci-da8xx device only has one clock, so a con_id is not needed, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner --- drivers/usb/host/ohci-da8xx.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v2 2/2] ARM: davinci: remove watchdog reset

This removes the watchdog reset code. The reset has been moved to drivers/watchdog/davinci_wdt.c. The watchdog driver registers the reset with the kernel so defining a reset for each machine is no longer needed. Signed-off-by: David Lechner Acked-by: Guenter Roeck

[PATCH v2 2/2] ARM: davinci: remove watchdog reset

This removes the watchdog reset code. The reset has been moved to drivers/watchdog/davinci_wdt.c. The watchdog driver registers the reset with the kernel so defining a reset for each machine is no longer needed. Signed-off-by: David Lechner Acked-by: Guenter Roeck ---

[PATCH v2 0/2] ARM: davinici: move watchdog restart from mach to drivers

This series moves the watchdog restart code from arch/arm/mach-davinci to drivers/watchdog. Tested working on LEGO MINDSTORMS EV3 (TI AM1808 processor). v2 changes: * rebased on linux-davinci/master (fixed conflict with clock.h) There is also still the unresolved question from Sekhar: > Hi

[PATCH v2 0/2] ARM: davinici: move watchdog restart from mach to drivers

This series moves the watchdog restart code from arch/arm/mach-davinci to drivers/watchdog. Tested working on LEGO MINDSTORMS EV3 (TI AM1808 processor). v2 changes: * rebased on linux-davinci/master (fixed conflict with clock.h) There is also still the unresolved question from Sekhar: > Hi

[PATCH v2 1/2] watchdog: davinci_wdt: add restart function

This adds a restart function to the davinci watchdog timer driver. This is copied from arch/arm/mach-davinci/time.c and will allow us to remove the code from there. Signed-off-by: David Lechner Reviewed-by: Guenter Roeck ---

[PATCH v2 1/2] watchdog: davinci_wdt: add restart function

This adds a restart function to the davinci watchdog timer driver. This is copied from arch/arm/mach-davinci/time.c and will allow us to remove the code from there. Signed-off-by: David Lechner Reviewed-by: Guenter Roeck --- drivers/watchdog/davinci_wdt.c | 38

Re: [PATCH] x86/mm/pti: remove dead logic during user pagetable population

On Sun, Jan 7, 2018 at 4:03 AM, Willy Tarreau wrote: > On Sun, Jan 07, 2018 at 01:50:59AM +0800, Jike Song wrote: >> Signed-off-by: Jike Song > > It would be nice to have a commit message, particularly in this quite > sensitive series... Yes that's useful, will

Re: [PATCH] x86/mm/pti: remove dead logic during user pagetable population

On Sun, Jan 7, 2018 at 4:03 AM, Willy Tarreau wrote: > On Sun, Jan 07, 2018 at 01:50:59AM +0800, Jike Song wrote: >> Signed-off-by: Jike Song > > It would be nice to have a commit message, particularly in this quite > sensitive series... Yes that's useful, will add it in v2 :) > > Willy --

[PATCH v2] libfdt: remove unnecessary include directive from

is a wrapper of scripts/dtc/libfdt/libfdt.h It should not do more than its job. In fact, libfdt.h depends on fdt.h, and scripts/dtc/libfdt/libfdt.h includes fdt.h already. Trust the work in the upstream DTC project. Signed-off-by: Masahiro Yamada --- Changes in

[PATCH v2] libfdt: remove unnecessary include directive from

is a wrapper of scripts/dtc/libfdt/libfdt.h It should not do more than its job. In fact, libfdt.h depends on fdt.h, and scripts/dtc/libfdt/libfdt.h includes fdt.h already. Trust the work in the upstream DTC project. Signed-off-by: Masahiro Yamada --- Changes in v2: - Rephrase commit-log a

Re: [PATCH] x86/mm/pti: remove dead logic during user pagetable population

On Sun, Jan 7, 2018 at 3:33 AM, Thomas Gleixner wrote: > On Sun, 7 Jan 2018, Jike Song wrote: > > Care to explain why you think this is not needed? > Hi Thomas, Look at one of the original code snippets: 162 if (pgd_none(*pgd)) { 163 unsigned

Re: [PATCH] x86/mm/pti: remove dead logic during user pagetable population

On Sun, Jan 7, 2018 at 3:33 AM, Thomas Gleixner wrote: > On Sun, 7 Jan 2018, Jike Song wrote: > > Care to explain why you think this is not needed? > Hi Thomas, Look at one of the original code snippets: 162 if (pgd_none(*pgd)) { 163 unsigned long new_p4d_page =

[RFC] memdup_user() and friends

After reviewing memdup_user() callers, I've found several places where it got completely unbounded values passed for size (up to 2Gb), as well as some bounded by ridiculously high values - e.g. if (size > 1024 * 128) /* sane value */ return -EINVAL;

[RFC] memdup_user() and friends

After reviewing memdup_user() callers, I've found several places where it got completely unbounded values passed for size (up to 2Gb), as well as some bounded by ridiculously high values - e.g. if (size > 1024 * 128) /* sane value */ return -EINVAL;

CPU frequency scaling (governor) issue (acpi-cpufreq)

Hi folks, on my old laptop I've a quadcore 2.5 GHz CPU, but the max freq the governor switches to goes only up to 2.1 GHz (at idle it's 1.4 GHz): cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 250 210 180 140 cat

CPU frequency scaling (governor) issue (acpi-cpufreq)

Hi folks, on my old laptop I've a quadcore 2.5 GHz CPU, but the max freq the governor switches to goes only up to 2.1 GHz (at idle it's 1.4 GHz): cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 250 210 180 140 cat

Re: [PATCH v5 02/12] x86/retpoline: Add initial retpoline support

On 1/6/2018 3:21 PM, Woodhouse, David wrote: > On Sat, 2018-01-06 at 21:16 +, Andrew Cooper wrote: >> On 06/01/18 11:49, David Woodhouse wrote: >>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c >>> index 372ba3f..40e6e54 100644 >>> --- a/arch/x86/kernel/cpu/common.c

Re: [PATCH v5 02/12] x86/retpoline: Add initial retpoline support

On 1/6/2018 3:21 PM, Woodhouse, David wrote: > On Sat, 2018-01-06 at 21:16 +, Andrew Cooper wrote: >> On 06/01/18 11:49, David Woodhouse wrote: >>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c >>> index 372ba3f..40e6e54 100644 >>> --- a/arch/x86/kernel/cpu/common.c

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

From: Willy Tarreau Date: Sat, 6 Jan 2018 21:42:29 +0100 > On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote: >> Normally people who propose security fixes don't have to argue about the >> fact they added 30 clocks to avoid your box being 0wned. > > In fact it depends,

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

From: Willy Tarreau Date: Sat, 6 Jan 2018 21:42:29 +0100 > On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote: >> Normally people who propose security fixes don't have to argue about the >> fact they added 30 clocks to avoid your box being 0wned. > > In fact it depends, because if a fix

Re: [PATCH v5 05/12] x86/retpoline/ftrace: Convert ftrace assembler indirect jumps

On Sat, Jan 6, 2018 at 11:53 AM, Thomas Gleixner wrote: > On Sat, 6 Jan 2018, Linus Torvalds wrote: > >> >> [ Goes off and looks ] >> >> Oh. The AMD lfence version wants a register. Oh well. > > The register load could be put into the macro itself, though we need to > supply a

Re: [PATCH v5 05/12] x86/retpoline/ftrace: Convert ftrace assembler indirect jumps

On Sat, Jan 6, 2018 at 11:53 AM, Thomas Gleixner wrote: > On Sat, 6 Jan 2018, Linus Torvalds wrote: > >> >> [ Goes off and looks ] >> >> Oh. The AMD lfence version wants a register. Oh well. > > The register load could be put into the macro itself, though we need to > supply a scratch register

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 6, 2018 at 3:31 PM, Dan Williams wrote: > > I assume if we put this in uaccess_begin() we also need audit for > paths that use access_ok but don't do on to call uaccess_begin()? A > quick glance shows a few places where we are open coding the stac(). >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 6, 2018 at 3:31 PM, Dan Williams wrote: > > I assume if we put this in uaccess_begin() we also need audit for > paths that use access_ok but don't do on to call uaccess_begin()? A > quick glance shows a few places where we are open coding the stac(). > Perhaps land the lfence in

metag build error in -next due to 'fs, elf: drop MAP_FIXED usage from elf_map'

The following build error is seen when building metag:meta2_defconfig or metag:tz1090_defconfig. arch/metag/kernel/process.c: In function '__metag_elf_map': arch/metag/kernel/process.c:421: error: 'tsk' undeclared Bisect results attached. Guenter --- # bad:

metag build error in -next due to 'fs, elf: drop MAP_FIXED usage from elf_map'

The following build error is seen when building metag:meta2_defconfig or metag:tz1090_defconfig. arch/metag/kernel/process.c: In function '__metag_elf_map': arch/metag/kernel/process.c:421: error: 'tsk' undeclared Bisect results attached. Guenter --- # bad:

[git pull] vfs fixes for -rc7

untangle sys_close() abuses in xt_bpf, deal with register_shrinker() failures in sget() The following changes since commit d7ee946942bdd12394809305e3df05aa4c8b7b8f: VFS: Handle lazytime in do_mount() (2017-12-09 20:16:33 -0500) are available in the git repository at:

[git pull] vfs fixes for -rc7

untangle sys_close() abuses in xt_bpf, deal with register_shrinker() failures in sget() The following changes since commit d7ee946942bdd12394809305e3df05aa4c8b7b8f: VFS: Handle lazytime in do_mount() (2017-12-09 20:16:33 -0500) are available in the git repository at:

[PATCH] jbd2: fix sphinx kerel-doc build warnings for journal_s

Sphinx emits various warnings when building make target 'htmldocs'. Currently struct journal_s definition contains duplicate documentation, some as kernel-docs and some as standard c89 comments. We can reduce duplication while cleaning up the kernel-docs. Move all kernel-docs to right above

[PATCH] jbd2: fix sphinx kerel-doc build warnings for journal_s

Sphinx emits various warnings when building make target 'htmldocs'. Currently struct journal_s definition contains duplicate documentation, some as kernel-docs and some as standard c89 comments. We can reduce duplication while cleaning up the kernel-docs. Move all kernel-docs to right above

[PATCH v6 0/1] Make input drivers y2038 safe

The series is aimed at making input events y2038 safe. It extends the lifetime of the realtime timestamps in the events to year 2106. The series is also a necessary update as glibc is set to provide 64 bit time_t support for 32 bit binaries. glibc plan is detailed at

[PATCH v6 1/1] input: Deprecate real timestamps beyond year 2106

struct timeval is not y2038 safe. All usage of timeval in the kernel will be replaced by y2038 safe structures. The change is also necessary as glibc is introducing support for 32 bit applications to use 64 bit time_t. Without this change, many applications would incorrectly interpret values in

[PATCH v6 0/1] Make input drivers y2038 safe

The series is aimed at making input events y2038 safe. It extends the lifetime of the realtime timestamps in the events to year 2106. The series is also a necessary update as glibc is set to provide 64 bit time_t support for 32 bit binaries. glibc plan is detailed at

[PATCH v6 1/1] input: Deprecate real timestamps beyond year 2106

struct timeval is not y2038 safe. All usage of timeval in the kernel will be replaced by y2038 safe structures. The change is also necessary as glibc is introducing support for 32 bit applications to use 64 bit time_t. Without this change, many applications would incorrectly interpret values in

[RFC PATCH 13/12] Retpoline vs. CONFIG_TRIM_UNUSED_SYMBOLS

Arjan pointed out that CONFIG_TRIM_UNUSED_SYMBOLS *really* doesn't like the dot in the symbols that GCC uses for the thunks. This seems to work, although my eyes are bleeding just a little bit. Given this, and the hack we already needed for MODVERSIONS, I wonder if a better approach might be to

[RFC PATCH 13/12] Retpoline vs. CONFIG_TRIM_UNUSED_SYMBOLS

Arjan pointed out that CONFIG_TRIM_UNUSED_SYMBOLS *really* doesn't like the dot in the symbols that GCC uses for the thunks. This seems to work, although my eyes are bleeding just a little bit. Given this, and the hack we already needed for MODVERSIONS, I wonder if a better approach might be to

Re: [net-next] netfilter: add segment routing header 'srh' match

Hi Ahmed, On Fri, Dec 29, 2017 at 12:07:52PM +0100, Ahmed Abdelsalam wrote: > It allows matching packets based on Segment Routing Header > (SRH) information. > The implementation considers revision 7 of the SRH draft. > https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07 > >

Re: [net-next] netfilter: add segment routing header 'srh' match

Hi Ahmed, On Fri, Dec 29, 2017 at 12:07:52PM +0100, Ahmed Abdelsalam wrote: > It allows matching packets based on Segment Routing Header > (SRH) information. > The implementation considers revision 7 of the SRH draft. > https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07 > >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Fri, Jan 5, 2018 at 7:09 PM, Linus Torvalds wrote: > On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds > wrote: >> >> The fact is, we have to stop speculating when access_ok() does *not* >> fail - because that's when we'll actually do

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Fri, Jan 5, 2018 at 7:09 PM, Linus Torvalds wrote: > On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds > wrote: >> >> The fact is, we have to stop speculating when access_ok() does *not* >> fail - because that's when we'll actually do the access. And it's that >> access that needs to be

Re: [patch 0/4] timer/nohz: Fix timer/nohz woes

On Sat, Jan 06, 2018 at 10:18:40PM +0100, Thomas Gleixner wrote: > On Fri, 5 Jan 2018, Paul E. McKenney wrote: > > But after more than 1,000 hours of test runs, split roughly evenly > > among the above three scenarios, there is no statistically significant > > difference in error rate among them.

Re: [patch 0/4] timer/nohz: Fix timer/nohz woes

On Sat, Jan 06, 2018 at 10:18:40PM +0100, Thomas Gleixner wrote: > On Fri, 5 Jan 2018, Paul E. McKenney wrote: > > But after more than 1,000 hours of test runs, split roughly evenly > > among the above three scenarios, there is no statistically significant > > difference in error rate among them.

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

> Even if it would be practical the speed probably going to be in bytes per > second, > so to read anything meaningful an attack detection techniques (that people > are actively working on) will be able to catch it. > At the end security cannot be absolute. > The current level of paranoia

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

> Even if it would be practical the speed probably going to be in bytes per > second, > so to read anything meaningful an attack detection techniques (that people > are actively working on) will be able to catch it. > At the end security cannot be absolute. > The current level of paranoia

[PATCH] crypto: clear htmldocs build warnings for crypto/hash

SPHINX build emits multiple warnings of kind: warning: duplicate section name 'Note' (when building kernel via make target 'htmldocs') This is caused by repeated use of comments of form: * Note: soau soaeusoa uoe We can change the format without loss of clarity and clear the

[PATCH] crypto: clear htmldocs build warnings for crypto/hash

SPHINX build emits multiple warnings of kind: warning: duplicate section name 'Note' (when building kernel via make target 'htmldocs') This is caused by repeated use of comments of form: * Note: soau soaeusoa uoe We can change the format without loss of clarity and clear the

Re: [PATCH] ACPI / WMI: Call acpi_wmi_init() later

On Sat, Jan 06, 2018 at 11:02:27AM +, Jonathan McDowell wrote: > On Sat, Jan 06, 2018 at 12:30:23AM +0100, Rafael J. Wysocki wrote: > > On Wed, Jan 3, 2018 at 12:49 PM, Rafael J. Wysocki > > wrote: > > > From: Rafael J. Wysocki > > > > > >

Re: [PATCH] ACPI / WMI: Call acpi_wmi_init() later

On Sat, Jan 06, 2018 at 11:02:27AM +, Jonathan McDowell wrote: > On Sat, Jan 06, 2018 at 12:30:23AM +0100, Rafael J. Wysocki wrote: > > On Wed, Jan 3, 2018 at 12:49 PM, Rafael J. Wysocki > > wrote: > > > From: Rafael J. Wysocki > > > > > > Calling acpi_wmi_init() at the subsys_initcall()

Re: [PATCH] netfilter: fix int overflow in xt_alloc_table_info()

On Thu, Dec 28, 2017 at 09:48:54AM +0100, Dmitry Vyukov wrote: > syzkaller triggered OOM kills by passing ipt_replace.size = -1 > to IPT_SO_SET_REPLACE. The root cause is that SMP_ALIGN() in > xt_alloc_table_info() causes int overflow and the size check passes > when it should not. SMP_ALIGN() is

Re: [PATCH] netfilter: fix int overflow in xt_alloc_table_info()

On Thu, Dec 28, 2017 at 09:48:54AM +0100, Dmitry Vyukov wrote: > syzkaller triggered OOM kills by passing ipt_replace.size = -1 > to IPT_SO_SET_REPLACE. The root cause is that SMP_ALIGN() in > xt_alloc_table_info() causes int overflow and the size check passes > when it should not. SMP_ALIGN() is

Problems with 'Construct init thread stack in the linker script rather than by union' in -next

Hi, commit 7e7a20a2058dc ("Construct init thread stack in the linker script rather than by union") results in various build failures in -next. cris: arch/cris/kernel/vmlinux.lds:67: undefined symbol `THREAD_SIZE' referenced in expression crisv32: arch/cris/kernel/vmlinux.lds:72:

Problems with 'Construct init thread stack in the linker script rather than by union' in -next

Hi, commit 7e7a20a2058dc ("Construct init thread stack in the linker script rather than by union") results in various build failures in -next. cris: arch/cris/kernel/vmlinux.lds:67: undefined symbol `THREAD_SIZE' referenced in expression crisv32: arch/cris/kernel/vmlinux.lds:72:

Re: [PATCH] Documentation: security/credentials.rst: explain need to sort group_list

On 01/06/18 12:20, Matthew Wilcox wrote: > > I've been thinking about all the kernel-doc we have that's completely > unincorporated. I've also been thinking about core-api/kernel-api.rst > which to my mind is completely unreadable in its current form -- look at >

Re: [PATCH] Documentation: security/credentials.rst: explain need to sort group_list

On 01/06/18 12:20, Matthew Wilcox wrote: > > I've been thinking about all the kernel-doc we have that's completely > unincorporated. I've also been thinking about core-api/kernel-api.rst > which to my mind is completely unreadable in its current form -- look at >

Re: [PATCH] atm/clip: Use seq_puts() in svc_addr()

On Sat, 6 Jan 2018 22:44:08 +0100 SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 6 Jan 2018 22:34:12 +0100 > > Two strings should be quickly put into a sequence by two function calls. > Thus use the function "seq_puts"

Re: [linux-sunxi] Re: [PATCH] uas: ignore UAS for Norelsys NS1068(X) chips

于 2018年1月7日 GMT+08:00 上午6:12:57, Hans de Goede 写到: >Hi, > >On 05-01-18 17:56, Icenowy Zheng wrote: >> The UAS mode of Norelsys NS1068(X) is reported to fail to work on >> several platforms with the following error message: >> >> xhci-hcd xhci-hcd.0.auto: ERROR Transfer

Re: [PATCH] atm/clip: Use seq_puts() in svc_addr()

On Sat, 6 Jan 2018 22:44:08 +0100 SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 6 Jan 2018 22:34:12 +0100 > > Two strings should be quickly put into a sequence by two function calls. > Thus use the function "seq_puts" instead of "seq_printf". > > This issue was detected by using

Re: [linux-sunxi] Re: [PATCH] uas: ignore UAS for Norelsys NS1068(X) chips

于 2018年1月7日 GMT+08:00 上午6:12:57, Hans de Goede 写到: >Hi, > >On 05-01-18 17:56, Icenowy Zheng wrote: >> The UAS mode of Norelsys NS1068(X) is reported to fail to work on >> several platforms with the following error message: >> >> xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for unknown stream

Re: [PATCH] uas: ignore UAS for Norelsys NS1068(X) chips

Hi, On 05-01-18 17:56, Icenowy Zheng wrote: The UAS mode of Norelsys NS1068(X) is reported to fail to work on several platforms with the following error message: xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for unknown stream ring slot 1 ep 8 xhci-hcd xhci-hcd.0.auto: @bf04a400

Re: [PATCH] uas: ignore UAS for Norelsys NS1068(X) chips

Hi, On 05-01-18 17:56, Icenowy Zheng wrote: The UAS mode of Norelsys NS1068(X) is reported to fail to work on several platforms with the following error message: xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for unknown stream ring slot 1 ep 8 xhci-hcd xhci-hcd.0.auto: @bf04a400

RE: [PATCH] mei: fix an && vs || typo

> > ->dev_state can't be both MEI_DEV_RESETTING and > MEI_DEV_POWER_DOWN at > the same time. && was clearing intended here. > > Fixes: 8d52af6795c0 ("mei: speed up the power down flow") > Signed-off-by: Dan Carpenter Thanks Dan but this was already reported and

RE: [PATCH] mei: fix an && vs || typo

> > ->dev_state can't be both MEI_DEV_RESETTING and > MEI_DEV_POWER_DOWN at > the same time. && was clearing intended here. > > Fixes: 8d52af6795c0 ("mei: speed up the power down flow") > Signed-off-by: Dan Carpenter Thanks Dan but this was already reported and patch was created by Colin.

[PATCH v3 1/2] iio: add kernel-doc for field @owner

When building kernel documentation sphinx emits the following warning warning: No description found for parameter 'owner' Add description for struct member 'owner'. Signed-off-by: Tobin C. Harding --- include/linux/iio/trigger.h | 1 + 1 file changed, 1 insertion(+)

[PATCH v3 1/2] iio: add kernel-doc for field @owner

When building kernel documentation sphinx emits the following warning warning: No description found for parameter 'owner' Add description for struct member 'owner'. Signed-off-by: Tobin C. Harding --- include/linux/iio/trigger.h | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v3 2/2] iio: add field identifier for @use_count kernel-doc

Kernel-doc for @use_count does not currently have a field identifier. All the rest of the fields do. @use_count is used internally and should not be accessed directly by the driver so it should be marked as so. Add [INTERN] identifier to @use_count field. Signed-off-by: Tobin C. Harding

[PATCH v3 2/2] iio: add field identifier for @use_count kernel-doc

Kernel-doc for @use_count does not currently have a field identifier. All the rest of the fields do. @use_count is used internally and should not be accessed directly by the driver so it should be marked as so. Add [INTERN] identifier to @use_count field. Signed-off-by: Tobin C. Harding ---

[PATCH v3 0/2] fix kernel-docs for struct iio_trigger

This series was inspired by a warning emitted by sphinx when running kernel make target 'htmldocs'. warning: No description found for parameter 'owner' Patch 1 adds a kernel-doc description for field @owner. Patch 2 adds field identifier to kernel-doc string (for @use_count). v3: -

[PATCH v3 0/2] fix kernel-docs for struct iio_trigger

This series was inspired by a warning emitted by sphinx when running kernel make target 'htmldocs'. warning: No description found for parameter 'owner' Patch 1 adds a kernel-doc description for field @owner. Patch 2 adds field identifier to kernel-doc string (for @use_count). v3: -

Re: [PATCH 0/3] eventfd: clean up unneeded cruft

On Sat, Jan 06, 2018 at 07:00:48PM +, Al Viro wrote: > On Sat, Jan 06, 2018 at 06:46:19PM +, Al Viro wrote: > > On Sat, Jan 06, 2018 at 09:45:41AM -0800, Eric Biggers wrote: > > > This series removes some cruft (mainly exported functions) from > > > fs/eventfd.c which seems to have been

Re: [PATCH 0/3] eventfd: clean up unneeded cruft

On Sat, Jan 06, 2018 at 07:00:48PM +, Al Viro wrote: > On Sat, Jan 06, 2018 at 06:46:19PM +, Al Viro wrote: > > On Sat, Jan 06, 2018 at 09:45:41AM -0800, Eric Biggers wrote: > > > This series removes some cruft (mainly exported functions) from > > > fs/eventfd.c which seems to have been

  1   2   3   4   5   6   7   >