Re: [PATCH 3/3] xen blkback: add fault injection facility

[staskins]

On 04/20/18 13:28, Juergen Gross wrote:

On 20/04/18 12:47, Stanislav Kinsburskii wrote:

This patch adds wrapper helpers around generic Xen fault inject
facility.
The major reason is to keep all the module fault injection directories
in a dedicated subdirectory instead of Xen fault inject root.

IOW, when using these helpers, per-device and named by device name
fault injection control directories will appear under the following
directory:
- /sys/kernel/debug/xen/fault_inject/xen-blkback/
instead of:
- /sys/kernel/debug/xen/fault_inject/

Signed-off-by: Stanislav Kinsburskii 
CC: Jens Axboe 
CC: Konrad Rzeszutek Wilk 
CC: "Roger Pau Monné" 
CC: linux-kernel@vger.kernel.org
CC: linux-bl...@vger.kernel.org
CC: xen-de...@lists.xenproject.org
CC: Stanislav Kinsburskii 
CC: David Woodhouse 

This is an exact copy of the netback patch apart from the names.

I don't like adding multiple copies of the same coding to the tree.


Sure, will dedupplicate this.



Juergen



Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

[PATCH v3 2/6] drm/panel: Add support for the EDT ETM0700G0EDH6

[jan.tuerk]

From: Jan Tuerk 

The Emerging Display Technology ETM0700G0EDH6 is the
uses the same panel as the ETM0700G0BDH6. It differs
in the hardware design for the backlight and the
touchscreen i2c interface. As the new display type has
different requirements for drive-strengths on the i2c-bus,
add an additional compatible to allow the handling of it or warn
about incompatible cpu and display combinations.

Signed-off-by: Jan Tuerk 
---
 drivers/gpu/drm/panel/panel-simple.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 8b7feb2888f2..2eed60134fa3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2149,6 +2149,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "edt,etm0700g0bdh6",
.data = _etm0700g0bdh6,
}, {
+   .compatible = "edt,etm0700g0edh6",
+   .data = _etm0700g0bdh6,
+   }, {
.compatible = "foxlink,fl500wvr00-a0t",
.data = _fl500wvr00_a0t,
}, {
-- 
2.11.0

RE: [PATCH V7 6/8] perf/x86/intel/uncore: Support IIO free running counters on SKX

[Liang, Kan]

> 
> From: Kan Liang 
> 
> As of Skylake Server, there are a number of free-running counters in
> each IIO Box that collect counts for per box IO clocks and per Port
> Input/Output x BW/Utilization.
> Add a new PMU for these free-running counters. Don't let them share with
> the GP counters of IIO box. Otherwise, it will result in some (probably)
> unexpected scheduling artifacts.
> 
> The free running counter is read-only and always active. Counting will
> be suspended only when the IIO Box is powered down.
> 
> There are three types of IIO free running counters on Skylake server, IO
> CLOCKS counter, BANDWIDTH counters and UTILIZATION counters.
> IO CLOCKS counter is to count IO clocks.
> BANDWIDTH counters are to count inbound(PCIe->CPU)/outbound(CPU-
> >PCIe)
> bandwidth.
> UTILIZATION counters are to count input/output utilization.
> 
> The bit width of the free running counters is 36-bits.
> 
> Signed-off-by: Kan Liang 
> ---
> 
> Changes since V6:
>  - Add a new PMU for IIO free-running counters.
> 

Hi Peter,

Could you please review the patch?
If it's OK for you, could you please merge the patch set?

Thanks,
Kan

>  arch/x86/events/intel/uncore_snbep.c | 82
> 
>  1 file changed, 82 insertions(+)
> 
> diff --git a/arch/x86/events/intel/uncore_snbep.c
> b/arch/x86/events/intel/uncore_snbep.c
> index 22ec65b..d6b302e 100644
> --- a/arch/x86/events/intel/uncore_snbep.c
> +++ b/arch/x86/events/intel/uncore_snbep.c
> @@ -3484,6 +3484,87 @@ static struct intel_uncore_type skx_uncore_iio = {
>   .format_group   = _uncore_iio_format_group,
>  };
> 
> +enum perf_uncore_iio_freerunning_type_id {
> + SKX_IIO_MSR_IOCLK   = 0,
> + SKX_IIO_MSR_BW  = 1,
> + SKX_IIO_MSR_UTIL= 2,
> +
> + SKX_IIO_FREERUNNING_TYPE_MAX,
> +};
> +
> +
> +static struct freerunning_counters skx_iio_freerunning[] = {
> + [SKX_IIO_MSR_IOCLK] = { 0xa45, 0x1, 0x20, 1, 36 },
> + [SKX_IIO_MSR_BW]= { 0xb00, 0x1, 0x10, 8, 36 },
> + [SKX_IIO_MSR_UTIL]  = { 0xb08, 0x1, 0x10, 8, 36 },
> +};
> +
> +static struct uncore_event_desc skx_uncore_iio_freerunning_events[] = {
> + /* Free-Running IO CLOCKS Counter */
> + INTEL_UNCORE_EVENT_DESC(ioclk,
>   "event=0xff,umask=0x10"),
> + /* Free-Running IIO BANDWIDTH Counters */
> + INTEL_UNCORE_EVENT_DESC(bw_in_port0,
>   "event=0xff,umask=0x20"),
> + INTEL_UNCORE_EVENT_DESC(bw_in_port0.scale,
>   "3.814697266e-6"),
> + INTEL_UNCORE_EVENT_DESC(bw_in_port0.unit,   "MiB"),
> + INTEL_UNCORE_EVENT_DESC(bw_in_port1,
>   "event=0xff,umask=0x21"),
> + INTEL_UNCORE_EVENT_DESC(bw_in_port1.scale,
>   "3.814697266e-6"),
> + INTEL_UNCORE_EVENT_DESC(bw_in_port1.unit,   "MiB"),
> + INTEL_UNCORE_EVENT_DESC(bw_in_port2,
>   "event=0xff,umask=0x22"),
> + INTEL_UNCORE_EVENT_DESC(bw_in_port2.scale,
>   "3.814697266e-6"),
> + INTEL_UNCORE_EVENT_DESC(bw_in_port2.unit,   "MiB"),
> + INTEL_UNCORE_EVENT_DESC(bw_in_port3,
>   "event=0xff,umask=0x23"),
> + INTEL_UNCORE_EVENT_DESC(bw_in_port3.scale,
>   "3.814697266e-6"),
> + INTEL_UNCORE_EVENT_DESC(bw_in_port3.unit,   "MiB"),
> + INTEL_UNCORE_EVENT_DESC(bw_out_port0,
>   "event=0xff,umask=0x24"),
> + INTEL_UNCORE_EVENT_DESC(bw_out_port0.scale,
>   "3.814697266e-6"),
> + INTEL_UNCORE_EVENT_DESC(bw_out_port0.unit,  "MiB"),
> + INTEL_UNCORE_EVENT_DESC(bw_out_port1,
>   "event=0xff,umask=0x25"),
> + INTEL_UNCORE_EVENT_DESC(bw_out_port1.scale,
>   "3.814697266e-6"),
> + INTEL_UNCORE_EVENT_DESC(bw_out_port1.unit,  "MiB"),
> + INTEL_UNCORE_EVENT_DESC(bw_out_port2,
>   "event=0xff,umask=0x26"),
> + INTEL_UNCORE_EVENT_DESC(bw_out_port2.scale,
>   "3.814697266e-6"),
> + INTEL_UNCORE_EVENT_DESC(bw_out_port2.unit,  "MiB"),
> + INTEL_UNCORE_EVENT_DESC(bw_out_port3,
>   "event=0xff,umask=0x27"),
> + INTEL_UNCORE_EVENT_DESC(bw_out_port3.scale,
>   "3.814697266e-6"),
> + INTEL_UNCORE_EVENT_DESC(bw_out_port3.unit,  "MiB"),
> + /* Free-running IIO UTILIZATION Counters */
> + INTEL_UNCORE_EVENT_DESC(util_in_port0,
>   "event=0xff,umask=0x30"),
> + INTEL_UNCORE_EVENT_DESC(util_out_port0,
>   "event=0xff,umask=0x31"),
> + INTEL_UNCORE_EVENT_DESC(util_in_port1,
>   "event=0xff,umask=0x32"),
> + INTEL_UNCORE_EVENT_DESC(util_out_port1,
>   "event=0xff,umask=0x33"),
> + INTEL_UNCORE_EVENT_DESC(util_in_port2,
>   "event=0xff,umask=0x34"),
> + INTEL_UNCORE_EVENT_DESC(util_out_port2,
>   "event=0xff,umask=0x35"),
> + INTEL_UNCORE_EVENT_DESC(util_in_port3,
>   "event=0xff,umask=0x36"),
> + INTEL_UNCORE_EVENT_DESC(util_out_port3,
>   "event=0xff,umask=0x37"),
> + { /* end: all zeroes */ },
> +};
> +
> +static struct intel_uncore_ops 

Re: [PATCH 4/8] clk: mediatek: mt2701-mm: switch to mfd device

[Matthias Brugger]

On 04/20/2018 03:00 PM, Matthias Brugger wrote:
> Hi Stephen,
> 
> On 11/15/2017 01:17 AM, Stephen Boyd wrote:
>> On 11/14, Matthias Brugger wrote:
>>> As the new mfd device is in place, switch probing
>>> for the MMSYS to support invocation from the mfd device.
>>>
>>> Signed-off-by: Matthias Brugger 
>>> ---
>>
>> Acked-by: Stephen Boyd 
>>
> 
> I did a minor change to this patch and patch 7/8 to get rid of mmsys_private
> variable. Nevertheless I kept your Acked-by, as it only changes how we get the
> device tree node.
> 
> Hope that's OK with you.
> 

Sorry, I didn't explain me. I'm talking about v2 of the series, which I'm
working on right now.

Regards,
Matthias

Re: [RFC PATCH 2/2] HISI LPC: Add PNP device support

[Mika Westerberg]

On Fri, Apr 20, 2018 at 06:07:26PM +0800, John Garry wrote:
> Currently the driver creates an per-ACPI device mfd_cell
> for child devices. This does not suit devices which are
> PNP-compatible, as we expect PNP-compatible devices to
> derive PNP devices.
> 
> To add PNP device support, we continue to allow the PNP
> scan code to create the PNP device (which have the
> enumeration_by_parent flag set), but expect the PNP
> scan to defer adding the device to allow the host probe
> code to do this. In addition, no longer do we create an
> mfd_cell (platform_device) for PNP-compatible devices.
> 
> We take this approach so that host probe code can
> translate the IO resources of the PNP device prior
> to adding the device.
> 
> Signed-off-by: John Garry 
> ---
>  drivers/bus/hisi_lpc.c | 38 +-
>  1 file changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> index 2d4611e..d228bc5 100644
> --- a/drivers/bus/hisi_lpc.c
> +++ b/drivers/bus/hisi_lpc.c
> @@ -17,8 +17,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
> +#include "../pnp/base.h"
> +
>  #define DRV_NAME "hisi-lpc"
>  
>  /*
> @@ -469,8 +472,11 @@ static int hisi_lpc_acpi_probe(struct device *hostdev)
>   struct acpi_device *child;
>   int size, ret, count = 0, cell_num = 0;
>  
> - list_for_each_entry(child, >children, node)
> + list_for_each_entry(child, >children, node) {
> + if (acpi_is_pnp_device(child))
> + continue;
>   cell_num++;
> + }
>  
>   /* allocate the mfd cell and companion ACPI info, one per child */
>   size = sizeof(*mfd_cells) + sizeof(*hisi_lpc_mfd_cells);
> @@ -492,6 +498,9 @@ static int hisi_lpc_acpi_probe(struct device *hostdev)
>   .pnpid = pnpid,
>   };
>  
> + if (acpi_is_pnp_device(child))
> + continue;
> +
>   /*
>* For any instances of this host controller (Hip06 and Hip07
>* are the only chipsets), we would not have multiple slaves
> @@ -523,6 +532,33 @@ static int hisi_lpc_acpi_probe(struct device *hostdev)
>   return ret;
>   }
>  
> + list_for_each_entry(child, >children, node) {
> + struct pnp_resource *pnp_res;
> + struct pnp_dev *pnp_dev;
> + int rc;
> +
> + if (!acpi_is_pnp_device(child))
> + continue;
> +
> + pnp_dev = child->driver_data;

...or better yet a PNP helper function that makes this more
understandable.

> +
> + /*
> +  * Prior to adding the device, we need to translate the
> +  * resources to logical PIO addresses.
> +  */
> + list_for_each_entry(pnp_res, _dev->resources, list) {
> + struct resource *res = _res->res;
> +
> + if (res->flags | IORESOURCE_IO)

I think you should use

if (resource_type(res) == IORESOURCE_IO)

instead.

> + hisi_lpc_acpi_xlat_io_res(child, adev, res);
> + }
> + rc = pnp_add_device(pnp_dev);
> + if (rc) {
> + put_device(_dev->dev);
> + return rc;
> + }
> + }
> +
>   return 0;
>  }
>  
> -- 
> 1.9.1

Re: [PATCH bpf-next 1/5] samples/bpf: Fix typo in comment

[Daniel Thompson]

On Fri, Apr 20, 2018 at 02:10:04PM +0200, Jesper Dangaard Brouer wrote:
> 
> On Thu, 19 Apr 2018 09:34:02 +0800 Leo Yan  wrote:
> 
> > Fix typo by replacing 'iif' with 'if'.
> > 
> > Signed-off-by: Leo Yan 
> > ---
> >  samples/bpf/bpf_load.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
> > index bebe418..28e4678 100644
> > --- a/samples/bpf/bpf_load.c
> > +++ b/samples/bpf/bpf_load.c
> > @@ -393,7 +393,7 @@ static int load_elf_maps_section(struct bpf_map_data 
> > *maps, int maps_shndx,
> > continue;
> > if (sym[nr_maps].st_shndx != maps_shndx)
> > continue;
> > -   /* Only increment iif maps section */
> > +   /* Only increment if maps section */
> > nr_maps++;
> > }
> 
> This was actually not a typo from my side.
> 
> With 'iif' I mean 'if and only if' ... but it doesn't matter much.

I think 'if and only if' is more commonly abbreviated 'iff' isn't it?


Daniel.

[PATCH 4/7] perf,x86/msr: Fix possible Spectre-v1 for msr

[Peter Zijlstra]

> arch/x86/events/msr.c:178 msr_event_init() warn: potential spectre issue 
> 'msr' (local cap)

Userspace controls @attr, sanitize cfg (attr->config) before using it
to index an array.

Reported-by: Dan Carpenter 
Signed-off-by: Peter Zijlstra 
---
 arch/x86/events/msr.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/arch/x86/events/msr.c
+++ b/arch/x86/events/msr.c
@@ -158,9 +158,6 @@ static int msr_event_init(struct perf_ev
if (event->attr.type != event->pmu->type)
return -ENOENT;
 
-   if (cfg >= PERF_MSR_EVENT_MAX)
-   return -EINVAL;
-
/* unsupported modes and filters */
if (event->attr.exclude_user   ||
event->attr.exclude_kernel ||
@@ -171,6 +168,11 @@ static int msr_event_init(struct perf_ev
event->attr.sample_period) /* no sampling */
return -EINVAL;
 
+   if (cfg >= PERF_MSR_EVENT_MAX)
+   return -EINVAL;
+
+   cfg = array_index_nospec(cfg, PERF_MSR_EVENT_MAX);
+
if (!msr[cfg].attr)
return -EINVAL;
 

[PATCH 6/7] sched: Fix possible Spectre-v1 for sched_prio_to_weight[]

[Peter Zijlstra]

> kernel/sched/core.c:6921 cpu_weight_nice_write_s64() warn: potential spectre 
> issue 'sched_prio_to_weight'

Userspace controls @nice, so sanitize the value before using it to
index an array.

Reported-by: Dan Carpenter 
Signed-off-by: Peter Zijlstra 
---
 kernel/sched/core.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6928,11 +6928,14 @@ static int cpu_weight_nice_write_s64(str
 struct cftype *cft, s64 nice)
 {
unsigned long weight;
+   int idx;
 
if (nice < MIN_NICE || nice > MAX_NICE)
return -ERANGE;
 
-   weight = sched_prio_to_weight[NICE_TO_PRIO(nice) - MAX_RT_PRIO];
+   idx = array_index_nospec(NICE_TO_PRIO(nice) - MAX_RT_PRIO, 40);
+   weight = sched_prio_to_weight[idx];
+
return sched_group_set_shares(css_tg(css), scale_load(weight));
 }
 #endif

[PATCH 5/7] perf,x86/cstate: Fix possible Spectre-v1 for pkg_msr

[Peter Zijlstra]

> arch/x86/events/intel/cstate.c:307 cstate_pmu_event_init() warn: potential 
> spectre issue 'pkg_msr' (local cap)

Userspace controls @attr, sanitize cfg (attr->config) before using it
to index an array.

Reported-by: Dan Carpenter 
Signed-off-by: Peter Zijlstra 
---
 arch/x86/events/intel/cstate.c |1 +
 1 file changed, 1 insertion(+)

--- a/arch/x86/events/intel/cstate.c
+++ b/arch/x86/events/intel/cstate.c
@@ -302,6 +302,7 @@ static int cstate_pmu_event_init(struct
} else if (event->pmu == _pkg_pmu) {
if (cfg >= PERF_CSTATE_PKG_EVENT_MAX)
return -EINVAL;
+   cfg = array_index_nospec(cfg, PERF_CSTATE_PKG_EVENT_MAX);
if (!pkg_msr[cfg].attr)
return -EINVAL;
event->hw.event_base = pkg_msr[cfg].msr;

[PATCH 4/8] sh_eth: Change platform check to CONFIG_ARCH_RENESAS

[Geert Uytterhoeven]

Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
CONFIG_ARCH_SHMOBILE, hence use the former.

Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
check.

This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/net/ethernet/renesas/sh_eth.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/renesas/sh_eth.h 
b/drivers/net/ethernet/renesas/sh_eth.h
index a5b792ce2ae7d046..1bf930d4a1e52c18 100644
--- a/drivers/net/ethernet/renesas/sh_eth.h
+++ b/drivers/net/ethernet/renesas/sh_eth.h
@@ -163,7 +163,7 @@ enum {
 };
 
 /* Driver's parameters */
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
+#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_RENESAS)
 #define SH_ETH_RX_ALIGN32
 #else
 #define SH_ETH_RX_ALIGN2
-- 
2.7.4

[PATCH 2/8] dmaengine: shdmac: Change platform check to CONFIG_ARCH_RENESAS

[Geert Uytterhoeven]

Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
CONFIG_ARCH_SHMOBILE, hence use the former.

Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
check, just like before support for Renesas ARM SoCs was added.

Instead of blindly changing all the #ifdefs, switch the main code block
in sh_dmae_probe() to IS_ENABLED(), as this allows to remove all the
remaining #ifdefs.

This will allow to drop ARCH_SHMOBILE on ARM in the near future.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/dma/sh/shdmac.c | 50 +
 1 file changed, 21 insertions(+), 29 deletions(-)

diff --git a/drivers/dma/sh/shdmac.c b/drivers/dma/sh/shdmac.c
index 516f5487cc44cf96..8fcaae482ce0949a 100644
--- a/drivers/dma/sh/shdmac.c
+++ b/drivers/dma/sh/shdmac.c
@@ -440,7 +440,6 @@ static bool sh_dmae_reset(struct sh_dmae_device *shdev)
return ret;
 }
 
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
 static irqreturn_t sh_dmae_err(int irq, void *data)
 {
struct sh_dmae_device *shdev = data;
@@ -451,7 +450,6 @@ static irqreturn_t sh_dmae_err(int irq, void *data)
sh_dmae_reset(shdev);
return IRQ_HANDLED;
 }
-#endif
 
 static bool sh_dmae_desc_completed(struct shdma_chan *schan,
   struct shdma_desc *sdesc)
@@ -683,11 +681,8 @@ static int sh_dmae_probe(struct platform_device *pdev)
const struct sh_dmae_pdata *pdata;
unsigned long chan_flag[SH_DMAE_MAX_CHANNELS] = {};
int chan_irq[SH_DMAE_MAX_CHANNELS];
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
unsigned long irqflags = 0;
-   int errirq;
-#endif
-   int err, i, irq_cnt = 0, irqres = 0, irq_cap = 0;
+   int err, errirq, i, irq_cnt = 0, irqres = 0, irq_cap = 0;
struct sh_dmae_device *shdev;
struct dma_device *dma_dev;
struct resource *chan, *dmars, *errirq_res, *chanirq_res;
@@ -789,33 +784,32 @@ static int sh_dmae_probe(struct platform_device *pdev)
if (err)
goto rst_err;
 
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
-   chanirq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
+   if (IS_ENABLED(CONFIG_CPU_SH4) || IS_ENABLED(CONFIG_ARCH_RENESAS)) {
+   chanirq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
 
-   if (!chanirq_res)
-   chanirq_res = errirq_res;
-   else
-   irqres++;
+   if (!chanirq_res)
+   chanirq_res = errirq_res;
+   else
+   irqres++;
 
-   if (chanirq_res == errirq_res ||
-   (errirq_res->flags & IORESOURCE_BITS) == IORESOURCE_IRQ_SHAREABLE)
-   irqflags = IRQF_SHARED;
+   if (chanirq_res == errirq_res ||
+   (errirq_res->flags & IORESOURCE_BITS) == 
IORESOURCE_IRQ_SHAREABLE)
+   irqflags = IRQF_SHARED;
 
-   errirq = errirq_res->start;
+   errirq = errirq_res->start;
 
-   err = devm_request_irq(>dev, errirq, sh_dmae_err, irqflags,
-  "DMAC Address Error", shdev);
-   if (err) {
-   dev_err(>dev,
-   "DMA failed requesting irq #%d, error %d\n",
-   errirq, err);
-   goto eirq_err;
+   err = devm_request_irq(>dev, errirq, sh_dmae_err,
+  irqflags, "DMAC Address Error", shdev);
+   if (err) {
+   dev_err(>dev,
+   "DMA failed requesting irq #%d, error %d\n",
+   errirq, err);
+   goto eirq_err;
+   }
+   } else {
+   chanirq_res = errirq_res;
}
 
-#else
-   chanirq_res = errirq_res;
-#endif /* CONFIG_CPU_SH4 || CONFIG_ARCH_SHMOBILE */
-
if (chanirq_res->start == chanirq_res->end &&
!platform_get_resource(pdev, IORESOURCE_IRQ, 1)) {
/* Special case - all multiplexed */
@@ -881,9 +875,7 @@ static int sh_dmae_probe(struct platform_device *pdev)
 chan_probe_err:
sh_dmae_chan_remove(shdev);
 
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
 eirq_err:
-#endif
 rst_err:
spin_lock_irq(_dmae_lock);
list_del_rcu(>node);
-- 
2.7.4

[PATCH 5/8] staging: emxx_udc: Change platform dependency to ARCH_RENESAS

[Geert Uytterhoeven]

Emma Mobile is a Renesas ARM SoC.  Since commit 9b5ba0df4ea4f940 ("ARM:
shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate
platform dependency than the legacy ARCH_SHMOBILE, hence use the
former.

This will allow to drop ARCH_SHMOBILE on ARM in the near future.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/staging/emxx_udc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/emxx_udc/Kconfig b/drivers/staging/emxx_udc/Kconfig
index d7577096fb25ae7a..e50e722183648c55 100644
--- a/drivers/staging/emxx_udc/Kconfig
+++ b/drivers/staging/emxx_udc/Kconfig
@@ -1,6 +1,6 @@
 config USB_EMXX
tristate "EMXX USB Function Device Controller"
-   depends on USB_GADGET && (ARCH_SHMOBILE || (ARM && COMPILE_TEST))
+   depends on USB_GADGET && (ARCH_RENESAS || (ARM && COMPILE_TEST))
help
   The Emma Mobile series of SoCs from Renesas Electronics and
   former NEC Electronics include USB Function hardware.
-- 
2.7.4

[PATCH v2 7/9] nds32: Fix the unknown type u8 issue.

[Greentime Hu]

It broke the 'allmodconfig' build.
We need to include  to make sure the type is defined
before using it.

Signed-off-by: Greentime Hu 
Acked-by: Arnd Bergmann 
---
 arch/nds32/include/asm/io.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/nds32/include/asm/io.h b/arch/nds32/include/asm/io.h
index 966e71b3c960..71cd226d6863 100644
--- a/arch/nds32/include/asm/io.h
+++ b/arch/nds32/include/asm/io.h
@@ -4,6 +4,8 @@
 #ifndef __ASM_NDS32_IO_H
 #define __ASM_NDS32_IO_H
 
+#include 
+
 extern void iounmap(volatile void __iomem *addr);
 #define __raw_writeb __raw_writeb
 static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
-- 
1.9.5

[PATCH v2 4/9] nds32: Fix drivers/gpu/drm/udl/udl_fb.c building error by defining PAGE_SHARED

[Greentime Hu]

It broke the 'allmodconfig' build.
drivers/gpu/drm/udl/udl_fb.c: In function 'udl_fb_mmap':
drivers/gpu/drm/udl/udl_fb.c:183:52: error: 'PAGE_SHARED' undeclared (first use 
in this function)
   if (remap_pfn_range(vma, start, page, PAGE_SIZE, PAGE_SHARED))
^~~
drivers/gpu/drm/udl/udl_fb.c:183:52: note: each undeclared identifier is 
reported only once for each function it appears in
make[4]: *** [drivers/gpu/drm/udl/udl_fb.o] Error 1

Signed-off-by: Greentime Hu 
Acked-by: Arnd Bergmann 
---
 arch/nds32/include/asm/pgtable.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/nds32/include/asm/pgtable.h b/arch/nds32/include/asm/pgtable.h
index 6783937edbeb..d3e19a55cf53 100644
--- a/arch/nds32/include/asm/pgtable.h
+++ b/arch/nds32/include/asm/pgtable.h
@@ -152,6 +152,7 @@
 #define PAGE_CACHE_L1  __pgprot(_HAVE_PAGE_L | _PAGE_V | _PAGE_M_KRW | _PAGE_D 
| _PAGE_E | _PAGE_G | _PAGE_CACHE)
 #define PAGE_MEMORY__pgprot(_HAVE_PAGE_L | _PAGE_V | _PAGE_M_KRW | _PAGE_D 
| _PAGE_E | _PAGE_G | _PAGE_CACHE_SHRD)
 #define PAGE_KERNEL__pgprot(_PAGE_V | _PAGE_M_KRW | _PAGE_D | _PAGE_E | 
_PAGE_G | _PAGE_CACHE_SHRD)
+#define PAGE_SHARED__pgprot(_PAGE_V | _PAGE_M_URW_KRW | _PAGE_D | 
_PAGE_CACHE_SHRD)
 #define PAGE_DEVICE__pgprot(_PAGE_V | _PAGE_M_KRW | _PAGE_D | _PAGE_G | 
_PAGE_C_DEV)
 #endif /* __ASSEMBLY__ */
 
-- 
1.9.5

[PATCH v2 5/9] nds32: Fix xfs_buf built failed by export invalidate_kernel_vmap_range and flush_kernel_vmap_range

[Greentime Hu]

It broke the 'allmodconfig' build.
fs/xfs/xfs_buf.c: In function 'xfs_buf_bio_end_io':
fs/xfs/xfs_buf.c:1242:3: error: implicit declaration of function 
'invalidate_kernel_vmap_range' [-Werror=implicit-function-declaration]
   invalidate_kernel_vmap_range(bp->b_addr, xfs_buf_vmap_len(bp));
   ^~~~
fs/xfs/xfs_buf.c: In function 'xfs_buf_ioapply_map':
fs/xfs/xfs_buf.c:1312:4: error: implicit declaration of function 
'flush_kernel_vmap_range' [-Werror=implicit-function-declaration]
flush_kernel_vmap_range(bp->b_addr,
^~~

Signed-off-by: Greentime Hu 
Acked-by: Arnd Bergmann 
---
 arch/nds32/include/asm/cacheflush.h |  2 ++
 arch/nds32/mm/cacheflush.c  | 18 ++
 2 files changed, 20 insertions(+)

diff --git a/arch/nds32/include/asm/cacheflush.h 
b/arch/nds32/include/asm/cacheflush.h
index 1240f148ec0f..10b48f0d8e85 100644
--- a/arch/nds32/include/asm/cacheflush.h
+++ b/arch/nds32/include/asm/cacheflush.h
@@ -32,6 +32,8 @@ void flush_anon_page(struct vm_area_struct *vma,
 
 #define ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE
 void flush_kernel_dcache_page(struct page *page);
+void flush_kernel_vmap_range(void *addr, int size);
+void invalidate_kernel_vmap_range(void *addr, int size);
 void flush_icache_range(unsigned long start, unsigned long end);
 void flush_icache_page(struct vm_area_struct *vma, struct page *page);
 #define flush_dcache_mmap_lock(mapping)   xa_lock_irq(&(mapping)->i_pages)
diff --git a/arch/nds32/mm/cacheflush.c b/arch/nds32/mm/cacheflush.c
index 6eb786a399a2..bd52918d5923 100644
--- a/arch/nds32/mm/cacheflush.c
+++ b/arch/nds32/mm/cacheflush.c
@@ -273,6 +273,24 @@ void flush_kernel_dcache_page(struct page *page)
local_irq_restore(flags);
 }
 
+void flush_kernel_vmap_range(void *addr, int size)
+{
+   unsigned long flags;
+   local_irq_save(flags);
+   cpu_dcache_wb_range((unsigned long)addr, (unsigned long)addr +  size);
+   local_irq_restore(flags);
+}
+EXPORT_SYMBOL(flush_kernel_vmap_range);
+
+void invalidate_kernel_vmap_range(void *addr, int size)
+{
+   unsigned long flags;
+   local_irq_save(flags);
+   cpu_dcache_inval_range((unsigned long)addr, (unsigned long)addr + size);
+   local_irq_restore(flags);
+}
+EXPORT_SYMBOL(invalidate_kernel_vmap_range);
+
 void flush_icache_range(unsigned long start, unsigned long end)
 {
unsigned long line_size, flags;
-- 
1.9.5

Re: [PATCH 0/8] arm: renesas: Change platform dependency to ARCH_RENESAS

[Arnd Bergmann]

On Fri, Apr 20, 2018 at 3:28 PM, Geert Uytterhoeven
 wrote:
> Hi all,
>
> Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas
> ARM SoCs.  This patch series completes the conversion, by:
>   1. Updating dependencies for drivers that weren't converted yet,
>   2. Removing the ARCH_SHMOBILE Kconfig symbols on ARM and ARM64.
>
> The first 6 patches can be applied independently by subsystem
> maintainers.
> The last two patches depend on the first 6 patches, and are thus marked
> RFC.

This all looks fine to me.

Acked-by: Arnd Bergmann 

  Arnd

Re: [PATCH] lib: micro-optimization for __bitmap_complement()

[Yury Norov]

Ping?

On Wed, Apr 11, 2018 at 05:59:14PM +0300, Yury Norov wrote:
> Use BITS_TO_LONGS() macro to avoid calculation of reminder
> (bits % BITS_PER_LONG) On ARM64 it saves 5 instruction for function -
> 16 before and 11 after.
> 
> Signed-off-by: Yury Norov 
> ---
>  lib/bitmap.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/lib/bitmap.c b/lib/bitmap.c
> index c82c61b66e16..7adc10074cff 100644
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -62,12 +62,9 @@ EXPORT_SYMBOL(__bitmap_equal);
>  
>  void __bitmap_complement(unsigned long *dst, const unsigned long *src, 
> unsigned int bits)
>  {
> - unsigned int k, lim = bits/BITS_PER_LONG;
> + unsigned int k, lim = BITS_TO_LONGS(bits);
>   for (k = 0; k < lim; ++k)
>   dst[k] = ~src[k];
> -
> - if (bits % BITS_PER_LONG)
> - dst[k] = ~src[k];
>  }
>  EXPORT_SYMBOL(__bitmap_complement);
>  
> -- 
> 2.14.1

Re: [PATCH v2 03/10] videobuf2-core: Add helper to get buffer private data from media request

[Hans Verkuil]

On 04/19/18 17:41, Paul Kocialkowski wrote:
> When calling media operation driver callbacks related to media requests,
> only a pointer to the request itself is provided, which is insufficient
> to retrieve the driver's context. Since the driver context is usually
> set as vb2 queue private data and given that the core can determine
> which objects attached to the request are buffers, it is possible to
> extract the associated private data for the first buffer found.
> 
> This is required in order to access the current m2m context from m2m
> drivers' private data in the context of media request operation
> callbacks. More specifically, this allows scheduling m2m device runs
> from the newly-introduced request complete operation.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/media/common/videobuf2/videobuf2-core.c | 15 +++
>  include/media/videobuf2-core.h  |  1 +
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index 13c9d9e243dd..6fa46bfc620f 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -1351,6 +1351,21 @@ bool vb2_core_request_has_buffers(struct media_request 
> *req)
>  }
>  EXPORT_SYMBOL_GPL(vb2_core_request_has_buffers);
>  
> +void *vb2_core_request_find_buffer_priv(struct media_request *req)
> +{
> + struct media_request_object *obj;
> + struct vb2_buffer *vb;
> +
> + obj = media_request_object_find(req, _core_req_ops, NULL);

This increases the object refcount but it is never decreased here.

> + if (!obj)
> + return NULL;
> +
> + vb = container_of(obj, struct vb2_buffer, req_obj);
> +
> + return vb2_get_drv_priv(vb->vb2_queue);

You need to add a media_request_object_put(obj); before returning here.

Regards,

Hans

> +}
> +EXPORT_SYMBOL_GPL(vb2_core_request_find_buffer_priv);
> +
>  int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb,
>struct media_request *req)
>  {
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index 032bd1bec555..65c0cf6afb55 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -1153,4 +1153,5 @@ int vb2_verify_memory_type(struct vb2_queue *q,
>   enum vb2_memory memory, unsigned int type);
>  
>  bool vb2_core_request_has_buffers(struct media_request *req);
> +void *vb2_core_request_find_buffer_priv(struct media_request *req);
>  #endif /* _MEDIA_VIDEOBUF2_CORE_H */
> 

Re: [PATCH v2 02/10] media-request: Add a request complete operation to allow m2m scheduling

[Hans Verkuil]

On 04/19/18 17:41, Paul Kocialkowski wrote:
> When using the request API in the context of a m2m driver, the
> operations that come with a m2m run scheduling call in their
> (m2m-specific) ioctl handler are delayed until the request is queued
> (for instance, this includes queuing buffers and streamon).
> 
> Thus, the m2m run scheduling calls are not called in due time since the
> request AP's internal plumbing will (rightfully) use the relevant core
> functions directly instead of the ioctl handler.
> 
> This ends up in a situation where nothing happens if there is no
> run-scheduling ioctl called after queuing the request.
> 
> In order to circumvent the issue, a new media operation is introduced,
> called at the time of handling the media request queue ioctl. It gives
> m2m drivers a chance to schedule a m2m device run at that time.
> 
> The existing req_queue operation cannot be used for this purpose, since
> it is called with the request queue mutex held, that is eventually needed
> in the device_run call to apply relevant controls.

I'll need to think about this a bit more. I understand the problem so something
needs to be done. I would like to avoid adding yet another op, though.

Regards,

Hans

> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/media/media-request.c | 3 +++
>  include/media/media-device.h  | 2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
> index 415f7e31019d..28ac5ccfe6a2 100644
> --- a/drivers/media/media-request.c
> +++ b/drivers/media/media-request.c
> @@ -157,6 +157,9 @@ static long media_request_ioctl_queue(struct 
> media_request *req)
>   media_request_get(req);
>   }
>  
> + if (mdev->ops->req_complete)
> + mdev->ops->req_complete(req);
> +
>   return ret;
>  }
>  
> diff --git a/include/media/media-device.h b/include/media/media-device.h
> index 07e323c57202..c7dcf2079cc9 100644
> --- a/include/media/media-device.h
> +++ b/include/media/media-device.h
> @@ -55,6 +55,7 @@ struct media_entity_notify {
>   * @req_alloc: Allocate a request
>   * @req_free: Free a request
>   * @req_queue: Queue a request
> + * @req_complete: Complete a request
>   */
>  struct media_device_ops {
>   int (*link_notify)(struct media_link *link, u32 flags,
> @@ -62,6 +63,7 @@ struct media_device_ops {
>   struct media_request *(*req_alloc)(struct media_device *mdev);
>   void (*req_free)(struct media_request *req);
>   int (*req_queue)(struct media_request *req);
> + void (*req_complete)(struct media_request *req);
>  };
>  
>  /**
> 

[no subject]

[ronaldmugar]

Hi Linux  https://bit.ly/2K1tXfw

Re: [PATCH net-next 2/2] netns: isolate seqnums to use per-netns locks

[Christian Brauner]

On Wed, Apr 18, 2018 at 11:52:47PM +0200, Christian Brauner wrote:
> On Wed, Apr 18, 2018 at 11:55:52AM -0500, Eric W. Biederman wrote:
> > Christian Brauner  writes:
> > 
> > > Now that it's possible to have a different set of uevents in different
> > > network namespaces, per-network namespace uevent sequence numbers are
> > > introduced. This increases performance as locking is now restricted to the
> > > network namespace affected by the uevent rather than locking
> > > everything.
> > 
> > Numbers please.  I personally expect that the netlink mc_list issues
> > will swamp any benefit you get from this.
> 
> I wouldn't see how this would be the case. The gist of this is:
> Everytime you send a uevent into a network namespace *not* owned by
> init_user_ns you currently *have* to take mutex_lock(uevent_sock_list)
> effectively blocking the host from processing uevents even though
> - the uevent you're receiving might be totally different from the
>   uevent that you're sending
> - the uevent socket of the non-init_user_ns owned network namespace
>   isn't even recorded in the list.
> 
> The other argument is that we now have properly isolated network
> namespaces wrt to uevents such that each netns can have its own set of
> uevents. This can either happen by a sufficiently privileged userspace
> process sending it uevents that are only dedicated to that specific
> netns. Or - and this *has been true for a long time* - because network
> devices are *properly namespaced*. Meaning a uevent for that network
> device is *tied to a network namespace*. For both cases the uevent
> sequence numbering will be absolutely misleading. For example, whenever
> you create e.g. a new veth device in a new network namespace it
> shouldn't be accounted against the initial network namespace but *only*
> against the network namespace that has that device added to it.

Eric, I did the testing. Here's what I did:

I compiled two 4.17-rc1 Kernels:
- one with per netns uevent seqnums with decoupled locking
- one without per netns uevent seqnums with decoupled locking

# Testcase 1:
Only Injecting Uevents into network namespaces not owned by the initial user
namespace.
- created 1000 new user namespace + network namespace pairs
- opened a uevent listener in each of those namespace pairs
- injected uevents into each of those network namespaces 10,000 times meaning
  10,000,000 (10 million) uevents were injected. (The high number of
  uevent injections should get rid of a lot of jitter.)
- Calculated the mean transaction time.
- *without* uevent sequence number namespacing:
  67 μs
- *with* uevent sequence number namespacing:
  55 μs
- makes a difference of 12 μs

# Testcase 2:
Injecting Uevents into network namespaces not owned by the initial user
namespace and network namespaces owned by the initial user namespace.
- created 500 new user namespace + network namespace pairs
- created 500 new network namespace pairs
- opened a uevent listener in each of those namespace pairs
- injected uevents into each of those network namespaces 10,000 times meaning
  10,000,000 (10 million) uevents were injected. (The high number of
  uevent injections should get rid of a lot of jitter.)
- Calculated the mean transaction time.
- *without* uevent sequence number namespacing:
  572 μs
- *with* uevent sequence number namespacing:
  514 μs
- makes a difference of 58 μs

So there's performance gain. The third case would be to create a bunch
of hanging processes that send SIGSTOP to themselves but do not actually
open a uevent socket in their respective namespaces and then inject
uevents into them. I expect there to be an even more performance
benefits since the rtnl_table_lock() isn't hit in this case because
there are no listeners.

Christian

Re: [PATCH] drm: udl: Destroy framebuffer only if it was initialized

[Sean Paul]

On Fri, Apr 20, 2018 at 01:50:01PM +0200, Emil Lundmark wrote:
> This fixes a NULL pointer dereference that can happen if the UDL
> driver is unloaded before the framebuffer is initialized. This can
> happen e.g. if the USB device is unplugged right after it was plugged
> in.
> 

JFYI, in future, if someone makes a suggestion on how to fix a bug, it's good
practice to add a Suggested-by tag to give credit.

Reviewed-by: Sean Paul 

> Signed-off-by: Emil Lundmark 
> ---
>  drivers/gpu/drm/udl/udl_fb.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index 2ebdc6d5a76e..5754e37f741b 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -426,9 +426,11 @@ static void udl_fbdev_destroy(struct drm_device *dev,
>  {
>   drm_fb_helper_unregister_fbi(>helper);
>   drm_fb_helper_fini(>helper);
> - drm_framebuffer_unregister_private(>ufb.base);
> - drm_framebuffer_cleanup(>ufb.base);
> - drm_gem_object_put_unlocked(>ufb.obj->base);
> + if (ufbdev->ufb.obj) {
> + drm_framebuffer_unregister_private(>ufb.base);
> + drm_framebuffer_cleanup(>ufb.base);
> + drm_gem_object_put_unlocked(>ufb.obj->base);
> + }
>  }
>  
>  int udl_fbdev_init(struct drm_device *dev)
> -- 
> 2.17.0.484.g0c8726318c-goog
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS

Re: [PATCH v2 05/10] media: v4l: Add definitions for MPEG2 frame format and header metadata

[Hans Verkuil]

On 04/19/18 17:45, Paul Kocialkowski wrote:
> Stateless video decoding engines require both the MPEG slices and
> associated metadata from the video stream in order to decode frames.
> 
> This introduces definitions for a new pixel format, describing buffers
> with MPEG2 slice data, as well as a control structure for passing the
> frame header (metadata) to drivers.
> 
> Signed-off-by: Paul Kocialkowski 
> Signed-off-by: Florent Revest 
> ---
>  drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++
>  drivers/media/v4l2-core/v4l2-ioctl.c |  1 +
>  include/uapi/linux/v4l2-controls.h   | 26 ++
>  include/uapi/linux/videodev2.h   |  3 +++
>  4 files changed, 40 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index ba05a8b9a095..fcdc12b9a9e0 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -761,6 +761,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>   case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: return 
> "Vertical MV Search Range";
>   case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: return "Repeat 
> Sequence Header";
>   case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME:   return "Force 
> Key Frame";
> + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:   return "MPEG2 
> Frame Header";
>  
>   /* VPX controls */
>   case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS:return "VPX 
> Number of Partitions";
> @@ -1152,6 +1153,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
> v4l2_ctrl_type *type,
>   case V4L2_CID_RDS_TX_ALT_FREQS:
>   *type = V4L2_CTRL_TYPE_U32;
>   break;
> + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
> + *type = V4L2_CTRL_TYPE_MPEG2_FRAME_HDR;
> + break;
>   default:
>   *type = V4L2_CTRL_TYPE_INTEGER;
>   break;
> @@ -1472,6 +1476,9 @@ static int std_validate(const struct v4l2_ctrl *ctrl, 
> u32 idx,
>   return -ERANGE;
>   return 0;
>  
> + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> + return 0;
> +
>   default:
>   return -EINVAL;
>   }
> @@ -2046,6 +2053,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct 
> v4l2_ctrl_handler *hdl,
>   case V4L2_CTRL_TYPE_U32:
>   elem_size = sizeof(u32);
>   break;
> + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> + elem_size = sizeof(struct v4l2_ctrl_mpeg2_frame_hdr);
> + break;
>   default:
>   if (type < V4L2_CTRL_COMPOUND_TYPES)
>   elem_size = sizeof(s32);
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 468c3c65362d..8070203da5d2 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1273,6 +1273,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>   case V4L2_PIX_FMT_VC1_ANNEX_L:  descr = "VC-1 (SMPTE 412M Annex 
> L)"; break;
>   case V4L2_PIX_FMT_VP8:  descr = "VP8"; break;
>   case V4L2_PIX_FMT_VP9:  descr = "VP9"; break;
> + case V4L2_PIX_FMT_MPEG2_FRAME:  descr = "MPEG2 Frame"; break;
>   case V4L2_PIX_FMT_CPIA1:descr = "GSPCA CPiA YUV"; break;
>   case V4L2_PIX_FMT_WNVA: descr = "WNVA"; break;
>   case V4L2_PIX_FMT_SN9C10X:  descr = "GSPCA SN9C10X"; break;
> diff --git a/include/uapi/linux/v4l2-controls.h 
> b/include/uapi/linux/v4l2-controls.h
> index cbbb750d87d1..8431b2a540c7 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -557,6 +557,8 @@ enum v4l2_mpeg_video_mpeg4_profile {
>  };
>  #define V4L2_CID_MPEG_VIDEO_MPEG4_QPEL   (V4L2_CID_MPEG_BASE+407)
>  
> +#define V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR (V4L2_CID_MPEG_BASE+450)
> +
>  /*  Control IDs for VP8 streams
>   *  Although VP8 is not part of MPEG we add these controls to the MPEG class
>   *  as that class is already handling other video compression standards
> @@ -985,4 +987,28 @@ enum v4l2_detect_md_mode {
>  #define V4L2_CID_DETECT_MD_THRESHOLD_GRID(V4L2_CID_DETECT_CLASS_BASE + 3)
>  #define V4L2_CID_DETECT_MD_REGION_GRID   
> (V4L2_CID_DETECT_CLASS_BASE + 4)
>  
> +struct v4l2_ctrl_mpeg2_frame_hdr {
> + __u32 slice_len;
> + __u32 slice_pos;
> + enum { MPEG1, MPEG2 } type;
> +
> + __u16 width;
> + __u16 height;
> +
> + enum { PCT_I = 1, PCT_P, PCT_B, PCT_D } picture_coding_type;
> + __u8 f_code[2][2];
> +
> + __u8 intra_dc_precision;
> + __u8 picture_structure;
> + __u8 top_field_first;
> + __u8 frame_pred_frame_dct;
> + __u8 concealment_motion_vectors;
> + __u8 q_scale_type;
> + __u8 intra_vlc_format;
> + __u8 

Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent" devices

[John Garry]

On 20/04/2018 14:52, Mika Westerberg wrote:

On Fri, Apr 20, 2018 at 02:24:18PM +0100, John Garry wrote:

Hi Mika,

On 20/04/2018 14:07, Mika Westerberg wrote:

On Fri, Apr 20, 2018 at 06:07:25PM +0800, John Garry wrote:

+   } else {
+   device->driver_data = dev;


I think this deserves a comment explaining why we (ab)use driver_data
like this.


Sure, could add. I didn't see any other way for the acpi_device structure to
reference the derived PNP device.

TBH, This overall approach is not good since we are creating the PNP device
in the scan, and then leaving the device in limbo, waiting for the parent to
add it, if at all. There's no rule for this.

So I'm looking for ideas on how to improve this.




Hi Mika,


One idea is to make pnpacpi_add_device() available outside of PNP and
call it directly (or some variation) in hisi_lpc.c when it walks over
its children.



I did consider this initially and it seems quite straightforward.

However I think the problem is that we would need to modify the 
acpi_device child resources from FW with kernel-specific resources, 
which does not seem right (I think that is what you meant). As I see, 
this is one reason that we went in the direction of modelling the host 
as an MFD, as we could set the resources of the mfd_cells.


So adding a variant of pnpacpi_add_device() could work, or modifying 
pnpacpi_add_device() to accept a callback to translate the resources. 
But this feature is specific to our very special requirement...


Thanks,
John


.

Re: s390 perf events JSONs query

[Hendrik Brueckner]

Hi John,

On Fri, Apr 20, 2018 at 02:53:27PM +0100, John Garry wrote:
> On 20/04/2018 14:25, Thomas-Mich Richter wrote:
> >On 04/20/2018 12:51 PM, John Garry wrote:
> >>I noticed that in 4.17-rc1 support was included for s390 perf pmu-events. I 
> >>also notice that the JSONs contain many common (identical actually) events 
> >>between different chips for this arch.
> >>
> >>Support was added for factoring out common arch events in 
> >>https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/tools/perf/pmu-events?h=next-20180420=e9d32c1bf0cd7a98358ec4aa1625bf2b3459b9ac
> >>
> >>ARM64 chips use this feature. I am not familiar with the s390 arch, but do 
> >>you think you could also use this feature?
> >>
> >>Thanks,
> >>John
> >>
> >
> >I have just played with this feature. I was caught off by this error message:
> >
> >[root@s35lp76 pmu-events]# ./jevents s390 arch /tmp/xxx 10
> >d 04096 s390 arch/s390
> >d 14096 cf_z14   arch/s390/cf_z14
> >f 21338 basic.json   arch/s390/cf_z14/basic.json
> >
> >jevents: Ignoring file arch/s390/archevent.json  < confusing error 
> >message
> 
> Let me check if this can be silenced.
> 
> >
> >jevents: Processing mapfile arch/s390/mapfile.csv
> >[root@s35lp76 pmu-events]#
> >
> >I started debugging, until I realized this file is still processed.
> >(Just a side remark).
> >
> >Anyway the features is nice, but it does not save anything in the resulting
> >pmu-events.c file, correct? The events defined in the common archevent.json
> >files are just copied into the structures of a specific machine.
> >
> 
> Yes, the resulting derived pmu-events.c should be the same. In fact,
> if there was naming inconsistencies in JSONs previously, they should
> now be gone.
> 
> >The feature saves time and space when you create the machine specific json
> >files because it allows you to refer to a common event by name. Cool!
> >
> >On s390 we do not create the json files manually, but have some scripts to
> >create them based on s390 type/model hardware specific input files.
> 
> Right, I would say that this is mostly useful when the JSONs are
> created manually, which was the case in the ARM world, but not x86.

It is really the right way and the coolest feature to go when the JSONs need
to be created manually.

For s390, I started manually with adding descriptions for the libpfm4 library.
Then, the events sysfs came up and that was the point in time when I created
a common database for the counters in the s390-tools package.  Meanwhile,
s390-tools, libpfm4, kernel, and Thomas recently added perf JSONs as possible
outputs formats.

> >@Hendrik,
> >we could rework our internal tool chain to emit the new "ArchStdEvent"
> >keyword for common events, but in the end we do not save anything in the
> >resulting pmu-events.c file. And it requires considerable rework to
> >support it.
> >Given that, I would put it very low priority on your todo list, comments?

I would consider this a low-priority given the fact that have to overwrite
to the counter number (for the model-dependent counters) as well.

Many thanks!
 
Kind regards,
  Hendrik

Re: [PATCH V2] USB: Increment wakeup count on remote wakeup.

[Alan Stern]

On Thu, 19 Apr 2018, Ravi Chandra Sadineni wrote:

> On chromebooks we depend on wakeup count to identify the wakeup source.
> But currently USB devices do not increment the wakeup count when they
> trigger the remote wake. This patch addresses the same.
> 
> Resume condition is reported differently on USB 2.0 and USB 3.0 devices.
> 
> On USB 2.0 devices, a wake capable device, if wake enabled, drives
> resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7).
> The upstream facing port then sets C_PORT_SUSPEND bit and reports a
> port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port
> has resumed before driving the resume signal from the host and
> C_PORT_SUSPEND is set, then the device attached to the given port might
> be the reason for the last system wakeup. Increment the wakeup count for
> the same.
> 
> On USB 3.0 devices, a function may signal that it wants to exit from device
> suspend by sending a Function Wake Device Notification to the host (USB3.0
> spec section 8.5.6.4) Thus on receiving the Function Wake, increment the
> wakeup count.
> 
> Signed-off-by: Ravi Chandra Sadineni 
> ---
>  drivers/usb/core/hcd.c |  2 ++
>  drivers/usb/core/hub.c | 10 +-
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index 777036ae63674..ee0f3ec57ce49 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -2374,7 +2374,9 @@ static void hcd_resume_work(struct work_struct *work)
>  void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
>  {
>   unsigned long flags;
> + struct device *dev = >self.root_hub->dev;
>  
> + pm_wakeup_event(dev, 0);
>   spin_lock_irqsave (_root_hub_lock, flags);
>   if (hcd->rh_registered) {
>   set_bit(HCD_FLAG_WAKEUP_PENDING, >flags);

In general, hcd->self.root_hub is guaranteed to be non-NULL only when 
hcd->rh_registered is set.  Therefore the assignment to dev and the 
call to pm_wakeup_event() should be moved within this "if" statement.

The rest of the patch looks okay.

Alan Stern

> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index f6ea16e9f6bb9..aa9968d90a48c 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -653,12 +653,17 @@ void usb_wakeup_notification(struct usb_device *hdev,
>   unsigned int portnum)
>  {
>   struct usb_hub *hub;
> + struct usb_port *port_dev;
>  
>   if (!hdev)
>   return;
>  
>   hub = usb_hub_to_struct_hub(hdev);
>   if (hub) {
> + port_dev = hub->ports[portnum - 1];
> + if (port_dev && port_dev->child)
> + pm_wakeup_event(_dev->child->dev, 0);
> +
>   set_bit(portnum, hub->wakeup_bits);
>   kick_hub_wq(hub);
>   }
> @@ -3434,8 +3439,11 @@ int usb_port_resume(struct usb_device *udev, 
> pm_message_t msg)
>  
>   /* Skip the initial Clear-Suspend step for a remote wakeup */
>   status = hub_port_status(hub, port1, , );
> - if (status == 0 && !port_is_suspended(hub, portstatus))
> + if (status == 0 && !port_is_suspended(hub, portstatus)) {
> + if (portchange & USB_PORT_STAT_C_SUSPEND)
> + pm_wakeup_event(>dev, 0);
>   goto SuspendCleared;
> + }
>  
>   /* see 7.1.7.7; affects power usage, but not budgeting */
>   if (hub_is_superspeed(hub->hdev))
> 

Re: [PATCH] printk: Ratelimit messages printed by console drivers

[Steven Rostedt]

On Fri, 20 Apr 2018 16:01:57 +0200
Petr Mladek  wrote:

> On Fri 2018-04-20 08:04:28, Steven Rostedt wrote:
> > On Fri, 20 Apr 2018 11:12:24 +0200
> > Petr Mladek  wrote:
> >   
> > > Yes, my number was arbitrary. The important thing is that it was long
> > > enough. Or do you know about an console that will not be able to write
> > > 100 lines within one hour?  
> > 
> > The problem is the way rate limit works. If you print 100 lines (or
> > 1000) in 5 seconds, then you just stopped printing from that context
> > for 59 minutes and 55 seconds. That's a long time to block printing.  
> 
> Are we talking about the same context?
> 
> I am talking about console drivers called from console_unlock(). It is
> very special context because it is more or less recursive:
> 
>  + could cause infinite loop
>  + the errors are usually the same again and again

The check is only when console_owner == current, which can easily
happen with an interrupt let alone an NMI.

The common case is not recursive.

> 
> As a result, if you get too many messages from this context:
> 
>  + you are lost (recursion)
>  + more messages != new information
> 
> And you need to fix the problem anyway. Otherwise, the system
> logging is a mess.
> 
> 
> > What happens if you had a couple of NMIs go off that takes up that
> > time, and then you hit a bug 10 minutes later from that context. You
> > just lost it.  
> 
> I do not understand how this is related to the NMI context.
> The messages in NMI context are not throttled!
> 
> OK, the original patch throttled also NMI messages when NMI
> interrupted console drivers. But it is easy to fix.

My mistake in just mentioning NMIs, because the check is on
console_owner which can be set with interrupts enabled. That means an
interrupt that does a print could hide printks from other interrupts or
NMIs when console_owner is set.

> 
> 
> > This is a magnitude larger than any other user of rate limit in the
> > kernel. The most common time is 5 seconds. The longest I can find is 1
> > minute. You are saying you want to block printing from this context for
> > 60 minutes!  
> 
> I see 1 day long limits in dio_warn_stale_pagecache() and
> xfs_scrub_experimental_warning().
> 
> Note that most ratelimiting is related to a single message. Also it
> is in situation where the system should recover within seconds.
> 
> 
> > That is HUGE! I don't understand your rational for such a huge number.
> > What data do you have to back that up with?  
> 
> We want to allow seeing the entire lockdep splat (Sergey wants more
> than 100 lines). Also it is not that unusual that slow console is busy
> several minutes when too many things are happening.
> 
> I proposed that long delay because I want to be on the safe side.
> Also I do not see a huge benefit in repeating the same messages
> too often.
> 
> Alternative solution would be to allow first, lets say 250, lines
> and then nothing. I mean to change the approach from rate-limiting
> to print-once.


Actually, I think we are fine with the one hour and 1000 prints if we
add to the condition. It can't just check console_owner. We need a way
to know that this is indeed a recursion. Perhaps we should set the
context we are in when setting console owner. Something like I have in
the ring buffer code.

enum {
CONTEXT_NONE,
CONTEXT_NMI,
CONTEXT_IRQ,
CONTEXT_SOFTIRQ,
CONTEXT_NORMAL
};

int git_context(void)
{
unsigned long pc = preempt_count();

if (!(pc & (NMI_MASK | HARDIRQ_MASK | SOFTIRQ_OFFSET)))
return CONTEXT_NORMAL;
else
return pc & NMI_MASK ? CONTEXT_NMI :
pc & HARDIRQ_MASK ? CONTEXT_IRQ : CONTEXT_SOFTIRQ;
}

static void console_lock_spinning_enable(void)
{
raw_spin_lock(_owner_lock);
console_owner = current;
console_context = get_context();
raw_spin_unlock(_owner_lock);
[..]


static int console_lock_spinning_disable_and_check(void)
{
raw_spin_lock(_owner_lock);
waiter = READ_ONCE(console_waiter);
console_owner = NULL;
console_context = CONTEXT_NONE;
raw_spin_unlock(_owner_lock);
[..]


Then have your check be:

+   /* Prevent infinite loop caused by messages from console drivers. */
+   if (console_owner == current && console_context == get_context() &&
+   !__ratelimit(_console))
+   return 0;

Then you know that this is definitely due to recursion.

-- Steve

Re: [RFC] perf/core: what is exclude_idle supposed to do

[Vince Weaver]

On Fri, 20 Apr 2018, Peter Zijlstra wrote:

> On Wed, Apr 18, 2018 at 11:10:20AM -0400, Vince Weaver wrote:
> > On Tue, 17 Apr 2018, Jiri Olsa wrote:
> > 
> > > On Mon, Apr 16, 2018 at 10:04:53PM +, Stephane Eranian wrote:
> > > > Hi,
> > > > 
> > > > I am trying to understand what the exclude_idle event attribute is 
> > > > supposed
> > > > to accomplish.
> > > > As per the definition in the header file:
> > > > 
> > > > exclude_idle   :  1, /* don't count when idle */
> > > 
> > > AFAICS it's not implemented
> > 
> > so just to be completely clear hear, we're saying that the "exclude_idle" 
> > modifier has never done anything useful and still doesn't?
> 
> AFAICT it works on Power and possibly ARM.

at least some ARMs are a bit more honest about it than x86

ivybridge:
Performance counter stats for '/bin/ls':
1,368,162  instructions
1,368,162  instructions:I

pi2/ARM cortex-A7
Performance counter stats for '/bin/ls':
1,910,083  instructions
  instructions:I

I'd fire up my Power8 machine to see but not sure it's worth the hassle 
and/or having to get out the ear protection.

Vince

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[Michal Hocko]

On Fri 20-04-18 10:23:49, Michal Hocko wrote:
> On Thu 19-04-18 12:34:53, David Rientjes wrote:
[...]
> > I understand the concern, but it's the difference between the victim 
> > getting stuck in exit_mmap() and actually taking a long time to free its 
> > memory in exit_mmap().  I don't have evidence of the former.
> 
> I do not really want to repeat myself. The primary purpose of the oom
> reaper is to provide a _guarantee_ of the forward progress. I do not
> care whether there is any evidences. All I know that lock_page has
> plethora of different dependencies and we cannot clearly state this is
> safe so we _must not_ depend on it when setting MMF_OOM_SKIP.
> 
> The way how the oom path was fragile and lockup prone based on
> optimistic assumptions shouldn't be repeated.
> 
> That being said, I haven't heard any actual technical argument about why
> locking the munmap path is a wrong thing to do while the MMF_OOM_SKIP
> dependency on the page_lock really concerns me so
> 
> Nacked-by: Michal Hocko 
> 
> If you want to keep the current locking protocol then you really have to
> make sure that the oom reaper will set MMF_OOM_SKIP when racing with
> exit_mmap.

So here is my suggestion for the fix.

>From 37ab85d619f508ceaf829e57648a3d986c6d8bfc Mon Sep 17 00:00:00 2001
From: Michal Hocko 
Date: Fri, 20 Apr 2018 13:53:08 +0200
Subject: [PATCH] oom: mm, oom: fix concurrent munlock and oom reaper unmap

David has noticed that our current assumption that the oom reaper can
race with exit_mmap is not correct. munlock_vma_pages_all() depends on
clearing VM_LOCKED from vm_flags before actually doing the munlock to
determine if any other vmas are locking the same memory, the check for
VM_LOCKED in the oom reaper is racy.

This is especially noticeable on architectures such as powerpc where
clearing a huge pmd requires serialize_against_pte_lookup().  If the pmd
is zapped by the oom reaper during follow_page_mask() after the check for
pmd_none() is bypassed, this ends up deferencing a NULL ptl.

Fix this by taking the exclusive mmap_sem in exit_mmap while tearing
down the address space. Once that is done MMF_OOM_SKIP is set so that
__oom_reap_task_mm can back off if it manages to take the read lock
finally.

Fixes: 212925802454 ("mm: oom: let oom_reap_task and exit_mmap run 
concurrently")
Cc: stable
Signed-off-by: Michal Hocko 
---
 mm/mmap.c | 36 ++--
 mm/oom_kill.c |  2 +-
 2 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index faf85699f1a1..216efa6d9f61 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3004,10 +3004,21 @@ void exit_mmap(struct mm_struct *mm)
struct mmu_gather tlb;
struct vm_area_struct *vma;
unsigned long nr_accounted = 0;
+   bool locked = false;
 
/* mm's last user has gone, and its about to be pulled down */
mmu_notifier_release(mm);
 
+   /*
+* The mm is not accessible for anybody except for the oom reaper
+* which cannot race with munlocking so make sure we exclude the
+* two.
+*/
+   if (unlikely(mm_is_oom_victim(mm))) {
+   down_write(>mmap_sem);
+   locked = true;
+   }
+
if (mm->locked_vm) {
vma = mm->mmap;
while (vma) {
@@ -3021,7 +3032,7 @@ void exit_mmap(struct mm_struct *mm)
 
vma = mm->mmap;
if (!vma)   /* Can happen if dup_mmap() received an OOM */
-   return;
+   goto out_unlock;
 
lru_add_drain();
flush_cache_mm(mm);
@@ -3030,23 +3041,6 @@ void exit_mmap(struct mm_struct *mm)
/* Use -1 here to ensure all VMAs in the mm are unmapped */
unmap_vmas(, vma, 0, -1);
 
-   if (unlikely(mm_is_oom_victim(mm))) {
-   /*
-* Wait for oom_reap_task() to stop working on this
-* mm. Because MMF_OOM_SKIP is already set before
-* calling down_read(), oom_reap_task() will not run
-* on this "mm" post up_write().
-*
-* mm_is_oom_victim() cannot be set from under us
-* either because victim->mm is already set to NULL
-* under task_lock before calling mmput and oom_mm is
-* set not NULL by the OOM killer only if victim->mm
-* is found not NULL while holding the task_lock.
-*/
-   set_bit(MMF_OOM_SKIP, >flags);
-   down_write(>mmap_sem);
-   up_write(>mmap_sem);
-   }
free_pgtables(, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
tlb_finish_mmu(, 0, -1);
 
@@ -3060,6 +3054,12 @@ void exit_mmap(struct mm_struct *mm)
vma = remove_vma(vma);
}
vm_unacct_memory(nr_accounted);
+
+out_unlock:
+   if (unlikely(locked)) {
+   set_bit(MMF_OOM_SKIP, >flags);
+   

Re: [RESEND][PATCH 2/4] NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler

[Andy Shevchenko]

On Wed, 2018-04-18 at 15:35 +0530, Amit Pundir wrote:

>   if (skb->data[transaction->aid_len + 2] !=
> - NFC_EVT_TRANSACTION_PARAMS_TAG)
> + NFC_EVT_TRANSACTION_PARAMS_TAG ||
> + skb->len < transaction->aid_len + transaction-
> >params_len + 4) {

> + devm_kfree(dev, transaction);

Oh, no.

This is not memory leak per se, this is bad choice of devm_ API where it
should use plain kmalloc() / kfree().

>   return -EPROTO;
> + }

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [RESEND][PATCH 4/4] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver

[Andy Shevchenko]

On Wed, 2018-04-18 at 15:35 +0530, Amit Pundir wrote:

> + if (phy->next_read_size >
> FDP_NCI_I2C_MAX_PAYLOAD) {

> + dev_dbg(>dev, "%s: corrupted
> packet\n",
> + __func__);

If Android people would follow the kernel in reasonable time they may
have noticed Dynamic Debug functionality and how it works.

In this case the __func__ is superfluous.

> + phy->next_read_size = 5;
> + goto flush;
> + }
>   } else {
>   phy->next_read_size =
> FDP_NCI_I2C_MIN_PAYLOAD;
>  

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [Xen-devel] [PATCH] xen-netfront: Fix hang on device removal

[Jason Andryuk]

On Thu, Apr 19, 2018 at 4:09 PM, Simon Gaiser
 wrote:
> Jason Andryuk:
>> On Thu, Apr 19, 2018 at 2:10 PM, Simon Gaiser
>>  wrote:
>>> Jason Andryuk:
 A toolstack may delete the vif frontend and backend xenstore entries
 while xen-netfront is in the removal code path.  In that case, the
 checks for xenbus_read_driver_state would return XenbusStateUnknown, and
 xennet_remove would hang indefinitely.  This hang prevents system
 shutdown.

 xennet_remove must be able to handle XenbusStateUnknown, and
 netback_changed must also wake up the wake_queue for that state as well.

 Fixes: 5b5971df3bc2 ("xen-netfront: remove warning when unloading module")
>>>
>>> I think this should go into stable since AFAIK the hanging network
>>> device can only be fixed by rebooting the guest. AFAICS this affects all
>>> 4.* branches since 5b5971df3bc2 got backported to them.
>>>
>>> Upstream commit c2d2e6738a209f0f9dffa2dc8e7292fc45360d61.
>>
>> Simon,
>>
>> Yes, I agree.  I actually submitted the request to stable earlier
>> today, so hopefully it gets added soon.
>
> Ok, great. (I checked the stable patch queue, but didn't check the
> mailing list archive).
>
>> Have you experienced this hang?
>
> Yes, it's affecting the kernel shipped by Qubes OS (see [1]).

Ok, interesting.  I tracked down this bug with older xenvm tools, and
I didn't know if libxl tools were also affected.

Greg KH added the patch to the stable queue, so it's in the process.

Regards,
Jason

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote:
> > > What we need is an sg_alloc_table_from_resources(dev, resources,
> > > num_resources) which does the handling common to all drivers.
> > A structure that contains
> > 
> > {page,offset,len} + {dma_addr+dma_len}
> > 
> > is not a good container for storing
> > 
> > {virt addr, dma_addr, len}
> > 
> > no matter what interface you build arond it.
> 
> Why not? I mean at least for my use case we actually don't need the virtual
> address.

If you don't need the virtual address you need scatterlist even list.

> What we need is {dma_addr+dma_len} in a consistent interface which can come
> from both {page,offset,len} as well as {resource, len}.

Ok.

> What I actually don't need is separate handling for system memory and
> resources, but that would we get exactly when we don't use sg_table.

At the very lowest level they will need to be handled differently for
many architectures, the questions is at what point we'll do the
branching out.

Re: [RFC PATCH 2/2] HISI LPC: Add PNP device support

[Andy Shevchenko]

On Fri, 2018-04-20 at 18:07 +0800, John Garry wrote:
> Currently the driver creates an per-ACPI device mfd_cell
> for child devices. This does not suit devices which are
> PNP-compatible, as we expect PNP-compatible devices to
> derive PNP devices.
> 
> To add PNP device support, we continue to allow the PNP
> scan code to create the PNP device (which have the
> enumeration_by_parent flag set), but expect the PNP
> scan to defer adding the device to allow the host probe
> code to do this. In addition, no longer do we create an
> mfd_cell (platform_device) for PNP-compatible devices.
> 
> We take this approach so that host probe code can
> translate the IO resources of the PNP device prior
> to adding the device.

> + list_for_each_entry(child, >children, node) {
> + if (acpi_is_pnp_device(child))
> + continue;

This is good candidate for a separate helper macro

#define for_each_acpi_non_pnp_device(child, adev) \
...

(see, for example, for_each_pci_bridge() implementation as an example)

 
> + list_for_each_entry(child, >children, node) {

> + if (!acpi_is_pnp_device(child))
> + continue;

Ditto.

> + /*
> +  * Prior to adding the device, we need to translate
> the
> +  * resources to logical PIO addresses.
> +  */
> + list_for_each_entry(pnp_res, _dev->resources,
> list) {
> + struct resource *res = _res->res;
> +

> + if (res->flags | IORESOURCE_IO)

What does this mean?

> + hisi_lpc_acpi_xlat_io_res(child,
> adev, res);
> + }

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH v3] selftests/livepatch: introduce tests

[Libor Pechacek]

Hi Joe,

I know I am late to the party, yet have some questions about the code.

On Thu 12-04-18 10:54:31, Joe Lawrence wrote:
> Add a few livepatch modules and simple target modules that the included
> regression suite can run tests against.
> 
> Signed-off-by: Joe Lawrence 
> ---
[...]
> diff --git a/tools/testing/selftests/livepatch/functions.sh 
> b/tools/testing/selftests/livepatch/functions.sh
> new file mode 100644
> index ..7aaef80e9edb
> --- /dev/null
> +++ b/tools/testing/selftests/livepatch/functions.sh
> @@ -0,0 +1,196 @@
> +#!/bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (C) 2018 Joe Lawrence 
> +
> +# Shell functions for the rest of the scripts.
> +
> +MAX_RETRIES=600
> +RETRY_INTERVAL=".1"  # seconds
> +
> +# die(msg) - game over, man
> +#msg - dying words
> +function die() {
> + echo "ERROR: $1" >&2
> + exit 1
> +}
> +
> +# set_dynamic_debug() - setup kernel dynamic debug
> +#TODO - push and pop this config?
> +function set_dynamic_debug() {
> + cat << EOF > /sys/kernel/debug/dynamic_debug/control
> +file kernel/livepatch/* +p
> +func klp_try_switch_task -p
> +EOF
> +}
> +
> +# wait_for_transition(modname)
> +#modname - livepatch module name
> +wait_for_transition() {
> + local mod="$1"; shift

Why is the function waiting for a concrete module to finish the transition?
Wouldn't checking all modules, and therefore watching the global transition
state, be equally efficient without the need to provide module name?

> +
> + # Wait for livepatch transition  ...
> + local i=0
> + while [[ $(cat /sys/kernel/livepatch/"$mod"/transition) != "0" ]]; do
> + i=$((i+1))
> + if [[ $i -eq $MAX_RETRIES ]]; then
> + die "failed to complete transition for module $mod"

FWIW, qa_test_klp tests dump blocking processes' stacks at this place for more
efficient information exchange between tester and developer.
(klp_dump_blocking_processes() in https://github.com/lpechacek/qa_test_klp,
file klp_tc_functions.sh)

> + fi
> + sleep $RETRY_INTERVAL
> + done
> +}
> +
> +# load_mod(modname, params) - load a kernel module
> +#modname - module name to load
> +#   params  - module parameters to pass to modprobe
> +function load_mod() {
> + local mod="$1"; shift
> + local args="$*"
> +
> + local msg="% modprobe $mod $args"
> + echo "${msg%% }" > /dev/kmsg
> + ret=$(modprobe "$mod" "$args" 2>&1)
> + if [[ "$ret" != "" ]]; then
> + echo "$ret" > /dev/kmsg
> + die "$ret"
> + fi
> +
> + # Wait for module in sysfs ...
> + local i=0
> + while [ ! -e /sys/module/"$mod" ]; do
> + i=$((i+1))
> + if [[ $i -eq $MAX_RETRIES ]]; then
> + die "failed to load module $mod"
> + fi
> + sleep $RETRY_INTERVAL
> + done
> +
> + # Wait for livepatch ...
> + if [[ $(modinfo "$mod" | awk '/^livepatch:/{print $NF}') == "Y" ]]; then
> +
> + # Wait for livepatch in sysfs ...
> + local i=0
> + while [ ! -e /sys/kernel/livepatch/"$mod" ]; do

Hmmm! Good test! Never came to my mind...

> + i=$((i+1))
> + if [[ $i -eq $MAX_RETRIES ]]; then
> + die "failed to load module $mod (sysfs)"
> + fi
> + sleep $RETRY_INTERVAL
> + done
> + fi
> +}
> +
> +# load_failing_mod(modname, params) - load a kernel module, expect to fail
> +#modname - module name to load
> +#   params  - module parameters to pass to modprobe
> +function load_failing_mod() {
> + local mod="$1"; shift
> + local args="$*"
> +
> + local msg="% modprobe $mod $args"
> + echo "${msg%% }" > /dev/kmsg
> + ret=$(modprobe "$mod" "$args" 2>&1)
> + if [[ "$ret" == "" ]]; then
> + echo "$mod unexpectedly loaded" > /dev/kmsg
> + die "$mod unexpectedly loaded"

I'm wondering why is the same message being logged to kernel buffer and console
when in other cases it's written to console only.

> + fi
> + echo "$ret" > /dev/kmsg
> +}
> +
> +# unload_mod(modname) - unload a kernel module
> +#modname - module name to unload
> +function unload_mod() {
> + local mod="$1"
> +
> + # Wait for module reference count to clear ...
> + local i=0
> + while [[ $(cat /sys/module/"$mod"/refcnt) != "0" ]]; do
> + i=$((i+1))
> + if [[ $i -eq $MAX_RETRIES ]]; then
> + die "failed to unload module $mod (refcnt)"
> + fi
> + sleep $RETRY_INTERVAL
> + done

The repeating pattern of "while ; do ; if ; then ..." seems to ask for encapsulation.

> +
> + echo "% rmmod $mod" > /dev/kmsg
> + ret=$(rmmod "$mod" 2>&1)
> + if [[ "$ret" != "" ]]; then
> + echo "$ret" > 

Re: [PATCH 1/1] arm: dts: rockchip: default serial for Tinker Board

[Heiko Stuebner]

Am Dienstag, 17. April 2018, 22:56:23 CEST schrieb Heinrich Schuchardt:
> The Asus Tinker Board uses serial 2 with 115,200 baud by default for
> communication in U-Boot. The same value is also chosen for other RK3288
> boards.
> 
> So let us set the same value in the Tinker Board device tree.
> 
> Signed-off-by: Heinrich Schuchardt 

applied for 4.18

Thanks
Heiko

[PATCH v3 4/6] ARM: dts: imx: Add an cpu0 label for imx6dl devices.

[jan.tuerk]

From: Jan Tuerk 

Adding the label cpu0 allows the adjustment of cpu-parameters
by reference in overlaying dtsi files in the same way as it
is possible for imx6q devices.

Signed-off-by: Jan Tuerk 
---
 arch/arm/boot/dts/imx6dl.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 558bce81209d..fc658bf3a693 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -21,7 +21,7 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   cpu@0 {
+   cpu0: cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
-- 
2.11.0

[PATCH v3 3/6] dt-bindings: display: Document the EDT et* displays in one file.

[jan.tuerk]

From: Jan Tuerk 

Document the Emerging Display Technology Corp. (EDT) using the
simple-panel binding in one single file.

Signed-off-by: Jan Tuerk 
---
 .../bindings/display/panel/edt,et-series.txt   | 39 ++
 .../bindings/display/panel/edt,et057090dhu.txt |  7 
 .../bindings/display/panel/edt,et070080dh6.txt | 10 --
 .../bindings/display/panel/edt,etm0700g0dh6.txt| 10 --
 4 files changed, 39 insertions(+), 27 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/edt,et-series.txt
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt

diff --git a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt 
b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt
new file mode 100644
index ..f56b99ebd9be
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt
@@ -0,0 +1,39 @@
+Emerging Display Technology Corp. Displays
+==
+
+
+Display bindings for EDT Display Technology Corp. Displays which are
+compatible with the simple-panel binding, which is specified in
+simple-panel.txt
+
+
+5,7" WVGA TFT Panels
+
+
++-+-+-+
+| Identifier  | compatbile  | description |
++=+=+=+
+| ET057090DHU | edt,et057090dhu | 5.7" VGA TFT LCD panel  |
++-+-+-+
+
+
+7,0" WVGA TFT Panels
+
+
++-+-+-+
+| Identifier  | compatbile  | description |
++=+=+=+
+| ETM0700G0DH6| edt,etm070080dh6| WVGA TFT Display with capacitive|
+| | | Touchscreen |
++-+-+-+
+| ETM0700G0BDH6   | edt,etm070080bdh6   | Same as ETM0700G0DH6 but with   |
+| | | inverted pixel clock.   |
++-+-+-+
+| ETM0700G0EDH6   | edt,etm070080edh6   | Same display as the ETM0700G0BDH6,  |
+| | | but with changed Hardware for the   |
+| | | backlight and the touch interface   |
++-+-+-+
+| ET070080DH6 | edt,etm070080dh6| Same timings as the ETM0700G0DH6,   |
+| | | but with resistive touch.   |
++-+-+-+
+
diff --git 
a/Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt 
b/Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt
deleted file mode 100644
index 4903d7b1d947..
--- a/Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt
+++ /dev/null
@@ -1,7 +0,0 @@
-Emerging Display Technology Corp. 5.7" VGA TFT LCD panel
-
-Required properties:
-- compatible: should be "edt,et057090dhu"
-
-This binding is compatible with the simple-panel binding, which is specified
-in simple-panel.txt in this directory.
diff --git 
a/Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt 
b/Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt
deleted file mode 100644
index 20cb38e836e4..
--- a/Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-Emerging Display Technology Corp. ET070080DH6 7.0" WVGA TFT LCD panel
-
-Required properties:
-- compatible: should be "edt,et070080dh6"
-
-This panel is the same as ETM0700G0DH6 except for the touchscreen.
-ET070080DH6 is the model with resistive touch.
-
-This binding is compatible with the simple-panel binding, which is specified
-in simple-panel.txt in this directory.
diff --git 
a/Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt 
b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt
deleted file mode 100644
index ee4b18053e40..
--- a/Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-Emerging Display Technology Corp. ETM0700G0DH6 7.0" WVGA TFT LCD panel
-
-Required properties:
-- compatible: should be "edt,etm0700g0dh6"
-
-This panel is the same as ET070080DH6 except for the 

[PATCH v3 6/6] ARM: imx_v6_v7_defconfig: Enable DA0963 PMIC support.

[jan.tuerk]

From: Jan Tuerk 

All recent emtrion modules based on i.mx6 make use of the DA0963.
Therefore enable it with the following defaults:
- CONFIG_MFD_DA9063=y
- CONFIG_REGULATOR_DA9063=y
- CONFIG_DA9063_WATCHDOG=m
MFD and REGULATOR are built-in to have it at Kernel boot-time.
The WATCHDOG is optional and could be loaded from userspace.

Signed-off-by: Jan Tuerk 
---
 arch/arm/configs/imx_v6_v7_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig 
b/arch/arm/configs/imx_v6_v7_defconfig
index 3a308437b088..691d431250d4 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -214,9 +214,11 @@ CONFIG_CPU_THERMAL=y
 CONFIG_IMX_THERMAL=y
 CONFIG_WATCHDOG=y
 CONFIG_DA9062_WATCHDOG=y
+CONFIG_DA9063_WATCHDOG=m
 CONFIG_IMX2_WDT=y
 CONFIG_MFD_DA9052_I2C=y
 CONFIG_MFD_DA9062=y
+CONFIG_MFD_DA9063=y
 CONFIG_MFD_MC13XXX_SPI=y
 CONFIG_MFD_MC13XXX_I2C=y
 CONFIG_MFD_STMPE=y
@@ -225,6 +227,7 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_ANATOP=y
 CONFIG_REGULATOR_DA9052=y
 CONFIG_REGULATOR_DA9062=y
+CONFIG_REGULATOR_DA9063=y
 CONFIG_REGULATOR_GPIO=y
 CONFIG_REGULATOR_MC13783=y
 CONFIG_REGULATOR_MC13892=y
-- 
2.11.0

[PATCH v3 5/6] ARM: dts: Add support for emtrion emCON-MX6 series

[jan.tuerk]

From: Jan Tuerk 

This patch adds support for the emtrion GmbH emCON-MX6 modules.
They are available with imx.6 Solo, Dual-Lite, Dual and Quad
equipped with Memory from 512MB to 2GB (configured by U-Boot).

Our default developer-Kit ships with the Avari baseboard and the
EDT ETM0700G0BDH6 Display (imx6[q|dl]-emcon-avari).

The devicetree is split into the common part providing all module
components and the basic support for all SoC versions
(imx6qdl-emcon.dtsi) and parts which are i.mx6 S|DL and D|Q relevant.
Finally the support for the avari baseboard in the developer-kit
configuration is provided by the emcon-avari dts files.

Signed-off-by: Jan Tuerk 
---
 Documentation/devicetree/bindings/arm/emtrion.txt |  13 +
 arch/arm/boot/dts/Makefile|   2 +
 arch/arm/boot/dts/imx6dl-emcon-avari.dts  | 224 ++
 arch/arm/boot/dts/imx6dl-emcon.dtsi   |  27 +
 arch/arm/boot/dts/imx6q-emcon-avari.dts   | 224 ++
 arch/arm/boot/dts/imx6q-emcon.dtsi|  27 +
 arch/arm/boot/dts/imx6qdl-emcon.dtsi  | 838 ++
 7 files changed, 1355 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/emtrion.txt
 create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi
 create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts
 create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi
 create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi

diff --git a/Documentation/devicetree/bindings/arm/emtrion.txt 
b/Documentation/devicetree/bindings/arm/emtrion.txt
new file mode 100644
index ..3ff6c6c2034d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/emtrion.txt
@@ -0,0 +1,13 @@
+Emtrion Devicetree Bindings
+===
+
+emCON Series:
+-
+
+Required root node properties
+   - compatible:
+   - "emtrion,emcon-mx6", "fsl,imx6q", "fsl,imx6dl"; : emCON-MX6 Generic 
SoM
+   - "emtrion,emcon-mx6", "fsl,imx6q"; : emCON-MX6D or 
emCON-MX6Q SoM
+   - "emtrion,emcon-mx6-avari", "fsl,imx6q";   : emCON-MX6D or 
emCON-MX6Q SoM on Avari Base
+   - "emtrion,emcon-mx6", "fsl,imx6dl";: emCON-MX6S or 
emCON-MX6DL SoM
+   - "emtrion,emcon-mx6-avari", "fsl,imx6dl";  : emCON-MX6S or 
emCON-MX6DL SoM on Avari Base
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..05b930da3fda 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -381,6 +381,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-cubox-i-emmc-som-v15.dtb \
imx6dl-cubox-i-som-v15.dtb \
imx6dl-dfi-fs700-m60.dtb \
+   imx6dl-emcon-avari.dtb \
imx6dl-gw51xx.dtb \
imx6dl-gw52xx.dtb \
imx6dl-gw53xx.dtb \
@@ -442,6 +443,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-display5-tianma-tm070-1280x768.dtb \
imx6q-dmo-edmqmx6.dtb \
imx6q-dms-ba16.dtb \
+   imx6q-emcon-avari.dtb \
imx6q-evi.dtb \
imx6q-gk802.dtb \
imx6q-gw51xx.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-emcon-avari.dts 
b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
new file mode 100644
index ..2344fb9498e3
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: (GPL-2.0 or MIT)
+/* Copyright (C) 2018 emtrion GmbH
+ * Author: Jan Tuerk  
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-emcon.dtsi"
+#include "imx6dl-emcon.dtsi" /*Include camera2 pinmux*/
+
+/ {
+   model = "emtrion SoM emCON-MX6 Solo/Dual-Lite Avari";
+   compatible = "emtrion,emcon-mx6-avari", "fsl,imx6dl";
+
+   aliases {
+   mmc0 = 
+   mmc2 = 
+   mmc1 = 
+   mmc3 = 
+   };
+
+   chosen {
+   stdout-path = <>;
+   };
+
+   memory {
+   reg = <0x1000 0x4000>;
+   };
+
+   supplies {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   wallplug5p0: supply@0 {
+   compatible = "regulator-fixed";
+   reg = <0>;
+   regulator-name = "WALL-PLUG";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   base3p3: supply@1 {
+   compatible = "regulator-fixed";
+   reg = <1>;
+   vin-supply = <>;
+   regulator-name = "3V3-avari";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   

[PATCH v3 0/6] Add basic support for emtrion emCON-MX6 modules

[jan.tuerk]

From: Jan Tuerk 

Changes for v3:
  [PATCH v3 1/6] drm/panel: Add support for the EDT ETM0700G0BDH6
- moved Documentation into seperate commit ([PATCH v3/6])

  [PATCH v3 2/6] drm/panel: Add support for the EDT ETM0700G0EDH6
- new Patch, adding additionally compatible for the new hardware type

  [PATCH v3 3/6] dt-bindings: display: Document the EDT et* displays in one 
file.
- new Patch, as requested by Rob Herring document the EDT Displays in a 
single file

  [PATCH v3 4/6] ARM: dts: imx: Add an cpu0 label for imx6dl devices.
- Unchanged
  [PATCH v3 5/6] ARM: dts: Add support for emtrion emCON-MX6 series
- change License Header to SPDX + dual-license without licence text.
- coding-style fixes
  [PATCH v3 6/6] ARM: imx_v6_v7_defconfig: Enable DA0963 PMIC support.
- Rebased and merged

 Documentation/devicetree/bindings/arm/emtrion.txt  |  13 +
 .../bindings/display/panel/edt,et-series.txt   |  39 +
 .../bindings/display/panel/edt,et057090dhu.txt |   7 -
 .../bindings/display/panel/edt,et070080dh6.txt |  10 -
 .../bindings/display/panel/edt,etm0700g0dh6.txt|  10 -
 arch/arm/boot/dts/Makefile |   2 +
 arch/arm/boot/dts/imx6dl-emcon-avari.dts   | 224 ++
 arch/arm/boot/dts/imx6dl-emcon.dtsi|  27 +
 arch/arm/boot/dts/imx6dl.dtsi  |   2 +-
 arch/arm/boot/dts/imx6q-emcon-avari.dts| 224 ++
 arch/arm/boot/dts/imx6q-emcon.dtsi |  27 +
 arch/arm/boot/dts/imx6qdl-emcon.dtsi   | 838 +
 arch/arm/configs/imx_v6_v7_defconfig   |   3 +
 drivers/gpu/drm/panel/panel-simple.c   |  18 +
 14 files changed, 1416 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/emtrion.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/edt,et-series.txt
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt
 create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi
 create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts
 create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi
 create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi

-- 
2.11.0

Re: [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc

[Peter Rosin]

On 2018-04-20 13:38, jacopo mondi wrote:
> Hi Peter,
> 
> On Fri, Apr 20, 2018 at 01:05:21PM +0200, Peter Rosin wrote:
>> On 2018-04-20 12:18, Laurent Pinchart wrote:
>>> Hello,
>>>
>>> On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
 Hi Peter,
 I've been a bit a pain in the arse for you recently, but please
 bear with me a bit more, and sorry for jumping late on the band wagon.

 On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote:
> Hi!
>
> I naively thought that since there was support for both nxp,tda19988 (in
> the tda998x driver) and the atmel-hlcdc, things would be a smooth ride.
> But it wasn't, so I started looking around and realized I had to fix
> things.
>
> In v1 and v2 I fixed things by making the atmel-hlcdc driver a master
> component, but now in v3 I fix things by making the tda998x driver
> a bridge instead. This was after a suggestion from Boris Brezillion
>>
>> That should be Brezillon, sorry for being sloppy with the spelling.
>>
> (the atmel-hlcdc maintainer), so there was some risk of bias ... but
> after comparing what was needed, I too find the bridge approach better.
>
> In addition to the above, our PCB interface between the SAMA5D3 and the
> HDMI encoder is only using 16 bits, and this has to be described
> somewhere, or the atmel-hlcdc driver have no chance of selecting the
> correct output mode. Since I have similar problems with a ds90c185 lvds
> encoder I added patches to override the atmel-hlcdc output format via
> DT properties compatible with the media video-interface binding and
> things start to play together.
>
> Since this series superseeds the bridge series [1], I have included the
> leftover bindings patch for the ti,ds90c185 here.

 I feel like this series would look better if it would make use of the
 proposed bridge media bus format support I have recently sent out [1]
 (and which was not there when you first sent v1).

 I understand your fundamental problem here is that the bus format
 that should be reported by your bridge is different from the ones
 actually supported by the TDA19988 chip, as the wirings ground some
 of the input pins.

 Although this is defintely something that could be described in the
 bridge's own OF node with the 'bus_width' property, and what I would do,
 now that you have made a bridge out from the tda19988 driver, is:

 1) Set the bridge accepted input bus_format parsing its pin
 configuration, or default it if that's not implemented yet.
 This will likely be rgb888. You can do that using the trivial
 support for bridge input image formats implemented by my series.
 2) Specify in the bridge endpoint a 'bus_width' of <16>
 3) In your atmel-hlcd get both the image format of the bridge (rgb888)
 and parse the remote endpoint property 'bus_width' and get the <16>
 value back.
>>>
>>> Parsing properties of remote nodes should be avoided as much as possible, as
>>> they need to be interpreted in the context of the DT bindings related to the
>>> compatible string applicable to that node. I'd rather have the bus_width
>>> property in the local endpoint node.
>>
>> In addition to that, my view of this binding
>>
>>  endpoint {
>>  bus-type = <0>;
> 
> bus-type is used by v4l2_fwnode helpers to decide which type of bus
> they're dealing with iirc. Here it seems to me it has no added
> value, also because in your bindings description "it shall be 0" and
> it is not parsed anywhere in you code, but no big deal

bus-type is indeed parsed and verified to be zero which means auto-detect
according to the video-interfaces binding. An auto-detect bus-type with
a given bus-width means a parallel interface IIUC.

>From patch 3/7:

if (of_property_read_u32(node, "bus-type", _type))
return 0;
if (bus_type != 0)
return -EINVAL;


>>  bus-widht = <16>;
>>  };
>>
>> is that it always means rgb565. See further below.
>>
 4) Set the correct format in the atmel hlcd driver to accommodate a
 bridge that wants rgb888 on a 16 bit wide bus (that would be rgb565,
 or are there other possible combinations I am missing?)

 I would consider this better mostly because in this series you are
 creating a semantic for the whole DRM subsystem on the 'bus_width'
 property, where numerical values as '12', '16' etc are arbitrary tied
 to the selection of a media bus format. At least you should use a
 common set of defines [1] between the device tree and the driver,
 but this looks anyway fragile imho.
>>>
>>> This I agree with though. Combining the remote bus format with the local bus
>>> width should fix the problem without having to parse remote properties.
>>
>> My thinking was that the binding with bus-type = <0> and bus-width = 
>> 

[PATCH v3 1/6] drm/panel: Add support for the EDT ETM0700G0BDH6

[jan.tuerk]

From: Jan Tuerk 

The Emerging Display Technology ETM0700G0BDH6 is exactly
the same display as the ETM0700G0DH6, exept the pixelclock
polarity. Therefore re-use the ETM0700G0DH6 modes. It is
used by default on emtrion Avari based development kits.

Signed-off-by: Jan Tuerk 
---
 drivers/gpu/drm/panel/panel-simple.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..8b7feb2888f2 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -909,6 +909,18 @@ static const struct panel_desc edt_etm0700g0dh6 = {
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
 };
 
+static const struct panel_desc edt_etm0700g0bdh6 = {
+   .modes = _etm0700g0dh6_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
+};
+
 static const struct drm_display_mode foxlink_fl500wvr00_a0t_mode = {
.clock = 32260,
.hdisplay = 800,
@@ -2134,6 +2146,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "edt,etm0700g0dh6",
.data = _etm0700g0dh6,
}, {
+   .compatible = "edt,etm0700g0bdh6",
+   .data = _etm0700g0bdh6,
+   }, {
.compatible = "foxlink,fl500wvr00-a0t",
.data = _fl500wvr00_a0t,
}, {
-- 
2.11.0

Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent" devices

[Mika Westerberg]

On Fri, Apr 20, 2018 at 06:07:25PM +0800, John Garry wrote:
> + } else {
> + device->driver_data = dev;

I think this deserves a comment explaining why we (ab)use driver_data
like this.

Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

[Rahul Lakkireddy]

On Thursday, April 04/19/18, 2018 at 20:23:37 +0530, Eric W. Biederman wrote:
> Rahul Lakkireddy  writes:
> 
> > On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave Young wrote:
> >> On 04/18/18 at 06:01pm, Rahul Lakkireddy wrote:
> >> > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
> >> > > Hi Rahul,
> >> > > On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
> >> > > > On production servers running variety of workloads over time, kernel
> >> > > > panic can happen sporadically after days or even months. It is
> >> > > > important to collect as much debug logs as possible to root cause
> >> > > > and fix the problem, that may not be easy to reproduce. Snapshot of
> >> > > > underlying hardware/firmware state (like register dump, firmware
> >> > > > logs, adapter memory, etc.), at the time of kernel panic will be very
> >> > > > helpful while debugging the culprit device driver.
> >> > > > 
> >> > > > This series of patches add new generic framework that enable device
> >> > > > drivers to collect device specific snapshot of the hardware/firmware
> >> > > > state of the underlying device in the crash recovery kernel. In crash
> >> > > > recovery kernel, the collected logs are added as elf notes to
> >> > > > /proc/vmcore, which is copied by user space scripts for 
> >> > > > post-analysis.
> >> > > > 
> >> > > > The sequence of actions done by device drivers to append their device
> >> > > > specific hardware/firmware logs to /proc/vmcore are as follows:
> >> > > > 
> >> > > > 1. During probe (before hardware is initialized), device drivers
> >> > > > register to the vmcore module (via vmcore_add_device_dump()), with
> >> > > > callback function, along with buffer size and log name needed for
> >> > > > firmware/hardware log collection.
> >> > > 
> >> > > I assumed the elf notes info should be prepared while kexec_[file_]load
> >> > > phase. But I did not read the old comment, not sure if it has been 
> >> > > discussed
> >> > > or not.
> >> > > 
> >> > 
> >> > We must not collect dumps in crashing kernel. Adding more things in
> >> > crash dump path risks not collecting vmcore at all. Eric had
> >> > discussed this in more detail at:
> >> > 
> >> > https://lkml.org/lkml/2018/3/24/319
> >> > 
> >> > We are safe to collect dumps in the second kernel. Each device dump
> >> > will be exported as an elf note in /proc/vmcore.
> >> 
> >> I understand that we should avoid adding anything in crash path.  And I 
> >> also
> >> agree to collect device dump in second kernel.  I just assumed device
> >> dump use some memory area to store the debug info and the memory
> >> is persistent so that this can be done in 2 steps, first register the
> >> address in elf header in kexec_load, then collect the dump in 2nd
> >> kernel.  But it seems the driver is doing some other logic to collect
> >> the info instead of just that simple like I thought. 
> >> 
> >
> > It seems simpler, but I'm concerned with waste of memory area, if
> > there are no device dumps being collected in second kernel. In
> > approach proposed in these series, we dynamically allocate memory
> > for the device dumps from second kernel's available memory.
> 
> Don't count that kernel having more than about 128MiB.
> 

If large dump is expected, Administrator can increase the memory
allocated to the second kernel (using crashkernel boot param), to
ensure device dumps get collected.

> For that reason if for no other it would be nice if it was possible to
> have the driver to not initialize the device and just stand there
> handing out the data a piece at a time as it is read from /proc/vmcore.
> 

Since cxgb4 is a network driver, it can be used to transfer the dumps
over the network. So we must ensure the dumps get collected and
stored, before device gets initialized to transfer dumps over
the network.

> The 2GiB number I read earlier concerns me for working in a limited
> environment.
> 

All dumps, including the 2GB on-chip memory dump, is compressed by
the cxgb4 driver as they are collected. The overall compressed dump
comes out at max 32 MB.

> It might even make sense to separate this into a completely separate
> module (depended upon the main driver if it makes sense to share
> the functionality) so that people performing crash dumps would not
> hesitate to include the code in their initramfs images.
> 
> I can see splitting a device up into a portion only to be used in case
> of a crash dump and a normal portion like we do for main memory but I
> doubt that makes sense in practice.
> 

This is not required, especially in case of network drivers, which
must collect underlying device dump and initialize the device to
transfer dumps over the network.

> >> > > If do this in 2nd kernel a question is driver can be loaded later than 
> >> > > vmcore init.
> >> > 
> >> > Yes, drivers will add their device dumps after vmcore init.
> >> > 
> >> > > How to guarantee the function works if vmcore 

[PATCH][next] cifs: ensure full_path is free'd on error exit path

[Colin King]

From: Colin Ian King 

Currently the check on the mode flags that returns -EPERM is leaking
full_path on the error exit return. Fix this by kfree'ing it before
the return.

Detected by CoverityScan, CID#1468029 ("Resource Leak")

Fixes: 49162bfde140 ("cifs: do not allow creating sockets except with SMB1 
posix exensions")
Signed-off-by: Colin Ian King 
---
 fs/cifs/dir.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
index f0a759dd6817..207883b39362 100644
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -684,8 +684,10 @@ int cifs_mknod(struct inode *inode, struct dentry 
*direntry, umode_t mode,
goto mknod_out;
}
 
-   if (!S_ISCHR(mode) && !S_ISBLK(mode))
+   if (!S_ISCHR(mode) && !S_ISBLK(mode)) {
+   kfree(full_path);
return -EPERM;
+   }
 
if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_UNX_EMUL))
goto mknod_out;
-- 
2.17.0

[PATCH 1/7] perf: Fix possible Spectre-v1 for aux_pages

[Peter Zijlstra]

> kernel/events/ring_buffer.c:871 perf_mmap_to_page() warn: potential spectre 
> issue 'rb->aux_pages'

Userspace controls @pgoff through the fault address. Sanitize the
array index before doing the array dereference.

Reported-by: Dan Carpenter 
Signed-off-by: Peter Zijlstra 
---
 kernel/events/ring_buffer.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -867,8 +867,10 @@ perf_mmap_to_page(struct ring_buffer *rb
return NULL;
 
/* AUX space */
-   if (pgoff >= rb->aux_pgoff)
-   return virt_to_page(rb->aux_pages[pgoff - 
rb->aux_pgoff]);
+   if (pgoff >= rb->aux_pgoff) {
+   int aux_pgoff = array_index_nospec(pgoff - 
rb->aux_pgoff, rb->aux_nr_pages);
+   return virt_to_page(rb->aux_pages[aux_pgoff]);
+   }
}
 
return __perf_mmap_to_page(rb, pgoff);

[PATCH 7/7] sched,autogroup: Fix possible Spectre-v1 for sched_prio_to_weight

[Peter Zijlstra]

> kernel/sched/autogroup.c:230 proc_sched_autogroup_set_nice() warn: potential 
> spectre issue 'sched_prio_to_weight'

Userspace controls @nice, sanitize the array index.

Reported-by: Dan Carpenter 
Signed-off-by: Peter Zijlstra 
---
 kernel/sched/autogroup.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/kernel/sched/autogroup.c
+++ b/kernel/sched/autogroup.c
@@ -209,7 +209,7 @@ int proc_sched_autogroup_set_nice(struct
static unsigned long next = INITIAL_JIFFIES;
struct autogroup *ag;
unsigned long shares;
-   int err;
+   int err, idx;
 
if (nice < MIN_NICE || nice > MAX_NICE)
return -EINVAL;
@@ -227,7 +227,9 @@ int proc_sched_autogroup_set_nice(struct
 
next = HZ / 10 + jiffies;
ag = autogroup_task_get(p);
-   shares = scale_load(sched_prio_to_weight[nice + 20]);
+
+   idx = array_index_nospec(nice + 20, 40);
+   shares = scale_load(sched_prio_to_weight[idx]);
 
down_write(>lock);
err = sched_group_set_shares(ag->tg, shares);

[PATCH] cifs: dir: fix memory leak in cifs_mknod

[Gustavo A. R. Silva]

Free allocated memory for full_path and xid before return.

Addresses-Coverity-ID: 1468029 ("Resource leak")
Fixes: 49162bfde140 ("cifs: do not allow creating sockets except with
SMB1 posix exensions")
Signed-off-by: Gustavo A. R. Silva 
---
 fs/cifs/dir.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
index f0a759d..71e32d9 100644
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -684,8 +684,11 @@ int cifs_mknod(struct inode *inode, struct dentry 
*direntry, umode_t mode,
goto mknod_out;
}
 
-   if (!S_ISCHR(mode) && !S_ISBLK(mode))
+   if (!S_ISCHR(mode) && !S_ISBLK(mode)) {
+   kfree(full_path);
+   free_xid(xid);
return -EPERM;
+   }
 
if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_UNX_EMUL))
goto mknod_out;
-- 
2.7.4

[PATCH 2/7] perf,x86: Fix possible Spectre-v1 for hw_perf_event

[Peter Zijlstra]

> arch/x86/events/core.c:319 set_ext_hw_attr() warn: potential spectre issue 
> 'hw_cache_event_ids[cache_type]' (local cap)
> arch/x86/events/core.c:319 set_ext_hw_attr() warn: potential spectre issue 
> 'hw_cache_event_ids' (local cap)
> arch/x86/events/core.c:328 set_ext_hw_attr() warn: potential spectre issue 
> 'hw_cache_extra_regs[cache_type]' (local cap)
> arch/x86/events/core.c:328 set_ext_hw_attr() warn: potential spectre issue 
> 'hw_cache_extra_regs' (local cap)

Userspace controls @config which contains 3 (byte) fields used for a 3
dimensional array deref.

Reported-by: Dan Carpenter 
Signed-off-by: Peter Zijlstra 
---
 arch/x86/events/core.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -304,17 +304,20 @@ set_ext_hw_attr(struct hw_perf_event *hw
 
config = attr->config;
 
-   cache_type = (config >>  0) & 0xff;
+   cache_type = (config >> 0) & 0xff;
if (cache_type >= PERF_COUNT_HW_CACHE_MAX)
return -EINVAL;
+   cache_type = array_index_nospec(cache_type, PERF_COUNT_HW_CACHE_MAX);
 
cache_op = (config >>  8) & 0xff;
if (cache_op >= PERF_COUNT_HW_CACHE_OP_MAX)
return -EINVAL;
+   cache_op = array_index_nospec(cache_op, PERF_COUNT_HW_CACHE_OP_MAX);
 
cache_result = (config >> 16) & 0xff;
if (cache_result >= PERF_COUNT_HW_CACHE_RESULT_MAX)
return -EINVAL;
+   cache_result = array_index_nospec(cache_result, 
PERF_COUNT_HW_CACHE_RESULT_MAX);
 
val = hw_cache_event_ids[cache_type][cache_op][cache_result];
 

Re: s390 perf events JSONs query

[Thomas-Mich Richter]

On 04/20/2018 12:51 PM, John Garry wrote:
> Hi Hendrik, Thomas,
> 
> I noticed that in 4.17-rc1 support was included for s390 perf pmu-events. I 
> also notice that the JSONs contain many common (identical actually) events 
> between different chips for this arch.
> 
> Support was added for factoring out common arch events in 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/tools/perf/pmu-events?h=next-20180420=e9d32c1bf0cd7a98358ec4aa1625bf2b3459b9ac
> 
> ARM64 chips use this feature. I am not familiar with the s390 arch, but do 
> you think you could also use this feature?
> 
> Thanks,
> John
> 

I have just played with this feature. I was caught off by this error message:

[root@s35lp76 pmu-events]# ./jevents s390 arch /tmp/xxx 10
d 04096 s390 arch/s390
d 14096 cf_z14   arch/s390/cf_z14
f 21338 basic.json   arch/s390/cf_z14/basic.json

jevents: Ignoring file arch/s390/archevent.json  < confusing error message

jevents: Processing mapfile arch/s390/mapfile.csv
[root@s35lp76 pmu-events]# 

I started debugging, until I realized this file is still processed.
(Just a side remark).

Anyway the features is nice, but it does not save anything in the resulting
pmu-events.c file, correct? The events defined in the common archevent.json
files are just copied into the structures of a specific machine.

The feature saves time and space when you create the machine specific json
files because it allows you to refer to a common event by name. Cool!

On s390 we do not create the json files manually, but have some scripts to
create them based on s390 type/model hardware specific input files.

@Hendirk,
we could rework our internal tool chain to emit the new "ArchStdEvent"
keyword for common events, but in the end we do not save anything in the
resulting pmu-events.c file. And it requires considerable rework to 
support it.
Given that, I would put it very low priority on your todo list, comments?

-- 
Thomas Richter, Dept 3303, IBM LTC Boeblingen Germany
--
Vorsitzende des Aufsichtsrats: Martina Koederitz 
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 
243294

Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent" devices

[John Garry]

Hi Mika,

On 20/04/2018 14:07, Mika Westerberg wrote:

On Fri, Apr 20, 2018 at 06:07:25PM +0800, John Garry wrote:

+   } else {
+   device->driver_data = dev;


I think this deserves a comment explaining why we (ab)use driver_data
like this.


Sure, could add. I didn't see any other way for the acpi_device 
structure to reference the derived PNP device.


TBH, This overall approach is not good since we are creating the PNP 
device in the scan, and then leaving the device in limbo, waiting for 
the parent to add it, if at all. There's no rule for this.


So I'm looking for ideas on how to improve this.

Thanks,
John



.

[GIT PULL] Please pull powerpc/linux.git powerpc-4.17-3 tag

[Michael Ellerman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Linus,

Please pull some more powerpc fixes for 4.17:

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-4.17-3

for you to fetch changes up to 56376c5864f8ff4ba7c78a80ae857eee3b1d23d8:

  powerpc/kvm: Fix lockups when running KVM guests on Power8 (2018-04-19 
16:22:20 +1000)

- 
powerpc fixes for 4.17 #3

Fix an off-by-one bug in our alternative asm patching which leads to incorrectly
patched code. This bug lay dormant for nearly 10 years but we finally hit it
due to a recent change.

Fix lockups when running KVM guests on Power8 due to a missing check when a
thread that's running KVM comes out of idle.

Fix an out-of-spec behaviour in the XIVE code (P9 interrupt controller).

Fix EEH handling of bridge MMIO windows.

Prevent crashes in our RFI fallback flush handler if firmware didn't tell us the
size of the L1 cache (only seen on simulators).

Thanks to:
  Benjamin Herrenschmidt, Madhavan Srinivasan, Michael Neuling.

- 
Benjamin Herrenschmidt (1):
  powerpc/xive: Fix trying to "push" an already active pool VP

Madhavan Srinivasan (1):
  powerpc/64s: Default l1d_size to 64K in RFI fallback flush

Michael Ellerman (2):
  powerpc/lib: Fix off-by-one in alternate feature patching
  powerpc/kvm: Fix lockups when running KVM guests on Power8

Michael Neuling (1):
  powerpc/eeh: Fix enabling bridge MMIO windows

 arch/powerpc/kernel/eeh_pe.c  |  3 ++-
 arch/powerpc/kernel/idle_book3s.S |  4 ++--
 arch/powerpc/kernel/setup_64.c| 11 +++
 arch/powerpc/lib/feature-fixups.c |  2 +-
 arch/powerpc/sysdev/xive/native.c |  4 
 5 files changed, 20 insertions(+), 4 deletions(-)
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJa2er8AAoJEFHr6jzI4aWAnc4P/2uaDmQ4NN9ETvsn11Ii6y9B
umuQ/TnFmS8piP9LrLyh5A0DNEheEizLf44qJDaXfgnJtV2+ZgKeW8kyzpdOYH1F
B6+Rq25gZ2ItBrKv8vrcfGyBFplVfSfg3KO/NC2tBoB/COCKA2lj6lxo1CvZ8BLq
Ov05mm2grmQ20XJgFQjAiK+GT6JKsra5Vc8WcpX3xj4DOP9yXvJpm5Ui+1RpqK0U
ZuKHocSKUQdIvQBuPcrqU6IVHN51lQLtvb//s3TUpMRS7sb7/y4VHBou93FsT8LZ
rjNKM4104u79ZN7SERRF17bqdY0fgmqHeAB1U8lxP8QvYo14z5ix99d9KjunDHt2
IRI25AhgHo4dfdcFr7sl3fg+85/Njwj4T7a2KPGw0FW4dIwPklodYzxnlVpbBQMB
92J8fKC6G0UsVza2KLySuGY1AO1FvAXw+84JfeqpBsShpH7op2QSa7GjxgF7YeXz
w0guFuUKBOlmiyuuTaq7HPGNVZBqmyAIpTaTKmv/L7pnaOY/fL14y4zPyKDav9VN
E6wLxqh0b1kOMaOzZelps8Isrd/5LCx9wmv6TnZCjGazoy6GtV0NTt4Nl8l0wjJW
uvDm8h6MOnwLG282OyKBJee79vBxKUey3cl41Y5DCkqJDmymnqTCCn/lF24zJ3nf
qpYttmW/n2nfdR/VSEZM
=UKi3
-END PGP SIGNATURE-

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

[Peter Rosin]

On 2018-04-20 12:24, Russell King - ARM Linux wrote:
> On Fri, Apr 20, 2018 at 01:06:49PM +0300, Laurent Pinchart wrote:
>> Hi Peter,
>>
>> Thank you for the patch.
>>
>> On Thursday, 19 April 2018 19:27:51 EEST Peter Rosin wrote:
>>> This makes this driver work with all(?) drivers that are not
>>> componentized and instead expect to connect to a panel/bridge. That
>>> said, the only one tested is atmel_hlcdc.
>>>
>>> This hooks the relevant work function previously called by the encoder
>>> and the component also to the bridge, since the encoder goes away when
>>> connecting to the bridge interface of the driver and the equivalent of
>>> bind/unbind of the component is handled by bridge attach/detach.
>>>
>>> The lifetime requirements of a bridge and a component are slightly
>>> different, which is the reason for struct tda998x_bridge.
>>
>> Couldn't you move the allocation and initialization (tda998x_create) of the 
>> tda998x_priv structure to probe time ? I think you wouldn't need a separate 
>> structure in that case. Unless I'm mistaken there would be an added benefit 
>> of 
>> separating component and bridge initialization, resulting in the encoder not 
>> being initialized at all if the component isn't used. You wouldn't need to 
>> add 
>> a local_encoder parameter to the tda998x_init() function.
> 
> No, I don't like that idea one bit, as I've stated in the past about the
> component API.  The same (probably) goes for the bridge stuff too.
> 
> Consider the following:
> 
> Your DRM system is initialised.  You then remove a module, which results
> in the DRM system being torn down.  You re-insert the module (eg, having
> made a change to it).  The DRM system is then re-initialised.
> 
> At this point, what is the state of variables such as priv->is_on if
> you allocate the structure at probe time?
> 
> What about all the other variables in the driver private structure - are
> you sure that the driver can cope with random values from the previous
> "usage" remaining there?
> 
> At the moment, this isn't a concern for the driver because we
> dev_kzalloc() the structure in the bind callback.  Move that to the
> probe function, and the structure is no longer re-initialised each
> time, and so it retains the previous state.  The driver is not setup
> to cope with that.
> 
> So, to work around that, you would need to reinitialise _everything_
> in the structure that the driver requires, which IMHO is a very
> open to bugs (eg, if a member is missed, or added without the
> necessary re-initialisation), _especially_ when this is not a path
> that will get regular testing.
> 
> If you want to do this for a subset of data, it would be much better
> to separate them into independent structures (maybe one embedded into
> the other) so that this problem can not occur.  That way, a subset
> of the data can be memset() when bound to the rest of the DRM system
> ensuring a consistent driver state and still achieve what you're
> suggesting.

This was the exact reason I added struct tda998x_bridge. It seemed
very risky to move the tda998x_create call (or some of its meat) to
the probe function. Even if that could be done I think it should
definitely be a separate patch.

Cheers,
Peter

Re: [RFC PATCH 2/2] HISI LPC: Add PNP device support

[Andy Shevchenko]

On Fri, 2018-04-20 at 14:09 +0100, John Garry wrote:
> On 20/04/2018 13:50, Andy Shevchenko wrote:
> > On Fri, 2018-04-20 at 18:07 +0800, John Garry wrote:

> > > + if (res->flags | IORESOURCE_IO)
> > 
> > What does this mean?
> 
> Here we check the resource flag for each resource for this PNP device
> - 
> for IO resources we must translate the resource value from the bus 
> address to the logical PIO address.

Please, re-read your code again.

-- 
Andy Shevchenko 
Intel Finland Oy

[PATCH 6/8] ASoC: sh: Update menu title and platform dependency

[Geert Uytterhoeven]

Change the menu title to refer to "Renesas SoCs" instead of "SuperH", as
both SuperH and ARM SoCs are supported.

Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is ARCH_RENESAS a more appropriate platform dependency for Renesas ARM
SoCs than the legacy ARCH_SHMOBILE, hence use the former.
Renesas SuperH SH-Mobile SoCs are still covered by the SUPERH
dependency.

This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future.

Signed-off-by: Geert Uytterhoeven 
---
 sound/soc/sh/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sh/Kconfig b/sound/soc/sh/Kconfig
index 1aa5cd77ca24a06f..c1b7fb91e3063f2b 100644
--- a/sound/soc/sh/Kconfig
+++ b/sound/soc/sh/Kconfig
@@ -1,5 +1,5 @@
-menu "SoC Audio support for SuperH"
-   depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
+menu "SoC Audio support for Renesas SoCs"
+   depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
 
 config SND_SOC_PCM_SH7760
tristate "SoC Audio support for Renesas SH7760"
-- 
2.7.4

[PATCH v2 1/9] nds32: lib: To use generic lib instead of libgcc to prevent the symbol undefined issue.

[Greentime Hu]

We can use the generic lib to fix these error because the symbol of
libgcc in toolchain is not exported.

ERROR: "__ucmpdi2" [fs/xfs/xfs.ko] undefined!
ERROR: "__ashrdi3" [fs/xfs/xfs.ko] undefined!
ERROR: "__lshrdi3" [fs/xfs/xfs.ko] undefined!
ERROR: "__ashldi3" [fs/ntfs/ntfs.ko] undefined!
...

Signed-off-by: Greentime Hu 
Acked-by: Arnd Bergmann 
---
 arch/nds32/Kconfig  | 6 ++
 arch/nds32/Makefile | 3 ---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/nds32/Kconfig b/arch/nds32/Kconfig
index 249f38d3388f..98e05f997f91 100644
--- a/arch/nds32/Kconfig
+++ b/arch/nds32/Kconfig
@@ -9,6 +9,12 @@ config NDS32
select CLKSRC_MMIO
select CLONE_BACKWARDS
select COMMON_CLK
+   select GENERIC_ASHLDI3
+   select GENERIC_ASHRDI3
+   select GENERIC_LSHRDI3
+   select GENERIC_CMPDI2
+   select GENERIC_MULDI3
+   select GENERIC_UCMPDI2
select GENERIC_ATOMIC64
select GENERIC_CPU_DEVICES
select GENERIC_CLOCKEVENTS
diff --git a/arch/nds32/Makefile b/arch/nds32/Makefile
index 91f933d5a962..20edf34e70ce 100644
--- a/arch/nds32/Makefile
+++ b/arch/nds32/Makefile
@@ -23,9 +23,6 @@ exportTEXTADDR
 # If we have a machine-specific directory, then include it in the build.
 core-y += arch/nds32/kernel/ arch/nds32/mm/
 libs-y += arch/nds32/lib/
-LIBGCC_PATH:= \
-  $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name)
-libs-y += $(LIBGCC_PATH)
 
 ifneq '$(CONFIG_NDS32_BUILTIN_DTB)' '""'
 BUILTIN_DTB := y
-- 
1.9.5

[PATCH v2 2/9] nds32: Fix building error when CONFIG_FREEZE is enabled.

[Greentime Hu]

To include kernel/Kconfig.freezer to make sure the dependency between
CONFIG_CGROUP_FREEZER and CONFIG_FREEZER

It will cause building error when I make allmodconfig.

kernel/cgroup/freezer.c: In function 'freezer_css_online':
kernel/cgroup/freezer.c:116:15: error: 'system_freezing_cnt' undeclared (first 
use in this function)
   atomic_inc(_freezing_cnt);
   ^~~
kernel/cgroup/freezer.c:116:15: note: each undeclared identifier is reported 
only once for each function it appears in
kernel/cgroup/freezer.c: In function 'freezer_css_offline':
kernel/cgroup/freezer.c:137:15: error: 'system_freezing_cnt' undeclared (first 
use in this function)
   atomic_dec(_freezing_cnt);
   ^~~
kernel/cgroup/freezer.c: In function 'freezer_attach':
kernel/cgroup/freezer.c:181:4: error: implicit declaration of function 
'freeze_task' [-Werror=implicit-function-declaration]
freeze_task(task);
^~~
kernel/cgroup/freezer.c: In function 'freezer_apply_state':
kernel/cgroup/freezer.c:360:16: error: 'system_freezing_cnt' undeclared (first 
use in this function)
atomic_inc(_freezing_cnt);
^~~

Signed-off-by: Greentime Hu 
Acked-by: Arnd Bergmann 
---
 arch/nds32/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/nds32/Kconfig b/arch/nds32/Kconfig
index 98e05f997f91..b7404f2dcf5b 100644
--- a/arch/nds32/Kconfig
+++ b/arch/nds32/Kconfig
@@ -88,6 +88,7 @@ endmenu
 
 menu "Kernel Features"
 source "kernel/Kconfig.preempt"
+source "kernel/Kconfig.freezer"
 source "mm/Kconfig"
 source "kernel/Kconfig.hz"
 endmenu
-- 
1.9.5

Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

[Eric W. Biederman]

Rahul Lakkireddy  writes:

> On Thursday, April 04/19/18, 2018 at 20:23:37 +0530, Eric W. Biederman wrote:
>> Rahul Lakkireddy  writes:
>> 
>> > On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave Young wrote:
>> >> On 04/18/18 at 06:01pm, Rahul Lakkireddy wrote:
>> >> > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
>> >> > > Hi Rahul,
>> >> > > On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
>> >> > > > On production servers running variety of workloads over time, kernel
>> >> > > > panic can happen sporadically after days or even months. It is
>> >> > > > important to collect as much debug logs as possible to root cause
>> >> > > > and fix the problem, that may not be easy to reproduce. Snapshot of
>> >> > > > underlying hardware/firmware state (like register dump, firmware
>> >> > > > logs, adapter memory, etc.), at the time of kernel panic will be 
>> >> > > > very
>> >> > > > helpful while debugging the culprit device driver.
>> >> > > > 
>> >> > > > This series of patches add new generic framework that enable device
>> >> > > > drivers to collect device specific snapshot of the hardware/firmware
>> >> > > > state of the underlying device in the crash recovery kernel. In 
>> >> > > > crash
>> >> > > > recovery kernel, the collected logs are added as elf notes to
>> >> > > > /proc/vmcore, which is copied by user space scripts for 
>> >> > > > post-analysis.
>> >> > > > 
>> >> > > > The sequence of actions done by device drivers to append their 
>> >> > > > device
>> >> > > > specific hardware/firmware logs to /proc/vmcore are as follows:
>> >> > > > 
>> >> > > > 1. During probe (before hardware is initialized), device drivers
>> >> > > > register to the vmcore module (via vmcore_add_device_dump()), with
>> >> > > > callback function, along with buffer size and log name needed for
>> >> > > > firmware/hardware log collection.
>> >> > > 
>> >> > > I assumed the elf notes info should be prepared while 
>> >> > > kexec_[file_]load
>> >> > > phase. But I did not read the old comment, not sure if it has been 
>> >> > > discussed
>> >> > > or not.
>> >> > > 
>> >> > 
>> >> > We must not collect dumps in crashing kernel. Adding more things in
>> >> > crash dump path risks not collecting vmcore at all. Eric had
>> >> > discussed this in more detail at:
>> >> > 
>> >> > https://lkml.org/lkml/2018/3/24/319
>> >> > 
>> >> > We are safe to collect dumps in the second kernel. Each device dump
>> >> > will be exported as an elf note in /proc/vmcore.
>> >> 
>> >> I understand that we should avoid adding anything in crash path.  And I 
>> >> also
>> >> agree to collect device dump in second kernel.  I just assumed device
>> >> dump use some memory area to store the debug info and the memory
>> >> is persistent so that this can be done in 2 steps, first register the
>> >> address in elf header in kexec_load, then collect the dump in 2nd
>> >> kernel.  But it seems the driver is doing some other logic to collect
>> >> the info instead of just that simple like I thought. 
>> >> 
>> >
>> > It seems simpler, but I'm concerned with waste of memory area, if
>> > there are no device dumps being collected in second kernel. In
>> > approach proposed in these series, we dynamically allocate memory
>> > for the device dumps from second kernel's available memory.
>> 
>> Don't count that kernel having more than about 128MiB.
>> 
>
> If large dump is expected, Administrator can increase the memory
> allocated to the second kernel (using crashkernel boot param), to
> ensure device dumps get collected.

Except 128MiB is already a already a huge amount to reserve.  I
typically have run crash dumps with 16MiB of memory and thought it was
overkill.  Looking below 32MiB seems a bit high but it is small enough
that it is still doable.  I am baffled at how 2GiB can be guaranteed to fit
in 32MiB (sparse register space?) but if it works reliably.

>> For that reason if for no other it would be nice if it was possible to
>> have the driver to not initialize the device and just stand there
>> handing out the data a piece at a time as it is read from /proc/vmcore.
>> 
>
> Since cxgb4 is a network driver, it can be used to transfer the dumps
> over the network. So we must ensure the dumps get collected and
> stored, before device gets initialized to transfer dumps over
> the network.

Good point.  For some reason I was thinking it was an infiniband and not
an 10GiB ethernet device.

>> The 2GiB number I read earlier concerns me for working in a limited
>> environment.
>> 
>
> All dumps, including the 2GB on-chip memory dump, is compressed by
> the cxgb4 driver as they are collected. The overall compressed dump
> comes out at max 32 MB.
>
>> It might even make sense to separate this into a completely separate
>> module (depended upon the main driver if it makes sense to share
>> the functionality) so that people performing crash dumps would not
>> hesitate 

Re: [RFC PATCH 2/2] HISI LPC: Add PNP device support

[John Garry]

Hi Mika,


 /*
@@ -469,8 +472,11 @@ static int hisi_lpc_acpi_probe(struct device *hostdev)
struct acpi_device *child;
int size, ret, count = 0, cell_num = 0;

-   list_for_each_entry(child, >children, node)
+   list_for_each_entry(child, >children, node) {
+   if (acpi_is_pnp_device(child))
+   continue;
cell_num++;
+   }

/* allocate the mfd cell and companion ACPI info, one per child */
size = sizeof(*mfd_cells) + sizeof(*hisi_lpc_mfd_cells);
@@ -492,6 +498,9 @@ static int hisi_lpc_acpi_probe(struct device *hostdev)
.pnpid = pnpid,
};

+   if (acpi_is_pnp_device(child))
+   continue;
+
/*
 * For any instances of this host controller (Hip06 and Hip07
 * are the only chipsets), we would not have multiple slaves
@@ -523,6 +532,33 @@ static int hisi_lpc_acpi_probe(struct device *hostdev)
return ret;
}

+   list_for_each_entry(child, >children, node) {
+   struct pnp_resource *pnp_res;
+   struct pnp_dev *pnp_dev;
+   int rc;
+
+   if (!acpi_is_pnp_device(child))
+   continue;
+
+   pnp_dev = child->driver_data;


...or better yet a PNP helper function that makes this more
understandable.


Sure, but I would not say the helper function would do the same, due to 
to (ab)use of driver_data element. As I mentioned in patch 1/2, I 
couldn't see a current method for the acpi_device to reference the PNP 
device.





+
+   /*
+* Prior to adding the device, we need to translate the
+* resources to logical PIO addresses.
+*/
+   list_for_each_entry(pnp_res, _dev->resources, list) {
+   struct resource *res = _res->res;
+
+   if (res->flags | IORESOURCE_IO)


I think you should use

if (resource_type(res) == IORESOURCE_IO)

instead.


Yes, since I don't know the difference between logical OR and logical AND :)




+   hisi_lpc_acpi_xlat_io_res(child, adev, res);
+   }
+   rc = pnp_add_device(pnp_dev);
+   if (rc) {
+   put_device(_dev->dev);
+   return rc;
+   }
+   }
+


Cheers,
John


return 0;
 }

--
1.9.1


.

Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM

[Matthew Wilcox]

On Fri, Apr 20, 2018 at 03:08:52PM +0200, Michal Hocko wrote:
> > In order to detect these bugs reliably I submit this patch that changes
> > kvmalloc to always use vmalloc if CONFIG_DEBUG_VM is turned on.
> 
> No way. This is just wrong! First of all, you will explode most likely
> on many allocations of small sizes. Second, CONFIG_DEBUG_VM tends to be
> enabled quite often.

I think it'll still suit Mikulas' debugging needs if we always use
vmalloc for sizes above PAGE_SIZE?

Re: [PATCH v6 24/30] drm/rockchip: Disable PSR on input events

[Andrzej Hajda]

Hi Enric,


On 05.04.2018 11:49, Enric Balletbo i Serra wrote:
> From: "Kristian H. Kristensen" 
>
> To improve PSR exit latency, we speculatively start exiting when we
> receive input events. Occasionally, this may lead to false positives,
> but most of the time we get a head start on coming out of PSR. Depending
> on how userspace takes to produce a new frame in response to the event,
> this can completely hide the exit latency. In case of Chrome OS, we
> typically get the input notifier 50ms or more before the dirty_fb
> triggered exit.

This patch is quite controversial and require more attention/discussion
and probably changes.
The rest of the patches is OK, and all have r-b/t-b tags.
If you prefer I can merge all other patches, if you rebase patches 25-30
on top of patch 23, or I can only merge patches 01-23.
What do you prefer?

Regards
Andrzej

>
> Signed-off-by: Kristian H. Kristensen 
> Signed-off-by: Thierry Escande 
> Signed-off-by: Enric Balletbo i Serra 
> Tested-by: Marek Szyprowski 
> ---
>
>  drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 134 
> 
>  1 file changed, 134 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> index 9376f4396b6b..a107845ba97c 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> @@ -12,6 +12,8 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include 
> +
>  #include 
>  #include 
>  
> @@ -35,6 +37,9 @@ struct psr_drv {
>   enum psr_state  state;
>  
>   struct delayed_work flush_work;
> + struct work_struct  disable_work;
> +
> + struct input_handlerinput_handler;
>  
>   int (*set)(struct drm_encoder *encoder, bool enable);
>  };
> @@ -133,6 +138,18 @@ static void psr_flush_handler(struct work_struct *work)
>   mutex_unlock(>lock);
>  }
>  
> +static void psr_disable_handler(struct work_struct *work)
> +{
> + struct psr_drv *psr = container_of(work, struct psr_drv, disable_work);
> +
> + /* If the state has changed since we initiated the flush, do nothing */
> + mutex_lock(>lock);
> + if (psr->state == PSR_ENABLE)
> + psr_set_state_locked(psr, PSR_FLUSH);
> + mutex_unlock(>lock);
> + mod_delayed_work(system_wq, >flush_work, PSR_FLUSH_TIMEOUT_MS);
> +}
> +
>  /**
>   * rockchip_drm_psr_activate - activate PSR on the given pipe
>   * @encoder: encoder to obtain the PSR encoder
> @@ -173,6 +190,7 @@ int rockchip_drm_psr_deactivate(struct drm_encoder 
> *encoder)
>   psr->active = false;
>   mutex_unlock(>lock);
>   cancel_delayed_work_sync(>flush_work);
> + cancel_work_sync(>disable_work);
>  
>   return 0;
>  }
> @@ -226,6 +244,95 @@ void rockchip_drm_psr_flush_all(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
>  
> +static void psr_input_event(struct input_handle *handle,
> + unsigned int type, unsigned int code,
> + int value)
> +{
> + struct psr_drv *psr = handle->handler->private;
> +
> + schedule_work(>disable_work);
> +}
> +
> +static int psr_input_connect(struct input_handler *handler,
> +  struct input_dev *dev,
> +  const struct input_device_id *id)
> +{
> + struct input_handle *handle;
> + int error;
> +
> + handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL);
> + if (!handle)
> + return -ENOMEM;
> +
> + handle->dev = dev;
> + handle->handler = handler;
> + handle->name = "rockchip-psr";
> +
> + error = input_register_handle(handle);
> + if (error)
> + goto err2;
> +
> + error = input_open_device(handle);
> + if (error)
> + goto err1;
> +
> + return 0;
> +
> +err1:
> + input_unregister_handle(handle);
> +err2:
> + kfree(handle);
> + return error;
> +}
> +
> +static void psr_input_disconnect(struct input_handle *handle)
> +{
> + input_close_device(handle);
> + input_unregister_handle(handle);
> + kfree(handle);
> +}
> +
> +/* Same device ids as cpu-boost */
> +static const struct input_device_id psr_ids[] = {
> + {
> + .flags = INPUT_DEVICE_ID_MATCH_EVBIT |
> +  INPUT_DEVICE_ID_MATCH_ABSBIT,
> + .evbit = { BIT_MASK(EV_ABS) },
> + .absbit = { [BIT_WORD(ABS_MT_POSITION_X)] =
> + BIT_MASK(ABS_MT_POSITION_X) |
> + BIT_MASK(ABS_MT_POSITION_Y) },
> + }, /* multi-touch touchscreen */
> + {
> + .flags = INPUT_DEVICE_ID_MATCH_EVBIT,
> + .evbit = { BIT_MASK(EV_ABS) },
> + .absbit = { [BIT_WORD(ABS_X)] = BIT_MASK(ABS_X) }
> +
> + }, /* stylus or joystick device */
> 

Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM

[Michal Hocko]

On Fri 20-04-18 06:41:36, Matthew Wilcox wrote:
> On Fri, Apr 20, 2018 at 03:08:52PM +0200, Michal Hocko wrote:
> > > In order to detect these bugs reliably I submit this patch that changes
> > > kvmalloc to always use vmalloc if CONFIG_DEBUG_VM is turned on.
> > 
> > No way. This is just wrong! First of all, you will explode most likely
> > on many allocations of small sizes. Second, CONFIG_DEBUG_VM tends to be
> > enabled quite often.
> 
> I think it'll still suit Mikulas' debugging needs if we always use
> vmalloc for sizes above PAGE_SIZE?

Even if that was the case then this doesn't sounds like CONFIG_DEBUG_VM
material. We do not want a completely different behavior when the config
is enabled. If we really need some better fallback testing coverage
then the fault injection, as suggested by Vlastimil, sounds much more
reasonable to me

-- 
Michal Hocko
SUSE Labs

Re: [RFC] vhost: introduce mdev based hardware vhost backend

[Michael S. Tsirkin]

On Fri, Apr 20, 2018 at 03:50:41AM +, Liang, Cunming wrote:
> 
> 
> > -Original Message-
> > From: Bie, Tiwei
> > Sent: Friday, April 20, 2018 11:28 AM
> > To: Michael S. Tsirkin 
> > Cc: Jason Wang ; alex.william...@redhat.com;
> > ddut...@redhat.com; Duyck, Alexander H ;
> > virtio-...@lists.oasis-open.org; linux-kernel@vger.kernel.org;
> > k...@vger.kernel.org; virtualizat...@lists.linux-foundation.org;
> > net...@vger.kernel.org; Daly, Dan ; Liang, Cunming
> > ; Wang, Zhihong ; Tan,
> > Jianfeng ; Wang, Xiao W ;
> > Tian, Kevin 
> > Subject: Re: [RFC] vhost: introduce mdev based hardware vhost backend
> > 
> > On Thu, Apr 19, 2018 at 09:40:23PM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Apr 10, 2018 at 03:25:45PM +0800, Jason Wang wrote:
> > > > > > > One problem is that, different virtio ring compatible devices
> > > > > > > may have different device interfaces. That is to say, we will
> > > > > > > need different drivers in QEMU. It could be troublesome. And
> > > > > > > that's what this patch trying to fix. The idea behind this
> > > > > > > patch is very simple: mdev is a standard way to emulate device
> > > > > > > in kernel.
> > > > > > So you just move the abstraction layer from qemu to kernel, and
> > > > > > you still need different drivers in kernel for different device
> > > > > > interfaces of accelerators. This looks even more complex than
> > > > > > leaving it in qemu. As you said, another idea is to implement
> > > > > > userspace vhost backend for accelerators which seems easier and
> > > > > > could co-work with other parts of qemu without inventing new type of
> > messages.
> > > > > I'm not quite sure. Do you think it's acceptable to add various
> > > > > vendor specific hardware drivers in QEMU?
> > > > >
> > > >
> > > > I don't object but we need to figure out the advantages of doing it
> > > > in qemu too.
> > > >
> > > > Thanks
> > >
> > > To be frank kernel is exactly where device drivers belong.  DPDK did
> > > move them to userspace but that's merely a requirement for data path.
> > > *If* you can have them in kernel that is best:
> > > - update kernel and there's no need to rebuild userspace
> > > - apps can be written in any language no need to maintain multiple
> > >   libraries or add wrappers
> > > - security concerns are much smaller (ok people are trying to
> > >   raise the bar with IOMMUs and such, but it's already pretty
> > >   good even without)
> > >
> > > The biggest issue is that you let userspace poke at the device which
> > > is also allowed by the IOMMU to poke at kernel memory (needed for
> > > kernel driver to work).
> > 
> > I think the device won't and shouldn't be allowed to poke at kernel memory. 
> > Its
> > kernel driver needs some kernel memory to work. But the device doesn't have
> > the access to them. Instead, the device only has the access to:
> > 
> > (1) the entire memory of the VM (if vIOMMU isn't used) or
> > (2) the memory belongs to the guest virtio device (if
> > vIOMMU is being used).
> > 
> > Below is the reason:
> > 
> > For the first case, we should program the IOMMU for the hardware device 
> > based
> > on the info in the memory table which is the entire memory of the VM.
> > 
> > For the second case, we should program the IOMMU for the hardware device
> > based on the info in the shadow page table of the vIOMMU.
> > 
> > So the memory can be accessed by the device is limited, it should be safe
> > especially for the second case.
> > 
> > My concern is that, in this RFC, we don't program the IOMMU for the mdev
> > device in the userspace via the VFIO API directly. Instead, we pass the 
> > memory
> > table to the kernel driver via the mdev device (BAR0) and ask the driver to 
> > do the
> > IOMMU programming. Someone may don't like it. The main reason why we don't
> > program IOMMU via VFIO API in userspace directly is that, currently IOMMU
> > drivers don't support mdev bus.
> > 
> > >
> > > Yes, maybe if device is not buggy it's all fine, but it's better if we
> > > do not have to trust the device otherwise the security picture becomes
> > > more murky.
> > >
> > > I suggested attaching a PASID to (some) queues - see my old post
> > > "using PASIDs to enable a safe variant of direct ring access".
> > 
> Ideally we can have a device binding with normal driver in host, meanwhile 
> support to allocate a few queues attaching with PASID on-demand. By vhost 
> mdev transport channel, the data path ability of queues(as a device) can 
> expose to qemu vhost adaptor as a vDPA instance. Then we can avoid VF number 
> limitation, providing vhost data path acceleration in a small granularity.

Exactly my point.

> > It's pretty cool. We also have some similar ideas.
> > Cunming will talk more about this.
> > 
> > Best 

Re: [PATCH v6 24/30] drm/rockchip: Disable PSR on input events

[Enric Balletbo i Serra]

Hi Andrzej,

On 20/04/18 15:47, Andrzej Hajda wrote:
> Hi Enric,
> 
> 
> On 05.04.2018 11:49, Enric Balletbo i Serra wrote:
>> From: "Kristian H. Kristensen" 
>>
>> To improve PSR exit latency, we speculatively start exiting when we
>> receive input events. Occasionally, this may lead to false positives,
>> but most of the time we get a head start on coming out of PSR. Depending
>> on how userspace takes to produce a new frame in response to the event,
>> this can completely hide the exit latency. In case of Chrome OS, we
>> typically get the input notifier 50ms or more before the dirty_fb
>> triggered exit.
> 
> This patch is quite controversial and require more attention/discussion
> and probably changes.

Agree.

> The rest of the patches is OK, and all have r-b/t-b tags.
> If you prefer I can merge all other patches, if you rebase patches 25-30
> on top of patch 23, or I can only merge patches 01-23.
> What do you prefer?
> 

If the patches 25-30 are also fine let me rebase those, and lets start a
discussion regarding patches 23-25 on another patchset. I'll send another
version without 23-25.

Regards,
 Enric

> Regards
> Andrzej
> 
>>
>> Signed-off-by: Kristian H. Kristensen 
>> Signed-off-by: Thierry Escande 
>> Signed-off-by: Enric Balletbo i Serra 
>> Tested-by: Marek Szyprowski 
>> ---
>>
>>  drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 134 
>> 
>>  1 file changed, 134 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
>> b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
>> index 9376f4396b6b..a107845ba97c 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
>> @@ -12,6 +12,8 @@
>>   * GNU General Public License for more details.
>>   */
>>  
>> +#include 
>> +
>>  #include 
>>  #include 
>>  
>> @@ -35,6 +37,9 @@ struct psr_drv {
>>  enum psr_state  state;
>>  
>>  struct delayed_work flush_work;
>> +struct work_struct  disable_work;
>> +
>> +struct input_handlerinput_handler;
>>  
>>  int (*set)(struct drm_encoder *encoder, bool enable);
>>  };
>> @@ -133,6 +138,18 @@ static void psr_flush_handler(struct work_struct *work)
>>  mutex_unlock(>lock);
>>  }
>>  
>> +static void psr_disable_handler(struct work_struct *work)
>> +{
>> +struct psr_drv *psr = container_of(work, struct psr_drv, disable_work);
>> +
>> +/* If the state has changed since we initiated the flush, do nothing */
>> +mutex_lock(>lock);
>> +if (psr->state == PSR_ENABLE)
>> +psr_set_state_locked(psr, PSR_FLUSH);
>> +mutex_unlock(>lock);
>> +mod_delayed_work(system_wq, >flush_work, PSR_FLUSH_TIMEOUT_MS);
>> +}
>> +
>>  /**
>>   * rockchip_drm_psr_activate - activate PSR on the given pipe
>>   * @encoder: encoder to obtain the PSR encoder
>> @@ -173,6 +190,7 @@ int rockchip_drm_psr_deactivate(struct drm_encoder 
>> *encoder)
>>  psr->active = false;
>>  mutex_unlock(>lock);
>>  cancel_delayed_work_sync(>flush_work);
>> +cancel_work_sync(>disable_work);
>>  
>>  return 0;
>>  }
>> @@ -226,6 +244,95 @@ void rockchip_drm_psr_flush_all(struct drm_device *dev)
>>  }
>>  EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
>>  
>> +static void psr_input_event(struct input_handle *handle,
>> +unsigned int type, unsigned int code,
>> +int value)
>> +{
>> +struct psr_drv *psr = handle->handler->private;
>> +
>> +schedule_work(>disable_work);
>> +}
>> +
>> +static int psr_input_connect(struct input_handler *handler,
>> + struct input_dev *dev,
>> + const struct input_device_id *id)
>> +{
>> +struct input_handle *handle;
>> +int error;
>> +
>> +handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL);
>> +if (!handle)
>> +return -ENOMEM;
>> +
>> +handle->dev = dev;
>> +handle->handler = handler;
>> +handle->name = "rockchip-psr";
>> +
>> +error = input_register_handle(handle);
>> +if (error)
>> +goto err2;
>> +
>> +error = input_open_device(handle);
>> +if (error)
>> +goto err1;
>> +
>> +return 0;
>> +
>> +err1:
>> +input_unregister_handle(handle);
>> +err2:
>> +kfree(handle);
>> +return error;
>> +}
>> +
>> +static void psr_input_disconnect(struct input_handle *handle)
>> +{
>> +input_close_device(handle);
>> +input_unregister_handle(handle);
>> +kfree(handle);
>> +}
>> +
>> +/* Same device ids as cpu-boost */
>> +static const struct input_device_id psr_ids[] = {
>> +{
>> +.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
>> + INPUT_DEVICE_ID_MATCH_ABSBIT,
>> +.evbit = { BIT_MASK(EV_ABS) },
>> +.absbit = { [BIT_WORD(ABS_MT_POSITION_X)] =
>> +  

Re: [PATCH bpf-next 1/5] samples/bpf: Fix typo in comment

[Jesper Dangaard Brouer]

On Fri, 20 Apr 2018 14:21:16 +0100
Daniel Thompson  wrote:

> On Fri, Apr 20, 2018 at 02:10:04PM +0200, Jesper Dangaard Brouer wrote:
> > 
> > On Thu, 19 Apr 2018 09:34:02 +0800 Leo Yan  wrote:
> >   
> > > Fix typo by replacing 'iif' with 'if'.
> > > 
> > > Signed-off-by: Leo Yan 
> > > ---
> > >  samples/bpf/bpf_load.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
> > > index bebe418..28e4678 100644
> > > --- a/samples/bpf/bpf_load.c
> > > +++ b/samples/bpf/bpf_load.c
> > > @@ -393,7 +393,7 @@ static int load_elf_maps_section(struct bpf_map_data 
> > > *maps, int maps_shndx,
> > >   continue;
> > >   if (sym[nr_maps].st_shndx != maps_shndx)
> > >   continue;
> > > - /* Only increment iif maps section */
> > > + /* Only increment if maps section */
> > >   nr_maps++;
> > >   }  
> > 
> > This was actually not a typo from my side.
> > 
> > With 'iif' I mean 'if and only if' ... but it doesn't matter much.  
> 
> I think 'if and only if' is more commonly abbreviated 'iff' isn't it?

Ah, yes![1]  -- then it *is* actually a typo! - LOL

I'm fine with changing this to "if" :-)


[1] https://en.wikipedia.org/wiki/If_and_only_if

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent" devices

[Mika Westerberg]

On Fri, Apr 20, 2018 at 02:24:18PM +0100, John Garry wrote:
> Hi Mika,
> 
> On 20/04/2018 14:07, Mika Westerberg wrote:
> > On Fri, Apr 20, 2018 at 06:07:25PM +0800, John Garry wrote:
> > > + } else {
> > > + device->driver_data = dev;
> > 
> > I think this deserves a comment explaining why we (ab)use driver_data
> > like this.
> 
> Sure, could add. I didn't see any other way for the acpi_device structure to
> reference the derived PNP device.
> 
> TBH, This overall approach is not good since we are creating the PNP device
> in the scan, and then leaving the device in limbo, waiting for the parent to
> add it, if at all. There's no rule for this.
> 
> So I'm looking for ideas on how to improve this.

One idea is to make pnpacpi_add_device() available outside of PNP and
call it directly (or some variation) in hisi_lpc.c when it walks over
its children.

[PATCH] [net] ipv6: sr: fix NULL pointer dereference in seg6_do_srh_encap()- v4 pkts

[Ahmed Abdelsalam]

In case of seg6 in encap mode, seg6_do_srh_encap() calls set_tun_src()
in order to set the src addr of outer IPv6 header.

The net_device is required for set_tun_src(). However calling ip6_dst_idev()
on dst_entry in case of IPv4 traffic results on the following bug.

Using just dst->dev should fix this BUG.

[  196.242461] BUG: unable to handle kernel NULL pointer dereference at 

[  196.242975] PGD 80010f076067 P4D 80010f076067 PUD 10f060067 PMD 0
[  196.243329] Oops:  [#1] SMP PTI
[  196.243468] Modules linked in: nfsd auth_rpcgss nfs_acl nfs lockd grace 
fscache sunrpc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc 
aesni_intel aes_x86_64 crypto_simd cryptd input_leds glue_helper led_class 
pcspkr serio_raw mac_hid video autofs4 hid_generic usbhid hid e1000 i2c_piix4 
ahci pata_acpi libahci
[  196.244362] CPU: 2 PID: 1089 Comm: ping Not tainted 4.16.0+ #1
[  196.244606] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
VirtualBox 12/01/2006
[  196.244968] RIP: 0010:seg6_do_srh_encap+0x1ac/0x300
[  196.245236] RSP: 0018:b2ce00b23a60 EFLAGS: 00010202
[  196.245464] RAX:  RBX: 8c7f53eea300 RCX: 
[  196.245742] RDX: f100 RSI: 8c7f52085a6c RDI: 8c7f41166850
[  196.246018] RBP: b2ce00b23aa8 R08: 000261e0 R09: 8c7f41166800
[  196.246294] R10: dce5040ac780 R11: 8c7f41166828 R12: 8c7f41166808
[  196.246570] R13: 8c7f52085a44 R14: b73211c0 R15: 8c7e69e44200
[  196.246846] FS:  7fc448789700() GS:8c7f59d0() 
knlGS:
[  196.247286] CS:  0010 DS:  ES:  CR0: 80050033
[  196.247526] CR2:  CR3: 00010f05a000 CR4: 000406e0
[  196.247804] Call Trace:
[  196.247972]  seg6_do_srh+0x15b/0x1c0
[  196.248156]  seg6_output+0x3c/0x220
[  196.248341]  ? prandom_u32+0x14/0x20
[  196.248526]  ? ip_idents_reserve+0x6c/0x80
[  196.248723]  ? __ip_select_ident+0x90/0x100
[  196.248923]  ? ip_append_data.part.50+0x6c/0xd0
[  196.249133]  lwtunnel_output+0x44/0x70
[  196.249328]  ip_send_skb+0x15/0x40
[  196.249515]  raw_sendmsg+0x8c3/0xac0
[  196.249701]  ? _copy_from_user+0x2e/0x60
[  196.249897]  ? rw_copy_check_uvector+0x53/0x110
[  196.250106]  ? _copy_from_user+0x2e/0x60
[  196.250299]  ? copy_msghdr_from_user+0xce/0x140
[  196.250508]  sock_sendmsg+0x36/0x40
[  196.250690]  ___sys_sendmsg+0x292/0x2a0
[  196.250881]  ? _cond_resched+0x15/0x30
[  196.251074]  ? copy_termios+0x1e/0x70
[  196.251261]  ? _copy_to_user+0x22/0x30
[  196.251575]  ? tty_mode_ioctl+0x1c3/0x4e0
[  196.251782]  ? _cond_resched+0x15/0x30
[  196.251972]  ? mutex_lock+0xe/0x30
[  196.252152]  ? vvar_fault+0xd2/0x110
[  196.252337]  ? __do_fault+0x1f/0xc0
[  196.252521]  ? __handle_mm_fault+0xc1f/0x12d0
[  196.252727]  ? __sys_sendmsg+0x63/0xa0
[  196.252919]  __sys_sendmsg+0x63/0xa0
[  196.253107]  do_syscall_64+0x72/0x200
[  196.253305]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[  196.253530] RIP: 0033:0x7fc4480b0690
[  196.253715] RSP: 002b:7ffde9f252f8 EFLAGS: 0246 ORIG_RAX: 
002e
[  196.254053] RAX: ffda RBX: 0040 RCX: 7fc4480b0690
[  196.254331] RDX:  RSI: 0060a360 RDI: 0003
[  196.254608] RBP: 7ffde9f253f0 R08: 002d1e81 R09: 0002
[  196.254884] R10: 7ffde9f250c0 R11: 0246 R12: 00b22070
[  196.255205] R13: 20c49ba5e353f7cf R14: 431bde82d7b634db R15: 7ffde9f278fe
[  196.255484] Code: a5 0f b6 45 c0 41 88 41 28 41 0f b6 41 2c 48 c1 e0 04 49 
8b 54 01 38 49 8b 44 01 30 49 89 51 20 49 89 41 18 48 8b 83 b0 00 00 00 <48> 8b 
30 49 8b 86 08 0b 00 00 48 8b 40 20 48 8b 50 08 48 0b 10
[  196.256190] RIP: seg6_do_srh_encap+0x1ac/0x300 RSP: b2ce00b23a60
[  196.256445] CR2: 
[  196.256676] ---[ end trace 71af7d093603885c ]---

Fixes: 8936ef7604c11 ipv6: sr: fix NULL pointer dereference when setting encap 
source address
Signed-off-by: Ahmed Abdelsalam 
---
I tested the patch for IPv6 and IPv4 traffic 

 net/ipv6/seg6_iptunnel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index f343e6f..5fe1394 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -136,7 +136,7 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct 
ipv6_sr_hdr *osrh, int proto)
isrh->nexthdr = proto;
 
hdr->daddr = isrh->segments[isrh->first_segment];
-   set_tun_src(net, ip6_dst_idev(dst)->dev, >daddr, >saddr);
+   set_tun_src(net, dst->dev, >daddr, >saddr);
 
 #ifdef CONFIG_IPV6_SEG6_HMAC
if (sr_has_hmac(isrh)) {
-- 
2.1.4

Re: [PATCH v2 05/10] media: v4l: Add definitions for MPEG2 frame format and header metadata

[Hans Verkuil]

On 04/19/18 17:45, Paul Kocialkowski wrote:
> Stateless video decoding engines require both the MPEG slices and
> associated metadata from the video stream in order to decode frames.
> 
> This introduces definitions for a new pixel format, describing buffers
> with MPEG2 slice data, as well as a control structure for passing the
> frame header (metadata) to drivers.
> 
> Signed-off-by: Paul Kocialkowski 
> Signed-off-by: Florent Revest 
> ---
>  drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++
>  drivers/media/v4l2-core/v4l2-ioctl.c |  1 +
>  include/uapi/linux/v4l2-controls.h   | 26 ++
>  include/uapi/linux/videodev2.h   |  3 +++
>  4 files changed, 40 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index ba05a8b9a095..fcdc12b9a9e0 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -761,6 +761,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>   case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: return 
> "Vertical MV Search Range";
>   case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: return "Repeat 
> Sequence Header";
>   case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME:   return "Force 
> Key Frame";
> + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:   return "MPEG2 
> Frame Header";
>  
>   /* VPX controls */
>   case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS:return "VPX 
> Number of Partitions";
> @@ -1152,6 +1153,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
> v4l2_ctrl_type *type,
>   case V4L2_CID_RDS_TX_ALT_FREQS:
>   *type = V4L2_CTRL_TYPE_U32;
>   break;
> + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
> + *type = V4L2_CTRL_TYPE_MPEG2_FRAME_HDR;
> + break;
>   default:
>   *type = V4L2_CTRL_TYPE_INTEGER;
>   break;
> @@ -1472,6 +1476,9 @@ static int std_validate(const struct v4l2_ctrl *ctrl, 
> u32 idx,
>   return -ERANGE;
>   return 0;
>  
> + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> + return 0;
> +
>   default:
>   return -EINVAL;
>   }
> @@ -2046,6 +2053,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct 
> v4l2_ctrl_handler *hdl,
>   case V4L2_CTRL_TYPE_U32:
>   elem_size = sizeof(u32);
>   break;
> + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> + elem_size = sizeof(struct v4l2_ctrl_mpeg2_frame_hdr);
> + break;
>   default:
>   if (type < V4L2_CTRL_COMPOUND_TYPES)
>   elem_size = sizeof(s32);
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 468c3c65362d..8070203da5d2 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1273,6 +1273,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>   case V4L2_PIX_FMT_VC1_ANNEX_L:  descr = "VC-1 (SMPTE 412M Annex 
> L)"; break;
>   case V4L2_PIX_FMT_VP8:  descr = "VP8"; break;
>   case V4L2_PIX_FMT_VP9:  descr = "VP9"; break;
> + case V4L2_PIX_FMT_MPEG2_FRAME:  descr = "MPEG2 Frame"; break;
>   case V4L2_PIX_FMT_CPIA1:descr = "GSPCA CPiA YUV"; break;
>   case V4L2_PIX_FMT_WNVA: descr = "WNVA"; break;
>   case V4L2_PIX_FMT_SN9C10X:  descr = "GSPCA SN9C10X"; break;
> diff --git a/include/uapi/linux/v4l2-controls.h 
> b/include/uapi/linux/v4l2-controls.h
> index cbbb750d87d1..8431b2a540c7 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -557,6 +557,8 @@ enum v4l2_mpeg_video_mpeg4_profile {
>  };
>  #define V4L2_CID_MPEG_VIDEO_MPEG4_QPEL   (V4L2_CID_MPEG_BASE+407)
>  
> +#define V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR (V4L2_CID_MPEG_BASE+450)
> +
>  /*  Control IDs for VP8 streams
>   *  Although VP8 is not part of MPEG we add these controls to the MPEG class
>   *  as that class is already handling other video compression standards
> @@ -985,4 +987,28 @@ enum v4l2_detect_md_mode {
>  #define V4L2_CID_DETECT_MD_THRESHOLD_GRID(V4L2_CID_DETECT_CLASS_BASE + 3)
>  #define V4L2_CID_DETECT_MD_REGION_GRID   
> (V4L2_CID_DETECT_CLASS_BASE + 4)
>  
> +struct v4l2_ctrl_mpeg2_frame_hdr {
> + __u32 slice_len;
> + __u32 slice_pos;
> + enum { MPEG1, MPEG2 } type;
> +
> + __u16 width;
> + __u16 height;
> +
> + enum { PCT_I = 1, PCT_P, PCT_B, PCT_D } picture_coding_type;

As someone else already mentioned (I believe): avoid enums. Use __u16
instead.

> + __u8 f_code[2][2];
> +
> + __u8 intra_dc_precision;
> + __u8 picture_structure;
> + __u8 top_field_first;
> + __u8 frame_pred_frame_dct;
> + __u8 

Re: [PATCH] printk: Ratelimit messages printed by console drivers

[Petr Mladek]

On Fri 2018-04-20 08:04:28, Steven Rostedt wrote:
> On Fri, 20 Apr 2018 11:12:24 +0200
> Petr Mladek  wrote:
> 
> > Yes, my number was arbitrary. The important thing is that it was long
> > enough. Or do you know about an console that will not be able to write
> > 100 lines within one hour?
> 
> The problem is the way rate limit works. If you print 100 lines (or
> 1000) in 5 seconds, then you just stopped printing from that context
> for 59 minutes and 55 seconds. That's a long time to block printing.

Are we talking about the same context?

I am talking about console drivers called from console_unlock(). It is
very special context because it is more or less recursive:

 + could cause infinite loop
 + the errors are usually the same again and again

As a result, if you get too many messages from this context:

 + you are lost (recursion)
 + more messages != new information

And you need to fix the problem anyway. Otherwise, the system
logging is a mess.


> What happens if you had a couple of NMIs go off that takes up that
> time, and then you hit a bug 10 minutes later from that context. You
> just lost it.

I do not understand how this is related to the NMI context.
The messages in NMI context are not throttled!

OK, the original patch throttled also NMI messages when NMI
interrupted console drivers. But it is easy to fix.


> This is a magnitude larger than any other user of rate limit in the
> kernel. The most common time is 5 seconds. The longest I can find is 1
> minute. You are saying you want to block printing from this context for
> 60 minutes!

I see 1 day long limits in dio_warn_stale_pagecache() and
xfs_scrub_experimental_warning().

Note that most ratelimiting is related to a single message. Also it
is in situation where the system should recover within seconds.


> That is HUGE! I don't understand your rational for such a huge number.
> What data do you have to back that up with?

We want to allow seeing the entire lockdep splat (Sergey wants more
than 100 lines). Also it is not that unusual that slow console is busy
several minutes when too many things are happening.

I proposed that long delay because I want to be on the safe side.
Also I do not see a huge benefit in repeating the same messages
too often.

Alternative solution would be to allow first, lets say 250, lines
and then nothing. I mean to change the approach from rate-limiting
to print-once.

Best Regards,
Petr

Re: [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

[Bjorn Helgaas]

[+cc Rajat, Alex because of their interest in the reset/hotplug issue]

For context, Sinan's patch is this:

> diff --git a/drivers/infiniband/hw/hfi1/pcie.c 
> b/drivers/infiniband/hw/hfi1/pcie.c
> index 83d66e8..75f49e3 100644
> --- a/drivers/infiniband/hw/hfi1/pcie.c
> +++ b/drivers/infiniband/hw/hfi1/pcie.c
> @@ -908,7 +908,8 @@ static int trigger_sbr(struct hfi1_devdata *dd)
>  * delay after a reset is required.  Per spec requirements,
>  * the link is either working or not after that point.
>  */
> -   pci_reset_bridge_secondary_bus(dev->bus->self);
> +   if (pci_reset_slot(dev->slot))
> +   pci_reset_bridge_secondary_bus(dev->bus->self);

On Thu, Apr 19, 2018 at 06:19:32PM -0400, Sinan Kaya wrote:
> On 4/19/2018 5:47 PM, Bjorn Helgaas wrote:
> >> Bjorn, would be appropriate to export pci_parent_bus_reset() or some
> >> variation therin??
> > I agree it would be really nice if the PCI core could help out somehow
> > so we could get some of this code out of individual drivers.

What I was really thinking here was about the whole Gen3 transition
thing, not the reset thing by itself.

> I can create a function called pci_reset_link() and move both slot and
> secondary bus reset inside.

What exactly is your patch fixing?  Is it the following?

  If the HFI link is not operating at 8GT/s, the driver's .probe()
  method tries to transition it to 8GT/s, which involves resetting the
  HFI device with pci_reset_bridge_secondary_bus().  If the HFI device
  is in a hotplug slot, the reset causes a "Link Down" event, which
  causes the pciehp driver to remove the HFI device and re-enumerate
  it when the link comes back up.

  When pciehp removes the device, it calls the HFI .remove() method,
  which is a problem because the .probe() method is still active.

  It looks like this should deadlock because __device_attach() holds
  the device_lock while calling .probe() and the
  device_release_driver() path tries to acquire it.

Your patch uses pci_reset_slot(), which connects with Rajat's work
(06a8d89af551 ("PCI: pciehp: Disable link notification across slot
reset")) to avoid hotplug events for intentional resets.

So I think I just reverse-engineered the whole rationale for your
patch :)  Sorry about the long detour.

I'm having a hard time articulating my thoughts here.  I think my
concern is that knowledge about this reset/link down/hotplug issue is
leaking out and we'll end up with different reset interfaces that may
or may not result in hotplug events.  This seems like a confusing API
because it's hard to explain which interface a driver should use.

Bjorn

Re: possible deadlock in blkdev_reread_part

[Tetsuo Handa]

Tetsuo Handa wrote:
> Eric Biggers wrote:
> > It seems that ->bd_mutex is held while opening and closing block devices, 
> > which
> > should rank it above both ->lo_ctl_mutex and loop_index_mutex (see 
> > lo_open() and
> > lo_release()).
> > 
> > But blkdev_reread_part(), which takes ->bd_mutex, is called from some of the
> > ioctls while ->lo_ctl_mutex is held.
> > 
> > Perhaps we should call blkdev_reread_part() at the end of the ioctls, after
> > ->lo_ctl_mutex has been dropped?  But it looks like that can do I/O to the
> > device, which probably could race with loop_clr_fd()...
> > 
> > Or perhaps we should just take both locks for the ioctls, in the order
> > ->bd_mutex, then ->lo_ctl_mutex -- and then use __blkdev_reread_part()?
> 
> But do we really need ->lo_ctl_mutex ? What is the purpose of ->lo_ctl_mutex ?
> If the purpose of ->lo_ctl_mutex is to serialize ioctl() request against each
> loop device when multiple threads opened the same loop device, I feel that
> 
>   There is no need to use ->lo_ctl_mutex which the lockdep will check and
>   complain, provided that ioctl() request cannot recurse into ioctl() request.
>   Instead, we can use simple flag variable whether an ioctl() is in progress.
>  
>   There is no need to use ->lo_ctl_mutex from __lo_release(), for it is
>   guaranteed that there is no in-flight ioctl() request when __lo_release()
>   is called, and loop_index_mutex is blocking further open() requests.
> 
> and simplify like below.
> 
Can we test this patch?

>From 0ca0694b74ca4b02e9d2e3f46c9d960ba167adec Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Fri, 20 Apr 2018 22:54:42 +0900
Subject: [PATCH] block/loop: Serialize ioctl operations.

syzbot is reporting various bugs which involve /dev/loopX.
Two of them

  INFO: rcu detected stall in lo_ioctl
  https://syzkaller.appspot.com/bug?id=7b49fb610af9cca78c24e9f796f2e8b0d5573997

  general protection fault in lo_ioctl (2)
  https://syzkaller.appspot.com/bug?id=f3cfe26e785d85f9ee259f385515291d21bd80a3

suggest that loop module is not thread safe. The former suggests that
l->lo_backing_file is forming circular loop and the latter suggests that
l->lo_backing_file became NULL.

In fact, recursion avoidance check in loop_set_fd() is traversing loop
devices without holding each lo->lo_ctl_mutex lock. lo_state can become
Lo_rundown and lo_backing_file can become NULL if raced with loop_clr_fd().

  /* Avoid recursion */
  f = file;
  while (is_loop_device(f)) {
struct loop_device *l;

if (f->f_mapping->host->i_bdev == bdev)
  goto out_putf;

l = f->f_mapping->host->i_bdev->bd_disk->private_data;
if (l->lo_state == Lo_unbound) {
  error = -EINVAL;
  goto out_putf;
}
f = l->lo_backing_file;
  }

Since ioctl() request on loop devices is not frequent operation, we don't
need fine grained locking. Let's use global lock rather than dancing with
locking order inside this recursion avoidance check.

Strategy is that the global lock is held upon entry of ioctl() request,
and release it before either starting operations which might recurse or
leaving ioctl() request. After the global lock is released, current thread
no longer uses "struct loop_device" memory because it might be modified
by next ioctl() request which was waiting for current ioctl() request.

In order to enforce this strategy, this patch inversed
loop_reread_partitions() and loop_unprepare_queue() in loop_clr_fd().
I don't know whether it breaks something, but I don't have testcases.

Since this patch serializes using global lock, race bugs should no longer
exist. Thus, it will be easy to test whether this patch broke something.

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 

Reported-by: syzbot 
Cc: Jens Axboe 
---
 drivers/block/loop.c | 231 ---
 drivers/block/loop.h |   1 -
 2 files changed, 128 insertions(+), 104 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index c9d0449..59716d1 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -81,11 +81,50 @@
 #include 
 
 static DEFINE_IDR(loop_index_idr);
-static DEFINE_MUTEX(loop_index_mutex);
+static DEFINE_MUTEX(loop_mutex);
+static void *loop_mutex_owner; /* == __mutex_owner(_mutex) */
 
 static int max_part;
 static int part_shift;
 
+/*
+ * lock_loop - Lock loop_mutex.
+ */
+static void lock_loop(void)
+{
+   mutex_lock(_mutex);
+   loop_mutex_owner = current;
+}
+
+/*
+ * lock_loop_killable - Lock loop_mutex unless killed.
+ */
+static int lock_loop_killable(void)
+{
+   int err = mutex_lock_killable(_mutex);
+
+   if (err)
+   return err;
+   loop_mutex_owner = current;
+   return 0;
+}
+
+/*
+ * unlock_loop - Unlock loop_mutex as needed.
+ *
+ * 

Re: [PATCH v2] sched/rt: Rework for_each_process_thread() iterations in tg_has_rt_tasks()

[Juri Lelli]

On 20/04/18 13:06, Kirill Tkhai wrote:
> From: Kirill Tkhai 
> 
> tg_rt_schedulable() iterates over all child task groups,
> while tg_has_rt_tasks() iterates over all linked tasks.
> In case of systems with big number of tasks, this may
> take a lot of time.
> 
> I observed hard LOCKUP on machine with 2+ processes
> after write to "cpu.rt_period_us" of cpu cgroup with
> 39 children. The problem occurred because of tasklist_lock
> is held for a long time and other processes can't do fork().
> 
> PID: 1036268  TASK: 88766c31  CPU: 36  COMMAND: "criu"
>  #0 [887f7f408e48] crash_nmi_callback at 81050601
>  #1 [887f7f408e58] nmi_handle at 816e0cc7
>  #2 [887f7f408eb0] do_nmi at 816e0fb0
>  #3 [887f7f408ef0] end_repeat_nmi at 816e00b9
> [exception RIP: tg_rt_schedulable+463]
> RIP: 810bf49f  RSP: 886537ad7d50  RFLAGS: 0202
> RAX:   RBX: 3b9aca00  RCX: 883e9cb4b1b0
> RDX: 887d0be43608  RSI: 886537ad7dd8  RDI: 8840a6ad
> RBP: 886537ad7d68   R8: 887d0be431b0   R9: 000e7ef0
> R10: 88164fc39400  R11: 00023380  R12: 81ef8d00
> R13: 810bea40  R14:   R15: 8840a6ad
> ORIG_RAX:   CS: 0010  SS: 0018
> ---  ---
>  #4 [886537ad7d50] tg_rt_schedulable at 810bf49f
>  #5 [886537ad7d70] walk_tg_tree_from at 810c6c91
>  #6 [886537ad7dc0] tg_set_rt_bandwidth at 810c6dd0
>  #7 [886537ad7e28] cpu_rt_period_write_uint at 810c6eea
>  #8 [886537ad7e38] cgroup_file_write at 8111cfd3
>  #9 [886537ad7ec8] vfs_write at 8121eced
> #10 [886537ad7f08] sys_write at 8121faff
> #11 [886537ad7f50] system_call_fastpath at 816e8a7d
> 
> The patch reworks tg_has_rt_tasks() and makes it to iterate over
> task group process list instead of iteration over all tasks list.
> This makes the function to scale well, and reduces its execution
> time.
> 
> Note, that since tasklist_lock doesn't protect a task against
> sched_class changing, we don't introduce new races in comparison
> to that we had before.

This seems to be true. However, I wonder why we are OK with current racy
code (against tasks moving between groups). :/

Can't a task join the group while we are iterating and we miss that?

Re: [PATCH] printk: Ratelimit messages printed by console drivers

[Steven Rostedt]

On Fri, 20 Apr 2018 10:17:51 -0400
Steven Rostedt  wrote:

> int git_context(void)

That should have been get_context(void) ;-)

-- Steve

Re: [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

[Sinan Kaya]

On 4/20/2018 10:00 AM, Bjorn Helgaas wrote:
> [+cc Rajat, Alex because of their interest in the reset/hotplug issue]
> 
> For context, Sinan's patch is this:
> 
>> diff --git a/drivers/infiniband/hw/hfi1/pcie.c 
>> b/drivers/infiniband/hw/hfi1/pcie.c
>> index 83d66e8..75f49e3 100644
>> --- a/drivers/infiniband/hw/hfi1/pcie.c
>> +++ b/drivers/infiniband/hw/hfi1/pcie.c
>> @@ -908,7 +908,8 @@ static int trigger_sbr(struct hfi1_devdata *dd)
>>  * delay after a reset is required.  Per spec requirements,
>>  * the link is either working or not after that point.
>>  */
>> -   pci_reset_bridge_secondary_bus(dev->bus->self);
>> +   if (pci_reset_slot(dev->slot))
>> +   pci_reset_bridge_secondary_bus(dev->bus->self);
> 
> On Thu, Apr 19, 2018 at 06:19:32PM -0400, Sinan Kaya wrote:
>> On 4/19/2018 5:47 PM, Bjorn Helgaas wrote:
 Bjorn, would be appropriate to export pci_parent_bus_reset() or some
 variation therin??
>>> I agree it would be really nice if the PCI core could help out somehow
>>> so we could get some of this code out of individual drivers.
> 
> What I was really thinking here was about the whole Gen3 transition
> thing, not the reset thing by itself.
> 
>> I can create a function called pci_reset_link() and move both slot and
>> secondary bus reset inside.
> 
> What exactly is your patch fixing?  Is it the following?
> 
>   If the HFI link is not operating at 8GT/s, the driver's .probe()
>   method tries to transition it to 8GT/s, which involves resetting the
>   HFI device with pci_reset_bridge_secondary_bus().  If the HFI device
>   is in a hotplug slot, the reset causes a "Link Down" event, which
>   causes the pciehp driver to remove the HFI device and re-enumerate
>   it when the link comes back up.
> 
>   When pciehp removes the device, it calls the HFI .remove() method,
>   which is a problem because the .probe() method is still active.
> 
>   It looks like this should deadlock because __device_attach() holds
>   the device_lock while calling .probe() and the
>   device_release_driver() path tries to acquire it.
> 
> Your patch uses pci_reset_slot(), which connects with Rajat's work
> (06a8d89af551 ("PCI: pciehp: Disable link notification across slot
> reset")) to avoid hotplug events for intentional resets.
> 
> So I think I just reverse-engineered the whole rationale for your
> patch :)  Sorry about the long detour.

Yes, you are on track. Basically; for all callers in drivers directory,
I was trying to call hotplug reset as in (1/2) of this patch before
secondary bus reset.

I learnt about this during our DPC+hotplug interaction thread here:

https://patchwork.kernel.org/project/linux-pci/list/?submitter=77241

Existing issues:
https://marc.info/?l=linux-pci=152336615707640=2
https://www.spinics.net/lists/linux-pci/msg70614.html


> 
> I'm having a hard time articulating my thoughts here.  I think my
> concern is that knowledge about this reset/link down/hotplug issue is
> leaking out and we'll end up with different reset interfaces that may
> or may not result in hotplug events.  This seems like a confusing API
> because it's hard to explain which interface a driver should use.

I think we should go ahead and combine slot reset and secondary bus
reset into a single API and hide the other ones (pci_reset_slot() and
pci_reset_bridge_secondary_bus()) from external users. This way,
people don't have to query if system supports hotplug or not like VFIO
does.

Other drivers (AER/IB) not doing this are broken in hotplug systems today.


> 
> Bjorn
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH net] tcp: don't read out-of-bounds opsize

[Eric Dumazet]

On 04/20/2018 06:57 AM, Jann Horn wrote:
> The old code reads the "opsize" variable from out-of-bounds memory (first
> byte behind the segment) if a broken TCP segment ends directly after an
> opcode that is neither EOL nor NOP.
> 
> The result of the read isn't used for anything, so the worst thing that
> could theoretically happen is a pagefault; and since the physmap is usually
> mostly contiguous, even that seems pretty unlikely.
>

No page fault possible, because tcp headers are in skb->head

And we have 'struct skb_shared_info'  at the end of skb->head anyway.

But, yes, reading some extra bytes with random content is possible.

Re: [PATCH v2] KVM: Extend MAX_IRQ_ROUTES to 4096 for all archs

[Cornelia Huck]

On Fri, 20 Apr 2018 21:51:13 +0800
Wanpeng Li  wrote:

> 2018-04-20 15:15 GMT+08:00 Cornelia Huck :
> > On Thu, 19 Apr 2018 17:47:28 -0700
> > Wanpeng Li  wrote:
> >  
> >> From: Wanpeng Li 
> >>
> >> Our virtual machines make use of device assignment by configuring
> >> 12 NVMe disks for high I/O performance. Each NVMe device has 129
> >> MSI-X Table entries:
> >> Capabilities: [50] MSI-X: Enable+ Count=129 Masked-Vector table: BAR=0 
> >> offset=2000
> >> The windows virtual machines fail to boot since they will map the number of
> >> MSI-table entries that the NVMe hardware reported to the bus to msi routing
> >> table, this will exceed the 1024. This patch extends MAX_IRQ_ROUTES to 4096
> >> for all archs, in the future this might be extended again if needed.
> >>
> >> Cc: Paolo Bonzini 
> >> Cc: Radim Krčmář 
> >> Cc: Tonny Lu 
> >> Cc: Cornelia Huck 
> >> Signed-off-by: Wanpeng Li 
> >> Signed-off-by: Tonny Lu 
> >> ---
> >> v1 -> v2:
> >>  * extend MAX_IRQ_ROUTES to 4096 for all archs
> >>
> >>  include/linux/kvm_host.h | 6 --
> >>  1 file changed, 6 deletions(-)
> >>
> >> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> >> index 6930c63..0a5c299 100644
> >> --- a/include/linux/kvm_host.h
> >> +++ b/include/linux/kvm_host.h
> >> @@ -1045,13 +1045,7 @@ static inline int mmu_notifier_retry(struct kvm 
> >> *kvm, unsigned long mmu_seq)
> >>
> >>  #ifdef CONFIG_HAVE_KVM_IRQ_ROUTING
> >>
> >> -#ifdef CONFIG_S390
> >>  #define KVM_MAX_IRQ_ROUTES 4096 //FIXME: we can have more than that...  
> >
> > What about /* might need extension/rework in the future */ instead of
> > the FIXME?  
> 
> Yeah, I guess the maintainers can help to fix it when applying. :)
> 
> >
> > As far as I understand, 4096 should cover most architectures and the
> > sane end of s390 configurations, but will not be enough at the scarier
> > end of s390. (I'm not sure how much it matters in practice.)
> >
> > Do we want to make this a tuneable in the future? Do some kind of
> > dynamic allocation? Not sure whether it is worth the trouble.  
> 
> I think keep as it is currently.

My main question here is how long this is enough... the number of
virtqueues per device is up to 1K from the initial 64, which makes it
possible to hit the 4K limit with fewer virtio devices than before (on
s390, each virtqueue uses a routing table entry). OTOH, we don't want
giant tables everywhere just to accommodate s390.

If the s390 maintainers tell me that nobody is doing the really insane
stuff, I'm happy as well :)

Re: [PATCH v2] sched/rt: Rework for_each_process_thread() iterations in tg_has_rt_tasks()

[Kirill Tkhai]

On 20.04.2018 17:11, Juri Lelli wrote:
> On 20/04/18 13:06, Kirill Tkhai wrote:
>> From: Kirill Tkhai 
>>
>> tg_rt_schedulable() iterates over all child task groups,
>> while tg_has_rt_tasks() iterates over all linked tasks.
>> In case of systems with big number of tasks, this may
>> take a lot of time.
>>
>> I observed hard LOCKUP on machine with 2+ processes
>> after write to "cpu.rt_period_us" of cpu cgroup with
>> 39 children. The problem occurred because of tasklist_lock
>> is held for a long time and other processes can't do fork().
>>
>> PID: 1036268  TASK: 88766c31  CPU: 36  COMMAND: "criu"
>>  #0 [887f7f408e48] crash_nmi_callback at 81050601
>>  #1 [887f7f408e58] nmi_handle at 816e0cc7
>>  #2 [887f7f408eb0] do_nmi at 816e0fb0
>>  #3 [887f7f408ef0] end_repeat_nmi at 816e00b9
>> [exception RIP: tg_rt_schedulable+463]
>> RIP: 810bf49f  RSP: 886537ad7d50  RFLAGS: 0202
>> RAX:   RBX: 3b9aca00  RCX: 883e9cb4b1b0
>> RDX: 887d0be43608  RSI: 886537ad7dd8  RDI: 8840a6ad
>> RBP: 886537ad7d68   R8: 887d0be431b0   R9: 000e7ef0
>> R10: 88164fc39400  R11: 00023380  R12: 81ef8d00
>> R13: 810bea40  R14:   R15: 8840a6ad
>> ORIG_RAX:   CS: 0010  SS: 0018
>> ---  ---
>>  #4 [886537ad7d50] tg_rt_schedulable at 810bf49f
>>  #5 [886537ad7d70] walk_tg_tree_from at 810c6c91
>>  #6 [886537ad7dc0] tg_set_rt_bandwidth at 810c6dd0
>>  #7 [886537ad7e28] cpu_rt_period_write_uint at 810c6eea
>>  #8 [886537ad7e38] cgroup_file_write at 8111cfd3
>>  #9 [886537ad7ec8] vfs_write at 8121eced
>> #10 [886537ad7f08] sys_write at 8121faff
>> #11 [886537ad7f50] system_call_fastpath at 816e8a7d
>>
>> The patch reworks tg_has_rt_tasks() and makes it to iterate over
>> task group process list instead of iteration over all tasks list.
>> This makes the function to scale well, and reduces its execution
>> time.
>>
>> Note, that since tasklist_lock doesn't protect a task against
>> sched_class changing, we don't introduce new races in comparison
>> to that we had before.
> 
> This seems to be true. However, I wonder why we are OK with current racy
> code (against tasks moving between groups). :/
> 
> Can't a task join the group while we are iterating and we miss that?

Yes, it can, but I'm not sure either this should be considered as problem,
seeing the race design we already have. It's not a real protection, this
place is to warn a person, he does something wrong. We check for zero written
there, but really written "1" will invent the same problems.

There are 
cgroup_threadgroup_change_begin(task)/cgroup_threadgroup_change_end(task)
to protect from cgroup change, but it seems we can't use it as they have task 
argument
and aimed to protect single task thread group in the future (despite they take 
global
percpu_rwsem).

Kirill

RE: [PATCH v2] platform/x86: dell-wmi: Ignore new rfkill and fn-lock events

[Mario.Limonciello]

> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Friday, April 20, 2018 2:29 AM
> To: Kai-Heng Feng
> Cc: mj...@srcf.ucam.org; dvh...@infradead.org; a...@infradead.org;
> Limonciello, Mario; platform-driver-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v2] platform/x86: dell-wmi: Ignore new rfkill and fn-lock
> events
> 
> On Friday 20 April 2018 15:26:48 Kai-Heng Feng wrote:
> > There are two new events generated by dell-wmi, rfkill and fn-lock, from
> > Dell Systems.
> >
> > When Fn-lock hotkey gets pressed to switch to function mode:
> > [85951.591542] dell_wmi: Unknown key with type 0x0010 and code 0xe035
> > pressed
> > [85951.591546] dell_wmi: Unknown key with type 0x0010 and code 0x
> > pressed
> >
> > When Fn-lock hotkey gets pressed to switch to multimedia mode:
> > [85956.667686] dell_wmi: Unknown key with type 0x0010 and code 0xe035
> > pressed
> > [85956.667690] dell_wmi: Unknown key with type 0x0010 and code 0x0001
> > pressed
> >
> > When radio hotkey gets pressed:
> > [85974.430220] dell_wmi: Unknown key with type 0x0010 and code 0xe008
> > pressed
> >
> > These events are for notification purpose, so we can ignore them.
> >
> > This patch is tested on XPS 9370.
> >
> > Signed-off-by: Kai-Heng Feng 
> 
> Reviewed-by: Pali Rohár 

Reviewed-by: Mario Limonciello 

> 
> > ---
> > v2: Reorder alphabetically.
> > More detailed changelog.
> >
> >  drivers/platform/x86/dell-wmi.c | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/platform/x86/dell-wmi.c 
> > b/drivers/platform/x86/dell-wmi.c
> > index 8d102195a392..ba8e6725d7ac 100644
> > --- a/drivers/platform/x86/dell-wmi.c
> > +++ b/drivers/platform/x86/dell-wmi.c
> > @@ -261,6 +261,12 @@ static const u16 bios_to_linux_keycode[256] = {
> >   * override them.
> >   */
> >  static const struct key_entry dell_wmi_keymap_type_0010[] = {
> > +   /* Fn-lock switched to function keys */
> > +   { KE_IGNORE, 0x0, { KEY_RESERVED } },
> > +
> > +   /* Fn-lock switched to multimedia keys */
> > +   { KE_IGNORE, 0x1, { KEY_RESERVED } },
> > +
> > /* Mic mute */
> > { KE_KEY, 0x150, { KEY_MICMUTE } },
> >
> > @@ -296,6 +302,14 @@ static const struct key_entry
> dell_wmi_keymap_type_0010[] = {
> > { KE_KEY,0x851, { KEY_PROG2 } },
> > { KE_KEY,0x852, { KEY_PROG3 } },
> >
> > +   /*
> > +* Radio disable (notify only -- there is no model for which the
> > +* WMI event is supposed to trigger an action).
> > +*/
> > +   { KE_IGNORE, 0xe008, { KEY_RFKILL } },
> > +
> > +   /* Fn-lock */
> > +   { KE_IGNORE, 0xe035, { KEY_RESERVED } },
> >  };
> >
> >  /*
> 
> --
> Pali Rohár
> pali.ro...@gmail.com

[PATCH 02/17] perf/core: Store context switch out type in PERF_RECORD_SWITCH[_CPU_WIDE]

[Arnaldo Carvalho de Melo]

From: Alexey Budankov 

Store preempting context switch out event into Perf trace as a part of
PERF_RECORD_SWITCH[_CPU_WIDE] record.

Percentage of preempting and non-preempting context switches help
understanding the nature of workloads (CPU or IO bound) that are running
on a machine;

The event is treated as preemption one when task->state value of the
thread being switched out is TASK_RUNNING. Event type encoding is
implemented using PERF_RECORD_MISC_SWITCH_OUT_PREEMPT bit;

Signed-off-by: Alexey Budankov 
Acked-by: Peter Zijlstra 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: 
http://lkml.kernel.org/r/9ff84e83-a0ca-dd82-a6d0-cb951689b...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 include/uapi/linux/perf_event.h   | 18 +++---
 kernel/events/core.c  |  4 
 tools/include/uapi/linux/perf_event.h | 18 +++---
 3 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 912b85b52344..b8e288a1f740 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -650,11 +650,23 @@ struct perf_event_mmap_page {
 #define PERF_RECORD_MISC_COMM_EXEC (1 << 13)
 #define PERF_RECORD_MISC_SWITCH_OUT(1 << 13)
 /*
- * Indicates that the content of PERF_SAMPLE_IP points to
- * the actual instruction that triggered the event. See also
- * perf_event_attr::precise_ip.
+ * These PERF_RECORD_MISC_* flags below are safely reused
+ * for the following events:
+ *
+ *   PERF_RECORD_MISC_EXACT_IP   - PERF_RECORD_SAMPLE of precise events
+ *   PERF_RECORD_MISC_SWITCH_OUT_PREEMPT - PERF_RECORD_SWITCH* events
+ *
+ *
+ * PERF_RECORD_MISC_EXACT_IP:
+ *   Indicates that the content of PERF_SAMPLE_IP points to
+ *   the actual instruction that triggered the event. See also
+ *   perf_event_attr::precise_ip.
+ *
+ * PERF_RECORD_MISC_SWITCH_OUT_PREEMPT:
+ *   Indicates that thread was preempted in TASK_RUNNING state.
  */
 #define PERF_RECORD_MISC_EXACT_IP  (1 << 14)
+#define PERF_RECORD_MISC_SWITCH_OUT_PREEMPT(1 << 14)
 /*
  * Reserve the last bit to indicate some extended misc field
  */
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 2d5fe26551f8..1bae80aaabfb 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7587,6 +7587,10 @@ static void perf_event_switch(struct task_struct *task,
},
};
 
+   if (!sched_in && task->state == TASK_RUNNING)
+   switch_event.event_id.header.misc |=
+   PERF_RECORD_MISC_SWITCH_OUT_PREEMPT;
+
perf_iterate_sb(perf_event_switch_output,
   _event,
   NULL);
diff --git a/tools/include/uapi/linux/perf_event.h 
b/tools/include/uapi/linux/perf_event.h
index 912b85b52344..b8e288a1f740 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -650,11 +650,23 @@ struct perf_event_mmap_page {
 #define PERF_RECORD_MISC_COMM_EXEC (1 << 13)
 #define PERF_RECORD_MISC_SWITCH_OUT(1 << 13)
 /*
- * Indicates that the content of PERF_SAMPLE_IP points to
- * the actual instruction that triggered the event. See also
- * perf_event_attr::precise_ip.
+ * These PERF_RECORD_MISC_* flags below are safely reused
+ * for the following events:
+ *
+ *   PERF_RECORD_MISC_EXACT_IP   - PERF_RECORD_SAMPLE of precise events
+ *   PERF_RECORD_MISC_SWITCH_OUT_PREEMPT - PERF_RECORD_SWITCH* events
+ *
+ *
+ * PERF_RECORD_MISC_EXACT_IP:
+ *   Indicates that the content of PERF_SAMPLE_IP points to
+ *   the actual instruction that triggered the event. See also
+ *   perf_event_attr::precise_ip.
+ *
+ * PERF_RECORD_MISC_SWITCH_OUT_PREEMPT:
+ *   Indicates that thread was preempted in TASK_RUNNING state.
  */
 #define PERF_RECORD_MISC_EXACT_IP  (1 << 14)
+#define PERF_RECORD_MISC_SWITCH_OUT_PREEMPT(1 << 14)
 /*
  * Reserve the last bit to indicate some extended misc field
  */
-- 
2.14.3

Re: [PATCH v2] tracing: fix bad use of igrab in trace_uprobe.c

[Miklos Szeredi]

On Thu, Apr 19, 2018 at 6:37 PM, Song Liu  wrote:
>
>
>> On Apr 19, 2018, at 7:44 AM, Miklos Szeredi  wrote:
>>
>> On Thu, Apr 19, 2018 at 10:58 AM, Miklos Szeredi  wrote:
>>> On Wed, Apr 18, 2018 at 7:40 PM, Song Liu  wrote:

*arg++ = '\0';
filename = argv[1];
ret = kern_path(filename, LOOKUP_FOLLOW, );
if (ret)
 -   goto fail_address_parse;
 -
 -   inode = igrab(d_real_inode(path.dentry));
>>
>> Also, where has the d_real_inode() gone?
>>
>> Looks like we need tu->inode back, since the return value of
>> d_real_inode() may change over time.   I'd do the "tu->inode =
>> d_real_inode(tu->path.dentry)" just before first use (i.e. when
>> enabling the tracepoint).
>>

>
> Do we need mechanism to prevent the return value of d_real_inode()
> to change? Would the following sequence happen?
>
> create trace_uprobe
> enable trace_uprobe (uprobe_register)
> d_real changes
> disable trace_uprobe (uprobe_unregister get wrong inode?)

Yes.

>
> Another case might be:
>
> create trace_uprobe
> enable trace_uprobe (uprobe_register)
> disable trace_uprobe (uprobe_unregister)
> d_real changes
> enable trace_uprobe (do we need new inode for uprobe_register)

Probably a good idea to use the new one, but doesn't really matter.
Do the one that's simpler.

This corner case is simply not interesting (modifying a binary while
it is being debugged with uprobe).  Let's just concentrate on making
this crash and leak free.

Thanks,
Miklos

[PATCH 13/17] perf record: Remove suggestion to enable APIC

[Arnaldo Carvalho de Melo]

From: Andi Kleen 

'perf record' suggests to enable the APIC on errors.

APIC is practically always used today and the problem is usually
somewhere else.

Just remove the outdated suggestion.

Signed-off-by: Andi Kleen 
Acked-by: Jiri Olsa 
Link: http://lkml.kernel.org/r/20180406203812.3087-5-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evsel.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 66b62570c855..3e87486c28fe 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -2870,8 +2870,7 @@ int perf_evsel__open_strerror(struct perf_evsel *evsel, 
struct target *target,
 #if defined(__i386__) || defined(__x86_64__)
if (evsel->attr.type == PERF_TYPE_HARDWARE)
return scnprintf(msg, size, "%s",
-   "No hardware sampling interrupt available.\n"
-   "No APIC? If so then you can boot the kernel with the \"lapic\" boot 
parameter to force-enable it.");
+   "No hardware sampling interrupt available.\n");
 #endif
break;
case EBUSY:
-- 
2.14.3

[PATCH 14/17] perf tools: Add '\n' at the end of parse-options error messages

[Arnaldo Carvalho de Melo]

From: Ravi Bangoria 

Few error messages does not have '\n' at the end and thus next prompt
gets printed in the same line. Ex,

  linux~$ perf buildid-cache -verbose --add ./a.out
   Error: did you mean `--verbose` (with two dashes ?)linux~$

Fix it.

Signed-off-by: Ravi Bangoria 
Reviewed-by: Masami Hiramatsu 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Kate Stewart 
Cc: Krister Johansen 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Philippe Ombredanne 
Cc: Sihyeon Jang 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/20180417041346.5617-2-ravi.bango...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/subcmd/parse-options.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/lib/subcmd/parse-options.c b/tools/lib/subcmd/parse-options.c
index f6a1babcbac4..cb7154eccbdc 100644
--- a/tools/lib/subcmd/parse-options.c
+++ b/tools/lib/subcmd/parse-options.c
@@ -433,7 +433,7 @@ static int parse_long_opt(struct parse_opt_ctx_t *p, const 
char *arg,
 
if (ambiguous_option) {
 fprintf(stderr,
-" Error: Ambiguous option: %s (could be --%s%s or 
--%s%s)",
+" Error: Ambiguous option: %s (could be --%s%s or 
--%s%s)\n",
 arg,
 (ambiguous_flags & OPT_UNSET) ?  "no-" : "",
 ambiguous_option->long_name,
@@ -458,7 +458,7 @@ static void check_typos(const char *arg, const struct 
option *options)
return;
 
if (strstarts(arg, "no-")) {
-   fprintf(stderr, " Error: did you mean `--%s` (with two dashes 
?)", arg);
+   fprintf(stderr, " Error: did you mean `--%s` (with two dashes 
?)\n", arg);
exit(129);
}
 
@@ -466,7 +466,7 @@ static void check_typos(const char *arg, const struct 
option *options)
if (!options->long_name)
continue;
if (strstarts(options->long_name, arg)) {
-   fprintf(stderr, " Error: did you mean `--%s` (with two 
dashes ?)", arg);
+   fprintf(stderr, " Error: did you mean `--%s` (with two 
dashes ?)\n", arg);
exit(129);
}
}
-- 
2.14.3

[PATCH 12/17] perf record: Remove misleading error suggestion

[Arnaldo Carvalho de Melo]

From: Andi Kleen 

When perf record encounters an error setting up an event it suggests
to enable CONFIG_PERF_EVENTS. This is misleading because:

- Usually it is enabled (it is really hard to disable on x86)

- The problem is usually somewhere else, e.g. the CPU is not supported
or an invalid configuration has been used.

Remove the misleading suggestion.

Signed-off-by: Andi Kleen 
Acked-by: Jiri Olsa 
Link: http://lkml.kernel.org/r/20180406203812.3087-4-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evsel.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 1ac8d9236efd..66b62570c855 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -2894,8 +2894,7 @@ int perf_evsel__open_strerror(struct perf_evsel *evsel, 
struct target *target,
 
return scnprintf(msg, size,
"The sys_perf_event_open() syscall returned with %d (%s) for event 
(%s).\n"
-   "/bin/dmesg may provide additional information.\n"
-   "No CONFIG_PERF_EVENTS=y kernel support configured?",
+   "/bin/dmesg | grep -i perf may provide additional information.\n",
 err, str_error_r(err, sbuf, sizeof(sbuf)),
 perf_evsel__name(evsel));
 }
-- 
2.14.3

[PATCH 04/17] perf script: Extend misc field decoding with switch out event type

[Arnaldo Carvalho de Melo]

From: Alexey Budankov 

Append 'p' sign to 'S' tag designating the type of context switch out event so
'Sp' means preemption context switch. Documentation is extended to cover
new presentation changes.

  $ perf script --show-switch-events -F +misc -I -i perf.data:

  hdparm 4073 [004] U  762.198265: 380194 cycles:ppp:  
7faf727f5a23 strchr (/usr/lib64/ld-2.26.so)
  hdparm 4073 [004] K  762.198366: 441572 cycles:ppp:  
b9218435 alloc_set_pte (/lib/modules/4.16.0-rc6+/build/vmlinux)
  hdparm 4073 [004] S  762.198391: PERF_RECORD_SWITCH_CPU_WIDE OUT  
next pid/tid:0/0
 swapper0 [004]762.198392: PERF_RECORD_SWITCH_CPU_WIDE IN   
prev pid/tid: 4073/4073
 swapper0 [004] Sp 762.198477: PERF_RECORD_SWITCH_CPU_WIDE OUT 
preempt  next pid/tid: 4073/4073
  hdparm 4073 [004]762.198478: PERF_RECORD_SWITCH_CPU_WIDE IN   
prev pid/tid:0/0
 swapper0 [007] K  762.198514:2303073 cycles:ppp:  
b98b0c66 intel_idle (/lib/modules/4.16.0-rc6+/build/vmlinux)
 swapper0 [007] Sp 762.198561: PERF_RECORD_SWITCH_CPU_WIDE OUT 
preempt  next pid/tid: 1134/1134
  kworker/u16:18 1134 [007]762.198562: PERF_RECORD_SWITCH_CPU_WIDE IN   
prev pid/tid:0/0
  kworker/u16:18 1134 [007] S  762.198567: PERF_RECORD_SWITCH_CPU_WIDE OUT  
next pid/tid:0/0

Signed-off-by: Alexey Budankov 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/5fc65ce7-8ca5-53ae-8858-8ddd27290...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-script.txt | 17 +
 tools/perf/builtin-script.c  |  5 -
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/tools/perf/Documentation/perf-script.txt 
b/tools/perf/Documentation/perf-script.txt
index 36ec0257f8d3..afdafe2110a1 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -228,14 +228,15 @@ OPTIONS
For sample events it's possible to display misc field with -F +misc 
option,
following letters are displayed for each bit:
 
- PERF_RECORD_MISC_KERNELK
- PERF_RECORD_MISC_USER  U
- PERF_RECORD_MISC_HYPERVISORH
- PERF_RECORD_MISC_GUEST_KERNEL  G
- PERF_RECORD_MISC_GUEST_USERg
- PERF_RECORD_MISC_MMAP_DATA*M
- PERF_RECORD_MISC_COMM_EXEC E
- PERF_RECORD_MISC_SWITCH_OUTS
+ PERF_RECORD_MISC_KERNEL   K
+ PERF_RECORD_MISC_USER U
+ PERF_RECORD_MISC_HYPERVISOR   H
+ PERF_RECORD_MISC_GUEST_KERNEL G
+ PERF_RECORD_MISC_GUEST_USER   g
+ PERF_RECORD_MISC_MMAP_DATA*   M
+ PERF_RECORD_MISC_COMM_EXECE
+ PERF_RECORD_MISC_SWITCH_OUT   S
+ PERF_RECORD_MISC_SWITCH_OUT_PREEMPT   Sp
 
  $ perf script -F +misc ...
   sched-messaging  1414 K 28690.636582:   4590 cycles ...
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index b17edbcd98cc..e0a9845b6cbc 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -657,8 +657,11 @@ static int perf_sample__fprintf_start(struct perf_sample 
*sample,
break;
case PERF_RECORD_SWITCH:
case PERF_RECORD_SWITCH_CPU_WIDE:
-   if (has(SWITCH_OUT))
+   if (has(SWITCH_OUT)) {
ret += fprintf(fp, "S");
+   if (sample->misc & 
PERF_RECORD_MISC_SWITCH_OUT_PREEMPT)
+   ret += fprintf(fp, "p");
+   }
default:
break;
}
-- 
2.14.3

[PATCH 05/17] perf list: Add s390 support for detailed/verbose PMU event description

[Arnaldo Carvalho de Melo]

From: Thomas Richter 

'perf list' with flags -d and -v print a description (-d) or a very
verbose explanation (-v) of CPU specific counter events.  These
descriptions are provided with the json files in directory
pmu-events/arch/s390/*.json.

Display of these descriptions on s390 requires the corresponding json
files.

On s390 this does not work because function is_pmu_core() does not
detect the s390 directory name where the CPU specific events are listed.
On x86 it is:

  /sys/bus/event_source/devices/cpu

whereas on s390 it is:

  /sys/bus/event_source/devices/cpum_cf
  /sys/bus/event_source/devices/cpum_sf

Fix this by adding s390 directory name testing to function
is_pmu_core(). This is the same approach as taken for the ARM platform.

Output before:

[root@s35lp76 perf]# ./perf list -d pmu
List of pre-defined events (to be used in -e):

  cpum_cf/AES_BLOCKED_CYCLES/  [Kernel PMU event]
  cpum_cf/AES_BLOCKED_FUNCTIONS/   [Kernel PMU event]
  cpum_cf/AES_CYCLES/  [Kernel PMU event]
  cpum_cf/AES_FUNCTIONS/   [Kernel PMU event]
  
  cpum_cf/TX_NC_TEND/  [Kernel PMU event]
  cpum_cf/VX_BCD_EXECUTION_SLOTS/  [Kernel PMU event]
  cpum_sf/SF_CYCLES_BASIC/ [Kernel PMU event]

Output after:

[root@s35lp76 perf]# ./perf list -d pmu
List of pre-defined events (to be used in -e):

  cpum_cf/AES_BLOCKED_CYCLES/  [Kernel PMU event]
  cpum_cf/AES_BLOCKED_FUNCTIONS/   [Kernel PMU event]
  cpum_cf/AES_CYCLES/  [Kernel PMU event]
  cpum_cf/AES_FUNCTIONS/   [Kernel PMU event]
  
  cpum_cf/TX_NC_TEND/  [Kernel PMU event]
  cpum_cf/VX_BCD_EXECUTION_SLOTS/  [Kernel PMU event]
  cpum_sf/SF_CYCLES_BASIC/ [Kernel PMU event]

3906:
  bcd_dfp_execution_slots
   [BCD DFP Execution Slots]
  decimal_instructions
   [Decimal Instructions]
  dtlb2_gpage_writes
   [DTLB2 GPAGE Writes]
  dtlb2_hpage_writes
   [DTLB2 HPAGE Writes]
  dtlb2_misses
   [DTLB2 Misses]
  dtlb2_writes
   [DTLB2 Writes]
  itlb2_misses
   [ITLB2 Misses]
  itlb2_writes
   [ITLB2 Writes]
  l1c_tlb2_misses
   [L1C TLB2 Misses]
  .

cfvn 3:
  cpu_cycles
   [CPU Cycles]
  instructions
   [Instructions]
  l1d_dir_writes
   [L1D Directory Writes]
  l1d_penalty_cycles
   [L1D Penalty Cycles]
  l1i_dir_writes
   [L1I Directory Writes]
  l1i_penalty_cycles
   [L1I Penalty Cycles]
  problem_state_cpu_cycles
   [Problem State CPU Cycles]
  problem_state_instructions
   [Problem State Instructions]
  

csvn generic:
  aes_blocked_cycles
   [AES Blocked Cycles]
  aes_blocked_functions
   [AES Blocked Functions]
  aes_cycles
   [AES Cycles]
  aes_functions
   [AES Functions]
  dea_blocked_cycles
   [DEA Blocked Cycles]
  dea_blocked_functions
   [DEA Blocked Functions]
  

Signed-off-by: Thomas Richter 
Reviewed-by: Hendrik Brueckner 
Acked-by: Mark Rutland 
Cc: Heiko Carstens 
Cc: Martin Schwidefsky 
Link: http://lkml.kernel.org/r/20180416132314.33249-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/pmu.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 064bdcb7bd78..61a5e5027338 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -562,6 +562,12 @@ static int is_pmu_core(const char *name)
if (stat(path, ) == 0)
return 1;
 
+   /* Look for cpu sysfs (specific to s390) */
+   scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/%s",
+ sysfs, name);
+   if (stat(path, ) == 0 && !strncmp(name, "cpum_", 5))
+   return 1;
+
return 0;
 }
 
-- 
2.14.3

[PATCH 06/17] perf: Return proper values for user stack errors

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Return immediately when we find issue in the user stack checks. The
error value could get overwritten by following check for
PERF_SAMPLE_REGS_INTR.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: H. Peter Anvin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: syzkaller-b...@googlegroups.com
Cc: x...@kernel.org
Fixes: 60e2364e60e8 ("perf: Add ability to sample machine state on interrupt")
Link: http://lkml.kernel.org/r/20180415092352.12403-1-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 kernel/events/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 1bae80aaabfb..67612ce359ad 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -10209,9 +10209,9 @@ static int perf_copy_attr(struct perf_event_attr __user 
*uattr,
 * __u16 sample size limit.
 */
if (attr->sample_stack_user >= USHRT_MAX)
-   ret = -EINVAL;
+   return -EINVAL;
else if (!IS_ALIGNED(attr->sample_stack_user, sizeof(u64)))
-   ret = -EINVAL;
+   return -EINVAL;
}
 
if (!attr->sample_max_stack)
-- 
2.14.3

Re: [PATCH] [net] ipv6: sr: fix NULL pointer dereference in seg6_do_srh_encap()- v4 pkts

[David Lebrun]

On 04/20/2018 02:58 PM, Ahmed Abdelsalam wrote:

In case of seg6 in encap mode, seg6_do_srh_encap() calls set_tun_src()
in order to set the src addr of outer IPv6 header.

The net_device is required for set_tun_src(). However calling ip6_dst_idev()
on dst_entry in case of IPv4 traffic results on the following bug.

Using just dst->dev should fix this BUG.



Good catch, thanks for spotting this. If you actually tested your fix 
with IPv4 and IPv6 traffic, you should mention it in the commit message. 
Your current formulation suggests that you just guessed a fix without 
testing.




Fixes: 8936ef7604c11 ipv6: sr: fix NULL pointer dereference when setting encap 
source address
Signed-off-by: Ahmed Abdelsalam


Acked-by: David Lebrun 

Re: [PATCH] x86: ipc: fix x32 version of shmid64_ds and msqid64_ds

[Arnd Bergmann]

On Fri, Apr 20, 2018 at 3:53 PM, Jeffrey Walton  wrote:
>> +#if !defined(__x86_64__) || !defined(__ilp32__)
>>  #include 
>> +#else
>
> I understand there's some progress having Clang compile the kernel.
> Clang treats __ILP32__ and friends differently than GCC. I believe
> ILP32 shows up just about everywhere there are 32-bit ints, longs and
> pointers. You might find it on Aarch64 or you might find it on MIPS64
> when using Clang.
>
> I think that means this may be a little suspicious:
>
> > +#if !defined(__x86_64__) || !defined(__ilp32__)
>
> I kind of felt LLVM was wandering away from the x32 ABI, but the LLVM
> devs insisted they were within their purview. Also see
> https://lists.llvm.org/pipermail/cfe-dev/2015-December/046300.html.
>
> Sorry about the top-post. I just wanted to pick out that one piece.

It seems I made a typo and it needs to be __ILP32__ rather than
__ilp32__ (corrected that locally, will resend once we have resolved
this).

Aside from that, the #if check seems to be correct to me: this
is an x86-specific header, so it won't ever be seen on other
architectures. On x86-32, __x86_64__ isn't set, so we don't care
about whether __ilp32__ is set or not, and on x86-64 (lp64),
__ilp32__ is never set, so we still get the asm-generic header.

  Arnd

Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays

[Daniel Stone]

Hi Tony!

On 20 April 2018 at 15:25, Tony Lindgren  wrote:
> * Daniel Stone  [180420 10:21]:
>> On 20 April 2018 at 08:09, Tomi Valkeinen  wrote:
>> > It's actually not quite clear to me how manual update displays work with
>> > DRM...
>> >
>> > As far as I see, we have essentially two cases: 1) single buffering,
>> > where the userspace must set an area in the fb dirty, which then
>> > triggers the update, 2) multi buffering, which doesn't need fb dirty,
>> > but just a page flip which triggers the update.
>> >
>> > In the 2) case (which I think is the optimal case which all the modern
>> > apps should use), there's no need for delayed work or any work, and the
>> > code flow should be very similar to the auto-update model.
>>
>> Correct. There's been talk (and I think patches?) of adding a
>> per-plane dirty property, so userspace can as an optimisation inform
>> the kernel of the area changed between frames. But short of that, a
>> pageflip needs to trigger a full-plane update, with no dirtyfb
>> required.
>
> For per-plane dirty property patches, which ones do you refer to?

Here's the latest iteration of that series:
https://lists.freedesktop.org/archives/dri-devel/2018-April/171900.html
<1522885748-67122-1-git-send-email-dra...@vmware.com>

> Then for xorg, there's my second attempt on fixing the command mode
> rotation at [0]. Not sure if that's enough for a fix?
>
> It seems not very efficient to me and I don't really know where
> the the per crtc dirty flag should be stored..

I try to deny all knowledge of X11 these days, I'm afraid.

Cheers,
Daniel

RE: [PATCH] platform/x86: dell-smbios: Match on www.dell.com in OEM strings too

[Mario.Limonciello]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Thursday, April 19, 2018 6:43 PM
> To: Limonciello, Mario
> Cc: Andy Shevchenko; LKML; platform-driver-...@vger.kernel.org
> Subject: Re: [PATCH] platform/x86: dell-smbios: Match on www.dell.com in OEM
> strings too
> 
> On Tue, Apr 17, 2018 at 02:45:56PM -0500, Mario Limonciello wrote:
> > Sergey reported that some much older Dell systems don't support
> > the OEM string "Dell System" but instead supported www.dell.com
> > in OEM strings.
> >
> > Match both of these to indicate that this driver is running on
> > a Dell system.
> >
> > Reported-by: Sergey Kubushyn 
> > Signed-off-by: Mario Limonciello 
> > Tested-by: Sergey Kubushyn 
> > ---
> >  drivers/platform/x86/dell-smbios-base.c | 10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/platform/x86/dell-smbios-base.c 
> > b/drivers/platform/x86/dell-
> smbios-base.c
> > index 2485c80..fbd6557 100644
> > --- a/drivers/platform/x86/dell-smbios-base.c
> > +++ b/drivers/platform/x86/dell-smbios-base.c
> > @@ -555,11 +555,15 @@ static void free_group(struct platform_device *pdev)
> >
> >  static int __init dell_smbios_init(void)
> >  {
> > -   const struct dmi_device *valid;
> > +   const struct dmi_device *valid_dell_system;
> > +   const struct dmi_device *valid_www;
> > int ret, wmi, smm;
> >
> > -   valid = dmi_find_device(DMI_DEV_TYPE_OEM_STRING, "Dell System",
> NULL);
> > -   if (!valid) {
> > +   valid_dell_system =
> > +   dmi_find_device(DMI_DEV_TYPE_OEM_STRING, "Dell System",
> NULL);
> > +   valid_www =
> > +   dmi_find_device(DMI_DEV_TYPE_OEM_STRING, "www.dell.com",
> NULL);
> > +   if (!valid_dell_system && !valid_www) {
> > pr_err("Unable to run on non-Dell system\n");
> > return -ENODEV;
> > }
> 
> Hrm, rather than introduce another variable that we don't use and always 
> perform
> both tests, when most of the time we only need to do the first, how about
> something like:
> 

Darren,

That looks good to me, thanks!

> 
> From 2cb5959dadec769167350a9bcb1d212a02b17af8 Mon Sep 17 00:00:00 2001
> Message-Id:
> <2cb5959dadec769167350a9bcb1d212a02b17af8.1524181265.git.dvhart@infrad
> ead.org>
> From: Mario Limonciello 
> Date: Tue, 17 Apr 2018 14:45:56 -0500
> Subject: [PATCH] platform/x86: dell-smbios: Match on www.dell.com in OEM
>  strings too
> 
> Sergey reported that some much older Dell systems don't support
> the OEM string "Dell System" but instead supported www.dell.com
> in OEM strings.
> 
> Match both of these to indicate that this driver is running on
> a Dell system.
> 
> Reported-by: Sergey Kubushyn 
> Tested-by: Sergey Kubushyn 
> Signed-off-by: Mario Limonciello 
> [dvhart: Simplify DMI logic and eliminate unnecessary variables]
> Signed-off-by: Darren Hart (VMware) 
> ---
>  drivers/platform/x86/dell-smbios-base.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/platform/x86/dell-smbios-base.c 
> b/drivers/platform/x86/dell-
> smbios-base.c
> index 33fb2a20458a..9dc282ed5a9e 100644
> --- a/drivers/platform/x86/dell-smbios-base.c
> +++ b/drivers/platform/x86/dell-smbios-base.c
> @@ -555,11 +555,10 @@ static void free_group(struct platform_device *pdev)
> 
>  static int __init dell_smbios_init(void)
>  {
> - const struct dmi_device *valid;
>   int ret, wmi, smm;
> 
> - valid = dmi_find_device(DMI_DEV_TYPE_OEM_STRING, "Dell System",
> NULL);
> - if (!valid) {
> + if (!dmi_find_device(DMI_DEV_TYPE_OEM_STRING, "Dell System", NULL)
> &&
> + !dmi_find_device(DMI_DEV_TYPE_OEM_STRING, "www.dell.com",
> NULL)) {
>   pr_err("Unable to run on non-Dell system\n");
>   return -ENODEV;
>   }
> --
> 2.14.3
> 
> 
> --
> Darren Hart
> VMware Open Source Technology Center

[REVIEW][PATCH 10/22] signal/nios2: Use force_sig_fault where appropriate

[Eric W. Biederman]

Filling in struct siginfo before calling force_sig_info a tedious and
error prone process, where once in a great while the wrong fields
are filled out, and siginfo has been inconsistently cleared.

Simplify this process by using the helper force_sig_fault.  Which
takes as a parameters all of the information it needs, ensures
all of the fiddly bits of filling in struct siginfo are done properly
and then calls force_sig_info.

In short about a 5 line reduction in code for every time force_sig_info
is called, which makes the calling function clearer.

Cc: Ley Foon Tan 
Cc: nios2-...@lists.rocketboards.org
Signed-off-by: "Eric W. Biederman" 
---
 arch/nios2/kernel/traps.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/nios2/kernel/traps.c b/arch/nios2/kernel/traps.c
index a69861d3e1a3..3bc3cd22b750 100644
--- a/arch/nios2/kernel/traps.c
+++ b/arch/nios2/kernel/traps.c
@@ -26,14 +26,7 @@ static DEFINE_SPINLOCK(die_lock);
 
 static void _send_sig(int signo, int code, unsigned long addr)
 {
-   siginfo_t info;
-
-   clear_siginfo();
-   info.si_signo = signo;
-   info.si_errno = 0;
-   info.si_code = code;
-   info.si_addr = (void __user *) addr;
-   force_sig_info(signo, , current);
+   force_sig_fault(signo, code, (void __user *) addr, current);
 }
 
 void die(const char *str, struct pt_regs *regs, long err)
-- 
2.14.1

[REVIEW][PATCH 09/22] signal/nds32: Use force_sig_fault where appropriate

[Eric W. Biederman]

Filling in struct siginfo before calling force_sig_info a tedious and
error prone process, where once in a great while the wrong fields
are filled out, and siginfo has been inconsistently cleared.

Simplify this process by using the helper force_sig_fault.  Which
takes as a parameters all of the information it needs, ensures
all of the fiddly bits of filling in struct siginfo are done properly
and then calls force_sig_info.

In short about a 5 line reduction in code for every time force_sig_info
is called, which makes the calling function clearer.

Cc: Greentime Hu 
Cc: Vincent Chen 
Signed-off-by: "Eric W. Biederman" 
---
 arch/nds32/kernel/traps.c | 20 
 arch/nds32/mm/fault.c | 19 +--
 2 files changed, 9 insertions(+), 30 deletions(-)

diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index 46911768f4b5..636d1c7aa895 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -222,20 +222,13 @@ void die_if_kernel(const char *str, struct pt_regs *regs, 
int err)
 
 int bad_syscall(int n, struct pt_regs *regs)
 {
-   siginfo_t info;
-
if (current->personality != PER_LINUX) {
send_sig(SIGSEGV, current, 1);
return regs->uregs[0];
}
 
-   clear_siginfo();
-   info.si_signo = SIGILL;
-   info.si_errno = 0;
-   info.si_code = ILL_ILLTRP;
-   info.si_addr = (void __user *)instruction_pointer(regs) - 4;
-
-   force_sig_info(SIGILL, , current);
+   force_sig_fault(SIGILL, ILL_ILLTRP,
+   (void __user *)instruction_pointer(regs) - 4, current);
die_if_kernel("Oops - bad syscall", regs, n);
return regs->uregs[0];
 }
@@ -288,16 +281,11 @@ void __init early_trap_init(void)
 void send_sigtrap(struct task_struct *tsk, struct pt_regs *regs,
  int error_code, int si_code)
 {
-   struct siginfo info;
-
tsk->thread.trap_no = ENTRY_DEBUG_RELATED;
tsk->thread.error_code = error_code;
 
-   clear_siginfo();
-   info.si_signo = SIGTRAP;
-   info.si_code = si_code;
-   info.si_addr = (void __user *)instruction_pointer(regs);
-   force_sig_info(SIGTRAP, , tsk);
+   force_sig_fault(SIGTRAP, si_code
+   (void __user *)instruction_pointer(regs), tsk);
 }
 
 void do_debug_trap(unsigned long entry, unsigned long addr,
diff --git a/arch/nds32/mm/fault.c b/arch/nds32/mm/fault.c
index 876ee01ff80a..9bdb7c3ecbb6 100644
--- a/arch/nds32/mm/fault.c
+++ b/arch/nds32/mm/fault.c
@@ -72,16 +72,15 @@ void do_page_fault(unsigned long entry, unsigned long addr,
struct task_struct *tsk;
struct mm_struct *mm;
struct vm_area_struct *vma;
-   siginfo_t info;
+   int si_code;
int fault;
unsigned int mask = VM_READ | VM_WRITE | VM_EXEC;
unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
 
-   clear_siginfo();
error_code = error_code & (ITYPE_mskINST | ITYPE_mskETYPE);
tsk = current;
mm = tsk->mm;
-   info.si_code = SEGV_MAPERR;
+   si_code = SEGV_MAPERR;
/*
 * We fault-in kernel-space virtual memory on-demand. The
 * 'reference' page table is init_mm.pgd.
@@ -162,7 +161,7 @@ void do_page_fault(unsigned long entry, unsigned long addr,
 */
 
 good_area:
-   info.si_code = SEGV_ACCERR;
+   si_code = SEGV_ACCERR;
 
/* first do some preliminary protection checks */
if (entry == ENTRY_PTE_NOT_PRESENT) {
@@ -267,11 +266,7 @@ void do_page_fault(unsigned long entry, unsigned long addr,
tsk->thread.address = addr;
tsk->thread.error_code = error_code;
tsk->thread.trap_no = entry;
-   info.si_signo = SIGSEGV;
-   info.si_errno = 0;
-   /* info.si_code has been set above */
-   info.si_addr = (void *)addr;
-   force_sig_info(SIGSEGV, , tsk);
+   force_sig_fault(SIGSEGV, si_code, (void __user *)addr, tsk);
return;
}
 
@@ -340,11 +335,7 @@ void do_page_fault(unsigned long entry, unsigned long addr,
tsk->thread.address = addr;
tsk->thread.error_code = error_code;
tsk->thread.trap_no = entry;
-   info.si_signo = SIGBUS;
-   info.si_errno = 0;
-   info.si_code = BUS_ADRERR;
-   info.si_addr = (void *)addr;
-   force_sig_info(SIGBUS, , tsk);
+   force_sig_fault(SIGBUS, BUS_ADRERR, (void __user *)addr, tsk);
 
return;
 
-- 
2.14.1

[REVIEW][PATCH 08/22] signal/mips: Use force_sig_fault where appropriate

[Eric W. Biederman]

Filling in struct siginfo before calling force_sig_info a tedious and
error prone process, where once in a great while the wrong fields
are filled out, and siginfo has been inconsistently cleared.

Simplify this process by using the helper force_sig_fault.  Which
takes as a parameters all of the information it needs, ensures
all of the fiddly bits of filling in struct siginfo are done properly
and then calls force_sig_info.

In short about a 5 line reduction in code for every time force_sig_info
is called, which makes the calling function clearer.

Cc: Ralf Baechle 
Cc: James Hogan 
Cc: linux-m...@linux-mips.org
Signed-off-by: "Eric W. Biederman" 
---
 arch/mips/kernel/traps.c | 65 ++--
 arch/mips/mm/fault.c | 19 --
 2 files changed, 23 insertions(+), 61 deletions(-)

diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 967e9e4e795e..66ec4b0b484d 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -699,17 +699,11 @@ static int simulate_sync(struct pt_regs *regs, unsigned 
int opcode)
 asmlinkage void do_ov(struct pt_regs *regs)
 {
enum ctx_state prev_state;
-   siginfo_t info;
-
-   clear_siginfo();
-   info.si_signo = SIGFPE;
-   info.si_code = FPE_INTOVF;
-   info.si_addr = (void __user *)regs->cp0_epc;
 
prev_state = exception_enter();
die_if_kernel("Integer overflow", regs);
 
-   force_sig_info(SIGFPE, , current);
+   force_sig_fault(SIGFPE, FPE_INTOVF, (void __user *)regs->cp0_epc, 
current);
exception_exit(prev_state);
 }
 
@@ -722,32 +716,27 @@ asmlinkage void do_ov(struct pt_regs *regs)
 void force_fcr31_sig(unsigned long fcr31, void __user *fault_addr,
 struct task_struct *tsk)
 {
-   struct siginfo si;
-
-   clear_siginfo();
-   si.si_addr = fault_addr;
-   si.si_signo = SIGFPE;
+   int si_code;
 
if (fcr31 & FPU_CSR_INV_X)
-   si.si_code = FPE_FLTINV;
+   si_code = FPE_FLTINV;
else if (fcr31 & FPU_CSR_DIV_X)
-   si.si_code = FPE_FLTDIV;
+   si_code = FPE_FLTDIV;
else if (fcr31 & FPU_CSR_OVF_X)
-   si.si_code = FPE_FLTOVF;
+   si_code = FPE_FLTOVF;
else if (fcr31 & FPU_CSR_UDF_X)
-   si.si_code = FPE_FLTUND;
+   si_code = FPE_FLTUND;
else if (fcr31 & FPU_CSR_INE_X)
-   si.si_code = FPE_FLTRES;
+   si_code = FPE_FLTRES;
 
-   force_sig_info(SIGFPE, , tsk);
+   force_sig_fault(SIGFPE, si_code, fault_addr, tsk);
 }
 
 int process_fpemu_return(int sig, void __user *fault_addr, unsigned long fcr31)
 {
-   struct siginfo si;
+   int si_code;
struct vm_area_struct *vma;
 
-   clear_siginfo();
switch (sig) {
case 0:
return 0;
@@ -757,23 +746,18 @@ int process_fpemu_return(int sig, void __user 
*fault_addr, unsigned long fcr31)
return 1;
 
case SIGBUS:
-   si.si_addr = fault_addr;
-   si.si_signo = sig;
-   si.si_code = BUS_ADRERR;
-   force_sig_info(sig, , current);
+   force_sig_fault(SIGBUS, BUS_ADRERR, fault_addr, current);
return 1;
 
case SIGSEGV:
-   si.si_addr = fault_addr;
-   si.si_signo = sig;
down_read(>mm->mmap_sem);
vma = find_vma(current->mm, (unsigned long)fault_addr);
if (vma && (vma->vm_start <= (unsigned long)fault_addr))
-   si.si_code = SEGV_ACCERR;
+   si_code = SEGV_ACCERR;
else
-   si.si_code = SEGV_MAPERR;
+   si_code = SEGV_MAPERR;
up_read(>mm->mmap_sem);
-   force_sig_info(sig, , current);
+   force_sig_fault(SIGSEGV, si_code, fault_addr, current);
return 1;
 
default:
@@ -896,10 +880,8 @@ asmlinkage void do_fpe(struct pt_regs *regs, unsigned long 
fcr31)
 void do_trap_or_bp(struct pt_regs *regs, unsigned int code, int si_code,
const char *str)
 {
-   siginfo_t info;
char b[40];
 
-   clear_siginfo();
 #ifdef CONFIG_KGDB_LOW_LEVEL_TRAP
if (kgdb_ll_trap(DIE_TRAP, str, regs, code, current->thread.trap_nr,
 SIGTRAP) == NOTIFY_STOP)
@@ -921,13 +903,9 @@ void do_trap_or_bp(struct pt_regs *regs, unsigned int 
code, int si_code,
case BRK_DIVZERO:
scnprintf(b, sizeof(b), "%s instruction in kernel code", str);
die_if_kernel(b, regs);
-   if (code == BRK_DIVZERO)
-   info.si_code = FPE_INTDIV;
-   else
-   info.si_code = FPE_INTOVF;
-   info.si_signo = SIGFPE;
-   info.si_addr = (void __user *) 

[REVIEW][PATCH 07/22] signal/microblaze: Use force_sig_fault where appropriate

[Eric W. Biederman]

Filling in struct siginfo before calling force_sig_info a tedious and
error prone process, where once in a great while the wrong fields
are filled out, and siginfo has been inconsistently cleared.

Simplify this process by using the helper force_sig_fault.  Which
takes as a parameters all of the information it needs, ensures
all of the fiddly bits of filling in struct siginfo are done properly
and then calls force_sig_info.

In short about a 5 line reduction in code for every time force_sig_info
is called, which makes the calling function clearer.

Cc: Michal Simek 
Signed-off-by: "Eric W. Biederman" 
---
 arch/microblaze/kernel/exceptions.c | 9 +
 arch/microblaze/mm/fault.c  | 9 +
 2 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/arch/microblaze/kernel/exceptions.c 
b/arch/microblaze/kernel/exceptions.c
index 443ec1feacb4..eafff21fcb0e 100644
--- a/arch/microblaze/kernel/exceptions.c
+++ b/arch/microblaze/kernel/exceptions.c
@@ -60,17 +60,10 @@ asmlinkage void sw_exception(struct pt_regs *regs)
 
 void _exception(int signr, struct pt_regs *regs, int code, unsigned long addr)
 {
-   siginfo_t info;
-
if (kernel_mode(regs))
die("Exception in kernel mode", regs, signr);
 
-   clear_siginfo();
-   info.si_signo = signr;
-   info.si_errno = 0;
-   info.si_code = code;
-   info.si_addr = (void __user *) addr;
-   force_sig_info(signr, , current);
+   force_sig_fault(signr, code, (void __user *)addr, current);
 }
 
 asmlinkage void full_exception(struct pt_regs *regs, unsigned int type,
diff --git a/arch/microblaze/mm/fault.c b/arch/microblaze/mm/fault.c
index 1251d380df47..af607447c683 100644
--- a/arch/microblaze/mm/fault.c
+++ b/arch/microblaze/mm/fault.c
@@ -289,14 +289,7 @@ void do_page_fault(struct pt_regs *regs, unsigned long 
address,
 do_sigbus:
up_read(>mmap_sem);
if (user_mode(regs)) {
-   siginfo_t info;
-
-   clear_siginfo();
-   info.si_signo = SIGBUS;
-   info.si_errno = 0;
-   info.si_code = BUS_ADRERR;
-   info.si_addr = (void __user *)address;
-   force_sig_info(SIGBUS, , current);
+   force_sig_fault(SIGBUS, BUS_ADRERR, (void __user *)address, 
current);
return;
}
bad_page_fault(regs, address, SIGBUS);
-- 
2.14.1

[REVIEW][PATCH 05/22] signal/m68k: Use force_sig_fault where appropriate

[Eric W. Biederman]

Filling in struct siginfo before calling force_sig_info a tedious and
error prone process, where once in a great while the wrong fields
are filled out, and siginfo has been inconsistently cleared.

Simplify this process by using the helper force_sig_fault.  Which
takes as a parameters all of the information it needs, ensures
all of the fiddly bits of filling in struct siginfo are done properly
and then calls force_sig_info.

In short about a 5 line reduction in code for every time force_sig_info
is called, which makes the calling function clearer.

Cc: Geert Uytterhoeven 
Cc: linux-m...@lists.linux-m68k.org
Signed-off-by: "Eric W. Biederman" 
---
 arch/m68k/kernel/traps.c | 60 
 arch/m68k/mm/fault.c | 25 +---
 2 files changed, 36 insertions(+), 49 deletions(-)

diff --git a/arch/m68k/kernel/traps.c b/arch/m68k/kernel/traps.c
index 0a00b476236d..b2fd000b9285 100644
--- a/arch/m68k/kernel/traps.c
+++ b/arch/m68k/kernel/traps.c
@@ -1007,11 +1007,10 @@ void bad_super_trap (struct frame *fp)
 
 asmlinkage void trap_c(struct frame *fp)
 {
-   int sig;
+   int sig, si_code;
+   void __user *addr;
int vector = (fp->ptregs.vector >> 2) & 0xff;
-   siginfo_t info;
 
-   clear_siginfo();
if (fp->ptregs.sr & PS_S) {
if (vector == VEC_TRACE) {
/* traced a trapping instruction on a 68020/30,
@@ -1030,21 +1029,21 @@ asmlinkage void trap_c(struct frame *fp)
/* send the appropriate signal to the user program */
switch (vector) {
case VEC_ADDRERR:
-   info.si_code = BUS_ADRALN;
+   si_code = BUS_ADRALN;
sig = SIGBUS;
break;
case VEC_ILLEGAL:
case VEC_LINE10:
case VEC_LINE11:
-   info.si_code = ILL_ILLOPC;
+   si_code = ILL_ILLOPC;
sig = SIGILL;
break;
case VEC_PRIV:
-   info.si_code = ILL_PRVOPC;
+   si_code = ILL_PRVOPC;
sig = SIGILL;
break;
case VEC_COPROC:
-   info.si_code = ILL_COPROC;
+   si_code = ILL_COPROC;
sig = SIGILL;
break;
case VEC_TRAP1:
@@ -1061,76 +1060,74 @@ asmlinkage void trap_c(struct frame *fp)
case VEC_TRAP12:
case VEC_TRAP13:
case VEC_TRAP14:
-   info.si_code = ILL_ILLTRP;
+   si_code = ILL_ILLTRP;
sig = SIGILL;
break;
case VEC_FPBRUC:
case VEC_FPOE:
case VEC_FPNAN:
-   info.si_code = FPE_FLTINV;
+   si_code = FPE_FLTINV;
sig = SIGFPE;
break;
case VEC_FPIR:
-   info.si_code = FPE_FLTRES;
+   si_code = FPE_FLTRES;
sig = SIGFPE;
break;
case VEC_FPDIVZ:
-   info.si_code = FPE_FLTDIV;
+   si_code = FPE_FLTDIV;
sig = SIGFPE;
break;
case VEC_FPUNDER:
-   info.si_code = FPE_FLTUND;
+   si_code = FPE_FLTUND;
sig = SIGFPE;
break;
case VEC_FPOVER:
-   info.si_code = FPE_FLTOVF;
+   si_code = FPE_FLTOVF;
sig = SIGFPE;
break;
case VEC_ZERODIV:
-   info.si_code = FPE_INTDIV;
+   si_code = FPE_INTDIV;
sig = SIGFPE;
break;
case VEC_CHK:
case VEC_TRAP:
-   info.si_code = FPE_INTOVF;
+   si_code = FPE_INTOVF;
sig = SIGFPE;
break;
case VEC_TRACE: /* ptrace single step */
-   info.si_code = TRAP_TRACE;
+   si_code = TRAP_TRACE;
sig = SIGTRAP;
break;
case VEC_TRAP15:/* breakpoint */
-   info.si_code = TRAP_BRKPT;
+   si_code = TRAP_BRKPT;
sig = SIGTRAP;
break;
default:
-   info.si_code = ILL_ILLOPC;
+   si_code = ILL_ILLOPC;
sig = SIGILL;
break;
}
-   info.si_signo = sig;
-   info.si_errno = 0;
switch (fp->ptregs.format) {
default:
-   info.si_addr = (void *) fp->ptregs.pc;
+   addr = (void __user *) fp->ptregs.pc;
break;
case 2:
-   info.si_addr = (void *) fp->un.fmt2.iaddr;
+   addr = (void __user *) fp->un.fmt2.iaddr;
break;
case 7:
-   info.si_addr = (void *) fp->un.fmt7.effaddr;
+   addr = (void __user *) fp->un.fmt7.effaddr;
  

[REVIEW][PATCH 03/22] signal/c6x: Use force_sig_fault where appropriate

[Eric W. Biederman]

Filling in struct siginfo before calling force_sig_info a tedious and
error prone process, where once in a great while the wrong fields
are filled out, and siginfo has been inconsistently cleared.

Simplify this process by using the helper force_sig_fault.  Which
takes as a parameters all of the information it needs, ensures
all of the fiddly bits of filling in struct siginfo are done properly
and then calls force_sig_info.

In short about a 5 line reduction in code for every time force_sig_info
is called, which makes the calling function clearer.

Cc: Mark Salter 
Cc: Aurelien Jacquiot 
Cc: linux-c6x-...@linux-c6x.org
Signed-off-by: "Eric W. Biederman" 
---
 arch/c6x/kernel/traps.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/arch/c6x/kernel/traps.c b/arch/c6x/kernel/traps.c
index c5feee4542b0..5c60aea3b75a 100644
--- a/arch/c6x/kernel/traps.c
+++ b/arch/c6x/kernel/traps.c
@@ -244,9 +244,7 @@ static struct exception_info eexcept_table[128] = {
 static void do_trap(struct exception_info *except_info, struct pt_regs *regs)
 {
unsigned long addr = instruction_pointer(regs);
-   siginfo_t info;
 
-   clear_siginfo();
if (except_info->code != TRAP_BRKPT)
pr_err("TRAP: %s PC[0x%lx] signo[%d] code[%d]\n",
   except_info->kernel_str, regs->pc,
@@ -254,12 +252,8 @@ static void do_trap(struct exception_info *except_info, 
struct pt_regs *regs)
 
die_if_kernel(except_info->kernel_str, regs, addr);
 
-   info.si_signo = except_info->signo;
-   info.si_errno = 0;
-   info.si_code  = except_info->code;
-   info.si_addr  = (void __user *)addr;
-
-   force_sig_info(except_info->signo, , current);
+   force_sig_fault(except_info->signo, except_info->code,
+   (void __user *)addr, current);
 }
 
 /*
-- 
2.14.1

Re: [RFC PATCH v2 4/6] sched/fair: Introduce an energy estimation helper function

[Quentin Perret]

Hi Leo,

On Wednesday 18 Apr 2018 at 20:15:47 (+0800), Leo Yan wrote:
> Sorry I introduce mess at here to spread my questions in several
> replying, later will try to ask questions in one replying.  Below are
> more questions which it's good to bring up:
> 
> The code for energy computation is quite neat and simple, but I think
> the energy computation mixes two concepts for CPU util: one concept is
> the estimated CPU util which is used to select CPU OPP in schedutil,
> another concept is the raw CPU util according to CPU real running time;
> for example, cpu_util_next() predicts CPU util but this value might be
> much higher than cpu_util(), especially after enabled UTIL_EST feature
> (I have shallow understanding for UTIL_EST so correct me as needed);

I'm not not sure to understand what you mean by higher than cpu_util()
here ... In which case would that happen ?

cpu_util_next() is basically used to figure out what will be the
cpu_util() of CPU A after task p has been enqueued on CPU B (no matter
what A and B are).

> but this patch simply computes CPU capacity and energy with the single
> one CPU utilization value (and it will be an inflated value afte enable
> UTIL_EST).  Is this purposed for simple implementation?
> 
> IMHO, cpu_util_next() can be used to predict CPU capacity, on the other
> hand, should we use the CPU util without UTIL_EST capping for 'sum_util',
> this can be more reasonable to reflect the CPU utilization?

Why would a decayed utilisation be a better estimate of the time that
a task is going to spend on a CPU ?

> 
> Furthermore, if we consider RT thread is running on CPU and connect with
> 'schedutil' governor, the CPU will run at maximum frequency, but we
> cannot say the CPU has 100% utilization.  The RT thread case is not
> handled in this patch.

Right, we don't account for RT tasks in the OPP prediction for now.
Vincent's patches to have a util_avg for RT runqueues could help us
do that I suppose ...

Thanks !
Quentin

Re: [PATCH] [net] ipv6: sr: fix NULL pointer dereference in seg6_do_srh_encap()- v4 pkts

[Ahmed Abdelsalam]

On Fri, 20 Apr 2018 15:38:08 +0100
David Lebrun  wrote:

> On 04/20/2018 02:58 PM, Ahmed Abdelsalam wrote:
> > In case of seg6 in encap mode, seg6_do_srh_encap() calls set_tun_src()
> > in order to set the src addr of outer IPv6 header.
> > 
> > The net_device is required for set_tun_src(). However calling ip6_dst_idev()
> > on dst_entry in case of IPv4 traffic results on the following bug.
> > 
> > Using just dst->dev should fix this BUG.
> > 
> 
> Good catch, thanks for spotting this. If you actually tested your fix 
> with IPv4 and IPv6 traffic, you should mention it in the commit message. 
> Your current formulation suggests that you just guessed a fix without 
> testing.
> 

Yes, I did two tests for both IPv4 and IPv6.
Sorry for this Language Bug. 

> > 
> > Fixes: 8936ef7604c11 ipv6: sr: fix NULL pointer dereference when setting 
> > encap source address
> > Signed-off-by: Ahmed Abdelsalam
> 
> Acked-by: David Lebrun 


-- 
Ahmed Abdelsalam 

[REVIEW][PATCH 19/22] signal/um: Use force_sig_fault in relay_signal.

[Eric W. Biederman]

Today user mode linux only works on x86 and x86_64 and this allows
simplifications of relay_signal.

- x86 always set si_errno to 0 in fault handlers.
- x86 does not implement si_trapno.
- Only si_codes between SI_USER and SI_KERNEL have a fault address.

Therefore warn if si_errno is set (it should never be).
Use force_sig_info in the case where we know we have a good fault.

For signals whose content it is not clear how to relay use plain
force_sig and let the signal sending code come up with an
appropriate generic siginfo.

Cc: Jeff Dike 
Cc: Richard Weinberger 
Cc: user-mode-linux-de...@lists.sourceforge.net
Signed-off-by: "Eric W. Biederman" 
---
 arch/um/kernel/trap.c | 28 +---
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/arch/um/kernel/trap.c b/arch/um/kernel/trap.c
index d4d38520c4c6..5f0ff17cd790 100644
--- a/arch/um/kernel/trap.c
+++ b/arch/um/kernel/trap.c
@@ -296,9 +296,6 @@ unsigned long segv(struct faultinfo fi, unsigned long ip, 
int is_user,
 
 void relay_signal(int sig, struct siginfo *si, struct uml_pt_regs *regs)
 {
-   struct faultinfo *fi;
-   struct siginfo clean_si;
-
if (!UPT_IS_USER(regs)) {
if (sig == SIGBUS)
printk(KERN_ERR "Bus error - the host /dev/shm or /tmp "
@@ -308,29 +305,30 @@ void relay_signal(int sig, struct siginfo *si, struct 
uml_pt_regs *regs)
 
arch_examine_signal(sig, regs);
 
-   clear_siginfo(_si);
-   clean_si.si_signo = si->si_signo;
-   clean_si.si_errno = si->si_errno;
-   clean_si.si_code = si->si_code;
+   if (unlikely(si->si_errno)) {
+   printk(KERN_ERR "Attempted to relay signal %d (si_code = %d) 
with errno %d\n",
+  sig, si->si_code, si->si_errno);
+   }
switch (sig) {
case SIGILL:
case SIGFPE:
case SIGSEGV:
case SIGBUS:
case SIGTRAP:
-   fi = UPT_FAULTINFO(regs);
-   clean_si.si_addr = (void __user *) FAULT_ADDRESS(*fi);
-   current->thread.arch.faultinfo = *fi;
-#ifdef __ARCH_SI_TRAPNO
-   clean_si.si_trapno = si->si_trapno;
-#endif
-   break;
+   if ((si->si_code > SI_USER) && (si->si_code < SI_KERNEL)) {
+   struct faultinfo *fi = UPT_FAULTINFO(regs);
+   current->thread.arch.faultinfo = *fi;
+   force_sig_fault(sig, si->si_code,
+   (void __user *)FAULT_ADDRESS(*fi),
+   current);
+   break;
+   }
default:
printk(KERN_ERR "Attempted to relay unknown signal %d (si_code 
= %d)\n",
sig, si->si_code);
}
 
-   force_sig_info(sig, _si, current);
+   force_sig(sig, current);
 }
 
 void bus_handler(int sig, struct siginfo *si, struct uml_pt_regs *regs)
-- 
2.14.1