Re: [RFC PATCH v2 1/2] locking/rwsem: Add a new RWSEM_WRITER_OWNED_NOSPIN flag
On Mon, May 14, 2018 at 10:31 PM, Waiman Long wrote: > There are use cases where a rwsem can be acquired by one task, but > released by another task. In thess cases, it may not be appropriate > for the lock waiters to spin on the task that acquires the lock. > One example will be the filesystem freeze/thaw code. > > To handle such use cases, a new RWSEM_WRITER_OWNED_NOSPIN > flag can now be set in the owner field of the rwsem by the new > rwsem_set_writer_owned_nospin() function to indicate that the rwsem is > writer owned, but optimistic spinning on the rwsem should be disabled. > > Later on, the new rwsem_set_writer_owned() function can be called to > set the new owner, if it is known. This function should not be called > without a prior rwsem_set_writer_owned_nospin() call. > > Signed-off-by: Waiman Long Makes sense to me. one nit. > > +static inline void __rwsem_set_writer_owned(struct rw_semaphore *sem, > + struct task_struct *task) rwsem_set_owner() doesn't pass in task argument and IMO __rwsem_set_writer_owned() shouldn't either. Thanks, Amir.
Re: [RFC] mm, THP: Map read-only text segments using large THP pages
> On May 14, 2018, at 9:19 AM, Christopher Lameter wrote: > > Cool. This could be controlled by the faultaround logic right? If we get > fault_around_bytes up to huge page size then it is reasonable to use a > huge page directly. It isn't presently but certainly could be; for the prototype it tries to map a large page when needed and, should that fail, it will fall through to the normal fault around code. I would think we would want a separate parameter, as I can see the usefulness of more fine-grained control. Many users may want to try mapping a large page if possible, but would prefer a smaller number of bytes to be read in fault around should we need to fall back to using PAGESIZE pages. > fault_around_bytes can be set via sysfs so there is a natural way to > control this feature there I think. I agree; perhaps I could use "fault_around_thp_bytes" or something similar. >> Since this approach will map a PMD size block of the memory map at a time, we >> should see a slight uptick in time spent in disk I/O but a substantial drop >> in >> page faults as well as a reduction in iTLB misses as address ranges will be >> mapped with the larger page. Analysis of a test program that consists of a >> very >> large text area (483,138,032 bytes in size) that thrashes D$ and I$ shows >> this >> does occur and there is a slight reduction in program execution time. > > I think we would also want such a feature for regular writable pages as > soon as possible. That is my ultimate long-term goal for this project - full r/w support of large THP pages; prototyping with read-only text pages seemed like the best first step to get a sense of the possible benefits. -- Bill
Re: [PATCH 1/4] amba: Export amba_bustype
On 8 May 2018 at 21:06, Kim Phillips wrote: > This patch is provided in the context of allowing the Coresight driver > subsystem to be loaded as modules. Coresight uses amba_bus in its call > to bus_find_device() in of_coresight_get_endpoint_device() when > searching for a configurable endpoint device. This patch allows > Coresight to reference amba_bustype when built as a module. Sounds like you are fixing a bug, don't your want this to go for stable and then also add a fixes tag? > > Cc: Mathieu Poirier > Cc: Alex Williamson > Cc: Eric Auger > Cc: Russell King > Cc: Greg Kroah-Hartman > Cc: Todd Kjos > Cc: Geert Uytterhoeven > Cc: Thierry Reding > Cc: Robin Murphy > Signed-off-by: Kim Phillips Reviewed-by: Ulf Hansson [...] Kind regards Uffe
Re: [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
On 05/15/2018 12:40 AM, Neil Armstrong wrote:
> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
> driver for such feature of the Embedded Controller.
>
> This driver is part of the cros-ec MFD and will be add as a sub-device when
> the feature bit is exposed by the EC.
>
> The controller will only handle a single logical address and handles
> all the messages retries and will only expose Success or Error.
>
> When the logical address is invalid, the controller will act as a CEC sniffer
> and transfer all messages on the bus.
I did not see any support for this. If this works as you state here, then adding
support for CEC_CAP_MONITOR_ALL is highly recommended.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/media/platform/Kconfig | 11 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/cros-ec/Makefile | 1 +
> drivers/media/platform/cros-ec/cros-ec-cec.c | 331
> +++
> 4 files changed, 345 insertions(+)
> create mode 100644 drivers/media/platform/cros-ec/Makefile
> create mode 100644 drivers/media/platform/cros-ec/cros-ec-cec.c
Shouldn't the directory be called cros-ec-cec?
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c7a1cf8..e55a8ed2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
>
> if CEC_PLATFORM_DRIVERS
>
> +config VIDEO_CROS_EC_CEC
> + tristate "Chrome OS EC CEC driver"
> + depends on MFD_CROS_EC || COMPILE_TEST
> + select CEC_CORE
> + select CEC_NOTIFIER
> + ---help---
> + If you say yes here you will get support for the
> + Chrome OS Embedded Controller's CEC.
> + The CEC bus is present in the HDMI connector and enables communication
> + between compatible devices.
> +
> config VIDEO_MESON_AO_CEC
> tristate "Amlogic Meson AO CEC driver"
> depends on ARCH_MESON || COMPILE_TEST
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 932515d..0e0582e 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS) +=
> qcom/camss-8x16/
> obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
>
> obj-y+= meson/
> +
> +obj-y+= cros-ec/
> diff --git a/drivers/media/platform/cros-ec/Makefile
> b/drivers/media/platform/cros-ec/Makefile
> new file mode 100644
> index 000..9ce97f9
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
> diff --git a/drivers/media/platform/cros-ec/cros-ec-cec.c
> b/drivers/media/platform/cros-ec/cros-ec-cec.c
> new file mode 100644
> index 000..fea90da
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec/cros-ec-cec.c
> @@ -0,0 +1,331 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * CEC driver for Chrome OS Embedded Controller
> + *
> + * Copyright (c) 2018 BayLibre, SAS
> + * Author: Neil Armstrong
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRV_NAME "cros-ec-cec"
> +
> +/**
> + * struct cros_ec_cec - Driver data for EC CEC
> + *
> + * @cros_ec: Pointer to EC device
> + * @notifier: Notifier info for responding to EC events
> + * @adap: CEC adapter
> + * @notify: CEC notifier pointer
> + * @rc_msg: storage for a received message
> + */
> +struct cros_ec_cec {
> + struct cros_ec_device *cros_ec;
> + struct notifier_block notifier;
> + struct cec_adapter *adap;
> + struct cec_notifier *notify;
> + struct cec_msg rx_msg;
> +};
> +
> +static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint8_t *cec_message = cros_ec->event_data.data.cec_message;
> + unsigned int len = cros_ec->event_size;
> +
> + cros_ec_cec->rx_msg.len = len;
How robust is the underlying code and hardware? What happens if a
CEC message with more than 16 bytes is received?
Hard to test unless you have an RPi3 set up as a CEC debugger. See
last section in https://hverkuil.home.xs4all.nl/cec-status.txt.
Since you worked with CEC for a while now I recommend you set up such
a system. It's cheap and very useful.
> + memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
> +
> + cec_received_msg(cros_ec_cec->adap, &cros_ec_cec->rx_msg);
> +}
> +
> +static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint32_t events = cros_ec->event_data.data.cec_events;
> +
> + if (events & EC_MKBP_CEC_SEND_OK)
> + cec_transmit_attempt_done(cros_ec_cec->adap,
> +
Re: [PATCH 8/9] perf/breakpoint: Split breakpoint "check" and "commit"
* Peter Zijlstra wrote:
> On Sun, May 06, 2018 at 09:19:54PM +0200, Frederic Weisbecker wrote:
> > arch/arm/include/asm/hw_breakpoint.h | 5 -
> > arch/arm/kernel/hw_breakpoint.c | 22 +++---
> > arch/arm64/include/asm/hw_breakpoint.h | 5 -
> > arch/arm64/kernel/hw_breakpoint.c| 22 +++---
> > arch/powerpc/include/asm/hw_breakpoint.h | 5 -
> > arch/powerpc/kernel/hw_breakpoint.c | 22 +++---
> > arch/sh/include/asm/hw_breakpoint.h | 5 -
> > arch/sh/kernel/hw_breakpoint.c | 22 +++---
> > arch/x86/include/asm/hw_breakpoint.h | 5 -
> > arch/x86/kernel/hw_breakpoint.c | 23 +++
> > arch/xtensa/include/asm/hw_breakpoint.h | 5 -
> > arch/xtensa/kernel/hw_breakpoint.c | 22 +++---
>
> Because of those ^,
>
> > kernel/events/hw_breakpoint.c| 11 ++-
>
> would it not make sense to have a prelimenary patch doing something
> like:
>
> __weak int hw_breakpoint_arch_check(struct perf_event *bp)
> {
> return arch_validate_hwbkpt_settings(bp);
> }
>
> __weak void hw_breakpoint_arch_commit(struct perf_event *bp)
> {
> }
>
> combined with this bit:
>
> > diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
> > index 6e28d28..6896ceeb 100644
> > --- a/kernel/events/hw_breakpoint.c
> > +++ b/kernel/events/hw_breakpoint.c
> > @@ -402,11 +402,12 @@ int dbg_release_bp_slot(struct perf_event *bp)
> >
> > static int validate_hw_breakpoint(struct perf_event *bp)
> > {
> > - int ret;
> > + int err;
> >
> > - ret = arch_validate_hwbkpt_settings(bp);
> > - if (ret)
> > - return ret;
> > + err = hw_breakpoint_arch_check(bp, &bp->attr);
> > + if (err)
> > + return err;
> > + hw_breakpoint_arch_commit(bp);
> >
> > if (arch_check_bp_in_kernelspace(bp)) {
> > if (bp->attr.exclude_kernel)
>
> And then convert the archs over one by one, and at the end remove the
> weak thingies entirely?
Makes sense.
The rest looks good to me - Frederic, once you implement Peter's uggestion I
suspect this series can be applied.
Thanks,
Ingo
Re: [PATCH] thermal: qcom: tsens: Allow number of sensors to come from DT
On Tue, May 8, 2018 at 2:53 AM, Bjorn Andersson
wrote:
> For platforms that has multiple copies of the TSENS hardware block it's
> necessary to be able to specify the number of sensors per block in DeviceTree.
>
> Signed-off-by: Bjorn Andersson
Just one comment below, otherwise,
Reviewed-by: Amit Kucheria
> ---
> .../devicetree/bindings/thermal/qcom-tsens.txt | 1 +
> drivers/thermal/qcom/tsens.c | 12 +---
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> index 292ed89d900b..06195e8f35e2 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> @@ -8,6 +8,7 @@ Required properties:
>
> - reg: Address range of the thermal registers
> - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
> +- #qcom,sensors: Number of sensors in tsens block
> - Refer to Documentation/devicetree/bindings/nvmem/nvmem.txt to know how to
> specify
> nvmem cells
>
> diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> index 3f9fe6aa51cc..20f3b87d7667 100644
> --- a/drivers/thermal/qcom/tsens.c
> +++ b/drivers/thermal/qcom/tsens.c
> @@ -116,6 +116,7 @@ static int tsens_probe(struct platform_device *pdev)
> struct tsens_device *tmdev;
> const struct tsens_data *data;
> const struct of_device_id *id;
> + u32 num_sensors;
>
> if (pdev->dev.of_node)
> dev = &pdev->dev;
> @@ -130,18 +131,23 @@ static int tsens_probe(struct platform_device *pdev)
> else
> data = &data_8960;
>
> - if (data->num_sensors <= 0) {
> + num_sensors = data->num_sensors;
> +
Probably worth adding a comment that we're overriding the num_sensors
from DT if available here.
> + if (np)
> + of_property_read_u32(np, "#qcom,sensors", &num_sensors);
> +
> + if (num_sensors <= 0) {
> dev_err(dev, "invalid number of sensors\n");
> return -EINVAL;
> }
>
> tmdev = devm_kzalloc(dev, sizeof(*tmdev) +
> -data->num_sensors * sizeof(*s), GFP_KERNEL);
> +num_sensors * sizeof(*s), GFP_KERNEL);
> if (!tmdev)
> return -ENOMEM;
>
> tmdev->dev = dev;
> - tmdev->num_sensors = data->num_sensors;
> + tmdev->num_sensors = num_sensors;
> tmdev->ops = data->ops;
> for (i = 0; i < tmdev->num_sensors; i++) {
> if (data->hw_ids)
> --
> 2.17.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-next: Tree for May 15
Hi all, News: I will not be doing any linux-next releases between Friday 18 May and Friday 25 May inclusive. Changes since 20180514: New trees: drivers-x86-fixes mmc-fixes rtc-fixes The kbuild tree gained a build failure for which I applied a patch. The audit tree gained a conflict against the selinux tree. Non-merge commits (relative to Linus' tree): 6142 5863 files changed, 227704 insertions(+), 107999 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 274 trees (counting Linus' and 61 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (67b8d5c70812 Linux 4.17-rc5) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (75bc37fefc44 Linux 4.17-rc4) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (30cfae461581 ARM: replace unnecessary perl with sed and the shell $(( )) operator) Merging arm64-fixes/for-next/fixes (0583a4ef0598 arm64: capabilities: Add NVIDIA Denver CPU to bp_harden list) Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" comment) Merging powerpc-fixes/fixes (6c0a8f6b5a45 powerpc/pseries: Fix CONFIG_NUMA=n build) Merging sparc/master (fff75eb2a08c Merge tag 'errseq-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (d49baa7e12ee net/smc: check for missing nlattrs in SMC_PNETID messages) Merging bpf/master (3597683c9da6 tools: bpf: handle NULL return in bpf_prog_load_xattr()) Merging ipsec/master (d9f92772e8ec xfrm6: avoid potential infinite loop in _decode_session6()) Merging netfilter/master (9d6b4bfb59a0 Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging ipvs/master (2f99aa31cd7a netfilter: nf_tables: skip synchronize_rcu if transaction log is empty) Merging wireless-drivers/master (ebd27d3317c6 ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y) Merging mac80211/master (914eac248d87 mac80211: use timeout from the AddBA response instead of the request) Merging rdma-fixes/for-rc (9aa169213d11 RDMA/cma: Do not query GID during QP state transition to RTR) Merging sound-current/for-linus (2f0d520a1a73 ALSA: hda/realtek - Clevo P950ER ALC1220 Fixup) Merging sound-asoc-fixes/for-linus (1ade2b2f9a3b Merge branch 'asoc-4.17' into asoc-linus) Merging regmap-fixes/for-linus (e37563bb6c59 Merge tag 'for-4.17-part2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux) Merging regulator-fixes/for-linus (e37563bb6c59 Merge tag 'for-4.17-part2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux) Merging spi-fixes/for-linus (c3317999e7ff Merge branch 'spi-4.17' into spi-linus) Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to pcie_print_link_status() messages) Merging driver-core.current/driver-core-linus (6da6c0db5316 Linux v4.17-rc3) Merging tty.current/tty-linus (6da6c0db5316 Linux v4.17-rc3) Merging usb.current/usb-linus (ebc3dd688cd9 usb: musb: fix remote wakeup racing with suspend) Merging usb-gadget-fixes/fixes (
Re: [PATCH] x86: pad assembly functions with INT3
* h...@zytor.com wrote: > > I guess it won't try to speculatively execute the 'pad' instructions - but > > you > > can never really tell! > > > > David > > The CPU doesn't speculate down past an unconditional control transfer. Doing > so > would be idiotic. I think, when it comes to speculative execution, our general expectation that CPUs don't do idiotic things got somewhat weakened in the past year or so ... Thanks, Ingo
Re: [PATCH v5 13/23] iommu: introduce device fault report API
Hi,
On 05/15/2018 04:55 AM, Jacob Pan wrote:
> On Mon, 14 May 2018 14:01:06 +0800
> Lu Baolu wrote:
>
>> Hi,
>>
>> On 05/12/2018 04:54 AM, Jacob Pan wrote:
>>> Traditionally, device specific faults are detected and handled
>>> within their own device drivers. When IOMMU is enabled, faults such
>>> as DMA related transactions are detected by IOMMU. There is no
>>> generic reporting mechanism to report faults back to the in-kernel
>>> device driver or the guest OS in case of assigned devices.
>>>
>>> Faults detected by IOMMU is based on the transaction's source ID
>>> which can be reported at per device basis, regardless of the device
>>> type is a PCI device or not.
>>>
>>> The fault types include recoverable (e.g. page request) and
>>> unrecoverable faults(e.g. access error). In most cases, faults can
>>> be handled by IOMMU drivers internally. The primary use cases are as
>>> follows:
>>> 1. page request fault originated from an SVM capable device that is
>>> assigned to guest via vIOMMU. In this case, the first level page
>>> tables are owned by the guest. Page request must be propagated to
>>> the guest to let guest OS fault in the pages then send page
>>> response. In this mechanism, the direct receiver of IOMMU fault
>>> notification is VFIO, which can relay notification events to QEMU
>>> or other user space software.
>>>
>>> 2. faults need more subtle handling by device drivers. Other than
>>> simply invoke reset function, there are needs to let device driver
>>> handle the fault with a smaller impact.
>>>
>>> This patchset is intended to create a generic fault report API such
>>> that it can scale as follows:
>>> - all IOMMU types
>>> - PCI and non-PCI devices
>>> - recoverable and unrecoverable faults
>>> - VFIO and other other in kernel users
>>> - DMA & IRQ remapping (TBD)
>>> The original idea was brought up by David Woodhouse and discussions
>>> summarized at https://lwn.net/Articles/608914/.
>>>
>>> Signed-off-by: Jacob Pan
>>> Signed-off-by: Ashok Raj
>>> Signed-off-by: Jean-Philippe Brucker
>>> ---
>>> drivers/iommu/iommu.c | 149
>>> +-
>>> include/linux/iommu.h | 35 +++- 2 files changed, 181
>>> insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>> index 3a49b96..b3f9daf 100644
>>> --- a/drivers/iommu/iommu.c
>>> +++ b/drivers/iommu/iommu.c
>>> @@ -609,6 +609,13 @@ int iommu_group_add_device(struct iommu_group
>>> *group, struct device *dev) goto err_free_name;
>>> }
>>>
>>> + dev->iommu_param = kzalloc(sizeof(*dev->iommu_param),
>>> GFP_KERNEL);
>>> + if (!dev->iommu_param) {
>>> + ret = -ENOMEM;
>>> + goto err_free_name;
>>> + }
>>> + mutex_init(&dev->iommu_param->lock);
>>> +
>>> kobject_get(group->devices_kobj);
>>>
>>> dev->iommu_group = group;
>>> @@ -639,6 +646,7 @@ int iommu_group_add_device(struct iommu_group
>>> *group, struct device *dev) mutex_unlock(&group->mutex);
>>> dev->iommu_group = NULL;
>>> kobject_put(group->devices_kobj);
>>> + kfree(dev->iommu_param);
>>> err_free_name:
>>> kfree(device->name);
>>> err_remove_link:
>>> @@ -685,7 +693,7 @@ void iommu_group_remove_device(struct device
>>> *dev) sysfs_remove_link(&dev->kobj, "iommu_group");
>>>
>>> trace_remove_device_from_group(group->id, dev);
>>> -
>>> + kfree(dev->iommu_param);
>>> kfree(device->name);
>>> kfree(device);
>>> dev->iommu_group = NULL;
>>> @@ -820,6 +828,145 @@ int iommu_group_unregister_notifier(struct
>>> iommu_group *group,
>>> EXPORT_SYMBOL_GPL(iommu_group_unregister_notifier);
>>> /**
>>> + * iommu_register_device_fault_handler() - Register a device fault
>>> handler
>>> + * @dev: the device
>>> + * @handler: the fault handler
>>> + * @data: private data passed as argument to the handler
>>> + *
>>> + * When an IOMMU fault event is received, call this handler with
>>> the fault event
>>> + * and data as argument. The handler should return 0 on success.
>>> If the fault is
>>> + * recoverable (IOMMU_FAULT_PAGE_REQ), the handler can also
>>> complete
>>> + * the fault by calling iommu_page_response() with one of the
>>> following
>>> + * response code:
>>> + * - IOMMU_PAGE_RESP_SUCCESS: retry the translation
>>> + * - IOMMU_PAGE_RESP_INVALID: terminate the fault
>>> + * - IOMMU_PAGE_RESP_FAILURE: terminate the fault and stop
>>> reporting
>>> + * page faults if possible.
>>> + *
>>> + * Return 0 if the fault handler was installed successfully, or an
>>> error.
>>> + */
>>> +int iommu_register_device_fault_handler(struct device *dev,
>>> + iommu_dev_fault_handler_t
>>> handler,
>>> + void *data)
>>> +{
>>> + struct iommu_param *param = dev->iommu_param;
>>> + int ret = 0;
>>> +
>>> + /*
>>> +* Device iommu_param should have been allocated when
>>> device is
>>> +* added to its iommu_group.
>>> +*/
>>> + if (!param)
>>> +
Re: use memcpy_mcsafe() for copy_to_iter() (was: Re: [PATCH v3 0/9] Series short description)
* Dan Williams wrote: > On Mon, May 14, 2018 at 12:26 AM, Ingo Molnar wrote: > > > > * Dan Williams wrote: > > > >> Ingo, Thomas, Al, any concerns with this series? > > > > Yeah, so: > > > >"[PATCH v3 0/9] Series short description" > > > > ... isn't the catchiest of titles to capture my [all too easily distracted] > > attention! ;-) > > My bad! After that mistake it became a toss-up between more spam and > hoping the distraction would not throw you off. > > > I have marked it now for -tip processing. Linus was happy with this and > > acked the > > approach, right? > > I think "happy" is a strong word when it comes to x86 machine check > handling. My interpretation is that he and Andy acquiesced that this > is about the best we can do with dax+mce as things stand today. So, how would you like to go about this series? To help move it forward I applied the first 5 commits to tip:x86/dax, on a vanilla v4.17-rc5 base, did some minor edits to the changelogs, tested it superficially (I don't have DAX so this essentially means build tests) and pushed out the result. Barring some later generic-x86 regression (unlikely) this looks good to me - feel free to cross-pull that branch into your DAX/nvdimm tree. Or we could apply the remaining changes to -tip too - your call. Thanks, Ingo
Re: [PATCH 4.16 00/72] 4.16.9-stable review
On Tue, May 15, 2018 at 11:01:53AM +0530, Naresh Kamboju wrote: > On 14 May 2018 at 12:18, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.16.9 release. > > There are 72 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 Wed May 16 06:47:58 UTC 2018. > > 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/v4.x/stable-review/patch-4.16.9-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-4.16.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Results from Linaro’s test farm. > No regressions on arm64, arm and x86_64. Wonderful, thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 4.16 00/72] 4.16.9-stable review
On Mon, May 14, 2018 at 04:01:22PM -0600, Shuah Khan wrote: > On 05/14/2018 12:48 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.16.9 release. > > There are 72 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 Wed May 16 06:47:58 UTC 2018. > > 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/v4.x/stable-review/patch-4.16.9-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-4.16.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
Re: [PATCH] Skip clk_put for attached clocks when freeing context
On Tue, May 15, 2018 at 10:50:17AM +1000, James Kelly wrote: > Capability to attach an existing clk to a MMIO regmap was > introduced in 4.17rc1. > > However, when using attached clk, regmap does not do the clk_get. > Therefore it should not do the clk_put when freeing the MMIO > regmap context. > > There does not appear to be any users of attached clocks yet > so this would be a good time to make this change before anything > depends on the existing behaviour. > > Signed-off-by: James Kelly Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
[tip:perf/urgent] perf tools: Add missing newline when parsing empty BPF proggie
Commit-ID: c23080a6e4e853cff2834436e3cf33eae7723900
Gitweb: https://git.kernel.org/tip/c23080a6e4e853cff2834436e3cf33eae7723900
Author: Arnaldo Carvalho de Melo
AuthorDate: Thu, 3 May 2018 15:59:58 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 11 May 2018 12:10:02 -0300
perf tools: Add missing newline when parsing empty BPF proggie
This is not specific to BPF but was found when parsing a .c BPF proggie
that while valid, had no events attached to tracepoints, kprobes, etc:
Very minimal file that perf's BPF code can compile:
# cat empty.c
char _license[] __attribute__((section("license"), used)) = "GPL";
int _version __attribute__((section("version"), used)) = LINUX_VERSION_CODE;
#
Before this patch:
# perf trace -e empty.c
WARNING: event parser found nothinginvalid or unsupported event: 'empty.c'
Run 'perf list' for a list of valid events
Usage: perf trace [] []
or: perf trace [] -- []
or: perf trace record [] []
or: perf trace record [] -- []
-e, --eventevent/syscall selector. use 'perf list' to list
available events
#
After:
# perf trace -e empty.c
WARNING: event parser found nothing
invalid or unsupported event: 'empty.c'
Run 'perf list' for a list of valid events
Usage: perf trace [] []
or: perf trace [] -- []
or: perf trace record [] []
or: perf trace record [] -- []
-e, --eventevent/syscall selector. use 'perf list' to list
available events
#
Cc: Adrian Hunter
Cc: David Ahern
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Wang Nan
Link: https://lkml.kernel.org/n/tip-8ysughiz00h6mjpcot04q...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 2fb0272146d8..b8b8a9558d32 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1715,7 +1715,7 @@ int parse_events(struct perf_evlist *evlist, const char
*str,
struct perf_evsel *last;
if (list_empty(&parse_state.list)) {
- WARN_ONCE(true, "WARNING: event parser found nothing");
+ WARN_ONCE(true, "WARNING: event parser found
nothing\n");
return -1;
}
[tip:perf/urgent] perf cs-etm: Remove redundant space
Commit-ID: 3a0887997d6731e1005ba09c93aa5c2898c78931
Gitweb: https://git.kernel.org/tip/3a0887997d6731e1005ba09c93aa5c2898c78931
Author: Leo Yan
AuthorDate: Thu, 10 May 2018 12:02:00 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 11 May 2018 10:46:36 -0300
perf cs-etm: Remove redundant space
There have two spaces ahead function name cs_etm__set_pid_tid_cpu(), so
remove one space and correct indentation.
Signed-off-by: Leo Yan
Acked-by: Mathieu Poirier
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: linux-arm-ker...@lists.infradead.org
Link:
http://lkml.kernel.org/r/1525924920-4381-2-git-send-email-leo@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/cs-etm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 2bf28b5acc08..bf16dc9ee507 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -613,8 +613,8 @@ cs_etm__get_trace(struct cs_etm_buffer *buff, struct
cs_etm_queue *etmq)
return buff->len;
}
-static void cs_etm__set_pid_tid_cpu(struct cs_etm_auxtrace *etm,
-struct auxtrace_queue *queue)
+static void cs_etm__set_pid_tid_cpu(struct cs_etm_auxtrace *etm,
+ struct auxtrace_queue *queue)
{
struct cs_etm_queue *etmq = queue->priv;
[tip:perf/urgent] perf annotate: Display all available events on --stdio
Commit-ID: 04d2600ab669b2d44dd7920cc8a1b95c8144084c
Gitweb: https://git.kernel.org/tip/04d2600ab669b2d44dd7920cc8a1b95c8144084c
Author: Jin Yao
AuthorDate: Wed, 9 May 2018 23:57:15 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 10 May 2018 15:19:30 -0300
perf annotate: Display all available events on --stdio
When we perform the following command lines:
$ perf record -e "{cycles,branches}" ./div
$ perf annotate main --stdio
The output shows only the first event, "cycles" and the displaying
format is not correct.
Percent | Source code & Disassembly of div for cycles (44550
samples)
---
:
:
:
:Disassembly of section .text:
:
:004004b0 :
:main():
:
:return i;
:}
:
:int main(void)
:{
0.00 : 4004b0: push %rbx
:int i;
:int flag;
:volatile double x = 1212121212, y =
121212;
:
:s_randseed = time(0);
0.00 : 4004b1: xor%edi,%edi
:srand(s_randseed);
0.00 : 4004b3: mov$0x77359400,%ebx
:
:return i;
:}
The issue is that the value of the 'nr_percent' variable is hardcoded to
1. This patch fixes it.
With this patch, the output is:
Percent | Source code & Disassembly of div for cycles (44550
samples)
---
:
:
:
:Disassembly of section .text:
:
:004004b0 :
:main():
:
:return i;
:}
:
:int main(void)
:{
0.000.00 : 4004b0: push %rbx
:int i;
:int flag;
:volatile double x = 1212121212, y =
121212;
:
:s_randseed = time(0);
0.000.00 : 4004b1: xor%edi,%edi
:srand(s_randseed);
0.000.00 : 4004b3: mov$0x77359400,%ebx
:
:return i;
:}
Signed-off-by: Jin Yao
Tested-by: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Kan Liang
Cc: Peter Zijlstra
Fixes: f681d593d1ce ("perf annotate: Remove disasm__calc_percent() from
disasm_line__print()")
Link:
http://lkml.kernel.org/r/1525881435-4092-1-git-send-email-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/annotate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 536ee148bff8..5d74a30fe00f 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1263,6 +1263,9 @@ annotation_line__print(struct annotation_line *al, struct
symbol *sym, u64 start
max_percent = sample->percent;
}
+ if (al->samples_nr > nr_percent)
+ nr_percent = al->samples_nr;
+
if (max_percent < min_pcnt)
return -1;
[tip:perf/urgent] perf cs-etm: Support unknown_thread in cs_etm_auxtrace
Commit-ID: 46d53620044f7b574c0f3216f8b4f2ce3559ce31
Gitweb: https://git.kernel.org/tip/46d53620044f7b574c0f3216f8b4f2ce3559ce31
Author: Leo Yan
AuthorDate: Thu, 10 May 2018 12:01:59 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 11 May 2018 10:45:23 -0300
perf cs-etm: Support unknown_thread in cs_etm_auxtrace
CoreSight doesn't allocate thread structure for unknown_thread in ETM
auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't
contain valid tid and then cs_etm__mem_access() uses unknown_thread
instead as thread handler, this results in a segmentation fault when
thread__find_addr_map() accesses the thread handler.
This commit creates a new thread data which is used by unknown_thread, so
CoreSight tracing can roll back to use unknown_thread if perf data
doesn't include valid thread info. This commit also releases thread
data for initialization failure case and for normal auxtrace free flow.
Signed-off-by: Leo Yan
Acked-by: Mathieu Poirier
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: linux-arm-ker...@lists.infradead.org
Link:
http://lkml.kernel.org/r/1525924920-4381-1-git-send-email-leo@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/cs-etm.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 40020b1ca54f..2bf28b5acc08 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -239,6 +239,7 @@ static void cs_etm__free(struct perf_session *session)
for (i = 0; i < aux->num_cpu; i++)
zfree(&aux->metadata[i]);
+ thread__zput(aux->unknown_thread);
zfree(&aux->metadata);
zfree(&aux);
}
@@ -1357,6 +1358,23 @@ int cs_etm__process_auxtrace_info(union perf_event
*event,
etm->auxtrace.free = cs_etm__free;
session->auxtrace = &etm->auxtrace;
+ etm->unknown_thread = thread__new(9, 9);
+ if (!etm->unknown_thread)
+ goto err_free_queues;
+
+ /*
+* Initialize list node so that at thread__zput() we can avoid
+* segmentation fault at list_del_init().
+*/
+ INIT_LIST_HEAD(&etm->unknown_thread->node);
+
+ err = thread__set_comm(etm->unknown_thread, "unknown", 0);
+ if (err)
+ goto err_delete_thread;
+
+ if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+ goto err_delete_thread;
+
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
return 0;
@@ -1371,16 +1389,18 @@ int cs_etm__process_auxtrace_info(union perf_event
*event,
err = cs_etm__synth_events(etm, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
err = auxtrace_queues__process_index(&etm->queues, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
etm->data_queued = etm->queues.populated;
return 0;
+err_delete_thread:
+ thread__zput(etm->unknown_thread);
err_free_queues:
auxtrace_queues__free(&etm->queues);
session->auxtrace = NULL;
[tip:perf/urgent] perf test: "probe libc's inet_pton" fails on s390 due to missing inline
Commit-ID: f8207b987fdc3768257704579bf29a717b4ea520
Gitweb: https://git.kernel.org/tip/f8207b987fdc3768257704579bf29a717b4ea520
Author: Thomas Richter
AuthorDate: Thu, 3 May 2018 08:58:37 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 10 May 2018 15:19:30 -0300
perf test: "probe libc's inet_pton" fails on s390 due to missing inline
perf test "probe libc's inet_pton & backtrace it with ping" fails on
4.17.0rc3 on s/390. It turned out that function __inet_pton is reported
as inline:
[root@s8360047 perf]# ./perf script -i /tmp/perf.data.111
ping 12457 [000] 1584.478959: probe_libc:inet_pton: (3ffb5a347e8)
1347e8 __inet_pton (inlined)
f19d7 gaih_inet.constprop.5 (/usr/lib64/libc-2.24.so)
f4c3f __GI_getaddrinfo (inlined)
410b main (/usr/bin/ping)
Allow __inet_pton listed as inline.
Signed-off-by: Thomas Richter
Cc: Heiko Carstens
Cc: Hendrik Brueckner
Cc: Martin Schwidefsky
Link: http://lkml.kernel.org/r/20180503065837.71043-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/shell/record+probe_libc_inet_pton.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
b/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
index 016882dbbc16..ee86473643be 100755
--- a/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
+++ b/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
@@ -16,7 +16,7 @@ nm -g $libc 2>/dev/null | fgrep -q inet_pton || exit 254
trace_libc_inet_pton_backtrace() {
idx=0
expected[0]="ping[][0-9 \.:]+probe_libc:inet_pton: \([[:xdigit:]]+\)"
- expected[1]=".*inet_pton[[:space:]]\($libc\)$"
+ expected[1]=".*inet_pton[[:space:]]\($libc|inlined\)$"
case "$(uname -m)" in
s390x)
eventattr='call-graph=dwarf,max-stack=4'
Re: [PATCH -resend 02/27] x86: assembly, use SYM_DATA for data
* Ingo Molnar wrote: > > * Jiri Slaby wrote: > > > We make proper use of SYM_DATA on global data instead of marking them as > > ENTRY. ENTRY is intended for functions and shall be paired with ENDPROC. > > ENTRY also aligns symbols which creates unnecessary holes here between > > data. > > > > ENTRY from saved_eip in wakeup_32 and many saved_* in wakeup_64 is > > simply dropped, as these symbols are local only. > > Yeah, so this commit talks about ENTRY() and ENDPROC(), while the new methods > are > SYM_FUNC_START()/END(). BTW., I like the series otherwise: for example in my comment above I wrote up the SYM_FUNC_START()/END() names from memory, without having to look up the primitives. [ Then I double checked it from the series to make sure I got it right. ;-) ] Before this I could never remember all these random, idiosyncratic, path dependent macro names - now there's at least some good high level structure to them. So it's a good step forward. Thanks, Ingo
Re: [PATCH] mmc: sdhci-pxav3: don't disable clocks when we might get an interrupt
On 15/05/18 09:18, Tom Hebb wrote:
> Hi,
>
> On 05/15/2018 01:59 AM, Adrian Hunter wrote:
>> On 15/05/18 00:56, Thomas Hebb wrote:
>>> Currently, runtime_suspend() unconditionally disables the clock gates
>>> for the controller, which means that it's unable to receive interrupts
>>> generated by connected SDIO cards.
>>
>> We currently get / put runtime pm with enable / disable of the SDIO IRQ
>> (refer sdhci_enable_sdio_irq()) so are you sure this is needed?
>
> You're correct; this patch is unnecessary. I wrote it before
> 923713b35745 ("mmc: sdhci: Disable runtime pm when the sdio_irq is
> enabled"), and it was needed then. Sorry for the noise.
>
> FYI, sdhci-esdhc-imx still checks the IRQ in its suspend/resume
> functions. That's one of the things that misled me to think this patch
> was still relevant.
+ a few people that have worked on sdhci-esdhc-imx
>
>>>
>>> Signed-off-by: Thomas Hebb
>>> ---
>>> drivers/mmc/host/sdhci-pxav3.c | 16 ++--
>>> 1 file changed, 10 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
>>> index a34434166ca7..59760f3cc1d7 100644
>>> --- a/drivers/mmc/host/sdhci-pxav3.c
>>> +++ b/drivers/mmc/host/sdhci-pxav3.c
>>> @@ -562,9 +562,11 @@ static int sdhci_pxav3_runtime_suspend(struct device
>>> *dev)
>>> if (host->tuning_mode != SDHCI_TUNING_MODE_3)
>>> mmc_retune_needed(host->mmc);
>>>
>>> - clk_disable_unprepare(pxa->clk_io);
>>> - if (!IS_ERR(pxa->clk_core))
>>> - clk_disable_unprepare(pxa->clk_core);
>>> + if (!sdhci_sdio_irq_enabled(host)) {
>>> + clk_disable_unprepare(pxa->clk_io);
>>> + if (!IS_ERR(pxa->clk_core))
>>> + clk_disable_unprepare(pxa->clk_core);
>>> + }
>>>
>>> return 0;
>>> }
>>> @@ -575,9 +577,11 @@ static int sdhci_pxav3_runtime_resume(struct device
>>> *dev)
>>> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> struct sdhci_pxa *pxa = sdhci_pltfm_priv(pltfm_host);
>>>
>>> - clk_prepare_enable(pxa->clk_io);
>>> - if (!IS_ERR(pxa->clk_core))
>>> - clk_prepare_enable(pxa->clk_core);
>>> + if (!sdhci_sdio_irq_enabled(host)) {
>>> + clk_prepare_enable(pxa->clk_io);
>>> + if (!IS_ERR(pxa->clk_core))
>>> + clk_prepare_enable(pxa->clk_core);
>>> + }
>>>
>>> return sdhci_runtime_resume_host(host);
>>> }
>>>
>>
>
[tip:locking/core] tools/memory-model: Update ASPLOS information
Commit-ID: 1a00b4554d477f05199e22ee71ba4c2525ca44cb
Gitweb: https://git.kernel.org/tip/1a00b4554d477f05199e22ee71ba4c2525ca44cb
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:33:56 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:18 +0200
tools/memory-model: Update ASPLOS information
ASPLOS 2018 was held in March: make sure this is reflected in
header comments and references.
Signed-off-by: Andrea Parri
Signed-off-by: Paul E. McKenney
Cc: Akira Yokosawa
Cc: Alan Stern
Cc: Andrew Morton
Cc: Boqun Feng
Cc: David Howells
Cc: Jade Alglave
Cc: Linus Torvalds
Cc: Luc Maranget
Cc: Nicholas Piggin
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: linux-a...@vger.kernel.org
Cc: parri.and...@gmail.com
Link:
http://lkml.kernel.org/r/1526340837-1-18-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
tools/memory-model/Documentation/references.txt | 11 ++-
tools/memory-model/linux-kernel.bell| 4 ++--
tools/memory-model/linux-kernel.cat | 4 ++--
tools/memory-model/linux-kernel.def | 4 ++--
4 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/tools/memory-model/Documentation/references.txt
b/tools/memory-model/Documentation/references.txt
index ba2e34c2ec3f..74f448f2616a 100644
--- a/tools/memory-model/Documentation/references.txt
+++ b/tools/memory-model/Documentation/references.txt
@@ -67,11 +67,12 @@ o Shaked Flur, Susmit Sarkar, Christopher Pulte, Kyndylan
Nienhuis,
Linux-kernel memory model
=
-o Andrea Parri, Alan Stern, Luc Maranget, Paul E. McKenney,
- and Jade Alglave. 2017. "A formal model of
- Linux-kernel memory ordering - companion webpage".
- http://moscova.inria.fr/∼maranget/cats7/linux/. (2017). [Online;
- accessed 30-January-2017].
+o Jade Alglave, Luc Maranget, Paul E. McKenney, Andrea Parri, and
+ Alan Stern. 2018. "Frightening small children and disconcerting
+ grown-ups: Concurrency in the Linux kernel". In Proceedings of
+ the 23rd International Conference on Architectural Support for
+ Programming Languages and Operating Systems (ASPLOS 2018). ACM,
+ New York, NY, USA, 405-418. Webpage: http://diy.inria.fr/linux/.
o Jade Alglave, Luc Maranget, Paul E. McKenney, Andrea Parri, and
Alan Stern. 2017. "A formal kernel memory-ordering model (part 1)"
diff --git a/tools/memory-model/linux-kernel.bell
b/tools/memory-model/linux-kernel.bell
index 432c7cf71b23..64f5740e0e75 100644
--- a/tools/memory-model/linux-kernel.bell
+++ b/tools/memory-model/linux-kernel.bell
@@ -5,10 +5,10 @@
* Copyright (C) 2017 Alan Stern ,
*Andrea Parri
*
- * An earlier version of this file appears in the companion webpage for
+ * An earlier version of this file appeared in the companion webpage for
* "Frightening small children and disconcerting grown-ups: Concurrency
* in the Linux kernel" by Alglave, Maranget, McKenney, Parri, and Stern,
- * which is to appear in ASPLOS 2018.
+ * which appeared in ASPLOS 2018.
*)
"Linux-kernel memory consistency model"
diff --git a/tools/memory-model/linux-kernel.cat
b/tools/memory-model/linux-kernel.cat
index 1e5c4653dd12..59b5cbe6b624 100644
--- a/tools/memory-model/linux-kernel.cat
+++ b/tools/memory-model/linux-kernel.cat
@@ -5,10 +5,10 @@
* Copyright (C) 2017 Alan Stern ,
*Andrea Parri
*
- * An earlier version of this file appears in the companion webpage for
+ * An earlier version of this file appeared in the companion webpage for
* "Frightening small children and disconcerting grown-ups: Concurrency
* in the Linux kernel" by Alglave, Maranget, McKenney, Parri, and Stern,
- * which is to appear in ASPLOS 2018.
+ * which appeared in ASPLOS 2018.
*)
"Linux-kernel memory consistency model"
diff --git a/tools/memory-model/linux-kernel.def
b/tools/memory-model/linux-kernel.def
index f0553bd37c08..6fa3eb28d40b 100644
--- a/tools/memory-model/linux-kernel.def
+++ b/tools/memory-model/linux-kernel.def
@@ -1,9 +1,9 @@
// SPDX-License-Identifier: GPL-2.0+
//
-// An earlier version of this file appears in the companion webpage for
+// An earlier version of this file appeared in the companion webpage for
// "Frightening small children and disconcerting grown-ups: Concurrency
// in the Linux kernel" by Alglave, Maranget, McKenney, Parri, and Stern,
-// which is to appear in ASPLOS 2018.
+// which appeared in ASPLOS 2018.
// ONCE
READ_ONCE(X) __load{once}(X)
[tip:locking/core] tools/memory-model: Add reference for 'Simplifying ARM concurrency'
Commit-ID: 99c12749b172758f6973fc023484f2fc8b91cd5a Gitweb: https://git.kernel.org/tip/99c12749b172758f6973fc023484f2fc8b91cd5a Author: Andrea Parri AuthorDate: Mon, 14 May 2018 16:33:57 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:19 +0200 tools/memory-model: Add reference for 'Simplifying ARM concurrency' The paper discusses the revised ARMv8 memory model; such revision had an important impact on the design of the LKMM. Signed-off-by: Andrea Parri Signed-off-by: Paul E. McKenney Cc: Akira Yokosawa Cc: Alan Stern Cc: Andrew Morton Cc: Boqun Feng Cc: David Howells Cc: Jade Alglave Cc: Linus Torvalds Cc: Luc Maranget Cc: Nicholas Piggin Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-a...@vger.kernel.org Cc: parri.and...@gmail.com Link: http://lkml.kernel.org/r/1526340837-1-19-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- tools/memory-model/Documentation/references.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/tools/memory-model/Documentation/references.txt b/tools/memory-model/Documentation/references.txt index 74f448f2616a..b177f3e4a614 100644 --- a/tools/memory-model/Documentation/references.txt +++ b/tools/memory-model/Documentation/references.txt @@ -63,6 +63,12 @@ oShaked Flur, Susmit Sarkar, Christopher Pulte, Kyndylan Nienhuis, Principles of Programming Languages (POPL 2017). ACM, New York, NY, USA, 429–442. +o Christopher Pulte, Shaked Flur, Will Deacon, Jon French, + Susmit Sarkar, and Peter Sewell. 2018. "Simplifying ARM concurrency: + multicopy-atomic axiomatic and operational models for ARMv8". In + Proceedings of the ACM on Programming Languages, Volume 2, Issue + POPL, Article No. 19. ACM, New York, NY, USA. + Linux-kernel memory model =
[tip:locking/core] MAINTAINERS, tools/memory-model: Update e-mail address for Andrea Parri
Commit-ID: 5ccdb7536ebec7a5f8a3883ba1985a80cec80dd3 Gitweb: https://git.kernel.org/tip/5ccdb7536ebec7a5f8a3883ba1985a80cec80dd3 Author: Andrea Parri AuthorDate: Mon, 14 May 2018 16:33:55 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:18 +0200 MAINTAINERS, tools/memory-model: Update e-mail address for Andrea Parri I moved to Amarula Solutions; switch to work e-mail address. Signed-off-by: Andrea Parri Signed-off-by: Paul E. McKenney Cc: Akira Yokosawa Cc: Alan Stern Cc: Andrew Morton Cc: Boqun Feng Cc: David Howells Cc: Jade Alglave Cc: Linus Torvalds Cc: Luc Maranget Cc: Nicholas Piggin Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-a...@vger.kernel.org Cc: parri.and...@gmail.com Link: http://lkml.kernel.org/r/1526340837-1-17-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 649e782e4415..b6341e8a3587 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8203,7 +8203,7 @@ F:drivers/misc/lkdtm/* LINUX KERNEL MEMORY CONSISTENCY MODEL (LKMM) M: Alan Stern -M: Andrea Parri +M: Andrea Parri M: Will Deacon M: Peter Zijlstra M: Boqun Feng
[tip:locking/core] tools/memory-model: Improve mixed-access checking in lock.cat
Commit-ID: 30b795df11a1a9dd7fc50c1ff4677343b67cb379 Gitweb: https://git.kernel.org/tip/30b795df11a1a9dd7fc50c1ff4677343b67cb379 Author: Alan Stern AuthorDate: Mon, 14 May 2018 16:33:52 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:18 +0200 tools/memory-model: Improve mixed-access checking in lock.cat The code in lock.cat which checks for normal read/write accesses to spinlock variables doesn't take into account the newly added RL and RU events. Add them into the test, and move the resulting code up near the start of the file, since a violation would indicate a pretty severe conceptual error in a litmus test. Tested-by: Andrea Parri Signed-off-by: Alan Stern Signed-off-by: Paul E. McKenney Cc: Akira Yokosawa Cc: Andrew Morton Cc: Boqun Feng Cc: David Howells Cc: Jade Alglave Cc: Linus Torvalds Cc: Luc Maranget Cc: Nicholas Piggin Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-a...@vger.kernel.org Cc: parri.and...@gmail.com Link: http://lkml.kernel.org/r/1526340837-1-14-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- tools/memory-model/lock.cat | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/tools/memory-model/lock.cat b/tools/memory-model/lock.cat index df74de2148f6..7217cd4941a4 100644 --- a/tools/memory-model/lock.cat +++ b/tools/memory-model/lock.cat @@ -32,6 +32,17 @@ include "cross.cat" * LKW, LF, RL, and RU have no ordering properties. *) +(* Backward compatibility *) +let RL = try RL with emptyset +let RU = try RU with emptyset + +(* Treat RL as a kind of LF: a read with no ordering properties *) +let LF = LF | RL + +(* There should be no ordinary R or W accesses to spinlocks *) +let ALL-LOCKS = LKR | LKW | UL | LF | RU +flag ~empty [M \ IW] ; loc ; [ALL-LOCKS] as mixed-lock-accesses + (* Link Lock-Reads to their RMW-partner Lock-Writes *) let lk-rmw = ([LKR] ; po-loc ; [LKW]) \ (po ; po) let rmw = rmw | lk-rmw @@ -49,20 +60,9 @@ flag ~empty LKW \ range(lk-rmw) as unpaired-LKW (* This will be allowed if we implement spin_is_locked() *) flag ~empty LKR \ domain(lk-rmw) as unpaired-LKR -(* There should be no ordinary R or W accesses to spinlocks *) -let ALL-LOCKS = LKR | LKW | UL | LF -flag ~empty [M \ IW] ; loc ; [ALL-LOCKS] as mixed-lock-accesses - (* The final value of a spinlock should not be tested *) flag ~empty [FW] ; loc ; [ALL-LOCKS] as lock-final -(* Backward compatibility *) -let RL = try RL with emptyset -let RU = try RU with emptyset - -(* Treat RL as a kind of LF: a read with no ordering properties *) -let LF = LF | RL - (* * Put lock operations in their appropriate classes, but leave UL out of W * until after the co relation has been generated.
[tip:locking/core] tools/memory-model: Fix coding style in 'lock.cat'
Commit-ID: 05604e7e3adbd78f074b7f86b14f50888bf66252
Gitweb: https://git.kernel.org/tip/05604e7e3adbd78f074b7f86b14f50888bf66252
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:33:54 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:18 +0200
tools/memory-model: Fix coding style in 'lock.cat'
This commit uses tabs for indentation and adds spaces around binary
operator.
Signed-off-by: Andrea Parri
Signed-off-by: Paul E. McKenney
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Cc: st...@rowland.harvard.edu
Link:
http://lkml.kernel.org/r/1526340837-1-16-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
tools/memory-model/lock.cat | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/memory-model/lock.cat b/tools/memory-model/lock.cat
index cd002a33ca8a..305ded17e741 100644
--- a/tools/memory-model/lock.cat
+++ b/tools/memory-model/lock.cat
@@ -84,16 +84,16 @@ let rfi-lf = ([LKW] ; po-loc ; [LF]) \ ([LKW] ; po-loc ;
[UL] ; po-loc)
(* rfe for LF events *)
let all-possible-rfe-lf =
- (*
- * Given an LF event r, compute the possible rfe edges for that event
- * (all those starting from LKW events in other threads),
- * and then convert that relation to a set of single-edge relations.
- *)
- let possible-rfe-lf r =
-let pair-to-relation p = p ++ 0
-in map pair-to-relation ((LKW * {r}) & loc & ext)
- (* Do this for each LF event r that isn't in rfi-lf *)
- in map possible-rfe-lf (LF \ range(rfi-lf))
+ (*
+* Given an LF event r, compute the possible rfe edges for that event
+* (all those starting from LKW events in other threads),
+* and then convert that relation to a set of single-edge relations.
+*)
+ let possible-rfe-lf r =
+ let pair-to-relation p = p ++ 0
+ in map pair-to-relation ((LKW * {r}) & loc & ext)
+ (* Do this for each LF event r that isn't in rfi-lf *)
+ in map possible-rfe-lf (LF \ range(rfi-lf))
(* Generate all rf relations for LF events *)
with rfe-lf from cross(all-possible-rfe-lf)
@@ -110,10 +110,10 @@ let rfi-ru = ([UL] ; po-loc ; [RU]) \ ([UL] ; po-loc ;
[LKW] ; po-loc)
(* rfe for RU events: an RU may read from an external UL or the initial write
*)
let all-possible-rfe-ru =
- let possible-rfe-ru r =
- let pair-to-relation p = p ++ 0
- in map pair-to-relation (((UL|IW) * {r}) & loc & ext)
- in map possible-rfe-ru RU
+ let possible-rfe-ru r =
+ let pair-to-relation p = p ++ 0
+ in map pair-to-relation (((UL | IW) * {r}) & loc & ext)
+ in map possible-rfe-ru RU
(* Generate all rf relations for RU events *)
with rfe-ru from cross(all-possible-rfe-ru)
[tip:locking/core] tools/memory-model: Remove out-of-date comments and code from lock.cat
Commit-ID: cee0321a404fe6b43d1f4364639c8ffe2f2b37d1 Gitweb: https://git.kernel.org/tip/cee0321a404fe6b43d1f4364639c8ffe2f2b37d1 Author: Alan Stern AuthorDate: Mon, 14 May 2018 16:33:53 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:18 +0200 tools/memory-model: Remove out-of-date comments and code from lock.cat lock.cat contains old comments and code referring to the possibility of LKR events that are not part of an RMW pair. This is a holdover from when I though we might end up using LKR events to implement spin_is_locked(). Reword the comments to remove this assumption and replace domain(lk-rmw) in the code with LKR. Tested-by: Andrea Parri [ paulmck: Pulled as lock-nest into previous line as discussed. ] Signed-off-by: Alan Stern Signed-off-by: Paul E. McKenney Cc: Akira Yokosawa Cc: Andrew Morton Cc: Boqun Feng Cc: David Howells Cc: Jade Alglave Cc: Linus Torvalds Cc: Luc Maranget Cc: Nicholas Piggin Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-a...@vger.kernel.org Cc: parri.and...@gmail.com Link: http://lkml.kernel.org/r/1526340837-1-15-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- tools/memory-model/lock.cat | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/tools/memory-model/lock.cat b/tools/memory-model/lock.cat index 7217cd4941a4..cd002a33ca8a 100644 --- a/tools/memory-model/lock.cat +++ b/tools/memory-model/lock.cat @@ -47,18 +47,15 @@ flag ~empty [M \ IW] ; loc ; [ALL-LOCKS] as mixed-lock-accesses let lk-rmw = ([LKR] ; po-loc ; [LKW]) \ (po ; po) let rmw = rmw | lk-rmw +(* The litmus test is invalid if an LKR/LKW event is not part of an RMW pair *) +flag ~empty LKW \ range(lk-rmw) as unpaired-LKW +flag ~empty LKR \ domain(lk-rmw) as unpaired-LKR + (* - * A paired LKR must always see an unlocked value; spin_lock() calls nested + * An LKR must always see an unlocked value; spin_lock() calls nested * inside a critical section (for the same lock) always deadlock. *) -empty ([LKW] ; po-loc ; [domain(lk-rmw)]) \ (po-loc ; [UL] ; po-loc) - as lock-nest - -(* The litmus test is invalid if an LKW event is not part of an RMW pair *) -flag ~empty LKW \ range(lk-rmw) as unpaired-LKW - -(* This will be allowed if we implement spin_is_locked() *) -flag ~empty LKR \ domain(lk-rmw) as unpaired-LKR +empty ([LKW] ; po-loc ; [LKR]) \ (po-loc ; [UL] ; po-loc) as lock-nest (* The final value of a spinlock should not be tested *) flag ~empty [FW] ; loc ; [ALL-LOCKS] as lock-final
Re: [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 05/15/2018 12:40 AM, Neil Armstrong wrote: > This patchs adds the cec_notifier feature to the intel_hdmi part > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate > between each HDMI ports. > The changes will allow the i915 HDMI code to notify EDID and HPD changes > to an eventual CEC adapter. > > Signed-off-by: Neil Armstrong > --- > drivers/gpu/drm/i915/intel_drv.h | 2 ++ > drivers/gpu/drm/i915/intel_hdmi.c | 10 ++ The Kconfig also needs to be changed. In the DRM_I915 you need to add: select CEC_CORE if CEC_NOTIFIER Otherwise you'll get problems if the cec driver is a module and i915 is built-in. Regards, Hans
[tip:locking/core] tools/memory-model: Improve comments in lock.cat
Commit-ID: fd0359dbac3df00d1c6c22769e7d647b16b920cc Gitweb: https://git.kernel.org/tip/fd0359dbac3df00d1c6c22769e7d647b16b920cc Author: Alan Stern AuthorDate: Mon, 14 May 2018 16:33:51 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:18 +0200 tools/memory-model: Improve comments in lock.cat This patch improves the comments in tools/memory-model/lock.cat. In addition to making the text more uniform and removing redundant comments, it adds a description of all the possible locking events that herd can generate. Tested-by: Andrea Parri Signed-off-by: Alan Stern Signed-off-by: Paul E. McKenney Cc: Akira Yokosawa Cc: Andrew Morton Cc: Boqun Feng Cc: David Howells Cc: Jade Alglave Cc: Linus Torvalds Cc: Luc Maranget Cc: Nicholas Piggin Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-a...@vger.kernel.org Cc: parri.and...@gmail.com Link: http://lkml.kernel.org/r/1526340837-1-13-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- tools/memory-model/lock.cat | 51 - 1 file changed, 36 insertions(+), 15 deletions(-) diff --git a/tools/memory-model/lock.cat b/tools/memory-model/lock.cat index 1f6d67e79065..df74de2148f6 100644 --- a/tools/memory-model/lock.cat +++ b/tools/memory-model/lock.cat @@ -4,15 +4,35 @@ * Copyright (C) 2017 Alan Stern *) -(* Generate coherence orders and handle lock operations *) (* - * Warning, crashes with herd7 versions strictly before 7.48. - * spin_islocked is functional from version 7.49. + * Generate coherence orders and handle lock operations * + * Warning: spin_is_locked() crashes herd7 versions strictly before 7.48. + * spin_is_locked() is functional from herd7 version 7.49. *) + include "cross.cat" -(* From lock reads to their partner lock writes *) +(* + * The lock-related events generated by herd are as follows: + * + * LKR Lock-Read: the read part of a spin_lock() or successful + * spin_trylock() read-modify-write event pair + * LKW Lock-Write: the write part of a spin_lock() or successful + * spin_trylock() RMW event pair + * UL Unlock: a spin_unlock() event + * LF Lock-Fail: a failed spin_trylock() event + * RL Read-Locked: a spin_is_locked() event which returns True + * RU Read-Unlocked: a spin_is_locked() event which returns False + * + * LKR and LKW events always come paired, like all RMW event sequences. + * + * LKR, LF, RL, and RU are read events; LKR has Acquire ordering. + * LKW and UL are write events; UL has Release ordering. + * LKW, LF, RL, and RU have no ordering properties. + *) + +(* Link Lock-Reads to their RMW-partner Lock-Writes *) let lk-rmw = ([LKR] ; po-loc ; [LKW]) \ (po ; po) let rmw = rmw | lk-rmw @@ -29,18 +49,16 @@ flag ~empty LKW \ range(lk-rmw) as unpaired-LKW (* This will be allowed if we implement spin_is_locked() *) flag ~empty LKR \ domain(lk-rmw) as unpaired-LKR -(* There should be no R or W accesses to spinlocks *) +(* There should be no ordinary R or W accesses to spinlocks *) let ALL-LOCKS = LKR | LKW | UL | LF flag ~empty [M \ IW] ; loc ; [ALL-LOCKS] as mixed-lock-accesses (* The final value of a spinlock should not be tested *) flag ~empty [FW] ; loc ; [ALL-LOCKS] as lock-final -(* - * Backward compatibility - *) -let RL = try RL with emptyset (* defined herd7 >= 7.49 *) -let RU = try RU with emptyset (* defined herd7 >= 7.49 *) +(* Backward compatibility *) +let RL = try RL with emptyset +let RU = try RU with emptyset (* Treat RL as a kind of LF: a read with no ordering properties *) let LF = LF | RL @@ -55,7 +73,6 @@ let W = W | LKW let Release = Release | UL let Acquire = Acquire | LKR - (* Match LKW events to their corresponding UL events *) let critical = ([LKW] ; po-loc ; [UL]) \ (po-loc ; [LKW | UL] ; po-loc) @@ -65,7 +82,6 @@ flag ~empty UL \ range(critical) as unmatched-unlock let UNMATCHED-LKW = LKW \ domain(critical) empty ([UNMATCHED-LKW] ; loc ; [UNMATCHED-LKW]) \ id as unmatched-locks - (* rfi for LF events: link each LKW to the LF events in its critical section *) let rfi-lf = ([LKW] ; po-loc ; [LF]) \ ([LKW] ; po-loc ; [UL] ; po-loc) @@ -86,18 +102,23 @@ let all-possible-rfe-lf = with rfe-lf from cross(all-possible-rfe-lf) let rf-lf = rfe-lf | rfi-lf -(* Read from unlock, ie islocked returning false, slightly different *) +(* + * RU, i.e., spin_is_locked() returning False, is slightly different. + * We rely on the memory model to rule out cases where spin_is_locked() + * within one of the lock's critical sections returns False. + *) -(* islocked returning false can read from the last po-previous unlock *) +(* rfi for RU events: an RU may read from the last po-previous UL *) let rfi-ru = ([UL] ; po-loc ; [RU]) \ ([UL] ; po-loc ; [LKW] ; po-loc) -(* any islocked returning false can read from any external unlock *) +(* rfe for RU events: an RU may
[tip:locking/core] tools/memory-model: Remove duplicated code from lock.cat
Commit-ID: 8559183ccaec97454b2515ac426f113967256cf9
Gitweb: https://git.kernel.org/tip/8559183ccaec97454b2515ac426f113967256cf9
Author: Alan Stern
AuthorDate: Mon, 14 May 2018 16:33:50 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:17 +0200
tools/memory-model: Remove duplicated code from lock.cat
This patch simplifies the implementation of spin_is_locked in the
LKMM. It capitalizes on the fact that a failed spin_trylock() and a
spin_is_locked() which returns True have exactly the same semantics
(those of READ_ONCE) and ordering properties (none). Therefore the
two kinds of events can be combined and handled by the same code,
instead of treated separately as they are currently.
Tested-by: Andrea Parri
Signed-off-by: Alan Stern
Signed-off-by: Paul E. McKenney
Cc: Akira Yokosawa
Cc: Andrew Morton
Cc: Boqun Feng
Cc: David Howells
Cc: Jade Alglave
Cc: Linus Torvalds
Cc: Luc Maranget
Cc: Nicholas Piggin
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: linux-a...@vger.kernel.org
Cc: parri.and...@gmail.com
Link:
http://lkml.kernel.org/r/1526340837-1-12-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
tools/memory-model/lock.cat | 28 ++--
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/tools/memory-model/lock.cat b/tools/memory-model/lock.cat
index 3b1439edc818..1f6d67e79065 100644
--- a/tools/memory-model/lock.cat
+++ b/tools/memory-model/lock.cat
@@ -41,11 +41,15 @@ flag ~empty [FW] ; loc ; [ALL-LOCKS] as lock-final
*)
let RL = try RL with emptyset (* defined herd7 >= 7.49 *)
let RU = try RU with emptyset (* defined herd7 >= 7.49 *)
+
+(* Treat RL as a kind of LF: a read with no ordering properties *)
+let LF = LF | RL
+
(*
* Put lock operations in their appropriate classes, but leave UL out of W
* until after the co relation has been generated.
*)
-let R = R | LKR | LF | RL | RU
+let R = R | LKR | LF | RU
let W = W | LKW
let Release = Release | UL
@@ -80,28 +84,8 @@ let all-possible-rfe-lf =
(* Generate all rf relations for LF events *)
with rfe-lf from cross(all-possible-rfe-lf)
-
let rf-lf = rfe-lf | rfi-lf
-(* rf for RL events, ie islocked returning true, similar to LF above *)
-
-(* islocked returning true inside a critical section
- * must read from the opening lock
- *)
-let rfi-rl = ([LKW] ; po-loc ; [RL]) \ ([LKW] ; po-loc ; [UL] ; po-loc)
-
-(* islocked returning true outside critical sections can match any
- * external lock.
- *)
-let all-possible-rfe-rl =
- let possible-rfe-lf r =
-let pair-to-relation p = p ++ 0
-in map pair-to-relation ((LKW * {r}) & loc & ext)
- in map possible-rfe-lf (RL \ range(rfi-rl))
-
-with rfe-rl from cross(all-possible-rfe-rl)
-let rf-rl = rfe-rl | rfi-rl
-
(* Read from unlock, ie islocked returning false, slightly different *)
(* islocked returning false can read from the last po-previous unlock *)
@@ -118,7 +102,7 @@ with rfe-ru from cross(all-possible-rfe-ru)
let rf-ru = rfe-ru | rfi-ru
(* Final rf relation *)
-let rf = rf | rf-lf | rf-rl | rf-ru
+let rf = rf | rf-lf | rf-ru
(* Generate all co relations, including LKW events but not UL *)
let co0 = co0 | ([IW] ; loc ; [LKW]) |
[tip:locking/core] tools/memory-model: Flag "cumulativity" and "propagation" tests
Commit-ID: 1bd3742043fa44dd0ec25770abdcdfe1f6e8681e
Gitweb: https://git.kernel.org/tip/1bd3742043fa44dd0ec25770abdcdfe1f6e8681e
Author: Paul E. McKenney
AuthorDate: Mon, 14 May 2018 16:33:49 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:17 +0200
tools/memory-model: Flag "cumulativity" and "propagation" tests
This commit flags WRC+pooncerelease+rmbonceonce+Once.litmus
as being forbidden by smp_store_release() A-cumulativity and
IRIW+mbonceonces+OnceOnce.litmus as being forbidden by the LKMM
propagation rule.
Suggested-by: Andrea Parri
Reported-by: Paolo Bonzini
[ paulmck: Updated wording as suggested by Alan Stern. ]
Signed-off-by: Paul E. McKenney
Acked-by: Alan Stern
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Link:
http://lkml.kernel.org/r/1526340837-1-11-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus | 2 +-
tools/memory-model/litmus-tests/README | 9 ++---
.../litmus-tests/WRC+pooncerelease+rmbonceonce+Once.litmus | 4 +++-
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
b/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
index 50d5db9ea983..98a3716efa37 100644
--- a/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
+++ b/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
@@ -7,7 +7,7 @@ C IRIW+mbonceonces+OnceOnce
* between each pairs of reads. In other words, is smp_mb() sufficient to
* cause two different reading processes to agree on the order of a pair
* of writes, where each write is to a different variable by a different
- * process?
+ * process? This litmus test exercises LKMM's "propagation" rule.
*)
{}
diff --git a/tools/memory-model/litmus-tests/README
b/tools/memory-model/litmus-tests/README
index 6919909bbd0f..17eb9a8c222d 100644
--- a/tools/memory-model/litmus-tests/README
+++ b/tools/memory-model/litmus-tests/README
@@ -23,7 +23,8 @@ IRIW+mbonceonces+OnceOnce.litmus
between each pairs of reads. In other words, is smp_mb()
sufficient to cause two different reading processes to agree on
the order of a pair of writes, where each write is to a different
- variable by a different process?
+ variable by a different process? This litmus test is forbidden
+ by LKMM's propagation rule.
IRIW+poonceonces+OnceOnce.litmus
Test of independent reads from independent writes with nothing
@@ -119,8 +120,10 @@ S+wmbonceonce+poacquireonce.litmus
WRC+poonceonces+Once.litmus
WRC+pooncerelease+rmbonceonce+Once.litmus
- These two are members of an extension of the MP litmus-test class
- in which the first write is moved to a separate process.
+ These two are members of an extension of the MP litmus-test
+ class in which the first write is moved to a separate process.
+ The second is forbidden because smp_store_release() is
+ A-cumulative in LKMM.
Z6.0+pooncelock+pooncelock+pombonce.litmus
Is the ordering provided by a spin_unlock() and a subsequent
diff --git
a/tools/memory-model/litmus-tests/WRC+pooncerelease+rmbonceonce+Once.litmus
b/tools/memory-model/litmus-tests/WRC+pooncerelease+rmbonceonce+Once.litmus
index 97fcbffde9a0..ad3448b941e6 100644
--- a/tools/memory-model/litmus-tests/WRC+pooncerelease+rmbonceonce+Once.litmus
+++ b/tools/memory-model/litmus-tests/WRC+pooncerelease+rmbonceonce+Once.litmus
@@ -5,7 +5,9 @@ C WRC+pooncerelease+rmbonceonce+Once
*
* This litmus test is an extension of the message-passing pattern, where
* the first write is moved to a separate process. Because it features
- * a release and a read memory barrier, it should be forbidden.
+ * a release and a read memory barrier, it should be forbidden. More
+ * specifically, this litmus test is forbidden because smp_store_release()
+ * is A-cumulative in LKMM.
*)
{}
[tip:locking/core] tools/memory-model: Add model support for spin_is_locked()
Commit-ID: 15553dcbca0638de57047e79b9fb4ea77aa04db3
Gitweb: https://git.kernel.org/tip/15553dcbca0638de57047e79b9fb4ea77aa04db3
Author: Luc Maranget
AuthorDate: Mon, 14 May 2018 16:33:48 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:17 +0200
tools/memory-model: Add model support for spin_is_locked()
This commit first adds a trivial macro for spin_is_locked() to
linux-kernel.def.
It also adds cat code for enumerating all possible matches of lock
write events (set LKW) with islocked events returning true (set RL,
for Read from Lock), and unlock write events (set UL) with islocked
events returning false (set RU, for Read from Unlock). Note that this
intentionally does not model uniprocessor kernels (CONFIG_SMP=n) built
with CONFIG_DEBUG_SPINLOCK=n, in which spin_is_locked() unconditionally
returns zero.
It also adds a pair of litmus tests demonstrating the minimal ordering
provided by spin_is_locked() in conjunction with spin_lock(). Will Deacon
noted that this minimal ordering happens on ARMv8:
https://lkml.kernel.org/r/20180226162426.gb17...@arm.com
Notice that herd7 installations strictly older than version 7.49
do not handle the new constructs.
Signed-off-by: Luc Maranget
Signed-off-by: Paul E. McKenney
Reviewed-by: Alan Stern
Cc: Akira Yokosawa
Cc: Andrea Parri
Cc: Andrew Morton
Cc: Boqun Feng
Cc: David Howells
Cc: Jade Alglave
Cc: Linus Torvalds
Cc: Luc Maranget
Cc: Nicholas Piggin
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: linux-a...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1526340837-1-10-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
tools/memory-model/linux-kernel.def| 1 +
.../MP+polockmbonce+poacquiresilsil.litmus | 35 ++
.../MP+polockonce+poacquiresilsil.litmus | 34 ++
tools/memory-model/litmus-tests/README | 10
tools/memory-model/lock.cat| 53 --
5 files changed, 129 insertions(+), 4 deletions(-)
diff --git a/tools/memory-model/linux-kernel.def
b/tools/memory-model/linux-kernel.def
index 6bd3bc431b3d..f0553bd37c08 100644
--- a/tools/memory-model/linux-kernel.def
+++ b/tools/memory-model/linux-kernel.def
@@ -38,6 +38,7 @@ cmpxchg_release(X,V,W) __cmpxchg{release}(X,V,W)
spin_lock(X) { __lock(X); }
spin_unlock(X) { __unlock(X); }
spin_trylock(X) __trylock(X)
+spin_is_locked(X) __islocked(X)
// RCU
rcu_read_lock() { __fence{rcu-lock}; }
diff --git
a/tools/memory-model/litmus-tests/MP+polockmbonce+poacquiresilsil.litmus
b/tools/memory-model/litmus-tests/MP+polockmbonce+poacquiresilsil.litmus
new file mode 100644
index ..50f4d62bbf0e
--- /dev/null
+++ b/tools/memory-model/litmus-tests/MP+polockmbonce+poacquiresilsil.litmus
@@ -0,0 +1,35 @@
+C MP+polockmbonce+poacquiresilsil
+
+(*
+ * Result: Never
+ *
+ * Do spinlocks combined with smp_mb__after_spinlock() provide order
+ * to outside observers using spin_is_locked() to sense the lock-held
+ * state, ordered by acquire? Note that when the first spin_is_locked()
+ * returns false and the second true, we know that the smp_load_acquire()
+ * executed before the lock was acquired (loosely speaking).
+ *)
+
+{
+}
+
+P0(spinlock_t *lo, int *x)
+{
+ spin_lock(lo);
+ smp_mb__after_spinlock();
+ WRITE_ONCE(*x, 1);
+ spin_unlock(lo);
+}
+
+P1(spinlock_t *lo, int *x)
+{
+ int r1;
+ int r2;
+ int r3;
+
+ r1 = smp_load_acquire(x);
+ r2 = spin_is_locked(lo);
+ r3 = spin_is_locked(lo);
+}
+
+exists (1:r1=1 /\ 1:r2=0 /\ 1:r3=1)
diff --git
a/tools/memory-model/litmus-tests/MP+polockonce+poacquiresilsil.litmus
b/tools/memory-model/litmus-tests/MP+polockonce+poacquiresilsil.litmus
new file mode 100644
index ..abf81e7a0895
--- /dev/null
+++ b/tools/memory-model/litmus-tests/MP+polockonce+poacquiresilsil.litmus
@@ -0,0 +1,34 @@
+C MP+polockonce+poacquiresilsil
+
+(*
+ * Result: Sometimes
+ *
+ * Do spinlocks provide order to outside observers using spin_is_locked()
+ * to sense the lock-held state, ordered by acquire? Note that when the
+ * first spin_is_locked() returns false and the second true, we know that
+ * the smp_load_acquire() executed before the lock was acquired (loosely
+ * speaking).
+ *)
+
+{
+}
+
+P0(spinlock_t *lo, int *x)
+{
+ spin_lock(lo);
+ WRITE_ONCE(*x, 1);
+ spin_unlock(lo);
+}
+
+P1(spinlock_t *lo, int *x)
+{
+ int r1;
+ int r2;
+ int r3;
+
+ r1 = smp_load_acquire(x);
+ r2 = spin_is_locked(lo);
+ r3 = spin_is_locked(lo);
+}
+
+exists (1:r1=1 /\ 1:r2=0 /\ 1:r3=1)
diff --git a/tools/memory-model/litmus-tests/README
b/tools/memory-model/litmus-tests/README
index 04096fb8b8d9..6919909bbd0f 100644
--- a/tools/memory-model/litmus-tests/README
+++ b/tools/memory-model/litmus-tests/README
@@ -63,6 +63,16 @@ LB+poonceonces.litmus
MP+onceassign+derefonce.litmus
As below
[tip:locking/core] tools/memory-model: Add scripts to test memory model
Commit-ID: 2fb6ae162f25a9c3bc45663c479a2b15fb69e768
Gitweb: https://git.kernel.org/tip/2fb6ae162f25a9c3bc45663c479a2b15fb69e768
Author: Paul E. McKenney
AuthorDate: Mon, 14 May 2018 16:33:47 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:17 +0200
tools/memory-model: Add scripts to test memory model
This commit adds a pair of scripts that run the memory model on litmus
tests, checking that the verification result of each litmus test matches
the result flagged in the litmus test itself. These scripts permit easier
checking of changes to the memory model against preconceived notions.
To run the scripts, go to the tools/memory-model directory and type
"scripts/checkalllitmus.sh". If all is well, the last line printed will
be "All litmus tests verified as was expected."
Signed-off-by: Paul E. McKenney
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Cc: st...@rowland.harvard.edu
Link:
http://lkml.kernel.org/r/1526340837-1-9-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
tools/memory-model/litmus-tests/.gitignore | 1 +
tools/memory-model/scripts/checkalllitmus.sh | 73 +++
tools/memory-model/scripts/checklitmus.sh| 86
3 files changed, 160 insertions(+)
diff --git a/tools/memory-model/litmus-tests/.gitignore
b/tools/memory-model/litmus-tests/.gitignore
new file mode 100644
index ..6e2ddc54152f
--- /dev/null
+++ b/tools/memory-model/litmus-tests/.gitignore
@@ -0,0 +1 @@
+*.litmus.out
diff --git a/tools/memory-model/scripts/checkalllitmus.sh
b/tools/memory-model/scripts/checkalllitmus.sh
new file mode 100644
index ..af0aa15ab84e
--- /dev/null
+++ b/tools/memory-model/scripts/checkalllitmus.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+#
+# Run herd tests on all .litmus files in the specified directory (which
+# defaults to litmus-tests) and check each file's result against a "Result:"
+# comment within that litmus test. If the verification result does not
+# match that specified in the litmus test, this script prints an error
+# message prefixed with "^^^". It also outputs verification results to
+# a file whose name is that of the specified litmus test, but with ".out"
+# appended.
+#
+# Usage:
+# sh checkalllitmus.sh [ directory ]
+#
+# The LINUX_HERD_OPTIONS environment variable may be used to specify
+# arguments to herd, whose default is defined by the checklitmus.sh script.
+# Thus, one would normally run this in the directory containing the memory
+# model, specifying the pathname of the litmus test to check.
+#
+# This script makes no attempt to run the litmus tests concurrently.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, you can access it online at
+# http://www.gnu.org/licenses/gpl-2.0.html.
+#
+# Copyright IBM Corporation, 2018
+#
+# Author: Paul E. McKenney
+
+litmusdir=${1-litmus-tests}
+if test -d "$litmusdir" -a -r "$litmusdir" -a -x "$litmusdir"
+then
+ :
+else
+ echo ' --- ' error: $litmusdir is not an accessible directory
+ exit 255
+fi
+
+# Find the checklitmus script. If it is not where we expect it, then
+# assume that the caller has the PATH environment variable set
+# appropriately.
+if test -x scripts/checklitmus.sh
+then
+ clscript=scripts/checklitmus.sh
+else
+ clscript=checklitmus.sh
+fi
+
+# Run the script on all the litmus tests in the specified directory
+ret=0
+for i in litmus-tests/*.litmus
+do
+ if ! $clscript $i
+ then
+ ret=1
+ fi
+done
+if test "$ret" -ne 0
+then
+ echo " ^^^ VERIFICATION MISMATCHES"
+else
+ echo All litmus tests verified as was expected.
+fi
+exit $ret
diff --git a/tools/memory-model/scripts/checklitmus.sh
b/tools/memory-model/scripts/checklitmus.sh
new file mode 100644
index ..e2e477472844
--- /dev/null
+++ b/tools/memory-model/scripts/checklitmus.sh
@@ -0,0 +1,86 @@
+#!/bin/sh
+#
+# Run a herd test and check the result against a "Result:" comment within
+# the litmus test. If the verification result does not match that specified
+# in the litmus test, this script prints an error message prefixed with
+# "^^^" and exits with a
[tip:locking/core] tools/memory-model: Model 'smp_store_mb()'
Commit-ID: bf8c6d963d16d40fbe70e94b61d9bf18c455fc6b
Gitweb: https://git.kernel.org/tip/bf8c6d963d16d40fbe70e94b61d9bf18c455fc6b
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:33:45 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:16 +0200
tools/memory-model: Model 'smp_store_mb()'
This commit models 'smp_store_mb(x, val);' to be semantically equivalent
to 'WRITE_ONCE(x, val); smp_mb();'.
Suggested-by: Paolo Bonzini
Suggested-by: Peter Zijlstra
Signed-off-by: Andrea Parri
Signed-off-by: Paul E. McKenney
Acked-by: Alan Stern
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Link:
http://lkml.kernel.org/r/1526340837-1-7-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
tools/memory-model/linux-kernel.def | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/memory-model/linux-kernel.def
b/tools/memory-model/linux-kernel.def
index 397e4e67e8c8..acf86f6f360a 100644
--- a/tools/memory-model/linux-kernel.def
+++ b/tools/memory-model/linux-kernel.def
@@ -14,6 +14,7 @@ smp_store_release(X,V) { __store{release}(*X,V); }
smp_load_acquire(X) __load{acquire}(*X)
rcu_assign_pointer(X,V) { __store{release}(X,V); }
rcu_dereference(X) __load{once}(X)
+smp_store_mb(X,V) { __store{once}(X,V); __fence{mb}; }
// Fences
smp_mb() { __fence{mb} ; }
[tip:locking/core] tools/memory-model: Fix coding style in 'linux-kernel.def'
Commit-ID: d17013e0bac66bb4d1be44f061754c7e53292b64
Gitweb: https://git.kernel.org/tip/d17013e0bac66bb4d1be44f061754c7e53292b64
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:33:46 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:17 +0200
tools/memory-model: Fix coding style in 'linux-kernel.def'
This commit fixes white spaces around semicolons.
Signed-off-by: Andrea Parri
Signed-off-by: Paul E. McKenney
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Cc: st...@rowland.harvard.edu
Link:
http://lkml.kernel.org/r/1526340837-1-8-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
tools/memory-model/linux-kernel.def | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/memory-model/linux-kernel.def
b/tools/memory-model/linux-kernel.def
index acf86f6f360a..6bd3bc431b3d 100644
--- a/tools/memory-model/linux-kernel.def
+++ b/tools/memory-model/linux-kernel.def
@@ -17,12 +17,12 @@ rcu_dereference(X) __load{once}(X)
smp_store_mb(X,V) { __store{once}(X,V); __fence{mb}; }
// Fences
-smp_mb() { __fence{mb} ; }
-smp_rmb() { __fence{rmb} ; }
-smp_wmb() { __fence{wmb} ; }
-smp_mb__before_atomic() { __fence{before-atomic} ; }
-smp_mb__after_atomic() { __fence{after-atomic} ; }
-smp_mb__after_spinlock() { __fence{after-spinlock} ; }
+smp_mb() { __fence{mb}; }
+smp_rmb() { __fence{rmb}; }
+smp_wmb() { __fence{wmb}; }
+smp_mb__before_atomic() { __fence{before-atomic}; }
+smp_mb__after_atomic() { __fence{after-atomic}; }
+smp_mb__after_spinlock() { __fence{after-spinlock}; }
// Exchange
xchg(X,V) __xchg{mb}(X,V)
@@ -35,26 +35,26 @@ cmpxchg_acquire(X,V,W) __cmpxchg{acquire}(X,V,W)
cmpxchg_release(X,V,W) __cmpxchg{release}(X,V,W)
// Spinlocks
-spin_lock(X) { __lock(X) ; }
-spin_unlock(X) { __unlock(X) ; }
+spin_lock(X) { __lock(X); }
+spin_unlock(X) { __unlock(X); }
spin_trylock(X) __trylock(X)
// RCU
rcu_read_lock() { __fence{rcu-lock}; }
-rcu_read_unlock() { __fence{rcu-unlock};}
+rcu_read_unlock() { __fence{rcu-unlock}; }
synchronize_rcu() { __fence{sync-rcu}; }
synchronize_rcu_expedited() { __fence{sync-rcu}; }
// Atomic
atomic_read(X) READ_ONCE(*X)
-atomic_set(X,V) { WRITE_ONCE(*X,V) ; }
+atomic_set(X,V) { WRITE_ONCE(*X,V); }
atomic_read_acquire(X) smp_load_acquire(X)
atomic_set_release(X,V) { smp_store_release(X,V); }
-atomic_add(V,X) { __atomic_op(X,+,V) ; }
-atomic_sub(V,X) { __atomic_op(X,-,V) ; }
-atomic_inc(X) { __atomic_op(X,+,1) ; }
-atomic_dec(X) { __atomic_op(X,-,1) ; }
+atomic_add(V,X) { __atomic_op(X,+,V); }
+atomic_sub(V,X) { __atomic_op(X,-,V); }
+atomic_inc(X) { __atomic_op(X,+,1); }
+atomic_dec(X) { __atomic_op(X,-,1); }
atomic_add_return(V,X) __atomic_op_return{mb}(X,+,V)
atomic_add_return_relaxed(V,X) __atomic_op_return{once}(X,+,V)
[tip:locking/core] tools/memory-order: Update the cheat-sheet to show that smp_mb__after_atomic() orders later RMW operations
Commit-ID: bfd403bb3617e17a272e1189e5c76253052c22b8 Gitweb: https://git.kernel.org/tip/bfd403bb3617e17a272e1189e5c76253052c22b8 Author: Paul E. McKenney AuthorDate: Mon, 14 May 2018 16:33:44 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:16 +0200 tools/memory-order: Update the cheat-sheet to show that smp_mb__after_atomic() orders later RMW operations The current cheat sheet does not claim that smp_mb__after_atomic() orders later RMW atomic operations, which it must, at least against earlier RMW atomic operations and whatever precedes them. This commit therefore adds the needed "Y". Signed-off-by: Paul E. McKenney Acked-by: Alan Stern Cc: Andrew Morton Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: aki...@gmail.com Cc: boqun.f...@gmail.com Cc: dhowe...@redhat.com Cc: j.algl...@ucl.ac.uk Cc: linux-a...@vger.kernel.org Cc: luc.maran...@inria.fr Cc: npig...@gmail.com Cc: parri.and...@gmail.com Link: http://lkml.kernel.org/r/1526340837-1-6-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- tools/memory-model/Documentation/cheatsheet.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/memory-model/Documentation/cheatsheet.txt b/tools/memory-model/Documentation/cheatsheet.txt index 46fe79afc737..33ba98d72b16 100644 --- a/tools/memory-model/Documentation/cheatsheet.txt +++ b/tools/memory-model/Documentation/cheatsheet.txt @@ -14,7 +14,7 @@ smp_wmb() YW Y YW smp_mb() & synchronize_rcu() CPY YYY Y Y YY Successful full non-void RMW CP Y Y YY Y Y Y Y YY Y smp_mb__before_atomic() CPY YYa a a aY -smp_mb__after_atomic()CPa aYY Y Y Y +smp_mb__after_atomic()CPa aYY Y Y YY Key: C: Ordering is cumulative
[tip:locking/core] tools/memory-order: Improve key for SELF and SV
Commit-ID: 35bb6ee6790600d29c598ebbf262359341f34e38 Gitweb: https://git.kernel.org/tip/35bb6ee6790600d29c598ebbf262359341f34e38 Author: Paul E. McKenney AuthorDate: Mon, 14 May 2018 16:33:43 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:16 +0200 tools/memory-order: Improve key for SELF and SV The key for "SELF" was missing completely and the key for "SV" was a bit obtuse. This commit therefore adds a key for "SELF" and improves the one for "SV". Reported-by: Paolo Bonzini Signed-off-by: Paul E. McKenney Acked-by: Alan Stern Cc: Andrew Morton Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: aki...@gmail.com Cc: boqun.f...@gmail.com Cc: dhowe...@redhat.com Cc: j.algl...@ucl.ac.uk Cc: linux-a...@vger.kernel.org Cc: luc.maran...@inria.fr Cc: npig...@gmail.com Cc: parri.and...@gmail.com Link: http://lkml.kernel.org/r/1526340837-1-5-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- tools/memory-model/Documentation/cheatsheet.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/memory-model/Documentation/cheatsheet.txt b/tools/memory-model/Documentation/cheatsheet.txt index c0eafdaddfa4..46fe79afc737 100644 --- a/tools/memory-model/Documentation/cheatsheet.txt +++ b/tools/memory-model/Documentation/cheatsheet.txt @@ -26,4 +26,5 @@ Key: C: Ordering is cumulative DR: Dependent read (address dependency) DW: Dependent write (address, data, or control dependency) RMW:Atomic read-modify-write operation - SV Same-variable access + SELF: Orders self, as opposed to accesses before and/or after + SV: Orders later accesses to the same variable
[tip:locking/core] tools/memory-model: Fix cheat sheet typo
Commit-ID: a839195186a2bca1b2b46e57619e9ad5b8d42426 Gitweb: https://git.kernel.org/tip/a839195186a2bca1b2b46e57619e9ad5b8d42426 Author: Paolo Bonzini AuthorDate: Mon, 14 May 2018 16:33:42 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:16 +0200 tools/memory-model: Fix cheat sheet typo "RWM" should be "RMW". Signed-off-by: Paolo Bonzini Signed-off-by: Paul E. McKenney Cc: Andrew Morton Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: aki...@gmail.com Cc: boqun.f...@gmail.com Cc: dhowe...@redhat.com Cc: j.algl...@ucl.ac.uk Cc: linux-a...@vger.kernel.org Cc: luc.maran...@inria.fr Cc: npig...@gmail.com Cc: parri.and...@gmail.com Cc: st...@rowland.harvard.edu Link: http://lkml.kernel.org/r/1526340837-1-4-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- tools/memory-model/Documentation/cheatsheet.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/memory-model/Documentation/cheatsheet.txt b/tools/memory-model/Documentation/cheatsheet.txt index 956b1ae4aafb..c0eafdaddfa4 100644 --- a/tools/memory-model/Documentation/cheatsheet.txt +++ b/tools/memory-model/Documentation/cheatsheet.txt @@ -1,6 +1,6 @@ Prior Operation Subsequent Operation --- --- - C Self R W RWM Self R W DR DW RMW SV + C Self R W RMW Self R W DR DW RMW SV -- - - --- - - -- -- --- -- Store, e.g., WRITE_ONCE()Y Y
Re: [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 05/15/2018 12:40 AM, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> to an eventual CEC adapter.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 10 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d436858..b50e51b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * __wait_for - magic wait macro
> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
> bool has_audio;
> bool rgb_quant_range_selectable;
> struct intel_connector *attached_connector;
> + struct cec_notifier *notifier;
> };
>
> struct intel_dp_mst_encoder;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1baef4a..9b94d72 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> connected = true;
> }
>
> + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
> +
> return connected;
> }
>
> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> {
> enum drm_connector_status status;
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
>
> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>
> + if (status != connector_status_connected)
> + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
> +
> return status;
> }
>
> @@ -2358,6 +2364,10 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> u32 temp = I915_READ(PEG_BAND_GAP_DATA);
> I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
> }
> +
> + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);
> + if (!intel_hdmi->notifier)
> + DRM_DEBUG_KMS("CEC notifier get failed\n");
You 'get' the notifier here, but where is the cec_notifier_put when the
connector is deleted?
Regards,
Hans
> }
>
> void intel_hdmi_init(struct drm_i915_private *dev_priv,
>
Re: [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd
On 14/05/2018 18:56, Andy Shevchenko wrote: > On Mon, May 14, 2018 at 1:57 PM, Richard Genoud > wrote: >> On 11/05/2018 12:38, Radu Pirea wrote: >>> This patch modifies the place where resources and device tree properties >>> are searched. > >> I think it may be simpler with something like: > >> + int size = mfd_pdev->resource[0].end - mfd_pdev->resource[0].start + >> 1; > > Isn't resource_size() macro for this very purpose? Indeed. + int size = resource_size(mfd_pdev->resource); would be even simpler ! > >>> + int size = to_platform_device(pdev->dev.parent)->resource[0].end - >>> + to_platform_device(pdev->dev.parent)->resource[0].start + 1; >>> >> ditto > > Ditto. > Thanks ! Richard.
[tip:locking/core] tools/memory-model: Update required version of herdtools7
Commit-ID: 5b62832c1e5284030500f82d6b3579ceed399fe6 Gitweb: https://git.kernel.org/tip/5b62832c1e5284030500f82d6b3579ceed399fe6 Author: Akira Yokosawa AuthorDate: Mon, 14 May 2018 16:33:41 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:16 +0200 tools/memory-model: Update required version of herdtools7 Code generated by klitmus7 version 7.48 doesn't compile with kernel header of 4.15 and later due to the absence of ACCESS_ONCE(). As the issue has been resolved in herdtools7 7.49, bump the required version number in README. Signed-off-by: Akira Yokosawa Signed-off-by: Paul E. McKenney Cc: Alan Stern Cc: Andrea Parri Cc: Andrew Morton Cc: Boqun Feng Cc: David Howells Cc: Jade Alglave Cc: Linus Torvalds Cc: Luc Maranget Cc: Nicholas Piggin Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-a...@vger.kernel.org Link: http://lkml.kernel.org/r/1526340837-1-3-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- tools/memory-model/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/memory-model/README b/tools/memory-model/README index 0b3a5f3c9ccd..734f7feaa5dc 100644 --- a/tools/memory-model/README +++ b/tools/memory-model/README @@ -20,7 +20,7 @@ that litmus test to be exercised within the Linux kernel. REQUIREMENTS -Version 7.48 of the "herd7" and "klitmus7" tools must be downloaded +Version 7.49 of the "herd7" and "klitmus7" tools must be downloaded separately: https://github.com/herd/herdtools7
[tip:locking/core] tools/memory-model: Redefine rb in terms of rcu-fence
Commit-ID: 9d036883a17969caf8796d1fce813af0ab016986 Gitweb: https://git.kernel.org/tip/9d036883a17969caf8796d1fce813af0ab016986 Author: Alan Stern AuthorDate: Mon, 14 May 2018 16:33:40 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:16 +0200 tools/memory-model: Redefine rb in terms of rcu-fence This patch reorganizes the definition of rb in the Linux Kernel Memory Consistency Model. The relation is now expressed in terms of rcu-fence, which consists of a sequence of gp and rscs links separated by rcu-link links, in which the number of occurrences of gp is >= the number of occurrences of rscs. Arguments similar to those published in http://diy.inria.fr/linux/long.pdf show that rcu-fence behaves like an inter-CPU strong fence. Furthermore, the definition of rb in terms of rcu-fence is highly analogous to the definition of pb in terms of strong-fence, which can help explain why rcu-path expresses a form of temporal ordering. This change should not affect the semantics of the memory model, just its internal organization. Signed-off-by: Alan Stern Signed-off-by: Paul E. McKenney Reviewed-by: Boqun Feng Reviewed-by: Andrea Parri Cc: Andrew Morton Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: aki...@gmail.com Cc: dhowe...@redhat.com Cc: j.algl...@ucl.ac.uk Cc: linux-a...@vger.kernel.org Cc: luc.maran...@inria.fr Cc: npig...@gmail.com Link: http://lkml.kernel.org/r/1526340837-1-2-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- tools/memory-model/Documentation/explanation.txt | 168 +++ tools/memory-model/linux-kernel.cat | 33 +++-- 2 files changed, 129 insertions(+), 72 deletions(-) diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt index 1a387d703212..1b09f3175a1f 100644 --- a/tools/memory-model/Documentation/explanation.txt +++ b/tools/memory-model/Documentation/explanation.txt @@ -27,7 +27,7 @@ Explanation of the Linux-Kernel Memory Consistency Model 19. AND THEN THERE WAS ALPHA 20. THE HAPPENS-BEFORE RELATION: hb 21. THE PROPAGATES-BEFORE RELATION: pb - 22. RCU RELATIONS: rcu-link, gp-link, rscs-link, and rb + 22. RCU RELATIONS: rcu-link, gp, rscs, rcu-fence, and rb 23. ODDS AND ENDS @@ -1451,8 +1451,8 @@ they execute means that it cannot have cycles. This requirement is the content of the LKMM's "propagation" axiom. -RCU RELATIONS: rcu-link, gp-link, rscs-link, and rb +RCU RELATIONS: rcu-link, gp, rscs, rcu-fence, and rb + RCU (Read-Copy-Update) is a powerful synchronization mechanism. It rests on two concepts: grace periods and read-side critical sections. @@ -1537,49 +1537,100 @@ relation, and the details don't matter unless you want to comb through a somewhat lengthy formal proof. Pretty much all you need to know about rcu-link is the information in the preceding paragraph. -The LKMM goes on to define the gp-link and rscs-link relations. They -bring grace periods and read-side critical sections into the picture, -in the following way: +The LKMM also defines the gp and rscs relations. They bring grace +periods and read-side critical sections into the picture, in the +following way: - E ->gp-link F means there is a synchronize_rcu() fence event S - and an event X such that E ->po S, either S ->po X or S = X, - and X ->rcu-link F. In other words, E and F are linked by a - grace period followed by an instance of rcu-link. + E ->gp F means there is a synchronize_rcu() fence event S such + that E ->po S and either S ->po F or S = F. In simple terms, + there is a grace period po-between E and F. - E ->rscs-link F means there is a critical section delimited by - an rcu_read_lock() fence L and an rcu_read_unlock() fence U, - and an event X such that E ->po U, either L ->po X or L = X, - and X ->rcu-link F. Roughly speaking, this says that some - event in the same critical section as E is linked by rcu-link - to F. + E ->rscs F means there is a critical section delimited by an + rcu_read_lock() fence L and an rcu_read_unlock() fence U, such + that E ->po U and either L ->po F or L = F. You can think of + this as saying that E and F are in the same critical section + (in fact, it also allows E to be po-before the start of the + critical section and F to be po-after the end). If we think of the rcu-link relation as standing for an extended -"before", then E ->gp-link F says that E executes before a grace -period which ends before F executes. (In fact it covers more than -this, because it also includes cases where E executes before a grace -period and some store propagates to F's CPU before F executes and -doesn't propagate to some other CPU until afte
[tip:locking/core] tools/memory-model: Rename link and rcu-path to rcu-link and rb
Commit-ID: 1ee2da5f9b5a8e814b397b77a08d44fed5f96a4a Gitweb: https://git.kernel.org/tip/1ee2da5f9b5a8e814b397b77a08d44fed5f96a4a Author: Alan Stern AuthorDate: Mon, 14 May 2018 16:33:39 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:15 +0200 tools/memory-model: Rename link and rcu-path to rcu-link and rb This patch makes a simple non-functional change to the RCU portion of the Linux Kernel Memory Consistency Model by renaming the "link" and "rcu-path" relations to "rcu-link" and "rb", respectively. The name "link" was an unfortunate choice, because it was too generic and subject to confusion with other meanings of the same word, which occur quite often in LKMM documentation. The name "rcu-path" is not very appropriate, because the relation is analogous to the happens-before (hb) and propagates-before (pb) relations -- although that fact won't become apparent until the second patch in this series. Signed-off-by: Alan Stern Signed-off-by: Paul E. McKenney Acked-by: Andrea Parri Cc: Andrew Morton Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: aki...@gmail.com Cc: boqun.f...@gmail.com Cc: dhowe...@redhat.com Cc: j.algl...@ucl.ac.uk Cc: linux-a...@vger.kernel.org Cc: luc.maran...@inria.fr Cc: npig...@gmail.com Link: http://lkml.kernel.org/r/1526340837-1-1-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- tools/memory-model/Documentation/explanation.txt | 93 tools/memory-model/linux-kernel.cat | 16 ++-- 2 files changed, 55 insertions(+), 54 deletions(-) diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt index a727c82bd434..1a387d703212 100644 --- a/tools/memory-model/Documentation/explanation.txt +++ b/tools/memory-model/Documentation/explanation.txt @@ -27,7 +27,7 @@ Explanation of the Linux-Kernel Memory Consistency Model 19. AND THEN THERE WAS ALPHA 20. THE HAPPENS-BEFORE RELATION: hb 21. THE PROPAGATES-BEFORE RELATION: pb - 22. RCU RELATIONS: link, gp-link, rscs-link, and rcu-path + 22. RCU RELATIONS: rcu-link, gp-link, rscs-link, and rb 23. ODDS AND ENDS @@ -1451,8 +1451,8 @@ they execute means that it cannot have cycles. This requirement is the content of the LKMM's "propagation" axiom. -RCU RELATIONS: link, gp-link, rscs-link, and rcu-path -- +RCU RELATIONS: rcu-link, gp-link, rscs-link, and rb +--- RCU (Read-Copy-Update) is a powerful synchronization mechanism. It rests on two concepts: grace periods and read-side critical sections. @@ -1509,8 +1509,8 @@ y, which occurs before the end of the critical section, did not propagate to P1 before the end of the grace period, violating the Guarantee. -In the kernel's implementations of RCU, the business about stores -propagating to every CPU is realized by placing strong fences at +In the kernel's implementations of RCU, the requirements for stores +to propagate to every CPU are fulfilled by placing strong fences at suitable places in the RCU-related code. Thus, if a critical section starts before a grace period does then the critical section's CPU will execute an smp_mb() fence after the end of the critical section and @@ -1523,19 +1523,19 @@ executes. What exactly do we mean by saying that a critical section "starts before" or "ends after" a grace period? Some aspects of the meaning are pretty obvious, as in the example above, but the details aren't -entirely clear. The LKMM formalizes this notion by means of a -relation with the unfortunately generic name "link". It is a very -general relation; among other things, X ->link Z includes cases where -X happens-before or is equal to some event Y which is equal to or -comes before Z in the coherence order. Taking Y = Z, this says that -X ->rfe Z implies X ->link Z, and taking Y = X, it says that X ->fr Z -and X ->co Z each imply X ->link Z. - -The formal definition of the link relation is more than a little +entirely clear. The LKMM formalizes this notion by means of the +rcu-link relation. rcu-link encompasses a very general notion of +"before": Among other things, X ->rcu-link Z includes cases where X +happens-before or is equal to some event Y which is equal to or comes +before Z in the coherence order. When Y = Z this says that X ->rfe Z +implies X ->rcu-link Z. In addition, when Y = X it says that X ->fr Z +and X ->co Z each imply X ->rcu-link Z. + +The formal definition of the rcu-link relation is more than a little obscure, and we won't give it here. It is closely related to the pb relation, and the details don't matter unless you want to comb through a somewhat lengthy formal proof. Pretty much all you need to know -about link is the information in the preceding paragraph. +about rcu-link is the information in the preceding paragraph. The LKMM goes o
Re: [PATCH v6] ANDROID: binder: change down_write to down_read
Hi Joel,
Sorry for the late response. I was off.
On Wed, May 09, 2018 at 04:19:41PM -0700, Joel Fernandes wrote:
> On Wed, May 09, 2018 at 03:40:23PM +0900, Minchan Kim wrote:
> > On Tue, May 08, 2018 at 04:08:13PM -0700, Joel Fernandes wrote:
> > > On Tue, May 08, 2018 at 07:51:01PM +0900, Minchan Kim wrote:
> > > > On Mon, May 07, 2018 at 10:28:29AM -0700, Joel Fernandes wrote:
> > > > > On Mon, May 07, 2018 at 11:15:37PM +0900, Minchan Kim wrote:
> > > > > > binder_update_page_range needs down_write of mmap_sem because
> > > > > > vm_insert_page need to change vma->vm_flags to VM_MIXEDMAP unless
> > > > > > it is set. However, when I profile binder working, it seems
> > > > > > every binder buffers should be mapped in advance by binder_mmap.
> > > > > > It means we could set VM_MIXEDMAP in binder_mmap time which is
> > > > > > already hold a mmap_sem as down_write so binder_update_page_range
> > > > > > doesn't need to hold a mmap_sem as down_write.
> > > > > > Please use proper API down_read. It would help mmap_sem contention
> > > > > > problem as well as fixing down_write abuse.
> > > > > >
> > > > > > Ganesh Mahendran tested app launching and binder throughput test
> > > > > > and he said he couldn't find any problem and I did binder latency
> > > > > > test per Greg KH request(Thanks Martijn to teach me how I can do)
> > > > > > I cannot find any problem, too.
> > > > > >
> > > > > > Cc: Ganesh Mahendran
> > > > > > Cc: Joe Perches
> > > > > > Cc: Arve Hjønnevåg
> > > > > > Cc: Todd Kjos
> > > > > > Cc: Greg Kroah-Hartman
> > > > > > Reviewed-by: Martijn Coenen
> > > > > > Signed-off-by: Minchan Kim
> > > > > > ---
> > > > > > drivers/android/binder.c | 4 +++-
> > > > > > drivers/android/binder_alloc.c | 6 +++---
> > > > > > 2 files changed, 6 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> > > > > > index 4eab5be3d00f..7b8e96f60719 100644
> > > > > > --- a/drivers/android/binder.c
> > > > > > +++ b/drivers/android/binder.c
> > > > > > @@ -4730,7 +4730,9 @@ static int binder_mmap(struct file *filp,
> > > > > > struct vm_area_struct *vma)
> > > > > > failure_string = "bad vm_flags";
> > > > > > goto err_bad_arg;
> > > > > > }
> > > > > > - vma->vm_flags = (vma->vm_flags | VM_DONTCOPY) & ~VM_MAYWRITE;
> > > > > > + vma->vm_flags |= VM_DONTCOPY | VM_MIXEDMAP;
> > > > > > + vma->vm_flags &= ~VM_MAYWRITE;
> > > > > > +
> > > > > > vma->vm_ops = &binder_vm_ops;
> > > > > > vma->vm_private_data = proc;
> > > > > >
> > > > > > diff --git a/drivers/android/binder_alloc.c
> > > > > > b/drivers/android/binder_alloc.c
> > > > > > index 5a426c877dfb..4f382d51def1 100644
> > > > > > --- a/drivers/android/binder_alloc.c
> > > > > > +++ b/drivers/android/binder_alloc.c
> > > > > > @@ -219,7 +219,7 @@ static int binder_update_page_range(struct
> > > > > > binder_alloc *alloc, int allocate,
> > > > > > mm = alloc->vma_vm_mm;
> > > > > >
> > > > > > if (mm) {
> > > > > > - down_write(&mm->mmap_sem);
> > > > > > + down_read(&mm->mmap_sem);
> > > > >
> > > > >
> > > > > Nice. Is there a need to hold the reader-lock at all here? Just
> > > > > curious what
> > > > > else is it protecting (here or in vm_insert_page).
> > > >
> > > > It should protect vm_area_struct. IOW, when we try insert page into
> > > > virtual address area,
> > > > vma shouldn't be changed(ie, unmap/collapse/split).
> > >
> > > When you say unmap, are you talking about pages being unmapped from the
> > > VMA
> > > or something else?
> >
> > I mean to destroy vm_area_struct itself as well as unmap pages.
> >
> > >
> > > For the collapse/split part, the binder VMA (vm_area_struct) itself isn't
> > > changed after the initial mmap (AFAIK) so I don't see a need for
> > > protection
> > > there.
> >
> > There is no way to unmap in runtime? What happens if some buggy applications
> > do unmap by mistake?
> > Cannot we access those B's vma from A context?
> > If B process is exiting, the VMA would be gone while A is accessing.
>
> If the VMA is gone, then why is it a good idea to map pages into it anyway?
Hmm, sorry about that. I couldn't understand your point.
>
> About the unmap at runtime part, your commit message was a bit confusing. You
> said "every binder buffers should be mapped in advance by binder_mmap." but I
> think the new binder shrinker mechanism doesn't make that true anymore.
It's good point. I didn't know know that.
When I see binder_vm_fault, it emits SIGBUS. That means shrinker cannot zap
pages
process is using, I think. IOW, every pages for binder are mapped at mmap time
and is never mapped in runtime by page fault. Right?
Thanks.
>
> The unmap by mistake point is a valid one I guess.
>
> thanks,
>
> - Joel
>
Re: [RFC PATCH 2/5] media: cec-notifier: Get notifier by device and connector name
Hi Neil,
Thanks for this patch series!
Some comments below:
On 05/15/2018 12:40 AM, Neil Armstrong wrote:
> In non device-tree world, we can need to get the notifier by the driver
> name directly and eventually defer probe if not yet created.
>
> This patch adds a variant of the get function by using the device name
> instead and will not create a notifier if not yet created.
>
> But the i915 driver exposes at least 2 HDMI connectors, this patch also
> adds the possibility to add a connector name tied to the notifier device
> to form a tuple and associate different CEC controllers for each HDMI
> connectors.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/media/cec/cec-notifier.c | 30 ---
> include/media/cec-notifier.h | 44
> ++--
> 2 files changed, 69 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/cec/cec-notifier.c
> b/drivers/media/cec/cec-notifier.c
> index 16dffa0..716070a 100644
> --- a/drivers/media/cec/cec-notifier.c
> +++ b/drivers/media/cec/cec-notifier.c
> @@ -21,6 +21,7 @@ struct cec_notifier {
> struct list_head head;
> struct kref kref;
> struct device *dev;
> + const char *conn;
> struct cec_adapter *cec_adap;
> void (*callback)(struct cec_adapter *adap, u16 pa);
>
> @@ -30,13 +31,34 @@ struct cec_notifier {
> static LIST_HEAD(cec_notifiers);
> static DEFINE_MUTEX(cec_notifiers_lock);
>
> -struct cec_notifier *cec_notifier_get(struct device *dev)
> +struct cec_notifier *cec_notifier_get_byname(const char *name,
> + const char *conn)
> {
> struct cec_notifier *n;
>
> mutex_lock(&cec_notifiers_lock);
> list_for_each_entry(n, &cec_notifiers, head) {
> - if (n->dev == dev) {
> + if (!strcmp(dev_name(n->dev), name) &&
> + (!conn || !strcmp(n->conn, conn))) {
> + kref_get(&n->kref);
> + mutex_unlock(&cec_notifiers_lock);
> + return n;
> + }
> + }
> + mutex_unlock(&cec_notifiers_lock);
> +
> + return NULL;
This doesn't seem right. For one it doesn't act like the other cec_notifier_get*
functions in that it doesn't make a new notifier if it wasn't found yet in the
list.
For another, I think this function shouldn't be here at all. How about calling
bus_find_device_by_name(), then use cec_notifier_get_conn()?
> +}
> +EXPORT_SYMBOL_GPL(cec_notifier_get_byname);
> +
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char
> *conn)
> +{
> + struct cec_notifier *n;
> +
> + mutex_lock(&cec_notifiers_lock);
> + list_for_each_entry(n, &cec_notifiers, head) {
> + if (n->dev == dev &&
> + (!conn || !strcmp(n->conn, conn))) {
> kref_get(&n->kref);
> mutex_unlock(&cec_notifiers_lock);
> return n;
> @@ -46,6 +68,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> if (!n)
> goto unlock;
> n->dev = dev;
> + if (conn)
> + n->conn = devm_kstrdup(dev, conn, GFP_KERNEL);
The use of devm_kstrdup worries me. The problem is that when the 'dev' device
is removed, this memory is also automatically freed. But the notifier might
still have a reference through the CEC driver, so you end up with a n->conn
pointer that points to freed memory.
I think it is better to just use kstrdup and kfree it when the last notifier
reference is released.
> n->phys_addr = CEC_PHYS_ADDR_INVALID;
> mutex_init(&n->lock);
> kref_init(&n->kref);
> @@ -54,7 +78,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> mutex_unlock(&cec_notifiers_lock);
> return n;
> }
> -EXPORT_SYMBOL_GPL(cec_notifier_get);
> +EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
>
> static void cec_notifier_release(struct kref *kref)
> {
> diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
> index cf0add7..70f2974 100644
> --- a/include/media/cec-notifier.h
> +++ b/include/media/cec-notifier.h
> @@ -20,6 +20,37 @@ struct cec_notifier;
> #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
>
> /**
> + * cec_notifier_get_byname - find a cec_notifier for the given device name
> + * and connector tuple.
> + * @name: device name that sends the events.
> + * @conn: the connector name from which the event occurs
> + *
> + * If a notifier for device @name exists, then increase the refcount and
> + * return that notifier.
> + *
> + * If it doesn't exist, return NULL
> + */
> +struct cec_notifier *cec_notifier_get_byname(const char *name,
> + const char *conn);
> +
> +/**
> + * cec_notifier_get_conn - find or create a new cec_notifier for the given
> + * device and connector tuple.
> + * @dev: device that sends the events.
> + * @conn: the connector name from which t
[tip:locking/core] locking/spinlocks: Clean up comment and #ifndef for {,queued_}spin_is_locked()
Commit-ID: 1362ae43c503a4e333ab6948fc4c6e0e794e1558
Gitweb: https://git.kernel.org/tip/1362ae43c503a4e333ab6948fc4c6e0e794e1558
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:01:29 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:15 +0200
locking/spinlocks: Clean up comment and #ifndef for {,queued_}spin_is_locked()
Removes "#ifndef queued_spin_is_locked" from the generic code: this is
unused and it's reasonable to conclude that it will continue to be unused.
Also removes the comment about spin_is_locked() from mutex_is_locked():
the comment remains valid but not particularly useful.
Suggested-by: Will Deacon
Signed-off-by: Andrea Parri
Signed-off-by: Paul E. McKenney
Acked-by: Will Deacon
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Cc: st...@rowland.harvard.edu
Link:
http://lkml.kernel.org/r/1526338889-7003-3-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
include/asm-generic/qspinlock.h | 2 --
include/linux/mutex.h | 3 ---
2 files changed, 5 deletions(-)
diff --git a/include/asm-generic/qspinlock.h b/include/asm-generic/qspinlock.h
index a8ed0a352d75..9cc457597ddf 100644
--- a/include/asm-generic/qspinlock.h
+++ b/include/asm-generic/qspinlock.h
@@ -26,7 +26,6 @@
* @lock: Pointer to queued spinlock structure
* Return: 1 if it is locked, 0 otherwise
*/
-#ifndef queued_spin_is_locked
static __always_inline int queued_spin_is_locked(struct qspinlock *lock)
{
/*
@@ -35,7 +34,6 @@ static __always_inline int queued_spin_is_locked(struct
qspinlock *lock)
*/
return atomic_read(&lock->val);
}
-#endif
/**
* queued_spin_value_unlocked - is the spinlock structure unlocked?
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 14bc0d5d0ee5..3093dd162424 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -146,9 +146,6 @@ extern void __mutex_init(struct mutex *lock, const char
*name,
*/
static inline bool mutex_is_locked(struct mutex *lock)
{
- /*
-* XXX think about spin_is_locked
-*/
return __mutex_owner(lock) != NULL;
}
[tip:locking/core] locking/spinlocks/arm64: Remove smp_mb() from arch_spin_is_locked()
Commit-ID: c6f5d02b6a0fb91be5d656885ce02cf28952181d
Gitweb: https://git.kernel.org/tip/c6f5d02b6a0fb91be5d656885ce02cf28952181d
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:01:28 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:15 +0200
locking/spinlocks/arm64: Remove smp_mb() from arch_spin_is_locked()
The following commit:
38b850a73034f ("arm64: spinlock: order spin_{is_locked,unlock_wait} against
local locks")
... added an smp_mb() to arch_spin_is_locked(), in order
"to ensure that the lock value is always loaded after any other locks have
been taken by the current CPU", and reported one example (the "insane case"
in ipc/sem.c) relying on such guarantee.
It is however understood that spin_is_locked() is not required to provide
such an ordering guarantee (a guarantee that is currently not provided by
all the implementations/archs), and that callers relying on such ordering
should instead insert suitable memory barriers before acting on the result
of spin_is_locked().
Following a recent auditing [1] of the callers of {,raw_}spin_is_locked(),
revealing that none of them are relying on the ordering guarantee anymore,
this commit removes the leading smp_mb() from the primitive thus reverting
38b850a73034f.
[1] https://marc.info/?l=linux-kernel&m=151981440005264&w=2
https://marc.info/?l=linux-kernel&m=152042843808540&w=2
https://marc.info/?l=linux-kernel&m=152043346110262&w=2
Signed-off-by: Andrea Parri
Signed-off-by: Paul E. McKenney
Acked-by: Will Deacon
Cc: Andrew Morton
Cc: Catalin Marinas
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Cc: st...@rowland.harvard.edu
Link:
http://lkml.kernel.org/r/1526338889-7003-2-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
arch/arm64/include/asm/spinlock.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm64/include/asm/spinlock.h
b/arch/arm64/include/asm/spinlock.h
index ebdae15d665d..26c5bd7d88d8 100644
--- a/arch/arm64/include/asm/spinlock.h
+++ b/arch/arm64/include/asm/spinlock.h
@@ -122,11 +122,6 @@ static inline int arch_spin_value_unlocked(arch_spinlock_t
lock)
static inline int arch_spin_is_locked(arch_spinlock_t *lock)
{
- /*
-* Ensure prior spin_lock operations to other locks have completed
-* on this CPU before we test whether "lock" is locked.
-*/
- smp_mb(); /* ^^^ */
return !arch_spin_value_unlocked(READ_ONCE(*lock));
}
[tip:locking/core] locking/spinlocks: Document the semantics of spin_is_locked()
Commit-ID: b7e4aadef28f217de8907eec60a964328797a2be
Gitweb: https://git.kernel.org/tip/b7e4aadef28f217de8907eec60a964328797a2be
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:01:27 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:15 +0200
locking/spinlocks: Document the semantics of spin_is_locked()
There appeared to be a certain, recurrent uncertainty concerning the
semantics of spin_is_locked(), likely a consequence of the fact that
this semantics remains undocumented or that it has been historically
linked to the (likewise unclear) semantics of spin_unlock_wait().
A recent auditing [1] of the callers of the primitive confirmed that
none of them are relying on particular ordering guarantees; document
this semantics by adding a docbook header to spin_is_locked(). Also,
describe behaviors specific to certain CONFIG_SMP=n builds.
[1] https://marc.info/?l=linux-kernel&m=151981440005264&w=2
https://marc.info/?l=linux-kernel&m=152042843808540&w=2
https://marc.info/?l=linux-kernel&m=152043346110262&w=2
Co-Developed-by: Andrea Parri
Co-Developed-by: Alan Stern
Co-Developed-by: David Howells
Signed-off-by: Andrea Parri
Signed-off-by: Alan Stern
Signed-off-by: David Howells
Signed-off-by: Paul E. McKenney
Acked-by: Randy Dunlap
Cc: Akira Yokosawa
Cc: Andrew Morton
Cc: Boqun Feng
Cc: Jade Alglave
Cc: Linus Torvalds
Cc: Luc Maranget
Cc: Nicholas Piggin
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: linux-a...@vger.kernel.org
Cc: parri.and...@gmail.com
Link:
http://lkml.kernel.org/r/1526338889-7003-1-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
include/linux/spinlock.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 4894d322d258..1e8a46435838 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -380,6 +380,24 @@ static __always_inline int spin_trylock_irq(spinlock_t
*lock)
raw_spin_trylock_irqsave(spinlock_check(lock), flags); \
})
+/**
+ * spin_is_locked() - Check whether a spinlock is locked.
+ * @lock: Pointer to the spinlock.
+ *
+ * This function is NOT required to provide any memory ordering
+ * guarantees; it could be used for debugging purposes or, when
+ * additional synchronization is needed, accompanied with other
+ * constructs (memory barriers) enforcing the synchronization.
+ *
+ * Returns: 1 if @lock is locked, 0 otherwise.
+ *
+ * Note that the function only tells you that the spinlock is
+ * seen to be locked, not that it is locked on your CPU.
+ *
+ * Further, on CONFIG_SMP=n builds with CONFIG_DEBUG_SPINLOCK=n,
+ * the return value is always 0 (see include/linux/spinlock_up.h).
+ * Therefore you should not rely heavily on the return value.
+ */
static __always_inline int spin_is_locked(spinlock_t *lock)
{
return raw_spin_is_locked(&lock->rlock);
[tip:locking/core] locking/Documentation: Use `warning` RST directive
Commit-ID: 173af2613efdc29547718848a0a2928a26b1398f Gitweb: https://git.kernel.org/tip/173af2613efdc29547718848a0a2928a26b1398f Author: SeongJae Park AuthorDate: Mon, 14 May 2018 15:55:33 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:15 +0200 locking/Documentation: Use `warning` RST directive Use the proper RST directive, pointed out by a build warning. Signed-off-by: SeongJae Park Signed-off-by: Paul E. McKenney Cc: Andrew Morton Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: aki...@gmail.com Cc: boqun.f...@gmail.com Cc: dhowe...@redhat.com Cc: j.algl...@ucl.ac.uk Cc: linux-a...@vger.kernel.org Cc: luc.maran...@inria.fr Cc: npig...@gmail.com Cc: parri.and...@gmail.com Cc: st...@rowland.harvard.edu Link: http://lkml.kernel.org/r/1526338533-6044-8-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- Documentation/core-api/atomic_ops.rst | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Documentation/core-api/atomic_ops.rst b/Documentation/core-api/atomic_ops.rst index 4ea4af71e68a..2e7165f86f55 100644 --- a/Documentation/core-api/atomic_ops.rst +++ b/Documentation/core-api/atomic_ops.rst @@ -466,10 +466,12 @@ Like the above, except that these routines return a boolean which indicates whether the changed bit was set _BEFORE_ the atomic bit operation. -WARNING! It is incredibly important that the value be a boolean, -ie. "0" or "1". Do not try to be fancy and save a few instructions by -declaring the above to return "long" and just returning something like -"old_val & mask" because that will not work. + +.. warning:: +It is incredibly important that the value be a boolean, ie. "0" or "1". +Do not try to be fancy and save a few instructions by declaring the +above to return "long" and just returning something like "old_val & +mask" because that will not work. For one thing, this return value gets truncated to int in many code paths using these interfaces, so on 64-bit if the bit is set in the
[tip:locking/core] locking/Documentation: Fix incorrect example code
Commit-ID: fc7bdc90249b216051d06496577c306327f2e3f5 Gitweb: https://git.kernel.org/tip/fc7bdc90249b216051d06496577c306327f2e3f5 Author: SeongJae Park AuthorDate: Mon, 14 May 2018 15:55:32 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:14 +0200 locking/Documentation: Fix incorrect example code - Remove a stale line of code - Fix the condition of the READ_ONCE() example Signed-off-by: SeongJae Park Signed-off-by: Paul E. McKenney Acked-by: Alan Stern Cc: Andrew Morton Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: aki...@gmail.com Cc: boqun.f...@gmail.com Cc: dhowe...@redhat.com Cc: j.algl...@ucl.ac.uk Cc: linux-a...@vger.kernel.org Cc: luc.maran...@inria.fr Cc: npig...@gmail.com Cc: parri.and...@gmail.com Link: http://lkml.kernel.org/r/1526338533-6044-7-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- Documentation/core-api/atomic_ops.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/core-api/atomic_ops.rst b/Documentation/core-api/atomic_ops.rst index fce929144ccd..4ea4af71e68a 100644 --- a/Documentation/core-api/atomic_ops.rst +++ b/Documentation/core-api/atomic_ops.rst @@ -111,7 +111,6 @@ If the compiler can prove that do_something() does not store to the variable a, then the compiler is within its rights transforming this to the following:: - tmp = a; if (a > 0) for (;;) do_something(); @@ -119,7 +118,7 @@ the following:: If you don't want the compiler to do this (and you probably don't), then you should use something like the following:: - while (READ_ONCE(a) < 0) + while (READ_ONCE(a) > 0) do_something(); Alternatively, you could place a barrier() call in the loop.
[tip:locking/core] locking/memory-barriers.txt/kokr: Update Korean translation to de-emphasize smp_read_barrier_depends() some more
Commit-ID: e89641dd038aa8affbbdc84b6633ccce5d2a2240
Gitweb: https://git.kernel.org/tip/e89641dd038aa8affbbdc84b6633ccce5d2a2240
Author: SeongJae Park
AuthorDate: Mon, 14 May 2018 15:55:31 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:14 +0200
locking/memory-barriers.txt/kokr: Update Korean translation to de-emphasize
smp_read_barrier_depends() some more
Translate this commit to Korean:
f28f0868feb1 ("locking/memory-barriers: De-emphasize
smp_read_barrier_depends() some more")
Signed-off-by: SeongJae Park
Signed-off-by: Paul E. McKenney
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Cc: st...@rowland.harvard.edu
Link:
http://lkml.kernel.org/r/1526338533-6044-6-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
.../translations/ko_KR/memory-barriers.txt | 27 ++
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt
b/Documentation/translations/ko_KR/memory-barriers.txt
index 99ef4ca1c1bf..21e78af7ee93 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -80,7 +80,7 @@ Documentation/memory-barriers.txt
- 메모리 배리어의 종류.
- 메모리 배리어에 대해 가정해선 안될 것.
- - 데이터 의존성 배리어.
+ - 데이터 의존성 배리어 (역사적).
- 컨트롤 의존성.
- SMP 배리어 짝맞추기.
- 메모리 배리어 시퀀스의 예.
@@ -576,8 +576,14 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
Documentation/DMA-API.txt
-데이터 의존성 배리어
-
+데이터 의존성 배리어 (역사적)
+-
+
+리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에
+추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐
+전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다.
+그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성
+배리어에 대한 이야기를 적습니다.
데이터 의존성 배리어의 사용에 있어 지켜야 하는 사항들은 약간 미묘하고, 데이터
의존성 배리어가 사용되어야 하는 상황도 항상 명백하지는 않습니다. 설명을 위해
@@ -2802,8 +2808,9 @@ CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을
여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들
-사이에 넣어야 합니다. 이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성
-큐를 처리하도록 강제하게 됩니다.
+사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로
+그렇게 됩니다). 이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를
+처리하도록 강제하게 됩니다.
CPU 1 CPU 2 COMMENT
=== === ===
@@ -2833,9 +2840,9 @@ CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을
액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장
약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
-더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, Alpha 아키텍쳐 전용
-코드와 READ_ONCE() 매크로 내부에서를 제외하고는 smp_read_barrier_depends() 가
-사용되지 않아야 함을 알아두시기 바랍니다.
+더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15
+이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는
+smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다.
캐시 일관성 VS DMA
@@ -2997,7 +3004,9 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서
메모리 일관성 시스템과 함께 두개의 캐시를 동기화 시켜서, 포인터 변경과 새로운
데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다.
-리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다.
+리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15
+부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서
+Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다.
위의 "캐시 일관성" 서브섹션을 참고하세요.
[tip:locking/core] locking/memory-barriers.txt/kokr: Update Korean translation to fix description of data dependency barriers
Commit-ID: e2ba8041f2edb2e998f2bd7b3fd5f2bcf6a5edd4
Gitweb: https://git.kernel.org/tip/e2ba8041f2edb2e998f2bd7b3fd5f2bcf6a5edd4
Author: SeongJae Park
AuthorDate: Mon, 14 May 2018 15:55:30 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:14 +0200
locking/memory-barriers.txt/kokr: Update Korean translation to fix description
of data dependency barriers
Translate this commit to Korean:
51de78892b12 ("memory-barriers: Fix description of data dependency barriers")
Signed-off-by: SeongJae Park
Signed-off-by: Paul E. McKenney
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Cc: st...@rowland.harvard.edu
Link:
http://lkml.kernel.org/r/1526338533-6044-5-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
Documentation/translations/ko_KR/memory-barriers.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt
b/Documentation/translations/ko_KR/memory-barriers.txt
index 2c0ab128cd04..99ef4ca1c1bf 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -427,8 +427,8 @@ CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니
데이터 의존성 배리어는 읽기 배리어의 보다 완화된 형태입니다. 두개의 로드
오퍼레이션이 있고 두번째 것이 첫번째 것의 결과에 의존하고 있을 때(예:
두번째 로드가 참조할 주소를 첫번째 로드가 읽는 경우), 두번째 로드가 읽어올
- 데이터는 첫번째 로드에 의해 그 주소가 얻어지기 전에 업데이트 되어 있음을
- 보장하기 위해서 데이터 의존성 배리어가 필요할 수 있습니다.
+ 데이터는 첫번째 로드에 의해 그 주소가 얻어진 뒤에 업데이트 됨을 보장하기
+ 위해서 데이터 의존성 배리어가 필요할 수 있습니다.
데이터 의존성 배리어는 상호 의존적인 로드 오퍼레이션들 사이의 부분적 순서
세우기입니다; 스토어 오퍼레이션들이나 독립적인 로드들, 또는 중복되는
[tip:locking/core] locking/memory-barriers.txt/kokr: Update Korean translation to cross-reference "tools/memory-model/"
Commit-ID: df9e0cc85c014868e57d2466239623f150c81b1a
Gitweb: https://git.kernel.org/tip/df9e0cc85c014868e57d2466239623f150c81b1a
Author: SeongJae Park
AuthorDate: Mon, 14 May 2018 15:55:29 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:14 +0200
locking/memory-barriers.txt/kokr: Update Korean translation to cross-reference
"tools/memory-model/"
Translate this commit to Korean:
621df431b0ac ("Documentation/memory-barriers.txt: Cross-reference
"tools/memory-model/"")
Signed-off-by: SeongJae Park
Signed-off-by: Paul E. McKenney
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Cc: st...@rowland.harvard.edu
Link:
http://lkml.kernel.org/r/1526338533-6044-4-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
Documentation/translations/ko_KR/memory-barriers.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt
b/Documentation/translations/ko_KR/memory-barriers.txt
index 44e47c2d33cf..2c0ab128cd04 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -36,6 +36,9 @@ Documentation/memory-barriers.txt
부분도 있고, 의도하진 않았지만 사람에 의해 쓰였다보니 불완전한 부분도 있습니다.
이 문서는 리눅스에서 제공하는 다양한 메모리 배리어들을 사용하기 위한
안내서입니다만, 뭔가 이상하다 싶으면 (그런게 많을 겁니다) 질문을 부탁드립니다.
+일부 이상한 점들은 공식적인 메모리 일관성 모델과 tools/memory-model/ 에 있는
+관련 문서를 참고해서 해결될 수 있을 겁니다. 그러나, 이 메모리 모델조차도 그
+관리자들의 의견의 집합으로 봐야지, 절대 옳은 예언자로 신봉해선 안될 겁니다.
다시 말하지만, 이 문서는 리눅스가 하드웨어에 기대하는 사항에 대한 명세서가
아닙니다.
[tip:locking/core] locking/memory-barriers.txt/kokr: Update Korean translation to de-emphasize smp_read_barrier_depends()
Commit-ID: 1ea32723c42a5c73a6da6a9731b9bdb6c5f206f0
Gitweb: https://git.kernel.org/tip/1ea32723c42a5c73a6da6a9731b9bdb6c5f206f0
Author: SeongJae Park
AuthorDate: Mon, 14 May 2018 15:55:28 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:14 +0200
locking/memory-barriers.txt/kokr: Update Korean translation to de-emphasize
smp_read_barrier_depends()
Translate this commit to Korean:
9ad3c143d7d6 ("doc: De-emphasize smp_read_barrier_depends")
Signed-off-by: SeongJae Park
Signed-off-by: Paul E. McKenney
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Cc: st...@rowland.harvard.edu
Link:
http://lkml.kernel.org/r/1526338533-6044-3-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
Documentation/translations/ko_KR/memory-barriers.txt | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt
b/Documentation/translations/ko_KR/memory-barriers.txt
index edef154d77b2..44e47c2d33cf 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -1790,7 +1790,7 @@ CPU 메모리 배리어
범용 mb()smp_mb()
쓰기 wmb() smp_wmb()
읽기 rmb() smp_rmb()
- 데이터 의존성 read_barrier_depends() smp_read_barrier_depends()
+ 데이터 의존성 READ_ONCE()
데이터 의존성 배리어를 제외한 모든 메모리 배리어는 컴파일러 배리어를
@@ -2829,7 +2829,10 @@ CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을
다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리
액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장
약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
-사용되지 않았을 때에는 그런 조정이 필요하지 않게 했습니다.
+사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
+더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, Alpha 아키텍쳐 전용
+코드와 READ_ONCE() 매크로 내부에서를 제외하고는 smp_read_barrier_depends() 가
+사용되지 않아야 함을 알아두시기 바랍니다.
캐시 일관성 VS DMA
[tip:locking/core] locking/memory-barriers.txt/kokr: Update Korean translation to indicate that READ_ONCE() now implies smp_barrier_depends()
Commit-ID: eabed716672c2f2275887ec69e001a9cc30b2294
Gitweb: https://git.kernel.org/tip/eabed716672c2f2275887ec69e001a9cc30b2294
Author: SeongJae Park
AuthorDate: Mon, 14 May 2018 15:55:27 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:13 +0200
locking/memory-barriers.txt/kokr: Update Korean translation to indicate that
READ_ONCE() now implies smp_barrier_depends()
Translate this commit to Korean:
40555946447a ("doc: READ_ONCE() now implies smp_barrier_depends()")
Signed-off-by: SeongJae Park
Signed-off-by: Paul E. McKenney
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Cc: st...@rowland.harvard.edu
Link:
http://lkml.kernel.org/r/1526338533-6044-2-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
Documentation/translations/ko_KR/memory-barriers.txt | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt
b/Documentation/translations/ko_KR/memory-barriers.txt
index 0a0930ab4156..edef154d77b2 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -255,17 +255,20 @@ CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니
(*) 어떤 CPU 든, 의존성이 존재하는 메모리 액세스들은 해당 CPU 자신에게
있어서는 순서대로 메모리 시스템에 수행 요청됩니다. 즉, 다음에 대해서:
- Q = READ_ONCE(P); smp_read_barrier_depends(); D = READ_ONCE(*Q);
+ Q = READ_ONCE(P); D = READ_ONCE(*Q);
CPU 는 다음과 같은 메모리 오퍼레이션 시퀀스를 수행 요청합니다:
Q = LOAD P, D = LOAD *Q
- 그리고 그 시퀀스 내에서의 순서는 항상 지켜집니다. 대부분의 시스템에서
- smp_read_barrier_depends() 는 아무일도 안하지만 DEC Alpha 에서는
- 명시적으로 사용되어야 합니다. 보통의 경우에는 smp_read_barrier_depends()
- 를 직접 사용하는 대신 rcu_dereference() 같은 것들을 사용해야 함을
- 알아두세요.
+ 그리고 그 시퀀스 내에서의 순서는 항상 지켜집니다. 하지만, DEC Alpha 에서
+ READ_ONCE() 는 메모리 배리어 명령도 내게 되어 있어서, DEC Alpha CPU 는
+ 다음과 같은 메모리 오퍼레이션들을 내놓게 됩니다:
+
+ Q = LOAD P, MEMORY_BARRIER, D = LOAD *Q, MEMORY_BARRIER
+
+ DEC Alpha 에서 수행되든 아니든, READ_ONCE() 는 컴파일러로부터의 악영향
+ 또한 제거합니다.
(*) 특정 CPU 내에서 겹치는 영역의 메모리에 행해지는 로드와 스토어 들은 해당
CPU 안에서는 순서가 바뀌지 않은 것으로 보여집니다. 즉, 다음에 대해서:
[tip:locking/core] locking/memory-barriers.txt: Fix broken DMA vs. MMIO ordering example
Commit-ID: 5846581e35637771952602eecc1e20ece5ced011 Gitweb: https://git.kernel.org/tip/5846581e35637771952602eecc1e20ece5ced011 Author: Will Deacon AuthorDate: Mon, 14 May 2018 15:55:26 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:13 +0200 locking/memory-barriers.txt: Fix broken DMA vs. MMIO ordering example The section of memory-barriers.txt that describes the dma_Xmb() barriers has an incorrect example claiming that a wmb() is required after writing to coherent memory in order for those writes to be visible to a device before a subsequent MMIO access using writel() can reach the device. In fact, this ordering guarantee is provided (at significant cost on some architectures such as arm and power) by writel, so the wmb() is not necessary. writel_relaxed exists for cases where this ordering is not required. Fix the example and update the text to make this clearer. Reported-by: Sinan Kaya Signed-off-by: Will Deacon Signed-off-by: Paul E. McKenney Cc: Andrew Morton Cc: Arnd Bergmann Cc: Benjamin Herrenschmidt Cc: Jason Gunthorpe Cc: Jonathan Corbet Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: aki...@gmail.com Cc: boqun.f...@gmail.com Cc: dhowe...@redhat.com Cc: j.algl...@ucl.ac.uk Cc: linux-a...@vger.kernel.org Cc: luc.maran...@inria.fr Cc: npig...@gmail.com Cc: parri.and...@gmail.com Cc: st...@rowland.harvard.edu Link: http://lkml.kernel.org/r/1526338533-6044-1-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- Documentation/memory-barriers.txt | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 6dafc8085acc..34c1970908a5 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1920,9 +1920,6 @@ There are some more advanced barrier functions: /* assign ownership */ desc->status = DEVICE_OWN; - /* force memory to sync before notifying device via MMIO */ - wmb(); - /* notify device of new descriptors */ writel(DESC_NOTIFY, doorbell); } @@ -1930,11 +1927,15 @@ There are some more advanced barrier functions: The dma_rmb() allows us guarantee the device has released ownership before we read the data from the descriptor, and the dma_wmb() allows us to guarantee the data is written to the descriptor before the device - can see it now has ownership. The wmb() is needed to guarantee that the - cache coherent memory writes have completed before attempting a write to - the cache incoherent MMIO region. - - See Documentation/DMA-API.txt for more information on consistent memory. + can see it now has ownership. Note that, when using writel(), a prior + wmb() is not needed to guarantee that the cache coherent memory writes + have completed before writing to the MMIO region. The cheaper + writel_relaxed() does not provide this guarantee and must not be used + here. + + See the subsection "Kernel I/O barrier effects" for more information on + relaxed I/O accessors and the Documentation/DMA-API.txt file for more + information on consistent memory. MMIO WRITE BARRIER
Re: [PATCH v2 1/3] sched/cpufreq: always consider blocked FAIR utilization
On 14 May 2018 at 18:48, Patrick Bellasi wrote:
> On 14-May 11:16, Vincent Guittot wrote:
>> Hi Patrick,
>
> Hi Vincent,
>
>> On 11 May 2018 at 15:15, Patrick Bellasi wrote:
>> > Since the refactoring introduced by:
>> >
>> >commit 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support")
>> >
>> > we aggregate FAIR utilization only if this class has runnable tasks.
>> > This was mainly due to avoid the risk to stay on an high frequency just
>> > because of the blocked utilization of a CPU not being properly decayed
>> > while the CPU was idle.
>> >
>> > However, since:
>> >
>> >commit 31e77c93e432 ("sched/fair: Update blocked load when newly idle")
>> >
>> > the FAIR blocked utilization is properly decayed also for IDLE CPUs.
>> >
>> > This allows us to use the FAIR blocked utilization as a safe mechanism
>> > to gracefully reduce the frequency only if no FAIR tasks show up on a
>> > CPU for a reasonable period of time.
>> >
>> > Moreover, we also reduce the frequency drops of CPUs running periodic
>> > tasks which, depending on the task periodicity and the time required
>> > for a frequency switch, was increasing the chances to introduce some
>> > undesirable performance variations.
>> >
>> > Reported-by: Vincent Guittot
>> > Signed-off-by: Patrick Bellasi
>> > Acked-by: Viresh Kumar
>> > Cc: Ingo Molnar
>> > Cc: Peter Zijlstra
>> > Cc: Rafael J. Wysocki
>> > Cc: Vincent Guittot
>> > Cc: Viresh Kumar
>> > Cc: Joel Fernandes
>> > Cc: linux-kernel@vger.kernel.org
>> > Cc: linux...@vger.kernel.org
>>
>> With this patch, I can't see the spurious OPP changes that I was seeing
>> before
>
> Cool thanks... regarding OPP updates I've added some more comments in
> my reply to Joel's comments to my last patch of this series.
>
> Would be nice if you can have a look... toward the end there are some
> considerations about schedutil updates (indirectly) triggered by your
> patches for blocked load updates on IDLE CPUs.
I have started to have a look at the 3rd patch and was checking if
there were some hole and your proposal regarding the update of blocked
load and the removed utilization
I will read your latest comment.
>
>> FWIW
>> Acked-by: Vincent Guittot
>> Tested-by: Vincent Guittot
>
> Thanks for testing, will add these to the next respin.
>
> --
> #include
>
> Patrick Bellasi
Re: [GIT PULL 0/5] perf/urgent fixes
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit 49cf4a4b3f5a8b02556dd4f45c5cee598d4fc799: > > Merge tag 'perf-urgent-for-mingo-4.17-20180507' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent > (2018-05-10 20:09:00 +0200) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-urgent-for-mingo-4.17-20180514 > > for you to fetch changes up to c23080a6e4e853cff2834436e3cf33eae7723900: > > perf tools: Add missing newline when parsing empty BPF proggie (2018-05-11 > 12:10:02 -0300) > > > perf/urgent fixes: > > - Fix segfault when processing unknown threads in cs-etm (Leo Yan) > > - Fix "perf test inet_pton" on s390 failing due to missing inline (Thomas > Richter) > > - Display all available events on 'perf annotate --stdio' (Jin Yao) > > - Add missing newline when parsing empty BPF proggie (Arnaldo Carvalho de > Melo) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (1): > perf tools: Add missing newline when parsing empty BPF proggie > > Jin Yao (1): > perf annotate: Display all available events on --stdio > > Leo Yan (2): > perf cs-etm: Support unknown_thread in cs_etm_auxtrace > perf cs-etm: Remove redundant space > > Thomas Richter (1): > perf test: "probe libc's inet_pton" fails on s390 due to missing inline > > .../tests/shell/record+probe_libc_inet_pton.sh | 2 +- > tools/perf/util/annotate.c | 3 +++ > tools/perf/util/cs-etm.c | 28 > ++ > tools/perf/util/parse-events.c | 2 +- > 4 files changed, 29 insertions(+), 6 deletions(-) Pulled, thanks a lot Arnaldo! Ingo
Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"
On 11-05-18, 14:57, Marek Szyprowski wrote: > Hi Frank, > > On 2018-05-10 18:04, Frank Mori Hess wrote: > > On Thu, May 10, 2018 at 4:31 AM, Marek Szyprowski > > wrote: > >> On 2018-05-09 19:48, Frank Mori Hess wrote: > >>> On Wed, May 9, 2018 at 9:19 AM, Marek Szyprowski > >>> wrote: > I understand that pl330 doesn't support real PAUSE, but as it has been > implemented since 2015 the limited support is perfectly possible - just > to let serial driver to read the amount of data transferred. > > Please note that DMA engine documentation clearly states that the best > residue granularity the driver might expect is BURST granularity. There > is no way to get the information about the data which still sits in the > DMA engine fifo when transfer is paused/terminated. This means that > the serial driver should set maxburst = 1 if it is interested in > getting exact number of bytes received/sent. With maxburst = 1 there > is no such thing as data loose in the DMA engine fifo. > >>> That is not my understanding of the dmaengine pause requirements, but > >>> of course Vinod can speak authoritatively on this. > >> Basing on the comments in dma_residue_granularity enum documentation (see > >> include/linux/dmaengine.h) there is no better granularity of residue > >> reporting than BURST units. If driver needs byte accuracy, then it should > >> use MAXBURST=1 and DMA_SLAVE_BUSWIDTH_1_BYTE configuration. > > That's an interesting line of thought. The 8250 serial driver clearly > > assumes it can do the sequence > > > > dma pause > > read residue > > dma terminate > > > > without data loss. > > Right. From DMA engine API perspective this is the only valid way to > read the > residue when you terminate the transfer. Not really, API allows you to read any point of time, you may support it or not is different matter. Granularity of reporting is also a different point. > > >It checks for the capabilities > > > > cmd_pause > > cmd_terminate > > residue_granularity != DMA_RESIDUE_GRANULARITY_DESCRIPTOR > > Checking for cmd_pause is a bit too strict, because cmd_pause means 'driver > supports both pause and resume', but the serial driver doesn't use resume at > all. A check for residue_granularity != DMA_RESIDUE_GRANULARITY_DESCRIPTOR > is on the other hand a bit too loose. thats true and it was added for audio which does pause/resume. If you feel it helps in serial to get pause & resume capabilities independently we can split them up, feel free to send a patch For Pause/resume data loss is _not_ expected. > > and some of the 8250 drivers like 8250_dw.c set a maxburst > 1. If it > > can't count on the pause/residue/terminate working without data loss > > then it is just broken. As is the 8250_omap.c driver. Is the > > description of dmaengine_pause in the documentation of "This pauses > > activity on the DMA channel without data loss" to be interpreted as > > "as long as you resume afterwards"? > > I assume that this requirement is for both - resuming and terminating. Terminate is abort, data loss may happen here. > >>> I also don't agree > >>> that data loss cannot happen for single transfers. It only becomes > >>> less likely since there are fewer bytes in the dma controller fifo and > >>> they stay there for a shorter period of time. But even so, there is > >>> nothing stopping the DMAKILL from killing the transfer thread after it > >>> does a single byte load but before it does the associated single byte > >>> store, as they are performed by separate instructions. As far as your > >>> serial port goes, the byte has been read by the host, even though it > >>> never made it to memory, so it is gone forever. The dma-330 does have > >>> a load lock which prevents some operations from interrupting a > >>> load/store combination, but in my observations DMAKILL does not > >>> respect the load lock. > >> For the last 3 years no one observed any issue with the current design > >> (single transfers with DMA_SLAVE_BUSWIDTH_1_BYTE). By removing this > >> feature we will loose ability to use DMA in the serial drivers, what is > >> mainly useful for low-power bluetooth operation (serial console is really > >> negligible case). > > It's not surprising it hasn't been reported. It is a race that > > requires a DMAKILL to be issued just as a byte is in-flight through > > the dma controller. The only reason a driver would pause the > > un-resumeable pl330 would be because the driver either knows or > > suspects no more data will be arriving and it gives up on the > > transfer. The only reason I noticed is we had a test which sent data > > to a serial port, waited just long enough for the serial port rx to > > timeout, then sent more data just as the pause was issuing DMAKILL. > > And then the test did this a few hundred thousand times until it > > noticed bad data. Also, given the way 8250 rx timeouts work, a person > > typing into a serial console wouldn't t
Re: possible deadlock in sk_diag_fill
On Tue, May 15, 2018 at 07:19:39AM +0200, Dmitry Vyukov wrote:
> On Mon, May 14, 2018 at 8:00 PM, Andrei Vagin wrote:
> >> >> Hello,
> >> >>
> >> >> syzbot found the following crash on:
> >> >>
> >> >> HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of
> >> >> git://git.k..
> >> >> git tree: upstream
> >> >> console output: https://syzkaller.appspot.com/x/log.txt?x=12164c9780
> >> >> kernel config:
> >> >> https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
> >> >> dashboard link:
> >> >> https://syzkaller.appspot.com/bug?extid=c1872be62e587eae9669
> >> >> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> >> >> userspace arch: i386
> >> >>
> >> >> Unfortunately, I don't have any reproducer for this crash yet.
> >> >>
> >> >> IMPORTANT: if you fix the bug, please add the following tag to the
> >> >> commit:
> >> >> Reported-by: syzbot+c1872be62e587eae9...@syzkaller.appspotmail.com
> >> >>
> >> >>
> >> >> ==
> >> >> WARNING: possible circular locking dependency detected
> >> >> 4.17.0-rc3+ #59 Not tainted
> >> >> --
> >> >> syz-executor1/25282 is trying to acquire lock:
> >> >> 4fddf743 (&(&u->lock)->rlock/1){+.+.}, at: sk_diag_dump_icons
> >> >> net/unix/diag.c:82 [inline]
> >> >> 4fddf743 (&(&u->lock)->rlock/1){+.+.}, at:
> >> >> sk_diag_fill.isra.5+0xa43/0x10d0 net/unix/diag.c:144
> >> >>
> >> >> but task is already holding lock:
> >> >> b6895645 (rlock-AF_UNIX){+.+.}, at: spin_lock
> >> >> include/linux/spinlock.h:310 [inline]
> >> >> b6895645 (rlock-AF_UNIX){+.+.}, at: sk_diag_dump_icons
> >> >> net/unix/diag.c:64 [inline]
> >> >> b6895645 (rlock-AF_UNIX){+.+.}, at:
> >> >> sk_diag_fill.isra.5+0x94e/0x10d0
> >> >> net/unix/diag.c:144
> >> >>
> >> >> which lock already depends on the new lock.
> >> >
> >> > In the code, we have a comment which explains why it is safe to take
> >> > this lock
> >> >
> >> > /*
> >> > * The state lock is outer for the same sk's
> >> > * queue lock. With the other's queue locked it's
> >> > * OK to lock the state.
> >> > */
> >> > unix_state_lock_nested(req);
> >> >
> >> > It is a question how to explain this to lockdep.
> >>
> >> Do I understand it correctly that (&u->lock)->rlock associated with
> >> AF_UNIX is locked under rlock-AF_UNIX, and then rlock-AF_UNIX is
> >> locked under (&u->lock)->rlock associated with AF_NETLINK? If so, I
> >> think we need to split (&u->lock)->rlock by family too, so that we
> >> have u->lock-AF_UNIX and u->lock-AF_NETLINK.
> >
> > I think here is another problem. lockdep woried about
> > sk->sk_receive_queue vs unix_sk(s)->lock.
> >
> > sk_diag_dump_icons() takes sk->sk_receive_queue and then
> > unix_sk(s)->lock.
> >
> > unix_dgram_sendmsg takes unix_sk(sk)->lock and then sk->sk_receive_queue.
> >
> > sk_diag_dump_icons() takes locks for two different sockets, but
> > unix_dgram_sendmsg() takes locks for one socket.
> >
> > sk_diag_dump_icons
> > if (sk->sk_state == TCP_LISTEN) {
> > spin_lock(&sk->sk_receive_queue.lock);
> > skb_queue_walk(&sk->sk_receive_queue, skb) {
> > unix_state_lock_nested(req);
> > spin_lock_nested(&unix_sk(s)->lock,
> >
> >
> > unix_dgram_sendmsg
> > unix_state_lock(other)
> > spin_lock(&unix_sk(s)->lock)
> > skb_queue_tail(&other->sk_receive_queue, skb);
> > spin_lock_irqsave(&list->lock, flags);
>
>
> Do you mean the following?
> There is socket 1 with state lock (S1) and queue lock (Q2), and socket
> 2 with state lock (S2) and queue lock (Q2). unix_dgram_sendmsg lock
> S1->Q1. And sk_diag_dump_icons locks Q1->S2.
> If yes, then this looks pretty much as deadlock. Consider that 2
> unix_dgram_sendmsg in 2 different threads lock S1 and S2 respectively.
> Now 2 sk_diag_dump_icons in 2 different threads lock Q1 and Q2
> respectively. Now sk_diag_dump_icons want to lock S's, and
> unix_dgram_sendmsg want to lock Q's. Nobody can proceed.
Q1 and S1 belongs to a listen socket, so they can't be taken from
unix_dgram_sendmsg().
Re: [PATCH] mmc: sdhci-pxav3: don't disable clocks when we might get an interrupt
Hi,
On 05/15/2018 01:59 AM, Adrian Hunter wrote:
> On 15/05/18 00:56, Thomas Hebb wrote:
>> Currently, runtime_suspend() unconditionally disables the clock gates
>> for the controller, which means that it's unable to receive interrupts
>> generated by connected SDIO cards.
>
> We currently get / put runtime pm with enable / disable of the SDIO IRQ
> (refer sdhci_enable_sdio_irq()) so are you sure this is needed?
You're correct; this patch is unnecessary. I wrote it before
923713b35745 ("mmc: sdhci: Disable runtime pm when the sdio_irq is
enabled"), and it was needed then. Sorry for the noise.
FYI, sdhci-esdhc-imx still checks the IRQ in its suspend/resume
functions. That's one of the things that misled me to think this patch
was still relevant.
>>
>> Signed-off-by: Thomas Hebb
>> ---
>> drivers/mmc/host/sdhci-pxav3.c | 16 ++--
>> 1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
>> index a34434166ca7..59760f3cc1d7 100644
>> --- a/drivers/mmc/host/sdhci-pxav3.c
>> +++ b/drivers/mmc/host/sdhci-pxav3.c
>> @@ -562,9 +562,11 @@ static int sdhci_pxav3_runtime_suspend(struct device
>> *dev)
>> if (host->tuning_mode != SDHCI_TUNING_MODE_3)
>> mmc_retune_needed(host->mmc);
>>
>> -clk_disable_unprepare(pxa->clk_io);
>> -if (!IS_ERR(pxa->clk_core))
>> -clk_disable_unprepare(pxa->clk_core);
>> +if (!sdhci_sdio_irq_enabled(host)) {
>> +clk_disable_unprepare(pxa->clk_io);
>> +if (!IS_ERR(pxa->clk_core))
>> +clk_disable_unprepare(pxa->clk_core);
>> +}
>>
>> return 0;
>> }
>> @@ -575,9 +577,11 @@ static int sdhci_pxav3_runtime_resume(struct device
>> *dev)
>> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> struct sdhci_pxa *pxa = sdhci_pltfm_priv(pltfm_host);
>>
>> -clk_prepare_enable(pxa->clk_io);
>> -if (!IS_ERR(pxa->clk_core))
>> -clk_prepare_enable(pxa->clk_core);
>> +if (!sdhci_sdio_irq_enabled(host)) {
>> +clk_prepare_enable(pxa->clk_io);
>> +if (!IS_ERR(pxa->clk_core))
>> +clk_prepare_enable(pxa->clk_core);
>> +}
>>
>> return sdhci_runtime_resume_host(host);
>> }
>>
>
Re: [PATCH memory-model 0/19] Updates to the formal memory model
Hi, * Paul E. McKenney wrote: > Hello! > > This series contains updates to the Linux kernel's formal memory model in > tools/memory-model. These are ready for inclusion into -tip. > > 1.Rename LKMM's "link" and "rcu-path" relations to "rcu-link" > and "rb", respectively, courtesy of Alan Stern. > > 2.Redefine LKMM's "rb" relation in terms of rcu-fence in order > to match the structure of LKMM's other strong fences, courtesy > of Alan Stern. > > 3.Update required version of herdtools7, courtesy of Akira Yokosawa. > > 4. Fix cheat sheet typo: "RWM" should be "RMW", courtesy of Paolo Bonzini. > > 5.Improve cheatsheet.txt key for SELF and SV. > > 6.Fix cheatsheet.txt to note that smp_mb__after_atomic() orders > later RMW operations. > > 7.Model smp_store_mb(), courtesy of Andrea Parri. > > 8.Fix coding style in 'linux-kernel.def', courtesy of Andrea Parri. > > 9.Add scripts to test the memory model. > > 10. Add model support for spin_is_locked(), courtesy of Luc Maranget. > > 11. Flag the tests that exercise "cumulativity" and "propagation". > > 12. Remove duplicated code from lock.cat, courtesy of Alan Stern. > > 13. Improve comments in lock.cat, courtesy of Alan Stern. > > 14. Improve mixed-access checking in lock.cat, courtesy of Alan Stern. > > 15. Remove out-of-date comments and code from lock.cat, which have > been obsoleted by the settled-upon spin_is_locked() semantics, > courtesy of Alan Stern. > > 16. Fix coding style in 'lock.cat', bringing the indentation to > Linux-kernel standard, courtesy of Andrea Parri. > > 17. Update Andrea Parri's email address in the MAINTAINERS file, > oddly enough courtesy of Andrea Parri. ;-) > > 18. Update ASPLOS information now that ASPLOS has come and gone, > courtesy of Andrea Parri. > > 19. Add reference for 'Simplifying ARM concurrency', courtesy > of Andrea Parri. > > Thanx, Paul > > > > MAINTAINERS | > 2 > tools/memory-model/Documentation/cheatsheet.txt | > 7 > tools/memory-model/Documentation/explanation.txt | > 261 +- > tools/memory-model/Documentation/references.txt | > 17 > tools/memory-model/README | > 2 > tools/memory-model/linux-kernel.bell | > 4 > tools/memory-model/linux-kernel.cat | > 53 +- > tools/memory-model/linux-kernel.def | > 34 - > tools/memory-model/litmus-tests/.gitignore| > 1 > tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus | > 2 > tools/memory-model/litmus-tests/MP+polockmbonce+poacquiresilsil.litmus| > 35 + > tools/memory-model/litmus-tests/MP+polockonce+poacquiresilsil.litmus | > 34 + > tools/memory-model/litmus-tests/README| > 19 > tools/memory-model/litmus-tests/WRC+pooncerelease+rmbonceonce+Once.litmus | > 4 > tools/memory-model/lock.cat | > 197 --- > tools/memory-model/scripts/checkalllitmus.sh | > 73 ++ > tools/memory-model/scripts/checklitmus.sh | > 86 +++ > 17 files changed, 595 insertions(+), 236 deletions(-) Applied this and the other two series to the locking tree, thanks Paul! I ended up editing some of the changelogs and titles, to better organize them: 99c12749b172: tools/memory-model: Add reference for 'Simplifying ARM concurrency' 1a00b4554d47: tools/memory-model: Update ASPLOS information 5ccdb7536ebe: MAINTAINERS, tools/memory-model: Update e-mail address for Andrea Parri 05604e7e3adb: tools/memory-model: Fix coding style in 'lock.cat' cee0321a404f: tools/memory-model: Remove out-of-date comments and code from lock.cat 30b795df11a1: tools/memory-model: Improve mixed-access checking in lock.cat fd0359dbac3d: tools/memory-model: Improve comments in lock.cat 8559183ccaec: tools/memory-model: Remove duplicated code from lock.cat 1bd3742043fa: tools/memory-model: Flag "cumulativity" and "propagation" tests 15553dcbca06: tools/memory-model: Add model support for spin_is_locked() 2fb6ae162f25: tools/memory-model: Add scripts to test memory model d17013e0bac6: tools/memory-model: Fix coding style in 'linux-kernel.def' bf8c6d963d16: tools/memory-model: Model 'smp_store_mb()' bfd403bb3617: tools/memory-order: Update the cheat-sheet to show that smp_mb__after_atomic() orders later RMW operations 35bb6ee67906: tools/memory-order: Improve key for SELF and SV a8
Re: [PATCH 4.4 00/56] 4.4.132-stable review
On 14 May 2018 at 12:18, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.132 release. > There are 56 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 Wed May 16 06:47:39 UTC 2018. > 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/v4.x/stable-review/patch-4.4.132-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-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.4.132-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: e33795f7a573385b26763104b63355823de20e4b git describe: v4.4.131-57-ge33795f7a573 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.131-57-ge33795f7a573 No regressions (compared to build v4.4.131-51-g9aa0dca71729) Boards, architectures and test suites: - juno-r2 - arm64 * boot - pass: 21 * kselftest - skip: 37, pass: 29 * libhugetlbfs - skip: 1, pass: 90 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 53, pass: 28 * ltp-fcntl-locktests-tests - pass: 2 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 6, pass: 57 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-hugetlb-tests - pass: 22 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-math-tests - pass: 11 * ltp-nptl-tests - pass: 2 * ltp-pty-tests - pass: 4 * ltp-sched-tests - skip: 4, pass: 10 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - skip: 140, pass: 1010 * ltp-timers-tests - pass: 13 qemu_x86_64 * boot - pass: 20 * kselftest - skip: 40, pass: 40 * libhugetlbfs - skip: 1, pass: 90 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 17, pass: 64 * ltp-fcntl-locktests-tests - pass: 2 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 6, pass: 57 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-hugetlb-tests - pass: 22 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-math-tests - pass: 11 * ltp-nptl-tests - pass: 2 * ltp-pty-tests - pass: 4 * ltp-sched-tests - skip: 1, pass: 13 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - skip: 155, pass: 995 * ltp-timers-tests - pass: 13 x15 - arm * boot - pass: 20 * kselftest - skip: 36, pass: 29 * libhugetlbfs - skip: 1, pass: 87 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 18, pass: 63 * ltp-fcntl-locktests-tests - pass: 2 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 5, pass: 58 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-hugetlb-tests - skip: 2, pass: 20 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-math-tests - pass: 11 * ltp-nptl-tests - pass: 2 * ltp-pty-tests - pass: 4 * ltp-sched-tests - skip: 1, pass: 13 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - skip: 78, pass: 1072 * ltp-timers-tests - pass: 13 x86_64 * boot - pass: 22 * kselftest - skip: 37, pass: 41 * kselftest-vsyscall-mode-native - fail: 1, skip: 37, pass: 40 * kselftest-vsyscall-mode-none - skip: 37, pass: 41 * libhugetlbfs - skip: 1, pass: 90 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 17, pass: 64 * ltp-fcntl-locktests-tests - pass: 2 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 5, pass: 58 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-hugetlb-tests - pass: 22 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-math-tests - pass: 11 * ltp-nptl-tests - pass: 2 * ltp-pty-tests - pass: 4 * ltp-sched-tests - skip: 5, pass: 9 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - skip: 119, pass: 1031 * ltp-timers-tests - pass: 13 Hikey board test results, Summary kernel: 4.4.132-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git tag: 4.4.132-rc1-hikey-20180514-190 git commit: 36ca71c104750c04fb621d8fce5843a66a21fa88 git describe: 4.4.132-rc1-hikey-20180514-190 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.132-rc1-hikey-20180514-190 No regressions (compared to build 4.4.132-rc1-hikey-20180511-188) Boards, architectures and test suites: - hi6220-hikey - arm64 * boot - pass: 20, * kselftest - pass: 27, skip: 38 * libhugetlbfs - pass: 90, skip: 1 * ltp-c
Re: linux-next: manual merge of the samsung-krzk tree with the dma-mapping tree
On Tue, May 15, 2018 at 1:09 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 10 May 2018 09:16:34 +1000 Stephen Rothwell
> wrote:
>>
>> Today's linux-next merge of the samsung-krzk tree got a conflict in:
>>
>> arch/arm/mach-exynos/Kconfig
>>
>> between commit:
>>
>> 4965a68780c5 ("arch: define the ARCH_DMA_ADDR_T_64BIT config symbol in
>> lib/Kconfig")
>>
>> from the dma-mapping tree and commit:
>>
>> c5deb598089c ("ARM: exynos: Remove support for Exynos5440")
>>
>> from the samsung-krzk tree.
>>
>> I fixed it up (the latter removed the whole section modified by
>> the former, so I just removed the section) 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.
>
> This is now a conflict between the arm-soc tree and the dma-mapping tree.
Yes, this is expected. Thanks for letting us know. I mentioned this
also in my pull request to arm-soc.
Best regards,
Krzysztof
Re: [GIT PULL 0/5] ARM: samsung/exynos: Stuff for v4.18
On Mon, May 14, 2018 at 10:55 PM, Olof Johansson wrote: > On Sun, May 13, 2018 at 05:42:33PM +0200, Krzysztof Kozlowski wrote: >> Hi, >> >> Changes for v4.18. No dependencies, no specific order of pulls. >> >> Support for Exynos5440 is removed step by step through different trees. > > 5440 was always a bit of a weird fit, it clearly was never an exynos5-family > platform. I take it there are no substantial users left that would need > mainline kernel support for it? I forgot to mention this in pull request (it is in the commit) - there are no known users. There are no real products and development boards are unpopular (probably only Samsung LSI has it). > Also, I noticed your PGP key has expired, so you should probably start > collecting signatures on a fresh subkey. It should be good, I prolonged it some time ago. Can you refresh it in your keyring? Best regards, Krzysztof
[PATCH] ARM: dts: berlin2q: add "cache-unified" to l2 node
Without this property, we get this boot warning:
"L2C: device tree omits to specify unified cache"
Signed-off-by: Jisheng Zhang
---
arch/arm/boot/dts/berlin2q.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index e23c49ae3ec2..7cba798152b9 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -149,6 +149,7 @@
l2: l2-cache-controller@ac {
compatible = "arm,pl310-cache";
reg = <0xac 0x1000>;
+ cache-unified;
cache-level = <2>;
arm,data-latency = <2 2 2>;
arm,tag-latency = <2 2 2>;
--
2.17.0
Re: [PATCH] ARM: dts: chromecast: override bad bootloader memory info
Hi,
On 05/14/2018 10:29 PM, Jisheng Zhang wrote:
> Hi,
>
> On Mon, 14 May 2018 17:56:45 -0400 Thomas Hebb wrote:
>
>> On the Chromecast, the bootloader provides us with an ATAG_MEM of
>> start=0x0100 and size=0x3eff8000. This is clearly incorrect, as the
>> range given encompasses nearly a GiB but the Chromecast only has 512MiB
>> of RAM! Additionally, this causes the kernel to be decompressed at
>> 0x8000, below the claimed beginning of RAM, and so the boot fails.
>>
>> Since the existing ATAG parsing code runs before the kernel is even
>> decompressed and irrevocably patches the device tree, don't even try
>
> This means you enabled ARM_ATAG_DTB_COMPAT. could we disable it instead?
> The ATAG is useless when we provide dtb. And IIRC, the ATAG is provided due
> to legacy history code.
>
> Thanks
Thanks for the quick review! It's true that compiling without
ARM_ATAG_DTB_COMPAT will prevent ATAG_MEM from getting parsed at all.
However, it will also prevent ATAG_CMDLINE from getting parsed, and the
command line from the Chromecast's bootloader does actually contain some
useful information--notably the mode in which the system was booted
(normal or recovery).
Userspace could conceivably want this information, so it's preferable
for the kernel to boot regardless of whether ARM_ATAG_DTB_COMPAT is
enabled. That's the intent of this patch.
I do agree in principle that ARM_ATAG_DTB_COMPAT should be disabled
whenever possible.
>> to bypass it. Instead, use the "linux,usable-memory" property instead
>> of the "reg" property to define the real range. The ATAG code only
>> overwrites reg, but linux,usable-memory is checked first in the OF
>> driver, so the fact that reg gets changed makes no difference.
>>
>> Signed-off-by: Thomas Hebb
>> ---
>> arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 12 +++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> index 20f31cdeaf38..54221f55bfa2 100644
>> --- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> +++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> @@ -52,7 +52,17 @@
>>
>> memory@0 {
>> device_type = "memory";
>> -reg = <0x 0x2000>; /* 512 MB */
>> +
>> +/*
>> + * We're using "linux,usable-memory" instead of "reg" here
>> + * because the (signed and encrypted) bootloader that shipped
>> + * with this device provides an incorrect memory range in
>> + * ATAG_MEM. Linux helpfully overrides the "reg" property with
>> + * data from the ATAG, so we can't specify the proper range
>> + * normally. Fortunately, this alternate property is checked
>> + * first by the OF driver, so we can (ab)use it instead.
>> + */
>> +linux,usable-memory = <0x 0x2000>; /* 512 MB */
>> };
>>
>> leds {
>
Re: [PATCH 1/3] ARM: dra762: hwmod: Add MCAN support
Hi Tony,
On Tuesday 01 May 2018 08:56 PM, Tony Lindgren wrote:
> Hi,
>
> * Faiz Abbas [180408 09:59]:
>> From: Lokesh Vutla
>>
>> Add MCAN hwmod data and register it for dra762 silicons.
>>
>> Signed-off-by: Lokesh Vutla
>> Signed-off-by: Faiz Abbas
>> ---
>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 32
>> +++
>> 1 file changed, 32 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> index 62352d1..a2cd7f8 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> @@ -1356,6 +1356,29 @@ static struct omap_hwmod dra7xx_mailbox13_hwmod = {
>> };
>>
>> /*
>> + * 'mcan' class
>> + *
>> + */
>> +static struct omap_hwmod_class dra76x_mcan_hwmod_class = {
>> +.name = "mcan",
>> +};
>
> Looks like you're missing the related struct omap_hwmod_class_sysconfig
> entry for this with the rev and sysconfig registers.
>
Sorry, I missed this email earlier. The MCAN module doesn't have
sysconfig registers.
Thanks,
Faiz
Re: [PATCH v3 4/6] ALSA: xen-front: Implement handling of shared buffers
On 05/15/2018 09:01 AM, Takashi Iwai wrote: On Tue, 15 May 2018 07:46:38 +0200, Oleksandr Andrushchenko wrote: On 05/14/2018 11:28 PM, Takashi Iwai wrote: On Mon, 14 May 2018 08:27:40 +0200, Oleksandr Andrushchenko wrote: --- /dev/null +++ b/sound/xen/xen_snd_front_shbuf.c @@ -0,0 +1,193 @@ +// SPDX-License-Identifier: GPL-2.0 OR MIT + +/* + * Xen para-virtual sound device + * + * Copyright (C) 2016-2018 EPAM Systems Inc. + * + * Author: Oleksandr Andrushchenko + */ + +#include +#include + +#include "xen_snd_front_shbuf.h" Hm, with the local build test, I get the following error: CC [M] sound/xen/xen_snd_front_shbuf.o In file included from sound/xen/xen_snd_front_shbuf.c:11:0: ./include/xen/xen.h:18:8: error: unknown type name ‘bool’ extern bool xen_pvh; ^~~~ In file included from ./include/xen/interface/xen.h:30:0, from ./include/xen/xen.h:29, from sound/xen/xen_snd_front_shbuf.c:11: ./arch/x86/include/asm/xen/interface.h:92:21: error: unknown type name ‘uint64_t’ DEFINE_GUEST_HANDLE(uint64_t); ^ Adding #include fixed the issue. Did you really test your patches with the latest Linus tree? My bad, it does build for ARM (which is my target), but also does need "#include " for x86 which I didn't build this time. Sorry about that. Do you want me to resend this single patch or you can make the change while applying? Yes, it's fine. Thank you thanks, Takashi
Re: [PATCH v3 4/6] ALSA: xen-front: Implement handling of shared buffers
On Tue, 15 May 2018 07:46:38 +0200, Oleksandr Andrushchenko wrote: > > On 05/14/2018 11:28 PM, Takashi Iwai wrote: > > On Mon, 14 May 2018 08:27:40 +0200, > > Oleksandr Andrushchenko wrote: > >> --- /dev/null > >> +++ b/sound/xen/xen_snd_front_shbuf.c > >> @@ -0,0 +1,193 @@ > >> +// SPDX-License-Identifier: GPL-2.0 OR MIT > >> + > >> +/* > >> + * Xen para-virtual sound device > >> + * > >> + * Copyright (C) 2016-2018 EPAM Systems Inc. > >> + * > >> + * Author: Oleksandr Andrushchenko > >> + */ > >> + > >> +#include > >> +#include > >> + > >> +#include "xen_snd_front_shbuf.h" > > Hm, with the local build test, I get the following error: > > > >CC [M] sound/xen/xen_snd_front_shbuf.o > >In file included from sound/xen/xen_snd_front_shbuf.c:11:0: > >./include/xen/xen.h:18:8: error: unknown type name ‘bool’ > > extern bool xen_pvh; > > ^~~~ > > In file included from ./include/xen/interface/xen.h:30:0, > > from ./include/xen/xen.h:29, > > from sound/xen/xen_snd_front_shbuf.c:11: > >./arch/x86/include/asm/xen/interface.h:92:21: error: unknown type name > > ‘uint64_t’ > > DEFINE_GUEST_HANDLE(uint64_t); > > ^ > > > > Adding #include fixed the issue. > > > > Did you really test your patches with the latest Linus tree? > My bad, it does build for ARM (which is my target), but also does > need "#include " for x86 which I didn't build this time. > Sorry about that. > > Do you want me to resend this single patch or you can make the change > while applying? Yes, it's fine. thanks, Takashi
[PATCH v3 2/8] PCI: Fix memory leak of devm_pci_alloc_host_bridge()
From: Jan Kiszka
devm_pci_release_host_bridge_dev() failed to release the resource list.
Fixes: 5c3f18cce083 ("PCI: Add devm_pci_alloc_host_bridge() interface")
Signed-off-by: Jan Kiszka
---
drivers/pci/probe.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ac91b6fd0bcd..eccf204c9160 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -526,12 +526,14 @@ static void devm_pci_release_host_bridge_dev(struct
device *dev)
if (bridge->release_fn)
bridge->release_fn(bridge);
+
+ pci_free_resource_list(&bridge->windows);
}
static void pci_release_host_bridge_dev(struct device *dev)
{
devm_pci_release_host_bridge_dev(dev);
- pci_free_host_bridge(to_pci_host_bridge(dev));
+ kfree(to_pci_host_bridge(dev));
}
struct pci_host_bridge *pci_alloc_host_bridge(size_t priv)
--
2.13.6
[PATCH v3 8/8] PCI: Enable PCI_DOMAINS along with generic PCI host controller
From: Jan Kiszka This controller is often instantiated by hypervisors, and they may add multiple of them or add them in addition to a physical host controller like the Jailhouse hypervisor is doing. Therefore allow for multiple domains so that we can handle them all. Signed-off-by: Jan Kiszka --- drivers/pci/host/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index 0d0177ce436c..3d25b35bb5ab 100644 --- a/drivers/pci/host/Kconfig +++ b/drivers/pci/host/Kconfig @@ -68,6 +68,7 @@ config PCI_HOST_GENERIC depends on (ARM || ARM64) && OF select PCI_HOST_COMMON select IRQ_DOMAIN + select PCI_DOMAINS help Say Y here if you want to support a simple generic PCI host controller, such as the one emulated by kvmtool. -- 2.13.6
[PATCH v3 5/8] PCI: Replace pr_*() with dev_*() in of_pci_get_host_bridge_resources()
From: Jan Kiszka
Now that we have a device reference, make use of it for printing.
Signed-off-by: Jan Kiszka
---
drivers/pci/of.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index ac97491ba377..4f21514cb4e4 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -282,15 +282,15 @@ int of_pci_get_host_bridge_resources(struct device *dev,
if (!bus_range)
return -ENOMEM;
- pr_info("host bridge %pOF ranges:\n", dev_node);
+ dev_info(dev, "host bridge %pOF ranges:\n", dev_node);
err = of_pci_parse_bus_range(dev_node, bus_range);
if (err) {
bus_range->start = busno;
bus_range->end = bus_max;
bus_range->flags = IORESOURCE_BUS;
- pr_info(" No bus range found for %pOF, using %pR\n",
- dev_node, bus_range);
+ dev_info(dev, " No bus range found for %pOF, using %pR\n",
+dev_node, bus_range);
} else {
if (bus_range->end > bus_range->start + bus_max)
bus_range->end = bus_range->start + bus_max;
@@ -302,7 +302,7 @@ int of_pci_get_host_bridge_resources(struct device *dev,
if (err)
goto parse_failed;
- pr_debug("Parsing ranges property...\n");
+ dev_dbg(dev, "Parsing ranges property...\n");
for_each_of_pci_range(&parser, &range) {
/* Read next ranges element */
if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
@@ -311,9 +311,9 @@ int of_pci_get_host_bridge_resources(struct device *dev,
snprintf(range_type, 4, "MEM");
else
snprintf(range_type, 4, "err");
- pr_info(" %s %#010llx..%#010llx -> %#010llx\n", range_type,
- range.cpu_addr, range.cpu_addr + range.size - 1,
- range.pci_addr);
+ dev_info(dev, " %s %#010llx..%#010llx -> %#010llx\n",
+range_type, range.cpu_addr,
+range.cpu_addr + range.size - 1, range.pci_addr);
/*
* If we failed translation or got a zero-sized region
@@ -336,14 +336,16 @@ int of_pci_get_host_bridge_resources(struct device *dev,
if (resource_type(res) == IORESOURCE_IO) {
if (!io_base) {
- pr_err("I/O range found for %pOF. Please
provide an io_base pointer to save CPU base address\n",
+ dev_err(dev,
+ "I/O range found for %pOF. Please
provide an io_base pointer to save CPU base address\n",
dev_node);
err = -EINVAL;
goto conversion_failed;
}
if (*io_base != (resource_size_t)OF_BAD_ADDR)
- pr_warn("More than one I/O resource converted
for %pOF. CPU base address for old range lost!\n",
- dev_node);
+ dev_warn(dev,
+"More than one I/O resource converted
for %pOF. CPU base address for old range lost!\n",
+dev_node);
*io_base = range.cpu_addr;
}
--
2.13.6
Re: [PATCH] mmc: sdhci-pxav3: don't disable clocks when we might get an interrupt
On 15/05/18 00:56, Thomas Hebb wrote:
> Currently, runtime_suspend() unconditionally disables the clock gates
> for the controller, which means that it's unable to receive interrupts
> generated by connected SDIO cards.
We currently get / put runtime pm with enable / disable of the SDIO IRQ
(refer sdhci_enable_sdio_irq()) so are you sure this is needed?
>
> Signed-off-by: Thomas Hebb
> ---
> drivers/mmc/host/sdhci-pxav3.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
> index a34434166ca7..59760f3cc1d7 100644
> --- a/drivers/mmc/host/sdhci-pxav3.c
> +++ b/drivers/mmc/host/sdhci-pxav3.c
> @@ -562,9 +562,11 @@ static int sdhci_pxav3_runtime_suspend(struct device
> *dev)
> if (host->tuning_mode != SDHCI_TUNING_MODE_3)
> mmc_retune_needed(host->mmc);
>
> - clk_disable_unprepare(pxa->clk_io);
> - if (!IS_ERR(pxa->clk_core))
> - clk_disable_unprepare(pxa->clk_core);
> + if (!sdhci_sdio_irq_enabled(host)) {
> + clk_disable_unprepare(pxa->clk_io);
> + if (!IS_ERR(pxa->clk_core))
> + clk_disable_unprepare(pxa->clk_core);
> + }
>
> return 0;
> }
> @@ -575,9 +577,11 @@ static int sdhci_pxav3_runtime_resume(struct device *dev)
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_pxa *pxa = sdhci_pltfm_priv(pltfm_host);
>
> - clk_prepare_enable(pxa->clk_io);
> - if (!IS_ERR(pxa->clk_core))
> - clk_prepare_enable(pxa->clk_core);
> + if (!sdhci_sdio_irq_enabled(host)) {
> + clk_prepare_enable(pxa->clk_io);
> + if (!IS_ERR(pxa->clk_core))
> + clk_prepare_enable(pxa->clk_core);
> + }
>
> return sdhci_runtime_resume_host(host);
> }
>
[PATCH v3 1/8] PCI: Make pci_get_new_domain_nr() static
From: Jan Kiszka
The only user of pci_get_new_domain_nr() is of_pci_bus_find_domain_nr().
Since they are defined in the same compilation unit,
pci_get_new_domain_nr() can be made static, which also simplifies
preprocessor conditionals.
No functional change intended.
Signed-off-by: Jan Kiszka
Acked-by: Lorenzo Pieralisi
---
drivers/pci/pci.c | 6 ++
include/linux/pci.h | 3 ---
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index dbfe7c4f3776..fe28cd76eacd 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5719,15 +5719,14 @@ static void pci_no_domains(void)
#endif
}
-#ifdef CONFIG_PCI_DOMAINS
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
static atomic_t __domain_nr = ATOMIC_INIT(-1);
-int pci_get_new_domain_nr(void)
+static int pci_get_new_domain_nr(void)
{
return atomic_inc_return(&__domain_nr);
}
-#ifdef CONFIG_PCI_DOMAINS_GENERIC
static int of_pci_bus_find_domain_nr(struct device *parent)
{
static int use_dt_domains = -1;
@@ -5782,7 +5781,6 @@ int pci_bus_find_domain_nr(struct pci_bus *bus, struct
device *parent)
acpi_pci_bus_find_domain_nr(bus);
}
#endif
-#endif
/**
* pci_ext_cfg_avail - can we access extended PCI config space?
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 73178a2fcee0..963232a6cd2e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1510,12 +1510,10 @@ void pci_cfg_access_unlock(struct pci_dev *dev);
*/
#ifdef CONFIG_PCI_DOMAINS
extern int pci_domains_supported;
-int pci_get_new_domain_nr(void);
#else
enum { pci_domains_supported = 0 };
static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
static inline int pci_proc_domain(struct pci_bus *bus) { return 0; }
-static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
#endif /* CONFIG_PCI_DOMAINS */
/*
@@ -1670,7 +1668,6 @@ static inline struct pci_dev
*pci_get_domain_bus_and_slot(int domain,
static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
static inline struct pci_dev *pci_dev_get(struct pci_dev *dev) { return NULL; }
-static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
#define dev_is_pci(d) (false)
#define dev_is_pf(d) (false)
--
2.13.6
[PATCH v3 0/8] PCI: leak fixes, removable generic PCI host, assorted stuff
Changes in v3: - refactor series to be both bisectable and simpler while reworking of_pci_get_host_bridge_resources() - include of_pci_get_host_bridge_resources() removal - include devm_of_pci_get_host_bridge_resources() error path fixes - effectively, no functional changes to v2 Changes in v2: - patch 1: commit message reworking as suggested by Lorenzo - patch 3-6: split-up as suggested by Bjorn - patch 8: new - patch 10: select PCI_DOMAINS from PCI_HOST_GENERIC, rather than allowing manual choice, as suggested by Lorenzo This primarily enables to unbind the generic PCI host controller without leaving lots of memory leaks behind. A previous proposal patch 5 was rejected because of those issues [1]. The fixes have been validated in the Jailhouse setup, where we add and remove a virtual PCI host controller on hypervisor activation/ deactivation, with the help of kmemleak. Besides that, there is tiny PCI API cleanup at the beginning and support for manually enabled PCI domains at the end that enables the Jailhouse scenario. Jan [1] http://lkml.iu.edu/hypermail/linux/kernel/1606.3/00072.html CC: Jingoo Han CC: Joao Pinto CC: Lorenzo Pieralisi CC: Will Deacon Jan Kiszka (8): PCI: Make pci_get_new_domain_nr() static PCI: Fix memory leak of devm_pci_alloc_host_bridge() PCI: Rename device node parameter of of_pci_get_host_bridge_resources() PCI: Replace dev_node parameter of of_pci_get_host_bridge_resources with device PCI: Replace pr_*() with dev_*() in of_pci_get_host_bridge_resources() PCI: Rework of_pci_get_host_bridge_resources() to devm_of_pci_get_host_bridge_resources() PCI: Add support for unbinding the generic PCI host controller PCI: Enable PCI_DOMAINS along with generic PCI host controller drivers/pci/dwc/pcie-designware-host.c | 2 +- drivers/pci/host/Kconfig | 1 + drivers/pci/host/pci-aardvark.c| 5 +-- drivers/pci/host/pci-ftpci100.c| 4 +- drivers/pci/host/pci-host-common.c | 13 ++ drivers/pci/host/pci-host-generic.c| 1 + drivers/pci/host/pci-v3-semi.c | 3 +- drivers/pci/host/pci-versatile.c | 3 +- drivers/pci/host/pci-xgene.c | 3 +- drivers/pci/host/pcie-altera.c | 5 +-- drivers/pci/host/pcie-iproc-platform.c | 4 +- drivers/pci/host/pcie-rcar.c | 5 +-- drivers/pci/host/pcie-rockchip.c | 4 +- drivers/pci/host/pcie-xilinx-nwl.c | 4 +- drivers/pci/host/pcie-xilinx.c | 4 +- drivers/pci/of.c | 72 +++--- drivers/pci/pci.c | 6 +-- drivers/pci/probe.c| 4 +- include/linux/of_pci.h | 4 +- include/linux/pci-ecam.h | 1 + include/linux/pci.h| 3 -- 21 files changed, 76 insertions(+), 75 deletions(-) -- 2.13.6
[PATCH v3 7/8] PCI: Add support for unbinding the generic PCI host controller
From: Jan Kiszka
Particularly useful when working in virtual environments where the
controller may come and go, but possibly not only there.
CC: Will Deacon
CC: Lorenzo Pieralisi
Signed-off-by: Jan Kiszka
---
drivers/pci/host/pci-host-common.c | 13 +
drivers/pci/host/pci-host-generic.c | 1 +
include/linux/pci-ecam.h| 1 +
3 files changed, 15 insertions(+)
diff --git a/drivers/pci/host/pci-host-common.c
b/drivers/pci/host/pci-host-common.c
index 5d028f53fdcd..d8f10451f273 100644
--- a/drivers/pci/host/pci-host-common.c
+++ b/drivers/pci/host/pci-host-common.c
@@ -101,5 +101,18 @@ int pci_host_common_probe(struct platform_device *pdev,
return ret;
}
+ platform_set_drvdata(pdev, bridge->bus);
+ return 0;
+}
+
+int pci_host_common_remove(struct platform_device *pdev)
+{
+ struct pci_bus *bus = platform_get_drvdata(pdev);
+
+ pci_lock_rescan_remove();
+ pci_stop_root_bus(bus);
+ pci_remove_root_bus(bus);
+ pci_unlock_rescan_remove();
+
return 0;
}
diff --git a/drivers/pci/host/pci-host-generic.c
b/drivers/pci/host/pci-host-generic.c
index 45319ee3b484..dea3ec7592a2 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -95,5 +95,6 @@ static struct platform_driver gen_pci_driver = {
.suppress_bind_attrs = true,
},
.probe = gen_pci_probe,
+ .remove = pci_host_common_remove,
};
builtin_platform_driver(gen_pci_driver);
diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
index baadad1aabbc..29efa09d686b 100644
--- a/include/linux/pci-ecam.h
+++ b/include/linux/pci-ecam.h
@@ -62,5 +62,6 @@ extern struct pci_ecam_ops xgene_v2_pcie_ecam_ops; /* APM
X-Gene PCIe v2.x */
/* for DT-based PCI controllers that support ECAM */
int pci_host_common_probe(struct platform_device *pdev,
struct pci_ecam_ops *ops);
+int pci_host_common_remove(struct platform_device *pdev);
#endif
#endif
--
2.13.6
[PATCH v3 6/8] PCI: Rework of_pci_get_host_bridge_resources() to devm_of_pci_get_host_bridge_resources()
From: Jan Kiszka of_pci_get_host_bridge_resources() allocates the resource structures it fills dynamically, but none of its callers care to release them so far. Rather than requiring everyone to do this explicitly, convert the existing function to a managed version. CC: Jingoo Han CC: Joao Pinto CC: Lorenzo Pieralisi Signed-off-by: Jan Kiszka --- drivers/pci/dwc/pcie-designware-host.c | 2 +- drivers/pci/host/pci-aardvark.c| 2 +- drivers/pci/host/pci-ftpci100.c| 2 +- drivers/pci/host/pci-v3-semi.c | 2 +- drivers/pci/host/pci-versatile.c | 2 +- drivers/pci/host/pci-xgene.c | 2 +- drivers/pci/host/pcie-altera.c | 2 +- drivers/pci/host/pcie-iproc-platform.c | 2 +- drivers/pci/host/pcie-rcar.c | 2 +- drivers/pci/host/pcie-rockchip.c | 2 +- drivers/pci/host/pcie-xilinx-nwl.c | 2 +- drivers/pci/host/pcie-xilinx.c | 2 +- drivers/pci/of.c | 37 +++--- include/linux/of_pci.h | 4 ++-- 14 files changed, 26 insertions(+), 39 deletions(-) diff --git a/drivers/pci/dwc/pcie-designware-host.c b/drivers/pci/dwc/pcie-designware-host.c index 5a535690b7b5..a8f6ab54b4c0 100644 --- a/drivers/pci/dwc/pcie-designware-host.c +++ b/drivers/pci/dwc/pcie-designware-host.c @@ -342,7 +342,7 @@ int dw_pcie_host_init(struct pcie_port *pp) if (!bridge) return -ENOMEM; - ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, + ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &bridge->windows, &pp->io_base); if (ret) return ret; diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c index 39d8fc2a8a76..1e048dd806dc 100644 --- a/drivers/pci/host/pci-aardvark.c +++ b/drivers/pci/host/pci-aardvark.c @@ -827,7 +827,7 @@ static int advk_pcie_parse_request_of_pci_ranges(struct advk_pcie *pcie) INIT_LIST_HEAD(&pcie->resources); - err = of_pci_get_host_bridge_resources(dev, 0, 0xff, + err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &pcie->resources, &iobase); if (err) return err; diff --git a/drivers/pci/host/pci-ftpci100.c b/drivers/pci/host/pci-ftpci100.c index 5c176f806fe5..87748eaeaaed 100644 --- a/drivers/pci/host/pci-ftpci100.c +++ b/drivers/pci/host/pci-ftpci100.c @@ -476,7 +476,7 @@ static int faraday_pci_probe(struct platform_device *pdev) if (IS_ERR(p->base)) return PTR_ERR(p->base); - ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, + ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &res, &io_base); if (ret) return ret; diff --git a/drivers/pci/host/pci-v3-semi.c b/drivers/pci/host/pci-v3-semi.c index f3f39935ac2f..167bf6f6b378 100644 --- a/drivers/pci/host/pci-v3-semi.c +++ b/drivers/pci/host/pci-v3-semi.c @@ -791,7 +791,7 @@ static int v3_pci_probe(struct platform_device *pdev) if (IS_ERR(v3->config_base)) return PTR_ERR(v3->config_base); - ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, &res, + ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &res, &io_base); if (ret) return ret; diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-versatile.c index ef33ec0a9e1b..ff2cd12b3978 100644 --- a/drivers/pci/host/pci-versatile.c +++ b/drivers/pci/host/pci-versatile.c @@ -67,7 +67,7 @@ static int versatile_pci_parse_request_of_pci_ranges(struct device *dev, resource_size_t iobase; struct resource_entry *win, *tmp; - err = of_pci_get_host_bridge_resources(dev, 0, 0xff, res, &iobase); + err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, res, &iobase); if (err) return err; diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c index 88e9a6d315b3..7b3ed6e34b6c 100644 --- a/drivers/pci/host/pci-xgene.c +++ b/drivers/pci/host/pci-xgene.c @@ -632,7 +632,7 @@ static int xgene_pcie_probe(struct platform_device *pdev) if (ret) return ret; - ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, &res, + ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &res, &iobase); if (ret) return ret; diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c index 61802e55a00c..49410c7ba0cc 100644 --- a/drivers/pci/host/pcie-altera.c +++ b/drivers/pci/host/pcie-altera.c @@ -490,7 +490,7 @@ static int altera_pcie_parse_request_of_pci_ranges(struct altera_pcie *pcie) struct device *dev = &pcie->pdev->dev; struct resource_entry *win; - err = of_pci_g
Re: [PATCH v5 13/13] mm: Clear shrinker bit if there are no objects related to memcg
On Thu, May 10, 2018 at 12:54:15PM +0300, Kirill Tkhai wrote:
> To avoid further unneed calls of do_shrink_slab()
> for shrinkers, which already do not have any charged
> objects in a memcg, their bits have to be cleared.
>
> This patch introduces a lockless mechanism to do that
> without races without parallel list lru add. After
> do_shrink_slab() returns SHRINK_EMPTY the first time,
> we clear the bit and call it once again. Then we restore
> the bit, if the new return value is different.
>
> Note, that single smp_mb__after_atomic() in shrink_slab_memcg()
> covers two situations:
>
> 1)list_lru_add() shrink_slab_memcg
> list_add_tail()for_each_set_bit() <--- read bit
> do_shrink_slab() <--- missed list update (no barrier)
>
> set_bit()do_shrink_slab() <--- seen list update
>
> This situation, when the first do_shrink_slab() sees set bit,
> but it doesn't see list update (i.e., race with the first element
> queueing), is rare. So we don't add before the first call
> of do_shrink_slab() instead of this to do not slow down generic
> case. Also, it's need the second call as seen in below in (2).
>
> 2)list_lru_add() shrink_slab_memcg()
> list_add_tail() ...
> set_bit() ...
> ... for_each_set_bit()
> do_shrink_slab()do_shrink_slab()
> clear_bit() ...
> ... ...
> list_lru_add() ...
> list_add_tail() clear_bit()
>
> set_bit() do_shrink_slab()
>
> The barriers guarantees, the second do_shrink_slab()
> in the right side task sees list update if really
> cleared the bit. This case is drawn in the code comment.
>
> [Results/performance of the patchset]
>
> After the whole patchset applied the below test shows signify
> increase of performance:
>
> $echo 1 > /sys/fs/cgroup/memory/memory.use_hierarchy
> $mkdir /sys/fs/cgroup/memory/ct
> $echo 4000M > /sys/fs/cgroup/memory/ct/memory.kmem.limit_in_bytes
> $for i in `seq 0 4000`; do mkdir /sys/fs/cgroup/memory/ct/$i; echo $$ >
> /sys/fs/cgroup/memory/ct/$i/cgroup.procs; mkdir -p s/$i; mount -t tmpfs $i
> s/$i; touch s/$i/file; done
>
> Then, 5 sequential calls of drop caches:
> $time echo 3 > /proc/sys/vm/drop_caches
>
> 1)Before:
> 0.00user 13.78system 0:13.78elapsed 99%CPU
> 0.00user 5.59system 0:05.60elapsed 99%CPU
> 0.00user 5.48system 0:05.48elapsed 99%CPU
> 0.00user 8.35system 0:08.35elapsed 99%CPU
> 0.00user 8.34system 0:08.35elapsed 99%CPU
>
> 2)After
> 0.00user 1.10system 0:01.10elapsed 99%CPU
> 0.00user 0.00system 0:00.01elapsed 64%CPU
> 0.00user 0.01system 0:00.01elapsed 82%CPU
> 0.00user 0.00system 0:00.01elapsed 64%CPU
> 0.00user 0.01system 0:00.01elapsed 82%CPU
>
> The results show the performance increases at least in 548 times.
>
> Signed-off-by: Kirill Tkhai
> ---
> include/linux/memcontrol.h |2 ++
> mm/vmscan.c| 19 +--
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 436691a66500..82c0bf2d0579 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -1283,6 +1283,8 @@ static inline void memcg_set_shrinker_bit(struct
> mem_cgroup *memcg, int nid, int
>
> rcu_read_lock();
> map = MEMCG_SHRINKER_MAP(memcg, nid);
> + /* Pairs with smp mb in shrink_slab() */
> + smp_mb__before_atomic();
> set_bit(nr, map->map);
> rcu_read_unlock();
> }
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 7b0075612d73..189b163bef4a 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -586,8 +586,23 @@ static unsigned long shrink_slab_memcg(gfp_t gfp_mask,
> int nid,
> continue;
>
> ret = do_shrink_slab(&sc, shrinker, priority);
> - if (ret == SHRINK_EMPTY)
> - ret = 0;
> + if (ret == SHRINK_EMPTY) {
> + clear_bit(i, map->map);
> + /*
> + * Pairs with mb in memcg_set_shrinker_bit():
> + *
> + * list_lru_add() shrink_slab_memcg()
> + * list_add_tail()clear_bit()
> + *
> + * set_bit() do_shrink_slab()
> + */
Please improve the comment so that it isn't just a diagram.
> + smp_mb__after_atomic();
> + ret = do_shrink_slab(&sc, shrinker, priority);
> + if (ret == SHRINK_EMPTY)
> + ret = 0;
> + else
> + memcg_set_shrinker_bit(memcg, nid, i);
> + }
> freed += ret;
>
> if (rwsem_is_contended(&shrinker_rwsem)) {
>
[PATCH v3 3/8] PCI: Rename device node parameter of of_pci_get_host_bridge_resources()
From: Jan Kiszka
We will add a real device parameter to this function soon.
Signed-off-by: Jan Kiszka
---
drivers/pci/of.c | 18 +-
include/linux/of_pci.h | 4 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index a28355c273ae..8d4778ef5806 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -245,7 +245,7 @@ EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
#if defined(CONFIG_OF_ADDRESS)
/**
* of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
- * @dev: device node of the host bridge having the range property
+ * @dev_node: device node of the host bridge having the range property
* @busno: bus number associated with the bridge root bus
* @bus_max: maximum number of buses for this bridge
* @resources: list where the range of resources will be added after DT parsing
@@ -262,7 +262,7 @@ EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
* It returns zero if the range parsing has been successful or a standard error
* value if it failed.
*/
-int of_pci_get_host_bridge_resources(struct device_node *dev,
+int of_pci_get_host_bridge_resources(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
{
@@ -281,15 +281,15 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev,
if (!bus_range)
return -ENOMEM;
- pr_info("host bridge %pOF ranges:\n", dev);
+ pr_info("host bridge %pOF ranges:\n", dev_node);
- err = of_pci_parse_bus_range(dev, bus_range);
+ err = of_pci_parse_bus_range(dev_node, bus_range);
if (err) {
bus_range->start = busno;
bus_range->end = bus_max;
bus_range->flags = IORESOURCE_BUS;
pr_info(" No bus range found for %pOF, using %pR\n",
- dev, bus_range);
+ dev_node, bus_range);
} else {
if (bus_range->end > bus_range->start + bus_max)
bus_range->end = bus_range->start + bus_max;
@@ -297,7 +297,7 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev,
pci_add_resource(resources, bus_range);
/* Check for ranges property */
- err = of_pci_range_parser_init(&parser, dev);
+ err = of_pci_range_parser_init(&parser, dev_node);
if (err)
goto parse_failed;
@@ -327,7 +327,7 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev,
goto parse_failed;
}
- err = of_pci_range_to_resource(&range, dev, res);
+ err = of_pci_range_to_resource(&range, dev_node, res);
if (err) {
kfree(res);
continue;
@@ -336,13 +336,13 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev,
if (resource_type(res) == IORESOURCE_IO) {
if (!io_base) {
pr_err("I/O range found for %pOF. Please
provide an io_base pointer to save CPU base address\n",
- dev);
+ dev_node);
err = -EINVAL;
goto conversion_failed;
}
if (*io_base != (resource_size_t)OF_BAD_ADDR)
pr_warn("More than one I/O resource converted
for %pOF. CPU base address for old range lost!\n",
- dev);
+ dev_node);
*io_base = range.cpu_addr;
}
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 091033a6b836..74eec1943ad2 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -71,11 +71,11 @@ of_irq_parse_and_map_pci(const struct pci_dev *dev, u8
slot, u8 pin)
#endif
#if defined(CONFIG_OF_ADDRESS)
-int of_pci_get_host_bridge_resources(struct device_node *dev,
+int of_pci_get_host_bridge_resources(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
#else
-static inline int of_pci_get_host_bridge_resources(struct device_node *dev,
+static inline int of_pci_get_host_bridge_resources(struct device_node
*dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
{
--
2.13.6
[PATCH v3 4/8] PCI: Replace dev_node parameter of of_pci_get_host_bridge_resources with device
From: Jan Kiszka
Another step towards a managed version of
of_pci_get_host_bridge_resources(): Feed in the underlying device,
rather than just the OF node. This will allow to use managed resource
allocation internally later on.
CC: Jingoo Han
CC: Joao Pinto
CC: Lorenzo Pieralisi
Signed-off-by: Jan Kiszka
---
drivers/pci/dwc/pcie-designware-host.c | 2 +-
drivers/pci/host/pci-aardvark.c| 5 ++---
drivers/pci/host/pci-ftpci100.c| 4 ++--
drivers/pci/host/pci-v3-semi.c | 3 ++-
drivers/pci/host/pci-versatile.c | 3 +--
drivers/pci/host/pci-xgene.c | 3 ++-
drivers/pci/host/pcie-altera.c | 5 ++---
drivers/pci/host/pcie-iproc-platform.c | 4 ++--
drivers/pci/host/pcie-rcar.c | 5 ++---
drivers/pci/host/pcie-rockchip.c | 4 ++--
drivers/pci/host/pcie-xilinx-nwl.c | 4 ++--
drivers/pci/host/pcie-xilinx.c | 4 ++--
drivers/pci/of.c | 9 +
include/linux/of_pci.h | 4 ++--
14 files changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/pci/dwc/pcie-designware-host.c
b/drivers/pci/dwc/pcie-designware-host.c
index 6c409079d514..5a535690b7b5 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -342,7 +342,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
if (!bridge)
return -ENOMEM;
- ret = of_pci_get_host_bridge_resources(np, 0, 0xff,
+ ret = of_pci_get_host_bridge_resources(dev, 0, 0xff,
&bridge->windows, &pp->io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c
index 9abf549631b4..39d8fc2a8a76 100644
--- a/drivers/pci/host/pci-aardvark.c
+++ b/drivers/pci/host/pci-aardvark.c
@@ -822,14 +822,13 @@ static int advk_pcie_parse_request_of_pci_ranges(struct
advk_pcie *pcie)
{
int err, res_valid = 0;
struct device *dev = &pcie->pdev->dev;
- struct device_node *np = dev->of_node;
struct resource_entry *win, *tmp;
resource_size_t iobase;
INIT_LIST_HEAD(&pcie->resources);
- err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pcie->resources,
- &iobase);
+ err = of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ &pcie->resources, &iobase);
if (err)
return err;
diff --git a/drivers/pci/host/pci-ftpci100.c b/drivers/pci/host/pci-ftpci100.c
index 5008fd87956a..5c176f806fe5 100644
--- a/drivers/pci/host/pci-ftpci100.c
+++ b/drivers/pci/host/pci-ftpci100.c
@@ -476,8 +476,8 @@ static int faraday_pci_probe(struct platform_device *pdev)
if (IS_ERR(p->base))
return PTR_ERR(p->base);
- ret = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff,
- &res, &io_base);
+ ret = of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ &res, &io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-v3-semi.c b/drivers/pci/host/pci-v3-semi.c
index 0a4dea796663..f3f39935ac2f 100644
--- a/drivers/pci/host/pci-v3-semi.c
+++ b/drivers/pci/host/pci-v3-semi.c
@@ -791,7 +791,8 @@ static int v3_pci_probe(struct platform_device *pdev)
if (IS_ERR(v3->config_base))
return PTR_ERR(v3->config_base);
- ret = of_pci_get_host_bridge_resources(np, 0, 0xff, &res, &io_base);
+ ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
+ &io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-versatile.c
index 5b3876f5312b..ef33ec0a9e1b 100644
--- a/drivers/pci/host/pci-versatile.c
+++ b/drivers/pci/host/pci-versatile.c
@@ -64,11 +64,10 @@ static int versatile_pci_parse_request_of_pci_ranges(struct
device *dev,
struct list_head *res)
{
int err, mem = 1, res_valid = 0;
- struct device_node *np = dev->of_node;
resource_size_t iobase;
struct resource_entry *win, *tmp;
- err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, &iobase);
+ err = of_pci_get_host_bridge_resources(dev, 0, 0xff, res, &iobase);
if (err)
return err;
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index 0a0d7ee6d3c9..88e9a6d315b3 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -632,7 +632,8 @@ static int xgene_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = of_pci_get_host_bridge_resources(dn, 0, 0xff, &res, &iobase);
+ ret = of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
+
[PATCH] cpufreq: add imx8mq-cpufreq driver
Add imx8mq-cpufreq driver for NXP i.MX8MQ SoC to support the
hardware specific frequency and voltage scaling requirements.
Signed-off-by: Anson Huang
---
drivers/cpufreq/Kconfig.arm | 8 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/imx8mq-cpufreq.c | 234 +++
3 files changed, 243 insertions(+)
create mode 100644 drivers/cpufreq/imx8mq-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 96b35b8..ea8e2b6 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -105,6 +105,14 @@ config ARM_IMX6Q_CPUFREQ
If in doubt, say N.
+config ARM_IMX8MQ_CPUFREQ
+ tristate "NXP i.MX8MQ cpufreq support"
+ select PM_OPP
+ help
+ This adds cpufreq driver support for NXP i.MX8MQ SoC.
+
+ If in doubt, say N.
+
config ARM_KIRKWOOD_CPUFREQ
def_bool MACH_KIRKWOOD
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade..a3bc61c 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_ARCH_DAVINCI)+= davinci-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
+obj-$(CONFIG_ARM_IMX8MQ_CPUFREQ) += imx8mq-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ) += mediatek-cpufreq.o
obj-$(CONFIG_MACH_MVEBU_V7)+= mvebu-cpufreq.o
diff --git a/drivers/cpufreq/imx8mq-cpufreq.c b/drivers/cpufreq/imx8mq-cpufreq.c
new file mode 100644
index 000..2aee6049
--- /dev/null
+++ b/drivers/cpufreq/imx8mq-cpufreq.c
@@ -0,0 +1,234 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 NXP
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct device *cpu_dev;
+static bool free_opp;
+static struct cpufreq_frequency_table *freq_table;
+static unsigned int transition_latency;
+static struct thermal_cooling_device *cdev;
+static struct regulator *arm_reg;
+static unsigned int max_freq;
+
+#define IMX8MQ_CPUFREQ_CLK_NUM 5
+
+enum IMX8MQ_CPUFREQ_CLKS {
+ A53,
+ A53_SRC,
+ ARM_PLL,
+ ARM_PLL_OUT,
+ SYS1_PLL_800M,
+};
+
+static struct clk_bulk_data clks[] = {
+ { .id = "a53" },
+ { .id = "a53_src" },
+ { .id = "arm_pll" },
+ { .id = "arm_pll_out" },
+ { .id = "sys1_pll_800m" },
+};
+
+static int imx8mq_set_target(struct cpufreq_policy *policy, unsigned int index)
+{
+ struct dev_pm_opp *opp;
+ unsigned long freq_hz, volt;
+ unsigned int old_freq, new_freq;
+ int ret;
+
+ new_freq = freq_table[index].frequency;
+ freq_hz = new_freq * 1000;
+ old_freq = policy->cur;
+
+ opp = dev_pm_opp_find_freq_ceil(cpu_dev, &freq_hz);
+ if (IS_ERR(opp)) {
+ dev_err(cpu_dev, "failed to find OPP for %ld\n", freq_hz);
+ return PTR_ERR(opp);
+ }
+ volt = dev_pm_opp_get_voltage(opp);
+ dev_pm_opp_put(opp);
+
+ dev_dbg(cpu_dev, "%u MHz --> %u MHz\n",
+ old_freq / 1000, new_freq / 1000);
+
+ if (new_freq > old_freq) {
+ ret = regulator_set_voltage_tol(arm_reg, volt, 0);
+ if (ret) {
+ dev_err(cpu_dev, "failed to scale arm_reg up: %d\n",
+ ret);
+ return ret;
+ }
+ }
+
+ clk_set_parent(clks[A53_SRC].clk, clks[SYS1_PLL_800M].clk);
+ clk_set_rate(clks[ARM_PLL].clk, new_freq * 1000);
+ clk_set_parent(clks[A53_SRC].clk, clks[ARM_PLL_OUT].clk);
+
+ /* Ensure the arm clock divider is what we expect */
+ ret = clk_set_rate(clks[A53].clk, new_freq * 1000);
+ if (ret)
+ dev_err(cpu_dev, "failed to set clock rate: %d\n", ret);
+
+ if (new_freq < old_freq) {
+ ret = regulator_set_voltage_tol(arm_reg, volt, 0);
+ if (ret) {
+ dev_err(cpu_dev, "failed to scale arm_reg down: %d\n",
+ ret);
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
+static void imx8mq_cpufreq_ready(struct cpufreq_policy *policy)
+{
+ cdev = of_cpufreq_cooling_register(policy);
+}
+
+static int imx8mq_cpufreq_init(struct cpufreq_policy *policy)
+{
+ int ret;
+
+ policy->clk = clks[A53].clk;
+ ret = cpufreq_generic_init(policy, freq_table, transition_latency);
+ policy->suspend_freq = max_freq;
+
+ return ret;
+}
+
+
linux-next: build failure after merge of the kbuild tree
Hi Masahiro,
After merging the kbuild tree, today's linux-next build (x86_64
modules_install) failed like this:
Usage: scripts/depmod.sh /sbin/depmod
Makefile:1314: recipe for target '_modinst_post' failed
Caused by commit
ea7ad9856a2c ("depmod.sh: remove symbol prefix support")
I added the following fix for today:
From: Stephen Rothwell
Date: Tue, 15 May 2018 15:47:33 +1000
Subject: [PATCH] depmod.sh: fix syntax check and uage message
fixes: ea7ad9856a2c ("depmod.sh: remove symbol prefix support")
Signed-off-by: Stephen Rothwell
---
scripts/depmod.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/depmod.sh b/scripts/depmod.sh
index 421d1aa01304..1a6f85e0e6e1 100755
--- a/scripts/depmod.sh
+++ b/scripts/depmod.sh
@@ -3,8 +3,8 @@
#
# A depmod wrapper used by the toplevel Makefile
-if test $# -ne 3; then
- echo "Usage: $0 /sbin/depmod " >&2
+if test $# -ne 2; then
+ echo "Usage: $0 /sbin/depmod " >&2
exit 1
fi
DEPMOD=$1
--
2.17.0
--
Cheers,
Stephen Rothwell
pgpcyekDFttro.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 4/6] ALSA: xen-front: Implement handling of shared buffers
On 05/14/2018 11:28 PM, Takashi Iwai wrote: On Mon, 14 May 2018 08:27:40 +0200, Oleksandr Andrushchenko wrote: --- /dev/null +++ b/sound/xen/xen_snd_front_shbuf.c @@ -0,0 +1,193 @@ +// SPDX-License-Identifier: GPL-2.0 OR MIT + +/* + * Xen para-virtual sound device + * + * Copyright (C) 2016-2018 EPAM Systems Inc. + * + * Author: Oleksandr Andrushchenko + */ + +#include +#include + +#include "xen_snd_front_shbuf.h" Hm, with the local build test, I get the following error: CC [M] sound/xen/xen_snd_front_shbuf.o In file included from sound/xen/xen_snd_front_shbuf.c:11:0: ./include/xen/xen.h:18:8: error: unknown type name ‘bool’ extern bool xen_pvh; ^~~~ In file included from ./include/xen/interface/xen.h:30:0, from ./include/xen/xen.h:29, from sound/xen/xen_snd_front_shbuf.c:11: ./arch/x86/include/asm/xen/interface.h:92:21: error: unknown type name ‘uint64_t’ DEFINE_GUEST_HANDLE(uint64_t); ^ Adding #include fixed the issue. Did you really test your patches with the latest Linus tree? My bad, it does build for ARM (which is my target), but also does need "#include " for x86 which I didn't build this time. Sorry about that. Do you want me to resend this single patch or you can make the change while applying? thanks, Takashi Thank you, Oleksandr
Re: [PATCH v5 11/13] mm: Iterate only over charged shrinkers during memcg shrink_slab()
On Thu, May 10, 2018 at 12:53:55PM +0300, Kirill Tkhai wrote:
> Using the preparations made in previous patches, in case of memcg
> shrink, we may avoid shrinkers, which are not set in memcg's shrinkers
> bitmap. To do that, we separate iterations over memcg-aware and
> !memcg-aware shrinkers, and memcg-aware shrinkers are chosen
> via for_each_set_bit() from the bitmap. In case of big nodes,
> having many isolated environments, this gives significant
> performance growth. See next patches for the details.
>
> Note, that the patch does not respect to empty memcg shrinkers,
> since we never clear the bitmap bits after we set it once.
> Their shrinkers will be called again, with no shrinked objects
> as result. This functionality is provided by next patches.
>
> Signed-off-by: Kirill Tkhai
> ---
> include/linux/memcontrol.h |1 +
> mm/vmscan.c| 70
> ++--
> 2 files changed, 62 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 82f892e77637..436691a66500 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -760,6 +760,7 @@ void mem_cgroup_split_huge_fixup(struct page *head);
> #define MEM_CGROUP_ID_MAX0
>
> struct mem_cgroup;
> +#define root_mem_cgroup NULL
Let's instead export mem_cgroup_is_root(). In case if MEMCG is disabled
it will always return false.
>
> static inline bool mem_cgroup_disabled(void)
> {
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index d8a2870710e0..a2e38e05adb5 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -376,6 +376,7 @@ int prealloc_shrinker(struct shrinker *shrinker)
> goto free_deferred;
> }
>
> + INIT_LIST_HEAD(&shrinker->list);
IMO this shouldn't be here, see my comment below.
> return 0;
>
> free_deferred:
> @@ -547,6 +548,63 @@ static unsigned long do_shrink_slab(struct
> shrink_control *shrinkctl,
> return freed;
> }
>
> +#ifdef CONFIG_MEMCG_SHRINKER
> +static unsigned long shrink_slab_memcg(gfp_t gfp_mask, int nid,
> + struct mem_cgroup *memcg, int priority)
> +{
> + struct memcg_shrinker_map *map;
> + unsigned long freed = 0;
> + int ret, i;
> +
> + if (!memcg_kmem_enabled() || !mem_cgroup_online(memcg))
> + return 0;
> +
> + if (!down_read_trylock(&shrinker_rwsem))
> + return 0;
> +
> + /*
> + * 1)Caller passes only alive memcg, so map can't be NULL.
> + * 2)shrinker_rwsem protects from maps expanding.
^^
Nit: space missing here :-)
> + */
> + map = rcu_dereference_protected(MEMCG_SHRINKER_MAP(memcg, nid), true);
> + BUG_ON(!map);
> +
> + for_each_set_bit(i, map->map, memcg_shrinker_nr_max) {
> + struct shrink_control sc = {
> + .gfp_mask = gfp_mask,
> + .nid = nid,
> + .memcg = memcg,
> + };
> + struct shrinker *shrinker;
> +
> + shrinker = idr_find(&shrinker_idr, i);
> + if (!shrinker) {
> + clear_bit(i, map->map);
> + continue;
> + }
The shrinker must be memcg aware so please add
BUG_ON((shrinker->flags & SHRINKER_MEMCG_AWARE) == 0);
> + if (list_empty(&shrinker->list))
> + continue;
I don't like using shrinker->list as an indicator that the shrinker has
been initialized. IMO if you do need such a check, you should split
shrinker_idr registration in two steps - allocate a slot in 'prealloc'
and set the pointer in 'register'. However, can we really encounter an
unregistered shrinker here? AFAIU a bit can be set in the shrinker map
only after the corresponding shrinker has been initialized, no?
> +
> + ret = do_shrink_slab(&sc, shrinker, priority);
> + freed += ret;
> +
> + if (rwsem_is_contended(&shrinker_rwsem)) {
> + freed = freed ? : 1;
> + break;
> + }
> + }
> +
> + up_read(&shrinker_rwsem);
> + return freed;
> +}
> +#else /* CONFIG_MEMCG_SHRINKER */
> +static unsigned long shrink_slab_memcg(gfp_t gfp_mask, int nid,
> + struct mem_cgroup *memcg, int priority)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_MEMCG_SHRINKER */
> +
> /**
> * shrink_slab - shrink slab caches
> * @gfp_mask: allocation context
> @@ -576,8 +634,8 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
> struct shrinker *shrinker;
> unsigned long freed = 0;
>
> - if (memcg && (!memcg_kmem_enabled() || !mem_cgroup_online(memcg)))
> - return 0;
> + if (memcg && memcg != root_mem_cgroup)
if (!mem_cgroup_is_root(memcg))
> + return shrink_slab_memcg(gfp_mask, nid, memcg, priority);
>
> if (!down_read_trylock(&shrinker_rwsem))
> goto out;
> @@ -589,13 +647,7 @@ s
Re: [RFC PATCH v2 2/2] locking/percpu-rwsem: Mark rwsem as non-spinnable in percpu_rwsem_release()
On Mon, May 14, 2018 at 10:31 PM, Waiman Long wrote:
> The percpu_rwsem_release() is called when the ownership of the embedded
> rwsem is to be transferred to another task. The new owner, however, may
> take a while to get the ownership of the lock via percpu_rwsem_acquire().
> During that period, the rwsem is now marked as writer-owned with no
> optimistic spinning.
>
Waiman,
Thanks for the fix. I will test it soon.
For this commit message I suggest that you add parts of the reproducer
found here:
https://marc.info/?l=linux-fsdevel&m=152622016219975&w=2
Thanks,
Amir.
> Signed-off-by: Waiman Long
> ---
> include/linux/percpu-rwsem.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/percpu-rwsem.h b/include/linux/percpu-rwsem.h
> index b1f37a8..dd37102 100644
> --- a/include/linux/percpu-rwsem.h
> +++ b/include/linux/percpu-rwsem.h
> @@ -131,16 +131,16 @@ static inline void percpu_rwsem_release(struct
> percpu_rw_semaphore *sem,
> bool read, unsigned long ip)
> {
> lock_release(&sem->rw_sem.dep_map, 1, ip);
> -#ifdef CONFIG_RWSEM_SPIN_ON_OWNER
> if (!read)
> - sem->rw_sem.owner = NULL;
> -#endif
> + rwsem_set_writer_owned_nospin(&sem->rw_sem);
> }
>
> static inline void percpu_rwsem_acquire(struct percpu_rw_semaphore *sem,
> bool read, unsigned long ip)
> {
> lock_acquire(&sem->rw_sem.dep_map, 0, 1, read, 1, NULL, ip);
> + if (!read)
> + rwsem_set_writer_owned(&sem->rw_sem, current);
> }
>
> #endif
> --
> 1.8.3.1
>
[tip:x86/build] x86/build/vdso: Put generated linker scripts to $(obj)/
Commit-ID: 1742ed2088ccc4ade3abd8fe888742dd0f1343f8 Gitweb: https://git.kernel.org/tip/1742ed2088ccc4ade3abd8fe888742dd0f1343f8 Author: Masahiro Yamada AuthorDate: Tue, 15 May 2018 11:52:24 +0900 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 07:32:42 +0200 x86/build/vdso: Put generated linker scripts to $(obj)/ Let's put generated files to $(obj)/ rather than $(src)/ although this is just a matter of taste because both are the same. Signed-off-by: Masahiro Yamada Cc: Andy Lutomirski Cc: Jeff Dike Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Richard Weinberger Cc: Thomas Gleixner Cc: user-mode-linux-de...@lists.sourceforge.net Cc: user-mode-linux-u...@lists.sourceforge.net Link: http://lkml.kernel.org/r/1526352744-28229-4-git-send-email-yamada.masah...@socionext.com Signed-off-by: Ingo Molnar --- arch/x86/entry/vdso/Makefile | 4 ++-- arch/x86/um/vdso/Makefile| 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile index 690df4c6b40a..261802b1cc50 100644 --- a/arch/x86/entry/vdso/Makefile +++ b/arch/x86/entry/vdso/Makefile @@ -51,7 +51,7 @@ VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \ -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 \ $(DISABLE_LTO) -$(obj)/vdso64.so.dbg: $(src)/vdso.lds $(vobjs) FORCE +$(obj)/vdso64.so.dbg: $(obj)/vdso.lds $(vobjs) FORCE $(call if_changed,vdso) HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi -I$(srctree)/arch/$(SUBARCH)/include/uapi @@ -119,7 +119,7 @@ $(obj)/%.so: OBJCOPYFLAGS := -S $(obj)/%.so: $(obj)/%.so.dbg $(call if_changed,objcopy) -$(obj)/vdsox32.so.dbg: $(src)/vdsox32.lds $(vobjx32s) FORCE +$(obj)/vdsox32.so.dbg: $(obj)/vdsox32.lds $(vobjx32s) FORCE $(call if_changed,vdso) CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds) diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile index e51d95c9098c..b2d6967262b2 100644 --- a/arch/x86/um/vdso/Makefile +++ b/arch/x86/um/vdso/Makefile @@ -30,7 +30,7 @@ VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \ $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso.so -$(obj)/vdso.so.dbg: $(src)/vdso.lds $(vobjs) FORCE +$(obj)/vdso.so.dbg: $(obj)/vdso.lds $(vobjs) FORCE $(call if_changed,vdso) $(obj)/%.so: OBJCOPYFLAGS := -S
[tip:x86/build] x86/build/vdso: Remove unnecessary export in Makefile
Commit-ID: 61615faf0a8968b604bd279fec5cb834ba59ed58 Gitweb: https://git.kernel.org/tip/61615faf0a8968b604bd279fec5cb834ba59ed58 Author: Masahiro Yamada AuthorDate: Tue, 15 May 2018 11:52:23 +0900 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 07:32:42 +0200 x86/build/vdso: Remove unnecessary export in Makefile CPPFLAGS_vdso.lds is assigned and referenced internally in each Makefile. No need to export it. Signed-off-by: Masahiro Yamada Cc: Andy Lutomirski Cc: Jeff Dike Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Richard Weinberger Cc: Thomas Gleixner Cc: user-mode-linux-de...@lists.sourceforge.net Cc: user-mode-linux-u...@lists.sourceforge.net Link: http://lkml.kernel.org/r/1526352744-28229-3-git-send-email-yamada.masah...@socionext.com Signed-off-by: Ingo Molnar --- arch/x86/entry/vdso/Makefile | 2 +- arch/x86/um/vdso/Makefile| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile index 298850683ee2..690df4c6b40a 100644 --- a/arch/x86/entry/vdso/Makefile +++ b/arch/x86/entry/vdso/Makefile @@ -44,7 +44,7 @@ obj-y += $(vdso_img_objs) targets += $(vdso_img_cfiles) targets += $(vdso_img_sodbg) $(vdso_img-y:%=vdso%.so) -export CPPFLAGS_vdso.lds += -P -C +CPPFLAGS_vdso.lds += -P -C VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \ -Wl,--no-undefined \ diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile index 10003359e633..e51d95c9098c 100644 --- a/arch/x86/um/vdso/Makefile +++ b/arch/x86/um/vdso/Makefile @@ -23,7 +23,7 @@ $(obj)/vdso.o: $(obj)/vdso.so targets += vdso.so vdso.so.dbg vdso.lds $(vobjs-y) -export CPPFLAGS_vdso.lds += -P -C +CPPFLAGS_vdso.lds += -P -C VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \ -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
[tip:x86/build] x86/build/vdso: Remove unused $(vobjs-nox32) in Makefile
Commit-ID: b3656612118f8961182f988168c835f023f0408a
Gitweb: https://git.kernel.org/tip/b3656612118f8961182f988168c835f023f0408a
Author: Masahiro Yamada
AuthorDate: Tue, 15 May 2018 11:52:22 +0900
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 07:32:42 +0200
x86/build/vdso: Remove unused $(vobjs-nox32) in Makefile
Since commit bfad381c0d1e ("x86/vdso: Improve the fake section
headers"), $(vobjs-nox32) is empty. Therefore, $(vobjs64-for-x32)
is the same as $(vobjs-y).
Signed-off-by: Masahiro Yamada
Cc: Andy Lutomirski
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1526352744-28229-2-git-send-email-yamada.masah...@socionext.com
Signed-off-by: Ingo Molnar
---
arch/x86/entry/vdso/Makefile | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index d998a487c9b1..298850683ee2 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -100,11 +100,8 @@ VDSO_LDFLAGS_vdsox32.lds = -Wl,-m,elf32_x86_64 \
-Wl,-z,max-page-size=4096 \
-Wl,-z,common-page-size=4096
-# 64-bit objects to re-brand as x32
-vobjs64-for-x32 := $(filter-out $(vobjs-nox32),$(vobjs-y))
-
# x32-rebranded versions
-vobjx32s-y := $(vobjs64-for-x32:.o=-x32.o)
+vobjx32s-y := $(vobjs-y:.o=-x32.o)
# same thing, but in the output directory
vobjx32s := $(foreach F,$(vobjx32s-y),$(obj)/$F)
Re: [PATCH 4.9 00/36] 4.9.100-stable review
On 14 May 2018 at 12:18, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.100 release. > There are 36 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 Wed May 16 06:47:47 UTC 2018. > 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/v4.x/stable-review/patch-4.9.100-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-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.9.100-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: 126d655643a828cd86fd7d8e154aa397bd08b31b git describe: v4.9.99-37-g126d655643a8 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.99-37-g126d655643a8 No regressions (compared to build v4.9.99-16-gb8ef70c6c0c7) Boards, architectures and test suites: - dragonboard-410c * boot - pass: 20 * kselftest - skip: 32, pass: 34 * libhugetlbfs - skip: 1, pass: 90 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 17, pass: 64 * ltp-fcntl-locktests-tests - pass: 2 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 6, pass: 57 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-hugetlb-tests - skip: 1, pass: 21 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-math-tests - pass: 11 * ltp-nptl-tests - pass: 2 * ltp-pty-tests - pass: 4 * ltp-sched-tests - pass: 14 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - skip: 135, pass: 1015 * ltp-timers-tests - pass: 13 hi6220-hikey - arm64 * boot - pass: 20 * kselftest - skip: 29, pass: 37 * libhugetlbfs - skip: 1, pass: 90 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 17, pass: 64 * ltp-fcntl-locktests-tests - pass: 2 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 6, pass: 57 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-hugetlb-tests - skip: 1, pass: 21 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-math-tests - pass: 11 * ltp-nptl-tests - pass: 2 * ltp-pty-tests - pass: 4 * ltp-sched-tests - skip: 4, pass: 10 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - skip: 136, pass: 1014 * ltp-timers-tests - pass: 13 juno-r2 - arm64 * boot - pass: 20 * kselftest - skip: 29, pass: 37 * libhugetlbfs - skip: 1, pass: 90 * ltp-containers-tests - skip: 17, pass: 64 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 6, pass: 57 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-math-tests - pass: 11 * ltp-pty-tests - pass: 4 * ltp-sched-tests - skip: 4, pass: 10 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - skip: 135, pass: 1015 * ltp-timers-tests - pass: 13 qemu_arm64 * boot - fail: 1, pass: 20 * kselftest - skip: 33, pass: 35 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 17, pass: 64 * ltp-fcntl-locktests-tests - pass: 2 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 6, pass: 57 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-hugetlb-tests - pass: 22 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-math-tests - pass: 11 * ltp-nptl-tests - pass: 2 * ltp-pty-tests - pass: 4 * ltp-sched-tests - skip: 6, pass: 8 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - fail: 2, skip: 157, pass: 991 * ltp-timers-tests - pass: 13 qemu_x86_64 * boot - pass: 20 * kselftest - skip: 33, pass: 47 * libhugetlbfs - skip: 1, pass: 90 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 17, pass: 64 * ltp-fcntl-locktests-tests - pass: 2 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 6, pass: 57 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-hugetlb-tests - pass: 22 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-math-tests - pass: 11 * ltp-nptl-tests - pass: 2 * ltp-pty-tests - pass: 4 * ltp-sched-tests - skip: 1, pass: 13 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - skip: 152, pass: 998 * ltp-timers-tests - pass: 13 x15 - arm * boot - pass: 20 * kselftest - skip: 29, pass: 36 * libhugetlbfs - skip: 1, pass: 87 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 18, pass: 63 * ltp-fcntl-locktests-tests - pass: 2 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 5, pass: 58 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_si
Re: [PATCH v4 0/4] ALSA: usb: UAC3 new features.
On Fri, 11 May 2018 17:25:33 +0200, Jorge Sanjuan wrote: > > v4 Updates: > - Removes already applied patch from v2 of this patchset. > - Adds small patch to parse Feature Unit number of channels. > - Rebased onto latest linux-next tag as today. > > Now that the UAC3 patch [1] has made it to linux-next I have some extra > features to make a UAC3 devices fully work in Linux. Including Jack > insertion control that I have put on top of this other patch [2] for > UAC2. Also adding support for the UAC3 Mixer Unit which is most likely > to appear in most headset type devices. > > UAC3 devices also require to have a Basic Audio Device (BADD) in a separate > config for which both Ruslan Bilovol and myself have submited different > approaches[3][4]. After an ongoing discussion between Ruslan and myself > we have decided that the patch from Ruslan[3] implements a simpler and > yet more robust BADD driver. > > All this features are tested with an actual UAC3 device that is still in > development. For this patch series, only the legacy config (#1. UAC1/UAC2) > and the UAC3 config have been tested. The BADD config will come in > a different patch from Ruslan. > > [1]: https://patchwork.kernel.org/patch/10298179/ > [2]: https://patchwork.kernel.org/patch/10305847/ > [3]: https://patchwork.kernel.org/patch/10340851/ > [4]: https://www.spinics.net/lists/alsa-devel/msg71617.html > > Based on linux-next tag: next-20180510 > > Jorge Sanjuan (4): > ALSA: usb-audio: UAC3. Add support for mixer unit. > ALSA: usb-audio: Use Class Specific EP for UAC3 devices. > ALSA: usb-audio: UAC3 Add support for connector insertion. > ALSA: usb-audio: UAC3: Parse Input Terminal number of channels. OK, now I applied all four patches. The patch 2 was queued to for-linus branch while others to for-next. The patch 4 was taken from the revised v4. Thanks! Takashi
Re: [PATCH 4.14 00/62] 4.14.41-stable review
On 14 May 2018 at 12:18, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.41 release. > There are 62 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 Wed May 16 06:47:52 UTC 2018. > 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/v4.x/stable-review/patch-4.14.41-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-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.14.41-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 13b3d94ce25df5cc037e4d28af3ef61933281cc5 git describe: v4.14.40-63-g13b3d94ce25d Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.40-63-g13b3d94ce25d No regressions (compared to build v4.14.40-22-g70a593c357b7) Boards, architectures and test suites: - dragonboard-410c * boot - pass: 20, * kselftest - pass: 41, skip: 27 * libhugetlbfs - pass: 90, skip: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 64, skip: 17 * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 57, skip: 6 * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1 * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 14, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1016, skip: 134 * ltp-timers-tests - pass: 13, hi6220-hikey - arm64 * boot - pass: 20, * kselftest - pass: 44, skip: 23 * libhugetlbfs - pass: 90, skip: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 64, skip: 17 * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 57, skip: 6 * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1 * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4 * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1015, skip: 135 * ltp-timers-tests - pass: 13, juno-r2 - arm64 * boot - pass: 27, * kselftest - pass: 43, skip: 25 * libhugetlbfs - pass: 90, skip: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 64, skip: 17 * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 57, skip: 6 * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 22, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 12, * ltp-sched-tests - pass: 10, skip: 4 * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 2032, skip: 268 * ltp-timers-tests - pass: 13, qemu_arm64 * boot - pass: 21, fail: 1, * kselftest - pass: 41, skip: 29 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 64, skip: 17 * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 57, skip: 6 * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 22, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 8, skip: 6 * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 992, fail: 2, skip: 156 * ltp-timers-tests - pass: 13, qemu_x86_64 * boot - pass: 20, * kselftest - pass: 50, skip: 30 * libhugetlbfs - pass: 90, skip: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 64, skip: 17 * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 57, skip: 6 * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 22, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 13, skip: 1 * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 998, skip: 152 * ltp-timers-tests - pass: 13, x15 - arm * boot - pass: 20, * kselftest - pass: 37, fail: 2, skip: 26 * libhugetlbfs - pass: 87, skip: 1 * ltp-cap_bounds-tests - pass: 2, * l
Re: [PATCH v1 4/4] samples/bpf: an example of a raw IR decoder
On Mon, May 14, 2018 at 2:11 PM, Sean Young wrote:
> This implements the grundig-16 IR protocol.
>
> Signed-off-by: Sean Young
> ---
> samples/bpf/Makefile | 4 +
> samples/bpf/bpf_load.c| 9 +-
> samples/bpf/grundig_decoder_kern.c| 112 ++
> samples/bpf/grundig_decoder_user.c| 54 +++
> tools/bpf/bpftool/prog.c | 1 +
> tools/include/uapi/linux/bpf.h| 17 +++-
> tools/testing/selftests/bpf/bpf_helpers.h | 6 ++
> 7 files changed, 200 insertions(+), 3 deletions(-)
> create mode 100644 samples/bpf/grundig_decoder_kern.c
> create mode 100644 samples/bpf/grundig_decoder_user.c
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 4d6a6edd4bf6..c6fa111f103a 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -44,6 +44,7 @@ hostprogs-y += xdp_monitor
> hostprogs-y += xdp_rxq_info
> hostprogs-y += syscall_tp
> hostprogs-y += cpustat
> +hostprogs-y += grundig_decoder
>
> # Libbpf dependencies
> LIBBPF := ../../tools/lib/bpf/bpf.o ../../tools/lib/bpf/nlattr.o
> @@ -95,6 +96,7 @@ xdp_monitor-objs := bpf_load.o $(LIBBPF) xdp_monitor_user.o
> xdp_rxq_info-objs := bpf_load.o $(LIBBPF) xdp_rxq_info_user.o
> syscall_tp-objs := bpf_load.o $(LIBBPF) syscall_tp_user.o
> cpustat-objs := bpf_load.o $(LIBBPF) cpustat_user.o
> +grundig_decoder-objs := bpf_load.o $(LIBBPF) grundig_decoder_user.o
>
> # Tell kbuild to always build the programs
> always := $(hostprogs-y)
> @@ -148,6 +150,7 @@ always += xdp_rxq_info_kern.o
> always += xdp2skb_meta_kern.o
> always += syscall_tp_kern.o
> always += cpustat_kern.o
> +always += grundig_decoder_kern.o
>
> HOSTCFLAGS += -I$(objtree)/usr/include
> HOSTCFLAGS += -I$(srctree)/tools/lib/
> @@ -193,6 +196,7 @@ HOSTLOADLIBES_xdp_monitor += -lelf
> HOSTLOADLIBES_xdp_rxq_info += -lelf
> HOSTLOADLIBES_syscall_tp += -lelf
> HOSTLOADLIBES_cpustat += -lelf
> +HOSTLOADLIBES_grundig_decoder += -lelf
>
> # Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on
> cmdline:
> # make samples/bpf/ LLC=~/git/llvm/build/bin/llc
> CLANG=~/git/llvm/build/bin/clang
> diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
> index bebe4188b4b3..0fd389e95bb9 100644
> --- a/samples/bpf/bpf_load.c
> +++ b/samples/bpf/bpf_load.c
> @@ -69,6 +69,7 @@ static int load_and_attach(const char *event, struct
> bpf_insn *prog, int size)
> bool is_sockops = strncmp(event, "sockops", 7) == 0;
> bool is_sk_skb = strncmp(event, "sk_skb", 6) == 0;
> bool is_sk_msg = strncmp(event, "sk_msg", 6) == 0;
> + bool is_ir_decoder = strncmp(event, "ir_decoder", 10) == 0;
> size_t insns_cnt = size / sizeof(struct bpf_insn);
> enum bpf_prog_type prog_type;
> char buf[256];
> @@ -102,6 +103,8 @@ static int load_and_attach(const char *event, struct
> bpf_insn *prog, int size)
> prog_type = BPF_PROG_TYPE_SK_SKB;
> } else if (is_sk_msg) {
> prog_type = BPF_PROG_TYPE_SK_MSG;
> + } else if (is_ir_decoder) {
> + prog_type = BPF_PROG_TYPE_RAWIR_DECODER;
> } else {
> printf("Unknown event '%s'\n", event);
> return -1;
> @@ -116,7 +119,8 @@ static int load_and_attach(const char *event, struct
> bpf_insn *prog, int size)
>
> prog_fd[prog_cnt++] = fd;
>
> - if (is_xdp || is_perf_event || is_cgroup_skb || is_cgroup_sk)
> + if (is_xdp || is_perf_event || is_cgroup_skb || is_cgroup_sk ||
> + is_ir_decoder)
> return 0;
>
> if (is_socket || is_sockops || is_sk_skb || is_sk_msg) {
> @@ -607,7 +611,8 @@ static int do_load_bpf_file(const char *path,
> fixup_map_cb fixup_map)
> memcmp(shname, "cgroup/", 7) == 0 ||
> memcmp(shname, "sockops", 7) == 0 ||
> memcmp(shname, "sk_skb", 6) == 0 ||
> - memcmp(shname, "sk_msg", 6) == 0) {
> + memcmp(shname, "sk_msg", 6) == 0 ||
> + memcmp(shname, "ir_decoder", 10) == 0) {
> ret = load_and_attach(shname, data->d_buf,
> data->d_size);
> if (ret != 0)
> diff --git a/samples/bpf/grundig_decoder_kern.c
> b/samples/bpf/grundig_decoder_kern.c
> new file mode 100644
> index ..c80f2c9cc69a
> --- /dev/null
> +++ b/samples/bpf/grundig_decoder_kern.c
> @@ -0,0 +1,112 @@
> +
> +#include
> +#include
> +#include "bpf_helpers.h"
> +#include
> +
> +enum grundig_state {
> + STATE_INACTIVE,
> + STATE_HEADER_SPACE,
> + STATE_LEADING_PULSE,
> + STATE_BITS_SPACE,
> + STATE_BITS_PULSE,
> +};
> +
> +struct decoder_state {
> + u32 bits;
> + enum grundig_state state;
> + u32 count;
> + u32 last_space;
> +};
> +
> +struct bpf_map_def SEC("maps") decoder_state_map
[tip:core/urgent] objtool: Detect RIP-relative switch table references
Commit-ID: 6f5ec2993b1f39aed12fa6fd56e8dc2272ee8a33
Gitweb: https://git.kernel.org/tip/6f5ec2993b1f39aed12fa6fd56e8dc2272ee8a33
Author: Josh Poimboeuf
AuthorDate: Mon, 14 May 2018 08:53:24 -0500
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 07:30:59 +0200
objtool: Detect RIP-relative switch table references
Typically a switch table can be found by detecting a .rodata access
followed an indirect jump:
1969: 4a 8b 0c e5 00 00 00mov0x0(,%r12,8),%rcx
1970: 00
196d: R_X86_64_32S .rodata+0x438
1971: e9 00 00 00 00 jmpq 1976
1972: R_X86_64_PC32 __x86_indirect_thunk_rcx-0x4
Randy Dunlap reported a case (seen with GCC 4.8) where the .rodata
access uses RIP-relative addressing:
19bd: 48 8b 3d 00 00 00 00mov0x0(%rip),%rdi# 19c4
19c0: R_X86_64_PC32 .rodata+0x45c
19c4: e9 00 00 00 00 jmpq 19c9
19c5: R_X86_64_PC32 __x86_indirect_thunk_rdi-0x4
In this case the relocation addend needs to be adjusted accordingly in
order to find the location of the switch table.
The fix is for case 3 (as described in the comments), but also make the
existing case 1 & 2 checks more precise by only adjusting the addend for
R_X86_64_PC32 relocations.
This fixes the following warnings:
drivers/video/fbdev/omap2/omapfb/dss/dispc.o: warning: objtool:
dispc_runtime_suspend()+0xbb8: sibling call from callable instruction with
modified stack frame
drivers/video/fbdev/omap2/omapfb/dss/dispc.o: warning: objtool:
dispc_runtime_resume()+0xcc5: sibling call from callable instruction with
modified stack frame
Reported-by: Randy Dunlap
Signed-off-by: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/b6098294fd67afb69af8c47c9883d7a68bf0f8ea.1526305958.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar
---
tools/objtool/check.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 9bb04fddd3c8..f4bbce838433 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -903,24 +903,24 @@ static struct rela *find_switch_table(struct objtool_file
*file,
{
struct rela *text_rela, *rodata_rela;
struct instruction *orig_insn = insn;
+ unsigned long table_offset;
+ /* case 1 & 2 */
text_rela = find_rela_by_dest_range(insn->sec, insn->offset, insn->len);
if (text_rela && text_rela->sym == file->rodata->sym &&
!find_symbol_containing(file->rodata, text_rela->addend)) {
- /* case 1 */
- rodata_rela = find_rela_by_dest(file->rodata,
- text_rela->addend);
- if (rodata_rela)
- return rodata_rela;
+ table_offset = text_rela->addend;
+ if (text_rela->type == R_X86_64_PC32) {
+ /* case 2 */
+ table_offset += 4;
+ file->ignore_unreachables = true;
+ }
- /* case 2 */
- rodata_rela = find_rela_by_dest(file->rodata,
- text_rela->addend + 4);
+ rodata_rela = find_rela_by_dest(file->rodata, table_offset);
if (!rodata_rela)
return NULL;
- file->ignore_unreachables = true;
return rodata_rela;
}
@@ -954,18 +954,21 @@ static struct rela *find_switch_table(struct objtool_file
*file,
if (!text_rela || text_rela->sym != file->rodata->sym)
continue;
+ table_offset = text_rela->addend;
+ if (text_rela->type == R_X86_64_PC32)
+ table_offset += 4;
+
/*
* Make sure the .rodata address isn't associated with a
* symbol. gcc jump tables are anonymous data.
*/
- if (find_symbol_containing(file->rodata, text_rela->addend))
- continue;
-
- rodata_rela = find_rela_by_dest(file->rodata,
text_rela->addend);
- if (!rodata_rela)
+ if (find_symbol_containing(file->rodata, table_offset))
continue;
- return rodata_rela;
+ /* mov [rodata addr], %reg */
+ rodata_rela = find_rela_by_dest(file->rodata, table_offset);
+ if (rodata_rela)
+ return rodata_rela;
}
return NULL;
Re: [PATCH] x86: add the flag -fno-reorder-blocks-and-partition
* Mikulas Patocka wrote: > GCC 8 turns on -freorder-blocks-and-partition by default, the ORC unwinder > can't deal with it and it results in a lot of warnings "sibling call from > callable instruction with modified stack frame". This patch adds the > -fno-reorder-blocks-and-partition option to KBUILD_CFLAGS. > > Signed-off-by: Mikulas Patocka > Cc: sta...@vger.kernel.org > > --- > arch/x86/Makefile |1 + > 1 file changed, 1 insertion(+) > > Index: linux-2.6/arch/x86/Makefile > === > --- linux-2.6.orig/arch/x86/Makefile 2018-05-15 07:19:40.0 +0200 > +++ linux-2.6/arch/x86/Makefile 2018-05-15 07:19:40.0 +0200 > @@ -59,6 +59,7 @@ endif > # > KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow > KBUILD_CFLAGS += $(call cc-option,-mno-avx,) > +KBUILD_CFLAGS += $(call cc-option,-fno-reorder-blocks-and-partition,) Could you check whether the latest objtool fixes in -tip: git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git master solves those warnings? Thanks, Ingo
Re: CONFIG_KCOV causing crash in svm_vcpu_run()
On Mon, May 14, 2018 at 7:25 PM, Eric Biggers wrote:
> On Mon, May 14, 2018 at 07:14:41AM +0200, Dmitry Vyukov wrote:
>> On Mon, May 14, 2018 at 5:02 AM, Eric Biggers wrote:
>> > Sorry, messed up address for KVM mailing list. See message below.
>> >
>> > On Sun, May 13, 2018 at 08:00:07PM -0700, Eric Biggers wrote:
>> >> With CONFIG_KCOV=y and an AMD processor, running the following program
>> >> crashes
>> >> the kernel with no output (I'm testing in a VM, so it's using nested
>> >> virtualization):
>> >>
>> >> #include
>> >> #include
>> >> #include
>> >>
>> >> int main()
>> >> {
>> >> int dev, vm, cpu;
>> >> char page[4096] __attribute__((aligned(4096))) = { 0 };
>> >> struct kvm_userspace_memory_region memreg = {
>> >> .memory_size = 4096,
>> >> .userspace_addr = (unsigned long)page,
>> >> };
>> >> dev = open("/dev/kvm", O_RDONLY);
>> >> vm = ioctl(dev, KVM_CREATE_VM, 0);
>> >> cpu = ioctl(vm, KVM_CREATE_VCPU, 0);
>> >> ioctl(vm, KVM_SET_USER_MEMORY_REGION, &memreg);
>> >> ioctl(cpu, KVM_RUN, 0);
>> >> }
>> >>
>> >> It bisects down to commit b2ac58f90540e39 ("KVM/SVM: Allow direct access
>> >> to
>> >> MSR_IA32_SPEC_CTRL"). The bug is apparently that due to the new code for
>> >> managing the SPEC_CTRL MSR, __sanitizer_cov_trace_pc() is being called
>> >> from
>> >> svm_vcpu_run() before the host's MSR_GS_BASE has been restored, which
>> >> causes a
>> >> crash somehow. The following patch fixes it, though I don't know that
>> >> it's the
>> >> right solution; maybe KCOV should be disabled in the function instead, or
>> >> maybe
>> >> there's a more fundamental problem. What do people think?
>>
>>
>> If __sanitizer_cov_trace_pc() crashes, I would expect there must be
>> few more of them here:
>>
>> if (unlikely(!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)))
>> svm->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL);
>>
>> if (svm->spec_ctrl)
>> native_wrmsrl(MSR_IA32_SPEC_CTRL, 0);
>>
>> Compiler inserts these callbacks into every basic block/edge.. Aren't there?
>>
>> Unfortunately we don't have an attribute that disables instrumentation
>> of a single function. This is currently possible only on file level.
>>
>
> Yes, due to the code dealing with MSR_IA32_SPEC_CTRL, there were several calls
> to __sanitizer_cov_trace_pc() before the write to MSR_GS_BASE. The patch I
> tested moves the write to MSR_GS_BASE to before all of them, so it's once
> again
> the first thing after the asm block. Again I'm not sure it's the proper
> solution, but it did make it stop crashing.
>From KCOV perspective:
This is definitely the simplest and less intrusive solution.
It's somewhat unreliable. But it's hard to tell if/when it will
actually break in practice. Compiler can decide to insert the callback
after asm block, or a branch can be added to wrmsrl (e.g. under some
debug config). More reliable solution would be to restore registers in
asm block itself, or move this to a separate file and disable
instrumentation of that file (though, will not save from non-inlined
wrmsrl). But again, the proposed solution may work well for the next
10 years, so additional complexity may not worth it.
Btw, I don't see anything about fs/gs in vmx_vcpu_run. Is it VMLAUNCH
that saves/restores them?
Re: [PATCH 1/2] ARM64: dts: meson-gxbb: odroidc2: enable sdcard UHS modes
Hi Jerome On 14 May 2018 at 19:18, Jerome Brunet wrote: > On Wed, 2018-05-02 at 00:29 +0530, Anand Moon wrote: >> Enable UHS modes for sdcard, on odroidc2. >> >> Signed-off-by: Anand Moon >> --- >> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts >> b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts >> index 54954b314a45..c90f8b46c60c 100644 >> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts >> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts >> @@ -258,6 +258,11 @@ >> cap-sd-highspeed; >> max-frequency = <1>; >> disable-wp; >> + sd-uhs-sdr12; >> + sd-uhs-sdr25; >> + sd-uhs-sdr50; >> + sd-uhs-sdr104; >> + sd-uhs-ddr50; >> >> cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>; >> cd-inverted; > > Hi Anand, > > I tried a few sdcards on the OC2 with your 2 patches. > Like with the libretech-cc, sdr104@200Mhz works "mostly", but, with some > sdcards, it does not - please see below. The same sdcards appear to be working > fine on my laptop. > > This is something I have not been able to crack yet on the libretech-cc. > > I'd suggest dropping sdr104 and keeping the max frequency at 100Mhz until we > can > figure out the problem here. > > With this changed: > > Tested-by: Jerome Brunet > > dd if=/dev/mmcblk1 of=/dev/zero bs=4M > [ 446.925817] mmc1: tuning execution failed: -5 > [ 446.956597] mmc1: tuning execution failed: -5 > [ 489.957810] print_req_error: I/O error, dev mmcblk1, sector 6654424 > [ 490.141975] print_req_error: I/O error, dev mmcblk1, sector 6656440 > [ 490.148304] print_req_error: I/O error, dev mmcblk1, sector 6656944 > [ 490.349650] print_req_error: I/O error, dev mmcblk1, sector 6658456 > [ 491.804382] print_req_error: I/O error, dev mmcblk1, sector 6747688 > [ 492.281246] print_req_error: I/O error, dev mmcblk1, sector 6784992 > [ 492.419034] print_req_error: I/O error, dev mmcblk1, sector 6785496 > [ 492.865878] print_req_error: I/O error, dev mmcblk1, sector 6791800 > [ 493.023809] print_req_error: I/O error, dev mmcblk1, sector 6792192 > [ 493.024435] Buffer I/O error on dev mmcblk1, logical block 849024, async > page > read > [ 493.217751] print_req_error: I/O error, dev mmcblk1, sector 6792808 > [ 494.891779] mmc1: tuning execution failed: -5 > [ 495.374186] print_req_error: 3 callbacks suppressed > [ 495.374193] print_req_error: I/O error, dev mmcblk1, sector 6854576 > [ 495.767498] print_req_error: I/O error, dev mmcblk1, sector 686 > [ 496.013104] print_req_error: I/O error, dev mmcblk1, sector 6863024 > [ 496.223042] print_req_error: I/O error, dev mmcblk1, sector 6864032 > [ 496.227003] print_req_error: I/O error, dev mmcblk1, sector 6864536 > [ 496.375175] print_req_error: I/O error, dev mmcblk1, sector 6864176 > [ 496.375806] Buffer I/O error on dev mmcblk1, logical block 858022, async > page > read > [ 496.521229] print_req_error: I/O error, dev mmcblk1, sector 6864184 > [ 496.521852] Buffer I/O error on dev mmcblk1, logical block 858023, async > page > read > [ 503.596978] print_req_error: I/O error, dev mmcblk1, sector 6983312 > [ 503.597606] Buffer I/O error on dev mmcblk1, logical block 872914, async > page > read > [ 505.280621] print_req_error: I/O error, dev mmcblk1, sector 7004536 > [ 505.281249] Buffer I/O error on dev mmcblk1, logical block 875567, async > page > read > [ 507.372560] print_req_error: I/O error, dev mmcblk1, sector 7048696 > [ 507.373192] Buffer I/O error on dev mmcblk1, logical block 881087, async > page > read > [ 511.355248] print_req_error: I/O error, dev mmcblk1, sector 7131352 > [ 511.355883] Buffer I/O error on dev mmcblk1, logical block 891419, async > page > read > [ 511.369076] print_req_error: I/O error, dev mmcblk1, sector 7131352 > [ 511.369694] Buffer I/O error on dev mmcblk1, logical block 891419, async > page > read > dd: error reading '/dev/mmcblk1': Input/output error > 868+7 records in > 868+7 records out > 3651252224 bytes (3.7 GB, 3.4 GiB) copied, 66.7736 s, 54.7 MB/s Thank for your testing, I will also do some more testing on all the sdcard and share you the result.. Mean while Sandisk Ultra microSDHC UHS-I card @A1 32GB shows. On my Odroid C2: [1.165784] meson-gx-mmc d0074000.mmc: allocated mmc-pwrseq [1.403756] meson-gx-mmc d0072000.mmc: Got CD GPIO [1.456160] Waiting for root device /dev/mmcblk1p2... [1.608180] mmc1: new ultra high speed SDR104 SDHC card at address [1.610002] mmcblk1: mmc1: JULIE 29.7 GiB [1.617811] mmcblk1: p1 p2 Also I did not encounter and read/write failure on the sdcard but I will re-test them. root@odroid64:~# dd if=/dev/mmcblk1 of=/dev/zero bs=4M 7609+1 records in 7609+1 records out 31914983424 bytes (32 GB, 30 GiB) copied, 368.637 s, 86.6 MB/s root@odroid64:~# Best Regards -Anand
Re: [PATCH 4.16 00/72] 4.16.9-stable review
On 14 May 2018 at 12:18, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.9 release. > There are 72 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 Wed May 16 06:47:58 UTC 2018. > 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/v4.x/stable-review/patch-4.16.9-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-4.16.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.16.9-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.16.y git commit: 618cea778f02d997c2e7bc0bf800617cf66f571d git describe: v4.16.8-72-g618cea778f02 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.16-oe/build/v4.16.8-72-g618cea778f02 No regressions (compared to build v4.16.8-73-gdaccae8696e8) Boards, architectures and test suites: - dragonboard-410c - arm64 * boot - fail: 3, pass: 19 * kselftest - fail: 1, skip: 26, pass: 41 * libhugetlbfs - fail: 1, skip: 1, pass: 89 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 17, pass: 64 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 6, pass: 57 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-hugetlb-tests - skip: 1, pass: 21 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-math-tests - pass: 11 * ltp-nptl-tests - pass: 2 * ltp-pty-tests - pass: 4 * ltp-sched-tests - pass: 14 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - skip: 133, pass: 1017 * ltp-timers-tests - pass: 13 hi6220-hikey - arm64 * boot - pass: 20 * kselftest - skip: 23, pass: 45 * libhugetlbfs - skip: 1, pass: 90 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 17, pass: 64 * ltp-fcntl-locktests-tests - pass: 2 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 6, pass: 57 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-hugetlb-tests - skip: 1, pass: 21 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-math-tests - pass: 11 * ltp-nptl-tests - pass: 2 * ltp-pty-tests - pass: 4 * ltp-sched-tests - skip: 4, pass: 10 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - skip: 134, pass: 1016 * ltp-timers-tests - pass: 13 juno-r2 - arm64 * boot - pass: 20 * kselftest - skip: 24, pass: 44 * libhugetlbfs - skip: 1, pass: 90 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 17, pass: 64 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 6, pass: 57 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-hugetlb-tests - pass: 22 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-math-tests - pass: 11 * ltp-nptl-tests - pass: 2 * ltp-sched-tests - skip: 4, pass: 10 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - skip: 133, pass: 1017 qemu_arm64 * boot - fail: 3, pass: 20 * kselftest - skip: 29, pass: 41 * libhugetlbfs - skip: 1, pass: 90 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 17, pass: 64 * ltp-fcntl-locktests-tests - pass: 2 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 6, pass: 57 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-hugetlb-tests - pass: 22 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-nptl-tests - pass: 2 * ltp-pty-tests - pass: 4 * ltp-sched-tests - skip: 6, pass: 8 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - fail: 2, skip: 155, pass: 993 * ltp-timers-tests - pass: 13 qemu_x86_64 * boot - pass: 19 * kselftest - skip: 30, pass: 50 * libhugetlbfs - skip: 1, pass: 90 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 17, pass: 64 * ltp-fcntl-locktests-tests - pass: 2 * ltp-filecaps-tests - pass: 2 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perms_simple-tests - pass: 19 * ltp-fsx-tests - pass: 2 * ltp-hugetlb-tests - pass: 22 * ltp-io-tests - pass: 3 * ltp-ipc-tests - pass: 9 * ltp-math-tests - pass: 11 * ltp-nptl-tests - pass: 2 * ltp-pty-tests - pass: 4 * ltp-sched-tests - skip: 1, pass: 13 * ltp-securebits-tests - pass: 4 * ltp-syscalls-tests - skip: 152, pass: 998 * ltp-timers-tests - pass: 13 x15 - arm * boot - pass: 21 * kselftest - skip: 28, pass: 37 * libhugetlbfs - skip: 1, pass: 87 * ltp-cap_bounds-tests - pass: 2 * ltp-containers-tests - skip: 18, pass: 63 * ltp-fcntl-locktests-tests - pass: 2 * ltp-filecaps-tests - pass: 2 * ltp-fs-tests - skip: 5, pass: 58 * ltp-fs_bind-tests - pass: 2 * ltp-fs_perm
Re: [PATCH v1 3/4] media: rc bpf: move ir_raw_event to uapi
On Mon, May 14, 2018 at 2:11 PM, Sean Young wrote:
> The context provided to a BPF_PROG_RAWIR_DECODER is a struct ir_raw_event;
> ensure user space has a a definition.
>
> Signed-off-by: Sean Young
> ---
> include/media/rc-core.h| 19 +--
> include/uapi/linux/bpf_rcdev.h | 24
Patch #2 already referenced this file. So if Patches #1 and #2
applied, there will be
a compilation error. Could you re-arrange your patchset so that after
sequentially
applying each patch, there is no compilation error?
> 2 files changed, 25 insertions(+), 18 deletions(-)
> create mode 100644 include/uapi/linux/bpf_rcdev.h
>
> diff --git a/include/media/rc-core.h b/include/media/rc-core.h
> index 6742fd86ff65..5d31e31d8ade 100644
> --- a/include/media/rc-core.h
> +++ b/include/media/rc-core.h
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> /**
> @@ -299,24 +300,6 @@ void rc_keydown_notimeout(struct rc_dev *dev, enum
> rc_proto protocol,
> void rc_keyup(struct rc_dev *dev);
> u32 rc_g_keycode_from_table(struct rc_dev *dev, u32 scancode);
>
> -/*
> - * From rc-raw.c
> - * The Raw interface is specific to InfraRed. It may be a good idea to
> - * split it later into a separate header.
> - */
> -struct ir_raw_event {
> - union {
> - u32 duration;
> - u32 carrier;
> - };
> - u8 duty_cycle;
> -
> - unsignedpulse:1;
> - unsignedreset:1;
> - unsignedtimeout:1;
> - unsignedcarrier_report:1;
> -};
> -
> #define DEFINE_IR_RAW_EVENT(event) struct ir_raw_event event = {}
>
> static inline void init_ir_raw_event(struct ir_raw_event *ev)
> diff --git a/include/uapi/linux/bpf_rcdev.h b/include/uapi/linux/bpf_rcdev.h
> new file mode 100644
> index ..d8629ff2b960
> --- /dev/null
> +++ b/include/uapi/linux/bpf_rcdev.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/* Copyright (c) 2018 Sean Young
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of version 2 of the GNU General Public
> + * License as published by the Free Software Foundation.
> + */
> +#ifndef _UAPI__LINUX_BPF_RCDEV_H__
> +#define _UAPI__LINUX_BPF_RCDEV_H__
> +
> +struct ir_raw_event {
> + union {
> + __u32 duration;
> + __u32 carrier;
> + };
> + __u8duty_cycle;
> +
> + unsignedpulse:1;
> + unsignedreset:1;
> + unsignedtimeout:1;
> + unsignedcarrier_report:1;
> +};
> +
> +#endif /* _UAPI__LINUX_BPF_RCDEV_H__ */
> --
> 2.17.0
>
Re: [PATCH v1 2/4] media: bpf: allow raw IR decoder bpf programs to be used
On Mon, May 14, 2018 at 2:10 PM, Sean Young wrote:
> This implements attaching, detaching, querying and execution. The target
> fd has to be the /dev/lircN device.
>
> Signed-off-by: Sean Young
> ---
> drivers/media/rc/ir-bpf-decoder.c | 191 ++
> drivers/media/rc/lirc_dev.c | 30 +
> drivers/media/rc/rc-core-priv.h | 15 +++
> drivers/media/rc/rc-ir-raw.c | 5 +
> include/uapi/linux/bpf.h | 1 +
> kernel/bpf/syscall.c | 7 ++
> 6 files changed, 249 insertions(+)
>
> diff --git a/drivers/media/rc/ir-bpf-decoder.c
> b/drivers/media/rc/ir-bpf-decoder.c
> index aaa5e208b1a5..651590a14772 100644
> --- a/drivers/media/rc/ir-bpf-decoder.c
> +++ b/drivers/media/rc/ir-bpf-decoder.c
> @@ -91,3 +91,194 @@ const struct bpf_verifier_ops ir_decoder_verifier_ops = {
> .get_func_proto = ir_decoder_func_proto,
> .is_valid_access = ir_decoder_is_valid_access
> };
> +
> +#define BPF_MAX_PROGS 64
> +
> +int rc_dev_bpf_attach(struct rc_dev *rcdev, struct bpf_prog *prog, u32 flags)
flags is not used in this function.
> +{
> + struct ir_raw_event_ctrl *raw;
> + struct bpf_prog_array __rcu *old_array;
> + struct bpf_prog_array *new_array;
> + int ret;
> +
> + if (rcdev->driver_type != RC_DRIVER_IR_RAW)
> + return -EINVAL;
> +
> + ret = mutex_lock_interruptible(&rcdev->lock);
> + if (ret)
> + return ret;
> +
> + raw = rcdev->raw;
> +
> + if (raw->progs && bpf_prog_array_length(raw->progs) >= BPF_MAX_PROGS)
> {
> + ret = -E2BIG;
> + goto out;
> + }
> +
> + old_array = raw->progs;
> + ret = bpf_prog_array_copy(old_array, NULL, prog, &new_array);
> + if (ret < 0)
> + goto out;
> +
> + rcu_assign_pointer(raw->progs, new_array);
> + bpf_prog_array_free(old_array);
> +out:
> + mutex_unlock(&rcdev->lock);
> + return ret;
> +}
> +
> +int rc_dev_bpf_detach(struct rc_dev *rcdev, struct bpf_prog *prog, u32 flags)
flags is not used in this function.
> +{
> + struct ir_raw_event_ctrl *raw;
> + struct bpf_prog_array __rcu *old_array;
> + struct bpf_prog_array *new_array;
> + int ret;
> +
> + if (rcdev->driver_type != RC_DRIVER_IR_RAW)
> + return -EINVAL;
> +
> + ret = mutex_lock_interruptible(&rcdev->lock);
> + if (ret)
> + return ret;
> +
> + raw = rcdev->raw;
> +
> + old_array = raw->progs;
> + ret = bpf_prog_array_copy(old_array, prog, NULL, &new_array);
> + if (ret < 0) {
> + bpf_prog_array_delete_safe(old_array, prog);
> + } else {
> + rcu_assign_pointer(raw->progs, new_array);
> + bpf_prog_array_free(old_array);
> + }
> +
> + bpf_prog_put(prog);
> + mutex_unlock(&rcdev->lock);
> + return 0;
> +}
> +
> +void rc_dev_bpf_run(struct rc_dev *rcdev)
> +{
> + struct ir_raw_event_ctrl *raw = rcdev->raw;
> +
> + if (raw->progs)
> + BPF_PROG_RUN_ARRAY(raw->progs, &raw->prev_ev, BPF_PROG_RUN);
> +}
> +
> +void rc_dev_bpf_put(struct rc_dev *rcdev)
> +{
> + struct bpf_prog_array *progs = rcdev->raw->progs;
> + int i, size;
> +
> + if (!progs)
> + return;
> +
> + size = bpf_prog_array_length(progs);
> + for (i = 0; i < size; i++)
> + bpf_prog_put(progs->progs[i]);
> +
> + bpf_prog_array_free(rcdev->raw->progs);
> +}
> +
> +int rc_dev_prog_attach(const union bpf_attr *attr)
> +{
> + struct bpf_prog *prog;
> + struct rc_dev *rcdev;
> + int ret;
> +
> + if (attr->attach_flags & BPF_F_ALLOW_OVERRIDE)
> + return -EINVAL;
Looks like you really did not use flags except here.
BPF_F_ALLOW_OVERRIDE is originally used for
cgroup type of attachment and the comment explicits
saying so.
In the query below, the flags value "0" is copied to userspace.
In your case, I think you can just disallow any value, i.g.,
attr->attach_flags must be 0, and then you further down
check that if the prog is already in the array, you just return an error.
> +
> + prog = bpf_prog_get_type(attr->attach_bpf_fd,
> +BPF_PROG_TYPE_RAWIR_DECODER);
> + if (IS_ERR(prog))
> + return PTR_ERR(prog);
> +
> + rcdev = rc_dev_get_from_fd(attr->target_fd);
> + if (IS_ERR(rcdev)) {
> + bpf_prog_put(prog);
> + return PTR_ERR(rcdev);
> + }
> +
> + ret = rc_dev_bpf_attach(rcdev, prog, attr->attach_flags);
> + if (ret)
> + bpf_prog_put(prog);
> +
> + put_device(&rcdev->dev);
> +
> + return ret;
> +}
> +
> +int rc_dev_prog_detach(const union bpf_attr *attr)
> +{
> + struct bpf_prog *prog;
> + struct rc_dev *rcdev;
> + int ret;
> +
> + if (attr->attach_flags & BPF_F_ALLOW_OVERRIDE)
>
[PATCH] x86: add the flag -fno-reorder-blocks-and-partition
GCC 8 turns on -freorder-blocks-and-partition by default, the ORC unwinder can't deal with it and it results in a lot of warnings "sibling call from callable instruction with modified stack frame". This patch adds the -fno-reorder-blocks-and-partition option to KBUILD_CFLAGS. Signed-off-by: Mikulas Patocka Cc: sta...@vger.kernel.org --- arch/x86/Makefile |1 + 1 file changed, 1 insertion(+) Index: linux-2.6/arch/x86/Makefile === --- linux-2.6.orig/arch/x86/Makefile2018-05-15 07:19:40.0 +0200 +++ linux-2.6/arch/x86/Makefile 2018-05-15 07:19:40.0 +0200 @@ -59,6 +59,7 @@ endif # KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow KBUILD_CFLAGS += $(call cc-option,-mno-avx,) +KBUILD_CFLAGS += $(call cc-option,-fno-reorder-blocks-and-partition,) ifeq ($(CONFIG_X86_32),y) BITS := 32
