* Re: [PATCH v3 6/6] mm,thp: handle writes to file with THP in pagecache
From: Rik van Riel @ 2019-06-20 13:00 UTC (permalink / raw)
To: Song Liu
Cc: linux-mm@kvack.org, matthew.wilcox@oracle.com,
kirill.shutemov@linux.intel.com, Kernel Team,
william.kucharski@oracle.com, akpm@linux-foundation.org
In-Reply-To: <B051CE4A-063B-4464-8193-93C9F1D0A0A7@fb.com>
On Wed, 2019-06-19 at 22:10 -0400, Song Liu wrote:
> > On Jun 19, 2019, at 6:39 PM, Rik van Riel <riel@fb.com> wrote:
> >
> > On Tue, 2019-06-18 at 23:24 -0700, Song Liu wrote:
> >
> > > index 8563339041f6..bab8d9eef46c 100644
> > > --- a/mm/truncate.c
> > > +++ b/mm/truncate.c
> > > @@ -790,7 +790,11 @@ EXPORT_SYMBOL_GPL(invalidate_inode_pages2);
> > > void truncate_pagecache(struct inode *inode, loff_t newsize)
> > > {
> > > struct address_space *mapping = inode->i_mapping;
> > > - loff_t holebegin = round_up(newsize, PAGE_SIZE);
> > > + loff_t holebegin;
> > > +
> > > + /* if non-shmem file has thp, truncate the whole file */
> > > + if (filemap_nr_thps(mapping))
> > > + newsize = 0;
> > >
> >
> > I don't get it. Sometimes truncate is used to
> > increase the size of a file, or to change it
> > to a non-zero size.
> >
> > Won't forcing the newsize to zero break applications,
> > when the file is truncated to a different size than
> > they expect?
>
> This is not truncate the file. It only drops page cache.
> truncate_setsize() will still set correct size. I don't
> think this breaks anything.
Ahhh, indeed. Good point.
I wonder if the dropping of the page cache could be
done automatically from open(), if it determines that
there are no more readonly THP users of the file, and
the new opener wants to write to the file?
That magic could be in a helper function, so it would
be just a one line change in the same spot where it
currently denies the permission :)
> We can probably make it smarter and only drop the clean
> huge pages (dirty page should not exist).
^ permalink raw reply
* RE: [PATCH v1 9/9] smaples: add vfio-mdev-pci driver
From: Liu, Yi L @ 2019-06-20 13:00 UTC (permalink / raw)
To: Alex Williamson
Cc: kwankhede@nvidia.com, Tian, Kevin, baolu.lu@linux.intel.com,
Sun, Yi Y, joro@8bytes.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, Masahiro Yamada
In-Reply-To: <20190619222647.72efc76a@x1.home>
Hi Alex,
> From: Alex Williamson [mailto:alex.williamson@redhat.com]
> Sent: Thursday, June 20, 2019 12:27 PM
> To: Liu, Yi L <yi.l.liu@intel.com>
> Subject: Re: [PATCH v1 9/9] smaples: add vfio-mdev-pci driver
>
> On Sat, 8 Jun 2019 21:21:11 +0800
> Liu Yi L <yi.l.liu@intel.com> wrote:
>
> > This patch adds sample driver named vfio-mdev-pci. It is to wrap
> > a PCI device as a mediated device. For a pci device, once bound
> > to vfio-mdev-pci driver, user space access of this device will
> > go through vfio mdev framework. The usage of the device follows
> > mdev management method. e.g. user should create a mdev before
> > exposing the device to user-space.
> >
> > Benefit of this new driver would be acting as a sample driver
> > for recent changes from "vfio/mdev: IOMMU aware mediated device"
> > patchset. Also it could be a good experiment driver for future
> > device specific mdev migration support.
> >
> > To use this driver:
> > a) build and load vfio-mdev-pci.ko module
> > execute "make menuconfig" and config CONFIG_SAMPLE_VFIO_MDEV_PCI
> > then load it with following command
> > > sudo modprobe vfio
> > > sudo modprobe vfio-pci
> > > sudo insmod drivers/vfio/pci/vfio-mdev-pci.ko
> >
> > b) unbind original device driver
> > e.g. use following command to unbind its original driver
> > > echo $dev_bdf > /sys/bus/pci/devices/$dev_bdf/driver/unbind
> >
> > c) bind vfio-mdev-pci driver to the physical device
> > > echo $vend_id $dev_id > /sys/bus/pci/drivers/vfio-mdev-pci/new_id
> >
> > d) check the supported mdev instances
> > > ls /sys/bus/pci/devices/$dev_bdf/mdev_supported_types/
> > vfio-mdev-pci-type1
> > > ls /sys/bus/pci/devices/$dev_bdf/mdev_supported_types/\
> > vfio-mdev-pci-type1/
> > available_instances create device_api devices name
>
>
> I think the static type name here is a problem (and why does it
> include "type1"?). We generally consider that a type defines a
> software compatible mdev, but in this case any PCI device wrapped in
> vfio-mdev-pci gets the same mdev type. This is only a sample driver,
> but that's a bad precedent. I've taken a stab at fixing this in the
> patch below, using the PCI vendor ID, device ID, subsystem vendor ID,
> subsystem device ID, class code, and revision to try to make the type
> as specific to the physical device assigned as we can through PCI.
Thanks, it is much better than what I proposed.
>
> >
> > e) create mdev on this physical device (only 1 instance)
> > > echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1003" > \
> > /sys/bus/pci/devices/$dev_bdf/mdev_supported_types/\
> > vfio-mdev-pci-type1/create
>
> Whoops, available_instances always reports 1 and it doesn't appear that
> the create function prevents additional mdevs. Also addressed in the
> patch below.
yep, thanks.
>
> > f) passthru the mdev to guest
> > add the following line in Qemu boot command
> > -device vfio-pci,\
> > sysfsdev=/sys/bus/mdev/devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1003
> >
> > g) destroy mdev
> > > echo 1 > /sys/bus/mdev/devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1003/\
> > remove
> >
>
> I also found that unbinding the parent device doesn't unregister with
> mdev, so it cannot be bound again, also fixed below.
Oops, good catch. :-)
> However, the patch below just makes the mdev interface behave
> correctly, I can't make it work on my system because commit
> 7bd50f0cd2fd ("vfio/type1: Add domain at(de)taching group helpers")
What error did you encounter. I tested the patch with a device in a
singleton iommu group. I'm also searching a proper machine with
multiple devices in an iommu group and test it.
> used iommu_attach_device() rather than iommu_attach_group() for non-aux
> mdev iommu_device. Is there a requirement that the mdev parent device
> is in a singleton iommu group?
I don't think there should have such limitation. Per my understanding,
vfio-mdev-pci should also be able to bind to devices which shares
iommu group with other devices. vfio-pci works well for such devices.
And since the two drivers share most of the codes, I think vfio-mdev-pci
should naturally support it as well.
> If this is a simplification, then
> vfio-mdev-pci should not bind to devices where this is violated since
> there's no way to use the device. Can we support it though?
yeah, I think we need to support it.
> If I have two devices in the same group and bind them both to
> vfio-mdev-pci, I end up with three groups, one for each mdev device and
> the original physical device group. vfio.c works with the mdev groups
> and will try to match both groups to the container. vfio_iommu_type1.c
> also works with the mdev groups, except for the point where we actually
> try to attach a group to a domain, which is the only window where we use
> the iommu_device rather than the provided group, but we don't record
> that anywhere. Should struct vfio_group have a pointer to a reference
> counted object that tracks the actual iommu_group attached, such that
> we can determine that the group is already attached to the domain and
> not try to attach again?
Agreed, we need to avoid such duplicated attach. Instead of adding
reference counted object in vfio_group. I'm also considering the logic
below:
/*
* Do this check in vfio_iommu_type1_attach_group(), after mdev_group
* is initialized.
*/
if (vfio_group->mdev_group) {
/*
* vfio_group->mdev_group is true means vfio_group->iommu_group
* is not the actual iommu_group which is going to be attached to
* domain. To avoid duplicate iommu_group attach, needs to check if
* the actual iommu_group. vfio_get_parent_iommu_group() is a
* newly added helper function which returns the actual attach
* iommu_group going to be attached for this mdev group.
*/
p_iommu_group = vfio_get_parent_iommu_group(
vfio_group->iommu_group);
list_for_each_entry(d, &iommu->domain_list, next) {
if (find_iommu_group(d, p_iommu_group)) {
mutex_unlock(&iommu->lock);
// skip group attach;
}
}
> Ideally I'd be able to bind one device to
> vfio-pci, the other to vfio-mdev-pci, and be able to use them both
> within the same container. It seems like this should be possible, it's
> the same effective iommu configuration as if they were both bound to
> vfio-pci. Thanks,
Agreed. Will test it. And thanks for the fix patch below. I've test it
with a device in a singleton iommu group. Need to test the scenario
you mentioned above. :-)
Thanks,
Yi Liu
>
> Alex
>
> diff --git a/drivers/vfio/pci/vfio_mdev_pci.c b/drivers/vfio/pci/vfio_mdev_pci.c
> index 07c8067b3f73..09143d3e5473 100644
> --- a/drivers/vfio/pci/vfio_mdev_pci.c
> +++ b/drivers/vfio/pci/vfio_mdev_pci.c
> @@ -65,18 +65,22 @@ MODULE_PARM_DESC(disable_idle_d3,
>
> static struct pci_driver vfio_mdev_pci_driver;
>
> -static ssize_t
> -name_show(struct kobject *kobj, struct device *dev, char *buf)
> -{
> - return sprintf(buf, "%s-type1\n", dev_name(dev));
> -}
> -
> -MDEV_TYPE_ATTR_RO(name);
> +struct vfio_mdev_pci_device {
> + struct vfio_pci_device vdev;
> + struct mdev_parent_ops ops;
> + struct attribute_group *groups[2];
> + struct attribute_group attr;
> + atomic_t avail;
> +};
>
> static ssize_t
> available_instances_show(struct kobject *kobj, struct device *dev, char *buf)
> {
> - return sprintf(buf, "%d\n", 1);
> + struct vfio_mdev_pci_device *vmdev;
> +
> + vmdev = pci_get_drvdata(to_pci_dev(dev));
> +
> + return sprintf(buf, "%d\n", atomic_read(&vmdev->avail));
> }
>
> MDEV_TYPE_ATTR_RO(available_instances);
> @@ -90,62 +94,57 @@ static ssize_t device_api_show(struct kobject *kobj, struct
> device *dev,
> MDEV_TYPE_ATTR_RO(device_api);
>
> static struct attribute *vfio_mdev_pci_types_attrs[] = {
> - &mdev_type_attr_name.attr,
> &mdev_type_attr_device_api.attr,
> &mdev_type_attr_available_instances.attr,
> NULL,
> };
>
> -static struct attribute_group vfio_mdev_pci_type_group1 = {
> - .name = "type1",
> - .attrs = vfio_mdev_pci_types_attrs,
> -};
> -
> -struct attribute_group *vfio_mdev_pci_type_groups[] = {
> - &vfio_mdev_pci_type_group1,
> - NULL,
> -};
> -
> struct vfio_mdev_pci {
> struct vfio_pci_device *vdev;
> struct mdev_device *mdev;
> - unsigned long handle;
> };
>
> static int vfio_mdev_pci_create(struct kobject *kobj, struct mdev_device *mdev)
> {
> struct device *pdev;
> - struct vfio_pci_device *vdev;
> + struct vfio_mdev_pci_device *vmdev;
> struct vfio_mdev_pci *pmdev;
> int ret;
>
> pdev = mdev_parent_dev(mdev);
> - vdev = dev_get_drvdata(pdev);
> + vmdev = dev_get_drvdata(pdev);
> +
> + if (atomic_dec_if_positive(&vmdev->avail) < 0)
> + return -ENOSPC;
> +
> pmdev = kzalloc(sizeof(struct vfio_mdev_pci), GFP_KERNEL);
> - if (pmdev == NULL) {
> - ret = -EBUSY;
> - goto out;
> - }
> + if (!pmdev)
> + return -ENOMEM;
>
> pmdev->mdev = mdev;
> - pmdev->vdev = vdev;
> + pmdev->vdev = &vmdev->vdev;
> mdev_set_drvdata(mdev, pmdev);
> ret = mdev_set_iommu_device(mdev_dev(mdev), pdev);
> if (ret) {
> pr_info("%s, failed to config iommu isolation for mdev: %s on
> pf: %s\n",
> __func__, dev_name(mdev_dev(mdev)), dev_name(pdev));
> - goto out;
> + kfree(pmdev);
> + atomic_inc(&vmdev->avail);
> + return ret;
> }
>
> -out:
> - return ret;
> + return 0;
> }
>
> static int vfio_mdev_pci_remove(struct mdev_device *mdev)
> {
> struct vfio_mdev_pci *pmdev = mdev_get_drvdata(mdev);
> + struct vfio_mdev_pci_device *vmdev;
> +
> + vmdev = container_of(pmdev->vdev, struct vfio_mdev_pci_device, vdev);
>
> kfree(pmdev);
> + atomic_inc(&vmdev->avail);
> pr_info("%s, succeeded for mdev: %s\n", __func__,
> dev_name(mdev_dev(mdev)));
>
> @@ -237,24 +236,12 @@ static ssize_t vfio_mdev_pci_write(struct mdev_device
> *mdev,
> return vfio_pci_write(pmdev->vdev, (char __user *)buf, count, ppos);
> }
>
> -static const struct mdev_parent_ops vfio_mdev_pci_ops = {
> - .supported_type_groups = vfio_mdev_pci_type_groups,
> - .create = vfio_mdev_pci_create,
> - .remove = vfio_mdev_pci_remove,
> -
> - .open = vfio_mdev_pci_open,
> - .release = vfio_mdev_pci_release,
> -
> - .read = vfio_mdev_pci_read,
> - .write = vfio_mdev_pci_write,
> - .mmap = vfio_mdev_pci_mmap,
> - .ioctl = vfio_mdev_pci_ioctl,
> -};
> -
> static int vfio_mdev_pci_driver_probe(struct pci_dev *pdev,
> const struct pci_device_id *id)
> {
> + struct vfio_mdev_pci_device *vmdev;
> struct vfio_pci_device *vdev;
> + const struct mdev_parent_ops *ops;
> int ret;
>
> if (pdev->hdr_type != PCI_HEADER_TYPE_NORMAL)
> @@ -273,10 +260,38 @@ static int vfio_mdev_pci_driver_probe(struct pci_dev
> *pdev,
> return -EBUSY;
> }
>
> - vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
> - if (!vdev)
> + vmdev = kzalloc(sizeof(*vmdev), GFP_KERNEL);
> + if (!vmdev)
> return -ENOMEM;
>
> + vmdev->attr.name = kasprintf(GFP_KERNEL,
> + "%04x:%04x:%04x:%04x:%06x:%02x",
> + pdev->vendor, pdev->device,
> + pdev->subsystem_vendor,
> + pdev->subsystem_device, pdev->class,
> + pdev->revision);
> + if (!vmdev->attr.name) {
> + kfree(vmdev);
> + return -ENOMEM;
> + }
> +
> + atomic_set(&vmdev->avail, 1);
> +
> + vmdev->attr.attrs = vfio_mdev_pci_types_attrs;
> + vmdev->groups[0] = &vmdev->attr;
> +
> + vmdev->ops.supported_type_groups = vmdev->groups;
> + vmdev->ops.create = vfio_mdev_pci_create;
> + vmdev->ops.remove = vfio_mdev_pci_remove;
> + vmdev->ops.open = vfio_mdev_pci_open;
> + vmdev->ops.release = vfio_mdev_pci_release;
> + vmdev->ops.read = vfio_mdev_pci_read;
> + vmdev->ops.write = vfio_mdev_pci_write;
> + vmdev->ops.mmap = vfio_mdev_pci_mmap;
> + vmdev->ops.ioctl = vfio_mdev_pci_ioctl;
> + ops = &vmdev->ops;
> +
> + vdev = &vmdev->vdev;
> vdev->pdev = pdev;
> vdev->irq_type = VFIO_PCI_NUM_IRQS;
> mutex_init(&vdev->igate);
> @@ -289,7 +304,7 @@ static int vfio_mdev_pci_driver_probe(struct pci_dev *pdev,
> #endif
> vdev->disable_idle_d3 = disable_idle_d3;
>
> - pci_set_drvdata(pdev, vdev);
> + pci_set_drvdata(pdev, vmdev);
>
> ret = vfio_pci_reflck_attach(vdev);
> if (ret) {
> @@ -320,7 +335,7 @@ static int vfio_mdev_pci_driver_probe(struct pci_dev *pdev,
> vfio_pci_set_power_state(vdev, PCI_D3hot);
> }
>
> - ret = mdev_register_device(&pdev->dev, &vfio_mdev_pci_ops);
> + ret = mdev_register_device(&pdev->dev, ops);
> if (ret)
> pr_err("Cannot register mdev for device %s\n",
> dev_name(&pdev->dev));
> @@ -332,12 +347,17 @@ static int vfio_mdev_pci_driver_probe(struct pci_dev
> *pdev,
>
> static void vfio_mdev_pci_driver_remove(struct pci_dev *pdev)
> {
> + struct vfio_mdev_pci_device *vmdev;
> struct vfio_pci_device *vdev;
>
> - vdev = pci_get_drvdata(pdev);
> - if (!vdev)
> + mdev_unregister_device(&pdev->dev);
> +
> + vmdev = pci_get_drvdata(pdev);
> + if (!vmdev)
> return;
>
> + vdev = &vmdev->vdev;
> +
> vfio_pci_reflck_put(vdev->reflck);
>
> kfree(vdev->region);
> @@ -355,7 +375,8 @@ static void vfio_mdev_pci_driver_remove(struct pci_dev
> *pdev)
> VGA_RSRC_LEGACY_IO |
> VGA_RSRC_LEGACY_MEM);
> }
>
> - kfree(vdev);
> + kfree(vmdev->attr.name);
> + kfree(vmdev);
> }
>
> static struct pci_driver vfio_mdev_pci_driver = {
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v17 04/10] acpi: add build_append_ghes_generic_data() helper for Generic Error Data Entry
From: Igor Mammedov @ 2019-06-20 12:28 UTC (permalink / raw)
To: Dongjiu Geng
Cc: peter.maydell, ehabkost, kvm, mst, mtosatti, qemu-devel, linuxarm,
shannon.zhaosl, zhengxiang9, qemu-arm, james.morse, xuwei5,
jonathan.cameron, pbonzini, lersek, rth
In-Reply-To: <1557832703-42620-5-git-send-email-gengdongjiu@huawei.com>
On Tue, 14 May 2019 04:18:17 -0700
Dongjiu Geng <gengdongjiu@huawei.com> wrote:
> It will help to add Generic Error Data Entry to ACPI tables
> without using packed C structures and avoid endianness
> issues as API doesn't need explicit conversion.
>
> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
> ---
> hw/acpi/aml-build.c | 32 ++++++++++++++++++++++++++++++++
> include/hw/acpi/aml-build.h | 6 ++++++
> 2 files changed, 38 insertions(+)
>
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index fb53f21..102a288 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -296,6 +296,38 @@ void build_append_ghes_notify(GArray *table, const uint8_t type,
> build_append_int_noprefix(table, error_threshold_window, 4);
> }
>
> +/* Generic Error Data Entry
> + * ACPI 4.0: 17.3.2.6.1 Generic Error Data
> + */
> +void build_append_ghes_generic_data(GArray *table, const char *section_type,
s/build_append_ghes_generic_data/build_append_ghes_generic_error_data/
> + uint32_t error_severity, uint16_t revision,
> + uint8_t validation_bits, uint8_t flags,
> + uint32_t error_data_length, uint8_t *fru_id,
> + uint8_t *fru_text, uint64_t time_stamp)
checkpatch probably will complain due to too long lines
you can use:
void build_append_ghe...
uint32_t error_severity, uint16_t revision,
...
> +{
> + int i;
> +
> + for (i = 0; i < 16; i++) {
> + build_append_int_noprefix(table, section_type[i], 1);
^^^
use QemuUUID instead, see vmgenid_build_acpi
> + }
> +
> + build_append_int_noprefix(table, error_severity, 4);
> + build_append_int_noprefix(table, revision, 2);
> + build_append_int_noprefix(table, validation_bits, 1);
> + build_append_int_noprefix(table, flags, 1);
> + build_append_int_noprefix(table, error_data_length, 4);
> +
> + for (i = 0; i < 16; i++) {
> + build_append_int_noprefix(table, fru_id[i], 1);
same as section_type
> + }
> +
> + for (i = 0; i < 20; i++) {
> + build_append_int_noprefix(table, fru_text[i], 1);
> + }
instead of loop use g_array_insert_vals()
> +
> + build_append_int_noprefix(table, time_stamp, 8);
that's not part of 'Table 17-13'
where does it come from?
> +}
> +
> /*
> * Build NAME(XXXX, 0x00000000) where 0x00000000 is encoded as a dword,
> * and return the offset to 0x00000000 for runtime patching.
> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> index 90c8ef8..a71db2f 100644
> --- a/include/hw/acpi/aml-build.h
> +++ b/include/hw/acpi/aml-build.h
> @@ -419,6 +419,12 @@ void build_append_ghes_notify(GArray *table, const uint8_t type,
> uint32_t error_threshold_value,
> uint32_t error_threshold_window);
>
> +void build_append_ghes_generic_data(GArray *table, const char *section_type,
> + uint32_t error_severity, uint16_t revision,
> + uint8_t validation_bits, uint8_t flags,
> + uint32_t error_data_length, uint8_t *fru_id,
> + uint8_t *fru_text, uint64_t time_stamp);
> +
> void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
> uint64_t len, int node, MemoryAffinityFlags flags);
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v17 05/10] acpi: add build_append_ghes_generic_status() helper for Generic Error Status Block
From: Igor Mammedov @ 2019-06-20 12:42 UTC (permalink / raw)
To: Dongjiu Geng
Cc: peter.maydell, ehabkost, kvm, mst, mtosatti, qemu-devel, linuxarm,
shannon.zhaosl, zhengxiang9, qemu-arm, james.morse, xuwei5,
jonathan.cameron, pbonzini, lersek, rth
In-Reply-To: <1557832703-42620-6-git-send-email-gengdongjiu@huawei.com>
On Tue, 14 May 2019 04:18:18 -0700
Dongjiu Geng <gengdongjiu@huawei.com> wrote:
> It will help to add Generic Error Status Block to ACPI tables
> without using packed C structures and avoid endianness
> issues as API doesn't need explicit conversion.
>
> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
> ---
> hw/acpi/aml-build.c | 14 ++++++++++++++
> include/hw/acpi/aml-build.h | 6 ++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index 102a288..ce90970 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -296,6 +296,20 @@ void build_append_ghes_notify(GArray *table, const uint8_t type,
> build_append_int_noprefix(table, error_threshold_window, 4);
> }
>
> +/* Generic Error Status Block
> + * ACPI 4.0: 17.3.2.6.1 Generic Error Data
> + */
> +void build_append_ghes_generic_status(GArray *table, uint32_t block_status,
maybe ..._generic_error_status???
> + uint32_t raw_data_offset, uint32_t raw_data_length,
> + uint32_t data_length, uint32_t error_severity)
see CODING_STYLE, 1.1 Multiline Indent
> +{
when describing filds from spec try to add 'verbatim' copy of the name from spec
so it would be esy to grep for it. Like:
/* Block Status */
> + build_append_int_noprefix(table, block_status, 4);
/* Raw Data Offset */
note applies all other places where you compose ACPI tables
> + build_append_int_noprefix(table, raw_data_offset, 4);
> + build_append_int_noprefix(table, raw_data_length, 4);
> + build_append_int_noprefix(table, data_length, 4);
> + build_append_int_noprefix(table, error_severity, 4);
> +}
> +
> /* Generic Error Data Entry
> * ACPI 4.0: 17.3.2.6.1 Generic Error Data
> */
> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> index a71db2f..1ec7e1b 100644
> --- a/include/hw/acpi/aml-build.h
> +++ b/include/hw/acpi/aml-build.h
> @@ -425,6 +425,12 @@ void build_append_ghes_generic_data(GArray *table, const char *section_type,
> uint32_t error_data_length, uint8_t *fru_id,
> uint8_t *fru_text, uint64_t time_stamp);
>
> +void
> +build_append_ghes_generic_status(GArray *table, uint32_t block_status,
> + uint32_t raw_data_offset,
> + uint32_t raw_data_length,
> + uint32_t data_length, uint32_t error_severity);
this and previous patch, it might be better to to move declaration
to its own header, for example to include/hw/acpi/acpi_ghes.h
that you are adding later in the series.
And maybe move helpers to hw/acpi/acpi_ghes.c
They are not really independent ACPI primitives that are shared
with other tables, aren't they?
.
> +
> void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
> uint64_t len, int node, MemoryAffinityFlags flags);
>
^ permalink raw reply
* Re: [Qemu-devel] [QEMU PATCH v4 0/10]: target/i386: kvm: Add support for save and restore of nested state
From: Paolo Bonzini @ 2019-06-20 12:38 UTC (permalink / raw)
To: Liran Alon, qemu-devel
Cc: ehabkost, kvm, maran.wilson, mtosatti, dgilbert, jmattson, rth
In-Reply-To: <20190619162140.133674-1-liran.alon@oracle.com>
On 19/06/19 18:21, Liran Alon wrote:
> Hi,
>
> This series aims to add support for QEMU to be able to migrate VMs that
> are running nested hypervisors. In order to do so, it utilizes the new
> IOCTLs introduced in KVM commit 8fcc4b5923af ("kvm: nVMX: Introduce
> KVM_CAP_NESTED_STATE") which was created for this purpose.
Applied with just three minor changes that should be uncontroversial:
> 6rd patch updates linux-headers to have updated struct kvm_nested_state.
> The updated struct now have explicit fields for the data portion.
Changed patch title to "linux-headers: sync with latest KVM headers from
Linux 5.2"
> 7rd patch add vmstate support for saving/restoring kernel integer types (e.g. __u16).
>
> 8th patch adds support for saving and restoring nested state in order to migrate
> guests which run a nested hypervisor.
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index e924663f32..f3cf6e1b27 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1671,10 +1671,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
struct kvm_vmx_nested_state_hdr *vmx_hdr =
&env->nested_state->hdr.vmx;
+ env->nested_state->format = KVM_STATE_NESTED_FORMAT_VMX;
vmx_hdr->vmxon_pa = -1ull;
vmx_hdr->vmcs12_pa = -1ull;
}
-
}
cpu->kvm_msr_buf = g_malloc0(MSR_BUF_SIZE);
which is a no-op since KVM_STATE_NESTED_FORMAT_VMX is zero, but it's tidy.
> 9th patch add support for KVM_CAP_EXCEPTION_PAYLOAD. This new KVM capability
> allows userspace to properly distingiush between pending and injecting exceptions.
>
> 10th patch changes the nested virtualization migration blocker to only
> be added when kernel lack support for one of the capabilities required
> for correct nested migration. i.e. Either KVM_CAP_NESTED_STATE or
> KVM_CAP_EXCEPTION_PAYLOAD.
Had to disable this for SVM unfortunately.
^ permalink raw reply related
* Re: cifs: Fix tracing build error with O=
From: Masahiro Yamada @ 2019-06-20 12:56 UTC (permalink / raw)
To: Herbert Xu
Cc: stfrench, linux-cifs, Linux Kernel Mailing List,
Christoph Hellwig
In-Reply-To: <20190620124731.dpnocjhh5co2ab5g@gondor.apana.org.au>
On Thu, Jun 20, 2019 at 9:47 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Thu, Jun 20, 2019 at 08:56:10PM +0900, Masahiro Yamada wrote:
> >
> > The similar question, and the answer is here:
> > https://lkml.org/lkml/2019/1/17/584
>
> But it doesn't work with O=:
>
> $ rm -rf build-compile/fs/cifs
> $ make O=build-compile fs/cifs
> make[1]: Entering directory '/home/herbert/src/build/kernel/test/build-compile'
> make[1]: Nothing to be done for '../fs/cifs'.
> make[1]: Leaving directory '/home/herbert/src/build/kernel/test/build-compile'
> $
You missed the trailing slash.
I suggested 'fs/cifs/' instead of 'fs/cifs'
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH net-next v2] ipv6: Error when route does not have any valid nexthops
From: David Ahern @ 2019-06-20 12:57 UTC (permalink / raw)
To: Ido Schimmel, netdev; +Cc: davem, mlxsw, Ido Schimmel
In-Reply-To: <20190620091021.18210-1-idosch@idosch.org>
On 6/20/19 3:10 AM, Ido Schimmel wrote:
> From: Ido Schimmel <idosch@mellanox.com>
>
> When user space sends invalid information in RTA_MULTIPATH, the nexthop
> list in ip6_route_multipath_add() is empty and 'rt_notif' is set to
> NULL.
>
> The code that emits the in-kernel notifications does not check for this
> condition, which results in a NULL pointer dereference [1].
>
> Fix this by bailing earlier in the function if the parsed nexthop list
> is empty. This is consistent with the corresponding IPv4 code.
>
> v2:
> * Check if parsed nexthop list is empty and bail with extack set
>
...
>
> Reported-by: syzbot+382566d339d52cd1a204@syzkaller.appspotmail.com
> Fixes: ebee3cad835f ("ipv6: Add IPv6 multipath notifications for add / replace")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> ---
> net/ipv6/route.c | 6 ++++++
> 1 file changed, 6 insertions(+)
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH 0/5] Fixes for HiSilicon LPC driver and logical PIO code
From: John Garry @ 2019-06-20 12:56 UTC (permalink / raw)
To: Olof Johansson
Cc: xuwei5, Bjorn Helgaas, Linuxarm, ARM-SoC Maintainers,
Linux Kernel Mailing List, linux-pci, Joe Perches
In-Reply-To: <CAOesGMg+jAae5A0LgvBH0=dF95Y208h0c5RZ6f0v6CVUhsMk4g@mail.gmail.com>
On 20/06/2019 13:42, Olof Johansson wrote:
> Hi John,
>
> For patches that go to a soc maintainer for merge, we're asking that
> people don't cc arm@kernel.org directly.
>
> We prefer to keep that alias mostly for pull requests from other
> maintainers and patches we might have a reason to apply directly.
> Otherwise we risk essentially getting all of linux-arm-kernel into
> this mailbox as well.
>
>
> Thanks!
>
> -Olof
>
Hi Olof,
Can do in future.
The specific reason here for me to cc arm@kernel.org was that I wanted
to at least make the maintainers aware that we intend to send some
patches outside the "arm soc" domain through their tree, * below.
Thanks,
John
> On Thu, Jun 20, 2019 at 11:33 AM John Garry <john.garry@huawei.com> wrote:
>>
>> As reported in [1], the hisi-lpc driver has certain issues in handling
>> logical PIO regions, specifically unregistering regions.
>>
>> This series add a method to unregister a logical PIO region, and fixes up
>> the driver to use them.
>>
>> RCU usage in logical PIO code looks to always have been broken, so that
>> is fixed also. This is not a major fix as the list which RCU protects is
>> very rarely modified.
>>
>> There is another patch to simplify logical PIO registration, made possible
>> by the fixes.
>>
>> At this point, there are still separate ongoing discussions about how to
>> stop the logical PIO and PCI host bridge code leaking ranges, as in [2].
>>
*
>> Hopefully this series can go through the arm soc tree and the maintainers
>> have no issue with that. I'm talking specifically about the logical PIO
>> code, which went through PCI tree on only previous upstreaming.
>>
>> Cc. linux-pci@vger.kernel.org
>>
>> [1] https://lore.kernel.org/lkml/1560770148-57960-1-git-send-email-john.garry@huawei.com/
>> [2] https://lore.kernel.org/lkml/4b24fd36-e716-7c5e-31cc-13da727802e7@huawei.com/
>>
>> John Garry (5):
>> lib: logic_pio: Fix RCU usage
>> lib: logic_pio: Add logic_pio_unregister_range()
>> bus: hisi_lpc: Unregister logical PIO range to avoid potential
>> use-after-free
>> bus: hisi_lpc: Add .remove method to avoid driver unbind crash
>> lib: logic_pio: Enforce LOGIC_PIO_INDIRECT region ops are set at
>> registration
>>
>> drivers/bus/hisi_lpc.c | 43 ++++++++++++++++++---
>> include/linux/logic_pio.h | 1 +
>> lib/logic_pio.c | 78 ++++++++++++++++++++++++++++-----------
>> 3 files changed, 95 insertions(+), 27 deletions(-)
>>
>> --
>> 2.17.1
>>
>
> .
>
^ permalink raw reply
* Re: [PATCH] spi/acpi: avoid spurious matches during slave enumeration
From: Mika Westerberg @ 2019-06-20 12:56 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-spi, broonie, andy.shevchenko, masahisa.kojima,
Rafael J. Wysocki, Jarkko Nikula, linux-acpi, Lukas Wunner
In-Reply-To: <20190620123649.4492-1-ard.biesheuvel@linaro.org>
On Thu, Jun 20, 2019 at 02:36:49PM +0200, Ard Biesheuvel wrote:
> In the new SPI ACPI slave enumeration code, we use the value of
> lookup.max_speed_khz as a flag to decide whether a match occurred.
> However, doing so only makes sense if we initialize its value to
> zero beforehand, or otherwise, random junk from the stack will
> cause spurious matches.
>
> So zero initialize the lookup struct fully, and only set the non-zero
> members explicitly.
>
> Fixes: 4c3c59544f33 ("spi/acpi: enumerate all SPI slaves in the namespace")
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
^ permalink raw reply
* [U-Boot] [nand] [ubi] Discrepancy Between U-Boot and Linux NAND PEBs
From: Ken Sloat @ 2019-06-20 12:55 UTC (permalink / raw)
To: u-boot
Hello All,
I have been working on a system using a NAND flash along with U-Boot 2018.07 and Linux Kernel 4.14. This is an Atmel based system FYI so it uses the Atmel NAND driver. I create a UBI image with 3 separate volumes - 2 of these are a specified fixed size and the third is specified as the minimum needed to hold the current files with the auto resize flag set. As a note, before the first run auto resize operation, there is over 200 MiB of unused space in the NAND - meaning there should be plenty of free space available for UBI to leave overhead when auto-resizing for bad block handling. Another point of note, is that I use UBI within U-Boot as well in order to read the kernel image and dtb out of the UBIFS.
I have noticed warnings in Linux when attaching UBI regarding not having enough reserved PEBs for bad block handling (it's short by 2). Upon further investigation into the issue, it appears as though there is a discrepancy between what U-Boot and Linux see in terms of the number of bad blocks:
U-Boot:
ubi0: good PEBs: 4093, bad PEBs: 3, corrupted PEBs: 0
ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
Linux:
ubi0 warning: ubi_eba_init: cannot reserve enough PEBs for bad PEB handling, reserved 71, need 73
......
ubi0: good PEBs: 4089, bad PEBs: 7, corrupted PEBs: 0
ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
After production flashing of a UBI image to NAND (with a "dumb" non UBI aware flasher), U-Boot will be the program to mount UBI. What this means is that it will complete the one time re-size operation. I used a Linux ramdisk image to flash from Linux and mount UBI in Linux for the first time to allow it to complete the auto-resize operation instead and compared:
U-Boot:
ubi0: attaching mtd1
ubi0: scanning is finished
ubi0: volume 1 ("rootfs") re-sized from 1501 to 3385 LEBs
ubi0: attached mtd1 (name "mtd=0", size 512 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 4093, bad PEBs: 3, corrupted PEBs: 0
Linux:
ubi0: attaching mtd6
ubi0: scanning is finished
ubi0: volume 1 ("rootfs") re-sized from 1501 to 3383 LEBs
ubi0: attached mtd6 (name "atmel_nand", size 512 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 4089, bad PEBs: 7, corrupted PEBs: 0
As you can see, U-Boot resizes the image to 3385 blocks while Linux only 3383 - hence the 2 blocks that Linux would complain about had U-Boot resized the volume.
I am not sure exactly what is causing this discrepancy as I just figured this out - but thought I would reach out and discuss it here. Obviously there are ways around this issue (program and mount UBI from Linux initially, don't use autoresize and specify all volume sizes, etc) but was wondering if there is some underlying problem. I noticed an older mailing discussion from several years ago where someone reported a similar issue regarding number of bad PEBs and seems the issue was chalked up to a potential driver problem on one side:
https://lists.denx.de/pipermail/u-boot/2015-June/216482.html
Any insight would be helpful.
Thanks,
Ken Sloat
^ permalink raw reply
* Re: [PATCH] spi/acpi: avoid spurious matches during slave enumeration
From: Jarkko Nikula @ 2019-06-20 12:54 UTC (permalink / raw)
To: Ard Biesheuvel, linux-spi
Cc: broonie, Mika Westerberg, andy.shevchenko, masahisa.kojima,
Rafael J. Wysocki, linux-acpi, Lukas Wunner
In-Reply-To: <20190620123649.4492-1-ard.biesheuvel@linaro.org>
On 6/20/19 3:36 PM, Ard Biesheuvel wrote:
> In the new SPI ACPI slave enumeration code, we use the value of
> lookup.max_speed_khz as a flag to decide whether a match occurred.
> However, doing so only makes sense if we initialize its value to
> zero beforehand, or otherwise, random junk from the stack will
> cause spurious matches.
>
> So zero initialize the lookup struct fully, and only set the non-zero
> members explicitly.
>
> Fixes: 4c3c59544f33 ("spi/acpi: enumerate all SPI slaves in the namespace")
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: andy.shevchenko@gmail.com
> Cc: masahisa.kojima@linaro.org
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> Cc: linux-acpi@vger.kernel.org
> Cc: Lukas Wunner <lukas@wunner.de>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> drivers/spi/spi.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
^ permalink raw reply
* RE: [PATCH net] tipc: change to use register_pernet_device
From: Jon Maloy @ 2019-06-20 12:53 UTC (permalink / raw)
To: Xin Long, network dev
Cc: davem@davemloft.net, Ying Xue,
tipc-discussion@lists.sourceforge.net
In-Reply-To: <1a8f3ada3e0a65b6e9250c4580a7c420b4ddddac.1561027168.git.lucien.xin@gmail.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of Xin Long
> Sent: 20-Jun-19 06:39
> To: network dev <netdev@vger.kernel.org>
> Cc: davem@davemloft.net; Jon Maloy <jon.maloy@ericsson.com>; Ying Xue
> <ying.xue@windriver.com>; tipc-discussion@lists.sourceforge.net
> Subject: [PATCH net] tipc: change to use register_pernet_device
>
> This patch is to fix a dst defcnt leak, which can be reproduced by doing:.ericsson.com>
>
> # ip net a c; ip net a s; modprobe tipc
> # ip net e s ip l a n eth1 type veth peer n eth1 netns c
> # ip net e c ip l s lo up; ip net e c ip l s eth1 up
> # ip net e s ip l s lo up; ip net e s ip l s eth1 up
> # ip net e c ip a a 1.1.1.2/8 dev eth1
> # ip net e s ip a a 1.1.1.1/8 dev eth1
> # ip net e c tipc b e m udp n u1 localip 1.1.1.2
> # ip net e s tipc b e m udp n u1 localip 1.1.1.1
> # ip net d c; ip net d s; rmmod tipc
>
> and it will get stuck and keep logging the error:
>
> unregister_netdevice: waiting for lo to become free. Usage count = 1
>
> The cause is that a dst is held by the udp sock's sk_rx_dst set on udp rx path
> with udp_early_demux == 1, and this dst (eventually holding lo dev) can't be
> released as bearer's removal in tipc pernet .exit happens after lo dev's
> removal, default_device pernet .exit.
>
> "There are two distinct types of pernet_operations recognized: subsys and
> device. At creation all subsys init functions are called before device
> init functions, and at destruction all device exit functions are called
> before subsys exit function."
>
> So by calling register_pernet_device instead to register tipc_net_ops, the
> pernet .exit() will be invoked earlier than loopback dev's removal when a
> netns is being destroyed, as fou/gue does.
>
> Note that vxlan and geneve udp tunnels don't have this issue, as the udp sock
> is released in their device ndo_stop().
>
> This fix is also necessary for tipc dst_cache, which will hold dsts on tx path and
> I will introduce in my next patch.
>
> Reported-by: Li Shuang <shuali@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/tipc/core.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/tipc/core.c b/net/tipc/core.c index ed536c0..c837072 100644
> --- a/net/tipc/core.c
> +++ b/net/tipc/core.c
> @@ -134,7 +134,7 @@ static int __init tipc_init(void)
> if (err)
> goto out_sysctl;
>
> - err = register_pernet_subsys(&tipc_net_ops);
> + err = register_pernet_device(&tipc_net_ops);
> if (err)
> goto out_pernet;
>
> @@ -142,7 +142,7 @@ static int __init tipc_init(void)
> if (err)
> goto out_socket;
>
> - err = register_pernet_subsys(&tipc_topsrv_net_ops);
> + err = register_pernet_device(&tipc_topsrv_net_ops);
> if (err)
> goto out_pernet_topsrv;
>
> @@ -153,11 +153,11 @@ static int __init tipc_init(void)
> pr_info("Started in single node mode\n");
> return 0;
> out_bearer:
> - unregister_pernet_subsys(&tipc_topsrv_net_ops);
> + unregister_pernet_device(&tipc_topsrv_net_ops);
> out_pernet_topsrv:
> tipc_socket_stop();
> out_socket:
> - unregister_pernet_subsys(&tipc_net_ops);
> + unregister_pernet_device(&tipc_net_ops);
> out_pernet:
> tipc_unregister_sysctl();
> out_sysctl:
> @@ -172,9 +172,9 @@ static int __init tipc_init(void) static void __exit
> tipc_exit(void) {
> tipc_bearer_cleanup();
> - unregister_pernet_subsys(&tipc_topsrv_net_ops);
> + unregister_pernet_device(&tipc_topsrv_net_ops);
> tipc_socket_stop();
> - unregister_pernet_subsys(&tipc_net_ops);
> + unregister_pernet_device(&tipc_net_ops);
> tipc_netlink_stop();
> tipc_netlink_compat_stop();
> tipc_unregister_sysctl();
> --
> 2.1.0
^ permalink raw reply
* Re: [PATCH 04/14] ABI: better identificate tables
From: Greg Kroah-Hartman @ 2019-06-20 12:54 UTC (permalink / raw)
To: Johan Hovold
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Stefan Achatz
In-Reply-To: <20190620120150.GH6241@localhost>
On Thu, Jun 20, 2019 at 02:01:50PM +0200, Johan Hovold wrote:
> > I don't know when "Description" and "RST-Description" would be used.
> > Why not just parse "Description" like rst text and if things are "messy"
> > we fix them up as found, like you did with the ":" here? It doesn't
> > have to be complex, we can always fix them up after-the-fact if new
> > stuff gets added that doesn't quite parse properly.
> >
> > Just like we do for most kernel-doc formatting :)
>
> But kernel-doc has a documented format, which was sort of the point I
> was trying to make. If the new get_abi.pl scripts expects a colon I
> think it should be mentioned somewhere (e.g. Documentation/ABI/README).
>
> Grepping for attribute entries in linux-next still reveals a number
> descriptions that still lack that colon and use varying formatting. More
> are bound to be added later, but perhaps that's ok depending on what
> you're aiming at here.
I'm aiming for "good enough" to start with, and then we can work through
the exceptions.
But given that Mauro hasn't resent the script that does the conversion
of the files, I don't know if that will even matter... {hint}
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH net] tipc: add dst_cache support for udp media
From: Jon Maloy @ 2019-06-20 12:53 UTC (permalink / raw)
To: Xin Long, network dev
Cc: davem@davemloft.net, Ying Xue,
tipc-discussion@lists.sourceforge.net, Paolo Abeni
In-Reply-To: <0ea2e8519f14d5c9e7bb7ba82a5be371bd4cb9ab.1561028621.git.lucien.xin@gmail.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of Xin Long
> Sent: 20-Jun-19 07:04
> To: network dev <netdev@vger.kernel.org>
> Cc: davem@davemloft.net; Jon Maloy <jon.maloy@ericsson.com>; Ying Xue
> <ying.xue@windriver.com>; tipc-discussion@lists.sourceforge.net; Paolo
> Abeni <pabeni@redhat.com>
> Subject: [PATCH net] tipc: add dst_cache support for udp media
>
> As other udp/ip tunnels do, tipc udp media should also have a lockless
> dst_cache supported on its tx path.
>
> Here we add dst_cache into udp_replicast to support dst cache for both
> rmcast and rcast, and rmcast uses ub->rcast and each rcast uses its own node
> in ub->rcast.list.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/tipc/udp_media.c | 72 ++++++++++++++++++++++++++++++++++-------
> -----------
> 1 file changed, 47 insertions(+), 25 deletions(-)
>
> diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c index
> 1405ccc..b8962df 100644
> --- a/net/tipc/udp_media.c
> +++ b/net/tipc/udp_media.c
> @@ -76,6 +76,7 @@ struct udp_media_addr {
> /* struct udp_replicast - container for UDP remote addresses */ struct
> udp_replicast {
> struct udp_media_addr addr;
> + struct dst_cache dst_cache;
> struct rcu_head rcu;
> struct list_head list;
> };
> @@ -158,22 +159,27 @@ static int tipc_udp_addr2msg(char *msg, struct
> tipc_media_addr *a)
> /* tipc_send_msg - enqueue a send request */ static int tipc_udp_xmit(struct
> net *net, struct sk_buff *skb,
> struct udp_bearer *ub, struct udp_media_addr *src,
> - struct udp_media_addr *dst)
> + struct udp_media_addr *dst, struct dst_cache *cache)
> {
> + struct dst_entry *ndst = dst_cache_get(cache);
> int ttl, err = 0;
> - struct rtable *rt;
>
> if (dst->proto == htons(ETH_P_IP)) {
> - struct flowi4 fl = {
> - .daddr = dst->ipv4.s_addr,
> - .saddr = src->ipv4.s_addr,
> - .flowi4_mark = skb->mark,
> - .flowi4_proto = IPPROTO_UDP
> - };
> - rt = ip_route_output_key(net, &fl);
> - if (IS_ERR(rt)) {
> - err = PTR_ERR(rt);
> - goto tx_error;
> + struct rtable *rt = (struct rtable *)ndst;
> +
> + if (!rt) {
> + struct flowi4 fl = {
> + .daddr = dst->ipv4.s_addr,
> + .saddr = src->ipv4.s_addr,
> + .flowi4_mark = skb->mark,
> + .flowi4_proto = IPPROTO_UDP
> + };
> + rt = ip_route_output_key(net, &fl);
> + if (IS_ERR(rt)) {
> + err = PTR_ERR(rt);
> + goto tx_error;
> + }
> + dst_cache_set_ip4(cache, &rt->dst, fl.saddr);
> }
>
> ttl = ip4_dst_hoplimit(&rt->dst);
> @@ -182,17 +188,19 @@ static int tipc_udp_xmit(struct net *net, struct
> sk_buff *skb,
> dst->port, false, true);
> #if IS_ENABLED(CONFIG_IPV6)
> } else {
> - struct dst_entry *ndst;
> - struct flowi6 fl6 = {
> - .flowi6_oif = ub->ifindex,
> - .daddr = dst->ipv6,
> - .saddr = src->ipv6,
> - .flowi6_proto = IPPROTO_UDP
> - };
> - err = ipv6_stub->ipv6_dst_lookup(net, ub->ubsock->sk, &ndst,
> - &fl6);
> - if (err)
> - goto tx_error;
> + if (!ndst) {
> + struct flowi6 fl6 = {
> + .flowi6_oif = ub->ifindex,
> + .daddr = dst->ipv6,
> + .saddr = src->ipv6,
> + .flowi6_proto = IPPROTO_UDP
> + };
> + err = ipv6_stub->ipv6_dst_lookup(net, ub->ubsock->sk,
> + &ndst, &fl6);
> + if (err)
> + goto tx_error;
> + dst_cache_set_ip6(cache, ndst, &fl6.saddr);
> + }
> ttl = ip6_dst_hoplimit(ndst);
> err = udp_tunnel6_xmit_skb(ndst, ub->ubsock->sk, skb, NULL,
> &src->ipv6, &dst->ipv6, 0, ttl, 0, @@ -230,7
> +238,8 @@ static int tipc_udp_send_msg(struct net *net, struct sk_buff *skb,
> }
>
> if (addr->broadcast != TIPC_REPLICAST_SUPPORT)
> - return tipc_udp_xmit(net, skb, ub, src, dst);
> + return tipc_udp_xmit(net, skb, ub, src, dst,
> + &ub->rcast.dst_cache);
>
> /* Replicast, send an skb to each configured IP address */
> list_for_each_entry_rcu(rcast, &ub->rcast.list, list) { @@ -242,7 +251,8
> @@ static int tipc_udp_send_msg(struct net *net, struct sk_buff *skb,
> goto out;
> }
>
> - err = tipc_udp_xmit(net, _skb, ub, src, &rcast->addr);
> + err = tipc_udp_xmit(net, _skb, ub, src, &rcast->addr,
> + &rcast->dst_cache);
> if (err)
> goto out;
> }
> @@ -286,6 +296,11 @@ static int tipc_udp_rcast_add(struct tipc_bearer *b,
> if (!rcast)
> return -ENOMEM;
>
> + if (dst_cache_init(&rcast->dst_cache, GFP_ATOMIC)) {
> + kfree(rcast);
> + return -ENOMEM;
> + }
> +
> memcpy(&rcast->addr, addr, sizeof(struct udp_media_addr));
>
> if (ntohs(addr->proto) == ETH_P_IP)
> @@ -742,6 +757,10 @@ static int tipc_udp_enable(struct net *net, struct
> tipc_bearer *b,
> tuncfg.encap_destroy = NULL;
> setup_udp_tunnel_sock(net, ub->ubsock, &tuncfg);
>
> + err = dst_cache_init(&ub->rcast.dst_cache, GFP_ATOMIC);
> + if (err)
> + goto err;
> +
> /**
> * The bcast media address port is used for all peers and the ip
> * is used if it's a multicast address.
> @@ -756,6 +775,7 @@ static int tipc_udp_enable(struct net *net, struct
> tipc_bearer *b,
>
> return 0;
> err:
> + dst_cache_destroy(&ub->rcast.dst_cache);
> if (ub->ubsock)
> udp_tunnel_sock_release(ub->ubsock);
> kfree(ub);
> @@ -769,10 +789,12 @@ static void cleanup_bearer(struct work_struct
> *work)
> struct udp_replicast *rcast, *tmp;
>
> list_for_each_entry_safe(rcast, tmp, &ub->rcast.list, list) {
> + dst_cache_destroy(&rcast->dst_cache);
> list_del_rcu(&rcast->list);
> kfree_rcu(rcast, rcu);
> }
>
> + dst_cache_destroy(&ub->rcast.dst_cache);
> if (ub->ubsock)
> udp_tunnel_sock_release(ub->ubsock);
> synchronize_net();
> --
> 2.1.0
^ permalink raw reply
* Re: [PATCH v3 1/6] crypto: essiv - create wrapper template for ESSIV generation
From: Herbert Xu @ 2019-06-20 12:53 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Eric Biggers, open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
device-mapper development, linux-fscrypt, Gilad Ben-Yossef,
Milan Broz
In-Reply-To: <CAKv+Gu-OwzmoYR5uymSNghEVc9xbkkt5C8MxAYA48UE=yBgb5g@mail.gmail.com>
On Thu, Jun 20, 2019 at 09:30:41AM +0200, Ard Biesheuvel wrote:
>
> Is this the right approach? Or are there better ways to convey this
> information when instantiating the template?
> Also, it seems to me that the dm-crypt and fscrypt layers would
> require major surgery in order to take advantage of this.
Oh and you don't have to make dm-crypt use it from the start. That
is, you can just make things simple by doing it one sector at a
time in the dm-crypt code even though the underlying essiv code
supports multiple sectors.
Someone who cares about this is sure to come along and fix it later.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3 1/6] crypto: essiv - create wrapper template for ESSIV generation
From: Herbert Xu @ 2019-06-20 12:53 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-fscrypt, Eric Biggers, Gilad Ben-Yossef,
device-mapper development,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Milan Broz
In-Reply-To: <CAKv+Gu-OwzmoYR5uymSNghEVc9xbkkt5C8MxAYA48UE=yBgb5g@mail.gmail.com>
On Thu, Jun 20, 2019 at 09:30:41AM +0200, Ard Biesheuvel wrote:
>
> Is this the right approach? Or are there better ways to convey this
> information when instantiating the template?
> Also, it seems to me that the dm-crypt and fscrypt layers would
> require major surgery in order to take advantage of this.
Oh and you don't have to make dm-crypt use it from the start. That
is, you can just make things simple by doing it one sector at a
time in the dm-crypt code even though the underlying essiv code
supports multiple sectors.
Someone who cares about this is sure to come along and fix it later.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v5 2/8] hw/acpi: Do not create memory hotplug method when handler is not defined
From: Igor Mammedov @ 2019-06-20 12:45 UTC (permalink / raw)
To: Shameer Kolothum
Cc: peter.maydell, sameo, ard.biesheuvel, shannon.zhaosl, qemu-devel,
xuwei5, linuxarm, eric.auger, qemu-arm, sebastien.boeuf, lersek
In-Reply-To: <20190522162252.28568-3-shameerali.kolothum.thodi@huawei.com>
On Wed, 22 May 2019 17:22:46 +0100
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote:
> From: Samuel Ortiz <sameo@linux.intel.com>
>
> With Hardware-reduced ACPI, the GED device will manage ACPI
> hotplug entirely. As a consequence, make the memory specific
> events AML generation optional. The code will only be added
> when the method name is not NULL.
>
> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
> ---
> hw/acpi/memory_hotplug.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c
> index c724f5f1e4..7e30e6f886 100644
> --- a/hw/acpi/memory_hotplug.c
> +++ b/hw/acpi/memory_hotplug.c
> @@ -719,10 +719,12 @@ void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem,
> }
> aml_append(table, dev_container);
>
> - method = aml_method(event_handler_method, 0, AML_NOTSERIALIZED);
> - aml_append(method,
> - aml_call0(MEMORY_DEVICES_CONTAINER "." MEMORY_SLOT_SCAN_METHOD));
> - aml_append(table, method);
> + if (event_handler_method) {
> + method = aml_method(event_handler_method, 0, AML_NOTSERIALIZED);
> + aml_append(method, aml_call0(MEMORY_DEVICES_CONTAINER "."
> + MEMORY_SLOT_SCAN_METHOD));
> + aml_append(table, method);
> + }
>
> g_free(mhp_res_path);
> }
^ permalink raw reply
* ✓ Fi.CI.BAT: success for series starting with drm/i915/execlists: Preempt-to-busy (rev2)
From: Patchwork @ 2019-06-20 12:52 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20190620070559.30076-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: series starting with drm/i915/execlists: Preempt-to-busy (rev2)
URL : https://patchwork.freedesktop.org/series/62431/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6312 -> Patchwork_13361
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/
Known issues
------------
Here are the changes found in Patchwork_13361 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_module_load@reload:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-icl-u3/igt@i915_module_load@reload.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/fi-icl-u3/igt@i915_module_load@reload.html
* igt@i915_selftest@live_hangcheck:
- fi-icl-u2: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#108569])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][5] ([fdo#107718]) -> [PASS][6]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][7] ([fdo#109485]) -> [PASS][8]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (49 -> 45)
------------------------------
Additional (5): fi-cml-u2 fi-bxt-j4205 fi-gdg-551 fi-icl-dsi fi-cml-u
Missing (9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-apl-guc fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-------------
* Linux: CI_DRM_6312 -> Patchwork_13361
CI_DRM_6312: 034e3ac6a2d180d188da927388b60c7e62c5655b @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5061: c88ced79a7b71aec58f1d9c5c599ac2f431bcf7a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13361: bfa0c571526c8b843afc7e42fe124e39ff9d81d3 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
bfa0c571526c drm/i915/execlists: Force preemption
0b5d7fbe498b drm/i915/execlists: Minimalistic timeslicing
4769517df2d7 drm/i915/execlists: Preempt-to-busy
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13361/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] drm/todo: Update drm_gem_object_funcs todo even more
From: Daniel Vetter @ 2019-06-20 12:52 UTC (permalink / raw)
To: Eric Engestrom
Cc: David Airlie, Daniel Vetter, Intel Graphics Development,
DRI Development, Maxime Ripard, Gerd Hoffmann, Thomas Zimmermann,
Greg Kroah-Hartman, Daniel Vetter
In-Reply-To: <20190618182508.lp6n4zcgxj7lsu6l@intel.com>
On Tue, Jun 18, 2019 at 07:25:08PM +0100, Eric Engestrom wrote:
> On Tuesday, 2019-06-18 16:02:41 +0200, Daniel Vetter wrote:
> > I rushed merging this a bit too much, and Noralf pointed out that
> > we're a lot better already and have made great progress.
> >
> > Let's try again.
> >
> > Fixes: 42dbbb4b54a3 ("drm/todo: Add new debugfs todo")
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: David Airlie <airlied@linux.ie>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Noralf Trønnes <noralf@tronnes.org>
> > Cc: Eric Anholt <eric@anholt.net>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> > Documentation/gpu/todo.rst | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > index 25878dd048fd..66c123737c3d 100644
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -212,9 +212,11 @@ struct drm_gem_object_funcs
> > GEM objects can now have a function table instead of having the callbacks on the
> > DRM driver struct. This is now the preferred way and drivers can be moved over.
> >
> > -Unfortunately some of the recently added GEM helpers are going in the wrong
> > -direction by adding OPS macros that use the old, deprecated hooks. See
> > -DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and DRM_GEM_VRAM_DRIVER_PRIME.
> > +DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS already support this, but
> > +DRM_GEM_VRAM_DRIVER_PRIME does not yet and needs to be aligend with the previous
>
> s/aligend/aligned/
Fixed while applying.
-Daniel
>
> > +two. We also need a 2nd version of the CMA define that doesn't require the
> > +vmapping to be present (different hook for prime importing). Plus this needs to
> > +be rolled out to all drivers using their own implementations, too.
> >
> > Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
> > ---------------------------------------------------------
> > --
> > 2.20.1
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH net] net/sched: flower: fix infinite loop in fl_walk()
From: Davide Caratti @ 2019-06-20 12:52 UTC (permalink / raw)
To: Cong Wang
Cc: Vlad Buslov, David S. Miller, Linux Kernel Network Developers,
Lucas Bates
In-Reply-To: <CAM_iQpUVJ9sG9ETE0zZ_azbDgWp_oi320nWy_g-uh2YJWYDOXw@mail.gmail.com>
hello Cong, thanks for reading.
On Wed, 2019-06-19 at 15:04 -0700, Cong Wang wrote:
> On Wed, Jun 19, 2019 at 2:10 PM Davide Caratti <dcaratti@redhat.com> wrote:
> > on some CPUs (e.g. i686), tcf_walker.cookie has the same size as the IDR.
> > In this situation, the following script:
> >
> > # tc filter add dev eth0 ingress handle 0xffffffff flower action ok
> > # tc filter show dev eth0 ingress
> >
> > results in an infinite loop. It happened also on other CPUs (e.g x86_64),
> > before commit 061775583e35 ("net: sched: flower: introduce reference
> > counting for filters"), because 'handle' + 1 made the u32 overflow before
> > it was assigned to 'cookie'; but that commit replaced the assignment with
> > a self-increment of 'cookie', so the problem was indirectly fixed.
>
> Interesting... Is this really specific to cls_flower? To me it looks like
> a bug of idr_*_ul() API's, especially for idr_for_each_entry_ul().
good question, I have to investigate this better (idr_for_each_entry_ul()
expands in a iteration of idr_get_next_ul()). It surely got in cls_flower
when it was converted to use IDRs, but it's true that there might be other
points in TC where IDR are used and the same pattern is present (see
below).
> Can you test if the following command has the same problem on i386?
>
> tc actions add action ok index 4294967295
the action is added, but then reading it back results in an infinite loop.
And again, the infinite loop happens on i686 and not on x86_64. I will try
to see where's the problem also here.
--
davide
^ permalink raw reply
* [LTP] [PATCH v3] sysctl/sysctl02: Add new regression test for overflow file-max
From: Petr Vorel @ 2019-06-20 12:52 UTC (permalink / raw)
To: ltp
In-Reply-To: <1560156706-13617-1-git-send-email-xuyang2018.jy@cn.fujitsu.com>
Hi Yang,
> On upstream kernel, before commit[1], the max value in proc_get_long based on
> the number of chars(21). It rejects values such as 184467440737095516160 (21 chars)
> but accepts values such as 18446744073709551616 (20 chars). But we should reject all
> because both are overflows. After this commit,the permitted max value is 2^64-1.
> Before commit[2], when writing echo 18446744073709551616 > /proc/sys/fs/file-max
> /proc/sys/fs/file-max will overflow and be set to 0. It may crash the system. This
> commit sets the max and min value for file-max. After this commit,the permitted max
> value is 2^63-1.
> Unfortunately, commit[2] introduced the minimum value points at the global 'zero'
> variable which is an int. This results in a KASAN splat when accessed as a long by
> proc_doulongvec_minmax on 64-bit architectures. This bug has been fixed by commit[3].
> I will set 2^64 ,2^64-1,2^63 and 0 to file-max in case and test it.
> [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7f2923c4f73f21cfd714d12a2d48de8c21f11cfe
> [2]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=32a5ad9c22852e6bd9e74bdec5934ef9d1480bc5
> [3]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9002b21465fa4d829edfc94a5a441005cffaa972
Merged with adjusted commit message and following diff.
Due que big changes I put my copyright there as well.
Thanks for your patch!
Kind regards,
Petr
diff --git testcases/commands/sysctl/sysctl02.sh testcases/commands/sysctl/sysctl02.sh
index 22dd0a429..8a434183e 100755
--- testcases/commands/sysctl/sysctl02.sh
+++ testcases/commands/sysctl/sysctl02.sh
@@ -1,26 +1,18 @@
#!/bin/sh
-
# SPDX-License-Identifier: GPL-2.0-or-later
# Copyright (c) 2019 FUJITSU LIMITED. All rights reserved.
+# Copyright (c) 2019 Petr Vorel <pvorel@suse.cz>
# Author: Yang Xu<xuyang2018.jy@cn.fujitsu.com>
#
-# Description:
-# This is a regression test for handling overflow for file-max.
-#
-# when writing 2^64 to /proc/sys/fs/file-max. It will overflow
-# and be set to 0. It crash system quickly.
+# Test for these regressions causing buffer overflow when writing into
+# /proc/sys/fs/file-max:
+# 7f2923c4f73f ("sysctl: handle overflow in proc_get_long")
+# 32a5ad9c2285 ("sysctl: handle overflow for file-max")
#
-# The kernel bug has been fixed in kernel:
-# '7f2923c4f' (sysctl: handle overflow in proc_get_long)
-# the permitted max value is 2^64-1.
-# '32a5ad9c2' (sysctl: handle overflow for file-max)
-# the permitted max value is 2^63-1
+# This bug has been fixed in 9002b21465fa ("kernel/sysctl.c: fix
+# out-of-bounds access when setting file-max")
#
-# After merged this patchset, if we exceed the max value, it will
-# keep old value. Unfortunately, it introudced a new bug when set it
-# to 0 and it will lead to system crash.
-# This bug has been fixed by commit 9002b2146
-# (kernel/sysctl.c: fix out-of-bounds access when setting file-max)
+# We test in sysctl02.sh setting 2^64, 2^64-1, 2^63 and 0.
TST_TESTFUNC=do_test
TST_SETUP=setup
@@ -28,60 +20,52 @@ TST_CLEANUP=cleanup
TST_CNT=4
TST_NEEDS_ROOT=1
TST_NEEDS_CMDS="sysctl"
-dir="/proc/sys/fs/"
+sys_name="fs.file-max"
+sys_file="/proc/sys/fs/file-max"
syms_file="/proc/kallsyms"
-name="file-max"
-orig_value=200000
. tst_test.sh
setup()
{
- [ ! -f "$dir""$name" ] && tst_brk TCONF \
- "$name was not supported"
- orig_value=$(cat "$dir""$name")
+ [ ! -f "$sys_file" ] && tst_brk TCONF "$sys_file not enabled"
+ orig_value=$(cat "$sys_file")
}
do_test()
{
case $1 in
- 1)sysctl_test_overflow 18446744073709551616;;
- 2)sysctl_test_overflow 18446744073709551615;;
- 3)sysctl_test_overflow 9223372036854775808;;
- 4)sysctl_test_zero;;
+ 1) sysctl_test_overflow 18446744073709551616 ;;
+ 2) sysctl_test_overflow 18446744073709551615 ;;
+ 3) sysctl_test_overflow 9223372036854775808 ;;
+ 4) sysctl_test_zero ;;
esac
}
sysctl_test_overflow()
{
- local old_value=$(cat "$dir""$name")
-
- sysctl -w "fs.file-max"=$1 >/dev/null 2>&1
+ local old_value="$(cat $sys_file)"
+ sysctl -w -q $sys_name=$1 2>/dev/null
+ local test_value="$(cat $sys_file)"
- local test_value=$(cat "$dir""$name")
-
- echo ${test_value} |grep -q ${old_value}
- if [ $? -eq 0 ]; then
- tst_res TPASS "file-max overflow, reject it and keep old value."
+ if echo $test_value | grep -q $old_value; then
+ tst_res TPASS "$sys_file overflows, reject it and keep old value"
else
- tst_res TFAIL "file-max overflow and set it to ${test_value}."
+ tst_res TFAIL "$sys_file overflows and set to $test_value"
fi
cleanup
}
sysctl_test_zero()
{
- sysctl -w "fs.file-max"=0 >/dev/null 2>&1
- [ ! -f "$syms_file" ] && tst_brk TCONF \
- "$syms_file was not supported"
- cat $syms_file |grep kasan_report >/dev/null 2>&1
- if [ $? -eq 0 ]; then
- dmesg | grep "KASAN: global-out-of-bounds in __do_proc_doulongvec_minmax" >/dev/null
- if [ $? -eq 0 ]; then
- tst_res TFAIL "file-max is set 0 and trigger a KASAN error"
+ [ ! -f "$syms_file" ] && tst_brk TCONF "$syms_file not enabled"
+ ROD sysctl -w -q $sys_name=0
+
+ if grep -q kasan_report $syms_file; then
+ if dmesg | grep -q "KASAN: global-out-of-bounds in __do_proc_doulongvec_minmax"; then
+ tst_res TFAIL "$sys_file is set 0 and trigger a KASAN error"
else
- tst_res TPASS \
- "file-max is set 0 and doesn't trigger a KASAN error"
+ tst_res TPASS "$sys_file is set 0 and doesn't trigger a KASAN error"
fi
else
tst_res TCONF "kernel doesn't support KASAN"
@@ -90,7 +74,7 @@ sysctl_test_zero()
cleanup()
{
- sysctl -w "fs.""$name"=${orig_value} >/dev/null 2>&1
+ [ -n "$orig_value" ] && sysctl -w -q $sys_name=$orig_value
}
tst_run
^ permalink raw reply related
* Re: [PATCH v3 1/6] crypto: essiv - create wrapper template for ESSIV generation
From: Herbert Xu @ 2019-06-20 12:52 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Eric Biggers, open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
device-mapper development, linux-fscrypt, Gilad Ben-Yossef,
Milan Broz
In-Reply-To: <CAKv+Gu-OwzmoYR5uymSNghEVc9xbkkt5C8MxAYA48UE=yBgb5g@mail.gmail.com>
On Thu, Jun 20, 2019 at 09:30:41AM +0200, Ard Biesheuvel wrote:
>
> Is this the right approach? Or are there better ways to convey this
> information when instantiating the template?
> Also, it seems to me that the dm-crypt and fscrypt layers would
> require major surgery in order to take advantage of this.
My preference would be to encode the sector size into the key.
Hardware that can only support some sector sizes can use fallbacks
as usual.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3 1/6] crypto: essiv - create wrapper template for ESSIV generation
From: Herbert Xu @ 2019-06-20 12:52 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-fscrypt, Eric Biggers, Gilad Ben-Yossef,
device-mapper development,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Milan Broz
In-Reply-To: <CAKv+Gu-OwzmoYR5uymSNghEVc9xbkkt5C8MxAYA48UE=yBgb5g@mail.gmail.com>
On Thu, Jun 20, 2019 at 09:30:41AM +0200, Ard Biesheuvel wrote:
>
> Is this the right approach? Or are there better ways to convey this
> information when instantiating the template?
> Also, it seems to me that the dm-crypt and fscrypt layers would
> require major surgery in order to take advantage of this.
My preference would be to encode the sector size into the key.
Hardware that can only support some sector sizes can use fallbacks
as usual.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t v3] Add Arm drivers as supported drivers by igt.
From: Petri Latvala @ 2019-06-20 12:51 UTC (permalink / raw)
To: Liviu Dudau; +Cc: IGT GPU Tool
In-Reply-To: <20190620124254.6736-1-liviu.dudau@arm.com>
On Thu, Jun 20, 2019 at 01:42:54PM +0100, Liviu Dudau wrote:
> Add the drivers maintained by Arm developers to the igt.
>
> v3: Update the mali-dp driver's name to match kernel driver code.
> v2: Order the modules array entries alphabetically, as per
> Petri Latvala's suggestion.
>
> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
> ---
> lib/drmtest.c | 3 +++
> lib/drmtest.h | 4 ++++
> 2 files changed, 7 insertions(+)
>
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index 25f203530..8243247a3 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -205,7 +205,10 @@ static const struct module {
> void (*modprobe)(const char *name);
> } modules[] = {
> { DRIVER_AMDGPU, "amdgpu" },
> + { DRIVER_HDLCD, "hdlcd" },
> { DRIVER_INTEL, "i915", modprobe_i915 },
> + { DRIVER_KOMEDA, "komeda" },
> + { DRIVER_MALIDP, "mali-dp" },
> { DRIVER_PANFROST, "panfrost" },
> { DRIVER_V3D, "v3d" },
> { DRIVER_VC4, "vc4" },
> diff --git a/lib/drmtest.h b/lib/drmtest.h
> index 6c4c3899c..952f0c4b6 100644
> --- a/lib/drmtest.h
> +++ b/lib/drmtest.h
> @@ -45,6 +45,10 @@
> #define DRIVER_AMDGPU (1 << 4)
> #define DRIVER_V3D (1 << 5)
> #define DRIVER_PANFROST (1 << 6)
> +#define DRIVER_HDLCD (1 << 7)
> +#define DRIVER_MALIDP (1 << 8)
> +#define DRIVER_KOMEDA (1 << 9)
> +
> /*
> * Exclude DRVER_VGEM from DRIVER_ANY since if you run on a system
> * with vgem as well as a supported driver, you can end up with a
> --
> 2.22.0
>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH] perf/rapl: restart perf rapl counter after resume
From: Peter Zijlstra @ 2019-06-20 12:50 UTC (permalink / raw)
To: Zhang Rui
Cc: linux-x86, LKML, mingo, acme, alexander.shishkin, jolsa, namhyung,
tglx, Liang, Kan
In-Reply-To: <1560778897.10723.6.camel@intel.com>
On Mon, Jun 17, 2019 at 09:41:37PM +0800, Zhang Rui wrote:
> After S3 suspend/resume, "perf stat -I 1000 -e power/energy-pkg/ -a"
> reports an insane value for the very first sampling period after resume
> as shown below.
>
> 19.278989977 2.16 Joules power/energy-pkg/
> 20.279373569 1.96 Joules power/energy-pkg/
> 21.279765481 2.09 Joules power/energy-pkg/
> 22.280305420 2.10 Joules power/energy-pkg/
> 25.504782277 4,294,966,686.01 Joules power/energy-pkg/
> 26.505114993 3.58 Joules power/energy-pkg/
> 27.505471758 1.66 Joules power/energy-pkg/
>
> Fix this by resetting the counter right after resume.
Cute...
> +#ifdef CONFIG_PM
> +
> +static int perf_rapl_suspend(void)
> +{
> + int i;
> +
> + get_online_cpus();
> + for (i = 0; i < rapl_pmus->maxpkg; i++)
> + rapl_pmu_update_all(rapl_pmus->pmus[i]);
> + put_online_cpus();
> + return 0;
> +}
> +
> +static void perf_rapl_resume(void)
> +{
> + int i;
> +
> + get_online_cpus();
> + for (i = 0; i < rapl_pmus->maxpkg; i++)
> + rapl_pmu_restart_all(rapl_pmus->pmus[i]);
> + put_online_cpus();
> +}
What's the reason for that get/put_online_cpus() here ?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.