[git pull] drm fixes for 4.17-rc4

Hi, This seems eerily quiet, so I expect it will explode next week or something. One i915 moduel firmware, two vmwgfx fixes, one vc4 fix and one bridge leak fix. Dave. The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64: Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)

[git pull] drm fixes for 4.17-rc4

Hi, This seems eerily quiet, so I expect it will explode next week or something. One i915 moduel firmware, two vmwgfx fixes, one vc4 fix and one bridge leak fix. Dave. The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64: Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)

Re: [PATCH v2] mfd: qcom-spmi-pmic: Add support for pm8005,pm8998,pmi8998

On Wed 02 May 09:35 PDT 2018, Stephen Boyd wrote: > Add the compatibles and PMIC ids for the pm8005, pm8998, and pmi8998 > PMICS found on MSM8998 and SDM845 based platforms. > > Cc: > Reviewed-by: Rob Herring > Reviewed-by: Doug Anderson

Re: [PATCH v2] mfd: qcom-spmi-pmic: Add support for pm8005,pm8998,pmi8998

On Wed 02 May 09:35 PDT 2018, Stephen Boyd wrote: > Add the compatibles and PMIC ids for the pm8005, pm8998, and pmi8998 > PMICS found on MSM8998 and SDM845 based platforms. > > Cc: > Reviewed-by: Rob Herring > Reviewed-by: Doug Anderson > Signed-off-by: Stephen Boyd > --- > > Changes from

Re: [PATCH] net: disable UDP punt on sockets in RCV_SHUTDWON

On 05/04/2018 02:08 PM, Chintan Shah wrote: > A UDP application which opens multiple sockets with same local > address/port combination (using SO_REUSEPORT/SO_REUSEADDR socket options); > and issues connect to a remote socket (using one of these local socket). > Now if the same socket, which

Re: [PATCH] net: disable UDP punt on sockets in RCV_SHUTDWON

On 05/04/2018 02:08 PM, Chintan Shah wrote: > A UDP application which opens multiple sockets with same local > address/port combination (using SO_REUSEPORT/SO_REUSEADDR socket options); > and issues connect to a remote socket (using one of these local socket). > Now if the same socket, which

Re: [PATCH v2] KVM: X86: Limit timer frequency to 200ms

ping, 2018-05-01 7:35 GMT+08:00 Wanpeng Li : > From: Wanpeng Li > > Anthoine reported: > The period used by Windows change over time but it can be 1 milliseconds > or less. I saw the limit_periodic_timer_frequency print so 500 > microseconds is

Re: [PATCH v2] KVM: X86: Limit timer frequency to 200ms

ping, 2018-05-01 7:35 GMT+08:00 Wanpeng Li : > From: Wanpeng Li > > Anthoine reported: > The period used by Windows change over time but it can be 1 milliseconds > or less. I saw the limit_periodic_timer_frequency print so 500 > microseconds is sometimes reached. > > As suggested by Paolo,

Re: rcu-bh design

On Fri, May 04, 2018 at 04:20:41PM -0700, Joel Fernandes wrote: > > > On 05/04/2018 03:49 PM, Paul E. McKenney wrote: > >>Yes just one more ;-). I am trying to write a 'probetorture' test inspired > >>by RCU torture that whacks the tracepoints in various scenarios. One of the > >>things I want

Re: rcu-bh design

On Fri, May 04, 2018 at 04:20:41PM -0700, Joel Fernandes wrote: > > > On 05/04/2018 03:49 PM, Paul E. McKenney wrote: > >>Yes just one more ;-). I am trying to write a 'probetorture' test inspired > >>by RCU torture that whacks the tracepoints in various scenarios. One of the > >>things I want

Re: [PATCH V2 1/5] X86: Hyper-V: Enlighten APIC access

Hi Srinivasan, I love your patch! Yet something to improve: [auto build test ERROR on v4.17-rc3] [also build test ERROR on next-20180504] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH V2 1/5] X86: Hyper-V: Enlighten APIC access

Hi Srinivasan, I love your patch! Yet something to improve: [auto build test ERROR on v4.17-rc3] [also build test ERROR on next-20180504] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [Ksummit-discuss] bug-introducing patches

On Fri, May 04, 2018 at 09:51:14PM +, Sasha Levin wrote: > I don't have an objection to moving this to it's own tag. It will make > my scripts somewhat simpler for sure. It's not a matter "moving this it's own tag", but creating a new tag --- because what is in the docs is a lie. It does not

Re: [Ksummit-discuss] bug-introducing patches

On Fri, May 04, 2018 at 09:51:14PM +, Sasha Levin wrote: > I don't have an objection to moving this to it's own tag. It will make > my scripts somewhat simpler for sure. It's not a matter "moving this it's own tag", but creating a new tag --- because what is in the docs is a lie. It does not

Re: [PATCH] soc: qcom: qmi: fix a buffer sizing bug

On Fri 27 Apr 07:08 PDT 2018, Alex Elder wrote: > In qmi_handle_init(), a buffer is allocated for to hold messages > received through the handle's socket. Any "normal" messages > (expected by the caller) will have a header prepended, so the > buffer size is adjusted to accomodate that. > > The

Re: [PATCH] soc: qcom: qmi: fix a buffer sizing bug

On Fri 27 Apr 07:08 PDT 2018, Alex Elder wrote: > In qmi_handle_init(), a buffer is allocated for to hold messages > received through the handle's socket. Any "normal" messages > (expected by the caller) will have a header prepended, so the > buffer size is adjusted to accomodate that. > > The

Re: [RFC PATCH v4 2/3] acpi: apei: Rename ghes_severity() to ghes_cper_severity()

On 05/04/2018 06:56 AM, Shiju Jose wrote: Hi Alex, Hi -Original Message- From: Alexandru Gagniuc [mailto:mr.nuke...@gmail.com] [snip] -static inline int ghes_severity(int severity) +static inline int ghes_cper_severity(int severity) [...] else

Re: [RFC PATCH v4 2/3] acpi: apei: Rename ghes_severity() to ghes_cper_severity()

On 05/04/2018 06:56 AM, Shiju Jose wrote: Hi Alex, Hi -Original Message- From: Alexandru Gagniuc [mailto:mr.nuke...@gmail.com] [snip] -static inline int ghes_severity(int severity) +static inline int ghes_cper_severity(int severity) [...] else

Re: [PATCH] MAINTAINERS: Update pattern for qcom_scm

On Fri 27 Apr 06:55 PDT 2018, Niklas Cassel wrote: > Update pattern for qcom_scm, so that get_maintainer.pl will show the > correct maintainers + lists, not only for qcom_scm.c, but also for > the files: qcom_scm-32.c, qcom_scm-64.c, qcom_scm.h. > Reviewed-by: Bjorn Andersson

Re: [PATCH] MAINTAINERS: Update pattern for qcom_scm

On Fri 27 Apr 06:55 PDT 2018, Niklas Cassel wrote: > Update pattern for qcom_scm, so that get_maintainer.pl will show the > correct maintainers + lists, not only for qcom_scm.c, but also for > the files: qcom_scm-32.c, qcom_scm-64.c, qcom_scm.h. > Reviewed-by: Bjorn Andersson Regards, Bjorn

Re: [PATCH] percpu_ida: Use _irqsave() instead of local_irq_save() + spin_lock

On Fri, 4 May 2018 17:32:18 +0200 Sebastian Andrzej Siewior wrote: > percpu_ida() decouples disabling interrupts from the locking operations. > This breaks some assumptions if the locking operations are replaced like > they are under -RT. > The same locking can be

Re: [PATCH] percpu_ida: Use _irqsave() instead of local_irq_save() + spin_lock

On Fri, 4 May 2018 17:32:18 +0200 Sebastian Andrzej Siewior wrote: > percpu_ida() decouples disabling interrupts from the locking operations. > This breaks some assumptions if the locking operations are replaced like > they are under -RT. > The same locking can be achieved by avoiding

Re: rcu-bh design

On 05/04/2018 03:49 PM, Paul E. McKenney wrote: Yes just one more ;-). I am trying to write a 'probetorture' test inspired by RCU torture that whacks the tracepoints in various scenarios. One of the things I want to do is verify the RCU callbacks are queued and secondly, they are executed.

Re: rcu-bh design

On 05/04/2018 03:49 PM, Paul E. McKenney wrote: Yes just one more ;-). I am trying to write a 'probetorture' test inspired by RCU torture that whacks the tracepoints in various scenarios. One of the things I want to do is verify the RCU callbacks are queued and secondly, they are executed.

[RFC 2/2] perf: Sharing PMU counters across compatible events

This patch tries to enable PMU sharing. To make perf event scheduling fast, we use special data structures. An array of "struct perf_event_dup" is added to the cpuctx, to remember all the duplicated events under this cpuctx. All the events under this cpuctx has a "dup_id" pointing to its

[RFC 2/2] perf: Sharing PMU counters across compatible events

This patch tries to enable PMU sharing. To make perf event scheduling fast, we use special data structures. An array of "struct perf_event_dup" is added to the cpuctx, to remember all the duplicated events under this cpuctx. All the events under this cpuctx has a "dup_id" pointing to its

[RFC 0/2] perf: Sharing PMU counters across compatible events

This is to follow up earlier discussion on sharing hardware PMU counters across compatible events: https://marc.info/?t=151213803600016 A lot of this set is based on Tejun's work. I also got a lot of ideas and insights from Jiri's version. The major effort in this version is to make perf event

[RFC 1/2] perf: add move_dup() for PMU sharing.

To share PMU across different counters, we need a "master event" that handles interaction with hardware or other software parts. It is necessary to switch master event to another event. To make this move compatible with the PMU, it is necessary to move connection or data from one perf_event to

[RFC 0/2] perf: Sharing PMU counters across compatible events

This is to follow up earlier discussion on sharing hardware PMU counters across compatible events: https://marc.info/?t=151213803600016 A lot of this set is based on Tejun's work. I also got a lot of ideas and insights from Jiri's version. The major effort in this version is to make perf event

[RFC 1/2] perf: add move_dup() for PMU sharing.

To share PMU across different counters, we need a "master event" that handles interaction with hardware or other software parts. It is necessary to switch master event to another event. To make this move compatible with the PMU, it is necessary to move connection or data from one perf_event to

Re: [PATCH v13 3/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index 0c9e392..3c7 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -679,6 +679,7 @@ static void show_smap_vma_flags(struct seq_file *m, > struct vm_area_struct *vma) > [ilog2(VM_PKEY_BIT1)] = "", >

Re: [PATCH v13 3/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index 0c9e392..3c7 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -679,6 +679,7 @@ static void show_smap_vma_flags(struct seq_file *m, > struct vm_area_struct *vma) > [ilog2(VM_PKEY_BIT1)] = "", >

Re: [PATCH v2 10/27] dts: bindings: Restrict coresight tmc-etr scatter-gather mode

On Thu, May 3, 2018 at 3:32 PM, Mathieu Poirier wrote: > On 1 May 2018 at 07:13, Rob Herring wrote: >> On Tue, May 01, 2018 at 10:10:40AM +0100, Suzuki K Poulose wrote: >>> We are about to add the support for ETR builtin scatter-gather mode >>> for

Re: [PATCH v2 10/27] dts: bindings: Restrict coresight tmc-etr scatter-gather mode

On Thu, May 3, 2018 at 3:32 PM, Mathieu Poirier wrote: > On 1 May 2018 at 07:13, Rob Herring wrote: >> On Tue, May 01, 2018 at 10:10:40AM +0100, Suzuki K Poulose wrote: >>> We are about to add the support for ETR builtin scatter-gather mode >>> for dealing with large amount of trace buffers.

Re: rcu-bh design

On Fri, May 04, 2018 at 08:33:19PM +, Joel Fernandes wrote: > On Fri, May 4, 2018 at 1:10 PM Paul E. McKenney > wrote: > [...] > > > >> > Almost. All context switches in an RCU-preempt read-side critical > section > > > >> > must be subject to priority boosting.

Re: rcu-bh design

On Fri, May 04, 2018 at 08:33:19PM +, Joel Fernandes wrote: > On Fri, May 4, 2018 at 1:10 PM Paul E. McKenney > wrote: > [...] > > > >> > Almost. All context switches in an RCU-preempt read-side critical > section > > > >> > must be subject to priority boosting. Preemption is one example, >

[PATCH v2 1/2] scsi: ufs: Extract devfreq registration

Failing to register with devfreq leaves hba->devfreq assigned, which causes the error path to dereference the ERR_PTR(). Rather than bolting on more conditionals, move the call of devm_devfreq_add_device() into it's own function and only update hba->devfreq once it's successfully registered. The

[PATCH v2 1/2] scsi: ufs: Extract devfreq registration

Failing to register with devfreq leaves hba->devfreq assigned, which causes the error path to dereference the ERR_PTR(). Rather than bolting on more conditionals, move the call of devm_devfreq_add_device() into it's own function and only update hba->devfreq once it's successfully registered. The

[PATCH v2 0/2] Fix UFS and devfreq interaction

With the introduction of f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency") the UFS host controller driver (UFSHCD) stopped probing for platforms that supports frequency scaling, e.g. all modern Qualcomm platforms. The cause of this was UFSHCD's reliance of not registering any

[PATCH v2 0/2] Fix UFS and devfreq interaction

With the introduction of f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency") the UFS host controller driver (UFSHCD) stopped probing for platforms that supports frequency scaling, e.g. all modern Qualcomm platforms. The cause of this was UFSHCD's reliance of not registering any

[PATCH v2 2/2] scsi: ufs: Use freq table with devfreq

devfreq requires that the client operates on actual frequencies, not only 0 and UMAX_INT and as such UFS brok with the introduction of f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency"). This patch registers the frequencies of the first clock as opp levels and use these to

[PATCH v2 2/2] scsi: ufs: Use freq table with devfreq

devfreq requires that the client operates on actual frequencies, not only 0 and UMAX_INT and as such UFS brok with the introduction of f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency"). This patch registers the frequencies of the first clock as opp levels and use these to

Re: [PATCH bpf-next 09/10] tools: bpftool: add simple perf event output reader

CC perf folks On Fri, 4 May 2018 14:25:03 -0700, Alexei Starovoitov wrote: > > +static void > > +perf_event_read(struct event_ring_info *ring, void **buf, size_t *buf_len) > > +{ > > + volatile struct perf_event_mmap_page *header = ring->mem; > > + __u64 buffer_size = MMAP_PAGE_CNT *

Re: [PATCH bpf-next 09/10] tools: bpftool: add simple perf event output reader

CC perf folks On Fri, 4 May 2018 14:25:03 -0700, Alexei Starovoitov wrote: > > +static void > > +perf_event_read(struct event_ring_info *ring, void **buf, size_t *buf_len) > > +{ > > + volatile struct perf_event_mmap_page *header = ring->mem; > > + __u64 buffer_size = MMAP_PAGE_CNT *

Re: [RFC PATCH for 4.18 00/14] Restartable Sequences

Hey - I think the ideas Daniel brings up here are interesting -- specifically the notion that a thread could set a "pre-sleep wish" to signal it's sleeping. As this conversation shows I think there's a fair bit of depth to that. For example, the FUTEX_LOCK is an alternative approach. Another

Re: [RFC PATCH for 4.18 00/14] Restartable Sequences

Hey - I think the ideas Daniel brings up here are interesting -- specifically the notion that a thread could set a "pre-sleep wish" to signal it's sleeping. As this conversation shows I think there's a fair bit of depth to that. For example, the FUTEX_LOCK is an alternative approach. Another

Re: [PATCH 4.4 15/50] s390/alternative: use a copy of the facility bit mask

On Fri, May 04, 2018 at 09:37:20AM +0200, Jiri Slaby wrote: > On 04/27/2018, 03:58 PM, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Martin Schwidefsky > > > > > > [

Re: [PATCH 4.4 15/50] s390/alternative: use a copy of the facility bit mask

On Fri, May 04, 2018 at 09:37:20AM +0200, Jiri Slaby wrote: > On 04/27/2018, 03:58 PM, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Martin Schwidefsky > > > > > > [ Upstream commit

Re: [PATCH v7 06/13] KVM: x86: Add Intel Processor Trace virtualization mode

On Fri, May 04, 2018 at 11:44:09PM +0200, Paolo Bonzini wrote: > On 04/05/2018 12:45, Peter Zijlstra wrote: > > On Thu, May 03, 2018 at 04:38:23PM +0300, Alexander Shishkin wrote: > >> On Thu, May 03, 2018 at 02:50:12PM +0200, Paolo Bonzini wrote: > > > >>> And you still need the module parameter

Re: [PATCH v7 06/13] KVM: x86: Add Intel Processor Trace virtualization mode

On Fri, May 04, 2018 at 11:44:09PM +0200, Paolo Bonzini wrote: > On 04/05/2018 12:45, Peter Zijlstra wrote: > > On Thu, May 03, 2018 at 04:38:23PM +0300, Alexander Shishkin wrote: > >> On Thu, May 03, 2018 at 02:50:12PM +0200, Paolo Bonzini wrote: > > > >>> And you still need the module parameter

[GIT PULL] xfs: more fixes for 4.17-rc4

Hi Linus, I've got one more bug fix for xfs for 4.17-rc4, which caps the amount of data we try to handle in one dedupe request so that userspace can't livelock the kernel. This series has been run through a full xfstests run during the week and through a quick xfstests run against this morning's

Re: [PATCH] [stable] arm64: Add work around for Arm Cortex-A55 Erratum 1024718

On Tue, May 01, 2018 at 11:26:04AM +0100, Suzuki K Poulose wrote: > commit ece1397cbc89c51914fae1aec729539cfd8bd62b upstream > > Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer > from an erratum 1024718, which causes incorrect updates when DBM/AP > bits in a page table entry is

[GIT PULL] xfs: more fixes for 4.17-rc4

Hi Linus, I've got one more bug fix for xfs for 4.17-rc4, which caps the amount of data we try to handle in one dedupe request so that userspace can't livelock the kernel. This series has been run through a full xfstests run during the week and through a quick xfstests run against this morning's

Re: [PATCH] [stable] arm64: Add work around for Arm Cortex-A55 Erratum 1024718

On Tue, May 01, 2018 at 11:26:04AM +0100, Suzuki K Poulose wrote: > commit ece1397cbc89c51914fae1aec729539cfd8bd62b upstream > > Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer > from an erratum 1024718, which causes incorrect updates when DBM/AP > bits in a page table entry is

**Herzlichen Glückwunsch!

Herzlichen Glückwunsch, Sie haben 650.000 Euro in den monatlichen Gewinnspielen von Euro Millions / Google Promo am 4. Mai 2018 gewonnen. Kontaktieren Sie unseren Schadenregulierungsbeauftragten mit den folgenden Informationen Vollständiger Name: Heimatadresse: Geschlecht: Alter: Besetzung:

**Herzlichen Glückwunsch!

Herzlichen Glückwunsch, Sie haben 650.000 Euro in den monatlichen Gewinnspielen von Euro Millions / Google Promo am 4. Mai 2018 gewonnen. Kontaktieren Sie unseren Schadenregulierungsbeauftragten mit den folgenden Informationen Vollständiger Name: Heimatadresse: Geschlecht: Alter: Besetzung:

Re: v4.4-stable: GPMI nand controller broken

On Fri, May 04, 2018 at 08:56:21AM +0200, Sascha Hauer wrote: > The following went into v4.4.120: > > 197190bc5c48 mtd: nand: gpmi: Fix failure when a erased page has a bitflip at > BBM > > This patch was backported to far for the stable tree. It only makes sense > (and only works) together

Re: v4.4-stable: GPMI nand controller broken

On Fri, May 04, 2018 at 08:56:21AM +0200, Sascha Hauer wrote: > The following went into v4.4.120: > > 197190bc5c48 mtd: nand: gpmi: Fix failure when a erased page has a bitflip at > BBM > > This patch was backported to far for the stable tree. It only makes sense > (and only works) together

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

Hi Sergey, Il 04/05/2018 23:59, Sergey Suloev ha scritto: Hi, Giulio, On 05/05/2018 12:52 AM, Giulio Benetti wrote: Hi Maxime! Il 04/05/2018 10:06, Maxime Ripard ha scritto: Hi, On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote: You don't have to handcode the fragments

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

Hi Sergey, Il 04/05/2018 23:59, Sergey Suloev ha scritto: Hi, Giulio, On 05/05/2018 12:52 AM, Giulio Benetti wrote: Hi Maxime! Il 04/05/2018 10:06, Maxime Ripard ha scritto: Hi, On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote: You don't have to handcode the fragments

[PATCH] arm64: dts: qcom: sdm845: Sort nodes in the soc by address

This is pure-churn and should be a no-op. I'm doing it in the hopes of reducing merge conflicts. When things are sorted in a sane way (and by base address seems sane) then it's less likely that future patches will cause merge conflicts. Signed-off-by: Douglas Anderson

[PATCH] arm64: dts: qcom: sdm845: Sort nodes in the soc by address

This is pure-churn and should be a no-op. I'm doing it in the hopes of reducing merge conflicts. When things are sorted in a sane way (and by base address seems sane) then it's less likely that future patches will cause merge conflicts. Signed-off-by: Douglas Anderson ---

Re: [PATCH v2 4/4] smack: provide socketpair callback

On 5/4/2018 7:28 AM, David Herrmann wrote: > From: Tom Gundersen > > Make sure to implement the new socketpair callback so the SO_PEERSEC > call on socketpair(2)s will return correct information. > > Signed-off-by: Tom Gundersen > Signed-off-by: David Herrmann

Re: [PATCH v2 4/4] smack: provide socketpair callback

On 5/4/2018 7:28 AM, David Herrmann wrote: > From: Tom Gundersen > > Make sure to implement the new socketpair callback so the SO_PEERSEC > call on socketpair(2)s will return correct information. > > Signed-off-by: Tom Gundersen > Signed-off-by: David Herrmann This doesn't look like it will

[PATCH v11 3/3] mm, x86, powerpc: display pkey in smaps only if arch supports pkeys

Currently the architecture specific code is expected to display the protection keys in smap for a given vma. This can lead to redundant code and possibly to divergent formats in which the key gets displayed. This patch changes the implementation. It displays the pkey only if the

[PATCH v11 3/3] mm, x86, powerpc: display pkey in smaps only if arch supports pkeys

Currently the architecture specific code is expected to display the protection keys in smap for a given vma. This can lead to redundant code and possibly to divergent formats in which the key gets displayed. This patch changes the implementation. It displays the pkey only if the

[PATCH v13 0/3] mm, x86, powerpc: Enhancements to Memory Protection Keys.

This patch series provides arch-neutral enhancements to enable memory-keys on new architecutes, and the corresponding changes in x86 and powerpc specific code to support that. a) Provides ability to support upto 32 keys. PowerPC can handle 32 keys and hence needs this. b) Arch-neutral

[PATCH v13 0/3] mm, x86, powerpc: Enhancements to Memory Protection Keys.

This patch series provides arch-neutral enhancements to enable memory-keys on new architecutes, and the corresponding changes in x86 and powerpc specific code to support that. a) Provides ability to support upto 32 keys. PowerPC can handle 32 keys and hence needs this. b) Arch-neutral

[PATCH v13 3/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

Only 4bits are allocated in the vma flags to hold 16 keys. This is sufficient on x86. PowerPC supports 32 keys, which needs 5bits. Allocate an additional bit. cc: Dave Hansen cc: Michael Ellermen cc: Benjamin Herrenschmidt

[PATCH v13 3/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

Only 4bits are allocated in the vma flags to hold 16 keys. This is sufficient on x86. PowerPC supports 32 keys, which needs 5bits. Allocate an additional bit. cc: Dave Hansen cc: Michael Ellermen cc: Benjamin Herrenschmidt cc: Andrew Morton Reviewed-by: Ingo Molnar Acked-by: Balbir Singh

[PATCH v13 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS is enabled. Powerpc also needs these bits. Hence lets define the VM_PKEY_BITx bits for any architecture that enables CONFIG_ARCH_HAS_PKEYS. cc: Michael Ellermen cc: Benjamin Herrenschmidt

[PATCH v13 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS is enabled. Powerpc also needs these bits. Hence lets define the VM_PKEY_BITx bits for any architecture that enables CONFIG_ARCH_HAS_PKEYS. cc: Michael Ellermen cc: Benjamin Herrenschmidt cc: Andrew Morton Reviewed-by:

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

Hi, Giulio, On 05/05/2018 12:52 AM, Giulio Benetti wrote: Hi Maxime! Il 04/05/2018 10:06, Maxime Ripard ha scritto: Hi, On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote: You don't have to handcode the fragments anymore with the new syntax, and U-Boot makes it really trivial to

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

Hi, Giulio, On 05/05/2018 12:52 AM, Giulio Benetti wrote: Hi Maxime! Il 04/05/2018 10:06, Maxime Ripard ha scritto: Hi, On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote: You don't have to handcode the fragments anymore with the new syntax, and U-Boot makes it really trivial to

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

Hi Maxime! Il 04/05/2018 10:06, Maxime Ripard ha scritto: Hi, On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote: You don't have to handcode the fragments anymore with the new syntax, and U-Boot makes it really trivial to use if you use the FIT image format to have multiple

Re: [PATCH v7 06/13] KVM: x86: Add Intel Processor Trace virtualization mode

On 04/05/2018 12:38, Alexander Shishkin wrote: >>> Or rather a parameter to decide who wins in case both host and guest want >>> to trace the guest. That's arguably better than having different versions of >>> PT in the guest depending on a module parameter setting. >> It's not different versions;

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

Hi Maxime! Il 04/05/2018 10:06, Maxime Ripard ha scritto: Hi, On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote: You don't have to handcode the fragments anymore with the new syntax, and U-Boot makes it really trivial to use if you use the FIT image format to have multiple

Re: [PATCH v7 06/13] KVM: x86: Add Intel Processor Trace virtualization mode

On 04/05/2018 12:38, Alexander Shishkin wrote: >>> Or rather a parameter to decide who wins in case both host and guest want >>> to trace the guest. That's arguably better than having different versions of >>> PT in the guest depending on a module parameter setting. >> It's not different versions;

Re: [Ksummit-discuss] bug-introducing patches

On Fri, May 04, 2018 at 02:38:01PM -0700, James Bottomley wrote: >On Fri, 2018-05-04 at 17:13 -0400, Theodore Y. Ts'o wrote: >> If it's not necessary, fine.  But we should still delete what is >> currently documented in stable_kernel_rules and was introduced in >> 8e9b9362266d, because it doesn't

Re: [Ksummit-discuss] bug-introducing patches

On Fri, May 04, 2018 at 02:38:01PM -0700, James Bottomley wrote: >On Fri, 2018-05-04 at 17:13 -0400, Theodore Y. Ts'o wrote: >> If it's not necessary, fine.  But we should still delete what is >> currently documented in stable_kernel_rules and was introduced in >> 8e9b9362266d, because it doesn't

Re: Proof-of-concept: better(?) page-table manipulation API

On Fri, May 04, 2018 at 09:12:44PM +, Matthew Wilcox wrote: > On Tue, Apr 24, 2018 at 06:43:56PM +0300, Kirill A. Shutemov wrote: > > +struct pt_ptr { > > + unsigned long *ptr; > > + int lvl; > > +}; > > On x86, you've got three kinds of paging scheme, referred to in the manual > as

Re: Proof-of-concept: better(?) page-table manipulation API

On Fri, May 04, 2018 at 09:12:44PM +, Matthew Wilcox wrote: > On Tue, Apr 24, 2018 at 06:43:56PM +0300, Kirill A. Shutemov wrote: > > +struct pt_ptr { > > + unsigned long *ptr; > > + int lvl; > > +}; > > On x86, you've got three kinds of paging scheme, referred to in the manual > as

Re: [PATCH v7 09/13] KVM: x86: Implement Intel Processor Trace context switch

On 04/05/2018 12:29, Alexander Shishkin wrote: > On Thu, May 03, 2018 at 08:08:39PM +0800, Luwei Kang wrote: >> +static void pt_guest_enter(struct vcpu_vmx *vmx) >> +{ >> +if (pt_mode == PT_MODE_HOST || pt_mode == PT_MODE_HOST_GUEST) >> +rdmsrl(MSR_IA32_RTIT_CTL,

Re: [PATCH v7 09/13] KVM: x86: Implement Intel Processor Trace context switch

On 04/05/2018 12:29, Alexander Shishkin wrote: > On Thu, May 03, 2018 at 08:08:39PM +0800, Luwei Kang wrote: >> +static void pt_guest_enter(struct vcpu_vmx *vmx) >> +{ >> +if (pt_mode == PT_MODE_HOST || pt_mode == PT_MODE_HOST_GUEST) >> +rdmsrl(MSR_IA32_RTIT_CTL,

Re: [PATCH v7 13/13] KVM: x86: Disable Intel Processor Trace when VMXON in L1 guest

On 04/05/2018 12:23, Alexander Shishkin wrote: >> Currently, Intel Processor Trace do not support tracing in L1 guest >> VMX operation(IA32_VMX_MISC[bit 14] is 0). As mentioned in SDM, > I don't understand this patch. You mention VMX_MISC[14] here, but I > can't see anything related to it in the

Re: [PATCH v7 13/13] KVM: x86: Disable Intel Processor Trace when VMXON in L1 guest

On 04/05/2018 12:23, Alexander Shishkin wrote: >> Currently, Intel Processor Trace do not support tracing in L1 guest >> VMX operation(IA32_VMX_MISC[bit 14] is 0). As mentioned in SDM, > I don't understand this patch. You mention VMX_MISC[14] here, but I > can't see anything related to it in the

Re: [PATCH v7 11/13] KVM: x86: Implement Intel Processor Trace MSRs read/write

On 04/05/2018 12:11, Alexander Shishkin wrote: >> + */ >> +if ((data & RTIT_CTL_TRACEEN) && !(data & RTIT_CTL_TOPA) && >> +!(data & RTIT_CTL_FABRIC_EN) && >> +!__pt_cap_get(vmx->pt_desc.caps, PT_CAP_single_range_output)) > You seem to be doing a lot of

Re: [PATCH v7 11/13] KVM: x86: Implement Intel Processor Trace MSRs read/write

On 04/05/2018 12:11, Alexander Shishkin wrote: >> + */ >> +if ((data & RTIT_CTL_TRACEEN) && !(data & RTIT_CTL_TOPA) && >> +!(data & RTIT_CTL_FABRIC_EN) && >> +!__pt_cap_get(vmx->pt_desc.caps, PT_CAP_single_range_output)) > You seem to be doing a lot of

Re: Motorola Droid 4 progress, power consumption

Hi! > > But I guess I can sample charge_counter every minute or so and get > > what I need? > > Not sure what the max time range is for the PMIC, but yeah I'd > assume once a minute is duoable. Maybe compare it to the chart > you already have? Yes, I can try some more graph painting. OTOH...

Re: Motorola Droid 4 progress, power consumption

Hi! > > But I guess I can sample charge_counter every minute or so and get > > what I need? > > Not sure what the max time range is for the PMIC, but yeah I'd > assume once a minute is duoable. Maybe compare it to the chart > you already have? Yes, I can try some more graph painting. OTOH...

Re: [PATCH v7 06/13] KVM: x86: Add Intel Processor Trace virtualization mode

On 04/05/2018 12:45, Peter Zijlstra wrote: > On Thu, May 03, 2018 at 04:38:23PM +0300, Alexander Shishkin wrote: >> On Thu, May 03, 2018 at 02:50:12PM +0200, Paolo Bonzini wrote: > >>> And you still need the module parameter to decide >>> whether the host is _allowed_ to cause incomplete traces

Re: [PATCH v7 06/13] KVM: x86: Add Intel Processor Trace virtualization mode

On 04/05/2018 12:45, Peter Zijlstra wrote: > On Thu, May 03, 2018 at 04:38:23PM +0300, Alexander Shishkin wrote: >> On Thu, May 03, 2018 at 02:50:12PM +0200, Paolo Bonzini wrote: > >>> And you still need the module parameter to decide >>> whether the host is _allowed_ to cause incomplete traces

Re: [PATCH] cxgb4vf: fix t4vf_eth_xmit()'s return type

| From: Luc Van Oostenryck | Sent: Tuesday, April 24, 2018 6:19:02 AM | | The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', | which is a typedef for an enum type, but the implementation in this | driver returns an 'int'. | | Fix this by returning

Re: [PATCH] cxgb4vf: fix t4vf_eth_xmit()'s return type

| From: Luc Van Oostenryck | Sent: Tuesday, April 24, 2018 6:19:02 AM | | The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', | which is a typedef for an enum type, but the implementation in this | driver returns an 'int'. | | Fix this by returning 'netdev_tx_t' in this driver

Re: [PATCH v7 07/10] drivers: qcom: rpmh: cache sleep/wake state requests

On Wed, May 02, 2018 at 01:37:46PM -0600, Lina Iyer wrote: > Active state requests are sent immediately to the RSC controller, while > sleep and wake state requests are cached in this driver to avoid taxing > the RSC controller repeatedly. The cached values will be sent to the > controller when

Re: [PATCH v7 07/10] drivers: qcom: rpmh: cache sleep/wake state requests

On Wed, May 02, 2018 at 01:37:46PM -0600, Lina Iyer wrote: > Active state requests are sent immediately to the RSC controller, while > sleep and wake state requests are cached in this driver to avoid taxing > the RSC controller repeatedly. The cached values will be sent to the > controller when

Re: [Ksummit-discuss] bug-introducing patches

On Fri, 2018-05-04 at 17:13 -0400, Theodore Y. Ts'o wrote: > If it's not necessary, fine.  But we should still delete what is > currently documented in stable_kernel_rules and was introduced in > 8e9b9362266d, because it doesn't describe current practice. It definitely doesn't seem to describe

Re: [Ksummit-discuss] bug-introducing patches

On Fri, 2018-05-04 at 17:13 -0400, Theodore Y. Ts'o wrote: > If it's not necessary, fine.  But we should still delete what is > currently documented in stable_kernel_rules and was introduced in > 8e9b9362266d, because it doesn't describe current practice. It definitely doesn't seem to describe

Re: [PATCH] Documentation: refcount-vs-atomic: Update reference to LKMM doc.

On Fri, May 04, 2018 at 02:13:59PM -0700, Kees Cook wrote: > On Fri, May 4, 2018 at 2:11 PM, Andrea Parri > wrote: > > The LKMM project has moved to 'tools/memory-model/'. > > > > Signed-off-by: Andrea Parri > > --- > >

Re: [PATCH] Documentation: refcount-vs-atomic: Update reference to LKMM doc.

On Fri, May 04, 2018 at 02:13:59PM -0700, Kees Cook wrote: > On Fri, May 4, 2018 at 2:11 PM, Andrea Parri > wrote: > > The LKMM project has moved to 'tools/memory-model/'. > > > > Signed-off-by: Andrea Parri > > --- > > Documentation/core-api/refcount-vs-atomic.rst | 2 +- > > 1 file changed, 1

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