Re: [PATCH] irqchip/gic-v3-its: Fix misplaced __iomem annotations

On 16/02/18 16:57, Robin Murphy wrote: > Save 26 lines worth of Sparse complaints by fixing up this minor > mishap. The pointee lies in the __iomem space; the pointer does not. > > Signed-off-by: Robin Murphy > --- > drivers/irqchip/irq-gic-v3-its.c | 4 ++-- > 1 file

Re: [PATCH] irqchip/gic-v3-its: Fix misplaced __iomem annotations

On 16/02/18 16:57, Robin Murphy wrote: > Save 26 lines worth of Sparse complaints by fixing up this minor > mishap. The pointee lies in the __iomem space; the pointer does not. > > Signed-off-by: Robin Murphy > --- > drivers/irqchip/irq-gic-v3-its.c | 4 ++-- > 1 file changed, 2 insertions(+),

[PATCH] irqchip/gic-v3-its: Fix misplaced __iomem annotations

Save 26 lines worth of Sparse complaints by fixing up this minor mishap. The pointee lies in the __iomem space; the pointer does not. Signed-off-by: Robin Murphy --- drivers/irqchip/irq-gic-v3-its.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] irqchip/gic-v3-its: Fix misplaced __iomem annotations

Save 26 lines worth of Sparse complaints by fixing up this minor mishap. The pointee lies in the __iomem space; the pointer does not. Signed-off-by: Robin Murphy --- drivers/irqchip/irq-gic-v3-its.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: TCP and BBR: reproducibly low cwnd and bandwidth

On Fri, Feb 16, 2018 at 11:26 AM, Holger Hoffstätte wrote: > > BBR in general will run with lower cwnd than e.g. Cubic or others. > That's a feature and necessary for WAN transfers. Please note that there's no general rule about whether BBR will run with a lower or

Re: TCP and BBR: reproducibly low cwnd and bandwidth

On Fri, Feb 16, 2018 at 11:26 AM, Holger Hoffstätte wrote: > > BBR in general will run with lower cwnd than e.g. Cubic or others. > That's a feature and necessary for WAN transfers. Please note that there's no general rule about whether BBR will run with a lower or higher cwnd than CUBIC, Reno,

Re: [PATCH v3] rtc: isl12026: Add driver.

On Thu, Feb 15, 2018 at 9:54 PM, David Daney wrote: > The ISL12026 is a combination RTC and EEPROM device with I2C > interface. The standard RTC driver interface is provided. The EEPROM > is accessed via the NVMEM interface via the "eeprom0" directory in the > sysfs

Re: [PATCH v3] rtc: isl12026: Add driver.

On Thu, Feb 15, 2018 at 9:54 PM, David Daney wrote: > The ISL12026 is a combination RTC and EEPROM device with I2C > interface. The standard RTC driver interface is provided. The EEPROM > is accessed via the NVMEM interface via the "eeprom0" directory in the > sysfs entry for the device. >

Re: [PATCH 4.9 43/92] x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown

Hi, This should use boot_cpu_has_bug(X86_BUG_CPU_MELTDOWN)) - I am preparing patches. Best, Nick

Re: [PATCH 4.9 43/92] x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown

Hi, This should use boot_cpu_has_bug(X86_BUG_CPU_MELTDOWN)) - I am preparing patches. Best, Nick

Re: [PATCH v2 1/2] jump_label: Explicitly disable jump labels in __init code

On 02/16/2018 11:31 AM, Josh Poimboeuf wrote: > After initmem has been freed, any jump label entries in __init code are > prevented from being written to by the kernel_text_address() check in > __jump_label_update(). However, this check is quite broad. If > kernel_text_address() were to return

Re: [PATCH v2 1/2] jump_label: Explicitly disable jump labels in __init code

On 02/16/2018 11:31 AM, Josh Poimboeuf wrote: > After initmem has been freed, any jump label entries in __init code are > prevented from being written to by the kernel_text_address() check in > __jump_label_update(). However, this check is quite broad. If > kernel_text_address() were to return

Re: [PATCH 1/3] tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h

Em Fri, Feb 16, 2018 at 01:52:45PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Mon, Jan 29, 2018 at 02:04:15PM +0530, Ravi Bangoria escreveu: > > Will be used for generating the syscall id/string translation table. > > > > Signed-off-by: Ravi Bangoria > > ---

Re: [PATCH 1/3] tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h

Em Fri, Feb 16, 2018 at 01:52:45PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Mon, Jan 29, 2018 at 02:04:15PM +0530, Ravi Bangoria escreveu: > > Will be used for generating the syscall id/string translation table. > > > > Signed-off-by: Ravi Bangoria > > --- > >

Re: [PATCH 1/4] perf record: Provide detailed information on s390 CPU

Em Tue, Feb 13, 2018 at 04:14:16PM +0100, Thomas Richter escreveu: > When perf record ... is setup to record data, the s390 > cpu information was a fixed string "IBM/S390". > > Replace this string with one containing more information > about the machine. The information included in the cpuid is >

Re: [PATCH 1/4] perf record: Provide detailed information on s390 CPU

Em Tue, Feb 13, 2018 at 04:14:16PM +0100, Thomas Richter escreveu: > When perf record ... is setup to record data, the s390 > cpu information was a fixed string "IBM/S390". > > Replace this string with one containing more information > about the machine. The information included in the cpuid is >

[PATCH][V2] net: dsa: mv88e6xxx: avoid unintended sign extension on a 16 bit shift

From: Colin Ian King The shifting of timehi by 16 bits to the left will be promoted to a 32 bit signed int and then sign-extended to an u64. If the top bit of timehi is set then all then all the upper bits of ns end up as also being set because of the sign-extension.

[PATCH][V2] net: dsa: mv88e6xxx: avoid unintended sign extension on a 16 bit shift

From: Colin Ian King The shifting of timehi by 16 bits to the left will be promoted to a 32 bit signed int and then sign-extended to an u64. If the top bit of timehi is set then all then all the upper bits of ns end up as also being set because of the sign-extension. Fix this by making timehi

Re: [PATCH] PM / wakeirq: Add wakeup name to dedicated wake irqs

* Andy Shevchenko [180216 10:40]: > Sorry, I was thinking that Tony may test it first to see if it does > what he wants. Well using dev_name() for the wakeirq name might still conflict with the device IO interrupt. But yeah I'll give it a try. Regards, Tony

Re: [PATCH] PM / wakeirq: Add wakeup name to dedicated wake irqs

* Andy Shevchenko [180216 10:40]: > Sorry, I was thinking that Tony may test it first to see if it does > what he wants. Well using dev_name() for the wakeirq name might still conflict with the device IO interrupt. But yeah I'll give it a try. Regards, Tony

Re: arm64/v4.16-rc1: KASAN: use-after-free Read in finish_task_switch

Hi, On Thu, Feb 15, 2018 at 10:08:56PM +, Mathieu Desnoyers wrote: > My current theory: do_exit() gets preempted after having set current->mm > to NULL, and after having issued mmput(), which brings the mm_count down > to 0. > > Unfortunately, if the scheduler switches from a userspace thread

Re: [PATCH] i40evf: remove redundant array comparisons to 0 checks

On 16/02/18 16:51, Andy Shevchenko wrote: > On Thu, Feb 15, 2018 at 9:42 PM, Colin King wrote: >> From: Colin Ian King >> >> The checks to see if key->dst.s6_addr and key->src.s6_addr are null >> pointers are redundant because these are

Re: [PATCH] i40evf: remove redundant array comparisons to 0 checks

On 16/02/18 16:51, Andy Shevchenko wrote: > On Thu, Feb 15, 2018 at 9:42 PM, Colin King wrote: >> From: Colin Ian King >> >> The checks to see if key->dst.s6_addr and key->src.s6_addr are null >> pointers are redundant because these are constant size arrays and >> so the checks always return

Re: arm64/v4.16-rc1: KASAN: use-after-free Read in finish_task_switch

Hi, On Thu, Feb 15, 2018 at 10:08:56PM +, Mathieu Desnoyers wrote: > My current theory: do_exit() gets preempted after having set current->mm > to NULL, and after having issued mmput(), which brings the mm_count down > to 0. > > Unfortunately, if the scheduler switches from a userspace thread

Re: Trial of conflict resolution of Alan's patch

On Fri, Feb 16, 2018 at 04:47:04PM +0100, Andrea Parri wrote: > On Fri, Feb 16, 2018 at 10:18:34AM -0500, Alan Stern wrote: > > On Fri, 16 Feb 2018, Akira Yokosawa wrote: > > > > > Hi, > > > > > > My forward-port patch doesn't apply to the "lkmm" branch. > > > It looks like

Re: Trial of conflict resolution of Alan's patch

On Fri, Feb 16, 2018 at 04:47:04PM +0100, Andrea Parri wrote: > On Fri, Feb 16, 2018 at 10:18:34AM -0500, Alan Stern wrote: > > On Fri, 16 Feb 2018, Akira Yokosawa wrote: > > > > > Hi, > > > > > > My forward-port patch doesn't apply to the "lkmm" branch. > > > It looks like

Re: [PATCH 1/3] tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h

Em Mon, Jan 29, 2018 at 02:04:15PM +0530, Ravi Bangoria escreveu: > Will be used for generating the syscall id/string translation table. > > Signed-off-by: Ravi Bangoria > --- > tools/arch/powerpc/include/uapi/asm/unistd.h | 399 > +++ >

Re: [PATCH 1/3] tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h

Em Mon, Jan 29, 2018 at 02:04:15PM +0530, Ravi Bangoria escreveu: > Will be used for generating the syscall id/string translation table. > > Signed-off-by: Ravi Bangoria > --- > tools/arch/powerpc/include/uapi/asm/unistd.h | 399 > +++ > tools/perf/check-headers.sh

Re: [PATCH] i40evf: remove redundant array comparisons to 0 checks

On Thu, Feb 15, 2018 at 9:42 PM, Colin King wrote: > From: Colin Ian King > > The checks to see if key->dst.s6_addr and key->src.s6_addr are null > pointers are redundant because these are constant size arrays and > so the checks always return

Re: [PATCH] i40evf: remove redundant array comparisons to 0 checks

On Thu, Feb 15, 2018 at 9:42 PM, Colin King wrote: > From: Colin Ian King > > The checks to see if key->dst.s6_addr and key->src.s6_addr are null > pointers are redundant because these are constant size arrays and > so the checks always return true. Fix this by removing the redundant > checks.

Re: [PATCH 1/7] sched: Add static_key for asymmetric cpu capacity optimizations

On Fri, Feb 16, 2018 at 03:41:01PM +, Morten Rasmussen wrote: > On Fri, Feb 16, 2018 at 02:47:04PM +0100, Peter Zijlstra wrote: > > On Thu, Feb 15, 2018 at 04:20:48PM +, Morten Rasmussen wrote: > > > +static void update_asym_cpucapacity(int cpu) > > > +{ > > > + if

Re: [PATCH 1/7] sched: Add static_key for asymmetric cpu capacity optimizations

On Fri, Feb 16, 2018 at 03:41:01PM +, Morten Rasmussen wrote: > On Fri, Feb 16, 2018 at 02:47:04PM +0100, Peter Zijlstra wrote: > > On Thu, Feb 15, 2018 at 04:20:48PM +, Morten Rasmussen wrote: > > > +static void update_asym_cpucapacity(int cpu) > > > +{ > > > + if

Re: udev USB autosupend whitelist (was Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version)

+ Benson (and there are probably others that know better answers) Hi, On Fri, Feb 16, 2018 at 09:26:37AM +0100, Hans de Goede wrote: > Going a bit off-topic here, so changed the subject. > I will reply on topic in another mail. > > On 16-02-18 03:27, Brian Norris wrote: > > I use a set of udev

Re: udev USB autosupend whitelist (was Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version)

+ Benson (and there are probably others that know better answers) Hi, On Fri, Feb 16, 2018 at 09:26:37AM +0100, Hans de Goede wrote: > Going a bit off-topic here, so changed the subject. > I will reply on topic in another mail. > > On 16-02-18 03:27, Brian Norris wrote: > > I use a set of udev

[PATCH 2/6] ARM: davinci: update the nand driver names

From: Bartosz Golaszewski Since commit d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock lookup table") we can no longer correctly lookup the nand clock when booting in legacy mode. Said commit added a dev_id to the nand clock which must match and it doesn't

[PATCH 2/6] ARM: davinci: update the nand driver names

From: Bartosz Golaszewski Since commit d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock lookup table") we can no longer correctly lookup the nand clock when booting in legacy mode. Said commit added a dev_id to the nand clock which must match and it doesn't correspond with the device

[PATCH 3/6] memory: aemif: don't rely on kbuild for driver's name

From: Bartosz Golaszewski We want to use aemif from board files. Use a static name in the driver's code. Signed-off-by: Bartosz Golaszewski --- drivers/memory/ti-aemif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 3/6] memory: aemif: don't rely on kbuild for driver's name

From: Bartosz Golaszewski We want to use aemif from board files. Use a static name in the driver's code. Signed-off-by: Bartosz Golaszewski --- drivers/memory/ti-aemif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c

[PATCH 6/6] ARM: davinci: use aemif platform driver in legacy mode for da850-evm

From: Bartosz Golaszewski We now support board files in aemif. Use the platform driver instead of the handcrafted API in da850-evm. Signed-off-by: Bartosz Golaszewski --- arch/arm/mach-davinci/board-da850-evm.c | 93

[PATCH 6/6] ARM: davinci: use aemif platform driver in legacy mode for da850-evm

From: Bartosz Golaszewski We now support board files in aemif. Use the platform driver instead of the handcrafted API in da850-evm. Signed-off-by: Bartosz Golaszewski --- arch/arm/mach-davinci/board-da850-evm.c | 93 ++--- 1 file changed, 51 insertions(+), 42

[PATCH 5/6] ARM: davinci: add aemif & nand support to da850-lcdk in legacy mode

From: Bartosz Golaszewski We now have support for aemif & nand from board files. As an example add support for nand to da850-lcdk in legacy mode. Signed-off-by: Bartosz Golaszewski --- arch/arm/mach-davinci/board-omapl138-hawk.c | 132

[PATCH 5/6] ARM: davinci: add aemif & nand support to da850-lcdk in legacy mode

From: Bartosz Golaszewski We now have support for aemif & nand from board files. As an example add support for nand to da850-lcdk in legacy mode. Signed-off-by: Bartosz Golaszewski --- arch/arm/mach-davinci/board-omapl138-hawk.c | 132 1 file changed, 132

Re: [PATCH v2] ASoC: dmic: Add optional wakeup delay

El Thu, Feb 15, 2018 at 06:47:29PM -0800 Brian Norris ha dit: > Hi, > > On Thu, Feb 15, 2018 at 06:24:16PM -0800, Matthias Kaehlcke wrote: > > On some systems a delay is needed after switching on the clocks, to allow > > the output to stabilize and avoid a popping noise at the beginning of > >

Re: [PATCH v2] ASoC: dmic: Add optional wakeup delay

El Thu, Feb 15, 2018 at 06:47:29PM -0800 Brian Norris ha dit: > Hi, > > On Thu, Feb 15, 2018 at 06:24:16PM -0800, Matthias Kaehlcke wrote: > > On some systems a delay is needed after switching on the clocks, to allow > > the output to stabilize and avoid a popping noise at the beginning of > >

[PATCH 4/6] memory: aemif: add support for board files

From: Bartosz Golaszewski Currently aemif is supported in two places separately. By the platform driver in drivers/memory and by a hand crafted driver in mach-davinci. We want to drop the latter but also keep the legacy mode. Add support for board files to the aemif

[PATCH 4/6] memory: aemif: add support for board files

From: Bartosz Golaszewski Currently aemif is supported in two places separately. By the platform driver in drivers/memory and by a hand crafted driver in mach-davinci. We want to drop the latter but also keep the legacy mode. Add support for board files to the aemif driver. The new structure

Re: [PATCH] objtool/x86: Replace Non-standard Range Expression in Case

On Fri, Feb 16, 2018 at 08:35:11AM -0600, Josh Poimboeuf wrote: > On Fri, Feb 16, 2018 at 07:55:13PM +0530, Progyan Bhattacharya wrote: > > Replace range expressions with seperate individual cases, i.e. convert case > > 1...3: to case 1: case 2: case 3 > > Range expression within case statements

Re: [PATCH] objtool/x86: Replace Non-standard Range Expression in Case

On Fri, Feb 16, 2018 at 08:35:11AM -0600, Josh Poimboeuf wrote: > On Fri, Feb 16, 2018 at 07:55:13PM +0530, Progyan Bhattacharya wrote: > > Replace range expressions with seperate individual cases, i.e. convert case > > 1...3: to case 1: case 2: case 3 > > Range expression within case statements

[PATCH 0/6] ARM: davinci: remove the mach-specific aemif driver - part 1

From: Bartosz Golaszewski Hi Sekhar, while waiting for David's updated series I prepared the first part of changes required to remove duplicate aemif support from mach-davinci. I actually noticed that one of my previous changes from 2017 broke nand in legacy mode -

[PATCH 0/6] ARM: davinci: remove the mach-specific aemif driver - part 1

From: Bartosz Golaszewski Hi Sekhar, while waiting for David's updated series I prepared the first part of changes required to remove duplicate aemif support from mach-davinci. I actually noticed that one of my previous changes from 2017 broke nand in legacy mode - the clock lookup no longer

[PATCH 1/6] nand: davinci: rename the platform driver

From: Bartosz Golaszewski Commit d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock lookup table") broke the nand support in board file mode for da850-based boards. Instead of reverting it and breaking the DT users in the process (due to clock lookup), rename

[PATCH 1/6] nand: davinci: rename the platform driver

From: Bartosz Golaszewski Commit d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock lookup table") broke the nand support in board file mode for da850-based boards. Instead of reverting it and breaking the DT users in the process (due to clock lookup), rename the driver to match the

Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open

2018-02-06 2:20 GMT+01:00 Dmitry Torokhov : > On Mon, Feb 05, 2018 at 11:07:08AM +0100, Christian Gmeiner wrote: >> Hi all. >> >> 2017-04-27 14:22 GMT+02:00 Martin Kepplinger >> : >> > The device could as well be in command mode, in

Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open

2018-02-06 2:20 GMT+01:00 Dmitry Torokhov : > On Mon, Feb 05, 2018 at 11:07:08AM +0100, Christian Gmeiner wrote: >> Hi all. >> >> 2017-04-27 14:22 GMT+02:00 Martin Kepplinger >> : >> > The device could as well be in command mode, in which this driver cannot >> > handle the device. When opening

Re: [PATCH] Staging: wlan-ng: Fix Alignment should match open paranthesis in prism2mgmt.c

On Fri, 2018-02-16 at 15:36 +0100, Greg KH wrote: > On Fri, Feb 16, 2018 at 12:18:36AM +0530, Yash Omer wrote: > > This is patch fixes up a matching paranthesis alignment issue found by > > checkpatch.pl script. [] > > diff --git a/drivers/staging/wlan-ng/prism2mgmt.c > >

Re: [PATCH] Staging: wlan-ng: Fix Alignment should match open paranthesis in prism2mgmt.c

On Fri, 2018-02-16 at 15:36 +0100, Greg KH wrote: > On Fri, Feb 16, 2018 at 12:18:36AM +0530, Yash Omer wrote: > > This is patch fixes up a matching paranthesis alignment issue found by > > checkpatch.pl script. [] > > diff --git a/drivers/staging/wlan-ng/prism2mgmt.c > >

Re: eeepc-wmi loaded on Asus desktop board

+Cc: Darren (for sure) On Fri, Feb 16, 2018 at 12:42 AM, Paul Menzel wrote: > Dear Linux folks, > > > Debugging an ACPI suspend problem on the desktop board Asus F285-M PRO with > Linux 4.14, I noticed, the module *eeepc_wmi* is loaded, and an

Re: eeepc-wmi loaded on Asus desktop board

+Cc: Darren (for sure) On Fri, Feb 16, 2018 at 12:42 AM, Paul Menzel wrote: > Dear Linux folks, > > > Debugging an ACPI suspend problem on the desktop board Asus F285-M PRO with > Linux 4.14, I noticed, the module *eeepc_wmi* is loaded, and an input device > is created. > > ``` > Feb 15 18:49:01

Re: eeepc-wmi loaded on Asus desktop board

+Cc: Darren. On Fri, Feb 16, 2018 at 12:42 AM, Paul Menzel wrote: > Dear Linux folks, > > > Debugging an ACPI suspend problem on the desktop board Asus F285-M PRO with > Linux 4.14, I noticed, the module *eeepc_wmi* is loaded, and an input device

Re: eeepc-wmi loaded on Asus desktop board

+Cc: Darren. On Fri, Feb 16, 2018 at 12:42 AM, Paul Menzel wrote: > Dear Linux folks, > > > Debugging an ACPI suspend problem on the desktop board Asus F285-M PRO with > Linux 4.14, I noticed, the module *eeepc_wmi* is loaded, and an input device > is created. > > ``` > Feb 15 18:49:01

Re: [PATCH] PM / wakeirq: Add wakeup name to dedicated wake irqs

* Rafael J. Wysocki [180216 09:42]: > On Fri, Feb 9, 2018 at 5:14 PM, Tony Lindgren wrote: > > This makes it easy to grep :wakeup /proc/interrupts. > > diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c > > ---

Re: [PATCH] PM / wakeirq: Add wakeup name to dedicated wake irqs

* Rafael J. Wysocki [180216 09:42]: > On Fri, Feb 9, 2018 at 5:14 PM, Tony Lindgren wrote: > > This makes it easy to grep :wakeup /proc/interrupts. > > diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c > > --- a/drivers/base/power/wakeirq.c > > +++

Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open

2018-02-05 11:40 GMT+01:00 Martin Kepplinger : > > > > > Martin Kepplinger | Entwicklung Software > > GINZINGER ELECTRONIC SYSTEMS GMBH > > Tel.: +43 7723 5422 157 > Mail: martin.kepplin...@ginzinger.com > Web: www.ginzinger.com > > > > > On 2018-02-05 11:07,

Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open

2018-02-05 11:40 GMT+01:00 Martin Kepplinger : > > > > > Martin Kepplinger | Entwicklung Software > > GINZINGER ELECTRONIC SYSTEMS GMBH > > Tel.: +43 7723 5422 157 > Mail: martin.kepplin...@ginzinger.com > Web: www.ginzinger.com > > > > > On 2018-02-05 11:07, Christian Gmeiner wrote: >> Hi all. >>

Re: [PATCH] scripts: kernel_doc: fixup reporting of function identifiers

> Am 16.02.2018 um 15:56 schrieb Jonathan Corbet : > > On Tue, 13 Feb 2018 13:31:46 +0200 > Mike Rapoport wrote: > >> When function description includes brackets after the function name as >> suggested by Documentation/doc-guide/kernel-doc, the

Re: [PATCH] scripts: kernel_doc: fixup reporting of function identifiers

> Am 16.02.2018 um 15:56 schrieb Jonathan Corbet : > > On Tue, 13 Feb 2018 13:31:46 +0200 > Mike Rapoport wrote: > >> When function description includes brackets after the function name as >> suggested by Documentation/doc-guide/kernel-doc, the kernel-doc script >> omits the function name from

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

On Fri, 2018-02-16 at 08:29 -0800, Jim Mattson wrote: > On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini wrote: > > > Uhm, taking contents from the hardware is wrong (guess why---live > > migration).  I'll send a revert of those two lines. > > Hardware seems like a

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

On Fri, 2018-02-16 at 08:29 -0800, Jim Mattson wrote: > On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini wrote: > > > Uhm, taking contents from the hardware is wrong (guess why---live > > migration).  I'll send a revert of those two lines. > > Hardware seems like a reasonable place to get the

Re: [PATCH] staging: ashmem: Fix lockdep issue during llseek

On Mon, Feb 12, 2018 at 05:01:25PM -0800, Joel Fernandes wrote: > ashmem_mutex create a chain of dependencies like so: > > (1) > mmap syscall -> > mmap_sem -> (acquired) > ashmem_mmap > ashmem_mutex (try to acquire) > (block) > > (2) > llseek syscall -> > ashmem_llseek -> >

Re: [PATCH] staging: ashmem: Fix lockdep issue during llseek

On Mon, Feb 12, 2018 at 05:01:25PM -0800, Joel Fernandes wrote: > ashmem_mutex create a chain of dependencies like so: > > (1) > mmap syscall -> > mmap_sem -> (acquired) > ashmem_mmap > ashmem_mutex (try to acquire) > (block) > > (2) > llseek syscall -> > ashmem_llseek -> >

Re: [PATCH 1/3] x86/Kconfig : Add missing i586-class cpus to X86_CMPXCHG64 Kconfig group

On Fri, Feb 16, 2018 at 5:08 PM, tedheadster wrote: > On Fri, Feb 16, 2018 at 9:17 AM, Andy Shevchenko > wrote: >> On Thu, Feb 15, 2018 at 6:54 PM, Matthew Whitehead >> wrote: >>> Several i586-class cpus supporting this

Re: [PATCH 1/3] x86/Kconfig : Add missing i586-class cpus to X86_CMPXCHG64 Kconfig group

On Fri, Feb 16, 2018 at 5:08 PM, tedheadster wrote: > On Fri, Feb 16, 2018 at 9:17 AM, Andy Shevchenko > wrote: >> On Thu, Feb 15, 2018 at 6:54 PM, Matthew Whitehead >> wrote: >>> Several i586-class cpus supporting this instruction are missing from >>> the X86_CMPXCHG64 config group. >> >> What

[PATCH v2 0/2] jump_label: Robustify jump label patching

v2: - Refine the warning so that it doesn't warn about __init entries - (Do so by explicitly disabling __init entries) - Drop v1 patches which removed __init tracepoints Josh Poimboeuf (2): jump_label: Explicitly disable jump labels in __init code jump_label: Warn on failed jump_label patch

[PATCH v2 0/2] jump_label: Robustify jump label patching

v2: - Refine the warning so that it doesn't warn about __init entries - (Do so by explicitly disabling __init entries) - Drop v1 patches which removed __init tracepoints Josh Poimboeuf (2): jump_label: Explicitly disable jump labels in __init code jump_label: Warn on failed jump_label patch

[PATCH v2 1/2] jump_label: Explicitly disable jump labels in __init code

After initmem has been freed, any jump label entries in __init code are prevented from being written to by the kernel_text_address() check in __jump_label_update(). However, this check is quite broad. If kernel_text_address() were to return false for any other reason, the jump label write would

[PATCH v2 1/2] jump_label: Explicitly disable jump labels in __init code

After initmem has been freed, any jump label entries in __init code are prevented from being written to by the kernel_text_address() check in __jump_label_update(). However, this check is quite broad. If kernel_text_address() were to return false for any other reason, the jump label write would

[PATCH v2 2/2] jump_label: Warn on failed jump_label patch

When the jump label code encounters an address which isn't recognized by kernel_text_address(), it just silently fails. This can be dangerous because jump labels are used in a variety of places, and are generally expected to work. Convert the silent failure to a warning. This won't warn about

[PATCH v2 2/2] jump_label: Warn on failed jump_label patch

When the jump label code encounters an address which isn't recognized by kernel_text_address(), it just silently fails. This can be dangerous because jump labels are used in a variety of places, and are generally expected to work. Convert the silent failure to a warning. This won't warn about

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini wrote: > Uhm, taking contents from the hardware is wrong (guess why---live > migration). I'll send a revert of those two lines. Hardware seems like a reasonable place to get the default value (cf. the VMX capability MSRs).

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini wrote: > Uhm, taking contents from the hardware is wrong (guess why---live > migration). I'll send a revert of those two lines. Hardware seems like a reasonable place to get the default value (cf. the VMX capability MSRs). Should these two lines

Re: [PATCH v2 5/9] staging: android: ion: Remove lable debugfs_done

On Mon, Feb 12, 2018 at 06:43:10PM +0800, Yisheng Xie wrote: > When failed to create debug_root, we will go on initail other part of > ion, so we can just info this message to user and do not need a lable > to jump. > > Acked-by: Laura Abbott > Signed-off-by: Yisheng Xie

Re: [PATCH v2 5/9] staging: android: ion: Remove lable debugfs_done

On Mon, Feb 12, 2018 at 06:43:10PM +0800, Yisheng Xie wrote: > When failed to create debug_root, we will go on initail other part of > ion, so we can just info this message to user and do not need a lable > to jump. > > Acked-by: Laura Abbott > Signed-off-by: Yisheng Xie > --- >

Re: [PATCH v2 4/9] staging: android: ion: Avoid NULL point in error path

On Mon, Feb 12, 2018 at 06:43:09PM +0800, Yisheng Xie wrote: > If we failed to create debugfs for ion at ion_device_create, the > debug_root of ion_device will be NULL, and then when try to create debug > file for shrinker of heap it will be create on the top of debugfs. If we > also failed to

Re: [PATCH v2 4/9] staging: android: ion: Avoid NULL point in error path

On Mon, Feb 12, 2018 at 06:43:09PM +0800, Yisheng Xie wrote: > If we failed to create debugfs for ion at ion_device_create, the > debug_root of ion_device will be NULL, and then when try to create debug > file for shrinker of heap it will be create on the top of debugfs. If we > also failed to

Re: TCP and BBR: reproducibly low cwnd and bandwidth

On 02/16/18 16:15, Oleksandr Natalenko wrote: > Hi, David, Eric, Neal et al. > > On čtvrtek 15. února 2018 21:42:26 CET Oleksandr Natalenko wrote: >> I've faced an issue with a limited TCP bandwidth between my laptop and a >> server in my 1 Gbps LAN while using BBR as a congestion control

Re: TCP and BBR: reproducibly low cwnd and bandwidth

On 02/16/18 16:15, Oleksandr Natalenko wrote: > Hi, David, Eric, Neal et al. > > On čtvrtek 15. února 2018 21:42:26 CET Oleksandr Natalenko wrote: >> I've faced an issue with a limited TCP bandwidth between my laptop and a >> server in my 1 Gbps LAN while using BBR as a congestion control

Re: TCP and BBR: reproducibly low cwnd and bandwidth

On Fri, Feb 16, 2018 at 7:15 AM, Oleksandr Natalenko wrote: > Hi, David, Eric, Neal et al. > > On čtvrtek 15. února 2018 21:42:26 CET Oleksandr Natalenko wrote: >> I've faced an issue with a limited TCP bandwidth between my laptop and a >> server in my 1 Gbps LAN while

Re: TCP and BBR: reproducibly low cwnd and bandwidth

On Fri, Feb 16, 2018 at 7:15 AM, Oleksandr Natalenko wrote: > Hi, David, Eric, Neal et al. > > On čtvrtek 15. února 2018 21:42:26 CET Oleksandr Natalenko wrote: >> I've faced an issue with a limited TCP bandwidth between my laptop and a >> server in my 1 Gbps LAN while using BBR as a congestion

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

2018-02-15 20:02 GMT+00:00 Andy Lutomirski : > On Thu, Feb 15, 2018 at 4:36 PM, Nadav Amit wrote: >> Based on the understanding that there should be no way for userspace to >> address the kernel-space from compatibility mode, disable it while >> running in

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

2018-02-15 20:02 GMT+00:00 Andy Lutomirski : > On Thu, Feb 15, 2018 at 4:36 PM, Nadav Amit wrote: >> Based on the understanding that there should be no way for userspace to >> address the kernel-space from compatibility mode, disable it while >> running in compatibility mode as long as the 64-bit

Re: [PATCH] staging: android: ion: Initialize dma_address of new sg list

On Fri, Feb 09, 2018 at 10:16:56PM -0800, Liam Mark wrote: > Fix the dup_sg_table function to initialize the dma_address of the new > sg list entries instead of the source dma_address entries. > > Fixes: 17fd283f3870 ("staging: android: ion: Duplicate sg_table") So this should be sent to the

Re: [PATCH] staging: android: ion: Initialize dma_address of new sg list

On Fri, Feb 09, 2018 at 10:16:56PM -0800, Liam Mark wrote: > Fix the dup_sg_table function to initialize the dma_address of the new > sg list entries instead of the source dma_address entries. > > Fixes: 17fd283f3870 ("staging: android: ion: Duplicate sg_table") So this should be sent to the

Re: [PATCH] arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump

Hi AKASHI, Thank you for the patch! Yet something to improve: [auto build test ERROR on arm64/for-next/core] [also build test ERROR on v4.16-rc1 next-20180216] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

Re: [PATCH] arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump

Hi AKASHI, Thank you for the patch! Yet something to improve: [auto build test ERROR on arm64/for-next/core] [also build test ERROR on v4.16-rc1 next-20180216] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

[PATCH] proc: move /proc/sysvipc creation to where it belongs

Signed-off-by: Alexey Dobriyan --- fs/proc/root.c |4 ipc/util.c |1 + 2 files changed, 1 insertion(+), 4 deletions(-) --- a/fs/proc/root.c +++ b/fs/proc/root.c @@ -136,10 +136,6 @@ void __init proc_root_init(void) proc_symlink("mounts", NULL,

[PATCH] proc: move /proc/sysvipc creation to where it belongs

Signed-off-by: Alexey Dobriyan --- fs/proc/root.c |4 ipc/util.c |1 + 2 files changed, 1 insertion(+), 4 deletions(-) --- a/fs/proc/root.c +++ b/fs/proc/root.c @@ -136,10 +136,6 @@ void __init proc_root_init(void) proc_symlink("mounts", NULL, "self/mounts");

Re: [PATCH 4/6] scripts: kernel-doc: support in-line comments on nested structs/unions

> Am 16.02.2018 um 15:56 schrieb Mauro Carvalho Chehab > : > > Em Fri, 16 Feb 2018 15:52:33 +0100 > Markus Heiser escreveu: > >>> Am 16.02.2018 um 14:48 schrieb Mauro Carvalho Chehab >>> : >>> >>> The parser at

Re: [PATCH 4/6] scripts: kernel-doc: support in-line comments on nested structs/unions

> Am 16.02.2018 um 15:56 schrieb Mauro Carvalho Chehab > : > > Em Fri, 16 Feb 2018 15:52:33 +0100 > Markus Heiser escreveu: > >>> Am 16.02.2018 um 14:48 schrieb Mauro Carvalho Chehab >>> : >>> >>> The parser at kernel-doc rejects names with dots in the middle. >>> Fix it, in order to

Re: [patch 1/2] mm, page_alloc: extend kernelcore and movablecore for percent

On Fri, 16 Feb 2018, Matthew Wilcox wrote: > On Fri, Feb 16, 2018 at 09:44:25AM -0600, Christopher Lameter wrote: > > On Thu, 15 Feb 2018, Matthew Wilcox wrote: > > > What I was proposing was an intermediate page allocator where slab would > > > request 2MB for its own uses all at once, then

Re: [patch 1/2] mm, page_alloc: extend kernelcore and movablecore for percent

On Fri, 16 Feb 2018, Matthew Wilcox wrote: > On Fri, Feb 16, 2018 at 09:44:25AM -0600, Christopher Lameter wrote: > > On Thu, 15 Feb 2018, Matthew Wilcox wrote: > > > What I was proposing was an intermediate page allocator where slab would > > > request 2MB for its own uses all at once, then

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