[PATCH v3 03/10] perf tools: Add processing of coresight metadata

From: Tor Jeremiassen The auxtrace_info section contains metadata that describes the number of trace capable CPUs, their ETM version and trace configuration, including trace id values. This information is required by the trace decoder in order to properly decode the compressed trace

[PATCH v3 03/10] perf tools: Add processing of coresight metadata

From: Tor Jeremiassen The auxtrace_info section contains metadata that describes the number of trace capable CPUs, their ETM version and trace configuration, including trace id values. This information is required by the trace decoder in order to properly decode the compressed trace packets.

[PATCH v3 01/10] perf tools: Integrating the CoreSight decoding library

The Open CoreSight Decoding Library (openCSD) is a free and open library to decode traces collected by the CoreSight hardware infrastructure. This patch adds the required mechanic to recognise the presence of the openCSD library on a system and set up miscellaneous flags to be used in the

[PATCH v3 01/10] perf tools: Integrating the CoreSight decoding library

The Open CoreSight Decoding Library (openCSD) is a free and open library to decode traces collected by the CoreSight hardware infrastructure. This patch adds the required mechanic to recognise the presence of the openCSD library on a system and set up miscellaneous flags to be used in the

[PATCH v3 05/10] perf tools: Add support for decoding CoreSight trace data

Adding functionality to create a CoreSight trace decoder capable of decoding trace data pushed by a client application. Co-authored-by: Tor Jeremiassen Signed-off-by: Mathieu Poirier --- tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 119

[PATCH v3 05/10] perf tools: Add support for decoding CoreSight trace data

Adding functionality to create a CoreSight trace decoder capable of decoding trace data pushed by a client application. Co-authored-by: Tor Jeremiassen Signed-off-by: Mathieu Poirier --- tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 119 1 file changed, 119

Re: [tip:x86/pti] x86/cpu/AMD: Use LFENCE_RDTSC instead of MFENCE_RDTSC

On 17/01/2018 18:21, Tom Lendacky wrote: > On 1/8/2018 11:01 AM, Paolo Bonzini wrote: >> On 08/01/2018 17:48, Dr. David Alan Gilbert wrote: If your hypervisor is lying to you about the primary family, then all bets are off.  I don't expect there will be any production systems doing

Re: [tip:x86/pti] x86/cpu/AMD: Use LFENCE_RDTSC instead of MFENCE_RDTSC

On 17/01/2018 18:21, Tom Lendacky wrote: > On 1/8/2018 11:01 AM, Paolo Bonzini wrote: >> On 08/01/2018 17:48, Dr. David Alan Gilbert wrote: If your hypervisor is lying to you about the primary family, then all bets are off.  I don't expect there will be any production systems doing

Re: [PATCH for 4.16 07/11] x86: Implement sync_core_before_usermode (v3)

On Wed, Jan 17, 2018 at 8:54 AM, Mathieu Desnoyers wrote: > Ensure that a core serializing instruction is issued before returning to > user-mode. x86 implements return to user-space through sysexit, sysrel, > and sysretq, which are not core serializing. > >

Re: [PATCH for 4.16 07/11] x86: Implement sync_core_before_usermode (v3)

On Wed, Jan 17, 2018 at 8:54 AM, Mathieu Desnoyers wrote: > Ensure that a core serializing instruction is issued before returning to > user-mode. x86 implements return to user-space through sysexit, sysrel, > and sysretq, which are not core serializing. > > Signed-off-by: Mathieu Desnoyers >

[PATCH v3 07/10] pert tools: Add queue management functionality

Add functionatlity to setup trace queues so that traces associated with CoreSight auxtrace events found in the perf.data file can be classified properly. The decoder and memory callback associated with each queue are then used to decode the traces that have been assigned to that queue.

[PATCH v3 07/10] pert tools: Add queue management functionality

Add functionatlity to setup trace queues so that traces associated with CoreSight auxtrace events found in the perf.data file can be classified properly. The decoder and memory callback associated with each queue are then used to decode the traces that have been assigned to that queue.

[PATCH v3 08/10] perf tools: Add full support for CoreSight trace decoding

This patch adds support for complete packet decoding, allowing traces collected during a trace session to be decoder from the "report" infrastructure. Co-authored-by: Tor Jeremiassen Signed-off-by: Mathieu Poirier --- tools/perf/util/cs-etm.c | 166

[PATCH v3 08/10] perf tools: Add full support for CoreSight trace decoding

This patch adds support for complete packet decoding, allowing traces collected during a trace session to be decoder from the "report" infrastructure. Co-authored-by: Tor Jeremiassen Signed-off-by: Mathieu Poirier --- tools/perf/util/cs-etm.c | 166

[PATCH v3 10/10] MAINTAINERS: Adding entry for CoreSight trace decoding

From: Tor Jeremiassen Adding maintainers for Coresight trace decoding via perf tools. Signed-off-by: Tor Jeremiassen --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index d76af75a653a..7eafa087dda3

[PATCH v3 10/10] MAINTAINERS: Adding entry for CoreSight trace decoding

From: Tor Jeremiassen Adding maintainers for Coresight trace decoding via perf tools. Signed-off-by: Tor Jeremiassen --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index d76af75a653a..7eafa087dda3 100644 --- a/MAINTAINERS +++

[PATCH v3 09/10] perf tools: Add mechanic to synthesise CoreSight trace packets

Once decoded from trace packets information on trace range needs to be communicated to the perf synthesis infrastructure so that it is available to the perf tools built-in rendering tools and scripts. Co-authored-by: Tor Jeremiassen Signed-off-by: Mathieu Poirier

[PATCH v3 09/10] perf tools: Add mechanic to synthesise CoreSight trace packets

Once decoded from trace packets information on trace range needs to be communicated to the perf synthesis infrastructure so that it is available to the perf tools built-in rendering tools and scripts. Co-authored-by: Tor Jeremiassen Signed-off-by: Mathieu Poirier --- tools/perf/util/cs-etm.c |

[PATCH v3 04/10] perf tools: Add decoder mechanic to support dumping trace data

This patch adds the required interface to the openCSD library to support dumping CoreSight trace packet using the "report --dump" command. The information conveyed is related to the type of packets gathered by a trace session rather than full decoding. Co-authored-by: Tor Jeremiassen

[PATCH v3 04/10] perf tools: Add decoder mechanic to support dumping trace data

This patch adds the required interface to the openCSD library to support dumping CoreSight trace packet using the "report --dump" command. The information conveyed is related to the type of packets gathered by a trace session rather than full decoding. Co-authored-by: Tor Jeremiassen

[PATCH v3 06/10] perf tools: Add functionality to communicate with the openCSD decoder

This patch adds functions to communicate with the openCSD trace decoder, more specifically to access program memory, fetch trace packets and reset the decoder. Co-authored-by: Tor Jeremiassen Signed-off-by: Mathieu Poirier ---

[PATCH v3 06/10] perf tools: Add functionality to communicate with the openCSD decoder

This patch adds functions to communicate with the openCSD trace decoder, more specifically to access program memory, fetch trace packets and reset the decoder. Co-authored-by: Tor Jeremiassen Signed-off-by: Mathieu Poirier --- tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 60

[PATCH v3 02/10] perf tools: Add initial entry point for decoder CoreSight traces

This patch adds the entry point for CoreSight trace decoding, serving as a jumping board for furhter expansions. Co-authored-by: Tor Jeremiassen Signed-off-by: Mathieu Poirier --- tools/perf/util/Build | 5 ++ tools/perf/util/auxtrace.c | 2 +

[PATCH v3 02/10] perf tools: Add initial entry point for decoder CoreSight traces

This patch adds the entry point for CoreSight trace decoding, serving as a jumping board for furhter expansions. Co-authored-by: Tor Jeremiassen Signed-off-by: Mathieu Poirier --- tools/perf/util/Build | 5 ++ tools/perf/util/auxtrace.c | 2 + tools/perf/util/cs-etm.c | 213

[PATCH v3 00/10] perf tools: Add support for CoreSight trace decoding

Hi Arnaldo, This patchset adds support for per-thread CoreSight trace decoding from the "perf report" interface. It is largely modelled on what has been done for intelPT traces and currently targets the ETMv4 architecture. Support for cpu-wide scenarios and ETMv3/PTMv1.1 will follow shortly.

[PATCH v3 00/10] perf tools: Add support for CoreSight trace decoding

Hi Arnaldo, This patchset adds support for per-thread CoreSight trace decoding from the "perf report" interface. It is largely modelled on what has been done for intelPT traces and currently targets the ETMv4 architecture. Support for cpu-wide scenarios and ETMv3/PTMv1.1 will follow shortly.

[PATCH v3 00/10] perf tools: Add support for CoreSight trace decoding

Hi Arnaldo, This patchset adds support for per-thread CoreSight trace decoding from the "perf report" interface. It is largely modelled on what has been done for intelPT traces and currently targets the ETMv4 architecture. Support for cpu-wide scenarios and ETMv3/PTMv1.1 will follow shortly.

[PATCH v3 00/10] perf tools: Add support for CoreSight trace decoding

Hi Arnaldo, This patchset adds support for per-thread CoreSight trace decoding from the "perf report" interface. It is largely modelled on what has been done for intelPT traces and currently targets the ETMv4 architecture. Support for cpu-wide scenarios and ETMv3/PTMv1.1 will follow shortly.

Re: [PATCH v2 1/3] Revert "do_SAK: Don't recursively take the tasklist_lock"

Oleg Nesterov writes: > On 01/17, Eric W. Biederman wrote: > >> Kirill Tkhai writes: >> >> > This reverts commit 20ac94378de5. >> > >> > send_sig() does not take tasklist_lock for a long time, >> > so this commit and the problem it solves are not relevant

Re: [PATCH v2 1/3] Revert "do_SAK: Don't recursively take the tasklist_lock"

Oleg Nesterov writes: > On 01/17, Eric W. Biederman wrote: > >> Kirill Tkhai writes: >> >> > This reverts commit 20ac94378de5. >> > >> > send_sig() does not take tasklist_lock for a long time, >> > so this commit and the problem it solves are not relevant >> > anymore. >> > >> > Also, the

Re: [3/5] clk: divider: add divider_ro_round_rate helper

On Thu, 2018-01-11 at 17:08 -0600, David Lechner wrote: > On 01/05/2018 11:09 AM, Jerome Brunet wrote: > > Like divider_round_rate, a couple a of driver are doing more or less > > the same operation to round the rate of the divider when it is read-only. > > > > We can factor this code so let's

Re: [3/5] clk: divider: add divider_ro_round_rate helper

On Thu, 2018-01-11 at 17:08 -0600, David Lechner wrote: > On 01/05/2018 11:09 AM, Jerome Brunet wrote: > > Like divider_round_rate, a couple a of driver are doing more or less > > the same operation to round the rate of the divider when it is read-only. > > > > We can factor this code so let's

[PATCH] pci: Store more data about VFs into the SRIOV struct

... to avoid reading them from the config space of all the PCI VFs. This is specially a useful optimization when bringing up thousands of VFs. Cc: Bjorn Helgaas Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: KarimAllah Ahmed

[PATCH] pci: Store more data about VFs into the SRIOV struct

... to avoid reading them from the config space of all the PCI VFs. This is specially a useful optimization when bringing up thousands of VFs. Cc: Bjorn Helgaas Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: KarimAllah Ahmed --- drivers/pci/iov.c | 20

Re: [PATCH v1 3/3] x86/platform/intel-mid: Add special handling of ACPI HW reduced platforms

On Wed, 2018-01-17 at 19:34 +0200, Andy Shevchenko wrote: > When switching to ACPI HW reduced platforms we still want to > initialize timers. > Override acpi_reduced_hw_init() to achieve that. Just realized, that it may annihilate the other acpi_reduced_hw_init() on non-MID platforms... Open to

Re: [PATCH v1 3/3] x86/platform/intel-mid: Add special handling of ACPI HW reduced platforms

On Wed, 2018-01-17 at 19:34 +0200, Andy Shevchenko wrote: > When switching to ACPI HW reduced platforms we still want to > initialize timers. > Override acpi_reduced_hw_init() to achieve that. Just realized, that it may annihilate the other acpi_reduced_hw_init() on non-MID platforms... Open to

[PATCH v2 2/2] arm64: Run enable method for errata work arounds on late CPUs

When a CPU is brought up after we have finalised the system wide capabilities (i.e, features and errata), we make sure the new CPU doesn't need a new errata work around which has not been detected already. However we don't run enable() method on the new CPU for the errata work arounds already

[PATCH v2 2/2] arm64: Run enable method for errata work arounds on late CPUs

When a CPU is brought up after we have finalised the system wide capabilities (i.e, features and errata), we make sure the new CPU doesn't need a new errata work around which has not been detected already. However we don't run enable() method on the new CPU for the errata work arounds already

[PATCH v2 1/2] arm64: capabilities: Clarify argument passed to enable call back

We issue the enable() call back for all CPU hwcaps capabilities available on the system, on all the CPUs. So far we have ignored the argument passed to the call back, which had a prototype to accept a "void *" for use with on_each_cpu() and later with stop_machine(). However, with commit

[PATCH v2 1/2] arm64: capabilities: Clarify argument passed to enable call back

We issue the enable() call back for all CPU hwcaps capabilities available on the system, on all the CPUs. So far we have ignored the argument passed to the call back, which had a prototype to accept a "void *" for use with on_each_cpu() and later with stop_machine(). However, with commit

[PATCH v2 0/2] arm64: Run enable method for errata work arounds on late CPUs

This v2 of the patch posted here [1]. Following the discussion there, I have included a patch (Patch 1) to clarify the argument passed to @enable() call back for a capability. Original patch (Patch 2) is unchanged. [1]

[PATCH v2 0/2] arm64: Run enable method for errata work arounds on late CPUs

This v2 of the patch posted here [1]. Following the discussion there, I have included a patch (Patch 1) to clarify the argument passed to @enable() call back for a capability. Original patch (Patch 2) is unchanged. [1]

Re: [PATCH v2 3/3] tty: Use RCU read lock to iterate tasks and threads in __do_SAK()

On 01/17, Eric W. Biederman wrote: > > __do_SAK() needs to be 100% accurate. But it can't. A process/thread can open tty right after the check. > I do not see the rcu_read_lock > guaranteeing that new processes created while the process list is being > iterated that happen to have a reference to

Re: [PATCH v2 3/3] tty: Use RCU read lock to iterate tasks and threads in __do_SAK()

On 01/17, Eric W. Biederman wrote: > > __do_SAK() needs to be 100% accurate. But it can't. A process/thread can open tty right after the check. > I do not see the rcu_read_lock > guaranteeing that new processes created while the process list is being > iterated that happen to have a reference to

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Wed, Jan 17, 2018 at 11:24:06AM -0600, Eric W. Biederman wrote: > Dave Martin writes: [...] > > Should si_code simply be ignored for the SIGKILL case? > > I know what x86 does in a similar case is it uses force_sig instead of > force_sig_info. Then the generic code

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Wed, Jan 17, 2018 at 11:24:06AM -0600, Eric W. Biederman wrote: > Dave Martin writes: [...] > > Should si_code simply be ignored for the SIGKILL case? > > I know what x86 does in a similar case is it uses force_sig instead of > force_sig_info. Then the generic code gets to worry about >

Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

On Tue, 16 Jan 2018 23:51:29 +0100 Frederic Weisbecker wrote: > On Tue, Jan 16, 2018 at 11:52:11AM -0500, Luiz Capitulino wrote: > > On Tue, 16 Jan 2018 16:41:00 +0100 > > Frederic Weisbecker wrote: > > > So isolcpus= is now the place where we control

Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

On Tue, 16 Jan 2018 23:51:29 +0100 Frederic Weisbecker wrote: > On Tue, Jan 16, 2018 at 11:52:11AM -0500, Luiz Capitulino wrote: > > On Tue, 16 Jan 2018 16:41:00 +0100 > > Frederic Weisbecker wrote: > > > So isolcpus= is now the place where we control the isolation features > > > and nohz is

Re: [PATCH] Bluetooth: 6lowpan: Fix disconnect bug in 6lowpan

Hi, 2018-01-17 7:15 GMT-05:00 Luiz Augusto von Dentz : > Hi, > > On Wed, Jan 17, 2018 at 1:47 AM, Guo Yi wrote: >> This patch fix the bluetooth 6lowpan disconnect fail bug. >> >> The type of the same address type have different define value in HCI

Re: [PATCH] Bluetooth: 6lowpan: Fix disconnect bug in 6lowpan

Hi, 2018-01-17 7:15 GMT-05:00 Luiz Augusto von Dentz : > Hi, > > On Wed, Jan 17, 2018 at 1:47 AM, Guo Yi wrote: >> This patch fix the bluetooth 6lowpan disconnect fail bug. >> >> The type of the same address type have different define value in HCI layer >> and L2CAP layer.That makes disconnect

[PATCH v1 1/3] ACPI / x86: boot: Not all platforms require acpi_reduced_hw_init()

Some platforms might take care of legacy devices on theirs own. Let's allow them to do that by exporting a weak function. Signed-off-by: Andy Shevchenko --- arch/x86/kernel/acpi/boot.c | 2 +- include/linux/acpi.h| 3 +++ 2 files changed, 4

[PATCH v1 1/3] ACPI / x86: boot: Not all platforms require acpi_reduced_hw_init()

Some platforms might take care of legacy devices on theirs own. Let's allow them to do that by exporting a weak function. Signed-off-by: Andy Shevchenko --- arch/x86/kernel/acpi/boot.c | 2 +- include/linux/acpi.h| 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git

Re: [PATCH v5 19/44] clk: davinci: New driver for TI DA8XX CFGCHIP clocks

On 01/17/2018 09:31 AM, Sekhar Nori wrote: On Monday 08 January 2018 07:47 AM, David Lechner wrote: This adds a new driver for the gate and multiplexer clocks in the CFGCHIPn syscon registers on TI DA8XX-type SoCs. Signed-off-by: David Lechner ---

Re: [PATCH v5 19/44] clk: davinci: New driver for TI DA8XX CFGCHIP clocks

On 01/17/2018 09:31 AM, Sekhar Nori wrote: On Monday 08 January 2018 07:47 AM, David Lechner wrote: This adds a new driver for the gate and multiplexer clocks in the CFGCHIPn syscon registers on TI DA8XX-type SoCs. Signed-off-by: David Lechner --- drivers/clk/davinci/Makefile| 2 +

[PATCH v1 2/3] x86/platform/intel-mid: Move PCI initialization to arch_init()

ACPI redefines x86_init.pci.init when enabled. Though we still need special treatment for MID platforms. Move our specific callback to x86_init.pci.arch_init() and, by calling acpi_noirq_set(), take back a control over IRQ assignment. Signed-off-by: Andy Shevchenko

[PATCH v1 2/3] x86/platform/intel-mid: Move PCI initialization to arch_init()

ACPI redefines x86_init.pci.init when enabled. Though we still need special treatment for MID platforms. Move our specific callback to x86_init.pci.arch_init() and, by calling acpi_noirq_set(), take back a control over IRQ assignment. Signed-off-by: Andy Shevchenko ---

Re: [PATCH v2 1/3] Revert "do_SAK: Don't recursively take the tasklist_lock"

On 01/17, Eric W. Biederman wrote: > Kirill Tkhai writes: > > > This reverts commit 20ac94378de5. > > > > send_sig() does not take tasklist_lock for a long time, > > so this commit and the problem it solves are not relevant > > anymore. > > > > Also, the problem of

Re: [PATCH v2 1/3] Revert "do_SAK: Don't recursively take the tasklist_lock"

On 01/17, Eric W. Biederman wrote: > Kirill Tkhai writes: > > > This reverts commit 20ac94378de5. > > > > send_sig() does not take tasklist_lock for a long time, > > so this commit and the problem it solves are not relevant > > anymore. > > > > Also, the problem of force_sig() is it clears

[PATCH v1 3/3] x86/platform/intel-mid: Add special handling of ACPI HW reduced platforms

When switching to ACPI HW reduced platforms we still want to initialize timers. Override acpi_reduced_hw_init() to achieve that. Signed-off-by: Andy Shevchenko --- arch/x86/platform/intel-mid/intel-mid.c | 9 + 1 file changed, 9 insertions(+) diff

[PATCH v1 3/3] x86/platform/intel-mid: Add special handling of ACPI HW reduced platforms

When switching to ACPI HW reduced platforms we still want to initialize timers. Override acpi_reduced_hw_init() to achieve that. Signed-off-by: Andy Shevchenko --- arch/x86/platform/intel-mid/intel-mid.c | 9 + 1 file changed, 9 insertions(+) diff --git

Re: [PATCH v5 12/44] clk: davinci: Add platform information for TI DA850 PSC

On 01/17/2018 05:57 AM, Sekhar Nori wrote: On Tuesday 16 January 2018 10:51 PM, David Lechner wrote: On 01/16/2018 08:00 AM, Sekhar Nori wrote: On Monday 08 January 2018 07:47 AM, David Lechner wrote: +void __init da850_psc_clk_init(void __iomem *psc0, void __iomem *psc1) +{ +    struct

Re: [PATCH v5 12/44] clk: davinci: Add platform information for TI DA850 PSC

On 01/17/2018 05:57 AM, Sekhar Nori wrote: On Tuesday 16 January 2018 10:51 PM, David Lechner wrote: On 01/16/2018 08:00 AM, Sekhar Nori wrote: On Monday 08 January 2018 07:47 AM, David Lechner wrote: +void __init da850_psc_clk_init(void __iomem *psc0, void __iomem *psc1) +{ +    struct

Re: [PATCH v5 11/44] clk: davinci: Add platform information for TI DA830 PSC

On 01/17/2018 06:18 AM, Sekhar Nori wrote: On Tuesday 16 January 2018 10:46 PM, David Lechner wrote: +static const struct davinci_psc_clk_info da830_psc0_info[] __initconst = { +    LPSC(0, 0, tpcc, pll0_sysclk2, LPSC_ALWAYS_ENABLED), +    LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),

Re: [PATCH v5 11/44] clk: davinci: Add platform information for TI DA830 PSC

On 01/17/2018 06:18 AM, Sekhar Nori wrote: On Tuesday 16 January 2018 10:46 PM, David Lechner wrote: +static const struct davinci_psc_clk_info da830_psc0_info[] __initconst = { +    LPSC(0, 0, tpcc, pll0_sysclk2, LPSC_ALWAYS_ENABLED), +    LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),

Re: [PATCH v7 0/5] x86/KASLR: Add parameter kaslr_mem=nn[KMG]@ss[KMG]

On Wed, 17 Jan 2018 18:53:46 +0800 Chao Fan wrote: > ***Background: > People reported that kaslr may randomly chooses some positions > which are located in movable memory regions. This will break memory > hotplug feature. > > And also on kvm guest with 4GB meory, the

Re: [PATCH v7 0/5] x86/KASLR: Add parameter kaslr_mem=nn[KMG]@ss[KMG]

On Wed, 17 Jan 2018 18:53:46 +0800 Chao Fan wrote: > ***Background: > People reported that kaslr may randomly chooses some positions > which are located in movable memory regions. This will break memory > hotplug feature. > > And also on kvm guest with 4GB meory, the good unfragmented 1GB

Re: [PATCH v2 1/2] nvmem: add driver for JZ4780 efuse

Hi Rob, On 11 January 2018 at 20:38, Rob Herring wrote: > On Sat, Jan 6, 2018 at 6:43 AM, PrasannaKumar Muralidharan > wrote: >> Hi Rob, >> >> On 4 January 2018 at 01:32, Rob Herring wrote: >>> On Thu, Dec 28, 2017 at 10:29:52PM

Re: [PATCH v2 1/2] nvmem: add driver for JZ4780 efuse

Hi Rob, On 11 January 2018 at 20:38, Rob Herring wrote: > On Sat, Jan 6, 2018 at 6:43 AM, PrasannaKumar Muralidharan > wrote: >> Hi Rob, >> >> On 4 January 2018 at 01:32, Rob Herring wrote: >>> On Thu, Dec 28, 2017 at 10:29:52PM +0100, Mathieu Malaterre wrote: From: PrasannaKumar

Re: [PATCH v5 10/44] clk: davinci: New driver for davinci PSC clocks

On 01/17/2018 06:25 AM, Sekhar Nori wrote: On Tuesday 16 January 2018 10:21 PM, David Lechner wrote: +static struct clk *davinci_psc_clk_register(const char *name, +    const char *parent_name, +    struct regmap *regmap, +    u32

Re: [PATCH v5 10/44] clk: davinci: New driver for davinci PSC clocks

On 01/17/2018 06:25 AM, Sekhar Nori wrote: On Tuesday 16 January 2018 10:21 PM, David Lechner wrote: +static struct clk *davinci_psc_clk_register(const char *name, +    const char *parent_name, +    struct regmap *regmap, +    u32

[PATCH] kvm: Map PFN-type memory regions as writable (if possible)

For EPT-violations that are triggered by a read, the pages are also mapped with write permissions (if their memory region is also writable). That would avoid getting yet another fault on the same page when a write occurs. This optimization only happens when you have a "struct page" backing the

[PATCH] kvm: Map PFN-type memory regions as writable (if possible)

For EPT-violations that are triggered by a read, the pages are also mapped with write permissions (if their memory region is also writable). That would avoid getting yet another fault on the same page when a write occurs. This optimization only happens when you have a "struct page" backing the

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

Dave Martin writes: > On Mon, Jan 15, 2018 at 11:23:03AM -0600, Eric W. Biederman wrote: >> Dave Martin writes: >> >> > On Thu, Jan 11, 2018 at 06:59:36PM -0600, Eric W. Biederman wrote: > > [...] > >> >> Possible ABI fixes include: >> >> - Send the

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

Dave Martin writes: > On Mon, Jan 15, 2018 at 11:23:03AM -0600, Eric W. Biederman wrote: >> Dave Martin writes: >> >> > On Thu, Jan 11, 2018 at 06:59:36PM -0600, Eric W. Biederman wrote: > > [...] > >> >> Possible ABI fixes include: >> >> - Send the signal without siginfo >> >> - Don't

Re: RCU stall in 8250 serial driver Linux 4.15-rc1

Hi Greg, Sorry for that. Here is the stack trace. C Program below TCP: request_sock_TCP: Possible SYN flooding on port 20003. Sending cookies. Check SNMP counters. TCP: request_sock_TCP: Possible SYN flooding on port 20003. Sending cookies. Check SNMP counters. TCP: request_sock_TCP: Possible

Re: RCU stall in 8250 serial driver Linux 4.15-rc1

Hi Greg, Sorry for that. Here is the stack trace. C Program below TCP: request_sock_TCP: Possible SYN flooding on port 20003. Sending cookies. Check SNMP counters. TCP: request_sock_TCP: Possible SYN flooding on port 20003. Sending cookies. Check SNMP counters. TCP: request_sock_TCP: Possible

Re: PROBLEM: epoll_wait does not obey edge triggering semantics for hierarchically constructed epoll sets

On 01/12/2018 07:06 PM, Nick Murphy wrote: > [1.] One line summary of the problem: > epoll_wait does not obey edge triggering semantics for file > descriptors which are themselves epoll file descriptors (i.e., epoll > fd's added to an epoll set with the EPOLLET flag) > > [2.] Full description

Re: PROBLEM: epoll_wait does not obey edge triggering semantics for hierarchically constructed epoll sets

On 01/12/2018 07:06 PM, Nick Murphy wrote: > [1.] One line summary of the problem: > epoll_wait does not obey edge triggering semantics for file > descriptors which are themselves epoll file descriptors (i.e., epoll > fd's added to an epoll set with the EPOLLET flag) > > [2.] Full description

Re: [tip:x86/pti] x86/cpu/AMD: Use LFENCE_RDTSC instead of MFENCE_RDTSC

On 1/8/2018 11:01 AM, Paolo Bonzini wrote: > On 08/01/2018 17:48, Dr. David Alan Gilbert wrote: >>> If your hypervisor is lying to you about the primary family, then all >>> bets are off.  I don't expect there will be any production systems doing >>> this. >> It's not that an unusual thing to do

Re: [tip:x86/pti] x86/cpu/AMD: Use LFENCE_RDTSC instead of MFENCE_RDTSC

On 1/8/2018 11:01 AM, Paolo Bonzini wrote: > On 08/01/2018 17:48, Dr. David Alan Gilbert wrote: >>> If your hypervisor is lying to you about the primary family, then all >>> bets are off.  I don't expect there will be any production systems doing >>> this. >> It's not that an unusual thing to do

Re: [PATCH v2 1/3] Revert "do_SAK: Don't recursively take the tasklist_lock"

Kirill Tkhai writes: > This reverts commit 20ac94378de5. > > send_sig() does not take tasklist_lock for a long time, > so this commit and the problem it solves are not relevant > anymore. > > Also, the problem of force_sig() is it clears SIGNAL_UNKILLABLE > flag, thus even

Re: [PATCH v2 1/3] Revert "do_SAK: Don't recursively take the tasklist_lock"

Kirill Tkhai writes: > This reverts commit 20ac94378de5. > > send_sig() does not take tasklist_lock for a long time, > so this commit and the problem it solves are not relevant > anymore. > > Also, the problem of force_sig() is it clears SIGNAL_UNKILLABLE > flag, thus even global init may be

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Mon, Jan 15, 2018 at 11:23:03AM -0600, Eric W. Biederman wrote: > Dave Martin writes: > > > On Thu, Jan 11, 2018 at 06:59:36PM -0600, Eric W. Biederman wrote: [...] > >> Possible ABI fixes include: > >> - Send the signal without siginfo > >> - Don't generate a signal

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Mon, Jan 15, 2018 at 11:23:03AM -0600, Eric W. Biederman wrote: > Dave Martin writes: > > > On Thu, Jan 11, 2018 at 06:59:36PM -0600, Eric W. Biederman wrote: [...] > >> Possible ABI fixes include: > >> - Send the signal without siginfo > >> - Don't generate a signal [...] > >> - Possibly

Re: LKML admins (syzbot emails are not delivered)

On Wed, Jan 17, 2018 at 5:53 PM, Theodore Ts'o wrote: > On Wed, Jan 17, 2018 at 09:06:54AM +0100, Dmitry Vyukov wrote: >> I've also mailed a change to appengine that supports *.c, *.log and >> *.patch as text/plain extensions. There does not seem to be any major >> objects to it,

Re: LKML admins (syzbot emails are not delivered)

On Wed, Jan 17, 2018 at 5:53 PM, Theodore Ts'o wrote: > On Wed, Jan 17, 2018 at 09:06:54AM +0100, Dmitry Vyukov wrote: >> I've also mailed a change to appengine that supports *.c, *.log and >> *.patch as text/plain extensions. There does not seem to be any major >> objects to it, but it will

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Wed, Jan 17, 2018 at 10:45:10AM -0600, Eric W. Biederman wrote: > Russell King - ARM Linux writes: > >From your description there still seems to be an association with an > instruction so I don't know if I would really call the signal > asynchronous. It sounds like the

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Wed, Jan 17, 2018 at 10:45:10AM -0600, Eric W. Biederman wrote: > Russell King - ARM Linux writes: > >From your description there still seems to be an association with an > instruction so I don't know if I would really call the signal > asynchronous. It sounds like the exception is delayed

Re: WARNING in can_rcv

On 01/17/2018 05:29 PM, Oliver Hartkopp wrote: >> Is this an Acked-by for both patches? >> > > Yes :-) > > Acked-by: Oliver Hartkopp Tnx > I just did not expect that you wanted to update the patches before > sending ... Why not :) Marc -- Pengutronix e.K.

Re: WARNING in can_rcv

On 01/17/2018 05:29 PM, Oliver Hartkopp wrote: >> Is this an Acked-by for both patches? >> > > Yes :-) > > Acked-by: Oliver Hartkopp Tnx > I just did not expect that you wanted to update the patches before > sending ... Why not :) Marc -- Pengutronix e.K. | Marc

Re: [PATCH RT 07/13] Revert "fs: jbd2: pull your plug when waiting for space"

On Wed, 17 Jan 2018 16:46:44 +0100 Sebastian Andrzej Siewior wrote: > On 2018-01-17 10:14:11 [-0500], Steven Rostedt wrote: > > 3.18.91-rt98-rc1 stable review patch. > > If anyone has any objections, please let me know. > > > > -- > > > > From: Sebastian

Re: [PATCH RT 07/13] Revert "fs: jbd2: pull your plug when waiting for space"

On Wed, 17 Jan 2018 16:46:44 +0100 Sebastian Andrzej Siewior wrote: > On 2018-01-17 10:14:11 [-0500], Steven Rostedt wrote: > > 3.18.91-rt98-rc1 stable review patch. > > If anyone has any objections, please let me know. > > > > -- > > > > From: Sebastian Andrzej Siewior > > >

Re: [PATCH 2/6] backlight/generic-bl: remove DRIVER1 state

On Wed, Jan 17, 2018 at 04:44:00PM +, Daniel Thompson wrote: > On 17/01/18 14:01, Daniel Vetter wrote: > > Nothing in the entire tree ever sets this, which means this is dead > > code. Remove it. > > > > Cc: Lee Jones > > Cc: Daniel Thompson

Re: [PATCH 2/6] backlight/generic-bl: remove DRIVER1 state

On Wed, Jan 17, 2018 at 04:44:00PM +, Daniel Thompson wrote: > On 17/01/18 14:01, Daniel Vetter wrote: > > Nothing in the entire tree ever sets this, which means this is dead > > code. Remove it. > > > > Cc: Lee Jones > > Cc: Daniel Thompson > > Cc: Jingoo Han > > Signed-off-by: Daniel

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On Wed, 17 Jan 2018 07:15:09 -0800 Tejun Heo wrote: > It's great that Steven's patches solve a good number of problems. It > is also true that there's a class of problems that it doesn't solve, > which other approaches do. The productive thing to do here is trying > to solve

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On Wed, 17 Jan 2018 07:15:09 -0800 Tejun Heo wrote: > It's great that Steven's patches solve a good number of problems. It > is also true that there's a class of problems that it doesn't solve, > which other approaches do. The productive thing to do here is trying > to solve the unsolved one

Re: KASAN: stack-out-of-bounds Read in __nla_put

On Thu, Jan 18, 2018 at 12:59 AM, David Ahern wrote: > On 1/17/18 2:39 AM, Xin Long wrote: >> I guess you need to move up your memset(0) a little bit: >> >> @@ -2427,6 +2443,7 @@ int netlink_rcv_skb(struct sk_buff *skb, int >> (*cb)(struct sk_buff *, >> nlh =

Re: KASAN: stack-out-of-bounds Read in __nla_put

On Thu, Jan 18, 2018 at 12:59 AM, David Ahern wrote: > On 1/17/18 2:39 AM, Xin Long wrote: >> I guess you need to move up your memset(0) a little bit: >> >> @@ -2427,6 +2443,7 @@ int netlink_rcv_skb(struct sk_buff *skb, int >> (*cb)(struct sk_buff *, >> nlh = nlmsg_hdr(skb); >>

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Wed, Jan 17, 2018 at 5:32 PM, Josh Triplett wrote: > On Wed, Jan 17, 2018 at 11:29:26AM +0100, Arnd Bergmann wrote: >> On Wed, Jan 17, 2018 at 12:57 AM, Paul E. McKenney >> wrote: >> > On Wed, Jan 17, 2018 at 12:03:18AM +0100, Arnd Bergmann

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Wed, Jan 17, 2018 at 5:32 PM, Josh Triplett wrote: > On Wed, Jan 17, 2018 at 11:29:26AM +0100, Arnd Bergmann wrote: >> On Wed, Jan 17, 2018 at 12:57 AM, Paul E. McKenney >> wrote: >> > On Wed, Jan 17, 2018 at 12:03:18AM +0100, Arnd Bergmann wrote: >> >> Evidently there is at least one driver

<    7   8   9   10   11   12   13   14   15   16   >