Re: [PATCH] docs: add index entry for networking/msg_zerocopy

On Tue, Jan 09, 2018 at 10:58:23AM -0700, Jonathan Corbet wrote: > On Sat, 6 Jan 2018 12:30:37 +1100 > "Tobin C. Harding" wrote: > > > Currently msg_zerocopy is not included in any toctree. Sphinx emits a > > build warning to this effect. The other three rst files in > >

Re: [PATCH] docs: add index entry for networking/msg_zerocopy

On Tue, Jan 09, 2018 at 10:58:23AM -0700, Jonathan Corbet wrote: > On Sat, 6 Jan 2018 12:30:37 +1100 > "Tobin C. Harding" wrote: > > > Currently msg_zerocopy is not included in any toctree. Sphinx emits a > > build warning to this effect. The other three rst files in > >

[PATCH 3/3] exec: Pin stack limit during exec

Since the stack rlimit is used in multiple places during exec and it can be changed via other threads (via setrlimit()) or processes (via prlimit()), the assumption that the value doesn't change cannot be made. This leads to races with mm layout selection and argument size calculations. This

[PATCH 3/3] exec: Pin stack limit during exec

Since the stack rlimit is used in multiple places during exec and it can be changed via other threads (via setrlimit()) or processes (via prlimit()), the assumption that the value doesn't change cannot be made. This leads to races with mm layout selection and argument size calculations. This

[PATCH 0/3] exec: Pin stack limit during exec

Attempts to solve problems with the stack limit changing during exec continue to be frustrated[1][2]. In addition to the specific issues around the Stack Clash family of flaws, Andy Lutomirski pointed out[3] other places during exec where the stack limit is used and is

[PATCH 0/3] exec: Pin stack limit during exec

Attempts to solve problems with the stack limit changing during exec continue to be frustrated[1][2]. In addition to the specific issues around the Stack Clash family of flaws, Andy Lutomirski pointed out[3] other places during exec where the stack limit is used and is

[PATCH 1/3] exec: Pass stack rlimit into mm layout functions

Since it is possible that the stack rlimit can change externally during exec (either via another thread calling setrlimit() or another process calling prlimit()), provide a way to pass the rlimit down into the per-architecture mm layout functions so that the rlimit can stay in the bprm structure

[PATCH 1/3] exec: Pass stack rlimit into mm layout functions

Since it is possible that the stack rlimit can change externally during exec (either via another thread calling setrlimit() or another process calling prlimit()), provide a way to pass the rlimit down into the per-architecture mm layout functions so that the rlimit can stay in the bprm structure

[PATCH 2/3] exec: Introduce finalize_exec() before start_thread()

Provide a final call back into fs/exec.c before start_thread() takes over, to handle any last-minute changes, like the coming restoration of the stack limit. Signed-off-by: Kees Cook --- fs/binfmt_aout.c| 1 + fs/binfmt_elf.c | 1 + fs/binfmt_elf_fdpic.c

[PATCH 2/3] exec: Introduce finalize_exec() before start_thread()

Provide a final call back into fs/exec.c before start_thread() takes over, to handle any last-minute changes, like the coming restoration of the stack limit. Signed-off-by: Kees Cook --- fs/binfmt_aout.c| 1 + fs/binfmt_elf.c | 1 + fs/binfmt_elf_fdpic.c | 1 +

Re: [PATCH v3 6/6] coresight: etm4x: Support panic kdump

On Thu, Dec 21, 2017 at 04:20:15PM +0800, Leo Yan wrote: > ETMv4 hardware information and configuration needs to be saved as > metadata; these metadata should be compatible with tool 'perf' and > can be used for tracing data analysis. ETMv4 usually works as tracer > per CPU, we cannot wait to

Re: [PATCH v3 6/6] coresight: etm4x: Support panic kdump

On Thu, Dec 21, 2017 at 04:20:15PM +0800, Leo Yan wrote: > ETMv4 hardware information and configuration needs to be saved as > metadata; these metadata should be compatible with tool 'perf' and > can be used for tracing data analysis. ETMv4 usually works as tracer > per CPU, we cannot wait to

linux-next: Signed-off-by missing for commits in the staging tree

Hi Greg, Commits 97c6166001ef ("Staging: rtlwifi: Remove unused variable and the code") 357f862bd214 ("staging: comedi: adv_pci1760: fix typo in comments") 23cb746b5e9d ("staging: rtl8192u: Replace mdelay with msleep in rtl8192_usb_probe") beac4303532f ("Staging: vt6656: Fix unnecessary

linux-next: Signed-off-by missing for commits in the staging tree

Hi Greg, Commits 97c6166001ef ("Staging: rtlwifi: Remove unused variable and the code") 357f862bd214 ("staging: comedi: adv_pci1760: fix typo in comments") 23cb746b5e9d ("staging: rtl8192u: Replace mdelay with msleep in rtl8192_usb_probe") beac4303532f ("Staging: vt6656: Fix unnecessary

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Hello, Steven. My apologies for the late reply. Was traveling and then got sick. On Thu, Dec 21, 2017 at 11:19:32PM -0500, Steven Rostedt wrote: > You don't think handing off printks to an offloaded thread isn't more > complex nor can it cause even more issues (like more likely to lose >

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Hello, Steven. My apologies for the late reply. Was traveling and then got sick. On Thu, Dec 21, 2017 at 11:19:32PM -0500, Steven Rostedt wrote: > You don't think handing off printks to an offloaded thread isn't more > complex nor can it cause even more issues (like more likely to lose >

Re: Fwd: [PATCH 0/2] sysfs: allow user-space request for devcoredump

On Tue, Jan 9, 2018 at 9:03 PM, Greg KH wrote: > On Tue, Jan 09, 2018 at 08:21:11PM +0100, Arend van Spriel wrote: >> + LKML >> >> -- Forwarded message -- >> From: Arend van Spriel >> Date: Tue, Jan 9, 2018 at 8:19 PM >> Subject: Re: [PATCH 0/2]

Re: Fwd: [PATCH 0/2] sysfs: allow user-space request for devcoredump

On Tue, Jan 9, 2018 at 9:03 PM, Greg KH wrote: > On Tue, Jan 09, 2018 at 08:21:11PM +0100, Arend van Spriel wrote: >> + LKML >> >> -- Forwarded message -- >> From: Arend van Spriel >> Date: Tue, Jan 9, 2018 at 8:19 PM >> Subject: Re: [PATCH 0/2] sysfs: allow user-space request

Re: [PATCH trivial-v2] RCU: Call touch_nmi_watchdog() while printing stall warnings

On Tue, Jan 09, 2018 at 10:52:22AM -0800, Tejun Heo wrote: > >From c1d1ae75ba4bde7c833560248b3f561085fa850e Mon Sep 17 00:00:00 2001 > From: Tejun Heo > Date: Tue, 9 Jan 2018 10:38:17 -0800 > Subject: [PATCH] RCU: Call touch_nmi_watchdog() while printing stall warnings > > When

Re: [PATCH trivial-v2] RCU: Call touch_nmi_watchdog() while printing stall warnings

On Tue, Jan 09, 2018 at 10:52:22AM -0800, Tejun Heo wrote: > >From c1d1ae75ba4bde7c833560248b3f561085fa850e Mon Sep 17 00:00:00 2001 > From: Tejun Heo > Date: Tue, 9 Jan 2018 10:38:17 -0800 > Subject: [PATCH] RCU: Call touch_nmi_watchdog() while printing stall warnings > > When RCU stall warning

Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v5

On Tue, Jan 09, 2018 at 11:47:55AM -0800, Christoph Hellwig wrote: > On Thu, Jan 04, 2018 at 02:49:21PM +0100, Christian König wrote: > > I perfectly agree on that, but this is for stable kernel backports. Because > > of this I want to keep the footprint as low as possible. > > > > When your

Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v5

On Tue, Jan 09, 2018 at 11:47:55AM -0800, Christoph Hellwig wrote: > On Thu, Jan 04, 2018 at 02:49:21PM +0100, Christian König wrote: > > I perfectly agree on that, but this is for stable kernel backports. Because > > of this I want to keep the footprint as low as possible. > > > > When your

Re: [PATCH 2/2] drivers: android: Fix logtags in methods

On Tue, Jan 09, 2018 at 07:45:33PM +, Harsh Shandilya wrote: > On Tue 9 Jan, 2018, 10:32 PM Greg Kroah-Hartman, > wrote: > > > On Fri, Dec 22, 2017 at 07:37:03PM +0530, Harsh Shandilya wrote: > > > From: Harsh Shandilya > > > > > > Several methods

Re: [PATCH 2/2] drivers: android: Fix logtags in methods

On Tue, Jan 09, 2018 at 07:45:33PM +, Harsh Shandilya wrote: > On Tue 9 Jan, 2018, 10:32 PM Greg Kroah-Hartman, > wrote: > > > On Fri, Dec 22, 2017 at 07:37:03PM +0530, Harsh Shandilya wrote: > > > From: Harsh Shandilya > > > > > > Several methods in the driver were hardcoding > > > the

Re: Fwd: [PATCH 0/2] sysfs: allow user-space request for devcoredump

On Tue, Jan 09, 2018 at 08:21:11PM +0100, Arend van Spriel wrote: > + LKML > > -- Forwarded message -- > From: Arend van Spriel > Date: Tue, Jan 9, 2018 at 8:19 PM > Subject: Re: [PATCH 0/2] sysfs: allow user-space request for devcoredump > To: Greg

Re: Fwd: [PATCH 0/2] sysfs: allow user-space request for devcoredump

On Tue, Jan 09, 2018 at 08:21:11PM +0100, Arend van Spriel wrote: > + LKML > > -- Forwarded message -- > From: Arend van Spriel > Date: Tue, Jan 9, 2018 at 8:19 PM > Subject: Re: [PATCH 0/2] sysfs: allow user-space request for devcoredump > To: Greg Kroah-Hartman > > > On Tue,

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

On Tue, Jan 9, 2018 at 11:31 AM, Christian König wrote: >> >> For example, was there a reason for that random 756GB address? Is the >> limit of the particular AMD 64-bit bar perhaps at the 1TB mark (and >> that "res->end" value is because "close to it, but not at the

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

On Tue, Jan 9, 2018 at 11:31 AM, Christian König wrote: >> >> For example, was there a reason for that random 756GB address? Is the >> limit of the particular AMD 64-bit bar perhaps at the 1TB mark (and >> that "res->end" value is because "close to it, but not at the top")? > > That is actually a

Re: perf: perf_fuzzer quickly locks up on 4.15-rc7

On Tue, Jan 09, 2018 at 01:09:57PM -0500, Steven Rostedt wrote: > On Tue, 9 Jan 2018 19:02:07 +0100 > Peter Zijlstra wrote: > > > This would globally serialize all perf_ioctl()'s, also that event_mutex > > is for trace_events and really does not belong in perf. > > > > So

Re: perf: perf_fuzzer quickly locks up on 4.15-rc7

On Tue, Jan 09, 2018 at 01:09:57PM -0500, Steven Rostedt wrote: > On Tue, 9 Jan 2018 19:02:07 +0100 > Peter Zijlstra wrote: > > > This would globally serialize all perf_ioctl()'s, also that event_mutex > > is for trace_events and really does not belong in perf. > > > > So no, I really rather

Re: unify the interface of the proportional-share policy in blkio/io

On 1/9/18 12:52 PM, Tejun Heo wrote: > Hello, Paolo. > > On Thu, Jan 04, 2018 at 08:00:02PM +0100, Paolo Valente wrote: >> The solution for the second type of parameters may prove useful to >> unify also the computation of statistics for the throttling policy. >> >> Does this proposal sound

Re: unify the interface of the proportional-share policy in blkio/io

On 1/9/18 12:52 PM, Tejun Heo wrote: > Hello, Paolo. > > On Thu, Jan 04, 2018 at 08:00:02PM +0100, Paolo Valente wrote: >> The solution for the second type of parameters may prove useful to >> unify also the computation of statistics for the throttling policy. >> >> Does this proposal sound

Re: unify the interface of the proportional-share policy in blkio/io

Hello, Paolo. On Thu, Jan 04, 2018 at 08:00:02PM +0100, Paolo Valente wrote: > The solution for the second type of parameters may prove useful to > unify also the computation of statistics for the throttling policy. > > Does this proposal sound reasonable? So, the above should work too but I

Re: unify the interface of the proportional-share policy in blkio/io

Hello, Paolo. On Thu, Jan 04, 2018 at 08:00:02PM +0100, Paolo Valente wrote: > The solution for the second type of parameters may prove useful to > unify also the computation of statistics for the throttling policy. > > Does this proposal sound reasonable? So, the above should work too but I

Re: [PATCH 4.4 00/37] 4.4.110-stable review

Quoting Greg Kroah-Hartman (gre...@linuxfoundation.org): > On Sat, Jan 06, 2018 at 02:20:16AM +0900, Alice Ferrazzi wrote: > > On Thu, Jan 4, 2018 at 5:11 AM, Greg Kroah-Hartman > > wrote: > > > This is the start of the stable review cycle for the 4.4.110 release. > >

Re: [PATCH 4.4 00/37] 4.4.110-stable review

Quoting Greg Kroah-Hartman (gre...@linuxfoundation.org): > On Sat, Jan 06, 2018 at 02:20:16AM +0900, Alice Ferrazzi wrote: > > On Thu, Jan 4, 2018 at 5:11 AM, Greg Kroah-Hartman > > wrote: > > > This is the start of the stable review cycle for the 4.4.110 release. > > > There are 37 patches in

Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v5

On Thu, Jan 04, 2018 at 02:49:21PM +0100, Christian König wrote: > I perfectly agree on that, but this is for stable kernel backports. Because > of this I want to keep the footprint as low as possible. > > When your patchset to clean that up lands for 4.16 I have no problem > changing that. > >

Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v5

On Thu, Jan 04, 2018 at 02:49:21PM +0100, Christian König wrote: > I perfectly agree on that, but this is for stable kernel backports. Because > of this I want to keep the footprint as low as possible. > > When your patchset to clean that up lands for 4.16 I have no problem > changing that. > >

[PATCH] PCI: iproc: Fix NULL pointer dereference for BCMA

With the inbound DMA mapping supported added, the iProc PCIe driver parses DT property "dma-ranges" through call to "of_pci_dma_range_parser_init". In the case of BCMA, this results in a NULL pointer deference due to a missing of_node. Fix this by adding a guard in pcie-iproc-platform.c to only

[PATCH] PCI: iproc: Fix NULL pointer dereference for BCMA

With the inbound DMA mapping supported added, the iProc PCIe driver parses DT property "dma-ranges" through call to "of_pci_dma_range_parser_init". In the case of BCMA, this results in a NULL pointer deference due to a missing of_node. Fix this by adding a guard in pcie-iproc-platform.c to only

Re: [PATCH] Input: cyapa - remove duplicated macro definitions

On Mon, Jan 08, 2018 at 10:54:02PM +0100, Rasmus Villemoes wrote: > Apart from whitespace differences, this block of macros is repeated > twice: > > $ x=./drivers/input/mouse/cyapa_gen3.c; diff -w -u <(sed -n '139,181p' $x) > <(sed -n '182,224p' $x) > $ > > Signed-off-by: Rasmus Villemoes

Re: [PATCH] Input: cyapa - remove duplicated macro definitions

On Mon, Jan 08, 2018 at 10:54:02PM +0100, Rasmus Villemoes wrote: > Apart from whitespace differences, this block of macros is repeated > twice: > > $ x=./drivers/input/mouse/cyapa_gen3.c; diff -w -u <(sed -n '139,181p' $x) > <(sed -n '182,224p' $x) > $ > > Signed-off-by: Rasmus Villemoes

Microblaze boot failure in -next due to 'of/fdt: use memblock_virt_alloc for early alloc'

Hi, microblaze and microblazeel images fail to boot in -next. Error log is: Early console on uartlite at 0x8400 bootconsole [earlyser0] enabled Ramdisk addr 0x, FDT at 0x9065323c Linux version 4.15.0-rc7-next-20180109 (gro...@jupiter.roeck-us.net) (gcc version 4.8.0 (GCC)) #1 Tue

Microblaze boot failure in -next due to 'of/fdt: use memblock_virt_alloc for early alloc'

Hi, microblaze and microblazeel images fail to boot in -next. Error log is: Early console on uartlite at 0x8400 bootconsole [earlyser0] enabled Ramdisk addr 0x, FDT at 0x9065323c Linux version 4.15.0-rc7-next-20180109 (gro...@jupiter.roeck-us.net) (gcc version 4.8.0 (GCC)) #1 Tue

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina wrote: > On Fri, 5 Jan 2018, Dan Williams wrote: > > [ ... snip ... ] >> Andi Kleen (1): >> x86, barrier: stop speculation for failed access_ok >> >> Dan Williams (13): >> x86: implement nospec_barrier() >> [media]

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina wrote: > On Fri, 5 Jan 2018, Dan Williams wrote: > > [ ... snip ... ] >> Andi Kleen (1): >> x86, barrier: stop speculation for failed access_ok >> >> Dan Williams (13): >> x86: implement nospec_barrier() >> [media] uvcvideo: prevent

Re: [PATCH] staging: pi433: remove unnecessary parentheses

On Tue, 2018-01-09 at 20:28 +0100, Greg Kroah-Hartman wrote: > On Tue, Jan 09, 2018 at 11:21:37AM -0800, Joe Perches wrote: > > On Tue, 2018-01-09 at 15:31 +0100, Greg Kroah-Hartman wrote: > > > On Mon, Jan 08, 2018 at 06:38:55PM +0100, Valentin Vidic wrote: > > > > Fixes checkpatch warnings: > >

Re: [PATCH] staging: pi433: remove unnecessary parentheses

On Tue, 2018-01-09 at 20:28 +0100, Greg Kroah-Hartman wrote: > On Tue, Jan 09, 2018 at 11:21:37AM -0800, Joe Perches wrote: > > On Tue, 2018-01-09 at 15:31 +0100, Greg Kroah-Hartman wrote: > > > On Mon, Jan 08, 2018 at 06:38:55PM +0100, Valentin Vidic wrote: > > > > Fixes checkpatch warnings: > >

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Fri, 5 Jan 2018, Dan Williams wrote: [ ... snip ... ] > Andi Kleen (1): > x86, barrier: stop speculation for failed access_ok > > Dan Williams (13): > x86: implement nospec_barrier() > [media] uvcvideo: prevent bounds-check bypass via speculative execution > carl9170:

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Fri, 5 Jan 2018, Dan Williams wrote: [ ... snip ... ] > Andi Kleen (1): > x86, barrier: stop speculation for failed access_ok > > Dan Williams (13): > x86: implement nospec_barrier() > [media] uvcvideo: prevent bounds-check bypass via speculative execution > carl9170:

Re: [PATCH] MAINTAINERS: Mark some staging directories as "Obsolete"

On Tue, Jan 09, 2018 at 11:33:56AM -0800, Joe Perches wrote: > Several staging directories have TODO files that indicate a > subsystem will be removed in the future. > > Using a status entry of "S: Obsolete" helps indicate the > subsystem files should not be modified unnecessarily. > >

Re: [PATCH] MAINTAINERS: Mark some staging directories as "Obsolete"

On Tue, Jan 09, 2018 at 11:33:56AM -0800, Joe Perches wrote: > Several staging directories have TODO files that indicate a > subsystem will be removed in the future. > > Using a status entry of "S: Obsolete" helps indicate the > subsystem files should not be modified unnecessarily. > >

[PATCH] MAINTAINERS: Mark some staging directories as "Obsolete"

Several staging directories have TODO files that indicate a subsystem will be removed in the future. Using a status entry of "S: Obsolete" helps indicate the subsystem files should not be modified unnecessarily. checkpatch also tests this setting and emits a warning that the matching

[PATCH] MAINTAINERS: Mark some staging directories as "Obsolete"

Several staging directories have TODO files that indicate a subsystem will be removed in the future. Using a status entry of "S: Obsolete" helps indicate the subsystem files should not be modified unnecessarily. checkpatch also tests this setting and emits a warning that the matching

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

Am 09.01.2018 um 20:18 schrieb Linus Torvalds: On Tue, Jan 9, 2018 at 2:37 AM, Christian König wrote: I tested a bit with Aaro and came up with the attached patch, it adds a 16GB guard between the end of memory and the new window for the PCIe root hub. But I agree

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

Am 09.01.2018 um 20:18 schrieb Linus Torvalds: On Tue, Jan 9, 2018 at 2:37 AM, Christian König wrote: I tested a bit with Aaro and came up with the attached patch, it adds a 16GB guard between the end of memory and the new window for the PCIe root hub. But I agree with you that this is just a

Re: [PATCH] staging: pi433: remove unnecessary parentheses

On Tue, Jan 09, 2018 at 11:21:37AM -0800, Joe Perches wrote: > On Tue, 2018-01-09 at 15:31 +0100, Greg Kroah-Hartman wrote: > > On Mon, Jan 08, 2018 at 06:38:55PM +0100, Valentin Vidic wrote: > > > Fixes checkpatch warnings: > > > CHECK: Unnecessary parentheses around 'mantisse != mantisse16' >

Re: [PATCH] staging: pi433: remove unnecessary parentheses

On Tue, Jan 09, 2018 at 11:21:37AM -0800, Joe Perches wrote: > On Tue, 2018-01-09 at 15:31 +0100, Greg Kroah-Hartman wrote: > > On Mon, Jan 08, 2018 at 06:38:55PM +0100, Valentin Vidic wrote: > > > Fixes checkpatch warnings: > > > CHECK: Unnecessary parentheses around 'mantisse != mantisse16' >

[PATCH] Documentation: usb: fix typo in UVC gadgetfs config command

This seems to be a copy error. With the fix the uvc gadget now can be created by following the instrucitons. Signed-off-by: Bin Liu --- Documentation/usb/gadget-testing.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/usb/gadget-testing.txt

[PATCH] Documentation: usb: fix typo in UVC gadgetfs config command

This seems to be a copy error. With the fix the uvc gadget now can be created by following the instrucitons. Signed-off-by: Bin Liu --- Documentation/usb/gadget-testing.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/usb/gadget-testing.txt

Re: [PATCH v12 1/3] lib: Add strongly typed 64bit int_sqrt

On Tue, 2018-01-09 at 16:18 +0100, Crt Mori wrote: > There is no option to perform 64bit integer sqrt on 32bit platform. > Added stronger typed int_sqrt64 enables the 64bit calculations to > be performed on 32bit platforms. Using same algorithm as int_sqrt() > with strong typing provides enough

Re: [PATCH v12 1/3] lib: Add strongly typed 64bit int_sqrt

On Tue, 2018-01-09 at 16:18 +0100, Crt Mori wrote: > There is no option to perform 64bit integer sqrt on 32bit platform. > Added stronger typed int_sqrt64 enables the 64bit calculations to > be performed on 32bit platforms. Using same algorithm as int_sqrt() > with strong typing provides enough

[PATCH] kmemleak: allow to coexist with fault injection

kmemleak does one slab allocation per user allocation. So if slab fault injection is enabled to any degree, kmemleak instantly fails to allocate and turns itself off. However, it's useful to use kmemleak with fault injection to find leaks on error paths. On the other hand, checking kmemleak itself

[PATCH] kmemleak: allow to coexist with fault injection

kmemleak does one slab allocation per user allocation. So if slab fault injection is enabled to any degree, kmemleak instantly fails to allocate and turns itself off. However, it's useful to use kmemleak with fault injection to find leaks on error paths. On the other hand, checking kmemleak itself

Re: [PATCH] staging: pi433: remove unnecessary parentheses

On Tue, 2018-01-09 at 15:31 +0100, Greg Kroah-Hartman wrote: > On Mon, Jan 08, 2018 at 06:38:55PM +0100, Valentin Vidic wrote: > > Fixes checkpatch warnings: > > CHECK: Unnecessary parentheses around 'mantisse != mantisse16' > > CHECK: Unnecessary parentheses around 'mantisse != mantisse20' >

Re: [PATCH] staging: pi433: remove unnecessary parentheses

On Tue, 2018-01-09 at 15:31 +0100, Greg Kroah-Hartman wrote: > On Mon, Jan 08, 2018 at 06:38:55PM +0100, Valentin Vidic wrote: > > Fixes checkpatch warnings: > > CHECK: Unnecessary parentheses around 'mantisse != mantisse16' > > CHECK: Unnecessary parentheses around 'mantisse != mantisse20' >

Fwd: [PATCH 0/2] sysfs: allow user-space request for devcoredump

+ LKML -- Forwarded message -- From: Arend van Spriel Date: Tue, Jan 9, 2018 at 8:19 PM Subject: Re: [PATCH 0/2] sysfs: allow user-space request for devcoredump To: Greg Kroah-Hartman On Tue, Jan 9, 2018 at 7:46 PM, Greg

Fwd: [PATCH 0/2] sysfs: allow user-space request for devcoredump

+ LKML -- Forwarded message -- From: Arend van Spriel Date: Tue, Jan 9, 2018 at 8:19 PM Subject: Re: [PATCH 0/2] sysfs: allow user-space request for devcoredump To: Greg Kroah-Hartman On Tue, Jan 9, 2018 at 7:46 PM, Greg Kroah-Hartman wrote: > On Tue, Dec 19, 2017 at

Re: [PATCH 2/4] f2fs: support FIEMAP_FLAG_CACHE

On 01/08, Chao Yu wrote: > This patch factors out f2fs_precache_extents from > f2fs_ioc_precache_extents, with the new function we can support > FIEMAP_FLAG_CACHE in ->fiemap. > > Signed-off-by: Chao Yu > --- > fs/f2fs/data.c | 12 +--- > fs/f2fs/f2fs.h | 1 + >

Re: [PATCH 2/4] f2fs: support FIEMAP_FLAG_CACHE

On 01/08, Chao Yu wrote: > This patch factors out f2fs_precache_extents from > f2fs_ioc_precache_extents, with the new function we can support > FIEMAP_FLAG_CACHE in ->fiemap. > > Signed-off-by: Chao Yu > --- > fs/f2fs/data.c | 12 +--- > fs/f2fs/f2fs.h | 1 + > fs/f2fs/file.c | 10

Re: [PATCH] EDAC, mv64x60: Fix an error handling path

On Sun, Jan 07, 2018 at 09:54:00PM +0100, Christophe JAILLET wrote: > We should not call 'edac_mc_del_mc()' if a corresponding call to > 'edac_mc_add_mc()' has not been performed yet. > > So here, we should go to err instead of err2 to branch at the right place > of the error handling path. > >

Re: [PATCH] EDAC, mv64x60: Fix an error handling path

On Sun, Jan 07, 2018 at 09:54:00PM +0100, Christophe JAILLET wrote: > We should not call 'edac_mc_del_mc()' if a corresponding call to > 'edac_mc_add_mc()' has not been performed yet. > > So here, we should go to err instead of err2 to branch at the right place > of the error handling path. > >

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

On Tue, Jan 9, 2018 at 2:37 AM, Christian König wrote: > > I tested a bit with Aaro and came up with the attached patch, it adds a 16GB > guard between the end of memory and the new window for the PCIe root hub. > But I agree with you that this is just a hack and not a

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

On Tue, Jan 9, 2018 at 2:37 AM, Christian König wrote: > > I tested a bit with Aaro and came up with the attached patch, it adds a 16GB > guard between the end of memory and the new window for the PCIe root hub. > But I agree with you that this is just a hack and not a real solution. Guys, that

Re: [PATCH 1/6] dt-bindings: soc: qcom: Add label for GLINK bindings

On 12/21/2017 11:36 AM, Stephen Boyd wrote: On 12/20/2017 05:35 PM, Bjorn Andersson wrote: On Wed 20 Dec 10:30 PST 2017, Rob Herring wrote: On Mon, Dec 18, 2017 at 02:02:09PM -0800, Chris Lew wrote: Add a label property to identify the edge this node represents. Why does a user need to

Re: [PATCH 1/6] dt-bindings: soc: qcom: Add label for GLINK bindings

On 12/21/2017 11:36 AM, Stephen Boyd wrote: On 12/20/2017 05:35 PM, Bjorn Andersson wrote: On Wed 20 Dec 10:30 PST 2017, Rob Herring wrote: On Mon, Dec 18, 2017 at 02:02:09PM -0800, Chris Lew wrote: Add a label property to identify the edge this node represents. Why does a user need to

[PATCH v1 03/16] arm64: Make page table helpers reusable

This patch rearranges the page table level helpers so that it can be reused for a page table with different number of levels (e.g, stage2 page table for a VM) than the kernel page tables. As such there is no functional change with this patch. The page table helpers are defined to do the right

[PATCH v1 03/16] arm64: Make page table helpers reusable

This patch rearranges the page table level helpers so that it can be reused for a page table with different number of levels (e.g, stage2 page table for a VM) than the kernel page tables. As such there is no functional change with this patch. The page table helpers are defined to do the right

[PATCH v1 02/16] irqchip: gicv3-its: Add helpers for handling 52bit address

Add helpers for encoding/decoding 52bit address in GICv3 ITS BASER register. When ITS uses 64K page size, the 52bits of physical address are encoded in BASER[47:12] as follows : Bits[47:16] of the register => bits[47:16] of the physical address Bits[15:12] of the register => bits[51:48] of the

[PATCH v1 02/16] irqchip: gicv3-its: Add helpers for handling 52bit address

Add helpers for encoding/decoding 52bit address in GICv3 ITS BASER register. When ITS uses 64K page size, the 52bits of physical address are encoded in BASER[47:12] as follows : Bits[47:16] of the register => bits[47:16] of the physical address Bits[15:12] of the register => bits[51:48] of the

[PATCH v1 07/16] kvm: arm/arm64: Remove spurious WARN_ON

On a 4-level page table pgd entry can be empty, unlike a 3-level page table. Remove the spurious WARN_ON() in stage_get_pud(). Cc: Marc Zyngier Cc: Christoffer Dall Signed-off-by: Suzuki K Poulose --- virt/kvm/arm/mmu.c | 2 +- 1

[PATCH v1 07/16] kvm: arm/arm64: Remove spurious WARN_ON

On a 4-level page table pgd entry can be empty, unlike a 3-level page table. Remove the spurious WARN_ON() in stage_get_pud(). Cc: Marc Zyngier Cc: Christoffer Dall Signed-off-by: Suzuki K Poulose --- virt/kvm/arm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v1 05/16] arm64: Helper for parange to PASize

Add a helper to convert ID_AA64MMFR0_EL1:PARange to they physical size shift. Limit the size to the maximum supported by the kernel. Cc: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Cc: Marc Zyngier

[PATCH v1 05/16] arm64: Helper for parange to PASize

Add a helper to convert ID_AA64MMFR0_EL1:PARange to they physical size shift. Limit the size to the maximum supported by the kernel. Cc: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Cc: Marc Zyngier Signed-off-by: Suzuki K Poulose --- arch/arm64/include/asm/cpufeature.h | 16

Re: [PATCH 5/6] rpmsg: Introduce rpmsg_get_rproc_name

On 12/19/2017 9:52 AM, Bjorn Andersson wrote: On Mon 18 Dec 14:02 PST 2017, Chris Lew wrote: Add support for client's to query the edge name their channel is registered for. This is useful for clients who share the same channel identifier across different remote procs. I presume this will

Re: [PATCH 5/6] rpmsg: Introduce rpmsg_get_rproc_name

On 12/19/2017 9:52 AM, Bjorn Andersson wrote: On Mon 18 Dec 14:02 PST 2017, Chris Lew wrote: Add support for client's to query the edge name their channel is registered for. This is useful for clients who share the same channel identifier across different remote procs. I presume this will

[PATCH v1 11/16] kvm: arm64: Make stage2 page table layout dynamic

So far we had a static stage2 page table handling code, based on a fixed IPA of 40bits. As we prepare for a configurable IPA size per VM, make the our stage2 page table code dynamic to do the right thing for a given VM. Support for the IPA size configuration needs other changes in the way we

[PATCH v1 10/16] kvm: arm/arm64: Prepare for VM specific stage2 translations

Right now the stage2 page table for a VM is hard coded, assuming an IPA of 40bits. As we are about to add support for per VM IPA, prepare the stage2 page table helpers to accept the kvm instance to make the right decision. No functional changes. Cc: Marc Zyngier Cc:

[PATCH v1 10/16] kvm: arm/arm64: Prepare for VM specific stage2 translations

Right now the stage2 page table for a VM is hard coded, assuming an IPA of 40bits. As we are about to add support for per VM IPA, prepare the stage2 page table helpers to accept the kvm instance to make the right decision. No functional changes. Cc: Marc Zyngier Cc: Christoffer Dall

[PATCH v1 11/16] kvm: arm64: Make stage2 page table layout dynamic

So far we had a static stage2 page table handling code, based on a fixed IPA of 40bits. As we prepare for a configurable IPA size per VM, make the our stage2 page table code dynamic to do the right thing for a given VM. Support for the IPA size configuration needs other changes in the way we

[PATCH v1 09/16] kvm: arm/arm64: Delay stage2 page table allocation

We allocate the entry level page tables for stage2 when the VM is created. This doesn't give us the flexibility of configuring the physical address space size for a VM. In order to allow the VM to choose the required size, we delay the allocation of stage2 entry level tables until we really try to

[PATCH v1 09/16] kvm: arm/arm64: Delay stage2 page table allocation

We allocate the entry level page tables for stage2 when the VM is created. This doesn't give us the flexibility of configuring the physical address space size for a VM. In order to allow the VM to choose the required size, we delay the allocation of stage2 entry level tables until we really try to

Re: [PATCH 4.14 00/38] 4.14.13-stable review

On Tue, Jan 09, 2018 at 05:45:39AM -0800, Guenter Roeck wrote: > On 01/08/2018 04:58 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.13 release. > > There are 38 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.14 00/38] 4.14.13-stable review

On Tue, Jan 09, 2018 at 05:45:39AM -0800, Guenter Roeck wrote: > On 01/08/2018 04:58 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.13 release. > > There are 38 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 1/4] f2fs: support F2FS_IOC_PRECACHE_EXTENTS

On 01/08, Chao Yu wrote: > This patch introduces a new ioctl F2FS_IOC_PRECACHE_EXTENTS to precache > extent info, in order to gain better performance during data/meta > accessing. > > Signed-off-by: Chao Yu > --- > fs/f2fs/data.c | 27 +++ >

Re: [PATCH 1/4] f2fs: support F2FS_IOC_PRECACHE_EXTENTS

On 01/08, Chao Yu wrote: > This patch introduces a new ioctl F2FS_IOC_PRECACHE_EXTENTS to precache > extent info, in order to gain better performance during data/meta > accessing. > > Signed-off-by: Chao Yu > --- > fs/f2fs/data.c | 27 +++ > fs/f2fs/f2fs.h | 2 ++ >

[PATCH v1 12/16] kvm: arm64: Dynamic configuration of VTCR and VTTBR mask

VTCR_EL2 holds the following key stage2 translation table parameters: SL0 - Entry level in the page table lookup. T0SZ - Denotes the size of the memory addressed by the table. We have been using fixed values for the SL0 depending on the page size as we have a fixed IPA size. But since we are

[PATCH v1 12/16] kvm: arm64: Dynamic configuration of VTCR and VTTBR mask

VTCR_EL2 holds the following key stage2 translation table parameters: SL0 - Entry level in the page table lookup. T0SZ - Denotes the size of the memory addressed by the table. We have been using fixed values for the SL0 depending on the page size as we have a fixed IPA size. But since we are

[PATCH v1 15/16] kvm: arm64: Allow configuring physical address space size

Allow the guests to choose a larger physical address space size. The default and minimum size is 40bits. A guest can change this right after the VM creation, but before the stage2 entry page tables are allocated (i.e, before it registers a memory range or maps a device address). The size is

[PATCH v1 15/16] kvm: arm64: Allow configuring physical address space size

Allow the guests to choose a larger physical address space size. The default and minimum size is 40bits. A guest can change this right after the VM creation, but before the stage2 entry page tables are allocated (i.e, before it registers a memory range or maps a device address). The size is

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