[PATCH v3 1/3] PCI/AER: factor out error reporting from AER

This patch factors out error reporting callbacks, which are currently tightly coupled with AER. DPC should be able to call these callbacks when DPC trigger event occurs. Signed-off-by: Oza Pawandeep diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index

[PATCH v3 1/3] PCI/AER: factor out error reporting from AER

This patch factors out error reporting callbacks, which are currently tightly coupled with AER. DPC should be able to call these callbacks when DPC trigger event occurs. Signed-off-by: Oza Pawandeep diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 6402f7f..fd053e5 100644

[PATCH v3 2/3] PCI/DPC: Unify and plumb error handling into DPC

Current DPC driver does not do recovery, e.g. calling end-point's driver's callbacks, which sanitize the sw. DPC driver implements link_reset callback, and calls pci_do_recovery. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pcie/pcie-dpc.c

[PATCH v3 2/3] PCI/DPC: Unify and plumb error handling into DPC

Current DPC driver does not do recovery, e.g. calling end-point's driver's callbacks, which sanitize the sw. DPC driver implements link_reset callback, and calls pci_do_recovery. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c index

[PATCH v3 3/3] PCI/DPC: Enumerate the devices after DPC trigger event

Implement error_resume callback in DPC, which, after DPC trigger event enumerates the devices beneath. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c index 68296ec..4c6bef3 100644 --- a/drivers/pci/pcie/pcie-dpc.c +++

[PATCH v3 3/3] PCI/DPC: Enumerate the devices after DPC trigger event

Implement error_resume callback in DPC, which, after DPC trigger event enumerates the devices beneath. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c index 68296ec..4c6bef3 100644 --- a/drivers/pci/pcie/pcie-dpc.c +++

[PATCH v3 0/4] Address error and recovery for AER and DPC

This patch set brings in error handling support for DPC The current implementation of AER and error message broadcasting to the EP driver is tightly coupled and limited to AER service driver. It is important to factor out broadcasting and other link handling callbacks. So that not only when AER

[PATCH v3 0/4] Address error and recovery for AER and DPC

This patch set brings in error handling support for DPC The current implementation of AER and error message broadcasting to the EP driver is tightly coupled and limited to AER service driver. It is important to factor out broadcasting and other link handling callbacks. So that not only when AER

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

On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > >

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

On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > >

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

On Sun, Jan 07, 2018 at 10:06:59AM -0500, Pavel Tatashin wrote: > Hi Greg, > > I reverted suse12 back to: > 13dae54cb229d078635f159dd8afe16ae683980b > x86/kaiser: Move feature detection up (bsc#1068032). > > And, still do not see the problem. So, whatever fixes the issue comes > before kaiser.

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

On Sun, Jan 07, 2018 at 10:06:59AM -0500, Pavel Tatashin wrote: > Hi Greg, > > I reverted suse12 back to: > 13dae54cb229d078635f159dd8afe16ae683980b > x86/kaiser: Move feature detection up (bsc#1068032). > > And, still do not see the problem. So, whatever fixes the issue comes > before kaiser.

Re: [PATCH v5 2/7] scsi: libsas: shut down the PHY if events reached the threshold

On 12/15/2017 01:18 PM, Hannes Reinecke wrote: > On 12/08/2017 10:42 AM, Jason Yan wrote: >> If the PHY burst too many events, we will alloc a lot of events for the >> worker. This may leads to memory exhaustion. >> >> Dan Williams suggested to shut down the PHY if the events reached the >>

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

On Sun, Jan 07, 2018 at 09:23:47PM -0500, David Miller wrote: > From: Thomas Gleixner > Date: Sun, 7 Jan 2018 21:56:39 +0100 (CET) > > > I surely agree, but we have gone the way of PTI without the ability of > > exempting individual processes exactly for one reason: > > > >

Re: [PATCH v5 2/7] scsi: libsas: shut down the PHY if events reached the threshold

On 12/15/2017 01:18 PM, Hannes Reinecke wrote: > On 12/08/2017 10:42 AM, Jason Yan wrote: >> If the PHY burst too many events, we will alloc a lot of events for the >> worker. This may leads to memory exhaustion. >> >> Dan Williams suggested to shut down the PHY if the events reached the >>

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

On Sun, Jan 07, 2018 at 09:23:47PM -0500, David Miller wrote: > From: Thomas Gleixner > Date: Sun, 7 Jan 2018 21:56:39 +0100 (CET) > > > I surely agree, but we have gone the way of PTI without the ability of > > exempting individual processes exactly for one reason: > > > > Lack of time > >

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

On Sun, 2018-01-07 at 08:12 -0200, Mauro Carvalho Chehab wrote: > Em Fri, 05 Jan 2018 20:41:41 +0100 > Knut Omang escreveu: > > > On Fri, 2018-01-05 at 16:08 -0200, Mauro Carvalho Chehab wrote: > > > Em Thu, 04 Jan 2018 21:15:31 +0100 > > > Knut Omang

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

On Sun, 2018-01-07 at 08:12 -0200, Mauro Carvalho Chehab wrote: > Em Fri, 05 Jan 2018 20:41:41 +0100 > Knut Omang escreveu: > > > On Fri, 2018-01-05 at 16:08 -0200, Mauro Carvalho Chehab wrote: > > > Em Thu, 04 Jan 2018 21:15:31 +0100 > > > Knut Omang escreveu: > > > > > > > > I'm surprised

[PATCH 0/2] pinctrl: meson: use one uniform 'function' name

These two patches are general improvement for meson pinctrl driver. It make the two pinctrl trees (ee/ao) to share one uniform 'function' name for one hardware block even its pin groups live inside two differet hardware domains, which for example EE vs AO domain here. This idea is motivated by

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

On Mon, 8 Jan 2018, Dominik Brodowski wrote: > On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote: > > As the meltdown/spectre problem affects several CPU architectures, it makes > > sense to have common way to express whether a system is affected by a > > particular vulnerability or

[PATCH 0/2] pinctrl: meson: use one uniform 'function' name

These two patches are general improvement for meson pinctrl driver. It make the two pinctrl trees (ee/ao) to share one uniform 'function' name for one hardware block even its pin groups live inside two differet hardware domains, which for example EE vs AO domain here. This idea is motivated by

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

On Mon, 8 Jan 2018, Dominik Brodowski wrote: > On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote: > > As the meltdown/spectre problem affects several CPU architectures, it makes > > sense to have common way to express whether a system is affected by a > > particular vulnerability or

[PATCH 1/2] pinctrl: meson: introduce a macro to have name/groups seperated

We introduce a macro FUNCTION_EX here, the main motivation is trying to have the possibility to expand the macro with the same of the '.name' number but different multiple '.groups/.num_groups' numbers. With this change, the meson pinctrl drivr is capable of have one uniform 'function' name but

[PATCH 1/2] pinctrl: meson: introduce a macro to have name/groups seperated

We introduce a macro FUNCTION_EX here, the main motivation is trying to have the possibility to expand the macro with the same of the '.name' number but different multiple '.groups/.num_groups' numbers. With this change, the meson pinctrl drivr is capable of have one uniform 'function' name but

[PATCH 2/2] pinctrl: meson-axg: correct the pin expansion of UART_AO_B

The 'uart_ao_b_groups' for the UART_AO_B pins is already defined which is living inside the AO domain, for these pins which are routed out from EE domain, we need to correct them with the 'FUNCTION_EX' macro, otherwise there is a conflict in the code level. Also slightly adjust the name to make

[PATCH 2/2] pinctrl: meson-axg: correct the pin expansion of UART_AO_B

The 'uart_ao_b_groups' for the UART_AO_B pins is already defined which is living inside the AO domain, for these pins which are routed out from EE domain, we need to correct them with the 'FUNCTION_EX' macro, otherwise there is a conflict in the code level. Also slightly adjust the name to make

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote: > As the meltdown/spectre problem affects several CPU architectures, it makes > sense to have common way to express whether a system is affected by a > particular vulnerability or not. If affected the way to express the > mitigation

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote: > As the meltdown/spectre problem affects several CPU architectures, it makes > sense to have common way to express whether a system is affected by a > particular vulnerability or not. If affected the way to express the > mitigation

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

>> @@ -708,11 +708,11 @@ static void svc_addr(struct seq_file *seq, struct >> sockaddr_atmsvc *addr) >> static int e164[] = { 1, 8, 4, 6, 1, 0 }; >> >> if (*addr->sas_addr.pub) { >> - seq_printf(seq, "%s", addr->sas_addr.pub); >> + seq_puts(seq,

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

>> @@ -708,11 +708,11 @@ static void svc_addr(struct seq_file *seq, struct >> sockaddr_atmsvc *addr) >> static int e164[] = { 1, 8, 4, 6, 1, 0 }; >> >> if (*addr->sas_addr.pub) { >> - seq_printf(seq, "%s", addr->sas_addr.pub); >> + seq_puts(seq,

Re: [v2,03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3

On Fri, Jan 05, 2018 at 01:12:33PM +, Will Deacon wrote: > For non-KASLR kernels where the KPTI behaviour has not been overridden > on the command line we can use ID_AA64PFR0_EL1.CSV3 to determine whether > or not we should unmap the kernel whilst running at EL0. > > Reviewed-by: Suzuki K

Re: [v2,03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3

On Fri, Jan 05, 2018 at 01:12:33PM +, Will Deacon wrote: > For non-KASLR kernels where the KPTI behaviour has not been overridden > on the command line we can use ID_AA64PFR0_EL1.CSV3 to determine whether > or not we should unmap the kernel whilst running at EL0. > > Reviewed-by: Suzuki K

Re: [PATCH v2 3/6] clocksource/drivers: atmel-pit: allow unselecting ATMEL_PIT

On 07/01/2018 19:44, Alexandre Belloni wrote: > On 07/01/2018 at 19:07:13 +0100, Daniel Lezcano wrote: >> On 05/01/2018 15:30, Alexandre Belloni wrote: >>> With the new TCB clocksource driver, atmel platforms are now able to boot >>> without the PIT driver. Allow unselecting it. >>> >>>

Re: [PATCH v2 3/6] clocksource/drivers: atmel-pit: allow unselecting ATMEL_PIT

On 07/01/2018 19:44, Alexandre Belloni wrote: > On 07/01/2018 at 19:07:13 +0100, Daniel Lezcano wrote: >> On 05/01/2018 15:30, Alexandre Belloni wrote: >>> With the new TCB clocksource driver, atmel platforms are now able to boot >>> without the PIT driver. Allow unselecting it. >>> >>>

Re: Linux 4.15-rc7

Linus, On Sun, 7 Jan 2018, Linus Torvalds wrote: > The one thing I want to do now that Meltdown and Spectre are public, > is to give a *big* shout-out to the x86 people, and Thomas Gleixner in > particular for really being on top of this. It's been one huge > annoyance, and honestly, Thomas

Re: Linux 4.15-rc7

Linus, On Sun, 7 Jan 2018, Linus Torvalds wrote: > The one thing I want to do now that Meltdown and Spectre are public, > is to give a *big* shout-out to the x86 people, and Thomas Gleixner in > particular for really being on top of this. It's been one huge > annoyance, and honestly, Thomas

[PATCH 2/2] arm64: Branch predictor hardening for Cavium ThunderX2

Use PSCI based mitigation for speculative execution attacks targeting the branch predictor. The approach is similar to the one used for Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to test if the firmware supports the capability. If the secure firmware has been updated with the

[PATCH 2/2] arm64: Branch predictor hardening for Cavium ThunderX2

Use PSCI based mitigation for speculative execution attacks targeting the branch predictor. The approach is similar to the one used for Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to test if the firmware supports the capability. If the secure firmware has been updated with the

[PATCH 1/2] arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs

Add the older Broadcom ID as well as the new Cavium ID for ThunderX2 CPUs. Signed-off-by: Jayachandran C --- arch/arm64/include/asm/cputype.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h

[PATCH 1/2] arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs

Add the older Broadcom ID as well as the new Cavium ID for ThunderX2 CPUs. Signed-off-by: Jayachandran C --- arch/arm64/include/asm/cputype.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index 84385b9..cce5735 100644

Re: [patch V2 2/2] x86/cpu: Implement CPU vulnerabilites sysfs functions

On Sun, Jan 07, 2018 at 10:48:01PM +0100, Thomas Gleixner wrote: > Implement the CPU vulnerabilty show functions for meltdown, spectre_v1 and > spectre_v2. > > Signed-off-by: Thomas Gleixner > --- > arch/x86/Kconfig |1 + > arch/x86/kernel/cpu/bugs.c | 29

Re: [patch V2 2/2] x86/cpu: Implement CPU vulnerabilites sysfs functions

On Sun, Jan 07, 2018 at 10:48:01PM +0100, Thomas Gleixner wrote: > Implement the CPU vulnerabilty show functions for meltdown, spectre_v1 and > spectre_v2. > > Signed-off-by: Thomas Gleixner > --- > arch/x86/Kconfig |1 + > arch/x86/kernel/cpu/bugs.c | 29

Re: [PATCH v2] x86: xen: remove the use of VLAIS

On 06/01/18 22:39, Nick Desaulniers wrote: > Variable Length Arrays In Structs (VLAIS) is not supported by Clang, and > frowned upon by others. > > https://lkml.org/lkml/2013/9/23/500 > > Here, the VLAIS was used because the size of the bitmap returned from > xen_mc_entry() depended on possibly

Re: [PATCH v2] x86: xen: remove the use of VLAIS

On 06/01/18 22:39, Nick Desaulniers wrote: > Variable Length Arrays In Structs (VLAIS) is not supported by Clang, and > frowned upon by others. > > https://lkml.org/lkml/2013/9/23/500 > > Here, the VLAIS was used because the size of the bitmap returned from > xen_mc_entry() depended on possibly

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote: > As the meltdown/spectre problem affects several CPU architectures, it makes > sense to have common way to express whether a system is affected by a > particular vulnerability or not. If affected the way to express the > mitigation

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote: > As the meltdown/spectre problem affects several CPU architectures, it makes > sense to have common way to express whether a system is affected by a > particular vulnerability or not. If affected the way to express the > mitigation

[PATCH] iio: adc: aspeed: Fix error handling path

The labels and branching order of the error path of 'aspeed_adc_probe()' are broken. Re-order the labels and goto statements. Signed-off-by: Christophe JAILLET --- Not sure where it comes from. Merge conflict incorrectly fixed? --- drivers/iio/adc/aspeed_adc.c | 7

[PATCH] iio: adc: aspeed: Fix error handling path

The labels and branching order of the error path of 'aspeed_adc_probe()' are broken. Re-order the labels and goto statements. Signed-off-by: Christophe JAILLET --- Not sure where it comes from. Merge conflict incorrectly fixed? --- drivers/iio/adc/aspeed_adc.c | 7 --- 1 file changed, 4

RE: [PATCH] KVM: VMX: use same MSR bitmaps for 32-/64-bit modes, fix MSR bitmaps for processor tracing

> -Original Message- > From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo > Bonzini > Sent: Friday, January 5, 2018 11:43 PM > To: linux-kernel@vger.kernel.org; k...@vger.kernel.org > Cc: Kang, Luwei > Subject: [PATCH] KVM: VMX: use same MSR

RE: [PATCH] KVM: VMX: use same MSR bitmaps for 32-/64-bit modes, fix MSR bitmaps for processor tracing

> -Original Message- > From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo > Bonzini > Sent: Friday, January 5, 2018 11:43 PM > To: linux-kernel@vger.kernel.org; k...@vger.kernel.org > Cc: Kang, Luwei > Subject: [PATCH] KVM: VMX: use same MSR bitmaps for 32-/64-bit

Re: [PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description

HI Martin: On 01/08/18 14:07, Yixun Lan wrote: > Hi Martin > > On 01/08/18 04:19, Martin Blumenstingl wrote: >> Hi Yixun, >> >> On Sat, Jan 6, 2018 at 1:10 AM, Yixun Lan wrote: >>> Describe the pinctrl info for the UART controller which is found >>> in the Meson-AXG SoCs.

Re: [PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description

HI Martin: On 01/08/18 14:07, Yixun Lan wrote: > Hi Martin > > On 01/08/18 04:19, Martin Blumenstingl wrote: >> Hi Yixun, >> >> On Sat, Jan 6, 2018 at 1:10 AM, Yixun Lan wrote: >>> Describe the pinctrl info for the UART controller which is found >>> in the Meson-AXG SoCs. >>> >>> Signed-off-by:

Re: [PATCH 4/7] pipe: fix off-by-one error when checking buffer limits

On Sun, Jan 07, 2018 at 09:35:39PM -0800, Eric Biggers wrote: > From: Eric Biggers > > With pipe-user-pages-hard set to 'N', users were actually only allowed > up to 'N - 1' buffers; and likewise for pipe-user-pages-soft. > > Fix this to allow up to 'N' buffers, as would be

Re: [PATCH 4/7] pipe: fix off-by-one error when checking buffer limits

On Sun, Jan 07, 2018 at 09:35:39PM -0800, Eric Biggers wrote: > From: Eric Biggers > > With pipe-user-pages-hard set to 'N', users were actually only allowed > up to 'N - 1' buffers; and likewise for pipe-user-pages-soft. > > Fix this to allow up to 'N' buffers, as would be expected.

Re: [PATCH V2 1/5] bindings: regulator: added support for suspend states

On 6 January 2018 at 03:18, Mark Brown wrote: > On Fri, Jan 05, 2018 at 12:53:28PM -0600, Rob Herring wrote: >> On Thu, Jan 04, 2018 at 03:22:44PM +0800, Chunyan Zhang wrote: > >> > + - regulator-suspend-microvolt: the default voltage which regulator >> > + would be set

Re: [PATCH V2 1/5] bindings: regulator: added support for suspend states

On 6 January 2018 at 03:18, Mark Brown wrote: > On Fri, Jan 05, 2018 at 12:53:28PM -0600, Rob Herring wrote: >> On Thu, Jan 04, 2018 at 03:22:44PM +0800, Chunyan Zhang wrote: > >> > + - regulator-suspend-microvolt: the default voltage which regulator >> > + would be set in suspend. The

Re: [PATCH] trace_uprobe: Display correct offset in uprobe_events

On Mon, Jan 08, 2018 at 12:01:04PM +0530, Ravi Bangoria wrote: > > > On 01/08/2018 10:49 AM, Srikar Dronamraju wrote: > > * Ravi Bangoria [2018-01-06 11:12:46]: > > > >> Recently, how the pointers being printed with %p has been changed > >> by commit

Re: [PATCH] trace_uprobe: Display correct offset in uprobe_events

On Mon, Jan 08, 2018 at 12:01:04PM +0530, Ravi Bangoria wrote: > > > On 01/08/2018 10:49 AM, Srikar Dronamraju wrote: > > * Ravi Bangoria [2018-01-06 11:12:46]: > > > >> Recently, how the pointers being printed with %p has been changed > >> by commit ad67b74d2469 ("printk: hash addresses

RE: WARNING: CPU: 0 PID: 0 at ./include/linux/netfilter.h:233 arp_rcv

From: Marco Franchi Sent: Friday, January 05, 2018 11:03 PM >Hi, > >I am getting the following warning on a imx6ul-evk board running linux-next >20180105: > >[9.233290] [ cut here ] >[9.242068] WARNING: CPU: 0 PID: 0 at

RE: WARNING: CPU: 0 PID: 0 at ./include/linux/netfilter.h:233 arp_rcv

From: Marco Franchi Sent: Friday, January 05, 2018 11:03 PM >Hi, > >I am getting the following warning on a imx6ul-evk board running linux-next >20180105: > >[9.233290] [ cut here ] >[9.242068] WARNING: CPU: 0 PID: 0 at >./include/linux/netfilter.h:233

Re: [v2, 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs

On Fri, Jan 05, 2018 at 01:12:41PM +, Will Deacon wrote: > Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing > and can theoretically be attacked by malicious code. > > This patch implements a PSCI-based mitigation for these CPUs when available. > The call into firmware

Re: [v2, 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs

On Fri, Jan 05, 2018 at 01:12:41PM +, Will Deacon wrote: > Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing > and can theoretically be attacked by malicious code. > > This patch implements a PSCI-based mitigation for these CPUs when available. > The call into firmware

Re: [PATCH] trace_uprobe: Display correct offset in uprobe_events

On 01/08/2018 10:49 AM, Srikar Dronamraju wrote: > * Ravi Bangoria [2018-01-06 11:12:46]: > >> Recently, how the pointers being printed with %p has been changed >> by commit ad67b74d2469 ("printk: hash addresses printed with %p"). >> This is causing a

Re: [PATCH] trace_uprobe: Display correct offset in uprobe_events

On 01/08/2018 10:49 AM, Srikar Dronamraju wrote: > * Ravi Bangoria [2018-01-06 11:12:46]: > >> Recently, how the pointers being printed with %p has been changed >> by commit ad67b74d2469 ("printk: hash addresses printed with %p"). >> This is causing a regression while showing offset in the >>

Re: [PATCHv3 0/2] capability controlled user-namespaces

On Mon, Jan 08, 2018 at 11:35:26AM +1100, James Morris wrote: > On Tue, 2 Jan 2018, Mahesh Bandewar (महेश बंडेवार) wrote: > > > On Sat, Dec 30, 2017 at 12:31 AM, James Morris > > wrote: > > > On Wed, 27 Dec 2017, Mahesh Bandewar (महेश बंडेवार) wrote: > > > > > >> Hello

Re: [PATCHv3 0/2] capability controlled user-namespaces

On Mon, Jan 08, 2018 at 11:35:26AM +1100, James Morris wrote: > On Tue, 2 Jan 2018, Mahesh Bandewar (महेश बंडेवार) wrote: > > > On Sat, Dec 30, 2017 at 12:31 AM, James Morris > > wrote: > > > On Wed, 27 Dec 2017, Mahesh Bandewar (महेश बंडेवार) wrote: > > > > > >> Hello James, > > >> > > >> Seems

[RESEND PATCH v3 2/2] sched/deadline: Initialize cp->elements[].cpu to an invalid value

Currently, migrating tasks to cpu0 unconditionally happens when the heap is empty, since cp->elements[].cpu was initialized to 0(=cpu0). We have to distinguish between the empty case and cpu0 to avoid the unnecessary migrations. Therefore, it has to return an invalid value e.i. -1 in that case.

[RESEND PATCH v11 2/2] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

It would be better to try to check other siblings first if SD_PREFER_SIBLING is flaged when pushing tasks - migration. Suggested-by: Peter Zijlstra Signed-off-by: Byungchul Park Reviewed-by: Steven Rostedt (VMware) ---

[RESEND PATCH v3 2/2] sched/deadline: Initialize cp->elements[].cpu to an invalid value

Currently, migrating tasks to cpu0 unconditionally happens when the heap is empty, since cp->elements[].cpu was initialized to 0(=cpu0). We have to distinguish between the empty case and cpu0 to avoid the unnecessary migrations. Therefore, it has to return an invalid value e.i. -1 in that case.

[RESEND PATCH v11 2/2] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

It would be better to try to check other siblings first if SD_PREFER_SIBLING is flaged when pushing tasks - migration. Suggested-by: Peter Zijlstra Signed-off-by: Byungchul Park Reviewed-by: Steven Rostedt (VMware) --- kernel/sched/rt.c | 80

[RESEND PATCH v11 0/2] Make find_later_rq() choose a closer cpu in topology

Change from v10 -. modify a comment a bit as Steven suggested Change from v9 -. modify a comment a bit so to be more clear as Juri suggested Change from v8 -. add suggested-by Peterz -. add several comments Change from v7 -. fix a trivial typo -. modify commit messages to

[RESEND PATCH v11 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

It would be better to try to check other siblings first if SD_PREFER_SIBLING is flaged when pushing tasks - migration. Suggested-by: Peter Zijlstra Signed-off-by: Byungchul Park Acked-by: Juri Lelli --- kernel/sched/deadline.c

[RESEND PATCH v11 0/2] Make find_later_rq() choose a closer cpu in topology

Change from v10 -. modify a comment a bit as Steven suggested Change from v9 -. modify a comment a bit so to be more clear as Juri suggested Change from v8 -. add suggested-by Peterz -. add several comments Change from v7 -. fix a trivial typo -. modify commit messages to

[RESEND PATCH v11 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

It would be better to try to check other siblings first if SD_PREFER_SIBLING is flaged when pushing tasks - migration. Suggested-by: Peter Zijlstra Signed-off-by: Byungchul Park Acked-by: Juri Lelli --- kernel/sched/deadline.c | 82 - 1 file

[RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

Changes from v2 - Run spellchecker over the text and fix typos - Add acked-by Daniel Changes from v1 - Enhance commit msg - Prevent WARN in cpumask_test_cpu() in cpudl_find() when best_cpu == -1 -8<- >From 7735382d07ae6a61d740ae39ba2ecf169d43b8a2 Mon Sep 17 00:00:00 2001 From:

[RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

Changes from v2 - Run spellchecker over the text and fix typos - Add acked-by Daniel Changes from v1 - Enhance commit msg - Prevent WARN in cpumask_test_cpu() in cpudl_find() when best_cpu == -1 -8<- >From 7735382d07ae6a61d740ae39ba2ecf169d43b8a2 Mon Sep 17 00:00:00 2001 From:

Re: [PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description

Hi Martin On 01/08/18 04:19, Martin Blumenstingl wrote: > Hi Yixun, > > On Sat, Jan 6, 2018 at 1:10 AM, Yixun Lan wrote: >> Describe the pinctrl info for the UART controller which is found >> in the Meson-AXG SoCs. >> >> Signed-off-by: Yixun Lan >>

Re: [PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description

Hi Martin On 01/08/18 04:19, Martin Blumenstingl wrote: > Hi Yixun, > > On Sat, Jan 6, 2018 at 1:10 AM, Yixun Lan wrote: >> Describe the pinctrl info for the UART controller which is found >> in the Meson-AXG SoCs. >> >> Signed-off-by: Yixun Lan >> --- >>

[PATCH 2/3] rtc: Factor out the RTC range validation into rtc_valid_range()

The RTC range validation code can be factored into rtc_valid_range() function to avoid duplicate code. Signed-off-by: Baolin Wang --- drivers/rtc/interface.c | 30 ++ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git

[PATCH 2/3] rtc: Factor out the RTC range validation into rtc_valid_range()

The RTC range validation code can be factored into rtc_valid_range() function to avoid duplicate code. Signed-off-by: Baolin Wang --- drivers/rtc/interface.c | 30 ++ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/drivers/rtc/interface.c

[PATCH 3/3] rtc: Add one offset seconds to expand RTC range

>From our investigation for all RTC drivers, 1 driver will be expired before year 2017, 7 drivers will be expired before year 2038, 23 drivers will be expired before year 2069, 72 drivers will be expired before 2100 and 104 drivers will be expired before 2106. Especially for these early expired

[PATCH 3/3] rtc: Add one offset seconds to expand RTC range

>From our investigation for all RTC drivers, 1 driver will be expired before year 2017, 7 drivers will be expired before year 2038, 23 drivers will be expired before year 2069, 72 drivers will be expired before 2100 and 104 drivers will be expired before 2106. Especially for these early expired

[PATCH 1/3] rtc: Use time64_t to save range_max of RTC

We need use rtc->range_max to valid if the time values are valid, and the time values are saved by time64_t type. So change the rtc->range_max to time64_t type for comparison correctly. Signed-off-by: Baolin Wang --- include/linux/rtc.h |2 +- 1 file changed, 1

[PATCH 1/3] rtc: Use time64_t to save range_max of RTC

We need use rtc->range_max to valid if the time values are valid, and the time values are saved by time64_t type. So change the rtc->range_max to time64_t type for comparison correctly. Signed-off-by: Baolin Wang --- include/linux/rtc.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH] rtc: Fix overflow when converting time64_t to rtc_time

Hi Alexandre, On 25 December 2017 at 19:10, Baolin Wang wrote: > If we convert one large time values to rtc_time, in the original formula > 'days * 86400' can be overflowed in 'unsigned int' type to make the formula > get one incorrect remain seconds value. Thus we can

Re: [PATCH] rtc: Fix overflow when converting time64_t to rtc_time

Hi Alexandre, On 25 December 2017 at 19:10, Baolin Wang wrote: > If we convert one large time values to rtc_time, in the original formula > 'days * 86400' can be overflowed in 'unsigned int' type to make the formula > get one incorrect remain seconds value. Thus we can use div_s64_rem() >

[PATCH] Staging: greybus: Fix multiple checks for null pointers

Fixes the following coding style issue as noted by checkpatch.pl at multiple lines: Comparison to NULL could be written "!token" Signed-off-by: Sumit Pundir --- drivers/staging/greybus/camera.c | 16 1 file changed, 8 insertions(+), 8 deletions(-)

[PATCH] Staging: greybus: Fix multiple checks for null pointers

Fixes the following coding style issue as noted by checkpatch.pl at multiple lines: Comparison to NULL could be written "!token" Signed-off-by: Sumit Pundir --- drivers/staging/greybus/camera.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git

[PATCH 1/7] pipe, sysctl: drop 'min' parameter from pipe-max-size converter

From: Eric Biggers Before validating the given value against pipe_min_size, do_proc_dopipe_max_size_conv() calls round_pipe_size(), which rounds the value up to pipe_min_size. Therefore, the second check against pipe_min_size is redundant. Remove it. Signed-off-by: Eric

[PATCH 1/7] pipe, sysctl: drop 'min' parameter from pipe-max-size converter

From: Eric Biggers Before validating the given value against pipe_min_size, do_proc_dopipe_max_size_conv() calls round_pipe_size(), which rounds the value up to pipe_min_size. Therefore, the second check against pipe_min_size is redundant. Remove it. Signed-off-by: Eric Biggers ---

[PATCH 6/7] pipe: simplify round_pipe_size()

From: Eric Biggers round_pipe_size() calculates the number of pages the requested size corresponds to, then rounds the page count up to the next power of 2. However, it also rounds everything < PAGE_SIZE up to PAGE_SIZE. Therefore, there's no need to actually translate the

[PATCH 5/7] pipe: reject F_SETPIPE_SZ with size over UINT_MAX

From: Eric Biggers A pipe's size is represented as an 'unsigned int'. As expected, writing a value greater than UINT_MAX to /proc/sys/fs/pipe-max-size fails with EINVAL. However, the F_SETPIPE_SZ fcntl silently truncates such values to 32 bits, rather than failing with

[PATCH 3/7] pipe: actually allow root to exceed the pipe buffer limits

From: Eric Biggers pipe-user-pages-hard and pipe-user-pages-soft are only supposed to apply to unprivileged users, as documented in both Documentation/sysctl/fs.txt and the pipe(7) man page. However, the capabilities are actually only checked when increasing a pipe's size

[PATCH 6/7] pipe: simplify round_pipe_size()

From: Eric Biggers round_pipe_size() calculates the number of pages the requested size corresponds to, then rounds the page count up to the next power of 2. However, it also rounds everything < PAGE_SIZE up to PAGE_SIZE. Therefore, there's no need to actually translate the size into a page

[PATCH 5/7] pipe: reject F_SETPIPE_SZ with size over UINT_MAX

From: Eric Biggers A pipe's size is represented as an 'unsigned int'. As expected, writing a value greater than UINT_MAX to /proc/sys/fs/pipe-max-size fails with EINVAL. However, the F_SETPIPE_SZ fcntl silently truncates such values to 32 bits, rather than failing with EINVAL as expected. (It

[PATCH 3/7] pipe: actually allow root to exceed the pipe buffer limits

From: Eric Biggers pipe-user-pages-hard and pipe-user-pages-soft are only supposed to apply to unprivileged users, as documented in both Documentation/sysctl/fs.txt and the pipe(7) man page. However, the capabilities are actually only checked when increasing a pipe's size using F_SETPIPE_SZ,

[PATCH 4/7] pipe: fix off-by-one error when checking buffer limits

From: Eric Biggers With pipe-user-pages-hard set to 'N', users were actually only allowed up to 'N - 1' buffers; and likewise for pipe-user-pages-soft. Fix this to allow up to 'N' buffers, as would be expected. Signed-off-by: Eric Biggers ---

[PATCH 4/7] pipe: fix off-by-one error when checking buffer limits

From: Eric Biggers With pipe-user-pages-hard set to 'N', users were actually only allowed up to 'N - 1' buffers; and likewise for pipe-user-pages-soft. Fix this to allow up to 'N' buffers, as would be expected. Signed-off-by: Eric Biggers --- fs/pipe.c | 4 ++-- 1 file changed, 2

[PATCH 7/7] pipe: read buffer limits atomically

From: Eric Biggers The pipe buffer limits are accessed without any locking, and may be changed at any time by the sysctl handlers. In theory this could cause problems for expressions like the following: pipe_user_pages_hard && user_bufs > pipe_user_pages_hard ...

[PATCH 7/7] pipe: read buffer limits atomically

From: Eric Biggers The pipe buffer limits are accessed without any locking, and may be changed at any time by the sysctl handlers. In theory this could cause problems for expressions like the following: pipe_user_pages_hard && user_bufs > pipe_user_pages_hard ... since the assembly code

  1   2   3   4   5   6   7   8   9   >