All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v2 2/4] libnvdimm/namespace: Enforce memremap_compat_align()
From: Jeff Moyer @ 2020-02-14 16:44 UTC (permalink / raw)
  To: Dan Williams
  Cc: Aneesh Kumar K.V, Vishal L Verma, linuxppc-dev,
	Linux Kernel Mailing List, linux-nvdimm
In-Reply-To: <CAPcyv4hQouRNBcJ4uZ2mysr_aKstLhvUf66gRQ_3QoQNyOy72g@mail.gmail.com>

Dan Williams <dan.j.williams@intel.com> writes:

> On Thu, Feb 13, 2020 at 1:55 PM Jeff Moyer <jmoyer@redhat.com> wrote:
>>
>> Dan Williams <dan.j.williams@intel.com> writes:
>>
>> > The pmem driver on PowerPC crashes with the following signature when
>> > instantiating misaligned namespaces that map their capacity via
>> > memremap_pages().
>> >
>> >     BUG: Unable to handle kernel data access at 0xc001000406000000
>> >     Faulting instruction address: 0xc000000000090790
>> >     NIP [c000000000090790] arch_add_memory+0xc0/0x130
>> >     LR [c000000000090744] arch_add_memory+0x74/0x130
>> >     Call Trace:
>> >      arch_add_memory+0x74/0x130 (unreliable)
>> >      memremap_pages+0x74c/0xa30
>> >      devm_memremap_pages+0x3c/0xa0
>> >      pmem_attach_disk+0x188/0x770
>> >      nvdimm_bus_probe+0xd8/0x470
>> >
>> > With the assumption that only memremap_pages() has alignment
>> > constraints, enforce memremap_compat_align() for
>> > pmem_should_map_pages(), nd_pfn, or nd_dax cases.
>> >
>> > Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> > Cc: Jeff Moyer <jmoyer@redhat.com>
>> > Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> > Link: https://lore.kernel.org/r/158041477336.3889308.4581652885008605170.stgit@dwillia2-desk3.amr.corp.intel.com
>> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>> > ---
>> >  drivers/nvdimm/namespace_devs.c |   10 ++++++++++
>> >  1 file changed, 10 insertions(+)
>> >
>> > diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
>> > index 032dc61725ff..aff1f32fdb4f 100644
>> > --- a/drivers/nvdimm/namespace_devs.c
>> > +++ b/drivers/nvdimm/namespace_devs.c
>> > @@ -1739,6 +1739,16 @@ struct nd_namespace_common *nvdimm_namespace_common_probe(struct device *dev)
>> >               return ERR_PTR(-ENODEV);
>> >       }
>> >
>> > +     if (pmem_should_map_pages(dev) || nd_pfn || nd_dax) {
>> > +             struct nd_namespace_io *nsio = to_nd_namespace_io(&ndns->dev);
>> > +             resource_size_t start = nsio->res.start;
>> > +
>> > +             if (!IS_ALIGNED(start | size, memremap_compat_align())) {
>> > +                     dev_dbg(&ndns->dev, "misaligned, unable to map\n");
>> > +                     return ERR_PTR(-EOPNOTSUPP);
>> > +             }
>> > +     }
>> > +
>> >       if (is_namespace_pmem(&ndns->dev)) {
>> >               struct nd_namespace_pmem *nspm;
>> >
>>
>> Actually, I take back my ack.  :) This prevents a previously working
>> namespace from being successfully probed/setup.
>
> Do you have a test case handy? I can see a potential gap with a
> namespace that used internal padding to fix up the alignment.

# ndctl list -v -n namespace0.0
[
  {
    "dev":"namespace0.0",
    "mode":"fsdax",
    "map":"dev",
    "size":52846133248,
    "uuid":"b99f6f6a-2909-4189-9bfa-6eeebd95d40e",
    "raw_uuid":"aff43777-015b-493f-bbf9-7c7b0fe33519",
    "sector_size":512,
    "align":4096,
    "blockdev":"pmem0",
    "numa_node":0
  }
]

# cat /sys/bus/nd/devices/region0/mappings
6

# grep namespace0.0 /proc/iomem
  1860000000-24e0003fff : namespace0.0

> The goal of this check is to catch cases that are just going to fail
> devm_memremap_pages(), and the expectation is that it could not have
> worked before unless it was ported from another platform, or someone
> flipped the page-size switch on PowerPC.

On x86, creation and probing of the namespace worked fine before this
patch.  What *doesn't* work is creating another fsdax namespace after
this one.  sector mode namespaces can still be created, though:

[
  {
    "dev":"namespace0.1",
    "mode":"sector",
    "size":53270768640,
    "uuid":"67ea2c74-d4b1-4fc9-9c1a-a7d2a6c2a4a7",
    "sector_size":512,
    "blockdev":"pmem0.1s"
  },

# grep namespace0.1 /proc/iomem
  24e0004000-3160007fff : namespace0.1

>> I thought we were only going to enforce the alignment for a newly
>> created namespace?  This should only check whether the alignment
>> works for the current platform.
>
> The model is a new default 16MB alignment is enforced at creation
> time, but if you need to support previously created namespaces then
> you can manually trim that alignment requirement to no less than
> memremap_compat_align() because that's the point at which
> devm_memremap_pages() will start failing or crashing.

The problem is that older kernels did not enforce alignment to
SUBSECTION_SIZE.  We shouldn't prevent those namespaces from being
accessed.  The probe itself will not cause the WARN_ON to trigger.
Creating new namespaces at misaligned addresses could, but you've
altered the free space allocation such that we won't hit that anymore.

If I drop this patch, the probe will still work, and allocating new
namespaces will also work:

# ndctl list
[
  {
    "dev":"namespace0.1",
    "mode":"sector",
    "size":53270768640,
    "uuid":"67ea2c74-d4b1-4fc9-9c1a-a7d2a6c2a4a7",
    "sector_size":512,
    "blockdev":"pmem0.1s"
  },
  {
    "dev":"namespace0.0",
    "mode":"fsdax",
    "map":"dev",
    "size":52846133248,
    "uuid":"b99f6f6a-2909-4189-9bfa-6eeebd95d40e",
    "sector_size":512,
    "align":4096,
    "blockdev":"pmem0"
  }
]
 ndctl create-namespace -m fsdax -s 36g -r 0
{
  "dev":"namespace0.2",
  "mode":"fsdax",
  "map":"dev",
  "size":"35.44 GiB (38.05 GB)",
  "uuid":"7893264c-c7ef-4cbe-95e1-ccf2aff041fb",
  "sector_size":512,
  "align":2097152,
  "blockdev":"pmem0.2"
}

proc/iomem:

1860000000-d55fffffff : Persistent Memory
  1860000000-24e0003fff : namespace0.0
  24e0004000-3160007fff : namespace0.1
  3162000000-3a61ffffff : namespace0.2

So, maybe the right thing is to make memremap_compat_align return
PAGE_SIZE for x86 instead of SUBSECTION_SIZE?

-Jeff


^ permalink raw reply

* Re: [PATCH v2 1/4] firmware: xilinx: Add sysfs interface
From: 'Greg KH' @ 2020-02-14 17:10 UTC (permalink / raw)
  To: Jolly Shah
  Cc: keescook@chromium.org, ard.biesheuvel@linaro.org,
	matt@codeblueprint.co.uk, dmitry.torokhov@gmail.com,
	linux-kernel@vger.kernel.org, Rajan Vaja, Michal Simek,
	sudeep.holla@arm.com, mingo@kernel.org,
	linux-arm-kernel@lists.infradead.org, hkallweit1@gmail.com
In-Reply-To: <3ef20e9d-052f-665c-7fc8-69a1f8bc9bd2@xilinx.com>

On Mon, Feb 10, 2020 at 04:57:01PM -0800, Jolly Shah wrote:
> Hi Greg,
> 
> > ------Original Message------
> > From: 'Greg Kh' <gregkh@linuxfoundation.org>
> > Sent:  Friday, January 31, 2020 1:36AM
> > To: Rajan Vaja <RAJANV@xilinx.com>
> > Cc: Jolly Shah <JOLLYS@xilinx.com>, Ard Biesheuvel
> <ard.biesheuvel@linaro.org>, Mingo <mingo@kernel.org>, Matt
> <matt@codeblueprint.co.uk>, Sudeep Holla <sudeep.holla@arm.com>, Hkallweit1
> <hkallweit1@gmail.com>, Keescook <keescook@chromium.org>, Dmitry Torokhov
> <dmitry.torokhov@gmail.com>, Michal Simek <michals@xilinx.com>,
> Linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Linux-kernel
> <linux-kernel@vger.kernel.org>
> > Subject: Re: [PATCH v2 1/4] firmware: xilinx: Add sysfs interface
> >
> > On Fri, Jan 31, 2020 at 09:05:15AM +0000, Rajan Vaja wrote:
> > > Hi Greg,
> > > 
> > > > -----Original Message-----
> > > > From: Greg KH <gregkh@linuxfoundation.org>
> > > > Sent: 31 January 2020 11:41 AM
> > > > To: Jolly Shah <JOLLYS@xilinx.com>
> > > > Cc: ard.biesheuvel@linaro.org; mingo@kernel.org; matt@codeblueprint.co.uk;
> > > > sudeep.holla@arm.com; hkallweit1@gmail.com; keescook@chromium.org;
> > > > dmitry.torokhov@gmail.com; Michal Simek <michals@xilinx.com>; Rajan Vaja
> > > > <RAJANV@xilinx.com>; linux-arm-kernel@lists.infradead.org; linux-
> > > > kernel@vger.kernel.org
> > > > Subject: Re: [PATCH v2 1/4] firmware: xilinx: Add sysfs interface
> > > > 
> > > > EXTERNAL EMAIL
> > > > 
> > > > On Thu, Jan 30, 2020 at 11:59:03PM +0000, Jolly Shah wrote:
> > > > > Hi Greg,
> > > > > 
> > > > > On 1/27/20, 10:28 PM, "linux-kernel-owner@vger.kernel.org on behalf of Greg
> > > > KH" <linux-kernel-owner@vger.kernel.org on behalf of
> > > > gregkh@linuxfoundation.org> wrote:
> > > > > 
> > > > >      On Mon, Jan 27, 2020 at 11:01:27PM +0000, Jolly Shah wrote:
> > > > >      >     > > > +     ret = kstrtol(tok, 16, &value);
> > > > >      >     > > > +     if (ret) {
> > > > >      >     > > > +             ret = -EFAULT;
> > > > >      >     > > > +             goto err;
> > > > >      >     > > > +     }
> > > > >      >     > > > +
> > > > >      >     > > > +     ret = eemi_ops->ioctl(0, read_ioctl, reg, 0, ret_payload);
> > > > >      >     > >
> > > > >      >     > > This feels "tricky", if you tie this to the device you have your driver
> > > > >      >     > > bound to, will this make it easier instead of having to go through the
> > > > >      >     > > ioctl callback?
> > > > >      >     > >
> > > > >      >     >
> > > > >      >     > GGS(general global storage) registers are in PMU space and linux
> > > > doesn't have access to it
> > > > >      >     > Hence ioctl is used.
> > > > >      >
> > > > >      >     Why not just a "real" call to the driver to make this type of reading?
> > > > >      >     You don't have ioctls within the kernel for other drivers to call,
> > > > >      >     that's not needed at all.
> > > > >      >
> > > > >      > these registers are for users  and for special needs where users wants
> > > > >      > to retain values over resets. but as they belong to PMU address space,
> > > > >      > these interface APIs are provided. They don’t allow access to any
> > > > >      > other registers.
> > > > > 
> > > > >      That's not the issue here.  The issue is you are using an "internal"
> > > > >      ioctl, instead just make a "real" call.
> > > > > 
> > > > > Sorry I am not clear. Do you mean that we should use linux standard
> > > > > ioctl interface instead of internal ioctl by mentioning "real" ?
> > > > 
> > > > No, you should just make a "real" function call to the exact thing you
> > > > want to do.  Not have an internal multi-plexor ioctl() call that others
> > > > then call.  This isn't a microkernel :)
> > > [Rajan] Sorry for multiple back and forth but as I understand, you are suggesting to create a new API for
> > > Read/write of GGS register instead of using PM_IOCTL API (eemi_ops->ioctl) for multiple purpose. Is my understanding correct?
> > 
> > That is correct.
> 
> 
> 
> Would like to clarify purpose of having ioctl API to avoid any confusion.
> eemi interface apis are defined to be platform independent and allows clock,
> reset, power etc management through firmware but apart from these generic
> operations, there are some operations which needs secure access through
> firmware. Examples are accessing some storage registers(ggs and pggs) for
> inter agent communication, configuring another agent(RPU) mode, boot device
> configuration etc. Those operations are covered as ioctls as they are very
> platform specific. Also only whitelisted operations are allowed through
> ioctl and is not exposed to user for any random read/write operation.
> 
> Olof earlier had same concerns. We had clarified the purpose and with his
> agreement, initial set of ioctls were accepted.
> (https://www.lkml.org/lkml/2018/9/24/1570)
> 
> Please suggest the best approach to handle this for current and future
> patches.

Ok, in looking further at this, it's both better than I thought, and
totally worse.

This interface you all are using where you ask the firmware driver for a
pointer to a set of operation functions and then make calls through that
is indicitive of an api that is NOT what we normally use in Linux at
all.

Just make the direct call to the firmware driver, no need to muck around
with tables of function pointers.  In fact, with the spectre changes,
you just made things slower than needed, and you can get back a bunch of
throughput by removing that whole middle layer.

So go do that first please, before adding any new stuff.

Now for the ioctl, yeah, that's not a "normal" pattern either.  But
right now you only have 2 "different" ioctls that you call.  So why not
just turn those 2 into real function calls as well that then makes the
"ioctl" call to the hardware?  That makes things a lot more obvious on
the kernel driver side exactly what is going on.

If you need to add more "ioctl" like calls, just add them as more
functions, no big deal.  How many more of these are you going to need
over time?

But that's not all that big of a deal right now, get rid of that whole
middle-layer first, that's more important to clean up.  You will get rid
of a lot of unneeded code and indirection that way, making it simpler
and easier to understand what exactly is happening.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] misc: Use kzalloc() instead of kmalloc() with flag GFP_ZERO.
From: Greg KH @ 2020-02-14 17:16 UTC (permalink / raw)
  To: Yi Wang
  Cc: sudeep.dutt, ashutosh.dixit, arnd, vincent.whitchurch,
	alexios.zavras, tglx, allison, linux-kernel, xue.zhihong,
	wang.liang82, Huang Zijiang
In-Reply-To: <1581501247-5479-1-git-send-email-wang.yi59@zte.com.cn>

On Wed, Feb 12, 2020 at 05:54:07PM +0800, Yi Wang wrote:
> From: Huang Zijiang <huang.zijiang@zte.com.cn>
> 
> Use kzalloc instead of manually setting kmalloc
> with flag GFP_ZERO since kzalloc sets allocated memory
> to zero.
> 
> Change in v2:
>      add indation

This list of what changed should go below the --- line.  I've fixed it
up now, no need to redo this.

thanks,

greg k-h

^ permalink raw reply

* Re: [RFC PATCH v4 01/25] virtual-bus: Implementation of Virtual Bus
From: Greg KH @ 2020-02-14 17:02 UTC (permalink / raw)
  To: Jeff Kirsher
  Cc: davem, Dave Ertman, netdev, linux-rdma, nhorman, sassmann, jgg,
	parav, galpress, selvin.xavier, sriharsha.basavapatna, benve,
	bharat, xavier.huwei, yishaih, leonro, mkalderon, aditr,
	Kiran Patil, Andrew Bowers
In-Reply-To: <20200212191424.1715577-2-jeffrey.t.kirsher@intel.com>

On Wed, Feb 12, 2020 at 11:14:00AM -0800, Jeff Kirsher wrote:
> From: Dave Ertman <david.m.ertman@intel.com>
> 
> This is the initial implementation of the Virtual Bus,
> virtbus_device and virtbus_driver.  The virtual bus is
> a software based bus intended to support registering
> virtbus_devices and virtbus_drivers and provide matching
> between them and probing of the registered drivers.
> 
> The bus will support probe/remove shutdown and
> suspend/resume callbacks.
> 
> Kconfig and Makefile alterations are included
> 
> Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
> Signed-off-by: Kiran Patil <kiran.patil@intel.com>
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

This looks a lot better, and is more of what I was thinking.  Some minor
comments below:

> +/**
> + * virtbus_dev_register - add a virtual bus device
> + * @vdev: virtual bus device to add
> + */
> +int virtbus_dev_register(struct virtbus_device *vdev)
> +{
> +	int ret;
> +
> +	if (!vdev->release) {
> +		dev_err(&vdev->dev, "virtbus_device .release callback NULL\n");

"virtbus_device MUST have a .release callback that does something!\n" 

> +		return -EINVAL;
> +	}
> +
> +	device_initialize(&vdev->dev);
> +
> +	vdev->dev.bus = &virtual_bus_type;
> +	vdev->dev.release = virtbus_dev_release;
> +	/* All device IDs are automatically allocated */
> +	ret = ida_simple_get(&virtbus_dev_ida, 0, 0, GFP_KERNEL);
> +	if (ret < 0) {
> +		dev_err(&vdev->dev, "get IDA idx for virtbus device failed!\n");
> +		put_device(&vdev->dev);

If you allocate the number before device_initialize(), no need to call
put_device().  Just a minor thing, no big deal.

> +		return ret;
> +	}
> +
> +	vdev->id = ret;
> +	dev_set_name(&vdev->dev, "%s.%d", vdev->name, vdev->id);
> +
> +	dev_dbg(&vdev->dev, "Registering virtbus device '%s'\n",
> +		dev_name(&vdev->dev));
> +
> +	ret = device_add(&vdev->dev);
> +	if (ret)
> +		goto device_add_err;
> +
> +	return 0;
> +
> +device_add_err:
> +	dev_err(&vdev->dev, "Add device to virtbus failed!\n");

Print the return error here too?

> +	put_device(&vdev->dev);
> +	ida_simple_remove(&virtbus_dev_ida, vdev->id);

You need to do this before put_device().

> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(virtbus_dev_register);
> +


> --- /dev/null
> +++ b/include/linux/virtual_bus.h
> @@ -0,0 +1,57 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * virtual_bus.h - lightweight software bus
> + *
> + * Copyright (c) 2019-20 Intel Corporation
> + *
> + * Please see Documentation/driver-api/virtual_bus.rst for more information
> + */
> +
> +#ifndef _VIRTUAL_BUS_H_
> +#define _VIRTUAL_BUS_H_
> +
> +#include <linux/device.h>
> +
> +struct virtbus_device {
> +	struct device dev;
> +	const char *name;
> +	void (*release)(struct virtbus_device *);
> +	int id;
> +	const struct virtbus_dev_id *matched_element;
> +};

Any reason you need to make "struct virtbus_device" a public structure
at all?  Why not just make it private and have the release function
pointer be passed as part of the register function?  That will keep
people from poking around in here.

> +
> +/* The memory for the table is expected to remain allocated for the duration
> + * of the pairing between driver and device.  The pointer for the matching
> + * element will be copied to the matched_element field of the virtbus_device.

I don't understand this last sentance, what are you trying to say?  We
save off a pointer to the element, so it better not go away, is that
what you mean?  Why would this happen?

> + */
> +struct virtbus_driver {
> +	int (*probe)(struct virtbus_device *);
> +	int (*remove)(struct virtbus_device *);
> +	void (*shutdown)(struct virtbus_device *);
> +	int (*suspend)(struct virtbus_device *, pm_message_t);
> +	int (*resume)(struct virtbus_device *);

Can all of these be const pointers such that we will not change them?

> +	struct device_driver driver;
> +	const struct virtbus_dev_id *id_table;
> +};

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH v2 1/4] firmware: xilinx: Add sysfs interface
From: 'Greg KH' @ 2020-02-14 17:10 UTC (permalink / raw)
  To: Jolly Shah
  Cc: Rajan Vaja, ard.biesheuvel@linaro.org, mingo@kernel.org,
	matt@codeblueprint.co.uk, sudeep.holla@arm.com,
	hkallweit1@gmail.com, keescook@chromium.org,
	dmitry.torokhov@gmail.com, Michal Simek,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <3ef20e9d-052f-665c-7fc8-69a1f8bc9bd2@xilinx.com>

On Mon, Feb 10, 2020 at 04:57:01PM -0800, Jolly Shah wrote:
> Hi Greg,
> 
> > ------Original Message------
> > From: 'Greg Kh' <gregkh@linuxfoundation.org>
> > Sent:  Friday, January 31, 2020 1:36AM
> > To: Rajan Vaja <RAJANV@xilinx.com>
> > Cc: Jolly Shah <JOLLYS@xilinx.com>, Ard Biesheuvel
> <ard.biesheuvel@linaro.org>, Mingo <mingo@kernel.org>, Matt
> <matt@codeblueprint.co.uk>, Sudeep Holla <sudeep.holla@arm.com>, Hkallweit1
> <hkallweit1@gmail.com>, Keescook <keescook@chromium.org>, Dmitry Torokhov
> <dmitry.torokhov@gmail.com>, Michal Simek <michals@xilinx.com>,
> Linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Linux-kernel
> <linux-kernel@vger.kernel.org>
> > Subject: Re: [PATCH v2 1/4] firmware: xilinx: Add sysfs interface
> >
> > On Fri, Jan 31, 2020 at 09:05:15AM +0000, Rajan Vaja wrote:
> > > Hi Greg,
> > > 
> > > > -----Original Message-----
> > > > From: Greg KH <gregkh@linuxfoundation.org>
> > > > Sent: 31 January 2020 11:41 AM
> > > > To: Jolly Shah <JOLLYS@xilinx.com>
> > > > Cc: ard.biesheuvel@linaro.org; mingo@kernel.org; matt@codeblueprint.co.uk;
> > > > sudeep.holla@arm.com; hkallweit1@gmail.com; keescook@chromium.org;
> > > > dmitry.torokhov@gmail.com; Michal Simek <michals@xilinx.com>; Rajan Vaja
> > > > <RAJANV@xilinx.com>; linux-arm-kernel@lists.infradead.org; linux-
> > > > kernel@vger.kernel.org
> > > > Subject: Re: [PATCH v2 1/4] firmware: xilinx: Add sysfs interface
> > > > 
> > > > EXTERNAL EMAIL
> > > > 
> > > > On Thu, Jan 30, 2020 at 11:59:03PM +0000, Jolly Shah wrote:
> > > > > Hi Greg,
> > > > > 
> > > > > On 1/27/20, 10:28 PM, "linux-kernel-owner@vger.kernel.org on behalf of Greg
> > > > KH" <linux-kernel-owner@vger.kernel.org on behalf of
> > > > gregkh@linuxfoundation.org> wrote:
> > > > > 
> > > > >      On Mon, Jan 27, 2020 at 11:01:27PM +0000, Jolly Shah wrote:
> > > > >      >     > > > +     ret = kstrtol(tok, 16, &value);
> > > > >      >     > > > +     if (ret) {
> > > > >      >     > > > +             ret = -EFAULT;
> > > > >      >     > > > +             goto err;
> > > > >      >     > > > +     }
> > > > >      >     > > > +
> > > > >      >     > > > +     ret = eemi_ops->ioctl(0, read_ioctl, reg, 0, ret_payload);
> > > > >      >     > >
> > > > >      >     > > This feels "tricky", if you tie this to the device you have your driver
> > > > >      >     > > bound to, will this make it easier instead of having to go through the
> > > > >      >     > > ioctl callback?
> > > > >      >     > >
> > > > >      >     >
> > > > >      >     > GGS(general global storage) registers are in PMU space and linux
> > > > doesn't have access to it
> > > > >      >     > Hence ioctl is used.
> > > > >      >
> > > > >      >     Why not just a "real" call to the driver to make this type of reading?
> > > > >      >     You don't have ioctls within the kernel for other drivers to call,
> > > > >      >     that's not needed at all.
> > > > >      >
> > > > >      > these registers are for users  and for special needs where users wants
> > > > >      > to retain values over resets. but as they belong to PMU address space,
> > > > >      > these interface APIs are provided. They don’t allow access to any
> > > > >      > other registers.
> > > > > 
> > > > >      That's not the issue here.  The issue is you are using an "internal"
> > > > >      ioctl, instead just make a "real" call.
> > > > > 
> > > > > Sorry I am not clear. Do you mean that we should use linux standard
> > > > > ioctl interface instead of internal ioctl by mentioning "real" ?
> > > > 
> > > > No, you should just make a "real" function call to the exact thing you
> > > > want to do.  Not have an internal multi-plexor ioctl() call that others
> > > > then call.  This isn't a microkernel :)
> > > [Rajan] Sorry for multiple back and forth but as I understand, you are suggesting to create a new API for
> > > Read/write of GGS register instead of using PM_IOCTL API (eemi_ops->ioctl) for multiple purpose. Is my understanding correct?
> > 
> > That is correct.
> 
> 
> 
> Would like to clarify purpose of having ioctl API to avoid any confusion.
> eemi interface apis are defined to be platform independent and allows clock,
> reset, power etc management through firmware but apart from these generic
> operations, there are some operations which needs secure access through
> firmware. Examples are accessing some storage registers(ggs and pggs) for
> inter agent communication, configuring another agent(RPU) mode, boot device
> configuration etc. Those operations are covered as ioctls as they are very
> platform specific. Also only whitelisted operations are allowed through
> ioctl and is not exposed to user for any random read/write operation.
> 
> Olof earlier had same concerns. We had clarified the purpose and with his
> agreement, initial set of ioctls were accepted.
> (https://www.lkml.org/lkml/2018/9/24/1570)
> 
> Please suggest the best approach to handle this for current and future
> patches.

Ok, in looking further at this, it's both better than I thought, and
totally worse.

This interface you all are using where you ask the firmware driver for a
pointer to a set of operation functions and then make calls through that
is indicitive of an api that is NOT what we normally use in Linux at
all.

Just make the direct call to the firmware driver, no need to muck around
with tables of function pointers.  In fact, with the spectre changes,
you just made things slower than needed, and you can get back a bunch of
throughput by removing that whole middle layer.

So go do that first please, before adding any new stuff.

Now for the ioctl, yeah, that's not a "normal" pattern either.  But
right now you only have 2 "different" ioctls that you call.  So why not
just turn those 2 into real function calls as well that then makes the
"ioctl" call to the hardware?  That makes things a lot more obvious on
the kernel driver side exactly what is going on.

If you need to add more "ioctl" like calls, just add them as more
functions, no big deal.  How many more of these are you going to need
over time?

But that's not all that big of a deal right now, get rid of that whole
middle-layer first, that's more important to clean up.  You will get rid
of a lot of unneeded code and indirection that way, making it simpler
and easier to understand what exactly is happening.

thanks,

greg k-h

^ permalink raw reply

* Re: [RFC PATCH 0/2] soundwire: add master_device/driver support
From: Greg KH @ 2020-02-14 16:49 UTC (permalink / raw)
  To: Pierre-Louis Bossart
  Cc: alsa-devel, linux-kernel, tiwai, broonie, vkoul, jank,
	srinivas.kandagatla, slawomir.blauciak, Bard liao, Rander Wang,
	Ranjani Sridharan
In-Reply-To: <20200201042011.5781-1-pierre-louis.bossart@linux.intel.com>

On Fri, Jan 31, 2020 at 10:20:09PM -0600, Pierre-Louis Bossart wrote:
> The SoundWire master representation needs to evolve to take into account:
> 
> a) a May 2019 recommendation from Greg KH to remove platform devices
> 
> b) the need on Intel platforms to support hardware startup only once
> the power rail dependencies are settled. The SoundWire master is not
> an independent IP at all.
> 
> c) the need to deal with external wakes handled by the PCI subsystem
> in specific low-power modes
> 
> In case it wasn't clear, the SoundWire subsystem is currently unusable
> with v5.5 on devices hitting the shelves very soon (race conditions,
> power management, suspend/resume, etc). v5.6 will only provide
> interface changes and no functional improvement. We've circled on the
> same concepts since September 2019, and I hope this direction is now
> aligned with the suggestions from Vinod Koul and that we can target
> v5.7 as the 'SoundWire just works(tm)' version.
> 
> This series is provided as an RFC since it depends on patches already
> for review.

Both of these look sane to me, nice work!

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply

* Re: [PATCH v2 0/8] serial: Disable DMA and PM on kernel console
From: Greg Kroah-Hartman @ 2020-02-14 16:33 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Jiri Slaby, linux-serial, Sebastian Andrzej Siewior,
	Tony Lindgren
In-Reply-To: <20200214114339.53897-1-andriy.shevchenko@linux.intel.com>

On Fri, Feb 14, 2020 at 01:43:31PM +0200, Andy Shevchenko wrote:
> This is second attempt [1] to get rid of problematic DMA and PM calls
> in the serial kernel console code.
> 
> Kernel console is sensitive to any kind of complex work needed to print
> out anything on it. One such case is emergency print during Oops.
> 
> Patches 1-3 are preparatory ones.

I've applied these first 3, as they are "obvious" :)

I'll let others weigh in on the other patches here, as I'd like to see
if Tony and others feel it solves their issues or not.

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH 5.5 000/120] 5.5.4-stable review
From: Greg Kroah-Hartman @ 2020-02-14 15:22 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: open list, Shuah Khan, patches, lkft-triage, Ben Hutchings,
	linux- stable, Andrew Morton, Linus Torvalds, Guenter Roeck
In-Reply-To: <CA+G9fYudhnZ9dmSk_ujQa4A8MA6N_HWjEyJV3CLDcBTceN-nLw@mail.gmail.com>

On Fri, Feb 14, 2020 at 03:50:33PM +0530, Naresh Kamboju wrote:
> On Thu, 13 Feb 2020 at 21:00, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 5.5.4 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat, 15 Feb 2020 15:16:41 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >         https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.4-rc1.gz
> > or in the git tree and branch at:
> >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

Thanks for testing all of tehse and letting me know.

greg k-h

^ permalink raw reply

* Re: linux-next: manual merge of the staging tree with the char-misc.current tree
From: Greg KH @ 2020-02-14 15:30 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Arnd Bergmann, Linux Next Mailing List, Linux Kernel Mailing List,
	Bartosz Golaszewski
In-Reply-To: <20200214105519.70a7f6a2@canb.auug.org.au>

On Fri, Feb 14, 2020 at 10:55:19AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   MAINTAINERS
> 
> between commit:
> 
>   95ba79e89c10 ("MAINTAINERS: remove unnecessary ':' characters")
> 
> from the char-misc.current tree and commit:
> 
>   caa6772db4c1 ("Staging: remove wusbcore and UWB from the kernel tree.")
> 
> from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc MAINTAINERS
> index a9a93de6223c,9a4c715d1e50..000000000000
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@@ -17118,12 -17089,7 +17113,7 @@@ S:	Maintaine
>   F:	drivers/usb/common/ulpi.c
>   F:	include/linux/ulpi/
>   
> - ULTRA-WIDEBAND (UWB) SUBSYSTEM
> - L:	devel@driverdev.osuosl.org
> - S:	Obsolete
> - F:	drivers/staging/uwb/
> - 
>  -UNICODE SUBSYSTEM:
>  +UNICODE SUBSYSTEM
>   M:	Gabriel Krisman Bertazi <krisman@collabora.com>
>   L:	linux-fsdevel@vger.kernel.org
>   S:	Supported

Thanks for this, I'll handle the merge issue when one of the branches
gets to Linus in a day or so.

greg k-h

^ permalink raw reply

* Re: [PATCH 5.5 000/120] 5.5.4-stable review
From: Greg Kroah-Hartman @ 2020-02-14 15:28 UTC (permalink / raw)
  To: Jon Hunter
  Cc: linux-kernel, torvalds, akpm, linux, shuah, patches,
	ben.hutchings, lkft-triage, stable, linux-tegra
In-Reply-To: <e49bd26e-560c-840e-7f21-ee040a783143@nvidia.com>

On Fri, Feb 14, 2020 at 10:27:39AM +0000, Jon Hunter wrote:
> 
> On 13/02/2020 15:19, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.5.4 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat, 15 Feb 2020 15:16:41 +0000.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.4-rc1.gz
> > or in the git tree and branch at:
> > 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> All tests are passing for Tegra ...
> 
> Test results for stable-v5.5:
>     13 builds:	13 pass, 0 fail
>     22 boots:	22 pass, 0 fail
>     40 tests:	40 pass, 0 fail
> 
> Linux version:	5.5.4-rc2-ged6d023a1817
> Boards tested:	tegra124-jetson-tk1, tegra186-p2771-0000,
>                 tegra194-p2972-0000, tegra20-ventana,
>                 tegra210-p2371-2180, tegra210-p3450-0000,
>                 tegra30-cardhu-a04
> 

Thanks for testing all of these and letting me know.

greg k-h

^ permalink raw reply

* Re: [PATCH v2 4/8] serial: core: Allow detach and attach serial device for console
From: Greg Kroah-Hartman @ 2020-02-14 16:28 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Jiri Slaby, linux-serial, Sebastian Andrzej Siewior,
	Tony Lindgren
In-Reply-To: <20200214114339.53897-5-andriy.shevchenko@linux.intel.com>

On Fri, Feb 14, 2020 at 01:43:35PM +0200, Andy Shevchenko wrote:
> In the future we would like to disable power management on the serial devices
> used as kernel consoles to avoid weird behaviour in some cases. However,
> disabling PM may prevent system to go to deep sleep states, which in its turn
> leads to the higher power consumption.
> 
> Tony Lindgren proposed a work around, i.e. allow user to detach such consoles
> to make PM working again. In case user wants to see what's going on, it also
> provides a mechanism to attach console back.
> 
> Link: https://lists.openwall.net/linux-kernel/2018/09/29/65
> Suggested-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  Documentation/ABI/testing/sysfs-tty |  7 ++++
>  drivers/tty/serial/serial_core.c    | 60 +++++++++++++++++++++++++++--
>  2 files changed, 63 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-tty b/Documentation/ABI/testing/sysfs-tty
> index 9eb3c2b6b040..e157130a6792 100644
> --- a/Documentation/ABI/testing/sysfs-tty
> +++ b/Documentation/ABI/testing/sysfs-tty
> @@ -154,3 +154,10 @@ Description:
>  		 device specification. For example, when user sets 7bytes on
>  		 16550A, which has 1/4/8/14 bytes trigger, the RX trigger is
>  		 automatically changed to 4 bytes.
> +
> +What:		/sys/class/tty/ttyS0/console
> +Date:		February 2020
> +Contact:	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> +Description:
> +		 Allows user to detach or attach back the given device as
> +		 kernel console. It shows and accepts a boolean variable.
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 7564bbd3061c..0415bb76efa0 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -1919,7 +1919,7 @@ static inline bool uart_console_enabled(struct uart_port *port)
>   */
>  static inline void uart_port_spin_lock_init(struct uart_port *port)
>  {
> -	if (uart_console_enabled(port))
> +	if (uart_console(port))
>  		return;
>  
>  	spin_lock_init(&port->lock);
> @@ -2749,6 +2749,56 @@ static ssize_t uart_get_attr_iomem_reg_shift(struct device *dev,
>  	return snprintf(buf, PAGE_SIZE, "%d\n", tmp.iomem_reg_shift);
>  }
>  
> +static ssize_t uart_get_attr_console(struct device *dev,
> +	struct device_attribute *attr, char *buf)
> +{
> +	struct tty_port *port = dev_get_drvdata(dev);
> +	struct uart_state *state = container_of(port, struct uart_state, port);
> +	struct uart_port *uport;
> +	bool console = false;
> +
> +	mutex_lock(&port->mutex);
> +	uport = uart_port_check(state);
> +	if (uport)
> +		console = uart_console_enabled(uport);
> +	mutex_unlock(&port->mutex);
> +
> +	return sprintf(buf, "%c\n", console ? 'Y' : 'N');
> +}
> +
> +static ssize_t uart_set_attr_console(struct device *dev,
> +	struct device_attribute *attr, const char *buf, size_t count)
> +{
> +	struct tty_port *port = dev_get_drvdata(dev);
> +	struct uart_state *state = container_of(port, struct uart_state, port);
> +	struct uart_port *uport;
> +	bool oldconsole, newconsole;
> +	int ret;
> +
> +	ret = kstrtobool(buf, &newconsole);
> +	if (ret)
> +		return ret;
> +
> +	mutex_lock(&port->mutex);
> +	uport = uart_port_check(state);
> +	if (uport) {
> +		oldconsole = uart_console_enabled(uport);
> +		if (oldconsole && !newconsole) {
> +			ret = unregister_console(uport->cons);
> +		} else if (!oldconsole && newconsole) {
> +			if (uart_console(uport))
> +				register_console(uport->cons);
> +			else
> +				ret = -ENOENT;
> +		}
> +	} else {
> +		ret = -ENXIO;
> +	}
> +	mutex_unlock(&port->mutex);
> +
> +	return ret < 0 ? ret : count;
> +}
> +
>  static DEVICE_ATTR(type, 0440, uart_get_attr_type, NULL);
>  static DEVICE_ATTR(line, 0440, uart_get_attr_line, NULL);
>  static DEVICE_ATTR(port, 0440, uart_get_attr_port, NULL);
> @@ -2762,6 +2812,7 @@ static DEVICE_ATTR(custom_divisor, 0440, uart_get_attr_custom_divisor, NULL);
>  static DEVICE_ATTR(io_type, 0440, uart_get_attr_io_type, NULL);
>  static DEVICE_ATTR(iomem_base, 0440, uart_get_attr_iomem_base, NULL);
>  static DEVICE_ATTR(iomem_reg_shift, 0440, uart_get_attr_iomem_reg_shift, NULL);
> +static DEVICE_ATTR(console, 0640, uart_get_attr_console, uart_set_attr_console);

Again, DEVICE_ATTR_RW() in the future?

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH v2 3/8] serial: core: use octal permissions on module param
From: Greg Kroah-Hartman @ 2020-02-14 16:27 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Jiri Slaby, linux-serial, Sebastian Andrzej Siewior,
	Tony Lindgren
In-Reply-To: <20200214114339.53897-4-andriy.shevchenko@linux.intel.com>

On Fri, Feb 14, 2020 at 01:43:34PM +0200, Andy Shevchenko wrote:
> Symbolic permissions 'S_IRUSR | S_IRGRP' are not preferred.
> Use octal permissions '0440'. This also makes code shorter.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  drivers/tty/serial/serial_core.c | 26 +++++++++++++-------------
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index bb2287048108..7564bbd3061c 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -2749,19 +2749,19 @@ static ssize_t uart_get_attr_iomem_reg_shift(struct device *dev,
>  	return snprintf(buf, PAGE_SIZE, "%d\n", tmp.iomem_reg_shift);
>  }
>  
> -static DEVICE_ATTR(type, S_IRUSR | S_IRGRP, uart_get_attr_type, NULL);
> -static DEVICE_ATTR(line, S_IRUSR | S_IRGRP, uart_get_attr_line, NULL);
> -static DEVICE_ATTR(port, S_IRUSR | S_IRGRP, uart_get_attr_port, NULL);
> -static DEVICE_ATTR(irq, S_IRUSR | S_IRGRP, uart_get_attr_irq, NULL);
> -static DEVICE_ATTR(flags, S_IRUSR | S_IRGRP, uart_get_attr_flags, NULL);
> -static DEVICE_ATTR(xmit_fifo_size, S_IRUSR | S_IRGRP, uart_get_attr_xmit_fifo_size, NULL);
> -static DEVICE_ATTR(uartclk, S_IRUSR | S_IRGRP, uart_get_attr_uartclk, NULL);
> -static DEVICE_ATTR(close_delay, S_IRUSR | S_IRGRP, uart_get_attr_close_delay, NULL);
> -static DEVICE_ATTR(closing_wait, S_IRUSR | S_IRGRP, uart_get_attr_closing_wait, NULL);
> -static DEVICE_ATTR(custom_divisor, S_IRUSR | S_IRGRP, uart_get_attr_custom_divisor, NULL);
> -static DEVICE_ATTR(io_type, S_IRUSR | S_IRGRP, uart_get_attr_io_type, NULL);
> -static DEVICE_ATTR(iomem_base, S_IRUSR | S_IRGRP, uart_get_attr_iomem_base, NULL);
> -static DEVICE_ATTR(iomem_reg_shift, S_IRUSR | S_IRGRP, uart_get_attr_iomem_reg_shift, NULL);
> +static DEVICE_ATTR(type, 0440, uart_get_attr_type, NULL);
> +static DEVICE_ATTR(line, 0440, uart_get_attr_line, NULL);
> +static DEVICE_ATTR(port, 0440, uart_get_attr_port, NULL);
> +static DEVICE_ATTR(irq, 0440, uart_get_attr_irq, NULL);
> +static DEVICE_ATTR(flags, 0440, uart_get_attr_flags, NULL);
> +static DEVICE_ATTR(xmit_fifo_size, 0440, uart_get_attr_xmit_fifo_size, NULL);
> +static DEVICE_ATTR(uartclk, 0440, uart_get_attr_uartclk, NULL);
> +static DEVICE_ATTR(close_delay, 0440, uart_get_attr_close_delay, NULL);
> +static DEVICE_ATTR(closing_wait, 0440, uart_get_attr_closing_wait, NULL);
> +static DEVICE_ATTR(custom_divisor, 0440, uart_get_attr_custom_divisor, NULL);
> +static DEVICE_ATTR(io_type, 0440, uart_get_attr_io_type, NULL);
> +static DEVICE_ATTR(iomem_base, 0440, uart_get_attr_iomem_base, NULL);
> +static DEVICE_ATTR(iomem_reg_shift, 0440, uart_get_attr_iomem_reg_shift, NULL);

I'll take these, but we should move them all to DEVICE_ATTR_RO() as that
would make things a lot more "obvious" what is happening here.

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH v2 6/8] serial: 8250_port: Disable DMA operations for kernel console
From: Greg Kroah-Hartman @ 2020-02-14 16:30 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Jiri Slaby, linux-serial, Sebastian Andrzej Siewior,
	Tony Lindgren
In-Reply-To: <20200214114339.53897-7-andriy.shevchenko@linux.intel.com>

On Fri, Feb 14, 2020 at 01:43:37PM +0200, Andy Shevchenko wrote:
> It would be too tricky and error prone to allow DMA operations on
> kernel console.
> 
> One of the concern is when DMA is a separate device, for example on
> Intel CherryTrail platforms, and might need special work around to be
> functional, see the commit
> 
>   eebb3e8d8aaf ("ACPI / LPSS: override power state for LPSS DMA device")
> 
> for more information.
> 
> Another one is that kernel console is used in atomic context, e.g.
> when printing crucial information to the user (Oops or crash),
> and DMA may not serve due to power management complications
> including non-atomic ACPI calls but not limited to it (see above).
> 
> Besides that, other concerns are described in the commit
> 
>   84b40e3b57ee ("serial: 8250: omap: Disable DMA for console UART")
> 
> done for OMAP UART and may be repeated here.
> 
> Disable any kind of DMA operations on kernel console due to above concerns.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  drivers/tty/serial/8250/8250_port.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index 6307a04c0cd9..8ed22aa31add 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -2294,10 +2294,14 @@ int serial8250_do_startup(struct uart_port *port)
>  	 * Request DMA channels for both RX and TX.
>  	 */
>  	if (up->dma) {
> -		retval = serial8250_request_dma(up);
> -		if (retval) {
> -			pr_warn_ratelimited("%s - failed to request DMA\n",
> -					    port->name);
> +		const char *msg = NULL;
> +
> +		if (uart_console(port))
> +			msg = "forbid DMA for kernel console";
> +		else if (serial8250_request_dma(up))
> +			msg = "failed to request DMA";
> +		if (msg) {
> +			pr_warn_ratelimited("%s - %s\n", port->name, msg);

dev_warn_ratelimited()?  You have a port, you should use it.

thanks,

greg k-h

^ permalink raw reply

* [igt-dev] ✗ Fi.CI.BAT: failure for i915/gem_ctx_engines: Exercise 0 engines[]
From: Patchwork @ 2020-02-14 20:02 UTC (permalink / raw)
  To: Chris Wilson; +Cc: igt-dev
In-Reply-To: <20200214192327.4002875-1-chris@chris-wilson.co.uk>

== Series Details ==

Series: i915/gem_ctx_engines: Exercise 0 engines[]
URL   : https://patchwork.freedesktop.org/series/73484/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7942 -> IGTPW_4156
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with IGTPW_4156 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_4156, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4156/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in IGTPW_4156:

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live_execlists:
    - fi-kbl-guc:         [PASS][1] -> [DMESG-FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-kbl-guc/igt@i915_selftest@live_execlists.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4156/fi-kbl-guc/igt@i915_selftest@live_execlists.html

  
Known issues
------------

  Here are the changes found in IGTPW_4156 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_close_race@basic-threads:
    - fi-byt-n2820:       [PASS][3] -> [INCOMPLETE][4] ([i915#45])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-byt-n2820/igt@gem_close_race@basic-threads.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4156/fi-byt-n2820/igt@gem_close_race@basic-threads.html

  * igt@i915_selftest@live_gem_contexts:
    - fi-cml-s:           [PASS][5] -> [DMESG-FAIL][6] ([i915#877])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4156/fi-cml-s/igt@i915_selftest@live_gem_contexts.html

  
#### Possible fixes ####

  * igt@gem_exec_suspend@basic-s0:
    - {fi-ehl-1}:         [INCOMPLETE][7] ([i915#937]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-ehl-1/igt@gem_exec_suspend@basic-s0.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4156/fi-ehl-1/igt@gem_exec_suspend@basic-s0.html

  * igt@i915_selftest@live_gem_contexts:
    - fi-cfl-8700k:       [INCOMPLETE][9] ([i915#424]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4156/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
  [i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
  [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (47 -> 41)
------------------------------

  Additional (3): fi-bsw-kefka fi-blb-e6850 fi-cfl-8109u 
  Missing    (9): fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 fi-ivb-3770 fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * IGT: IGT_5442 -> IGTPW_4156

  CI-20190529: 20190529
  CI_DRM_7942: f4805f5a516d0a107438ff0f236c9f4187434819 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_4156: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4156/index.html
  IGT_5442: 3f6080996885b997685f08ecb8b416b2dc485290 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools



== Testlist changes ==

+igt@gem_ctx_engines@none

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4156/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply

* Re: [PATCH v2 1/2] staging: exfat: remove DOSNAMEs.
From: Greg Kroah-Hartman @ 2020-02-14 16:18 UTC (permalink / raw)
  To: Tetsuhiro Kohada
  Cc: Valdis Kletnieks, linux-fsdevel, devel, linux-kernel,
	Mori.Takahiro, motai.hirotaka
In-Reply-To: <20200214033140.72339-1-Kohada.Tetsuhiro@dc.MitsubishiElectric.co.jp>

On Fri, Feb 14, 2020 at 12:31:39PM +0900, Tetsuhiro Kohada wrote:
> remove 'dos_name','ShortName' and related definitions.
> 
> 'dos_name' and 'ShortName' are definitions before VFAT.
> These are never used in exFAT.
> 
> Signed-off-by: Tetsuhiro Kohada <Kohada.Tetsuhiro@dc.MitsubishiElectric.co.jp>
> ---
> Changes in v2:
> - Rebase to linux-next-next-20200213.

I think you might need to rebase again, this patch doesn't apply at all
to my tree :(

sorry,

greg k-h

^ permalink raw reply

* Re: [PATCH 5.4 00/96] 5.4.20-stable review
From: Greg Kroah-Hartman @ 2020-02-14 15:23 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Guenter Roeck, Linux Kernel Mailing List,
	torvalds@linux-foundation.org, Andrew Morton, Shuah Khan, patches,
	Ben Hutchings, lkft-triage, stable
In-Reply-To: <CAMuHMdV0nRPVjRpvVuZBMpaTfQGeMQN-2xrSehDwXOoG=4iATw@mail.gmail.com>

On Fri, Feb 14, 2020 at 08:55:48AM +0100, Geert Uytterhoeven wrote:
> Hi Günter,
> 
> On Thu, Feb 13, 2020 at 11:28 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > On Thu, Feb 13, 2020 at 07:20:07AM -0800, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 5.4.20 release.
> > > There are 96 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Sat, 15 Feb 2020 15:16:40 +0000.
> > > Anything received after that time might be too late.
> > >
> >
> > Build reference: v5.4.19-98-gdfae536f94c2
> > gcc version: powerpc64-linux-gcc (GCC) 9.2.0
> >
> > Building powerpc:defconfig ... failed
> > --------------
> > Error log:
> > drivers/rtc/rtc-ds1307.c:1570:21: error: variable 'regmap_config' has initializer but incomplete type
> >  1570 | static const struct regmap_config regmap_config = {
> >
> > Bisect log below. Looks like the the definition of "not needed"
> > needs an update.
> 
> "not needed" goes together with (or after) "when necessary":
> 578c2b661e2b1b47 ("rtc: Kconfig: select REGMAP_I2C when necessary")

Thanks for that, I'll consider it for the next round of releases.

greg k-h

^ permalink raw reply

* [PATCH] USB: misc: iowarrior: add support for the 100 device
From: Greg Kroah-Hartman @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-usb; +Cc: Christoph Jung

Add a new device id for the 100 devie.  It has 4 interfaces like the 28
and 28L devices but a larger endpoint so more I/O pins.

Cc: Christoph Jung <jung@codemercs.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/usb/misc/iowarrior.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c
index d20b60acfe8a..dce20301e367 100644
--- a/drivers/usb/misc/iowarrior.c
+++ b/drivers/usb/misc/iowarrior.c
@@ -36,6 +36,7 @@
 /* fuller speed iowarrior */
 #define USB_DEVICE_ID_CODEMERCS_IOW28	0x1504
 #define USB_DEVICE_ID_CODEMERCS_IOW28L	0x1505
+#define USB_DEVICE_ID_CODEMERCS_IOW100	0x1506
 
 /* OEMed devices */
 #define USB_DEVICE_ID_CODEMERCS_IOW24SAG	0x158a
@@ -144,6 +145,7 @@ static const struct usb_device_id iowarrior_ids[] = {
 	{USB_DEVICE(USB_VENDOR_ID_CODEMERCS, USB_DEVICE_ID_CODEMERCS_IOW56AM)},
 	{USB_DEVICE(USB_VENDOR_ID_CODEMERCS, USB_DEVICE_ID_CODEMERCS_IOW28)},
 	{USB_DEVICE(USB_VENDOR_ID_CODEMERCS, USB_DEVICE_ID_CODEMERCS_IOW28L)},
+	{USB_DEVICE(USB_VENDOR_ID_CODEMERCS, USB_DEVICE_ID_CODEMERCS_IOW100)},
 	{}			/* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, iowarrior_ids);
@@ -386,6 +388,7 @@ static ssize_t iowarrior_write(struct file *file,
 	case USB_DEVICE_ID_CODEMERCS_IOW56AM:
 	case USB_DEVICE_ID_CODEMERCS_IOW28:
 	case USB_DEVICE_ID_CODEMERCS_IOW28L:
+	case USB_DEVICE_ID_CODEMERCS_IOW100:
 		/* The IOW56 uses asynchronous IO and more urbs */
 		if (atomic_read(&dev->write_busy) == MAX_WRITES_IN_FLIGHT) {
 			/* Wait until we are below the limit for submitted urbs */
@@ -786,7 +789,8 @@ static int iowarrior_probe(struct usb_interface *interface,
 	if ((dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW56) ||
 	    (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW56AM) ||
 	    (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW28) ||
-	    (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW28L)) {
+	    (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW28L) ||
+	    (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW100)) {
 		res = usb_find_last_int_out_endpoint(iface_desc,
 				&dev->int_out_endpoint);
 		if (res) {
@@ -802,7 +806,8 @@ static int iowarrior_probe(struct usb_interface *interface,
 	    ((dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW56) ||
 	     (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW56AM) ||
 	     (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW28) ||
-	     (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW28L)))
+	     (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW28L) ||
+	     (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW100)))
 		/* IOWarrior56 has wMaxPacketSize different from report size */
 		dev->report_size = 7;
 

base-commit: bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9
prerequisite-patch-id: de0eb78ec316f2890ad7f235832eafb221b2d9b1
prerequisite-patch-id: 4fb8fac9e49d2dad489f45c00d4d5e469e72e752
-- 
2.25.0


^ permalink raw reply related

* Re: [PATCH 5.5 000/120] 5.5.4-stable review
From: Greg Kroah-Hartman @ 2020-02-14 15:22 UTC (permalink / raw)
  To: shuah
  Cc: linux-kernel, torvalds, akpm, linux, patches, ben.hutchings,
	lkft-triage, stable
In-Reply-To: <ac7421a1-63d0-3a81-f049-0be6a3bc4db0@kernel.org>

On Thu, Feb 13, 2020 at 05:40:48PM -0700, shuah wrote:
> On 2/13/20 8:19 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.5.4 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat, 15 Feb 2020 15:16:41 +0000.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.4-rc1.gz
> > or in the git tree and branch at:
> > 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

^ permalink raw reply

* Re: [PATCH 4.19 091/195] padata: Remove broken queue flushing
From: Greg Kroah-Hartman @ 2020-02-14 15:21 UTC (permalink / raw)
  To: Yang Yingliang
  Cc: linux-kernel, stable, Herbert Xu, Daniel Jordan, Sasha Levin
In-Reply-To: <5E4674BB.4020900@huawei.com>

On Fri, Feb 14, 2020 at 06:21:47PM +0800, Yang Yingliang wrote:
> Hi,
> 
> On 2020/2/10 20:32, Greg Kroah-Hartman wrote:
> > From: Herbert Xu <herbert@gondor.apana.org.au>
> > 
> > [ Upstream commit 07928d9bfc81640bab36f5190e8725894d93b659 ]
> > 
> > The function padata_flush_queues is fundamentally broken because
> > it cannot force padata users to complete the request that is
> > underway.  IOW padata has to passively wait for the completion
> > of any outstanding work.
> > 
> > As it stands flushing is used in two places.  Its use in padata_stop
> > is simply unnecessary because nothing depends on the queues to
> > be flushed afterwards.
> > 
> > The other use in padata_replace is more substantial as we depend
> > on it to free the old pd structure.  This patch instead uses the
> > pd->refcnt to dynamically free the pd structure once all requests
> > are complete.
> > 
> > Fixes: 2b73b07ab8a4 ("padata: Flush the padata queues actively")
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> > Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > ---
> >   kernel/padata.c | 46 ++++++++++++----------------------------------
> >   1 file changed, 12 insertions(+), 34 deletions(-)
> > 
> > diff --git a/kernel/padata.c b/kernel/padata.c
> > index 6c06b3039faed..11c5f9c8779ea 100644
> > --- a/kernel/padata.c
> > +++ b/kernel/padata.c
> > @@ -35,6 +35,8 @@
> >   #define MAX_OBJ_NUM 1000
> > +static void padata_free_pd(struct parallel_data *pd);
> > +
> >   static int padata_index_to_cpu(struct parallel_data *pd, int cpu_index)
> >   {
> >   	int cpu, target_cpu;
> > @@ -334,6 +336,7 @@ static void padata_serial_worker(struct work_struct *serial_work)
> >   	struct padata_serial_queue *squeue;
> >   	struct parallel_data *pd;
> >   	LIST_HEAD(local_list);
> > +	int cnt;
> >   	local_bh_disable();
> >   	squeue = container_of(serial_work, struct padata_serial_queue, work);
> > @@ -343,6 +346,8 @@ static void padata_serial_worker(struct work_struct *serial_work)
> >   	list_replace_init(&squeue->serial.list, &local_list);
> >   	spin_unlock(&squeue->serial.lock);
> > +	cnt = 0;
> > +
> >   	while (!list_empty(&local_list)) {
> >   		struct padata_priv *padata;
> > @@ -352,9 +357,12 @@ static void padata_serial_worker(struct work_struct *serial_work)
> >   		list_del_init(&padata->list);
> >   		padata->serial(padata);
> > -		atomic_dec(&pd->refcnt);
> > +		cnt++;
> >   	}
> >   	local_bh_enable();
> > +
> > +	if (atomic_sub_and_test(cnt, &pd->refcnt))
> > +		padata_free_pd(pd);
> >   }
> >   /**
> > @@ -501,8 +509,7 @@ static struct parallel_data *padata_alloc_pd(struct padata_instance *pinst,
> >   	timer_setup(&pd->timer, padata_reorder_timer, 0);
> >   	atomic_set(&pd->seq_nr, -1);
> >   	atomic_set(&pd->reorder_objects, 0);
> > -	atomic_set(&pd->refcnt, 0);
> > -	pd->pinst = pinst;
> This patch remove this assignment, it's cause a null-ptr-deref when using
> pd->pinst in padata_reorder().
> 
> [39135.886908] Unable to handle kernel NULL pointer dereference at virtual
> address 0000000000000010
> [39135.886909] Mem abort info:
> [39135.886910]   ESR = 0x96000004
> [39135.886912]   Exception class = DABT (current EL), IL = 32 bits
> [39135.886913]   SET = 0, FnV = 0
> [39135.886913]   EA = 0, S1PTW = 0
> [39135.886914] Data abort info:
> [39135.886915]   ISV = 0, ISS = 0x00000004
> [39135.886915]   CM = 0, WnR = 0
> [39135.886918] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000c66d7ef5
> [39135.886919] [0000000000000010] pgd=0000000000000000
> [39135.886922] Internal error: Oops: 96000004 [#1] SMP
> [39135.897190] Modules linked in: authenc pcrypt crypto_user cfg80211 rfkill
> ib_isert iscsi_target_mod ib_srpt target_core_mod dm_mirror dm_region_hash
> rpcrdma dm_log ib_srp scsi_transport_srp sunrpc dm_mod ib_ipoib rdma_ucm
> ib_uverbs ib_umad ib_iser rdma_cm ib_cm iw_cm aes_ce_blk crypto_simd cryptd
> aes_ce_cipher hns_roce_hw_v2 ghash_ce sha2_ce sha256_arm64 hns_roce ib_core
> sha1_ce sbsa_gwdt hi_sfc sg mtd ipmi_ssif sch_fq_codel ip_tables realtek
> hclge hinic hns3 ipmi_si hisi_sas_v3_hw hibmc_drm hnae3 hisi_sas_main
> ipmi_devintf ipmi_msghandler
> [39135.997870] Process kworker/0:2 (pid: 789, stack limit =
> 0x0000000047f55ba6)
> [39136.012707] CPU: 0 PID: 789 Comm: kworker/0:2 Kdump: loaded Not tainted
> 4.19.103+ #1
> [39136.029010] Hardware name: Huawei TaiShan 2280 V2/BC82AMDD, BIOS 1.08
> 12/14/2019
> [39136.044587] Workqueue: pencrypt padata_parallel_worker
> [39136.055396] pstate: 00c00009 (nzcv daif +PAN +UAO)
> [39136.065479] pc : padata_reorder+0x144/0x2e0
> [39136.074274] lr : padata_reorder+0x124/0x2e0
> [39136.083070] sp : ffff0000149cbc90
> [39136.090036] x29: ffff0000149cbc90 x28: 0000000000000001
> [39136.101215] x27: ffffa02fd14af080 x26: ffffa02fd5fe1600
> [39136.112392] x25: ffff5df7bf4c0ac8 x24: ffffa02fd5fe1628
> [39136.123569] x23: 0000000000000000 x22: ffff00000828a258
> [39136.134747] x21: ffffa02fd5fe1618 x20: ffff000009a79788
> [39136.145924] x19: ffff5df7bf4c0ac8 x18: 00000000bef9a3f7
> [39136.157102] x17: 0000000066bb7710 x16: 000000009a34db62
> [39136.168280] x15: 0000000000342311 x14: 0000000037c9c538
> [39136.179458] x13: 00000000deb82818 x12: 000000007abb6477
> [39136.190638] x11: 000000006e0b05e5 x10: 00000000ccde2d6a
> [39136.201817] x9 : 0000000000000000 x8 : a544a826aa446d6a
> [39136.212996] x7 : e5050b6ea3a6345c x6 : ffffa02fd74ef030
> [39136.224174] x5 : 0000000000000010 x4 : ffff5df7bf4c0ac8
> [39136.235354] x3 : ffff5df7bf4c0ad8 x2 : ffff5df7bf4c0ac8
> [39136.246532] x1 : ffff5df7bf4c0ad8 x0 : 0000000000000000
> [39136.257712] Call trace:
> [39136.262851]  padata_reorder+0x144/0x2e0
> [39136.270922]  padata_do_serial+0xc8/0x128
> [39136.279177]  pcrypt_aead_enc+0x60/0x70 [pcrypt]
> [39136.288708]  padata_parallel_worker+0xd8/0x138
> [39136.298056]  process_one_work+0x1bc/0x4b8
> [39136.306489]  worker_thread+0x164/0x580
> [39136.314374]  kthread+0x134/0x138
> [39136.321163]  ret_from_fork+0x10/0x18
> [39136.328681] Code: f900033b 52800000 91004261 089ffc20 (f9400ae1)
> [39136.341508] ---[ end trace fc1b4f00385f0fee ]---
> [39136.351221] Kernel panic - not syncing: Fatal exception in interrupt
> [39136.364591] SMP: stopping secondary CPUs
> [39136.372863] Kernel Offset: disabled
> [39138.438722] CPU features: 0x12,a2200a38
> [39138.446797] Memory Limit: none
> [39138.463025] Starting crashdump kernel...
> [39138.471295] Bye!

So this causes a problem in the 4.19-rc tree but not in Linus's tree?
Or am I confused?  Should it be dropped from stable or is there some
other fix-of-a-fix that I need to apply here?

thanks,

greg k-h

^ permalink raw reply

* Re: 4.14+ doesn't work on only board with open-source BIOS & without Spectre bugs
From: Greg KH @ 2020-02-14 15:19 UTC (permalink / raw)
  To: cipher-hearts; +Cc: stable, linux-kernel
In-Reply-To: <20200214100655.pyljxoa5pkhagbct@localhost.0.0.1>

On Fri, Feb 14, 2020 at 10:06:55AM +0000, cipher-hearts@riseup.net wrote:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=206257
> 
> Any suggestions?

Can you run 'git bisect' to find the problem commit?

thanks,

greg k-h

^ permalink raw reply

* Re: [Intel-gfx] [PATCH 19/19] drm/i915: Use ww pinning for intel_context_create_request()
From: Ruhl, Michael J @ 2020-02-14 20:01 UTC (permalink / raw)
  To: Maarten Lankhorst, intel-gfx@lists.freedesktop.org
In-Reply-To: <20200214103055.2117836-20-maarten.lankhorst@linux.intel.com>

>-----Original Message-----
>From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of
>Maarten Lankhorst
>Sent: Friday, February 14, 2020 5:31 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 19/19] drm/i915: Use ww pinning for
>intel_context_create_request()
>
>We want to get rid of intel_context_pin(), convert
>intel_context_create_request() first. :)
>
>Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>---
> drivers/gpu/drm/i915/gt/intel_context.c | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
>b/drivers/gpu/drm/i915/gt/intel_context.c
>index 87f9f9e61916..44868b10be0a 100644
>--- a/drivers/gpu/drm/i915/gt/intel_context.c
>+++ b/drivers/gpu/drm/i915/gt/intel_context.c
>@@ -436,15 +436,25 @@ int intel_context_prepare_remote_request(struct
>intel_context *ce,
>
> struct i915_request *intel_context_create_request(struct intel_context *ce)
> {
>+	struct i915_gem_ww_ctx ww;
> 	struct i915_request *rq;
> 	int err;
>
>-	err = intel_context_pin(ce);
>-	if (unlikely(err))
>-		return ERR_PTR(err);
>+	i915_gem_ww_ctx_init(&ww, true);
>+retry:
>+	err = intel_context_pin_ww(ce, &ww);
>+	if (!err) {
>+		rq = i915_request_create(ce);
>+		intel_context_unpin(ce);
>+	} else if (err == -EDEADLK) {
>+		err = i915_gem_ww_ctx_backoff(&ww);
>+		if (!err)
>+			goto retry;
>+	} else {
>+		rq = ERR_PTR(err);
>+	}

If you have the pathological path:

err = intel_context_pin_ww(cd, &&))
	else if (err == -EDEADLK)
		err = i915_gem_ww_ctx_backoff(&ww) ; (where err != 0)

It appears that you can get to IS_ERR(rq) with rq being garbage from the
stack.

Do you need to preset rq, or set it on: 

if (!err)
	goto retry;
else
	rq = ERR_PTR(err);

?

Thanks,

Mike


>
>-	rq = i915_request_create(ce);
>-	intel_context_unpin(ce);
>+	i915_gem_ww_ctx_fini(&ww);
>
> 	if (IS_ERR(rq))
> 		return rq;
>--
>2.25.0.24.g3f081b084b0
>
>_______________________________________________
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* Re: [PATCH] x86/mce/amd: Fix kobject lifetime
From: Greg KH @ 2020-02-14 15:17 UTC (permalink / raw)
  To: Borislav Petkov; +Cc: stable, X86 ML, Yazen Ghannam, LKML
In-Reply-To: <20200214083230.GA13395@zn.tnic>

On Fri, Feb 14, 2020 at 09:32:30AM +0100, Borislav Petkov wrote:
> On Fri, Feb 14, 2020 at 09:28:01AM +0100, Borislav Petkov wrote:
> > From: Thomas Gleixner <tglx@linutronix.de>
> > 
> > Accessing the MCA thresholding controls in sysfs concurrently with CPU
> > hotplug can lead to a couple of KASAN-reported issues:
> > 
> >   BUG: KASAN: use-after-free in sysfs_file_ops+0x155/0x180
> >   Read of size 8 at addr ffff888367578940 by task grep/4019
> > 
> > and
> > 
> >   BUG: KASAN: use-after-free in show_error_count+0x15c/0x180
> >   Read of size 2 at addr ffff888368a05514 by task grep/4454
> > 
> > for example. Both result from the fact that the threshold block
> > creation/teardown code frees the descriptor memory itself instead of
> > defining proper ->release function and leaving it to the driver core to
> > take care of that, after all sysfs accesses have completed.
> > 
> > Do that and get rid of the custom freeing code, fixing the above UAFs in
> > the process.
> > 
> >   [ bp: write commit message. ]
> > 
> > Fixes: 95268664390b ("[PATCH] x86_64: mce_amd support for family 0x10 processors")
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Signed-off-by: Borislav Petkov <bp@suse.de>
> > Cc: <stable@vger.kernel.org>
> 
> Damn git-send-email: it read out Cc: stable and added it to the Cc list.
> I've added
> 
> suppresscc = bodycc
> 
> to my .gitconfig.
> 
> Sorry stable guys.

Does not bother me at all, it's fine to see stuff come by that will end
up in future trees, it's not noise at all.  So no need to suppress
stable@vger if you don't want to.

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH 06/35] s390/mm: add (non)secure page access exceptions handlers
From: Christian Borntraeger @ 2020-02-14 19:59 UTC (permalink / raw)
  To: David Hildenbrand, Janosch Frank
  Cc: KVM, Cornelia Huck, Thomas Huth, Ulrich Weigand, Claudio Imbrenda,
	Andrea Arcangeli, linux-s390, Michael Mueller, Vasily Gorbik,
	linux-mm, Andrew Morton, Janosch Frank
In-Reply-To: <c05f8672-dc29-271a-66d2-73138406cf21@redhat.com>



On 14.02.20 19:05, David Hildenbrand wrote:
> On 07.02.20 12:39, Christian Borntraeger wrote:
>> From: Vasily Gorbik <gor@linux.ibm.com>
>>
>> Add exceptions handlers performing transparent transition of non-secure
>> pages to secure (import) upon guest access and secure pages to
>> non-secure (export) upon hypervisor access.
>>
>> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
>> [frankja@linux.ibm.com: adding checks for failures]
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> [imbrenda@linux.ibm.com:  adding a check for gmap fault]
>> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
>> [borntraeger@de.ibm.com: patch merging, splitting, fixing]
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  arch/s390/kernel/pgm_check.S |  4 +-
>>  arch/s390/mm/fault.c         | 86 ++++++++++++++++++++++++++++++++++++
>>  2 files changed, 88 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/s390/kernel/pgm_check.S b/arch/s390/kernel/pgm_check.S
>> index 59dee9d3bebf..27ac4f324c70 100644
>> --- a/arch/s390/kernel/pgm_check.S
>> +++ b/arch/s390/kernel/pgm_check.S
>> @@ -78,8 +78,8 @@ PGM_CHECK(do_dat_exception)		/* 39 */
>>  PGM_CHECK(do_dat_exception)		/* 3a */
>>  PGM_CHECK(do_dat_exception)		/* 3b */
>>  PGM_CHECK_DEFAULT			/* 3c */
>> -PGM_CHECK_DEFAULT			/* 3d */
>> -PGM_CHECK_DEFAULT			/* 3e */
>> +PGM_CHECK(do_secure_storage_access)	/* 3d */
>> +PGM_CHECK(do_non_secure_storage_access)	/* 3e */
>>  PGM_CHECK_DEFAULT			/* 3f */
>>  PGM_CHECK_DEFAULT			/* 40 */
>>  PGM_CHECK_DEFAULT			/* 41 */
>> diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
>> index 7b0bb475c166..fab4219fa0be 100644
>> --- a/arch/s390/mm/fault.c
>> +++ b/arch/s390/mm/fault.c
>> @@ -38,6 +38,7 @@
>>  #include <asm/irq.h>
>>  #include <asm/mmu_context.h>
>>  #include <asm/facility.h>
>> +#include <asm/uv.h>
>>  #include "../kernel/entry.h"
>>  
>>  #define __FAIL_ADDR_MASK -4096L
>> @@ -816,3 +817,88 @@ static int __init pfault_irq_init(void)
>>  early_initcall(pfault_irq_init);
>>  
>>  #endif /* CONFIG_PFAULT */
>> +
>> +#if IS_ENABLED(CONFIG_KVM)
>> +void do_secure_storage_access(struct pt_regs *regs)
>> +{
>> +	unsigned long addr = regs->int_parm_long & __FAIL_ADDR_MASK;
>> +	struct vm_area_struct *vma;
>> +	struct mm_struct *mm;
>> +	struct page *page;
>> +	int rc;
>> +
>> +	switch (get_fault_type(regs)) {
>> +	case USER_FAULT:
>> +		mm = current->mm;
>> +		down_read(&mm->mmap_sem);
>> +		vma = find_vma(mm, addr);
>> +		if (!vma) {
>> +			up_read(&mm->mmap_sem);
>> +			do_fault_error(regs, VM_READ | VM_WRITE, VM_FAULT_BADMAP);
>> +			break;
>> +		}
>> +		page = follow_page(vma, addr, FOLL_WRITE | FOLL_GET);
>> +		if (IS_ERR_OR_NULL(page)) {
>> +			up_read(&mm->mmap_sem);
>> +			break;
>> +		}
>> +		if (arch_make_page_accessible(page))
>> +			send_sig(SIGSEGV, current, 0);
>> +		put_page(page);
>> +		up_read(&mm->mmap_sem);
>> +		break;
>> +	case KERNEL_FAULT:
>> +		page = phys_to_page(addr);
>> +		if (unlikely(!try_get_page(page)))
>> +			break;
>> +		rc = arch_make_page_accessible(page);
>> +		put_page(page);
>> +		if (rc)
>> +			BUG();
>> +		break;
>> +	case VDSO_FAULT:
>> +		/* fallthrough */
>> +	case GMAP_FAULT:
>> +		/* fallthrough */
> 
> Could we ever get here from the SIE?

GMAP_FAULT is only set if we came from the sie critical section, so unless we have a bug no.

> 
>> +	default:
>> +		do_fault_error(regs, VM_READ | VM_WRITE, VM_FAULT_BADMAP);
>> +		WARN_ON_ONCE(1);
>> +	}
>> +}
>> +NOKPROBE_SYMBOL(do_secure_storage_access);
>> +
>> +void do_non_secure_storage_access(struct pt_regs *regs)
>> +{
>> +	unsigned long gaddr = regs->int_parm_long & __FAIL_ADDR_MASK;
>> +	struct gmap *gmap = (struct gmap *)S390_lowcore.gmap;
>> +	struct uv_cb_cts uvcb = {
>> +		.header.cmd = UVC_CMD_CONV_TO_SEC_STOR,
>> +		.header.len = sizeof(uvcb),
>> +		.guest_handle = gmap->guest_handle,
>> +		.gaddr = gaddr,
>> +	};
>> +	int rc;
>> +
>> +	if (get_fault_type(regs) != GMAP_FAULT) {
>> +		do_fault_error(regs, VM_READ | VM_WRITE, VM_FAULT_BADMAP);
>> +		WARN_ON_ONCE(1);
>> +		return;
>> +	}
>> +
>> +	rc = uv_make_secure(gmap, gaddr, &uvcb);
>> +	if (rc == -EINVAL && uvcb.header.rc != 0x104)
>> +		send_sig(SIGSEGV, current, 0);
> 
> 
> Looks good to me, but I don't feel like being ready for an r-b. I'll
> have to let that sink in :)
> 
> Assumed-is-okay-by: David Hildenbrand <david@redhat.com>
> 
> 

^ permalink raw reply

* Re: [PATCH 2/3] random: rng-seed source is utf-8
From: Rob Herring @ 2020-02-14 19:58 UTC (permalink / raw)
  To: Masami Hiramatsu
  Cc: linux-kernel@vger.kernel.org, Android Kernel Team, Mark Salyzyn,
	Theodore Ts'o, Arnd Bergmann, Greg Kroah-Hartman,
	Richard Henderson, Mark Brown, Kees Cook, Hsin-Yi Wang,
	Vasily Gorbik, Andrew Morton, Steven Rostedt, Mike Rapoport,
	Arvind Sankar, Dominik Brodowski, Thomas Gleixner,
	Alexander Potapenko, Jonathan Corbet, Mauro Carvalho Chehab,
	Josh Poimboeuf, Pawan Gupta, Juergen Gross,
	Linux Doc Mailing List
In-Reply-To: <158166062748.9887.15284887096084339722.stgit@devnote2>

On Fri, Feb 14, 2020 at 12:10 AM Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> From: Mark Salyzyn <salyzyn@android.com>
>
> commit 428826f5358c922dc378830a1717b682c0823160
> ("fdt: add support for rng-seed") makes the assumption that the data
> in rng-seed is binary, when it is typically constructed of utf-8

Typically? Why is that?

> characters which has a bitness of roughly 6 to give appropriate
> credit due for the entropy.

^ permalink raw reply

* Re: [Letux-kernel] [PATCH v2] net: davicom: dm9000: allow to pass MAC address through mac_addr module parameter
From: Paul Cercueil @ 2020-02-14 19:57 UTC (permalink / raw)
  To: H. Nikolaus Schaller
  Cc: Discussions about the Letux Kernel, Andrew Lunn, netdev,
	linux-kernel, David S. Miller, Richard Fontana, kernel,
	Petr Štetiar, Thomas Gleixner, Heiner Kallweit
In-Reply-To: <A686A3C7-09A4-4654-A265-2BDBEF41A7C4@goldelico.com>



Le ven., févr. 14, 2020 at 20:38, H. Nikolaus Schaller 
<hns@goldelico.com> a écrit :
>>  Am 14.02.2020 um 20:24 schrieb H. Nikolaus Schaller 
>> <hns@goldelico.com>:
>> 
>> 
>>>  Am 14.02.2020 um 19:47 schrieb Paul Cercueil 
>>> <paul@crapouillou.net>:
>>> 
>>>  Hi Nikolaus,
>>> 
>>>  What I'd suggest is to write a NVMEM driver for the efuse and 
>>> retrieve the MAC address cleanly with nvmem_get_mac_address().
>>> 
>>>  It shouldn't be hard to do (there's already code for it in the 
>>> non-upstream 3.18 kernel for the CI20) and you remove the 
>>> dependency on uboot.
>> 
>>  Interesting approach. I have found this:
>> 
>>  https://lore.kernel.org/patchwork/patch/868158/
>> 
>>  but it looks as if it was never finished (I could not locate a V3 
>> or anything mainline?)
>>  and and it tries to solve other problems as well.
>> 

Yes, I think it's a bit too complex - it's probably fine to just read 
chunks of 4 bytes.

>> 
>>  And it looks to be much more complex than my "solution" to the 
>> immediate problem.
>> 

Yes, a proper fix usually means more work ;)
>> 
>>  I have to study it to know if I can write a nvmem_get_mac_address().
> 
> Another question is how to link this very jz4780 specific code to the 
> generic davicom dm9000 driver?
> And where should the new code live. In some jz4780 specific file or 
> elsewhere?

In the dm9000's devicetree node you'd have a "mac-address = 
<&mac_addr>;". The "mac-address" is already a standard property, and 
the davicom driver already supports it.

The "mac_addr" should be a pointer to the efuse cell that corresponds 
to the MAC address. See the examples at the bottom of 
Documentation/devicetree/bindings/nvmem/nvmem.yaml and 
Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml.

-Paul

> 
>> 
>>  BR,
>>  Nikolaus
>> 
>>> 
>>>  -Paul
>>> 
>>> 
>>>  Le ven., févr. 14, 2020 at 17:07, H. Nikolaus Schaller 
>>> <hns@goldelico.com> a écrit :
>>>>  The MIPS Ingenic CI20 board is shipped with a quite old u-boot
>>>>  (ci20-v2013.10 see https://elinux.org/CI20_Dev_Zone). This passes
>>>>  the MAC address through dm9000.mac_addr=xx:xx:xx:xx:xx:xx
>>>>  kernel module parameter to give the board a fixed MAC address.
>>>>  This is not processed by the dm9000 driver which assigns a random
>>>>  MAC address on each boot, making DHCP assign a new IP address
>>>>  each time.
>>>>  So we add a check for the mac_addr module parameter as a last
>>>>  resort before assigning a random one. This mechanism can also
>>>>  be used outside of u-boot to provide a value through modprobe
>>>>  config.
>>>>  To parse the MAC address in a new function get_mac_addr() we
>>>>  use an copy adapted from the ksz884x.c driver which provides
>>>>  the same functionality.
>>>>  Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>>>  ---
>>>>  drivers/net/ethernet/davicom/dm9000.c | 42 
>>>> +++++++++++++++++++++++++++
>>>>  1 file changed, 42 insertions(+)
>>>>  diff --git a/drivers/net/ethernet/davicom/dm9000.c 
>>>> b/drivers/net/ethernet/davicom/dm9000.c
>>>>  index 1ea3372775e6..7402030b0352 100644
>>>>  --- a/drivers/net/ethernet/davicom/dm9000.c
>>>>  +++ b/drivers/net/ethernet/davicom/dm9000.c
>>>>  @@ -1409,6 +1409,43 @@ static struct dm9000_plat_data 
>>>> *dm9000_parse_dt(struct device *dev)
>>>>  	return pdata;
>>>>  }
>>>>  +static char *mac_addr = ":";
>>>>  +module_param(mac_addr, charp, 0);
>>>>  +MODULE_PARM_DESC(mac_addr, "MAC address");
>>>>  +
>>>>  +static void get_mac_addr(struct net_device *ndev, char *macaddr)
>>>>  +{
>>>>  +	int i = 0;
>>>>  +	int j = 0;
>>>>  +	int got_num = 0;
>>>>  +	int num = 0;
>>>>  +
>>>>  +	while (j < ETH_ALEN) {
>>>>  +		if (macaddr[i]) {
>>>>  +			int digit;
>>>>  +
>>>>  +			got_num = 1;
>>>>  +			digit = hex_to_bin(macaddr[i]);
>>>>  +			if (digit >= 0)
>>>>  +				num = num * 16 + digit;
>>>>  +			else if (':' == macaddr[i])
>>>>  +				got_num = 2;
>>>>  +			else
>>>>  +				break;
>>>>  +		} else if (got_num) {
>>>>  +			got_num = 2;
>>>>  +		} else {
>>>>  +			break;
>>>>  +		}
>>>>  +		if (got_num == 2) {
>>>>  +			ndev->dev_addr[j++] = (u8)num;
>>>>  +			num = 0;
>>>>  +			got_num = 0;
>>>>  +		}
>>>>  +		i++;
>>>>  +	}
>>>>  +}
>>>>  +
>>>>  /*
>>>>  * Search DM9000 board, allocate space and register it
>>>>  */
>>>>  @@ -1679,6 +1716,11 @@ dm9000_probe(struct platform_device *pdev)
>>>>  			ndev->dev_addr[i] = ior(db, i+DM9000_PAR);
>>>>  	}
>>>>  +	if (!is_valid_ether_addr(ndev->dev_addr)) {
>>>>  +		mac_src = "param";
>>>>  +		get_mac_addr(ndev, mac_addr);
>>>>  +	}
>>>>  +
>>>>  	if (!is_valid_ether_addr(ndev->dev_addr)) {
>>>>  		inv_mac_addr = true;
>>>>  		eth_hw_addr_random(ndev);
>>>>  --
>>>>  2.23.0
>>> 
>>> 
>> 
>>  _______________________________________________
>>  http://projects.goldelico.com/p/gta04-kernel/
>>  Letux-kernel mailing list
>>  Letux-kernel@openphoenux.org
>>  http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel



^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.