[Patch v6 16/16] x86/smt: Allow disabling of SMT when last SMT is offlined

2018-11-20 Thread Tim Chen
Currently cpu_use_smt_and_hotplug is only set during boot time to indicate if SMT is in use. However, CPU topology may change and when the last SMT thread is offlined, the SMT code path can be skipped. The sched_smt_present key detects this condition. Export sched_smt_present and incorporate it

[Patch v6 10/16] x86/speculation: Create PRCTL interface to restrict indirect branch speculation

2018-11-20 Thread Tim Chen
Create PRCTL interface to restrict an application's indirect branch speculation. This will protect the application against spectre v2 attack from another application. Invocations: Check indirect branch speculation status with - prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, 0, 0, 0);

Re: [PATCH v2] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support

2018-11-20 Thread Rafael David Tinoco
On 11/20/18 10:11 PM, Rafael David Tinoco wrote: On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the physical frame number might be so big that zsmalloc obj encoding (to location) will break, causing: BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc Read of size 4 at

Re: [PATCH v2] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support

2018-11-20 Thread Rafael David Tinoco
On 11/20/18 10:11 PM, Rafael David Tinoco wrote: On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the physical frame number might be so big that zsmalloc obj encoding (to location) will break, causing: BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc Read of size 4 at

[PATCH v2] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support

2018-11-20 Thread Rafael David Tinoco
On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the physical frame number might be so big that zsmalloc obj encoding (to location) will break, causing: BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc Read of size 4 at addr by task mkfs.ext4/623 CPU: 2 PID: 623

[PATCH v2] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support

2018-11-20 Thread Rafael David Tinoco
On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the physical frame number might be so big that zsmalloc obj encoding (to location) will break, causing: BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc Read of size 4 at addr by task mkfs.ext4/623 CPU: 2 PID: 623

[RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO

2018-11-20 Thread Lina Iyer
SDM845 SoC has an always-on interrupt controller (PDC) with select GPIO routed to the PDC as interrupts that can be used to wake the system up from deep low power modes and suspend. Signed-off-by: Lina Iyer --- .../bindings/pinctrl/qcom,sdm845-pinctrl.txt | 31 ++- 1 file

[RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO

2018-11-20 Thread Lina Iyer
SDM845 SoC has an always-on interrupt controller (PDC) with select GPIO routed to the PDC as interrupts that can be used to wake the system up from deep low power modes and suspend. Signed-off-by: Lina Iyer --- .../bindings/pinctrl/qcom,sdm845-pinctrl.txt | 31 ++- 1 file

[RFC v3 1/3] drivers: pinctrl: msm: setup gpio irqchip in hierarchy with pdc irqchip

2018-11-20 Thread Lina Iyer
Signed-off-by: Lina Iyer --- drivers/pinctrl/qcom/pinctrl-msm.c | 125 - 1 file changed, 121 insertions(+), 4 deletions(-) diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c index 7c7d083e2c0d..3857aa5539e0 100644 ---

[RFC v3 1/3] drivers: pinctrl: msm: setup gpio irqchip in hierarchy with pdc irqchip

2018-11-20 Thread Lina Iyer
Signed-off-by: Lina Iyer --- drivers/pinctrl/qcom/pinctrl-msm.c | 125 - 1 file changed, 121 insertions(+), 4 deletions(-) diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c index 7c7d083e2c0d..3857aa5539e0 100644 ---

[RFC v3 3/3] arm64: dts: msm: add PDC wake irq maps for GPIOs for SDM845

2018-11-20 Thread Lina Iyer
Add PDC wakeup irq for GPIOs and the wakeup parent for TLMM. Signed-off-by: Lina Iyer --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 18 ++ 1 file changed, 18 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi index

[RFC v3 0/3] qcom: GPIO IRQ wakeup using PDC irqchip

2018-11-20 Thread Lina Iyer
Hi, This is an attempt at using GPIO as wake up sources. Based on discussions with Stephen and Marc [1], the idea that is used here is to make PDC interrupt controller the parent of TLMM irqchip. Wakeup capable GPIO IRQs have corresponding parent interrupt in PDC and therefore the GIC. The TLMM

[RFC v3 3/3] arm64: dts: msm: add PDC wake irq maps for GPIOs for SDM845

2018-11-20 Thread Lina Iyer
Add PDC wakeup irq for GPIOs and the wakeup parent for TLMM. Signed-off-by: Lina Iyer --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 18 ++ 1 file changed, 18 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi index

[RFC v3 0/3] qcom: GPIO IRQ wakeup using PDC irqchip

2018-11-20 Thread Lina Iyer
Hi, This is an attempt at using GPIO as wake up sources. Based on discussions with Stephen and Marc [1], the idea that is used here is to make PDC interrupt controller the parent of TLMM irqchip. Wakeup capable GPIO IRQs have corresponding parent interrupt in PDC and therefore the GIC. The TLMM

[PATCH 1/2] doc:process: add links where missing

2018-11-20 Thread Federico Vaga
Some documents are refering to others without links. With this patch I add those missing links. This patch affects only documents under process/ and labels where necessary. Signed-off-by: Federico Vaga --- Documentation/admin-guide/devices.rst| 1 +

[PATCH 1/2] doc:process: add links where missing

2018-11-20 Thread Federico Vaga
Some documents are refering to others without links. With this patch I add those missing links. This patch affects only documents under process/ and labels where necessary. Signed-off-by: Federico Vaga --- Documentation/admin-guide/devices.rst| 1 +

linux-next: manual merge of the mlx5-next tree with the rdma tree

2018-11-20 Thread Stephen Rothwell
Hi Leon, Today's linux-next merge of the mlx5-next tree got a conflict in: drivers/infiniband/hw/mlx5/main.c between commit: 9afc97c29b03 ("mlx5: remove support for ib_get_vector_affinity") from the rdma tree and commit: f2f3df550139 ("net/mlx5: EQ, Privatize eq_table and friends")

linux-next: manual merge of the mlx5-next tree with the rdma tree

2018-11-20 Thread Stephen Rothwell
Hi Leon, Today's linux-next merge of the mlx5-next tree got a conflict in: drivers/infiniband/hw/mlx5/main.c between commit: 9afc97c29b03 ("mlx5: remove support for ib_get_vector_affinity") from the rdma tree and commit: f2f3df550139 ("net/mlx5: EQ, Privatize eq_table and friends")

Re: [RFC PATCH 1/3] mm, proc: be more verbose about unstable VMA flags in /proc//smaps

2018-11-20 Thread David Rientjes
On Tue, 20 Nov 2018, Jan Kara wrote: > > Even though vma flags exported via /proc//smaps are explicitly > > documented to be not guaranteed for future compatibility the warning > > doesn't go far enough because it doesn't mention semantic changes to > > those flags. And they are important as well

Re: [RFC PATCH 1/3] mm, proc: be more verbose about unstable VMA flags in /proc//smaps

2018-11-20 Thread David Rientjes
On Tue, 20 Nov 2018, Jan Kara wrote: > > Even though vma flags exported via /proc//smaps are explicitly > > documented to be not guaranteed for future compatibility the warning > > doesn't go far enough because it doesn't mention semantic changes to > > those flags. And they are important as well

Re: [PATCH v2 1/7] staging:iio:ad2s90: Add device tree support

2018-11-20 Thread Matheus Tavares Bernardino
On Mon, Nov 19, 2018 at 6:09 AM Ardelean, Alexandru wrote: > > On Sun, 2018-11-18 at 02:25 -0200, Matheus Tavares wrote: > > This patch adds device tree support to ad2s90 with standard > > device tree id table. > > > > Hey, > > Comment inline > > > Signed-off-by: Matheus Tavares > > --- > >

Re: [PATCH v2 1/7] staging:iio:ad2s90: Add device tree support

2018-11-20 Thread Matheus Tavares Bernardino
On Mon, Nov 19, 2018 at 6:09 AM Ardelean, Alexandru wrote: > > On Sun, 2018-11-18 at 02:25 -0200, Matheus Tavares wrote: > > This patch adds device tree support to ad2s90 with standard > > device tree id table. > > > > Hey, > > Comment inline > > > Signed-off-by: Matheus Tavares > > --- > >

Re: [PATCH v3] debugobjects: scale the static pool size

2018-11-20 Thread Joe Perches
On Wed, 2018-11-21 at 00:54 +0100, Qian Cai wrote: > On 11/20/18 at 6:38 PM, Waiman Long wrote: > > On 11/20/2018 06:28 PM, Qian Cai wrote: > > > The current value of the early boot static pool size is not big enough > > > for systems with large number of CPUs with timer or/and workqueue > > >

Re: [PATCH v3] debugobjects: scale the static pool size

2018-11-20 Thread Joe Perches
On Wed, 2018-11-21 at 00:54 +0100, Qian Cai wrote: > On 11/20/18 at 6:38 PM, Waiman Long wrote: > > On 11/20/2018 06:28 PM, Qian Cai wrote: > > > The current value of the early boot static pool size is not big enough > > > for systems with large number of CPUs with timer or/and workqueue > > >

Re: [PATCH v3] debugobjects: scale the static pool size

2018-11-20 Thread Qian Cai
On 11/20/18 at 6:38 PM, Waiman Long wrote: > On 11/20/2018 06:28 PM, Qian Cai wrote: > > The current value of the early boot static pool size is not big enough > > for systems with large number of CPUs with timer or/and workqueue > > objects selected. As the results, systems have 60+ CPUs with

Re: [PATCH v3] debugobjects: scale the static pool size

2018-11-20 Thread Qian Cai
On 11/20/18 at 6:38 PM, Waiman Long wrote: > On 11/20/2018 06:28 PM, Qian Cai wrote: > > The current value of the early boot static pool size is not big enough > > for systems with large number of CPUs with timer or/and workqueue > > objects selected. As the results, systems have 60+ CPUs with

Re: [PATCH 4.4 131/160] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-11-20 Thread David Rientjes
On Tue, 20 Nov 2018, Michal Hocko wrote: > On Mon 19-11-18 14:16:24, David Rientjes wrote: > > On Mon, 19 Nov 2018, Greg Kroah-Hartman wrote: > > > > > 4.4-stable review patch. If anyone has any objections, please let me > > > know. > > > > > > > As I noted when this patch was originally

Re: [PATCH 4.4 131/160] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-11-20 Thread David Rientjes
On Tue, 20 Nov 2018, Michal Hocko wrote: > On Mon 19-11-18 14:16:24, David Rientjes wrote: > > On Mon, 19 Nov 2018, Greg Kroah-Hartman wrote: > > > > > 4.4-stable review patch. If anyone has any objections, please let me > > > know. > > > > > > > As I noted when this patch was originally

Re: STIBP by default.. Revert?

2018-11-20 Thread Arjan van de Ven
On 11/20/2018 11:27 PM, Jiri Kosina wrote: On Mon, 19 Nov 2018, Arjan van de Ven wrote: In the documentation, AMD officially recommends against this by default, and I can speak for Intel that our position is that as well: this really must not be on by default. Thanks for pointing to the AMD

Re: STIBP by default.. Revert?

2018-11-20 Thread Arjan van de Ven
On 11/20/2018 11:27 PM, Jiri Kosina wrote: On Mon, 19 Nov 2018, Arjan van de Ven wrote: In the documentation, AMD officially recommends against this by default, and I can speak for Intel that our position is that as well: this really must not be on by default. Thanks for pointing to the AMD

Re: [PATCH v3] debugobjects: scale the static pool size

2018-11-20 Thread Waiman Long
On 11/20/2018 06:28 PM, Qian Cai wrote: > The current value of the early boot static pool size is not big enough > for systems with large number of CPUs with timer or/and workqueue > objects selected. As the results, systems have 60+ CPUs with both timer > and workqueue objects enabled could

Re: [PATCH v3] debugobjects: scale the static pool size

2018-11-20 Thread Waiman Long
On 11/20/2018 06:28 PM, Qian Cai wrote: > The current value of the early boot static pool size is not big enough > for systems with large number of CPUs with timer or/and workqueue > objects selected. As the results, systems have 60+ CPUs with both timer > and workqueue objects enabled could

Re: [PATCH v2 4/7] dt-bindings:iio:resolver: Add docs for ad2s90

2018-11-20 Thread Matheus Tavares Bernardino
On Mon, Nov 19, 2018 at 6:22 AM Ardelean, Alexandru wrote: > > On Sun, 2018-11-18 at 02:25 -0200, Matheus Tavares wrote: > > This patch adds the device tree binding documentation for the ad2s90 > > resolver-to-digital converter. > > > > One minor comment inline. > > > Signed-off-by: Matheus

Re: [PATCH v2 4/7] dt-bindings:iio:resolver: Add docs for ad2s90

2018-11-20 Thread Matheus Tavares Bernardino
On Mon, Nov 19, 2018 at 6:22 AM Ardelean, Alexandru wrote: > > On Sun, 2018-11-18 at 02:25 -0200, Matheus Tavares wrote: > > This patch adds the device tree binding documentation for the ad2s90 > > resolver-to-digital converter. > > > > One minor comment inline. > > > Signed-off-by: Matheus

[PATCH v3] debugobjects: scale the static pool size

2018-11-20 Thread Qian Cai
The current value of the early boot static pool size is not big enough for systems with large number of CPUs with timer or/and workqueue objects selected. As the results, systems have 60+ CPUs with both timer and workqueue objects enabled could trigger "ODEBUG: Out of memory. ODEBUG disabled".

[PATCH v3] debugobjects: scale the static pool size

2018-11-20 Thread Qian Cai
The current value of the early boot static pool size is not big enough for systems with large number of CPUs with timer or/and workqueue objects selected. As the results, systems have 60+ CPUs with both timer and workqueue objects enabled could trigger "ODEBUG: Out of memory. ODEBUG disabled".

[PATCH v9 RESEND 4/4] Kselftest for module text allocation benchmarking

2018-11-20 Thread Rick Edgecombe
This adds a test module in lib/, and a script in kselftest that does benchmarking on the allocation of memory in the module space. Performance here would have some small impact on kernel module insertions, BPF JIT insertions and kprobes. In the case of KASLR features for the module space, this

[PATCH v9 RESEND 4/4] Kselftest for module text allocation benchmarking

2018-11-20 Thread Rick Edgecombe
This adds a test module in lib/, and a script in kselftest that does benchmarking on the allocation of memory in the module space. Performance here would have some small impact on kernel module insertions, BPF JIT insertions and kprobes. In the case of KASLR features for the module space, this

[PATCH v9 RESEND 3/4] vmalloc: Add debugfs modfraginfo

2018-11-20 Thread Rick Edgecombe
Add debugfs file "modfraginfo" for providing info on module space fragmentation. This can be used for determining if loadable module randomization is causing any problems for extreme module loading situations, like huge numbers of modules or extremely large modules. Sample output when KASLR is

[PATCH v9 RESEND 0/4] KASLR feature to randomize each loadable module

2018-11-20 Thread Rick Edgecombe
Resending this because I missed Jessica in the "to" list. Also removing the part of this coverletter that talked about KPTI helping with some local kernel text de-randomizing methods, because I'm not sure I fully understand this. This

[PATCH v9 RESEND 1/4] vmalloc: Add __vmalloc_node_try_addr function

2018-11-20 Thread Rick Edgecombe
Create __vmalloc_node_try_addr function that tries to allocate at a specific address without triggering any lazy purging and retry. For the randomized allocator that uses this function, failing to allocate at a specific address is a lot more common. This function will not try to do any lazy purge

[PATCH v9 RESEND 3/4] vmalloc: Add debugfs modfraginfo

2018-11-20 Thread Rick Edgecombe
Add debugfs file "modfraginfo" for providing info on module space fragmentation. This can be used for determining if loadable module randomization is causing any problems for extreme module loading situations, like huge numbers of modules or extremely large modules. Sample output when KASLR is

[PATCH v9 RESEND 0/4] KASLR feature to randomize each loadable module

2018-11-20 Thread Rick Edgecombe
Resending this because I missed Jessica in the "to" list. Also removing the part of this coverletter that talked about KPTI helping with some local kernel text de-randomizing methods, because I'm not sure I fully understand this. This

[PATCH v9 RESEND 1/4] vmalloc: Add __vmalloc_node_try_addr function

2018-11-20 Thread Rick Edgecombe
Create __vmalloc_node_try_addr function that tries to allocate at a specific address without triggering any lazy purging and retry. For the randomized allocator that uses this function, failing to allocate at a specific address is a lot more common. This function will not try to do any lazy purge

[PATCH v9 RESEND 2/4] x86/modules: Increase randomization for modules

2018-11-20 Thread Rick Edgecombe
This changes the behavior of the KASLR logic for allocating memory for the text sections of loadable modules. It randomizes the location of each module text section with about 17 bits of entropy in typical use. This is enabled on X86_64 only. For 32 bit, the behavior is unchanged. It refactors

[PATCH v9 RESEND 2/4] x86/modules: Increase randomization for modules

2018-11-20 Thread Rick Edgecombe
This changes the behavior of the KASLR logic for allocating memory for the text sections of loadable modules. It randomizes the location of each module text section with about 17 bits of entropy in typical use. This is enabled on X86_64 only. For 32 bit, the behavior is unchanged. It refactors

Re: [PATCH v5] tpm: add support for partial reads

2018-11-20 Thread Tadeusz Struk
On 11/20/18 3:07 PM, Jarkko Sakkinen wrote: + /* Holds the resul of the last successful call to tpm_transmit() */ >>> This comment is cruft. >> Do you want me to remove it? This is the comment you proposed. > As I explained before it made sense before you made the remark that > it can only

Re: [PATCH v5] tpm: add support for partial reads

2018-11-20 Thread Tadeusz Struk
On 11/20/18 3:07 PM, Jarkko Sakkinen wrote: + /* Holds the resul of the last successful call to tpm_transmit() */ >>> This comment is cruft. >> Do you want me to remove it? This is the comment you proposed. > As I explained before it made sense before you made the remark that > it can only

Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()

2018-11-20 Thread Finn Thain
On Tue, 20 Nov 2018, Kars de Jong wrote: > Op ma 19 nov. 2018 om 02:10 schreef Finn Thain : > > > > hp300_gettimeoffset() never checks the timer interrupt flag and will > > fail to notice when the timer counter gets reloaded. That means the > > clock could jump backwards. > > > > Remove this code

Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()

2018-11-20 Thread Finn Thain
On Tue, 20 Nov 2018, Kars de Jong wrote: > Op ma 19 nov. 2018 om 02:10 schreef Finn Thain : > > > > hp300_gettimeoffset() never checks the timer interrupt flag and will > > fail to notice when the timer counter gets reloaded. That means the > > clock could jump backwards. > > > > Remove this code

Re: [PATCH 1/2] ARM: dts: qcom: Add SoC-specific string for sdhci-msm-v4 nodes

2018-11-20 Thread Doug Anderson
Andy, On Mon, Nov 5, 2018 at 1:09 PM Douglas Anderson wrote: > > As per upstream discussion [1], we should have an SoC-specific > compatible string for Qualcomm's SDHCI nodes. Let's add it. > > [1] https://lkml.kernel.org/r/20181105203657.GA32282@bogus > > Signed-off-by: Douglas Anderson > ---

Re: [PATCH 1/2] ARM: dts: qcom: Add SoC-specific string for sdhci-msm-v4 nodes

2018-11-20 Thread Doug Anderson
Andy, On Mon, Nov 5, 2018 at 1:09 PM Douglas Anderson wrote: > > As per upstream discussion [1], we should have an SoC-specific > compatible string for Qualcomm's SDHCI nodes. Let's add it. > > [1] https://lkml.kernel.org/r/20181105203657.GA32282@bogus > > Signed-off-by: Douglas Anderson > ---

Re: [PATCH v5] tpm: add support for partial reads

2018-11-20 Thread Jarkko Sakkinen
On Tue, Nov 20, 2018 at 10:30:32AM -0800, Tadeusz Struk wrote: > On 11/20/18 4:48 AM, Jarkko Sakkinen wrote: > >> The usecase is implemented in this TSS commit: > >> https://github.com/tpm2-software/tpm2-tss/commit/ce982f67a67dc08e24683d30b05800648d8a264c > > Can you implement test for this to > >

Re: [PATCH v5] tpm: add support for partial reads

2018-11-20 Thread Jarkko Sakkinen
On Tue, Nov 20, 2018 at 10:30:32AM -0800, Tadeusz Struk wrote: > On 11/20/18 4:48 AM, Jarkko Sakkinen wrote: > >> The usecase is implemented in this TSS commit: > >> https://github.com/tpm2-software/tpm2-tss/commit/ce982f67a67dc08e24683d30b05800648d8a264c > > Can you implement test for this to > >

Re: [PATCH v5] tpm: add support for partial reads

2018-11-20 Thread Jarkko Sakkinen
On Tue, Nov 20, 2018 at 10:36:14AM -0800, Tadeusz Struk wrote: > On 11/20/18 4:48 AM, Jarkko Sakkinen wrote: > >> + /* Holds the resul of the last successful call to tpm_transmit() */ > > This comment is cruft. > > Do you want me to remove it? This is the comment you proposed. As I explained

Re: [PATCH v5] tpm: add support for partial reads

2018-11-20 Thread Jarkko Sakkinen
On Tue, Nov 20, 2018 at 10:36:14AM -0800, Tadeusz Struk wrote: > On 11/20/18 4:48 AM, Jarkko Sakkinen wrote: > >> + /* Holds the resul of the last successful call to tpm_transmit() */ > > This comment is cruft. > > Do you want me to remove it? This is the comment you proposed. As I explained

[PATCH] RISC-V: Fix of_node_* refcount

2018-11-20 Thread Atish Patra
Fix of_node* refcount at various places by using of_node_put. Signed-off-by: Atish Patra --- arch/riscv/kernel/cacheinfo.c | 11 +++ arch/riscv/kernel/cpu.c| 1 + arch/riscv/kernel/cpufeature.c | 2 ++ arch/riscv/kernel/perf_event.c | 1 + arch/riscv/kernel/smpboot.c| 6

[PATCH] RISC-V: Fix of_node_* refcount

2018-11-20 Thread Atish Patra
Fix of_node* refcount at various places by using of_node_put. Signed-off-by: Atish Patra --- arch/riscv/kernel/cacheinfo.c | 11 +++ arch/riscv/kernel/cpu.c| 1 + arch/riscv/kernel/cpufeature.c | 2 ++ arch/riscv/kernel/perf_event.c | 1 + arch/riscv/kernel/smpboot.c| 6

Re: [PATCH 1/3] ARM: davinci: define gpio interrupts as separate resources

2018-11-20 Thread Sekhar Nori
On 20/11/18 12:08 PM, J, KEERTHY wrote: > > > On 11/20/2018 2:22 AM, Sekhar Nori wrote: >> On 13/11/18 7:20 PM, Bartosz Golaszewski wrote: >>> From: Bartosz Golaszewski >>> >>> Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous >>> IRQ numbering") the davinci GPIO driver fails

Re: [PATCH 1/3] ARM: davinci: define gpio interrupts as separate resources

2018-11-20 Thread Sekhar Nori
On 20/11/18 12:08 PM, J, KEERTHY wrote: > > > On 11/20/2018 2:22 AM, Sekhar Nori wrote: >> On 13/11/18 7:20 PM, Bartosz Golaszewski wrote: >>> From: Bartosz Golaszewski >>> >>> Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous >>> IRQ numbering") the davinci GPIO driver fails

Re: Cleaning up numbering for new x86 syscalls?

2018-11-20 Thread Bernd Petrovitsch
On 20/11/2018 08:33, Ingo Molnar wrote: [...] > 6. Is x32 even used in practice? I still think it was a mistake to add it >and some significant distributions like Fedora are not enabling it. x32 works as far as gcc/gas/ld is concerned (at least for compiling non-trivial programs). Finding a

Re: Cleaning up numbering for new x86 syscalls?

2018-11-20 Thread Bernd Petrovitsch
On 20/11/2018 08:33, Ingo Molnar wrote: [...] > 6. Is x32 even used in practice? I still think it was a mistake to add it >and some significant distributions like Fedora are not enabling it. x32 works as far as gcc/gas/ld is concerned (at least for compiling non-trivial programs). Finding a

Re: RFC: userspace exception fixups

2018-11-20 Thread Jarkko Sakkinen
On Tue, Nov 20, 2018 at 07:19:37AM -0800, Andy Lutomirski wrote: > What is "#GP with EPCM"? We certainly don't want to react to #UD in A typo. Meant #PF with PF_SGX set i.e. EPCM conflict. > general by mucking with some regs and retrying -- that will infinite > loop and confuse everyone. I'm

Re: RFC: userspace exception fixups

2018-11-20 Thread Jarkko Sakkinen
On Tue, Nov 20, 2018 at 07:19:37AM -0800, Andy Lutomirski wrote: > What is "#GP with EPCM"? We certainly don't want to react to #UD in A typo. Meant #PF with PF_SGX set i.e. EPCM conflict. > general by mucking with some regs and retrying -- that will infinite > loop and confuse everyone. I'm

Re: [PATCH v9 05/17] tpm: declare struct tpm_header

2018-11-20 Thread Jarkko Sakkinen
On Tue, Nov 20, 2018 at 09:01:11AM -0700, Jason Gunthorpe wrote: > On Tue, Nov 20, 2018 at 03:08:05PM +0200, Jarkko Sakkinen wrote: > > On Mon, Nov 19, 2018 at 09:33:31PM +, Winkler, Tomas wrote: > > > > > > > > > > > Decleare struct tpm_header that replaces struct tpm_input_header and > > >

Re: [PATCH v9 05/17] tpm: declare struct tpm_header

2018-11-20 Thread Jarkko Sakkinen
On Tue, Nov 20, 2018 at 09:01:11AM -0700, Jason Gunthorpe wrote: > On Tue, Nov 20, 2018 at 03:08:05PM +0200, Jarkko Sakkinen wrote: > > On Mon, Nov 19, 2018 at 09:33:31PM +, Winkler, Tomas wrote: > > > > > > > > > > > Decleare struct tpm_header that replaces struct tpm_input_header and > > >

Re: RFC: userspace exception fixups

2018-11-20 Thread Jarkko Sakkinen
On Tue, Nov 20, 2018 at 12:11:33PM +0200, Jarkko Sakkinen wrote: > On Mon, Nov 19, 2018 at 09:00:08AM -0800, Andy Lutomirski wrote: > > On Mon, Nov 19, 2018 at 8:02 AM Jarkko Sakkinen > > wrote: > > > > > > On Mon, Nov 19, 2018 at 07:29:36AM -0800, Andy Lutomirski wrote: > > > > 1. The kernel

Re: RFC: userspace exception fixups

2018-11-20 Thread Jarkko Sakkinen
On Tue, Nov 20, 2018 at 12:11:33PM +0200, Jarkko Sakkinen wrote: > On Mon, Nov 19, 2018 at 09:00:08AM -0800, Andy Lutomirski wrote: > > On Mon, Nov 19, 2018 at 8:02 AM Jarkko Sakkinen > > wrote: > > > > > > On Mon, Nov 19, 2018 at 07:29:36AM -0800, Andy Lutomirski wrote: > > > > 1. The kernel

Re: [PATCH 20/25] sched/kcpustat: Introduce vtime-aware kcpustat accessor

2018-11-20 Thread Frederic Weisbecker
On Tue, Nov 20, 2018 at 03:23:06PM +0100, Peter Zijlstra wrote: > On Wed, Nov 14, 2018 at 03:46:04AM +0100, Frederic Weisbecker wrote: > > > +void kcpustat_cputime(struct kernel_cpustat *kcpustat, int cpu, > > + u64 *user, u64 *nice, u64 *system, > > + u64 *guest,

Re: [PATCH 20/25] sched/kcpustat: Introduce vtime-aware kcpustat accessor

2018-11-20 Thread Frederic Weisbecker
On Tue, Nov 20, 2018 at 03:23:06PM +0100, Peter Zijlstra wrote: > On Wed, Nov 14, 2018 at 03:46:04AM +0100, Frederic Weisbecker wrote: > > > +void kcpustat_cputime(struct kernel_cpustat *kcpustat, int cpu, > > + u64 *user, u64 *nice, u64 *system, > > + u64 *guest,

Re: [REGRESSION] x86, perf: counter freezing breaks rr

2018-11-20 Thread Andi Kleen
> In fact, I'll argue FREEZE_ON_OVERFLOW is unfixably broken for > independent counters, because while one counter overflows, we'll stall > counting on all others until we've handled the PMI. > > Even though the PMI might not be for them and they very much want/need > to continue counting. We

Re: [REGRESSION] x86, perf: counter freezing breaks rr

2018-11-20 Thread Andi Kleen
> In fact, I'll argue FREEZE_ON_OVERFLOW is unfixably broken for > independent counters, because while one counter overflows, we'll stall > counting on all others until we've handled the PMI. > > Even though the PMI might not be for them and they very much want/need > to continue counting. We

Re: dyntick-idle CPU and node's qsmask

2018-11-20 Thread Paul E. McKenney
On Tue, Nov 20, 2018 at 02:28:13PM -0800, Paul E. McKenney wrote: > On Tue, Nov 20, 2018 at 12:42:43PM -0800, Joel Fernandes wrote: > > On Sun, Nov 11, 2018 at 10:36:18AM -0800, Paul E. McKenney wrote: > > > On Sun, Nov 11, 2018 at 10:09:16AM -0800, Joel Fernandes wrote: > > > > On Sat, Nov 10,

Re: dyntick-idle CPU and node's qsmask

2018-11-20 Thread Paul E. McKenney
On Tue, Nov 20, 2018 at 02:28:13PM -0800, Paul E. McKenney wrote: > On Tue, Nov 20, 2018 at 12:42:43PM -0800, Joel Fernandes wrote: > > On Sun, Nov 11, 2018 at 10:36:18AM -0800, Paul E. McKenney wrote: > > > On Sun, Nov 11, 2018 at 10:09:16AM -0800, Joel Fernandes wrote: > > > > On Sat, Nov 10,

Re: [PATCH 21/25] procfs: Use vtime aware kcpustat accessor

2018-11-20 Thread Frederic Weisbecker
On Tue, Nov 20, 2018 at 03:24:22PM +0100, Peter Zijlstra wrote: > On Wed, Nov 14, 2018 at 03:46:05AM +0100, Frederic Weisbecker wrote: > > /* Copy values here to work around gcc-2.95.3, gcc-2.96 */ > > Just a note to let you know the current minimum GCC version is 4.6 :-) Yeah,

Re: [PATCH 21/25] procfs: Use vtime aware kcpustat accessor

2018-11-20 Thread Frederic Weisbecker
On Tue, Nov 20, 2018 at 03:24:22PM +0100, Peter Zijlstra wrote: > On Wed, Nov 14, 2018 at 03:46:05AM +0100, Frederic Weisbecker wrote: > > /* Copy values here to work around gcc-2.95.3, gcc-2.96 */ > > Just a note to let you know the current minimum GCC version is 4.6 :-) Yeah,

Re: dyntick-idle CPU and node's qsmask

2018-11-20 Thread Paul E. McKenney
On Tue, Nov 20, 2018 at 12:42:43PM -0800, Joel Fernandes wrote: > On Sun, Nov 11, 2018 at 10:36:18AM -0800, Paul E. McKenney wrote: > > On Sun, Nov 11, 2018 at 10:09:16AM -0800, Joel Fernandes wrote: > > > On Sat, Nov 10, 2018 at 08:22:10PM -0800, Paul E. McKenney wrote: > > > > On Sat, Nov 10,

Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER

2018-11-20 Thread Sinan Kaya
On 11/20/2018 4:42 PM, Keith Busch wrote: How does that work? If the OS takes control, it sets up MSIs that FW don't react to, and disables system errors through PCIe Root Control. Aren't those sys errs the mechanism FW knows it has something to do, which means the OS can effectively fence it

Re: dyntick-idle CPU and node's qsmask

2018-11-20 Thread Paul E. McKenney
On Tue, Nov 20, 2018 at 12:42:43PM -0800, Joel Fernandes wrote: > On Sun, Nov 11, 2018 at 10:36:18AM -0800, Paul E. McKenney wrote: > > On Sun, Nov 11, 2018 at 10:09:16AM -0800, Joel Fernandes wrote: > > > On Sat, Nov 10, 2018 at 08:22:10PM -0800, Paul E. McKenney wrote: > > > > On Sat, Nov 10,

Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER

2018-11-20 Thread Sinan Kaya
On 11/20/2018 4:42 PM, Keith Busch wrote: How does that work? If the OS takes control, it sets up MSIs that FW don't react to, and disables system errors through PCIe Root Control. Aren't those sys errs the mechanism FW knows it has something to do, which means the OS can effectively fence it

Re: [PATCH v3 01/20] lib/vsprintf: Print time and date in human readable format via %pt

2018-11-20 Thread Alexandre Belloni
Hello, (Please update my email address). On 13/11/2018 19:17:10+0200, Andy Shevchenko wrote: > There are users which print time and date represented by content of > struct rtc_time in human readable format. > > Instead of open coding that each time introduce %ptR[dt][rv] specifier. > > Note,

Re: [PATCH v3 01/20] lib/vsprintf: Print time and date in human readable format via %pt

2018-11-20 Thread Alexandre Belloni
Hello, (Please update my email address). On 13/11/2018 19:17:10+0200, Andy Shevchenko wrote: > There are users which print time and date represented by content of > struct rtc_time in human readable format. > > Instead of open coding that each time introduce %ptR[dt][rv] specifier. > > Note,

Re: [PATCH] mmc: core: Remove timeout when enabling cache

2018-11-20 Thread Ulf Hansson
On 20 November 2018 at 15:55, Sjoerd Simons wrote: > On Tue, 2018-11-20 at 15:24 +0100, Ulf Hansson wrote: >> On 20 November 2018 at 15:00, Sjoerd Simons >> wrote: >> > On Tue, 2018-11-20 at 14:08 +0100, Ulf Hansson wrote: >> > > + Hal Emmerich >> > > >> > > On 20 November 2018 at 12:38, Sjoerd

Re: [PATCH] mmc: core: Remove timeout when enabling cache

2018-11-20 Thread Ulf Hansson
On 20 November 2018 at 15:55, Sjoerd Simons wrote: > On Tue, 2018-11-20 at 15:24 +0100, Ulf Hansson wrote: >> On 20 November 2018 at 15:00, Sjoerd Simons >> wrote: >> > On Tue, 2018-11-20 at 14:08 +0100, Ulf Hansson wrote: >> > > + Hal Emmerich >> > > >> > > On 20 November 2018 at 12:38, Sjoerd

Re: [REGRESSION] x86, perf: counter freezing breaks rr

2018-11-20 Thread Peter Zijlstra
On Tue, Nov 20, 2018 at 11:16:42PM +0100, Peter Zijlstra wrote: > Ooh, so the thing does FREEZE_ON_OVERFLOW _not_ FREEZE_ON_PMI. Yes, that > can be a big difference. > > See, FREEZE_ON_PMI, as advertised by the name, should have no observable > effect on counters limited to USR. But something

Re: [REGRESSION] x86, perf: counter freezing breaks rr

2018-11-20 Thread Peter Zijlstra
On Tue, Nov 20, 2018 at 11:16:42PM +0100, Peter Zijlstra wrote: > Ooh, so the thing does FREEZE_ON_OVERFLOW _not_ FREEZE_ON_PMI. Yes, that > can be a big difference. > > See, FREEZE_ON_PMI, as advertised by the name, should have no observable > effect on counters limited to USR. But something

Re: [REGRESSION] x86, perf: counter freezing breaks rr

2018-11-20 Thread Andi Kleen
On Tue, Nov 20, 2018 at 01:46:05PM -0800, Kyle Huey wrote: > On Tue, Nov 20, 2018 at 1:18 PM Andi Kleen wrote: > > > > > I suppose that's fair that it's better for some use cases. The flip > > > side is that it's no longer possible to get exactly accurate counts > > > from user space if you're

Re: [REGRESSION] x86, perf: counter freezing breaks rr

2018-11-20 Thread Andi Kleen
On Tue, Nov 20, 2018 at 01:46:05PM -0800, Kyle Huey wrote: > On Tue, Nov 20, 2018 at 1:18 PM Andi Kleen wrote: > > > > > I suppose that's fair that it's better for some use cases. The flip > > > side is that it's no longer possible to get exactly accurate counts > > > from user space if you're

Re: [REGRESSION] x86, perf: counter freezing breaks rr

2018-11-20 Thread Peter Zijlstra
On Tue, Nov 20, 2018 at 12:11:44PM -0800, Andi Kleen wrote: > > > > Given that we're already at rc3, and that this renders rr unusable, > > > > we'd ask that counter freezing be disabled for the 4.20 release. > > > > > > The boot option should be good enough for the release? > > > > I'm not

Re: [REGRESSION] x86, perf: counter freezing breaks rr

2018-11-20 Thread Peter Zijlstra
On Tue, Nov 20, 2018 at 12:11:44PM -0800, Andi Kleen wrote: > > > > Given that we're already at rc3, and that this renders rr unusable, > > > > we'd ask that counter freezing be disabled for the 4.20 release. > > > > > > The boot option should be good enough for the release? > > > > I'm not

LPC Traffic Shaping w/ BPF Talk - percpu followup

2018-11-20 Thread Dennis Zhou
Hi Eddie, Vlad, and Willem, A few people mentioned to me that you guys were experiencing issues with the percpu memory allocator. I saw the talk slides mention the following two bullets: 1) allocation pattern makes the per cpu allocator reach a highly fragmented state 2) sometimes takes a

LPC Traffic Shaping w/ BPF Talk - percpu followup

2018-11-20 Thread Dennis Zhou
Hi Eddie, Vlad, and Willem, A few people mentioned to me that you guys were experiencing issues with the percpu memory allocator. I saw the talk slides mention the following two bullets: 1) allocation pattern makes the per cpu allocator reach a highly fragmented state 2) sometimes takes a

Re: [PATCH v2 0/4] device property: Add fwnode_get_name() helper

2018-11-20 Thread Rafael J. Wysocki
On Thursday, November 8, 2018 5:51:52 PM CET Heikki Krogerus wrote: > Hi, > > This is the second version of my proposal for this helper. The > first version can be checked here: > https://lkml.org/lkml/2018/11/5/326 > > In order to support also ACPI properly, I decided to change the API. > The

Re: [PATCH v2 0/4] device property: Add fwnode_get_name() helper

2018-11-20 Thread Rafael J. Wysocki
On Thursday, November 8, 2018 5:51:52 PM CET Heikki Krogerus wrote: > Hi, > > This is the second version of my proposal for this helper. The > first version can be checked here: > https://lkml.org/lkml/2018/11/5/326 > > In order to support also ACPI properly, I decided to change the API. > The

[GIT PULL] MIPS fixes for v4.20-rc4

2018-11-20 Thread Paul Burton
Hi Linus, Here are a few MIPS fixes for v4.20-rc4, please pull. Thanks, Paul The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad: Linux 4.20-rc2 (2018-11-11 17:12:31 -0600) are available in the Git repository at:

[GIT PULL] MIPS fixes for v4.20-rc4

2018-11-20 Thread Paul Burton
Hi Linus, Here are a few MIPS fixes for v4.20-rc4, please pull. Thanks, Paul The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad: Linux 4.20-rc2 (2018-11-11 17:12:31 -0600) are available in the Git repository at:

Re: [REGRESSION] x86, perf: counter freezing breaks rr

2018-11-20 Thread Kyle Huey
On Tue, Nov 20, 2018 at 1:18 PM Andi Kleen wrote: > > > I suppose that's fair that it's better for some use cases. The flip > > side is that it's no longer possible to get exactly accurate counts > > from user space if you're using the PMI (because any events between > > the overflow itself and

Re: [REGRESSION] x86, perf: counter freezing breaks rr

2018-11-20 Thread Kyle Huey
On Tue, Nov 20, 2018 at 1:18 PM Andi Kleen wrote: > > > I suppose that's fair that it's better for some use cases. The flip > > side is that it's no longer possible to get exactly accurate counts > > from user space if you're using the PMI (because any events between > > the overflow itself and

Re: [PATCH 2/8] pstore: Do not use crash buffer for decompression

2018-11-20 Thread Joel Fernandes
On Wed, Nov 14, 2018 at 01:56:09AM -0600, Kees Cook wrote: > On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes wrote: > > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote: > >> static void decompress_record(struct pstore_record *record) > >> { > >> + int ret; > >> int

Re: [PATCH 2/8] pstore: Do not use crash buffer for decompression

2018-11-20 Thread Joel Fernandes
On Wed, Nov 14, 2018 at 01:56:09AM -0600, Kees Cook wrote: > On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes wrote: > > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote: > >> static void decompress_record(struct pstore_record *record) > >> { > >> + int ret; > >> int

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