[PATCH v2 1/3] /dev/dax, pmem: direct access to persistent memory
Device DAX is the device-centric analogue of Filesystem DAX (CONFIG_FS_DAX). It allows memory ranges to be allocated and mapped without need of an intervening file system. Device DAX is strict, precise and predictable. Specifically this interface: 1/ Guarantees fault granularity with respect to a given page size (pte, pmd, or pud) set at configuration time. 2/ Enforces deterministic behavior by being strict about what fault scenarios are supported. For example, by forcing MADV_DONTFORK semantics and omitting MAP_PRIVATE support device-dax guarantees that a mapping always behaves/performs the same once established. It is the "what you see is what you get" access mechanism to differentiated memory vs filesystem DAX which has filesystem specific implementation semantics. Persistent memory is the first target, but the mechanism is also targeted for exclusive allocations of performance differentiated memory ranges. This commit is limited to the base device driver infrastructure to associate a dax device with pmem range. Cc: Jeff Moyer Cc: Christoph Hellwig Cc: Andrew Morton Cc: Dave Hansen Cc: Ross Zwisler Signed-off-by: Dan Williams --- drivers/Kconfig |2 drivers/Makefile|1 drivers/dax/Kconfig | 25 +++ drivers/dax/Makefile|4 + drivers/dax/dax.c | 252 +++ drivers/dax/dax.h | 24 +++ drivers/dax/pmem.c | 168 +++ tools/testing/nvdimm/Kbuild |9 + tools/testing/nvdimm/config_check.c |2 9 files changed, 487 insertions(+) create mode 100644 drivers/dax/Kconfig create mode 100644 drivers/dax/Makefile create mode 100644 drivers/dax/dax.c create mode 100644 drivers/dax/dax.h create mode 100644 drivers/dax/pmem.c diff --git a/drivers/Kconfig b/drivers/Kconfig index d2ac339de85f..8298eab84a6f 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -190,6 +190,8 @@ source "drivers/android/Kconfig" source "drivers/nvdimm/Kconfig" +source "drivers/dax/Kconfig" + source "drivers/nvmem/Kconfig" source "drivers/hwtracing/stm/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile index 8f5d076baeb0..0b6f3d60193d 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -66,6 +66,7 @@ obj-$(CONFIG_PARPORT) += parport/ obj-$(CONFIG_NVM) += lightnvm/ obj-y += base/ block/ misc/ mfd/ nfc/ obj-$(CONFIG_LIBNVDIMM)+= nvdimm/ +obj-$(CONFIG_DEV_DAX) += dax/ obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/ obj-$(CONFIG_NUBUS)+= nubus/ obj-y += macintosh/ diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig new file mode 100644 index ..86ffbaa891ad --- /dev/null +++ b/drivers/dax/Kconfig @@ -0,0 +1,25 @@ +menuconfig DEV_DAX + tristate "DAX: direct access to differentiated memory" + default m if NVDIMM_DAX + help + Support raw access to differentiated (persistence, bandwidth, + latency...) memory via an mmap(2) capable character + device. Platform firmware or a device driver may identify a + platform memory resource that is differentiated from the + baseline memory pool. Mappings of a /dev/daxX.Y device impose + restrictions that make the mapping behavior deterministic. + +if DEV_DAX + +config DEV_DAX_PMEM + tristate "PMEM DAX: direct access to persistent memory" + depends on NVDIMM_DAX + default DEV_DAX + help + Support raw access to persistent memory. Note that this + driver consumes memory ranges allocated and exported by the + libnvdimm sub-system. + + Say Y if unsure + +endif diff --git a/drivers/dax/Makefile b/drivers/dax/Makefile new file mode 100644 index ..27c54e38478a --- /dev/null +++ b/drivers/dax/Makefile @@ -0,0 +1,4 @@ +obj-$(CONFIG_DEV_DAX) += dax.o +obj-$(CONFIG_DEV_DAX_PMEM) += dax_pmem.o + +dax_pmem-y := pmem.o diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c new file mode 100644 index ..8207fb33a992 --- /dev/null +++ b/drivers/dax/dax.c @@ -0,0 +1,252 @@ +/* + * Copyright(c) 2016 Intel Corporation. All rights reserved. + * + * 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. + * + * 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. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +static int dax_major; +static struct class *dax_class; +static DEFINE_IDA(dax_minor_ida); + +/** + * struct dax_region - mapping infrastructure for dax
[PATCH v2 2/3] /dev/dax, core: file operations and dax-mmap
The "Device DAX" core enables dax mappings of performance / feature
differentiated memory. An open mapping or file handle keeps the backing
struct device live, but new mappings are only possible while the device
is enabled. Faults are handled under rcu_read_lock to synchronize
with the enabled state of the device.
Similar to the filesystem-dax case the backing memory may optionally
have struct page entries. However, unlike fs-dax there is no support
for private mappings, or mappings that are not backed by media (see
use of zero-page in fs-dax).
Mappings are always guaranteed to match the alignment of the dax_region.
If the dax_region is configured to have a 2MB alignment, all mappings
are guaranteed to be backed by a pmd entry. Contrast this determinism
with the fs-dax case where pmd mappings are opportunistic. If userspace
attempts to force a misaligned mapping, the driver will fail the mmap
attempt. See dax_dev_check_vma() for other scenarios that are rejected,
like MAP_PRIVATE mappings.
Cc: Jeff Moyer
Cc: Christoph Hellwig
Cc: Andrew Morton
Cc: Dave Hansen
Cc: Ross Zwisler
Signed-off-by: Dan Williams
---
drivers/dax/Kconfig |1
drivers/dax/dax.c | 316 +++
mm/huge_memory.c|1
mm/hugetlb.c|1
4 files changed, 319 insertions(+)
diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
index 86ffbaa891ad..cedab7572de3 100644
--- a/drivers/dax/Kconfig
+++ b/drivers/dax/Kconfig
@@ -1,6 +1,7 @@
menuconfig DEV_DAX
tristate "DAX: direct access to differentiated memory"
default m if NVDIMM_DAX
+ depends on TRANSPARENT_HUGEPAGE
help
Support raw access to differentiated (persistence, bandwidth,
latency...) memory via an mmap(2) capable character
diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 8207fb33a992..b2fe8a0ce866 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -49,6 +49,7 @@ struct dax_region {
* @region - parent region
* @dev - device backing the character device
* @kref - enable this data to be tracked in filp->private_data
+ * @alive - !alive + rcu grace period == no new mappings can be established
* @id - child id in the region
* @num_resources - number of physical address extents in this device
* @res - array of physical address ranges
@@ -57,6 +58,7 @@ struct dax_dev {
struct dax_region *region;
struct device *dev;
struct kref kref;
+ bool alive;
int id;
int num_resources;
struct resource res[0];
@@ -150,6 +152,10 @@ static void destroy_dax_dev(void *_dev)
dev_dbg(dev, "%s\n", __func__);
+ /* disable and flush fault handlers, TODO unmap inodes */
+ dax_dev->alive = false;
+ synchronize_rcu();
+
get_device(dev);
device_unregister(dev);
ida_simple_remove(&dax_region->ida, dax_dev->id);
@@ -173,6 +179,7 @@ int devm_create_dax_dev(struct dax_region *dax_region,
struct resource *res,
memcpy(dax_dev->res, res, sizeof(*res) * count);
dax_dev->num_resources = count;
kref_init(&dax_dev->kref);
+ dax_dev->alive = true;
dax_dev->region = dax_region;
kref_get(&dax_region->kref);
@@ -217,9 +224,318 @@ int devm_create_dax_dev(struct dax_region *dax_region,
struct resource *res,
}
EXPORT_SYMBOL_GPL(devm_create_dax_dev);
+/* return an unmapped area aligned to the dax region specified alignment */
+static unsigned long dax_dev_get_unmapped_area(struct file *filp,
+ unsigned long addr, unsigned long len, unsigned long pgoff,
+ unsigned long flags)
+{
+ unsigned long off, off_end, off_align, len_align, addr_align, align;
+ struct dax_dev *dax_dev = filp ? filp->private_data : NULL;
+ struct dax_region *dax_region;
+
+ if (!dax_dev || addr)
+ goto out;
+
+ dax_region = dax_dev->region;
+ align = dax_region->align;
+ off = pgoff << PAGE_SHIFT;
+ off_end = off + len;
+ off_align = round_up(off, align);
+
+ if ((off_end <= off_align) || ((off_end - off_align) < align))
+ goto out;
+
+ len_align = len + align;
+ if ((off + len_align) < off)
+ goto out;
+
+ addr_align = current->mm->get_unmapped_area(filp, addr, len_align,
+ pgoff, flags);
+ if (!IS_ERR_VALUE(addr_align)) {
+ addr_align += (off - addr_align) & (align - 1);
+ return addr_align;
+ }
+ out:
+ return current->mm->get_unmapped_area(filp, addr, len, pgoff, flags);
+}
+
+static int __match_devt(struct device *dev, const void *data)
+{
+ const dev_t *devt = data;
+
+ return dev->devt == *devt;
+}
+
+static struct device *dax_dev_find(dev_t dev_t)
+{
+ return class_find_device(dax_class, NULL, &dev_t, __match_devt);
+}
+
+static int dax_dev_open(struct inode *inode, struct file *filp)
+{
+ struct dax_de
[PATCH v2 0/3] "Device DAX" for persistent memory
Changes since v1: [1] 1/ Dropped the lead in cleanup patches from this posting as they appear on the libnvdimm-for-next branch. 2/ Fixed the needlessly overweight fault locking by replacing it with rcu_read_lock() and drop taking the i_mmap_lock since it has no effect or purpose. Unlike block devices the vfs does not arrange for character device inodes to share the same address_space. 3/ Fixed the device release path since the class release method is not called when the device is created by device_create_with_groups(). 4/ Cleanups resulting from the switch to carry (struct dax_dev *) in filp->private_date. --- Device DAX is the device-centric analogue of Filesystem DAX (CONFIG_FS_DAX). It allows memory ranges to be allocated and mapped without need of an intervening file system or being bound to block device semantics. Why "Device DAX"? 1/ As I mentioned at LSF [2] we are starting to see platforms with performance and feature differentiated memory ranges. Environments like high-performance-computing and usages like in-memory databases want exclusive allocation of a memory range with zero conflicting kernel/metadata allocations. For dedicated applications of high bandwidth or low latency memory device-DAX provides a predictable direct map mechanism. Note that this is only for the small number of "crazy" applications that are willing to re-write to get every bit of performance. For everyone else we, Dave Hansen and I, are looking to add a mechanism to hot-plug device-DAX ranges into the mm to get general memory management services (oversubscribe / migration, etc) with the understanding that it may sacrifice some predictability. 2/ For persistent memory there are similar applications that are willing to re-write to take full advantage of byte-addressable persistence. This mechanism satisfies those usages that only need a pre-allocated file to mmap. 3/ It answers Dave Chinner's call to start thinking about pmem-native solutions. Device DAX specifically avoids block-device and file system conflicts. [1]: https://lists.01.org/pipermail/linux-nvdimm/2016-May/005660.html [2]: https://lwn.net/Articles/685107/ --- Dan Williams (3): /dev/dax, pmem: direct access to persistent memory /dev/dax, core: file operations and dax-mmap Revert "block: enable dax for raw block devices" block/ioctl.c | 32 -- drivers/Kconfig |2 drivers/Makefile|1 drivers/dax/Kconfig | 26 ++ drivers/dax/Makefile|4 drivers/dax/dax.c | 568 +++ drivers/dax/dax.h | 24 + drivers/dax/pmem.c | 168 ++ fs/block_dev.c | 96 ++ include/linux/fs.h |8 include/uapi/linux/fs.h |1 mm/huge_memory.c|1 mm/hugetlb.c|1 tools/testing/nvdimm/Kbuild |9 + tools/testing/nvdimm/config_check.c |2 15 files changed, 835 insertions(+), 108 deletions(-) create mode 100644 drivers/dax/Kconfig create mode 100644 drivers/dax/Makefile create mode 100644 drivers/dax/dax.c create mode 100644 drivers/dax/dax.h create mode 100644 drivers/dax/pmem.c
[PATCH v2 3/3] Revert "block: enable dax for raw block devices"
This reverts commit 5a023cdba50c5f5f2bc351783b3131699deb3937.
The functionality is superseded by the new "Device DAX" facility.
Cc: Jeff Moyer
Cc: Christoph Hellwig
Cc: Dave Chinner
Cc: Andrew Morton
Cc: Ross Zwisler
Cc: Jan Kara
Signed-off-by: Dan Williams
---
block/ioctl.c | 32
fs/block_dev.c | 96 ++-
include/linux/fs.h |8
include/uapi/linux/fs.h |1
4 files changed, 29 insertions(+), 108 deletions(-)
diff --git a/block/ioctl.c b/block/ioctl.c
index 4ff1f92f89ca..698c7933d582 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -407,35 +407,6 @@ static inline int is_unrecognized_ioctl(int ret)
ret == -ENOIOCTLCMD;
}
-#ifdef CONFIG_FS_DAX
-bool blkdev_dax_capable(struct block_device *bdev)
-{
- struct gendisk *disk = bdev->bd_disk;
-
- if (!disk->fops->direct_access)
- return false;
-
- /*
-* If the partition is not aligned on a page boundary, we can't
-* do dax I/O to it.
-*/
- if ((bdev->bd_part->start_sect % (PAGE_SIZE / 512))
- || (bdev->bd_part->nr_sects % (PAGE_SIZE / 512)))
- return false;
-
- /*
-* If the device has known bad blocks, force all I/O through the
-* driver / page cache.
-*
-* TODO: support finer grained dax error handling
-*/
- if (disk->bb && disk->bb->count)
- return false;
-
- return true;
-}
-#endif
-
static int blkdev_flushbuf(struct block_device *bdev, fmode_t mode,
unsigned cmd, unsigned long arg)
{
@@ -598,9 +569,6 @@ int blkdev_ioctl(struct block_device *bdev, fmode_t mode,
unsigned cmd,
case BLKTRACESETUP:
case BLKTRACETEARDOWN:
return blk_trace_ioctl(bdev, cmd, argp);
- case BLKDAXGET:
- return put_int(arg, !!(bdev->bd_inode->i_flags & S_DAX));
- break;
case IOC_PR_REGISTER:
return blkdev_pr_register(bdev, argp);
case IOC_PR_RESERVE:
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 20a2c02b77c4..36ee10ca503e 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include "internal.h"
@@ -1159,6 +1160,33 @@ void bd_set_size(struct block_device *bdev, loff_t size)
}
EXPORT_SYMBOL(bd_set_size);
+static bool blkdev_dax_capable(struct block_device *bdev)
+{
+ struct gendisk *disk = bdev->bd_disk;
+
+ if (!disk->fops->direct_access || !IS_ENABLED(CONFIG_FS_DAX))
+ return false;
+
+ /*
+* If the partition is not aligned on a page boundary, we can't
+* do dax I/O to it.
+*/
+ if ((bdev->bd_part->start_sect % (PAGE_SIZE / 512))
+ || (bdev->bd_part->nr_sects % (PAGE_SIZE / 512)))
+ return false;
+
+ /*
+* If the device has known bad blocks, force all I/O through the
+* driver / page cache.
+*
+* TODO: support finer grained dax error handling
+*/
+ if (disk->bb && disk->bb->count)
+ return false;
+
+ return true;
+}
+
static void __blkdev_put(struct block_device *bdev, fmode_t mode, int
for_part);
/*
@@ -1724,79 +1752,13 @@ static const struct address_space_operations
def_blk_aops = {
.is_dirty_writeback = buffer_check_dirty_writeback,
};
-#ifdef CONFIG_FS_DAX
-/*
- * In the raw block case we do not need to contend with truncation nor
- * unwritten file extents. Without those concerns there is no need for
- * additional locking beyond the mmap_sem context that these routines
- * are already executing under.
- *
- * Note, there is no protection if the block device is dynamically
- * resized (partition grow/shrink) during a fault. A stable block device
- * size is already not enforced in the blkdev_direct_IO path.
- *
- * For DAX, it is the responsibility of the block device driver to
- * ensure the whole-disk device size is stable while requests are in
- * flight.
- *
- * Finally, unlike the filemap_page_mkwrite() case there is no
- * filesystem superblock to sync against freezing. We still include a
- * pfn_mkwrite callback for dax drivers to receive write fault
- * notifications.
- */
-static int blkdev_dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
-{
- return __dax_fault(vma, vmf, blkdev_get_block, NULL);
-}
-
-static int blkdev_dax_pfn_mkwrite(struct vm_area_struct *vma,
- struct vm_fault *vmf)
-{
- return dax_pfn_mkwrite(vma, vmf);
-}
-
-static int blkdev_dax_pmd_fault(struct vm_area_struct *vma, unsigned long addr,
- pmd_t *pmd, unsigned int flags)
-{
- return __dax_pmd_fault(vma, addr, pmd, flags, blkdev_get_block, NULL);
-}
-
-static const struct vm_operations_struct blkdev_dax_vm_ops = {
- .fault = blkdev_dax_fault,
- .pmd_fa
Re: [RFC][PATCH] printk: Add option to append kernel version to the dict
Hello,
On (05/13/16 13:58), Calvin Owens wrote:
[..]
> +#if defined(CONFIG_PRINTK_APPEND_UNAME)
> +static ssize_t msg_print_ext_uname(char *buf, size_t size)
> +{
> + return scnprintf(buf, size, " UNAME=%s\n", init_utsname()->release);
> +}
> +#else
> +static ssize_t msg_print_ext_uname(char *buf, size_t size)
> +{
> + return 0;
> +}
> +#endif
> +
> /* /dev/kmsg - userspace message inject/listen interface */
> struct devkmsg_user {
> u64 seq;
> @@ -2305,6 +2317,8 @@ skip:
> sizeof(ext_text) - ext_len,
> log_dict(msg), msg->dict_len,
> log_text(msg), msg->text_len);
> + ext_len += msg_print_ext_uname(ext_text + ext_len,
> + sizeof(ext_text) - ext_len);
> }
what if there is no place left for init_utsname() after msg_print_ext_header()
+ msg_print_ext_body()?
do you need init_utsname in every message? or just in WARN/ERR ones?
-ss
Re: [PATCH] dwc3: gadget: Defer starting the gadget device until gadget is power on
On 13 May 2016 at 20:46, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: > why does it need restart? Why is dwc3 powered off? Who powers it off? Because when the dwc3 Vbus is off (no cable pluging in now), especially for some mobile device, the system need to power off the dwc3 to save power in this situation. >>> >>> but dwc3 doesn't do this by itself, so who's doing it? >> >> Yes, the dwc3 clock is controlled by the Soc system, so the Soc system >> can disable the dwc3 clock when there is no cable plugging in. > > understood. > > This looks like a *really* bad power management implementation. Do you > have hibernation enabled? Do you have Clock gating enabled? Which dwc3 > version are you using? How was it configured? This is not hibernation, we want to power off the dwc3 to save power when no cable plugging in. Yes, we have clock gating, at this situation we will disable the clock and shutdown the phy to save power. For mobile device, most time no cable plugging in, so we need to think about the power consuming. How do you think this requirement? >>> >>> Well, seems like you're missing *proper* runtime PM. I've been meaning >>> to work on it for weeks, but I still have a few other things to do >>> before I get to that. In any case, we don't need to do what you did >>> here. There are better ways. >> >> Make sense. > > cool, if you wanna work on it, let me know and I can give some details > of what I have in mind. OK. I would like to do that, please help to give me some details. Thanks. > > -- > balbi -- Baolin.wang Best Regards
[PATCH v6 4/6] crypto: algif_akcipher - enable compilation
From: Stephan Mueller Add the Makefile and Kconfig updates to allow algif_akcipher to be compiled. Signed-off-by: Stephan Mueller Signed-off-by: Tadeusz Struk --- crypto/Kconfig |9 + crypto/Makefile |1 + 2 files changed, 10 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 93a1fdc..b932319 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1626,6 +1626,15 @@ config CRYPTO_USER_API_AEAD This option enables the user-spaces interface for AEAD cipher algorithms. +config CRYPTO_USER_API_AKCIPHER + tristate "User-space interface for asymmetric key cipher algorithms" + depends on NET + select CRYPTO_AKCIPHER2 + select CRYPTO_USER_API + help + This option enables the user-spaces interface for asymmetric + key cipher algorithms. + config CRYPTO_HASH_INFO bool diff --git a/crypto/Makefile b/crypto/Makefile index 4f4ef7e..c51ac16 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -121,6 +121,7 @@ obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o obj-$(CONFIG_CRYPTO_USER_API_SKCIPHER) += algif_skcipher.o obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o obj-$(CONFIG_CRYPTO_USER_API_AEAD) += algif_aead.o +obj-$(CONFIG_CRYPTO_USER_API_AKCIPHER) += algif_akcipher.o # # generic algorithms and the async_tx api
[PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface
From: Stephan Mueller
This patch adds the user space interface for asymmetric ciphers. The
interface allows the use of sendmsg as well as vmsplice to provide data.
This version has been rebased on top of 4.6 and a few chackpatch issues
have been fixed.
Signed-off-by: Stephan Mueller
Signed-off-by: Tadeusz Struk
---
crypto/algif_akcipher.c | 542 +++
1 file changed, 542 insertions(+)
create mode 100644 crypto/algif_akcipher.c
diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c
new file mode 100644
index 000..6342b6e
--- /dev/null
+++ b/crypto/algif_akcipher.c
@@ -0,0 +1,542 @@
+/*
+ * algif_akcipher: User-space interface for asymmetric cipher algorithms
+ *
+ * Copyright (C) 2015, Stephan Mueller
+ *
+ * This file provides the user-space API for asymmetric ciphers.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct akcipher_sg_list {
+ unsigned int cur;
+ struct scatterlist sg[ALG_MAX_PAGES];
+};
+
+struct akcipher_ctx {
+ struct akcipher_sg_list tsgl;
+ struct af_alg_sgl rsgl[ALG_MAX_PAGES];
+
+ struct af_alg_completion completion;
+
+ unsigned long used;
+
+ unsigned int len;
+ bool more;
+ bool merge;
+ int op;
+
+ struct akcipher_request req;
+};
+
+static inline int akcipher_sndbuf(struct sock *sk)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct akcipher_ctx *ctx = ask->private;
+
+ return max_t(int, max_t(int, sk->sk_sndbuf & PAGE_MASK, PAGE_SIZE) -
+ ctx->used, 0);
+}
+
+static inline bool akcipher_writable(struct sock *sk)
+{
+ return akcipher_sndbuf(sk) >= PAGE_SIZE;
+}
+
+static inline int akcipher_calcsize(struct akcipher_ctx *ctx)
+{
+ return crypto_akcipher_maxsize(crypto_akcipher_reqtfm(&ctx->req));
+}
+
+static void akcipher_put_sgl(struct sock *sk)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct akcipher_ctx *ctx = ask->private;
+ struct akcipher_sg_list *sgl = &ctx->tsgl;
+ struct scatterlist *sg = sgl->sg;
+ unsigned int i;
+
+ for (i = 0; i < sgl->cur; i++) {
+ if (!sg_page(sg + i))
+ continue;
+
+ put_page(sg_page(sg + i));
+ sg_assign_page(sg + i, NULL);
+ }
+ sg_init_table(sg, ALG_MAX_PAGES);
+ sgl->cur = 0;
+ ctx->used = 0;
+ ctx->more = 0;
+ ctx->merge = 0;
+}
+
+static void akcipher_wmem_wakeup(struct sock *sk)
+{
+ struct socket_wq *wq;
+
+ if (!akcipher_writable(sk))
+ return;
+
+ rcu_read_lock();
+ wq = rcu_dereference(sk->sk_wq);
+ if (wq_has_sleeper(&wq->wait))
+ wake_up_interruptible_sync_poll(&wq->wait, POLLIN |
+ POLLRDNORM |
+ POLLRDBAND);
+ sk_wake_async(sk, SOCK_WAKE_WAITD, POLL_IN);
+ rcu_read_unlock();
+}
+
+static int akcipher_wait_for_data(struct sock *sk, unsigned int flags)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct akcipher_ctx *ctx = ask->private;
+ long timeout;
+ DEFINE_WAIT(wait);
+ int err = -ERESTARTSYS;
+
+ if (flags & MSG_DONTWAIT)
+ return -EAGAIN;
+
+ set_bit(SOCKWQ_ASYNC_WAITDATA, &sk->sk_socket->flags);
+
+ for (;;) {
+ if (signal_pending(current))
+ break;
+ prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
+ timeout = MAX_SCHEDULE_TIMEOUT;
+ if (sk_wait_event(sk, &timeout, !ctx->more)) {
+ err = 0;
+ break;
+ }
+ }
+ finish_wait(sk_sleep(sk), &wait);
+
+ clear_bit(SOCKWQ_ASYNC_WAITDATA, &sk->sk_socket->flags);
+
+ return err;
+}
+
+static void akcipher_data_wakeup(struct sock *sk)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct akcipher_ctx *ctx = ask->private;
+ struct socket_wq *wq;
+
+ if (ctx->more)
+ return;
+ if (!ctx->used)
+ return;
+
+ rcu_read_lock();
+ wq = rcu_dereference(sk->sk_wq);
+ if (wq_has_sleeper(&wq->wait))
+ wake_up_interruptible_sync_poll(&wq->wait, POLLOUT |
+ POLLRDNORM |
+ POLLRDBAND);
+ sk_wake_async(sk, SOCK_WAKE_SPACE, POLL_OUT);
+ rcu_read_unlock();
+}
+
+static int akcipher_sendmsg(struct socket *sock, struct msghdr *msg,
+
[PATCH v6 5/6] crypto: algif_akcipher - add ops_nokey
Similar to algif_skcipher and algif_hash, algif_akcipher needs
to prevent user space from using the interface in an improper way.
This patch adds nokey ops handlers, which do just that.
Signed-off-by: Tadeusz Struk
---
crypto/algif_akcipher.c | 159 +--
1 file changed, 152 insertions(+), 7 deletions(-)
diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c
index 6342b6e..e00793d 100644
--- a/crypto/algif_akcipher.c
+++ b/crypto/algif_akcipher.c
@@ -27,6 +27,11 @@ struct akcipher_sg_list {
struct scatterlist sg[ALG_MAX_PAGES];
};
+struct akcipher_tfm {
+ struct crypto_akcipher *akcipher;
+ bool has_key;
+};
+
struct akcipher_ctx {
struct akcipher_sg_list tsgl;
struct af_alg_sgl rsgl[ALG_MAX_PAGES];
@@ -450,25 +455,151 @@ static struct proto_ops algif_akcipher_ops = {
.poll = akcipher_poll,
};
+static int akcipher_check_key(struct socket *sock)
+{
+ int err = 0;
+ struct sock *psk;
+ struct alg_sock *pask;
+ struct akcipher_tfm *tfm;
+ struct sock *sk = sock->sk;
+ struct alg_sock *ask = alg_sk(sk);
+
+ lock_sock(sk);
+ if (ask->refcnt)
+ goto unlock_child;
+
+ psk = ask->parent;
+ pask = alg_sk(ask->parent);
+ tfm = pask->private;
+
+ err = -ENOKEY;
+ lock_sock_nested(psk, SINGLE_DEPTH_NESTING);
+ if (!tfm->has_key)
+ goto unlock;
+
+ if (!pask->refcnt++)
+ sock_hold(psk);
+
+ ask->refcnt = 1;
+ sock_put(psk);
+
+ err = 0;
+
+unlock:
+ release_sock(psk);
+unlock_child:
+ release_sock(sk);
+
+ return err;
+}
+
+static int akcipher_sendmsg_nokey(struct socket *sock, struct msghdr *msg,
+ size_t size)
+{
+ int err;
+
+ err = akcipher_check_key(sock);
+ if (err)
+ return err;
+
+ return akcipher_sendmsg(sock, msg, size);
+}
+
+static ssize_t akcipher_sendpage_nokey(struct socket *sock, struct page *page,
+ int offset, size_t size, int flags)
+{
+ int err;
+
+ err = akcipher_check_key(sock);
+ if (err)
+ return err;
+
+ return akcipher_sendpage(sock, page, offset, size, flags);
+}
+
+static int akcipher_recvmsg_nokey(struct socket *sock, struct msghdr *msg,
+ size_t ignored, int flags)
+{
+ int err;
+
+ err = akcipher_check_key(sock);
+ if (err)
+ return err;
+
+ return akcipher_recvmsg(sock, msg, ignored, flags);
+}
+
+static struct proto_ops algif_akcipher_ops_nokey = {
+ .family = PF_ALG,
+
+ .connect= sock_no_connect,
+ .socketpair = sock_no_socketpair,
+ .getname= sock_no_getname,
+ .ioctl = sock_no_ioctl,
+ .listen = sock_no_listen,
+ .shutdown = sock_no_shutdown,
+ .getsockopt = sock_no_getsockopt,
+ .mmap = sock_no_mmap,
+ .bind = sock_no_bind,
+ .accept = sock_no_accept,
+ .setsockopt = sock_no_setsockopt,
+
+ .release= af_alg_release,
+ .sendmsg= akcipher_sendmsg_nokey,
+ .sendpage = akcipher_sendpage_nokey,
+ .recvmsg= akcipher_recvmsg_nokey,
+ .poll = akcipher_poll,
+};
+
static void *akcipher_bind(const char *name, u32 type, u32 mask)
{
- return crypto_alloc_akcipher(name, type, mask);
+ struct akcipher_tfm *tfm;
+ struct crypto_akcipher *akcipher;
+
+ tfm = kzalloc(sizeof(*tfm), GFP_KERNEL);
+ if (!tfm)
+ return ERR_PTR(-ENOMEM);
+
+ akcipher = crypto_alloc_akcipher(name, type, mask);
+ if (IS_ERR(akcipher)) {
+ kfree(tfm);
+ return ERR_CAST(akcipher);
+ }
+
+ tfm->akcipher = akcipher;
+ return tfm;
}
static void akcipher_release(void *private)
{
- crypto_free_akcipher(private);
+ struct akcipher_tfm *tfm = private;
+ struct crypto_akcipher *akcipher = tfm->akcipher;
+
+ crypto_free_akcipher(akcipher);
+ kfree(tfm);
}
static int akcipher_setprivkey(void *private, const u8 *key,
unsigned int keylen)
{
- return crypto_akcipher_set_priv_key(private, key, keylen);
+ struct akcipher_tfm *tfm = private;
+ struct crypto_akcipher *akcipher = tfm->akcipher;
+ int err;
+
+ err = crypto_akcipher_set_priv_key(akcipher, key, keylen);
+ tfm->has_key = !err;
+ return err;
}
static int akcipher_setpubkey(void *private, const u8 *key, unsigned int
keylen)
{
- return crypto_akcipher_set_pub_key(private, key, keylen);
+ struct akcipher_tfm *tfm = private;
+ s
[PATCH v6 2/6] crypto: AF_ALG -- add setpubkey setsockopt call
From: Stephan Mueller
For supporting asymmetric ciphers, user space must be able to set the
public key. The patch adds a new setsockopt call for setting the public
key.
Signed-off-by: Stephan Mueller
---
crypto/af_alg.c | 18 +-
include/crypto/if_alg.h |1 +
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index f5e18c2..24dc082 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -202,13 +202,17 @@ unlock:
}
static int alg_setkey(struct sock *sk, char __user *ukey,
- unsigned int keylen)
+ unsigned int keylen,
+ int (*setkey)(void *private, const u8 *key,
+ unsigned int keylen))
{
struct alg_sock *ask = alg_sk(sk);
- const struct af_alg_type *type = ask->type;
u8 *key;
int err;
+ if (!setkey)
+ return -ENOPROTOOPT;
+
key = sock_kmalloc(sk, keylen, GFP_KERNEL);
if (!key)
return -ENOMEM;
@@ -217,7 +221,7 @@ static int alg_setkey(struct sock *sk, char __user *ukey,
if (copy_from_user(key, ukey, keylen))
goto out;
- err = type->setkey(ask->private, key, keylen);
+ err = setkey(ask->private, key, keylen);
out:
sock_kzfree_s(sk, key, keylen);
@@ -247,10 +251,14 @@ static int alg_setsockopt(struct socket *sock, int level,
int optname,
case ALG_SET_KEY:
if (sock->state == SS_CONNECTED)
goto unlock;
- if (!type->setkey)
+
+ err = alg_setkey(sk, optval, optlen, type->setkey);
+ break;
+ case ALG_SET_PUBKEY:
+ if (sock->state == SS_CONNECTED)
goto unlock;
- err = alg_setkey(sk, optval, optlen);
+ err = alg_setkey(sk, optval, optlen, type->setpubkey);
break;
case ALG_SET_AEAD_AUTHSIZE:
if (sock->state == SS_CONNECTED)
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index a2bfd78..6c3e6e7 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -52,6 +52,7 @@ struct af_alg_type {
void *(*bind)(const char *name, u32 type, u32 mask);
void (*release)(void *private);
int (*setkey)(void *private, const u8 *key, unsigned int keylen);
+ int (*setpubkey)(void *private, const u8 *key, unsigned int keylen);
int (*accept)(void *private, struct sock *sk);
int (*accept_nokey)(void *private, struct sock *sk);
int (*setauthsize)(void *private, unsigned int authsize);
[PATCH v6 6/6] crypto: AF_ALG - add support for key_id
This patch adds support for asymmetric key type to AF_ALG.
It will work as follows: A new PF_ALG socket options are
added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely
ALG_SET_KEY_ID and ALG_SET_PUBKEY_ID for setting public and
private keys respectively. When these new options will be used
the user, instead of providing the key material, will provide a
key id and the key itself will be obtained from kernel keyring
subsystem. The user will use the standard tools (keyctl tool
or the keyctl syscall) for key instantiation and to obtain the
key id. The key id can also be obtained by reading the
/proc/keys file.
When a key corresponding to the given keyid is found, it is stored
in the socket context and subsequent crypto operation invoked by the
user will use the new asymmetric accessor functions instead of akcipher
api. The asymmetric subtype can internally use akcipher api or
invoke operations defined by a given subtype, depending on the
key type.
Signed-off-by: Tadeusz Struk
---
crypto/af_alg.c | 10 ++
crypto/algif_akcipher.c | 207 ++-
include/crypto/if_alg.h |1
include/uapi/linux/if_alg.h |2
4 files changed, 215 insertions(+), 5 deletions(-)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 24dc082..59c8244 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -260,6 +260,16 @@ static int alg_setsockopt(struct socket *sock, int level,
int optname,
err = alg_setkey(sk, optval, optlen, type->setpubkey);
break;
+
+ case ALG_SET_KEY_ID:
+ case ALG_SET_PUBKEY_ID:
+ /* ALG_SET_KEY_ID is only for akcipher */
+ if (!strcmp(type->name, "akcipher") ||
+ sock->state == SS_CONNECTED)
+ goto unlock;
+
+ err = alg_setkey(sk, optval, optlen, type->setkeyid);
+ break;
case ALG_SET_AEAD_AUTHSIZE:
if (sock->state == SS_CONNECTED)
goto unlock;
diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c
index e00793d..6733df1 100644
--- a/crypto/algif_akcipher.c
+++ b/crypto/algif_akcipher.c
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -29,6 +31,7 @@ struct akcipher_sg_list {
struct akcipher_tfm {
struct crypto_akcipher *akcipher;
+ char keyid[12];
bool has_key;
};
@@ -37,6 +40,7 @@ struct akcipher_ctx {
struct af_alg_sgl rsgl[ALG_MAX_PAGES];
struct af_alg_completion completion;
+ struct key *key;
unsigned long used;
@@ -322,6 +326,153 @@ unlock:
return err ? err : size;
}
+static int asym_key_encrypt(const struct key *key, struct akcipher_request
*req)
+{
+ struct kernel_pkey_params params = {0};
+ char *src = NULL, *dst = NULL, *in, *out;
+ int ret;
+
+ if (!sg_is_last(req->src)) {
+ src = kmalloc(req->src_len, GFP_KERNEL);
+ if (!src)
+ return -ENOMEM;
+ scatterwalk_map_and_copy(src, req->src, 0, req->src_len, 0);
+ in = src;
+ } else {
+ in = sg_virt(req->src);
+ }
+ if (!sg_is_last(req->dst)) {
+ dst = kmalloc(req->dst_len, GFP_KERNEL);
+ if (!dst) {
+ kfree(src);
+ return -ENOMEM;
+ }
+ out = dst;
+ } else {
+ out = sg_virt(req->dst);
+ }
+ params.key = (struct key *)key;
+ params.in_len = req->src_len;
+ params.out_len = req->dst_len;
+ ret = encrypt_blob(¶ms, in, out);
+ if (ret)
+ goto free;
+
+ if (dst)
+ scatterwalk_map_and_copy(dst, req->dst, 0, req->dst_len, 1);
+free:
+ kfree(src);
+ kfree(dst);
+ return ret;
+}
+
+static int asym_key_decrypt(const struct key *key, struct akcipher_request
*req)
+{
+ struct kernel_pkey_params params = {0};
+ char *src = NULL, *dst = NULL, *in, *out;
+ int ret;
+
+ if (!sg_is_last(req->src)) {
+ src = kmalloc(req->src_len, GFP_KERNEL);
+ if (!src)
+ return -ENOMEM;
+ scatterwalk_map_and_copy(src, req->src, 0, req->src_len, 0);
+ in = src;
+ } else {
+ in = sg_virt(req->src);
+ }
+ if (!sg_is_last(req->dst)) {
+ dst = kmalloc(req->dst_len, GFP_KERNEL);
+ if (!dst) {
+ kfree(src);
+ return -ENOMEM;
+ }
+ out = dst;
+ } else {
+ out = sg_virt(req->dst);
+ }
+ params.key = (struct key *)key;
+ params.in_len = req->src_len;
+ params.out_len = req->dst_len;
+ ret = decrypt_blob(¶ms, in, out);
+ if (ret)
+ goto free;
[PATCH v6 1/6] crypto: AF_ALG -- add sign/verify API
From: Stephan Mueller
Add the flags for handling signature generation and signature
verification.
Also, the patch adds the interface for setting a public key.
Signed-off-by: Stephan Mueller
Signed-off-by: Tadeusz Struk
---
include/uapi/linux/if_alg.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
index f2acd2f..02e6162 100644
--- a/include/uapi/linux/if_alg.h
+++ b/include/uapi/linux/if_alg.h
@@ -34,9 +34,12 @@ struct af_alg_iv {
#define ALG_SET_OP 3
#define ALG_SET_AEAD_ASSOCLEN 4
#define ALG_SET_AEAD_AUTHSIZE 5
+#define ALG_SET_PUBKEY 6
/* Operations */
#define ALG_OP_DECRYPT 0
#define ALG_OP_ENCRYPT 1
+#define ALG_OP_SIGN2
+#define ALG_OP_VERIFY 3
#endif /* _LINUX_IF_ALG_H */
[PATCH v6 0/6] crypto: algif - add akcipher
First four patches are a resend of the v3 algif_akcipher from Stephan Mueller, with minor changes after rebase on top of 4.6-rc1. The next three patches add support for keys stored in system keyring subsystem. First patch adds algif_akcipher nokey hadlers. Second patch adds generic sign, verify, encrypt, decrypt accessors functions to the asymmetric key type. These will be defined by asymmetric subtypes, similarly to how public_key currently defines the verify_signature function. Third patch adds support for ALG_SET_KEY_ID and ALG_SET_PUBKEY_ID commands to AF_ALG and setkeyid operation to the af_alg_type struct. If the keyid is used then the afalg layer acquires the key for the keyring subsystem and uses the new asymmetric accessor functions instead of akcipher api. The asymmetric subtypes can use akcipher api internally. This is the same v5 version as before rebased on top of http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-asym-keyctl v6 changes: - update to reflect changes in kernel_pkey_params struct v5 changes: - drop public key changes and use new version provided by David v4 changes: - don't use internal public_key struct in af_alg. - add generic accessor functions to asymmetric key type, which take the generic struct key type and resolve the specific subtype internally v3 changes: - include Stephan's patches (rebased on 4.6-rc1) - add algif_akcipher nokey hadlers - add public_key info struct to public_key and helper query functions - add a check if a key is a software accessible key on af_alg, and return -ENOKEY if it isn't v2 changes: - pass the original skcipher request in ablkcipher.base.data instead of casting it back from the ablkcipher request. - rename _req to base_req - dropped 3/3 --- Stephan Mueller (4): crypto: AF_ALG -- add sign/verify API crypto: AF_ALG -- add setpubkey setsockopt call crypto: AF_ALG -- add asymmetric cipher interface crypto: algif_akcipher - enable compilation Tadeusz Struk (2): crypto: algif_akcipher - add ops_nokey crypto: AF_ALG - add support for key_id crypto/Kconfig |9 crypto/Makefile |1 crypto/af_alg.c | 28 + crypto/algif_akcipher.c | 884 +++ include/crypto/if_alg.h |2 include/uapi/linux/if_alg.h |5 6 files changed, 924 insertions(+), 5 deletions(-) create mode 100644 crypto/algif_akcipher.c -- TS
[PATCH perf/core v8 11/16] perf probe: Accept %sdt and %cached event name
From: Masami Hiramatsu
To improbe usability, support %[PROVIDER:]SDTEVENT format to
add new probes on SDT and cached events.
e.g.
# perf probe -x /lib/libc-2.17.so %lll_lock_wait_private
Added new event:
sdt_libc:lll_lock_wait_private (on %lll_lock_wait_private in
/usr/lib/libc-2.17.so)
You can now use it in all perf tools, such as:
perf record -e sdt_libc:lll_lock_wait_private -aR sleep 1
# perf probe -l | more
sdt_libc:lll_lock_wait_private (on __lll_lock_wait_private+21
in /usr/lib/libc-2.17.so)
Note that this is not only for SDT events, but also normal
events with event-name.
e.g. define "myevent" on cache (-n doesn't add the real probe)
# perf probe -x ./perf --cache -n --add 'myevent=dso__load $params'
Reuse the "myevent" from cache as below.
# perf probe -x ./perf %myevent
Signed-off-by: Masami Hiramatsu
Signed-off-by: Masami Hiramatsu
---
Changes in v7:
- Fix a bug to return an error if no SDT/cached events found in cache.
---
tools/perf/Documentation/perf-probe.txt |3 +
tools/perf/util/probe-event.c | 82 ++-
tools/perf/util/probe-event.h |1
tools/perf/util/probe-file.c|9 +++
4 files changed, 71 insertions(+), 24 deletions(-)
diff --git a/tools/perf/Documentation/perf-probe.txt
b/tools/perf/Documentation/perf-probe.txt
index 7a258e9..43523be 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -151,6 +151,8 @@ Probe points are defined by following syntax.
3) Define event based on source file with lazy pattern
[[GROUP:]EVENT=]SRC;PTN [ARG ...]
+4) Pre-defined SDT events
+ %[PROVIDER:]SDTEVENT
'EVENT' specifies the name of new event, if omitted, it will be set the name
of the probed function. You can also specify a group name by 'GROUP', if
omitted, set 'probe' is used for kprobe and 'probe_' is used for uprobe.
Note that using existing group name can conflict with other events.
Especially, using the group name reserved for kernel modules can hide embedded
events in the
@@ -158,6 +160,7 @@ modules.
'FUNC' specifies a probed function name, and it may have one of the following
options; '+OFFS' is the offset from function entry address in bytes, ':RLN' is
the relative-line number from function entry line, and '%return' means that it
probes function return. And ';PTN' means lazy matching pattern (see LAZY
MATCHING). Note that ';PTN' must be the end of the probe point definition. In
addition, '@SRC' specifies a source file which has that function.
It is also possible to specify a probe point by the source line number or lazy
matching by using 'SRC:ALN' or 'SRC;PTN' syntax, where 'SRC' is the source file
path, ':ALN' is the line number and ';PTN' is the lazy matching pattern.
'ARG' specifies the arguments of this probe point, (see PROBE ARGUMENT).
+'SDTEVENT' and 'PROVIDER' is the pre-defined event name which is defined by
user SDT (Statically Defined Tracing) or the pre-cached probes with event name.
PROBE ARGUMENT
--
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 79da841..5ec98b2 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1199,6 +1199,34 @@ err:
return err;
}
+static int parse_perf_probe_event_name(char **arg, struct perf_probe_event
*pev)
+{
+ char *ptr;
+
+ ptr = strchr(*arg, ':');
+ if (ptr) {
+ *ptr = '\0';
+ if (!is_c_func_name(*arg))
+ goto ng_name;
+ pev->group = strdup(*arg);
+ if (!pev->group)
+ return -ENOMEM;
+ *arg = ptr + 1;
+ } else
+ pev->group = NULL;
+ if (!is_c_func_name(*arg)) {
+ng_name:
+ semantic_error("%s is bad for event name -it must "
+ "follow C symbol-naming rule.\n", *arg);
+ return -EINVAL;
+ }
+ pev->event = strdup(*arg);
+ if (pev->event == NULL)
+ return -ENOMEM;
+
+ return 0;
+}
+
/* Parse probepoint definition. */
static int parse_perf_probe_point(char *arg, struct perf_probe_event *pev)
{
@@ -1206,38 +1234,43 @@ static int parse_perf_probe_point(char *arg, struct
perf_probe_event *pev)
char *ptr, *tmp;
char c, nc = 0;
bool file_spec = false;
+ int ret;
+
/*
*
* perf probe [GRP:][EVENT=]SRC[:LN|;PTN]
* perf probe [GRP:][EVENT=]FUNC[@SRC][+OFFS|%return|:LN|;PAT]
+* perf probe %[GRP:]SDT_EVENT
*/
if (!arg)
return -EINVAL;
+ if (arg[0] == '%') {
+ pev->sdt = true;
+ arg++;
+ }
+
ptr = strpbrk(arg, ";=@+%");
- if (ptr && *ptr == '=') { /* Event name */
- *ptr = '\0';
-
[PATCH perf/core v8 16/16] perf probe: Support a special SDT probe format
Support a special SDT probe format which can omit the '%' prefix
only if the SDT group name starts with "sdt_". So, for example
both of "%sdt_libc:setjump" and "sdt_libc:setjump" are acceptable
for perf probe --add.
Suggested-by: Brendan Gregg
Signed-off-by: Masami Hiramatsu
---
tools/perf/Documentation/perf-probe.txt |4 +++-
tools/perf/util/probe-event.c | 12 ++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/tools/perf/Documentation/perf-probe.txt
b/tools/perf/Documentation/perf-probe.txt
index 43523be..2ebde8b 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -152,7 +152,9 @@ Probe points are defined by following syntax.
[[GROUP:]EVENT=]SRC;PTN [ARG ...]
4) Pre-defined SDT events
- %[PROVIDER:]SDTEVENT
+ %[sdt_PROVIDER:]SDTEVENT
+ or,
+ sdt_PROVIDER:SDTEVENT
'EVENT' specifies the name of new event, if omitted, it will be set the name
of the probed function. You can also specify a group name by 'GROUP', if
omitted, set 'probe' is used for kprobe and 'probe_' is used for uprobe.
Note that using existing group name can conflict with other events.
Especially, using the group name reserved for kernel modules can hide embedded
events in the
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index bd31cac..a4819f9 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1245,9 +1245,17 @@ static int parse_perf_probe_point(char *arg, struct
perf_probe_event *pev)
if (!arg)
return -EINVAL;
- if (arg[0] == '%') {
+ /*
+* If the probe point starts with '%',
+* or starts with "sdt_" and has a ':' but no '=',
+* then it should be a SDT/cached probe point.
+*/
+ if (arg[0] == '%' ||
+ (!strncmp(arg, "sdt_", 4) &&
+!!strchr(arg, ':') && !strchr(arg, '='))) {
pev->sdt = true;
- arg++;
+ if (arg[0] == '%')
+ arg++;
}
ptr = strpbrk(arg, ";=@+%");
[PATCH perf/core v8 12/16] perf-list: Show SDT and pre-cached events
From: Masami Hiramatsu
Show SDT and pre-cached events by perf-list with "sdt". This also
shows the binary and build-id where the events are placed only
when there are same name events on different binaries.
e.g.
# perf list sdt
List of pre-defined events (to be used in -e):
sdt_libc:lll_futex_wake[SDT event]
sdt_libc:lll_lock_wait_private [SDT event]
sdt_libc:longjmp [SDT event]
sdt_libc:longjmp_target[SDT event]
...
sdt_libstdcxx:rethrow@/usr/bin/gcc(0cc207fc4b27) [SDT event]
sdt_libstdcxx:rethrow@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
sdt_libstdcxx:throw@/usr/bin/gcc(0cc207fc4b27) [SDT event]
sdt_libstdcxx:throw@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
The binary path and build-id are shown in below format;
:@()
Signed-off-by: Masami Hiramatsu
Signed-off-by: Masami Hiramatsu
---
Changes in v5:
- Fix a build error for minimal option.
Changes in v4:
- Update patch description.
- Change event list format.
---
tools/perf/builtin-list.c |4 ++
tools/perf/util/parse-events.c | 83
tools/perf/util/parse-events.h |2 +
tools/perf/util/probe-file.h |9
4 files changed, 98 insertions(+)
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 5e22db4..3cba865 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -62,6 +62,8 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
print_hwcache_events(NULL, raw_dump);
else if (strcmp(argv[i], "pmu") == 0)
print_pmu_events(NULL, raw_dump);
+ else if (strcmp(argv[i], "sdt") == 0)
+ print_sdt_events(NULL, NULL, raw_dump);
else if ((sep = strchr(argv[i], ':')) != NULL) {
int sep_idx;
@@ -76,6 +78,7 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
s[sep_idx] = '\0';
print_tracepoint_events(s, s + sep_idx + 1, raw_dump);
+ print_sdt_events(s, s + sep_idx + 1, raw_dump);
free(s);
} else {
if (asprintf(&s, "*%s*", argv[i]) < 0) {
@@ -89,6 +92,7 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
print_hwcache_events(s, raw_dump);
print_pmu_events(s, raw_dump);
print_tracepoint_events(NULL, s, raw_dump);
+ print_sdt_events(NULL, s, raw_dump);
free(s);
}
}
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index bcbc983..f9c8b7b 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -20,6 +20,7 @@
#include "pmu.h"
#include "thread_map.h"
#include "cpumap.h"
+#include "probe-file.h"
#include "asm/bug.h"
#define MAX_NAME_LEN 100
@@ -1976,6 +1977,86 @@ static bool is_event_supported(u8 type, unsigned config)
return ret;
}
+void print_sdt_events(const char *subsys_glob, const char *event_glob,
+ bool name_only)
+{
+ struct probe_cache *pcache;
+ struct probe_cache_entry *ent;
+ struct strlist *bidlist, *sdtlist;
+ struct strlist_config cfg = {.dont_dupstr = true};
+ struct str_node *nd, *nd2;
+ char *buf, *path, *ptr = NULL;
+ bool show_detail = false;
+ int ret;
+
+ sdtlist = strlist__new(NULL, &cfg);
+ if (!sdtlist) {
+ pr_debug("Failed to allocate new strlist for SDT\n");
+ return;
+ }
+ ret = build_id_cache__list_all(&bidlist);
+ if (ret < 0) {
+ pr_debug("Failed to get buildids: %d\n", ret);
+ return;
+ }
+ strlist__for_each(nd, bidlist) {
+ pcache = probe_cache__new(nd->s);
+ if (!pcache)
+ continue;
+ if (!list_empty(&pcache->list))
+ list_for_each_entry(ent, &pcache->list, list) {
+ if (!ent->sdt)
+ continue;
+ if (subsys_glob &&
+ !strglobmatch(ent->pev.group, subsys_glob))
+ continue;
+ if (event_glob &&
+ !strglobmatch(ent->pev.event, event_glob))
+ continue;
+ ret = asprintf(&buf, "%s:%s@%s", ent->pev.group,
+ ent->pev.event, nd->s);
+ if (ret > 0)
+
[PATCH perf/core v8 14/16] perf probe: Allow wildcard for cached events
Allo glob wildcard for reusing cached/SDT events. This also
automatically find the target binaries, e.g.
# perf probe -a %sdt_libc:\*
This example adds probes for all SDT in libc.
Note that the SDTs must have been scanned by perf buildid-cache.
Signed-off-by: Masami Hiramatsu
---
Changes in v7:
- Continue to search caches if a build-id cache has no probe cache.
- Make probe_cache__open() to accept DSO__NAME_KALLSYMS for kernel.
- Fix to add probes correctly when a wildcard matchs both of
uprobes and kprobes.
Changes in v5.1:
- Fix a SEGV bug when a group name is omitted. (Thanks Hemant!)
---
tools/perf/util/probe-event.c | 211 +
tools/perf/util/probe-event.h |1
tools/perf/util/probe-file.c | 46 +++--
tools/perf/util/probe-file.h |5 +
4 files changed, 232 insertions(+), 31 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 5ec98b2..0019a22 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -236,7 +236,7 @@ static void clear_perf_probe_point(struct perf_probe_point
*pp)
free(pp->lazy_line);
}
-static void clear_probe_trace_events(struct probe_trace_event *tevs, int ntevs)
+void clear_probe_trace_events(struct probe_trace_event *tevs, int ntevs)
{
int i;
@@ -1206,7 +1206,7 @@ static int parse_perf_probe_event_name(char **arg, struct
perf_probe_event *pev)
ptr = strchr(*arg, ':');
if (ptr) {
*ptr = '\0';
- if (!is_c_func_name(*arg))
+ if (!pev->sdt && !is_c_func_name(*arg))
goto ng_name;
pev->group = strdup(*arg);
if (!pev->group)
@@ -1214,7 +1214,7 @@ static int parse_perf_probe_event_name(char **arg, struct
perf_probe_event *pev)
*arg = ptr + 1;
} else
pev->group = NULL;
- if (!is_c_func_name(*arg)) {
+ if (!pev->sdt && !is_c_func_name(*arg)) {
ng_name:
semantic_error("%s is bad for event name -it must "
"follow C symbol-naming rule.\n", *arg);
@@ -1640,6 +1640,11 @@ int parse_probe_trace_command(const char *cmd, struct
probe_trace_event *tev)
p = strchr(argv[1], ':');
if (p) {
tp->module = strndup(argv[1], p - argv[1]);
+ if (!tp->module) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ tev->uprobes = (tp->module[0] == '/');
p++;
} else
p = argv[1];
@@ -2514,7 +2519,7 @@ static int probe_trace_event__set_name(struct
probe_trace_event *tev,
int ret;
/* If probe_event or trace_event already have the name, reuse it */
- if (pev->event)
+ if (pev->event && !pev->sdt)
event = pev->event;
else if (tev->event)
event = tev->event;
@@ -2527,7 +2532,7 @@ static int probe_trace_event__set_name(struct
probe_trace_event *tev,
else
event = tev->point.realname;
}
- if (pev->group)
+ if (pev->group && !pev->sdt)
group = pev->group;
else if (tev->group)
group = tev->group;
@@ -2552,41 +2557,60 @@ static int probe_trace_event__set_name(struct
probe_trace_event *tev,
return 0;
}
-static int __add_probe_trace_events(struct perf_probe_event *pev,
-struct probe_trace_event *tevs,
-int ntevs, bool allow_suffix)
+static int __open_probe_file_and_namelist(bool uprobe,
+ struct strlist **namelist)
{
- int i, fd, ret;
- struct probe_trace_event *tev = NULL;
- struct probe_cache *cache = NULL;
- struct strlist *namelist;
+ int fd;
- fd = probe_file__open(PF_FL_RW | (pev->uprobes ? PF_FL_UPROBE : 0));
+ fd = probe_file__open(PF_FL_RW | (uprobe ? PF_FL_UPROBE : 0));
if (fd < 0)
return fd;
/* Get current event names */
- namelist = probe_file__get_namelist(fd);
- if (!namelist) {
+ *namelist = probe_file__get_namelist(fd);
+ if (!(*namelist)) {
pr_debug("Failed to get current event list.\n");
- ret = -ENOMEM;
- goto close_out;
+ close(fd);
+ return -ENOMEM;
}
+ return fd;
+}
+
+static int __add_probe_trace_events(struct perf_probe_event *pev,
+struct probe_trace_event *tevs,
+int ntevs, bool allow_suffix)
+{
+ int i, fd[2] = {-1, -1}, up, ret;
+ struct probe_trace_event *tev = NULL;
+ struct probe_cache *cache = NULL;
+ struct strlist *namelist[2] = {NULL, NULL};
+
+ up = pev->uprobes ? 1 : 0;
+ fd[up] = __open_probe_fil
[PATCH perf/core v8 10/16] perf buildid-cache: Scan and import user SDT events to probe cache
From: Masami Hiramatsu
perf buildid-cache --add scans given binary and add
the SDT events to probe cache. "sdt_" prefix is appended for
all SDT providers to avoid event-name clash with other pre-defined
events. It is possible to use the cached SDT events as other cached
events, via perf probe --add "sdt_:=".
e.g.
# perf buildid-cache --add /lib/libc-2.17.so
# perf probe --cache --list | head -n 5
/usr/lib/libc-2.17.so (a6fb821bdf53660eb2c29f778757aef294d3d392):
sdt_libc:setjmp=setjmp
sdt_libc:longjmp=longjmp
sdt_libc:longjmp_target=longjmp_target
sdt_libc:memory_heap_new=memory_heap_new
# perf probe -x /usr/lib/libc-2.17.so \
-a sdt_libc:memory_heap_new=memory_heap_new
Added new event:
sdt_libc:memory_heap_new (on memory_heap_new
in /usr/lib/libc-2.17.so)
You can now use it in all perf tools, such as:
perf record -e sdt_libc:memory_heap_new -aR sleep 1
# perf probe -l
sdt_libc:memory_heap_new (on new_heap+183 in /usr/lib/libc-2.17.so)
Note that SDT event entries in probe-cache file is somewhat different
from normal cached events. Normal one starts with "#", but SDTs are
starting with "%".
Signed-off-by: Masami Hiramatsu
Signed-off-by: Masami Hiramatsu
---
Changes in v4:
- Fix a bug to copy correct group name to entries.
- Fix to consolidate same-name entries.
---
tools/perf/util/build-id.c | 27 +++--
tools/perf/util/probe-file.c | 67 --
tools/perf/util/probe-file.h |2 +
3 files changed, 90 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index 14fbd37..68a67eb 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -17,6 +17,7 @@
#include "tool.h"
#include "header.h"
#include "vdso.h"
+#include "probe-file.h"
static bool no_buildid_cache;
@@ -513,6 +514,23 @@ int build_id_cache__list_build_ids(const char *pathname,
return ret;
}
+#ifdef HAVE_LIBELF_SUPPORT
+static void build_id_cache__add_sdt_cache(const char *sbuild_id,
+ const char *realname)
+{
+ struct probe_cache *cache;
+
+ cache = probe_cache__new(sbuild_id);
+ if (!cache)
+ return;
+ if (probe_cache__scan_sdt(cache, realname) >= 0)
+ probe_cache__commit(cache);
+ probe_cache__delete(cache);
+}
+#else
+#define build_id_cache__add_sdt_cache(sbuild_id, realname) do { } while (0)
+#endif
+
int build_id_cache__add_s(const char *sbuild_id, const char *name,
bool is_kallsyms, bool is_vdso)
{
@@ -556,20 +574,23 @@ int build_id_cache__add_s(const char *sbuild_id, const
char *name,
goto out_free;
}
+ /* Make a symbolic link */
if (!build_id_cache__linkname(sbuild_id, linkname, size))
goto out_free;
+
tmp = strrchr(linkname, '/');
*tmp = '\0';
-
if (access(linkname, X_OK) && mkdir_p(linkname, 0755))
goto out_free;
-
*tmp = '/';
tmp = dir_name + strlen(buildid_dir) - 5;
memcpy(tmp, "../..", 5);
-
if (symlink(tmp, linkname) == 0)
err = 0;
+
+ /* Update SDT cache */
+ build_id_cache__add_sdt_cache(sbuild_id, realname);
+
out_free:
if (!is_kallsyms)
free(realname);
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index cc0f183..da241ed 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -429,12 +429,15 @@ static int probe_cache__load(struct probe_cache *pcache)
p = strchr(buf, '\n');
if (p)
*p = '\0';
- if (buf[0] == '#') {/* #perf_probe_event */
+ /* #perf_probe_event or %sdt_event */
+ if (buf[0] == '#' || buf[0] == '%') {
entry = probe_cache_entry__new(NULL);
if (!entry) {
ret = -ENOMEM;
goto out;
}
+ if (buf[0] == '%')
+ entry->sdt = true;
entry->spev = strdup(buf + 1);
if (entry->spev)
ret = parse_perf_probe_command(buf + 1,
@@ -611,14 +614,72 @@ out_err:
return ret;
}
+static unsigned long long sdt_note__get_addr(struct sdt_note *note)
+{
+ return note->bit32 ? (unsigned long long)note->addr.a32[0]
+: (unsigned long long)note->addr.a64[0];
+}
+
+int probe_cache__scan_sdt(struct probe_cache *pcache, const char *pathname)
+{
+ struct probe_cache_entry *entry = NULL;
+ struct list_head sdtlist;
+ struct sdt_note *note;
+ char *buf;
+ char sdtgrp[64];
+ int ret;
+
+ INIT_LIST_HEAD(&sdtlist);
+ ret = get_sdt_note_list(&sdtlist, pa
[PATCH perf/core v8 13/16] perf-list: Skip SDTs placed in invalid binaries
From: Masami Hiramatsu
Skip SDTs placed in invalid (non-exist, or older version)
binaries. Note that perf-probe --cache --list and
perf-probe --cache --del still handle all the caches
including invalid binaries.
Signed-off-by: Masami Hiramatsu
Signed-off-by: Masami Hiramatsu
---
Changes in v7:
- Validate build-id via sysfs if it is for kallsyms,
Changes in v4:
- Rename a parameter 'valid' to 'validonly' :)
---
tools/perf/builtin-probe.c |2 +-
tools/perf/util/build-id.c | 33 -
tools/perf/util/build-id.h |2 +-
tools/perf/util/parse-events.c |2 +-
tools/perf/util/probe-file.c |2 +-
5 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 8f61525..4a86aea 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -370,7 +370,7 @@ static int del_perf_probe_caches(struct strfilter *filter)
struct str_node *nd;
int ret;
- ret = build_id_cache__list_all(&bidlist);
+ ret = build_id_cache__list_all(&bidlist, false);
if (ret < 0) {
pr_debug("Failed to get buildids: %d\n", ret);
return ret;
diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index 68a67eb..424f4e2 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -209,6 +209,31 @@ out:
return ret;
}
+/* Check if the given build_id cache is valid on current running system */
+static bool build_id_cache__valid_id(char *sbuild_id)
+{
+ char real_sbuild_id[SBUILD_ID_SIZE] = "";
+ char *pathname;
+ int ret = 0;
+ bool result = false;
+
+ pathname = build_id_cache__origname(sbuild_id);
+ if (!pathname)
+ return false;
+
+ if (!strcmp(pathname, DSO__NAME_KALLSYMS))
+ ret = sysfs__sprintf_build_id("/", real_sbuild_id);
+ else if (pathname[0] == '/')
+ ret = filename__sprintf_build_id(pathname, real_sbuild_id);
+ else
+ ret = -EINVAL; /* Should we support other special DSO cache? */
+ if (ret >= 0)
+ result = (strcmp(sbuild_id, real_sbuild_id) == 0);
+ free(pathname);
+
+ return result;
+}
+
static const char *build_id_cache__basename(bool is_kallsyms, bool is_vdso)
{
return is_kallsyms ? "kallsyms" : (is_vdso ? "vdso" : "elf");
@@ -420,7 +445,7 @@ void disable_buildid_cache(void)
no_buildid_cache = true;
}
-int build_id_cache__list_all(struct strlist **result)
+int build_id_cache__list_all(struct strlist **result, bool validonly)
{
struct strlist *toplist, *list, *bidlist;
struct str_node *nd, *nd2;
@@ -428,6 +453,10 @@ int build_id_cache__list_all(struct strlist **result)
char sbuild_id[SBUILD_ID_SIZE];
int ret = 0;
+ /* for filename__ functions */
+ if (validonly)
+ symbol__init(NULL);
+
/* Open the top-level directory */
if (asprintf(&topdir, "%s/.build-id/", buildid_dir) < 0)
return -errno;
@@ -457,6 +486,8 @@ int build_id_cache__list_all(struct strlist **result)
nd->s, nd2->s);
continue;
}
+ if (validonly && !build_id_cache__valid_id(sbuild_id))
+ continue;
strlist__add(bidlist, sbuild_id);
}
strlist__delete(list);
diff --git a/tools/perf/util/build-id.h b/tools/perf/util/build-id.h
index c05503e..480600b 100644
--- a/tools/perf/util/build-id.h
+++ b/tools/perf/util/build-id.h
@@ -34,7 +34,7 @@ char *build_id_cache__origname(const char *sbuild_id);
char *build_id_cache__linkname(const char *sbuild_id, char *bf, size_t size);
char *build_id_cache__cachedir(const char *sbuild_id, const char *name,
bool is_kallsyms, bool is_vdso);
-int build_id_cache__list_all(struct strlist **result);
+int build_id_cache__list_all(struct strlist **result, bool validonly);
int build_id_cache__list_build_ids(const char *pathname,
struct strlist **result);
bool build_id_cache__cached(const char *sbuild_id);
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index f9c8b7b..53d52a3 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1994,7 +1994,7 @@ void print_sdt_events(const char *subsys_glob, const char
*event_glob,
pr_debug("Failed to allocate new strlist for SDT\n");
return;
}
- ret = build_id_cache__list_all(&bidlist);
+ ret = build_id_cache__list_all(&bidlist, true);
if (ret < 0) {
pr_debug("Failed to get buildids: %d\n", ret);
return;
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index bc82a55..c4104c4 1
[PATCH perf/core v8 15/16] perf probe: Support @BUILDID or @FILE suffix for SDT events
Support @BUILDID or @FILE suffix for SDT events. This allows
perf to add probes on SDTs/pre-cached events on given FILE
or the file which has given BUILDID (also, this complements
BUILDID.)
For example, both gcc and libstdc++ has same SDTs as below.
If you would like to add a probe on sdt_libstdcxx:catch on gcc,
you can do as below.
# perf list sdt | tail -n 6
sdt_libstdcxx:catch@/usr/bin/gcc(0cc207fc4b27) [SDT event]
sdt_libstdcxx:catch@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
sdt_libstdcxx:rethrow@/usr/bin/gcc(0cc207fc4b27) [SDT event]
sdt_libstdcxx:rethrow@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
sdt_libstdcxx:throw@/usr/bin/gcc(0cc207fc4b27) [SDT event]
sdt_libstdcxx:throw@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
# perf probe -a sdt_libstdcxx:catch@0cc
Added new event:
sdt_libstdcxx:catch (on %catch in /usr/bin/gcc)
You can now use it in all perf tools, such as:
perf record -e sdt_libstdcxx:catch -aR sleep 1
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/build-id.c| 40
tools/perf/util/build-id.h|1 +
tools/perf/util/probe-event.c | 16 ++--
3 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index 424f4e2..c32931c 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -504,6 +504,46 @@ out:
return ret;
}
+static bool str_is_build_id(const char *maybe_sbuild_id, size_t len)
+{
+ size_t i;
+
+ for (i = 0; i < len; i++) {
+ if (!isxdigit(maybe_sbuild_id[i]))
+ return false;
+ }
+ return true;
+}
+
+/* Return the valid complete build-id */
+char *build_id_cache__complement(const char *incomplete_sbuild_id)
+{
+ struct strlist *list;
+ struct str_node *nd, *cand = NULL;
+ char *sbuild_id = NULL;
+ size_t len = strlen(incomplete_sbuild_id);
+
+ if (len >= SBUILD_ID_SIZE ||
+ !str_is_build_id(incomplete_sbuild_id, len) ||
+ build_id_cache__list_all(&list, true) < 0)
+ return NULL;
+
+ strlist__for_each(nd, list) {
+ if (strncmp(nd->s, incomplete_sbuild_id, len) != 0)
+ continue;
+ if (cand) { /* Error: There are more than 2 candidates. */
+ cand = NULL;
+ break;
+ }
+ cand = nd;
+ }
+ if (cand)
+ sbuild_id = strdup(cand->s);
+ strlist__delete(list);
+
+ return sbuild_id;
+}
+
char *build_id_cache__cachedir(const char *sbuild_id, const char *name,
bool is_kallsyms, bool is_vdso)
{
diff --git a/tools/perf/util/build-id.h b/tools/perf/util/build-id.h
index 480600b..9bd6d0b 100644
--- a/tools/perf/util/build-id.h
+++ b/tools/perf/util/build-id.h
@@ -35,6 +35,7 @@ char *build_id_cache__linkname(const char *sbuild_id, char
*bf, size_t size);
char *build_id_cache__cachedir(const char *sbuild_id, const char *name,
bool is_kallsyms, bool is_vdso);
int build_id_cache__list_all(struct strlist **result, bool validonly);
+char *build_id_cache__complement(const char *incomplete_sbuild_id);
int build_id_cache__list_build_ids(const char *pathname,
struct strlist **result);
bool build_id_cache__cached(const char *sbuild_id);
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 0019a22..bd31cac 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1253,8 +1253,20 @@ static int parse_perf_probe_point(char *arg, struct
perf_probe_event *pev)
ptr = strpbrk(arg, ";=@+%");
if (pev->sdt) {
if (ptr) {
- semantic_error("%s must contain only an SDT event
name.\n", arg);
- return -EINVAL;
+ if (*ptr != '@') {
+ semantic_error("%s must contain only an SDT
event name.\n", arg);
+ return -EINVAL;
+ }
+ /* This must be a target file name or build id */
+ tmp = build_id_cache__complement(ptr + 1);
+ if (tmp) {
+ pev->target = build_id_cache__origname(tmp);
+ free(tmp);
+ } else
+ pev->target = strdup(ptr + 1);
+ if (!pev->target)
+ return -ENOMEM;
+ *ptr = '\0';
}
ret = parse_perf_probe_event_name(&arg, pev);
if (ret == 0) {
[PATCH perf/core v8 05/16] perf probe: Use cache entry if possible
From: Masami Hiramatsu
Before analyzing debuginfo, try to find a corresponding entry
from probe cache always. This does not depend on --cache,
the --cache enables to store/update cache, but looking up
the cache is always enabled.
Signed-off-by: Masami Hiramatsu
Signed-off-by: Masami Hiramatsu
---
Changes in v6:
- Remove fallback lookup routine by using function name
as cached event name, because it should be done by following
patch which supports %cached-event.
---
tools/perf/util/probe-event.c | 65 -
tools/perf/util/probe-file.c | 20 -
tools/perf/util/probe-file.h |5 +++
3 files changed, 86 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 854885b..acc8341 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2472,17 +2472,24 @@ static int probe_trace_event__set_name(struct
probe_trace_event *tev,
char buf[64];
int ret;
+ /* If probe_event or trace_event already have the name, reuse it */
if (pev->event)
event = pev->event;
- else
+ else if (tev->event)
+ event = tev->event;
+ else {
+ /* Or generate new one from probe point */
if (pev->point.function &&
(strncmp(pev->point.function, "0x", 2) != 0) &&
!strisglob(pev->point.function))
event = pev->point.function;
else
event = tev->point.realname;
+ }
if (pev->group)
group = pev->group;
+ else if (tev->group)
+ group = tev->group;
else
group = PERFPROBE_GROUP;
@@ -2529,7 +2536,7 @@ static int __add_probe_trace_events(struct
perf_probe_event *pev,
for (i = 0; i < ntevs; i++) {
tev = &tevs[i];
/* Skip if the symbol is out of .text or blacklisted */
- if (!tev->point.symbol)
+ if (!tev->point.symbol && !pev->uprobes)
continue;
/* Set new name for tev (and update namelist) */
@@ -2842,6 +2849,55 @@ errout:
bool __weak arch__prefers_symtab(void) { return false; }
+static int find_probe_trace_events_from_cache(struct perf_probe_event *pev,
+ struct probe_trace_event **tevs)
+{
+ struct probe_cache *cache;
+ struct probe_cache_entry *entry;
+ struct probe_trace_event *tev;
+ struct str_node *node;
+ int ret, i;
+
+ cache = probe_cache__new(pev->target);
+ if (!cache)
+ return 0;
+
+ entry = probe_cache__find(cache, pev);
+ if (!entry) {
+ ret = 0;
+ goto out;
+ }
+
+ ret = strlist__nr_entries(entry->tevlist);
+ if (ret > probe_conf.max_probes) {
+ pr_debug("Too many entries matched in the cache of %s\n",
+pev->target ? : "kernel");
+ ret = -E2BIG;
+ goto out;
+ }
+
+ *tevs = zalloc(ret * sizeof(*tev));
+ if (!*tevs) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ i = 0;
+ strlist__for_each(node, entry->tevlist) {
+ tev = &(*tevs)[i++];
+ ret = parse_probe_trace_command(node->s, tev);
+ if (ret < 0)
+ goto out;
+ /* Set the uprobes attribute as same as original */
+ tev->uprobes = pev->uprobes;
+ }
+ ret = i;
+
+out:
+ probe_cache__delete(cache);
+ return ret;
+}
+
static int convert_to_probe_trace_events(struct perf_probe_event *pev,
struct probe_trace_event **tevs)
{
@@ -2864,6 +2920,11 @@ static int convert_to_probe_trace_events(struct
perf_probe_event *pev,
if (ret > 0)
return ret;
+ /* At first, we need to lookup cache entry */
+ ret = find_probe_trace_events_from_cache(pev, tevs);
+ if (ret > 0)
+ return ret; /* Found in probe cache */
+
if (arch__prefers_symtab() && !perf_probe_event_need_dwarf(pev)) {
ret = find_probe_trace_events_from_map(pev, tevs);
if (ret > 0)
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 689d874..f30f609 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -514,7 +514,7 @@ static bool streql(const char *a, const char *b)
return !strcmp(a, b);
}
-static struct probe_cache_entry *
+struct probe_cache_entry *
probe_cache__find(struct probe_cache *pcache, struct perf_probe_event *pev)
{
struct probe_cache_entry *entry = NULL;
@@ -539,6 +539,24 @@ found:
return entry;
}
+struct probe_cache_entry *
+probe_cache__find_by_name(struct probe_cache
[PATCH perf/core v8 03/16] perf-buildid-cache: Use path/to/bin/buildid/elf instead of path/to/bin/buildid
From: Masami Hiramatsu
Use path/to/bin/buildid/elf instead of path/to/bin/buildid
to store corresponding elf binary.
This also stores vdso in buildid/vdso, kallsyms in buildid/kallsyms.
Note that the existing caches are not updated until user adds
or updates the cache. Anyway, if there is the old style build-id
cache it falls back to use it. (IOW, it is backward compatible)
Signed-off-by: Masami Hiramatsu
Signed-off-by: Masami Hiramatsu
---
Changes in v7:
- Move kallsyms buildid related code into build-id.c
(as build_id_cache__kallsyms_path).
Changes in v6:
- Replace local __is_regular_file with is_regular_file in util.c.
(Thank you Namhyung!)
- Fix dso__build_id_is_kmod() to check symlink in buildid cache correctly.
Changes in v5:
- Support old style buildid caches.
---
tools/perf/util/build-id.c | 115 ++--
tools/perf/util/build-id.h |2 +
tools/perf/util/dso.h |5 ++
tools/perf/util/symbol.c |5 --
4 files changed, 96 insertions(+), 31 deletions(-)
diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index 67e5966..67f986c 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -144,7 +144,32 @@ static int asnprintf(char **strp, size_t size, const char
*fmt, ...)
return ret;
}
-static char *build_id__filename(const char *sbuild_id, char *bf, size_t size)
+char *build_id_cache__kallsyms_path(const char *sbuild_id, char *bf,
+ size_t size)
+{
+ bool is_alloc = !!bf;
+ bool retry_old = true;
+
+ asnprintf(&bf, size, "%s/%s/%s/kallsyms",
+ buildid_dir, DSO__NAME_KALLSYMS, sbuild_id);
+retry:
+ if (!access(bf, F_OK))
+ return bf;
+ if (is_alloc)
+ free(bf);
+ if (retry_old) {
+ /* Try old style kallsyms cache */
+ asnprintf(&bf, size, "%s/%s/%s",
+ buildid_dir, DSO__NAME_KALLSYMS, sbuild_id);
+ retry_old = false;
+ goto retry;
+ }
+
+ return NULL;
+}
+
+static char *build_id_cache__linkname(const char *sbuild_id, char *bf,
+ size_t size)
{
char *tmp = bf;
int ret = asnprintf(&bf, size, "%s/.build-id/%.2s/%s", buildid_dir,
@@ -154,23 +179,52 @@ static char *build_id__filename(const char *sbuild_id,
char *bf, size_t size)
return bf;
}
+static const char *build_id_cache__basename(bool is_kallsyms, bool is_vdso)
+{
+ return is_kallsyms ? "kallsyms" : (is_vdso ? "vdso" : "elf");
+}
+
char *dso__build_id_filename(const struct dso *dso, char *bf, size_t size)
{
- char build_id_hex[SBUILD_ID_SIZE];
+ bool is_kallsyms = dso__is_kallsyms((struct dso *)dso);
+ bool is_vdso = dso__is_vdso((struct dso *)dso);
+ char sbuild_id[SBUILD_ID_SIZE];
+ char *linkname;
+ bool alloc = (bf == NULL);
+ int ret;
if (!dso->has_build_id)
return NULL;
- build_id__sprintf(dso->build_id, sizeof(dso->build_id), build_id_hex);
- return build_id__filename(build_id_hex, bf, size);
+ build_id__sprintf(dso->build_id, sizeof(dso->build_id), sbuild_id);
+ linkname = build_id_cache__linkname(sbuild_id, NULL, 0);
+ if (!linkname)
+ return NULL;
+
+ /* Check if old style build_id cache */
+ if (is_regular_file(linkname))
+ ret = asnprintf(&bf, size, "%s", linkname);
+ else
+ ret = asnprintf(&bf, size, "%s/%s", linkname,
+build_id_cache__basename(is_kallsyms, is_vdso));
+ if (ret < 0 || (!alloc && size < (unsigned int)ret))
+ bf = NULL;
+ free(linkname);
+
+ return bf;
}
bool dso__build_id_is_kmod(const struct dso *dso, char *bf, size_t size)
{
- char *id_name, *ch;
+ char *id_name = NULL, *ch;
struct stat sb;
+ char sbuild_id[SBUILD_ID_SIZE];
+
+ if (!dso->has_build_id)
+ goto err;
- id_name = dso__build_id_filename(dso, bf, size);
+ build_id__sprintf(dso->build_id, sizeof(dso->build_id), sbuild_id);
+ id_name = build_id_cache__linkname(sbuild_id, NULL, 0);
if (!id_name)
goto err;
if (access(id_name, F_OK))
@@ -194,18 +248,14 @@ bool dso__build_id_is_kmod(const struct dso *dso, char
*bf, size_t size)
if (ch - 3 < bf)
goto err;
+ free(id_name);
return strncmp(".ko", ch - 3, 3) == 0;
err:
- /*
-* If dso__build_id_filename work, get id_name again,
-* because id_name points to bf and is broken.
-*/
- if (id_name)
- id_name = dso__build_id_filename(dso, bf, size);
pr_err("Invalid build id: %s\n", id_name ? :
dso->long_name ? :
dso->short_name ? :
[PATCH perf/core v8 07/16] perf probe: Remove caches when --cache is given
From: Masami Hiramatsu
perf-probe --del removes caches when --cache is given.
Note that the delete pattern is not same as normal events.
If you cached probes with event name, --del "eventname"
works as expected. However, if you skipped it, the cached
probes doesn't have actual event name. In that case
--del "probe-desc" is required (wildcard is acceptable).
For example a cache entry has the probe-desc "vfs_read $params",
you can remove it with --del 'vfs_read*'.
-
# perf probe --cache --list
/[kernel.kallsyms] (1466a0a250b5d0070c6d0f03c5fed30b237970a1):
vfs_read $params
/usr/lib64/libc-2.17.so (c31ffe7942bfd77b2fca8f9bd5709d387a86d3bc):
getaddrinfo $params
# perf probe --cache --del vfs_read\*
Removed event: probe:vfs_read
# perf probe --cache --list
/[kernel.kallsyms] (1466a0a250b5d0070c6d0f03c5fed30b237970a1):
/usr/lib64/libc-2.17.so (c31ffe7942bfd77b2fca8f9bd5709d387a86d3bc):
getaddrinfo $params
-
Signed-off-by: Masami Hiramatsu
Signed-off-by: Masami Hiramatsu
---
Changes in v4:
- move del_perf_probe_caches() into builtin-probe.c since
command-line related delete procedure is there now.
---
tools/perf/Documentation/perf-probe.txt |1 +
tools/perf/builtin-probe.c | 27 ++
tools/perf/util/probe-file.c| 32 ---
tools/perf/util/probe-file.h|2 ++
4 files changed, 55 insertions(+), 7 deletions(-)
diff --git a/tools/perf/Documentation/perf-probe.txt
b/tools/perf/Documentation/perf-probe.txt
index 5a70d45..8d09173 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -116,6 +116,7 @@ OPTIONS
(With --add) Cache the probes. Any events which successfully added
are also stored in the cache file.
(With --list) Show cached probes.
+ (With --del) Remove cached probes.
--max-probes=NUM::
Set the maximum number of probe points for an event. Default is 128.
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 53e380c0e..8f61525 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -363,6 +363,30 @@ out_cleanup:
return ret;
}
+static int del_perf_probe_caches(struct strfilter *filter)
+{
+ struct probe_cache *cache;
+ struct strlist *bidlist;
+ struct str_node *nd;
+ int ret;
+
+ ret = build_id_cache__list_all(&bidlist);
+ if (ret < 0) {
+ pr_debug("Failed to get buildids: %d\n", ret);
+ return ret;
+ }
+
+ strlist__for_each(nd, bidlist) {
+ cache = probe_cache__new(nd->s);
+ if (!cache)
+ continue;
+ probe_cache__remove_entries(cache, filter);
+ probe_cache__commit(cache);
+ probe_cache__delete(cache);
+ }
+ return 0;
+}
+
static int perf_del_probe_events(struct strfilter *filter)
{
int ret, ret2, ufd = -1, kfd = -1;
@@ -375,6 +399,9 @@ static int perf_del_probe_events(struct strfilter *filter)
pr_debug("Delete filter: \'%s\'\n", str);
+ if (probe_conf.cache)
+ return del_perf_probe_caches(filter);
+
/* Get current event names */
ret = probe_file__open_both(&kfd, &ufd, PF_FL_RW);
if (ret < 0)
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index a6d4a67..cc0f183 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -660,19 +660,37 @@ out:
return ret;
}
+static bool probe_cache_entry__compare(struct probe_cache_entry *entry,
+ struct strfilter *filter)
+{
+ char buf[128], *ptr = entry->spev;
+
+ if (entry->pev.event) {
+ snprintf(buf, 128, "%s:%s", entry->pev.group, entry->pev.event);
+ ptr = buf;
+ }
+ return strfilter__compare(filter, ptr);
+}
+
+int probe_cache__remove_entries(struct probe_cache *pcache,
+ struct strfilter *filter)
+{
+ struct probe_cache_entry *entry, *tmp;
+
+ list_for_each_entry_safe(entry, tmp, &pcache->list, list) {
+ if (probe_cache_entry__compare(entry, filter))
+ probe_cache_entry__delete(entry);
+ }
+ return 0;
+}
+
static int probe_cache__show_entries(struct probe_cache *pcache,
struct strfilter *filter)
{
struct probe_cache_entry *entry;
- char buf[128], *ptr;
list_for_each_entry(entry, &pcache->list, list) {
- if (entry->pev.event) {
- ptr = buf;
- snprintf(buf, 128, "%s:%s", entry->pev.group,
entry->pev.event);
- } else
- ptr = entry->spev;
- if (strfilter__compare(filter, ptr))
+ if (probe_cache_entry__compare(entry, filter))
[PATCH perf/core v8 08/16] perf/sdt: ELF support for SDT
From: Hemant Kumar
This patch serves the initial support to identify and list SDT events in
binaries.
When programs containing SDT markers are compiled, gcc with the help of
assembler
directives identifies them and places them in the section ".note.stapsdt". To
find
these markers from the binaries, one needs to traverse through this section and
parse the relevant details like the name, type and location of the marker. Also,
the original location could be skewed due to the effect of prelinking. If that
is
the case, the locations need to be adjusted.
The functions in this patch open a given ELF, find out the SDT section, parse
the
relevant details, adjust the location (if necessary) and populate them in a
list.
A typical note entry in ".note.stapsdt" section is as follows :
|--nhdr.n_namesz--|
| nhdr | "stapsdt" |
- |--|
| | |
| | |
nhdr.n_descsize | "provider_name" "note_name" |
| ||
- |--|
| nhdr | "stapsdt" |
|...
The above shows an excerpt from the section ".note.stapsdt".
'nhdr' is a structure which has the note name size (n_namesz), note
description size (n_desc_sz) and note type (n_type). So, in order to
parse the note note info, we need nhdr to tell us where to start from.
As can be seen from , the name of the SDT notes given is "stapsdt".
But this is not the identifier of the note.
After that, we go to description of the note to find out its location, the
address of the ".stapsdt.base" section and the semaphore address.
Then, we find the provider name and the SDT marker name and then follow the
arguments.
Signed-off-by: Hemant Kumar
Reviewed-by: Masami Hiramatsu
Acked-by: Namhyung Kim
---
tools/perf/util/symbol-elf.c | 252 ++
tools/perf/util/symbol.h | 22
2 files changed, 274 insertions(+)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 87a297d..e74ce17 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1781,6 +1781,258 @@ void kcore_extract__delete(struct kcore_extract *kce)
unlink(kce->extract_filename);
}
+/**
+ * populate_sdt_note : Parse raw data and identify SDT note
+ * @elf: elf of the opened file
+ * @data: raw data of a section with description offset applied
+ * @len: note description size
+ * @type: type of the note
+ * @sdt_notes: List to add the SDT note
+ *
+ * Responsible for parsing the @data in section .note.stapsdt in @elf and
+ * if its an SDT note, it appends to @sdt_notes list.
+ */
+static int populate_sdt_note(Elf **elf, const char *data, size_t len,
+struct list_head *sdt_notes)
+{
+ const char *provider, *name;
+ struct sdt_note *tmp = NULL;
+ GElf_Ehdr ehdr;
+ GElf_Addr base_off = 0;
+ GElf_Shdr shdr;
+ int ret = -EINVAL;
+
+ union {
+ Elf64_Addr a64[NR_ADDR];
+ Elf32_Addr a32[NR_ADDR];
+ } buf;
+
+ Elf_Data dst = {
+ .d_buf = &buf, .d_type = ELF_T_ADDR, .d_version = EV_CURRENT,
+ .d_size = gelf_fsize((*elf), ELF_T_ADDR, NR_ADDR, EV_CURRENT),
+ .d_off = 0, .d_align = 0
+ };
+ Elf_Data src = {
+ .d_buf = (void *) data, .d_type = ELF_T_ADDR,
+ .d_version = EV_CURRENT, .d_size = dst.d_size, .d_off = 0,
+ .d_align = 0
+ };
+
+ tmp = (struct sdt_note *)calloc(1, sizeof(struct sdt_note));
+ if (!tmp) {
+ ret = -ENOMEM;
+ goto out_err;
+ }
+
+ INIT_LIST_HEAD(&tmp->note_list);
+
+ if (len < dst.d_size + 3)
+ goto out_free_note;
+
+ /* Translation from file representation to memory representation */
+ if (gelf_xlatetom(*elf, &dst, &src,
+ elf_getident(*elf, NULL)[EI_DATA]) == NULL) {
+ pr_err("gelf_xlatetom : %s\n", elf_errmsg(-1));
+ goto out_free_note;
+ }
+
+ /* Populate the fields of sdt_note */
+ provider = data + dst.d_size;
+
+ name = (const char *)memchr(provider, '\0', data + len - provider);
+ if (name++ == NULL)
+ goto out_free_note;
+
+ tmp->provider = strdup(provider);
+ if (!tmp->provider) {
+ ret = -ENOMEM;
+ goto out_free_note;
+ }
+ tmp->name = strdup(name);
+ if (!tmp->name) {
+ ret = -ENOMEM;
+ goto out_free_prov;
+ }
+
+ if (gelf_getclass(*elf) == ELFCLASS32) {
+ memcpy(&tmp->addr, &buf, 3 * sizeof(Elf32_Addr));
+ tmp->bit32 = true;
+ } else {
+
[PATCH perf/core v8 04/16] perf probe: Add --cache option to cache the probe definitions
From: Masami Hiramatsu
Add --cache option to cache the probe definitions. This
just saves the result of the dwarf analysis to probe cache.
Signed-off-by: Masami Hiramatsu
Signed-off-by: Masami Hiramatsu
---
Changes in v6:
- Remove unneeded O_APPEND from open(). (Thanks Namhyung!)
- Fix to check the return value of probe_cache_entry__new and strdup.(ditto)
Changes in v5:
- Move probe_cache* definitions. (code cleanup)
Changes in v4:
- Remove cache saving failure message.
---
tools/perf/Documentation/perf-probe.txt |4
tools/perf/builtin-probe.c |1
tools/perf/util/build-id.c | 12 +
tools/perf/util/build-id.h |2
tools/perf/util/probe-event.c | 124 +++--
tools/perf/util/probe-event.h |5 +
tools/perf/util/probe-file.c| 307 +++
tools/perf/util/probe-file.h| 19 ++
8 files changed, 447 insertions(+), 27 deletions(-)
diff --git a/tools/perf/Documentation/perf-probe.txt
b/tools/perf/Documentation/perf-probe.txt
index 3a8a9ba..947db6f 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -109,6 +109,10 @@ OPTIONS
Dry run. With this option, --add and --del doesn't execute actual
adding and removal operations.
+--cache::
+ Cache the probes (with --add option). Any events which successfully
added
+ are also stored in the cache file.
+
--max-probes=NUM::
Set the maximum number of probe points for an event. Default is 128.
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 9af859b..6d7ab431 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -512,6 +512,7 @@ __cmd_probe(int argc, const char **argv, const char *prefix
__maybe_unused)
"Enable symbol demangling"),
OPT_BOOLEAN(0, "demangle-kernel", &symbol_conf.demangle_kernel,
"Enable kernel symbol demangling"),
+ OPT_BOOLEAN(0, "cache", &probe_conf.cache, "Manipulate probe cache"),
OPT_END()
};
int ret;
diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index 67f986c..ccf0d0d 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -390,9 +390,8 @@ void disable_buildid_cache(void)
no_buildid_cache = true;
}
-static char *build_id_cache__dirname_from_path(const char *name,
- bool is_kallsyms, bool is_vdso,
- const char *sbuild_id)
+char *build_id_cache__cachedir(const char *sbuild_id, const char *name,
+ bool is_kallsyms, bool is_vdso)
{
char *realname = (char *)name, *filename;
bool slash = is_kallsyms || is_vdso;
@@ -420,8 +419,7 @@ int build_id_cache__list_build_ids(const char *pathname,
char *dir_name;
int ret = 0;
- dir_name = build_id_cache__dirname_from_path(pathname, false, false,
-NULL);
+ dir_name = build_id_cache__cachedir(NULL, pathname, false, false);
if (!dir_name)
return -ENOMEM;
@@ -447,8 +445,8 @@ int build_id_cache__add_s(const char *sbuild_id, const char
*name,
goto out_free;
}
- dir_name = build_id_cache__dirname_from_path(name, is_kallsyms,
-is_vdso, sbuild_id);
+ dir_name = build_id_cache__cachedir(sbuild_id, name,
+ is_kallsyms, is_vdso);
if (!dir_name)
goto out_free;
diff --git a/tools/perf/util/build-id.h b/tools/perf/util/build-id.h
index e5435f4..d8c7f2f 100644
--- a/tools/perf/util/build-id.h
+++ b/tools/perf/util/build-id.h
@@ -30,6 +30,8 @@ bool perf_session__read_build_ids(struct perf_session
*session, bool with_hits);
int perf_session__write_buildid_table(struct perf_session *session, int fd);
int perf_session__cache_build_ids(struct perf_session *session);
+char *build_id_cache__cachedir(const char *sbuild_id, const char *name,
+ bool is_kallsyms, bool is_vdso);
int build_id_cache__list_build_ids(const char *pathname,
struct strlist **result);
bool build_id_cache__cached(const char *sbuild_id);
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 74401a2..854885b 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -67,7 +67,6 @@ int e_snprintf(char *str, size_t size, const char *format,
...)
return ret;
}
-static char *synthesize_perf_probe_point(struct perf_probe_point *pp);
static struct machine *host_machine;
/* Initialize symbol maps and path of vmlinux/modules */
@@ -1712,7 +1711,7 @@ out:
}
/* Compose only probe point (not argument) */
-static char *synthesize
[PATCH perf/core v8 06/16] perf probe: Show all cached probes
From: Masami Hiramatsu
perf probe --list shows all cached probes when --cache
is given. Each caches are shown with on which binary that
probed. e.g.
-
# perf probe --cache vfs_read \$params
# perf probe --cache -x /lib64/libc-2.17.so getaddrinfo \$params
# perf probe --cache --list
[kernel.kallsyms] (1466a0a250b5d0070c6d0f03c5fed30b237970a1):
vfs_read $params
/usr/lib64/libc-2.17.so (c31ffe7942bfd77b2fca8f9bd5709d387a86d3bc):
getaddrinfo $params
-
Note that $params requires debuginfo.
Signed-off-by: Masami Hiramatsu
Signed-off-by: Masami Hiramatsu
---
Changes in v7:
- Remove the top '/' from binary name if it is not a regular file.
---
tools/perf/Documentation/perf-probe.txt |8 ++-
tools/perf/builtin-probe.c |2 -
tools/perf/util/build-id.c | 86 ++-
tools/perf/util/build-id.h |3 +
tools/perf/util/probe-event.c |3 +
tools/perf/util/probe-file.c| 67 +++-
tools/perf/util/probe-file.h|1
7 files changed, 163 insertions(+), 7 deletions(-)
diff --git a/tools/perf/Documentation/perf-probe.txt
b/tools/perf/Documentation/perf-probe.txt
index 947db6f..5a70d45 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -67,7 +67,10 @@ OPTIONS
-l::
--list[=[GROUP:]EVENT]::
- List up current probe events. This can also accept filtering patterns
of event names.
+ List up current probe events. This can also accept filtering patterns of
+ event names.
+ When this is used with --cache, perf shows all cached probes instead of
+ the live probes.
-L::
--line=::
@@ -110,8 +113,9 @@ OPTIONS
adding and removal operations.
--cache::
- Cache the probes (with --add option). Any events which successfully
added
+ (With --add) Cache the probes. Any events which successfully added
are also stored in the cache file.
+ (With --list) Show cached probes.
--max-probes=NUM::
Set the maximum number of probe points for an event. Default is 128.
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 6d7ab431..53e380c0e 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -44,7 +44,7 @@
#define DEFAULT_VAR_FILTER "!__k???tab_* & !__crc_*"
#define DEFAULT_FUNC_FILTER "!_*"
-#define DEFAULT_LIST_FILTER "*:*"
+#define DEFAULT_LIST_FILTER "*"
/* Session management structure */
static struct {
diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index ccf0d0d..14fbd37 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -168,8 +168,7 @@ retry:
return NULL;
}
-static char *build_id_cache__linkname(const char *sbuild_id, char *bf,
- size_t size)
+char *build_id_cache__linkname(const char *sbuild_id, char *bf, size_t size)
{
char *tmp = bf;
int ret = asnprintf(&bf, size, "%s/.build-id/%.2s/%s", buildid_dir,
@@ -179,6 +178,36 @@ static char *build_id_cache__linkname(const char
*sbuild_id, char *bf,
return bf;
}
+char *build_id_cache__origname(const char *sbuild_id)
+{
+ char *linkname;
+ char buf[PATH_MAX];
+ char *ret = NULL, *p;
+ size_t offs = 5;/* == strlen("../..") */
+
+ linkname = build_id_cache__linkname(sbuild_id, NULL, 0);
+ if (!linkname)
+ return NULL;
+
+ if (readlink(linkname, buf, PATH_MAX) < 0)
+ goto out;
+ /* The link should be "../../" */
+ p = strrchr(buf, '/'); /* Cut off the "/" */
+ if (p && (p > buf + offs)) {
+ *p = '\0';
+ if (buf[offs + 1] == '[')
+ offs++; /*
+* This is a DSO name, like [kernel.kallsyms].
+* Skip the first '/', since this is not the
+* cache of a regular file.
+*/
+ ret = strdup(buf + offs); /* Skip "../..[/]" */
+ }
+out:
+ free(linkname);
+ return ret;
+}
+
static const char *build_id_cache__basename(bool is_kallsyms, bool is_vdso)
{
return is_kallsyms ? "kallsyms" : (is_vdso ? "vdso" : "elf");
@@ -390,6 +419,59 @@ void disable_buildid_cache(void)
no_buildid_cache = true;
}
+int build_id_cache__list_all(struct strlist **result)
+{
+ struct strlist *toplist, *list, *bidlist;
+ struct str_node *nd, *nd2;
+ char *topdir, *linkdir;
+ char sbuild_id[SBUILD_ID_SIZE];
+ int ret = 0;
+
+ /* Open the top-level directory */
+ if (asprintf(&topdir, "%s/.build-id/", buildid_dir) < 0)
+ return -errno;
+ toplist = lsdir(topdir, lsdir_no_dot_filter);
+ if (!toplist) {
+ pr_debug("Failed to opendir %s\n", topdir);
+ ret = -errn
[PATCH perf/core v8 09/16] perf probe: Add group name support
From: Masami Hiramatsu
Allow user to set group name for adding new event.
Note that user must ensure that the group name doesn't
conflict with existing group name carefully.
E.g. Existing group name can conflict with other events.
Especially, using the group name reserved for kernel
modules can hide kernel embedded events when loading
modules.
Signed-off-by: Masami Hiramatsu
Signed-off-by: Masami Hiramatsu
---
Changes in v4:
- Update Documentation/perf-probe.txt too.
---
tools/perf/Documentation/perf-probe.txt | 10 ++
tools/perf/util/probe-event.c | 23 ++-
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/tools/perf/Documentation/perf-probe.txt
b/tools/perf/Documentation/perf-probe.txt
index 8d09173..7a258e9 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -143,16 +143,18 @@ PROBE SYNTAX
Probe points are defined by following syntax.
1) Define event based on function name
- [EVENT=]FUNC[@SRC][:RLN|+OFFS|%return|;PTN] [ARG ...]
+ [[GROUP:]EVENT=]FUNC[@SRC][:RLN|+OFFS|%return|;PTN] [ARG ...]
2) Define event based on source file with line number
- [EVENT=]SRC:ALN [ARG ...]
+ [[GROUP:]EVENT=]SRC:ALN [ARG ...]
3) Define event based on source file with lazy pattern
- [EVENT=]SRC;PTN [ARG ...]
+ [[GROUP:]EVENT=]SRC;PTN [ARG ...]
-'EVENT' specifies the name of new event, if omitted, it will be set the name
of the probed function. Currently, event group name is set as 'probe'.
+'EVENT' specifies the name of new event, if omitted, it will be set the name
of the probed function. You can also specify a group name by 'GROUP', if
omitted, set 'probe' is used for kprobe and 'probe_' is used for uprobe.
+Note that using existing group name can conflict with other events.
Especially, using the group name reserved for kernel modules can hide embedded
events in the
+modules.
'FUNC' specifies a probed function name, and it may have one of the following
options; '+OFFS' is the offset from function entry address in bytes, ':RLN' is
the relative-line number from function entry line, and '%return' means that it
probes function return. And ';PTN' means lazy matching pattern (see LAZY
MATCHING). Note that ';PTN' must be the end of the probe point definition. In
addition, '@SRC' specifies a source file which has that function.
It is also possible to specify a probe point by the source line number or lazy
matching by using 'SRC:ALN' or 'SRC;PTN' syntax, where 'SRC' is the source file
path, ':ALN' is the line number and ';PTN' is the lazy matching pattern.
'ARG' specifies the arguments of this probe point, (see PROBE ARGUMENT).
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 57fd657..79da841 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1208,10 +1208,8 @@ static int parse_perf_probe_point(char *arg, struct
perf_probe_event *pev)
bool file_spec = false;
/*
*
-* perf probe [EVENT=]SRC[:LN|;PTN]
-* perf probe [EVENT=]FUNC[@SRC][+OFFS|%return|:LN|;PAT]
-*
-* TODO:Group name support
+* perf probe [GRP:][EVENT=]SRC[:LN|;PTN]
+* perf probe [GRP:][EVENT=]FUNC[@SRC][+OFFS|%return|:LN|;PAT]
*/
if (!arg)
return -EINVAL;
@@ -1220,11 +1218,19 @@ static int parse_perf_probe_point(char *arg, struct
perf_probe_event *pev)
if (ptr && *ptr == '=') { /* Event name */
*ptr = '\0';
tmp = ptr + 1;
- if (strchr(arg, ':')) {
- semantic_error("Group name is not supported yet.\n");
- return -ENOTSUP;
- }
+ ptr = strchr(arg, ':');
+ if (ptr) {
+ *ptr = '\0';
+ if (!is_c_func_name(arg))
+ goto not_fname;
+ pev->group = strdup(arg);
+ if (!pev->group)
+ return -ENOMEM;
+ arg = ptr + 1;
+ } else
+ pev->group = NULL;
if (!is_c_func_name(arg)) {
+not_fname:
semantic_error("%s is bad for event name -it must "
"follow C symbol-naming rule.\n", arg);
return -EINVAL;
@@ -1232,7 +1238,6 @@ static int parse_perf_probe_point(char *arg, struct
perf_probe_event *pev)
pev->event = strdup(arg);
if (pev->event == NULL)
return -ENOMEM;
- pev->group = NULL;
arg = tmp;
}
[PATCH perf/core v8 02/16] perf symbol: Cleanup the code flow of dso__find_kallsyms
Cleanup the code flow of dso__find_kallsyms() to remove
redundant checking code and add some comment for readability.
Signed-off-by: Masami Hiramatsu
---
Changes in v8:
- Add comments why we can't use access(R_OK) for /proc/kcore access.
---
tools/perf/util/symbol.c | 68 --
1 file changed, 35 insertions(+), 33 deletions(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 2252b54..abda8ba 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1641,6 +1641,20 @@ static int find_matching_kcore(struct map *map, char
*dir, size_t dir_sz)
return ret;
}
+/*
+ * Use open(O_RDONLY) to check readability directly instead of access(R_OK)
+ * since access(R_OK) only checks with real UID/GID but open() use effective
+ * UID/GID and actual capabilities (e.g. /proc/kcore requires CAP_SYS_RAWIO).
+ */
+static bool filename__readable(const char *file)
+{
+ int fd = open(file, O_RDONLY);
+ if (fd < 0)
+ return false;
+ close(fd);
+ return true;
+}
+
static char *dso__find_kallsyms(struct dso *dso, struct map *map)
{
u8 host_build_id[BUILD_ID_SIZE];
@@ -1660,45 +1674,36 @@ static char *dso__find_kallsyms(struct dso *dso, struct
map *map)
sizeof(host_build_id)) == 0)
is_host = dso__build_id_equal(dso, host_build_id);
- build_id__sprintf(dso->build_id, sizeof(dso->build_id), sbuild_id);
-
- scnprintf(path, sizeof(path), "%s/%s/%s", buildid_dir,
- DSO__NAME_KCORE, sbuild_id);
-
- /* Use /proc/kallsyms if possible */
+ /* Try a fast path for /proc/kallsyms if possible */
if (is_host) {
- DIR *d;
- int fd;
-
- /* If no cached kcore go with /proc/kallsyms */
- d = opendir(path);
- if (!d)
- goto proc_kallsyms;
- closedir(d);
-
/*
-* Do not check the build-id cache, until we know we cannot use
-* /proc/kcore.
+* Do not check the build-id cache, unless we know we cannot use
+* /proc/kcore or module maps don't match to /proc/kallsyms.
+* To check readability of /proc/kcore, do not use access(R_OK)
+* since /proc/kcore requires CAP_SYS_RAWIO to read and access
+* can't check it.
*/
- fd = open("/proc/kcore", O_RDONLY);
- if (fd != -1) {
- close(fd);
- /* If module maps match go with /proc/kallsyms */
- if (!validate_kcore_addresses("/proc/kallsyms", map))
- goto proc_kallsyms;
- }
-
- /* Find kallsyms in build-id cache with kcore */
- if (!find_matching_kcore(map, path, sizeof(path)))
- return strdup(path);
-
- goto proc_kallsyms;
+ if (filename__readable("/proc/kcore") &&
+ !validate_kcore_addresses("/proc/kallsyms", map))
+ goto proc_kallsyms;
}
+ build_id__sprintf(dso->build_id, sizeof(dso->build_id), sbuild_id);
+
/* Find kallsyms in build-id cache with kcore */
+ scnprintf(path, sizeof(path), "%s/%s/%s",
+ buildid_dir, DSO__NAME_KCORE, sbuild_id);
+
if (!find_matching_kcore(map, path, sizeof(path)))
return strdup(path);
+ /* Use current /proc/kallsyms if possible */
+ if (is_host) {
+proc_kallsyms:
+ return strdup("/proc/kallsyms");
+ }
+
+ /* Finally, find a cache of kallsyms */
scnprintf(path, sizeof(path), "%s/%s/%s",
buildid_dir, DSO__NAME_KALLSYMS, sbuild_id);
@@ -1709,9 +1714,6 @@ static char *dso__find_kallsyms(struct dso *dso, struct
map *map)
}
return strdup(path);
-
-proc_kallsyms:
- return strdup("/proc/kallsyms");
}
static int dso__load_kernel_sym(struct dso *dso, struct map *map,
[PATCH perf/core v8 01/16] perf buildid: Introduce DSO__NAME_KALLSYMS and DSO__NAME_KCORE
Instead of using raw string, use DSO__NAME_KALLSYMS and DSO__NAME_KCORE
macros for kallsyms and kcore.
Signed-off-by: Masami Hiramatsu
---
tools/perf/builtin-buildid-cache.c |8
tools/perf/util/annotate.c |2 +-
tools/perf/util/machine.c |2 +-
tools/perf/util/symbol.c | 10 +-
tools/perf/util/symbol.h |3 +++
5 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/tools/perf/builtin-buildid-cache.c
b/tools/perf/builtin-buildid-cache.c
index 632efc6..d75bded 100644
--- a/tools/perf/builtin-buildid-cache.c
+++ b/tools/perf/builtin-buildid-cache.c
@@ -119,8 +119,8 @@ static int build_id_cache__add_kcore(const char *filename,
bool force)
if (build_id_cache__kcore_buildid(from_dir, sbuildid) < 0)
return -1;
- scnprintf(to_dir, sizeof(to_dir), "%s/[kernel.kcore]/%s",
- buildid_dir, sbuildid);
+ scnprintf(to_dir, sizeof(to_dir), "%s/%s/%s",
+ buildid_dir, DSO__NAME_KCORE, sbuildid);
if (!force &&
!build_id_cache__kcore_existing(from_dir, to_dir, sizeof(to_dir))) {
@@ -131,8 +131,8 @@ static int build_id_cache__add_kcore(const char *filename,
bool force)
if (build_id_cache__kcore_dir(dir, sizeof(dir)))
return -1;
- scnprintf(to_dir, sizeof(to_dir), "%s/[kernel.kcore]/%s/%s",
- buildid_dir, sbuildid, dir);
+ scnprintf(to_dir, sizeof(to_dir), "%s/%s/%s/%s",
+ buildid_dir, DSO__NAME_KCORE, sbuildid, dir);
if (mkdir_p(to_dir, 0755))
return -1;
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 4db73d5..b811924 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1122,7 +1122,7 @@ int symbol__annotate(struct symbol *sym, struct map *map,
size_t privsize)
} else if (dso__is_kcore(dso)) {
goto fallback;
} else if (readlink(symfs_filename, command, sizeof(command)) < 0 ||
- strstr(command, "[kernel.kallsyms]") ||
+ strstr(command, DSO__NAME_KALLSYMS) ||
access(symfs_filename, R_OK)) {
free(filename);
fallback:
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 639a290..18dd96b 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -709,7 +709,7 @@ static struct dso *machine__get_kernel(struct machine
*machine)
if (machine__is_host(machine)) {
vmlinux_name = symbol_conf.vmlinux_name;
if (!vmlinux_name)
- vmlinux_name = "[kernel.kallsyms]";
+ vmlinux_name = DSO__NAME_KALLSYMS;
kernel = machine__findnew_kernel(machine, vmlinux_name,
"[kernel]", DSO_TYPE_KERNEL);
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 7fb3330..2252b54 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1662,8 +1662,8 @@ static char *dso__find_kallsyms(struct dso *dso, struct
map *map)
build_id__sprintf(dso->build_id, sizeof(dso->build_id), sbuild_id);
- scnprintf(path, sizeof(path), "%s/[kernel.kcore]/%s", buildid_dir,
- sbuild_id);
+ scnprintf(path, sizeof(path), "%s/%s/%s", buildid_dir,
+ DSO__NAME_KCORE, sbuild_id);
/* Use /proc/kallsyms if possible */
if (is_host) {
@@ -1699,8 +1699,8 @@ static char *dso__find_kallsyms(struct dso *dso, struct
map *map)
if (!find_matching_kcore(map, path, sizeof(path)))
return strdup(path);
- scnprintf(path, sizeof(path), "%s/[kernel.kallsyms]/%s",
- buildid_dir, sbuild_id);
+ scnprintf(path, sizeof(path), "%s/%s/%s",
+ buildid_dir, DSO__NAME_KALLSYMS, sbuild_id);
if (access(path, F_OK)) {
pr_err("No kallsyms or vmlinux with build-id %s was found\n",
@@ -1769,7 +1769,7 @@ do_kallsyms:
if (err > 0 && !dso__is_kcore(dso)) {
dso->binary_type = DSO_BINARY_TYPE__KALLSYMS;
- dso__set_long_name(dso, "[kernel.kallsyms]", false);
+ dso__set_long_name(dso, DSO__NAME_KALLSYMS, false);
map__fixup_start(map);
map__fixup_end(map);
}
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 2b5e4ed..25f2fd67 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -44,6 +44,9 @@ Elf_Scn *elf_section_by_name(Elf *elf, GElf_Ehdr *ep,
#define DMGL_ANSI(1 << 1) /* Include const, volatile, etc */
#endif
+#define DSO__NAME_KALLSYMS "[kernel.kallsyms]"
+#define DSO__NAME_KCORE"[kernel.kcore]"
+
/** struct symbol - symtab entry
*
* @ignore - resolvable but tools ignore it (e.g. idle routines)
[PATCH perf/core v8 00/16] perf-probe --cache and SDT support
Hi, Here is the 8th version of the patchset for probe-cache and initial SDT support. The previous version is here; https://lkml.org/lkml/2016/5/11/446 This version I droped the second patch in v7 because it may involves unintended behavior change and we'd better discuss it out of this series. I also added comments why we can't use access(R_OK) for /proc/kcore. Hemant, could you review and test this series so that we can proceed to your patch depending on this? Thank you, --- Hemant Kumar (1): perf/sdt: ELF support for SDT Masami Hiramatsu (15): perf buildid: Introduce DSO__NAME_KALLSYMS and DSO__NAME_KCORE perf symbol: Cleanup the code flow of dso__find_kallsyms perf-buildid-cache: Use path/to/bin/buildid/elf instead of path/to/bin/buildid perf probe: Add --cache option to cache the probe definitions perf probe: Use cache entry if possible perf probe: Show all cached probes perf probe: Remove caches when --cache is given perf probe: Add group name support perf buildid-cache: Scan and import user SDT events to probe cache perf probe: Accept %sdt and %cached event name perf-list: Show SDT and pre-cached events perf-list: Skip SDTs placed in invalid binaries perf probe: Allow wildcard for cached events perf probe: Support @BUILDID or @FILE suffix for SDT events perf probe: Support a special SDT probe format tools/perf/Documentation/perf-probe.txt | 26 +- tools/perf/builtin-buildid-cache.c |8 tools/perf/builtin-list.c |4 tools/perf/builtin-probe.c | 30 ++ tools/perf/util/annotate.c |2 tools/perf/util/build-id.c | 295 -- tools/perf/util/build-id.h |8 tools/perf/util/dso.h |5 tools/perf/util/machine.c |2 tools/perf/util/parse-events.c | 83 + tools/perf/util/parse-events.h |2 tools/perf/util/probe-event.c | 492 +++--- tools/perf/util/probe-event.h |7 tools/perf/util/probe-file.c| 502 +++ tools/perf/util/probe-file.h| 41 +++ tools/perf/util/symbol-elf.c| 252 tools/perf/util/symbol.c| 73 ++--- tools/perf/util/symbol.h| 25 ++ 18 files changed, 1719 insertions(+), 138 deletions(-) -- Masami Hiramatsu
[PATCH] scripts/package/Makefile: rpmbuild add support of RPMOPTS
After commit 21a59991ce0c ("scripts/package/Makefile: rpmbuild is needed
for rpm targets"), it is no longer possible to specify RPMOPTS.
For example, we can no longer able to control _topdir using the following
make command.
make RPMOPTS="--define '_topdir /home/xyz/workspace/'" binrpm-pkg
Fixes: 21a59991ce0c ("scripts/package/Makefile: rpmbuild is needed
for rpm targets")
Cc: # 4.3+
Signed-off-by: Srinivas Pandruvada
---
scripts/package/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/package/Makefile b/scripts/package/Makefile
index c2c7389..71b4a8a 100644
--- a/scripts/package/Makefile
+++ b/scripts/package/Makefile
@@ -52,7 +52,7 @@ rpm-pkg rpm: FORCE
$(call cmd,src_tar,$(KERNELPATH),kernel.spec)
$(CONFIG_SHELL) $(srctree)/scripts/mkversion > $(objtree)/.tmp_version
mv -f $(objtree)/.tmp_version $(objtree)/.version
- rpmbuild --target $(UTS_MACHINE) -ta $(KERNELPATH).tar.gz
+ rpmbuild $(RPMOPTS) --target $(UTS_MACHINE) -ta $(KERNELPATH).tar.gz
rm $(KERNELPATH).tar.gz kernel.spec
# binrpm-pkg
@@ -63,7 +63,7 @@ binrpm-pkg: FORCE
$(CONFIG_SHELL) $(srctree)/scripts/mkversion > $(objtree)/.tmp_version
mv -f $(objtree)/.tmp_version $(objtree)/.version
- rpmbuild --define "_builddir $(objtree)" --target \
+ rpmbuild $(RPMOPTS) --define "_builddir $(objtree)" --target \
$(UTS_MACHINE) -bb $(objtree)/binkernel.spec
rm binkernel.spec
--
2.5.5
Re: Unclear BSD licensing (headers, MODULE_LICENSE, versions)
On Sun, May 15, 2016 at 12:44:35AM +0200, Rafał Miłecki wrote: > > I recently received a hint that it would be nice/expected to have DTS > files licensed under BSD. I had no experience with BSD, so I started > looking at this and the way kernel parts use it. There is a lot of sloppiness in some of the driver code. Unfortunately, fixing it is something that really has to be done by the copyright holder, or whoever submitted the kernel in the first place and who has clear knowledge of what the copyright holder had intended. There is also a fairly wide range of seriousness of the various defects you've listed. On one extreme, although it's true that some license, such as the ClearBSD license has in its template, when the original code file you've referenced has in its header: * Copyright 2004-2012 Analog Devices Inc. * Licensed under the Clear BSD license. tt's pretty obvious that Organization should be "Analog Devices Inc". In other cases, it's pretty clear that someone copied the drivers from some out-of-tree distribution (e.g., "see kernel-base/COPYING...") and where finding the original distribution and then adding the Copyright permission statement is a pretty easy thing to do. (And in case where a third party can easily show proof that the intent of the copyright holder is clearly expressed, that third party probably is able to submit a patch to fix up the source file. > I'm wondering how we could improve this situation. I got 2 main ideas: > > 1) Extend MODULE_LICENSE > We could add new acceptable entries specifying BSD version. We could > try to improve checkpatch.pl to look for a full license in a header > (it seems to be required as it has to provide ). Maybe > we could figure out (with some lawyers?) how to treat sources using > "Dual BSD/GPL" mentioning GPL only (without BSD) in their header. I'm not a fan of this approach. MODULE_LICENSE puts a hint about the copyright license of a module where it can be found by the module loader. This is useful to enforce things like GPL_SYMBOL_EXPORT, but I don't think we should try to make MODULE_LICESE to be more than that. > 2) Get clear rules on how to write a header > If you find extending MODULE_LICENSE a bad idea, maybe we can simply > help people write proper headers. Explain the problem, provide > examples, maybe add some check in checkpatch.pl. Adding more text about how to add a proper copyright notice and license permission statement to the SubmittingDrivers file seems like a good idea. I doubt we can make checkpatch.pl smart enough to handle this situation cleanly. Cheers, - Ted
Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems
James Bottomley writes: > On Sat, 2016-05-14 at 10:53 +0100, Djalal Harouni wrote: Just a couple of quick comments from a very high level design point. - I think a shiftfs is valuable in the same way that overlayfs is valuable. Esepcially in the Docker case where a lot of containers want a shared base image (for efficiency), but it is desirable to run those containers in different user namespaces for safety. - It is also the plan to make it possible to mount a filesystem where the uids and gids of that filesystem on disk do not have a one to one mapping to kernel uids and gids. 99% of the work has already be done, for all filesystem except XFS. That said there are some significant issues to work through, before something like that can be enabled. * Handling of uids/gids on disk that don't map into a kuid/kgid. * Safety from poisoned filesystem images. I have slowly been working with Seth Forshee on these issues as the last thing I want is to introduce more security bugs right now. Seth being a braver man than I am has already merged his changes into the Ubuntu kernel. Right now we are targeting fuse, because fuse is already designed to handle poisoned filesystem images. So to safely enable this kind of mapping for fuse is not a giant step. The big thing from my point of view is to get the VFS interfaces correct so that the VFS handles all of the weird cases that come up with uids and gids that don't map, and any other weird cases. Keeping the weird bits out of the filesystems. James, Djalal I regert I have not been able to read through either of your patches cloesely yet. From a high level view I believe there are use cases for both approaches, and the use cases do not necessarily overlap. Djalal I think you are seeing the upsides and not the practical dangers of poisoned filesystem images. James I think you are missing the fact that all filesystems already have the make_kuid and make_kgid calls right where the data comes off disk, and the from_kuid and from_kgid calls right where the on-disk data is being created just before it goes on disk. Which means that the actual impact on filesystems of the translation is trivial. Where the actual impact of filesystems is much higher is the infrastructure needed to ensure poisoned filesystem images do not cause a kernel compromise. That extends to the filesystem testing and code review process beyond and is more than just a kernel problem. Hardening that attack surface of the disk side of filesystems is difficult especially when not impacting filesystem performance. So I don't think it makes sense to frame this as an either/or situation. I think there is a need for both solutions. Djalal if you could work with Seth I think that would be very useful. I know I am dragging my heels there but I really hope I can dig in and get everything reviewed and merged soonish. James if you could see shiftfs with a different set of merits than what to Djalal is doing I think that would be useful. As it would allow everyone to concentrate on getting the bugs out of their solutions. That said I am not certain shiftfs makes sense without Seth's patches to handle the weird cases at the VFS level.What do you do with uids and gids that don't map? You can reinvent how to handle the strange cases in shfitfs or we can work on solving this problem at the VFS level so people don't have to go through the error prone work of reinventing solutions. The big ugly nasty in all of this is that we are fundamentally dealing with uids and gids which are security identifiers. Practically any bug is exploitable and CVE worthy. So it make sense to tread very carefully. Even with care it can takes months if not years to get the number of bugs down to a level where you are not the favorite target of people looking for exploitable kernel bugs. Eric
Re: [PATCH 1/1 v2] hwmon: add support for Sensirion SHT3x sensors
On 04/25/2016 01:42 AM, Pascal Sachs wrote: From: David Frey This driver implements support for the Sensirion SHT3x-DIS chip, a humidity and temperature sensor. Temperature is measured in degrees celsius, relative humidity is expressed as a percentage. In the sysfs interface, all values are scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500. Signed-off-by: Pascal Sachs --- Patch was generated against kernel v4.6-rc5 Documentation/hwmon/sht3x | 66 drivers/hwmon/Kconfig | 10 + drivers/hwmon/Makefile | 1 + drivers/hwmon/sht3x.c | 675 drivers/hwmon/twl4030-madc-hwmon.c | 1 + Please drop this change. include/linux/platform_data/sht3x.h | 25 ++ 6 files changed, 778 insertions(+) create mode 100644 Documentation/hwmon/sht3x create mode 100644 drivers/hwmon/sht3x.c create mode 100644 include/linux/platform_data/sht3x.h Please run checkpatch --strict over your patch. There are lots of unnecessary/undesirable empty lines and spaces. It would also tell you about the presumably left-over FIXME in twl4030-madc-hwmon.c. diff --git a/Documentation/hwmon/sht3x b/Documentation/hwmon/sht3x new file mode 100644 index 000..c04748d --- /dev/null +++ b/Documentation/hwmon/sht3x @@ -0,0 +1,66 @@ +Kernel driver sht3x +=== + +Supported chips: + * Sensirion SHT3x-DIS +Prefix: 'sht3x' +Addresses scanned: none +Datasheet: http://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/Humidity/Sensirion_Humidity_Datasheet_SHT3x_DIS.pdf + +Author: + David Frey + Pascal Sachs + +Description +--- + +This driver implements support for the Sensirion SHT3x-DIS chip, a humidity +and temperature sensor. Temperature is measured in degrees celsius, relative +humidity is expressed as a percentage. In the sysfs interface, all values are +scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500. + +The device communicates with the I2C protocol. Sensors can have the I2C +addresses 0x44 or 0x45, depending on the wiring. See +Documentation/i2c/instantiating-devices for methods to instantiate the device. + +There are two options configurable by means of sht3x_platform_data: +1. blocking (pull the I2C clock line down while performing the measurement) or + non-blocking mode. Blocking mode will guarantee the fastest result but + the I2C bus will be busy during that time. By default, non-blocking mode + is used. Make sure clock-stretching works properly on your device if you + want to use blocking mode. +2. high or low accuracy. High accuracy is used by default and using it is + strongly recommended. + +The sht3x sensor supports a single shot mode as well as 5 periodic measure +modes, which can be controlled with the frequency sysfs interface. +The allowed frequencies are as follows: + * 0 single shot mode + * 500 0.5 Hz periodic measurement + * 1000 1 Hz periodic measurement + * 2000 2 Hz periodic measurement + * 4000 4 Hz periodic measurement + * 1 10 Hz periodic measurement + +While in periodic measure mode, read out of humidity and temperature values are +not supported. Nevertheless it is possible to read out the values with maximal Really ? I seem to be missing this in the datasheet. Section 4.4 suggests that both are supported. Besides, this would be really odd - what would be the point of periodic mode (or any mode, for that matter) if it doesn't really measure anything ? +the same frequency as the periodic measure mode. This text does not really make sense to me. Should one of those "periodic" be "single shot" ? + +sysfs-Interface +--- + +temp1_input:temperature input +humidity1_input:humidity input +temp1_max: temperature max value +temp1_max_hyst: temperature hysteresis value for max limit +humidity1_max: humidity max value +humidity1_max_hyst: humidity hysteresis value for max limit +temp1_min: temperature min value +temp1_min_hyst: temperature hysteresis value for min limit +humidity1_min: humidity min value +humidity1_min_hyst: humidity hysteresis value for min limit +frequency: Measurement frequency, 0 for single shot, frequency in +mHz for periodic measurement Please use standard attributes (update_interval). +soft_reset: Soft reset the internal state of the sensor, clear the +status register, clear the alert and switch back to +single shot mode Makes me really unhappy. It is not a standard attribute, there is no clear indication why it is needed, and it affects other attributes (mode) without updating the command pointer, thus probably breaking things. In general, if the chip is that unstable that it needs to be reset once in a while, that should be auto-detected if possible and be handled automatically. A manual "please reset me
[PATCH] Staging: android: ion: fixed a kzalloc coding style issue.
Fixed a coding style issue. Issue reported by checkpatch.pl. Signed-off-by: Shubham Bansal --- drivers/staging/android/ion/ion.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 8536567..2217ccb 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -184,7 +184,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap *heap, struct scatterlist *sg; int i, ret; - buffer = kzalloc(sizeof(struct ion_buffer), GFP_KERNEL); + buffer = kzalloc(sizeof(*buffer), GFP_KERNEL); if (!buffer) return ERR_PTR(-ENOMEM); -- 2.1.4
Re: [PATCH] ftrace/x86: Fix function graph tracer reset path
Hi Namhyung, I'm interested in this problem, and it seems compiling environment related or kconfig related problem. If you can reproduce this kernel, would you share what the "AS" commandline shows? That can be done as below; $ make V=1 arch/x86/kernel/mcount_64.o | grep mcount_64 Thank you, On Fri, 13 May 2016 22:53:43 +0900 Namhyung Kim wrote: > On my system, simply enabling and disabling function graph tracer can > crash the kernel. I don't know how it worked until now. > > The ftrace_disable_ftrace_graph_caller() modifies jmp instruction at > ftrace_graph_call assuming it's a 5 bytes near jmp (e9 ). > However it's a short jmp consisting of 2 bytes only (eb ). And > ftrace_stub() is located just below the ftrace_graph_caller so > modification above breaks the instruction resulting in kernel oops on > the ftrace_stub() with the invalid opcode like below: > > # cd /sys/kernel/trace > # echo function_graph > current_tracer > # echo nop > current_tracer > > [ 78.122055] invalid opcode: [#1] SMP > [ 78.125125] Modules linked in: x86_pkg_temp_thermal kvm_intel kvm > irqbypass crc32c_intel pcspkr iwldvm iwlwifi > [ 78.128241] CPU: 2 PID: 17 Comm: migration/2 Not tainted 4.6.0-rc4+ #36 > [ 78.131310] Hardware name: LENOVO 4286A74/4286A74, BIOS 8DET56WW (1.26 ) > 12/01/2011 > [ 78.134369] task: 88040bec4240 ti: 88040bee4000 task.ti: > 88040bee4000 > [ 78.137412] RIP: 0010:[] [] > ftrace_stub+0x0/0x8 > [ 78.140477] RSP: 0018:88040bee7e48 EFLAGS: 00010246 > [ 78.143489] RAX: 88040bec4240 RBX: 8107a7b0 RCX: > 001f > [ 78.146512] RDX: RSI: 88041e2929d8 RDI: > 88040bee7e50 > [ 78.149581] RBP: 88040bee7e80 R08: 88040bee4000 R09: > > [ 78.152647] R10: 000318b7 R11: 8800d661f800 R12: > 88040d8011b0 > [ 78.155679] R13: 81e43620 R14: 88040bda8588 R15: > 81e503e0 > [ 78.158675] FS: () GS:88041e28() > knlGS: > [ 78.161699] CS: 0010 DS: ES: CR0: 80050033 > [ 78.164690] CR2: 7fadb22dde1d CR3: d5ce2000 CR4: > 000406e0 > [ 78.167691] Stack: > [ 78.170658] 8110b3ee 8188de90 0009161d55f6 > 0012306fc2e4 > [ 78.173710] 8804 88040bec4240 > 88040bee7ec8 > [ 78.176783] 81893bbd 88040bec4240 > 81893ba8 > [ 78.179863] Call Trace: > [ 78.182853] [] ? ftrace_return_to_handler+0x8e/0x100 > [ 78.185909] [] ? __schedule+0xae0/0xae0 > [ 78.188941] [] return_to_handler+0x15/0x27 > [ 78.192001] [] ? ftrace_graph_caller+0xa8/0xa8 > [ 78.195091] [] ? sort_range+0x30/0x30 > [ 78.198138] [] kthread+0xc9/0xe0 > [ 78.201143] [] ret_from_fork+0x22/0x40 > [ 78.204138] [] ? kthread_worker_fn+0x170/0x170 > [ 78.207129] Code: 8b 44 24 48 48 8b 7c 24 70 48 8b 74 24 68 48 8b 54 24 > 60 >48 8b 4c 24 58 48 8b 44 24 50 48 8b 6c 24 20 48 81 c4 > d0 >00 00 00 e9 fd ff ff 80 00 00 00 00 9c 55 ff 74 > 24 18 >55 48 89 e5 ff 74 24 > [ 78.213997] RIP [] ftrace_stub+0x0/0x8 > [ 78.217190] RSP > [ 78.220374] ---[ end trace 0af2f0d9f7301011 ]--- > > Looking at the code dump, the ftrace_stub instruction was overwritten as > . Below is disassembly output of related code. > > $ objdump -d --start-address=0x818939a6 > --stop-address=0x818939b0 vmlinux > > vmlinux: file format elf64-x86-64 > > Disassembly of section .text: > > 818939a6 : > 818939a6: eb 00 jmp818939a8 > > > 818939a8 : > 818939a8: c3 retq > 818939a9: 0f 1f 80 00 00 00 00nopl 0x0(%rax) > > As you can see ftrace_epilogue (same as ftrace_graph_caller) is 2 byte > ahead of ftrace_stub. And it's replaced by a jump to ftrace_stub() by > ftrace_disable_ftrace_graph_caller: "e9 <0xfffd>". Pads 3 bytes > after ftrace_epilogue to prevent ftrace_stub from being overwritten. > > Signed-off-by: Namhyung Kim > --- > arch/x86/kernel/mcount_64.S | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/arch/x86/kernel/mcount_64.S b/arch/x86/kernel/mcount_64.S > index ed48a9f465f8..0e6af57a713a 100644 > --- a/arch/x86/kernel/mcount_64.S > +++ b/arch/x86/kernel/mcount_64.S > @@ -180,6 +180,15 @@ GLOBAL(ftrace_epilogue) > #ifdef CONFIG_FUNCTION_GRAPH_TRACER > GLOBAL(ftrace_graph_call) > jmp ftrace_stub > + /* > + * The above jmp is generated as a short jump which occupies 2 bytes > + * but ftrace_enable/disable_ftrace_graph_caller() assumes it's a > + * near jump which occupies 5 bytes so breaks ftrace_stub() below. > + * Add 3 bytes padding to avoid that. > + */ > +
Re: [PATCH 3.14 01/23] compiler-gcc: integrate the various compiler-gcc[345].h files
On Wed, May 11, 2016 at 11:27:10AM +0200, Jiri Slaby wrote: > On 05/09/2016, 09:17 AM, Greg Kroah-Hartman wrote: > > 3.14-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Joe Perches > > > > commit f320793e52aee78f0fbb8bcaf10e6614d2e67bfc upstream. > > > > [ Upstream commit cb984d101b30eb7478d32df56a0023e4603cba7f ] > > The former SHA seems to be bogus. Hm, I got it a bit wrong, it's in the linux-stable tree, not Linus's tree, sorry for the confusion. greg k-h
Unclear BSD licensing (headers, MODULE_LICENSE, versions)
Hi, I recently received a hint that it would be nice/expected to have DTS files licensed under BSD. I had no experience with BSD, so I started looking at this and the way kernel parts use it. Obviously Linux kernel is licensed under GPLv2, so all its code has to use GPLv2 compatible license. I found 3 BSD licenses in use by kernel code: 1) BSD 3-clause license 2) BSD 2-clause license 3) Clear BSD license Unfortunately in many cases (of source files) I wasn't able to clearly determine used BSD license. First of all, an accepted ident "Dual BSD/GPL" doesn't specify BSD version. All I can read in include/linux/module.h is "[GNU Public License v2 or BSD license choice]". It could mean any (of GPLv2 compatible) BSD versions. I guess ideally (in current situation) every file using "Dual BSD/GPL" should specify BSD license version in a header. However this isn't the case. 1) Some "Dual BSD/GPL" sources mention GPL in a header forgetting about BSD. Can we treat such files as BSD-licensed at all? Few examples: arch/arm/mach-pxa/am300epd.c drivers/fmc/fmc-trivial.c drivers/net/ppp/ppp_deflate.c drivers/scsi/a100u2w.c drivers/xen/xen-scsiback.c 2) Some "Dual BSD/GPL" sources don't specify BSD version in a header. E.g. all you can find in a header is "All rights reserved. Licensed under dual BSD/GPL license.". Two examples: drivers/char/pcmcia/cm4000_cs.c drivers/char/pcmcia/cm4040_cs.c Another problem is text of BSD license 1) Some BSD 2-clause licensed sources don't link to its content. In case of GPLv2 some sources simply mention this license and refer to COPYING. Few examples: a) drivers/bcma/main.c "Licensed under the GNU/GPL. See COPYING for details." b) drivers/block/umem.c "This driver is released to the public under the terms of the GNU GENERAL PUBLIC LICENSE version 2 c) drivers/mfd/tps6507x.c "For licencing details see kernel-base/COPYING" I believe the same could be done for BSD 2-clause license, however there is no file that can be pointed. It results in some sources specifying 2-clause license in a header without really providing the content. Example: arch/arm/boot/dts/lpc4350.dtsi 2) Some BSD 3-clause or Clear BSD licensed sources don't provide needed text Many templates of BSD 3-clause license I found contain that should be replaced by a proper organization/company. That makes me suspect we can't have a generic text of BSD 3-clause or Clear BSD in any shared file like COPYING. However there are sources that specify one of above licenses without providing or linking its text. Few examples: arch/blackfin/mach-bf609/include/mach/anomaly.h drivers/block/zram/zram_drv.c I'm wondering how we could improve this situation. I got 2 main ideas: 1) Extend MODULE_LICENSE We could add new acceptable entries specifying BSD version. We could try to improve checkpatch.pl to look for a full license in a header (it seems to be required as it has to provide ). Maybe we could figure out (with some lawyers?) how to treat sources using "Dual BSD/GPL" mentioning GPL only (without BSD) in their header. 2) Get clear rules on how to write a header If you find extending MODULE_LICENSE a bad idea, maybe we can simply help people write proper headers. Explain the problem, provide examples, maybe add some check in checkpatch.pl. What do you think about this? -- Rafał
Re: [RFC][PATCH] printk: Add option to append kernel version to the dict
On Fri, May 13, 2016 at 10:58 PM, Calvin Owens wrote: > We use netconsole to collect kernel logs from all the servers at > Facebook. We use this patch internally so each logline has a record of > which kernel version emitted it. > > At first glance, this might seem lazy: as you would expect, we have a > database which records which kernel version a host is currently running. > But there are a lot of situations where that database cannot be current: > early-ish boot crashes are probably the best example, but even beyond > that there are lots of varieties of kernel brokenness that can prevent > the database from being updated. Doing it explicitly this way ensures > that we always know exactly what version emitted a given message. > > Doing it in printk() itself rather than extended netconsole ends up > being much simpler, and has the advantage that future extended console > implementations will be able to benefit from this as well. > > Signed-off-by: Calvin Owens > --- > init/Kconfig | 8 > kernel/printk/printk.c | 14 ++ > 2 files changed, 22 insertions(+) I don't think adding a new config option is appropriate. How about adding a log format string tunable to netconsole? -- Thanks, //richard
Re: [PATCH RFT 1/2] phylib: add device reset GPIO support
Hello. On 05/14/2016 10:50 PM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the individual resets only. This actually needs to be addresses a layer above. What you have is a bus reset, not a device reset. No. There's simply no such thing as a bus reset for the xMII/MDIO busses, there's simply no reset signaling on them. Every device has its own reset signal and its own timing requirements. Except in the case above, where two phys are sharing the same reset signal. So although it is not part of the mdio standard to have a bus reset, this is in effect what the gpio line is doing, resetting all devices on the bus. If you don't model that as a bus reset, how do you model it? I'm not suggesting that the shared reset should be handled by my patch. Contrariwise, I suggested to use the mii_bus::reset() method I think we miss understood each other somewhere. Your code is great for one gpio reset line for one phy. I think there could be similar code one layer above to handle one gpio line for multiple phys. Ah, you want me to recognize some MAC/MDIO bound prop (e.g. "mdio-reset-gpios") in of_mdiobus_register()? I'll think about it now that my patch needs fixing anyway... Andrew MBR, Sergei
[PATCH v4 2/4] ASoC: MAX9860: new driver
This is a driver for the MAX9860 Mono Audio Voice Codec.
https://datasheets.maximintegrated.com/en/ds/MAX9860.pdf
This driver does not support sidetone since the DVST register field is
backwards with the mute near the maximum level instead of the minimum.
Signed-off-by: Peter Rosin
---
MAINTAINERS| 7 +
sound/soc/codecs/Kconfig | 6 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/max9860.c | 753 +
sound/soc/codecs/max9860.h | 162 ++
5 files changed, 930 insertions(+)
create mode 100644 sound/soc/codecs/max9860.c
create mode 100644 sound/soc/codecs/max9860.h
diff --git a/MAINTAINERS b/MAINTAINERS
index a727d9959ecd..e433bc54eba2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7000,6 +7000,13 @@ F:
Documentation/devicetree/bindings/i2c/max6697.txt
F: drivers/hwmon/max6697.c
F: include/linux/platform_data/max6697.h
+MAX9860 MONO AUDIO VOICE CODEC DRIVER
+M: Peter Rosin
+L: alsa-de...@alsa-project.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/sound/max9860.txt
+F: sound/soc/codecs/max9860.*
+
MAXIM MUIC CHARGER DRIVERS FOR EXYNOS BASED BOARDS
M: Krzysztof Kozlowski
L: linux...@vger.kernel.org
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 7ef3a0c16478..241a23c9aa9f 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -83,6 +83,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MAX98925 if I2C
select SND_SOC_MAX98926 if I2C
select SND_SOC_MAX9850 if I2C
+ select SND_SOC_MAX9860 if I2C
select SND_SOC_MAX9768 if I2C
select SND_SOC_MAX9877 if I2C
select SND_SOC_MC13783 if MFD_MC13XXX
@@ -534,6 +535,11 @@ config SND_SOC_MAX98926
config SND_SOC_MAX9850
tristate
+config SND_SOC_MAX9860
+ tristate "Maxim MAX9860 Mono Audio Voice Codec"
+ depends on I2C
+ select REGMAP_I2C
+
config SND_SOC_PCM1681
tristate "Texas Instruments PCM1681 CODEC"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 185a712a7fe7..e435f4df1787 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -78,6 +78,7 @@ snd-soc-max9867-objs := max9867.o
snd-soc-max98925-objs := max98925.o
snd-soc-max98926-objs := max98926.o
snd-soc-max9850-objs := max9850.o
+snd-soc-max9860-objs := max9860.o
snd-soc-mc13783-objs := mc13783.o
snd-soc-ml26124-objs := ml26124.o
snd-soc-nau8825-objs := nau8825.o
@@ -287,6 +288,7 @@ obj-$(CONFIG_SND_SOC_MAX9867) += snd-soc-max9867.o
obj-$(CONFIG_SND_SOC_MAX98925) += snd-soc-max98925.o
obj-$(CONFIG_SND_SOC_MAX98926) += snd-soc-max98926.o
obj-$(CONFIG_SND_SOC_MAX9850) += snd-soc-max9850.o
+obj-$(CONFIG_SND_SOC_MAX9860) += snd-soc-max9860.o
obj-$(CONFIG_SND_SOC_MC13783) += snd-soc-mc13783.o
obj-$(CONFIG_SND_SOC_ML26124) += snd-soc-ml26124.o
obj-$(CONFIG_SND_SOC_NAU8825) += snd-soc-nau8825.o
diff --git a/sound/soc/codecs/max9860.c b/sound/soc/codecs/max9860.c
new file mode 100644
index ..2b0dd6a18dad
--- /dev/null
+++ b/sound/soc/codecs/max9860.c
@@ -0,0 +1,753 @@
+/*
+ * Driver for the MAX9860 Mono Audio Voice Codec
+ *
+ * https://datasheets.maximintegrated.com/en/ds/MAX9860.pdf
+ *
+ * The driver does not support sidetone since the DVST register field is
+ * backwards with the mute near the maximum level instead of the minimum.
+ *
+ * Author: Peter Rosin
+ * Copyright 2016 Axentia Technologies
+ *
+ * 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.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "max9860.h"
+
+struct max9860_priv {
+ struct regmap *regmap;
+ struct regulator *dvddio;
+ struct notifier_block dvddio_nb;
+ u8 psclk;
+ unsigned long pclk_rate;
+ int fmt;
+};
+
+static int max9860_dvddio_event(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct max9860_priv *max9860 = container_of(nb, struct max9860_priv,
+ dvddio_nb);
+ if (event & REGULATOR_EVENT_DISABLE) {
+ regcache_mark_dirty(max9860->regmap);
+ regcache_cache_only(max9860->regmap, true);
+ }
+
+ return 0;
+}
+
+static const struct reg_default max9860_reg_defaults[] = {
+ { MAX9860_PWRMAN, 0x00 },
+ { MAX9860_INTEN,0x00 },
+ { MAX9860_SYSCL
[PATCH v4 3/4] ASoC: dapm: support mixer controls with mute at non-zero value
The max9860 codec has a mixer control field that has its mute/disable at
the wrong end of the scale. I.e. you turn the volume up and up, and then
as the final step the volume is off. This does not sit well with DAPM,
which assumes the mute/off is at the minimum value.
Add support for such backwards controls with code that searches TLV ranges
for the mute value and use that as trigger for DAPM off.
Signed-off-by: Peter Rosin
---
sound/soc/soc-dapm.c | 38 +++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index c4464858bf01..8a1131781339 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
@@ -722,16 +723,46 @@ static int dapm_connect_mux(struct snd_soc_dapm_context
*dapm,
return -ENODEV;
}
+static int dapm_find_tlv_mute(const unsigned int *tlv)
+{
+ int cnt;
+ const unsigned int *range;
+
+ if (!tlv || tlv[0] != SNDRV_CTL_TLVT_DB_RANGE)
+ return 0;
+
+ cnt = tlv[1] / sizeof(unsigned int);
+
+ /*
+* Each group of six values should be
+* { start end type len min step/mute }
+*/
+ for (range = &tlv[2]; cnt >= 6; cnt -= 6, range += 6) {
+ if (range[2] != SNDRV_CTL_TLVT_DB_SCALE)
+ return 0; /* wrong type, terminate */
+ if (range[3] != 2 * sizeof(unsigned int))
+ return 0; /* wrong len, terminate */
+ if (!(range[5] & TLV_DB_SCALE_MUTE))
+ continue; /* no mute in this range */
+ return range[0]; /* start of this range is the mute value */
+ }
+
+ return 0;
+}
+
/* set up initial codec paths */
static void dapm_set_mixer_path_status(struct snd_soc_dapm_path *p, int i)
{
+ const struct snd_kcontrol_new *kcontrol_new
+ = &p->sink->kcontrol_news[i];
struct soc_mixer_control *mc = (struct soc_mixer_control *)
- p->sink->kcontrol_news[i].private_value;
+ kcontrol_new->private_value;
unsigned int reg = mc->reg;
unsigned int shift = mc->shift;
unsigned int max = mc->max;
unsigned int mask = (1 << fls(max)) - 1;
unsigned int invert = mc->invert;
+ int mute_value = dapm_find_tlv_mute(kcontrol_new->tlv.p);
unsigned int val;
if (reg != SND_SOC_NOPM) {
@@ -739,7 +770,7 @@ static void dapm_set_mixer_path_status(struct
snd_soc_dapm_path *p, int i)
val = (val >> shift) & mask;
if (invert)
val = max - val;
- p->connect = !!val;
+ p->connect = val != mute_value;
} else {
p->connect = 0;
}
@@ -3045,6 +3076,7 @@ int snd_soc_dapm_put_volsw(struct snd_kcontrol *kcontrol,
int max = mc->max;
unsigned int mask = (1 << fls(max)) - 1;
unsigned int invert = mc->invert;
+ int mute_value = dapm_find_tlv_mute(kcontrol->tlv.p);
unsigned int val;
int connect, change, reg_change = 0;
struct snd_soc_dapm_update update;
@@ -3056,7 +3088,7 @@ int snd_soc_dapm_put_volsw(struct snd_kcontrol *kcontrol,
kcontrol->id.name);
val = (ucontrol->value.integer.value[0] & mask);
- connect = !!val;
+ connect = val != mute_value;
if (invert)
val = max - val;
--
2.1.4
[PATCH v4 0/4] ASoC: MAX9860: new driver
Hi! I kept the sidetone changes in separate patches since I don't know if I solved the DAPM-off issue cleanly enough. Also, a new driver may still have a chance to make 4.7, but maybe it's too late for the DAPM changes? Finally, I wonder if the device tree crowd prefers seeing the whole of a series such as this, or only the bindings patch? Cheers, Peter New in v4: - Split out the device tree bindings in its own patch. - Move format check from ->startup to ->set_fmt. - Don't spam the log on probe defer. - Follow-up patches for the backwards sidetone control. New in v3: - The updated bindings file went missing in v2. Sorry for the confusion. New in v2: - Add comment about fall through when Integer Clock Mode is not possible. - Drop export of max9860_probe. - Ignore clk docs and read the mclk rate w/o enabling the clock. - Manage the DVDDIO supply. Peter Rosin (4): dt-bindings: sound: add bindings for the max9860 codec ASoC: MAX9860: new driver ASoC: dapm: support mixer controls with mute at non-zero value ASoC: MAX9860: add sidetone mixer control .../devicetree/bindings/sound/max9860.txt | 28 + MAINTAINERS| 7 + sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/max9860.c | 765 + sound/soc/codecs/max9860.h | 162 + sound/soc/soc-dapm.c | 38 +- 7 files changed, 1005 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/max9860.txt create mode 100644 sound/soc/codecs/max9860.c create mode 100644 sound/soc/codecs/max9860.h -- 2.1.4
Re: [PATCH net-next] net: switchdev: Drop EXPERIMENTAL from description
From: Florian Fainelli Date: Sat, 14 May 2016 12:49:54 -0700 > Switchdev has been around for quite a while now, putting "EXPERIMENTAL" > in the description is no longer accurate, drop it. > > Signed-off-by: Florian Fainelli Yeah this is long overdue, applied, thanks.
Re: [PATCH RFT 1/2] phylib: add device reset GPIO support
Hello.
On 05/13/2016 10:18 PM, Sergei Shtylyov wrote:
[we already talked about this patch in #armlinux, I'm now just
forwarding my comments on the list. Background was that I sent an easier
and less complete patch with the same idea. See
http://patchwork.ozlabs.org/patch/621418/]
[added Linus Walleij to Cc, there is a question for you/him below]
On Fri, Apr 29, 2016 at 01:12:54AM +0300, Sergei Shtylyov wrote:
--- net-next.orig/Documentation/devicetree/bindings/net/phy.txt
+++ net-next/Documentation/devicetree/bindings/net/phy.txt
@@ -35,6 +35,8 @@ Optional Properties:
- broken-turn-around: If set, indicates the PHY device does not correctly
release the turn around line low at the end of a MDIO transaction.
+- reset-gpios: The GPIO phandle and specifier for the PHY reset signal.
+
Example:
ethernet-phy@0 {
This is great.
Index: net-next/drivers/net/phy/at803x.c
===
--- net-next.orig/drivers/net/phy/at803x.c
+++ net-next/drivers/net/phy/at803x.c
@@ -65,7 +65,6 @@ MODULE_LICENSE("GPL");
[...]
My patch breaks this driver. I wasn't aware of it.
I tried to be as careful as I could but still it looks that I didn't
succeed at that too...
Hm, I'm starting to forget the vital details about my patch...
[...]
Index: net-next/drivers/net/phy/mdio_device.c
===
--- net-next.orig/drivers/net/phy/mdio_device.c
+++ net-next/drivers/net/phy/mdio_device.c
[...]
@@ -117,9 +126,16 @@ static int mdio_probe(struct device *dev
struct mdio_driver *mdiodrv = to_mdio_driver(drv);
int err = 0;
-if (mdiodrv->probe)
+if (mdiodrv->probe) {
+/* Deassert the reset signal */
+mdio_device_reset(mdiodev, 0);
+
err = mdiodrv->probe(mdiodev);
+/* Assert the reset signal */
+mdio_device_reset(mdiodev, 1);
I wonder if it's safe to do this in general. What if ->probe does
something with the phy that is lost by resetting but that is relied on
later?
Well, I thought that config_init() method is designed for that but indeed
the LXT driver writes to BMCR in its probe() method and hence is broken.
Thank you for noticing...
It's broken even without my patch. The phylib will cause a PHY soft reset
Only iff the config_init() method exists in the PHY driver...
when attaching to the PHY device, so all BMCR programming dpone in the probe()
method will be lost. My patch does make sense as is.
No, actually it doesn't. :-(
Looks like I should alsolook into fixing lxt.c.
It took me to actually do a patch to understand my fault. Sigh... :-/
Florian, what do you think?
Florian, is phy_init_hw() logic correct?
MBR, Sergei
[PATCH v4 4/4] ASoC: MAX9860: add sidetone mixer control
Signed-off-by: Peter Rosin
---
sound/soc/codecs/max9860.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/max9860.c b/sound/soc/codecs/max9860.c
index 2b0dd6a18dad..8d257cc20ef7 100644
--- a/sound/soc/codecs/max9860.c
+++ b/sound/soc/codecs/max9860.c
@@ -3,9 +3,6 @@
*
* https://datasheets.maximintegrated.com/en/ds/MAX9860.pdf
*
- * The driver does not support sidetone since the DVST register field is
- * backwards with the mute near the maximum level instead of the minimum.
- *
* Author: Peter Rosin
* Copyright 2016 Axentia Technologies
*
@@ -135,6 +132,10 @@ const struct regmap_config max9860_regmap = {
static const DECLARE_TLV_DB_SCALE(dva_tlv, -9100, 100, 1);
static const DECLARE_TLV_DB_SCALE(dvg_tlv, 0, 600, 0);
static const DECLARE_TLV_DB_SCALE(adc_tlv, -1200, 100, 0);
+/* The dvst field has its mute in the wrong end. Sigh. */
+static const DECLARE_TLV_DB_RANGE(dvst_tlv,
+ 0, MAX9860_DVST_MIN - 1,TLV_DB_SCALE_ITEM(-6000, 200, 0),
+ MAX9860_DVST_MIN, MAX9860_DVST_MIN, TLV_DB_SCALE_ITEM(0, 0, 1));
static const DECLARE_TLV_DB_RANGE(pam_tlv,
0, MAX9860_PAM_MAX - 1, TLV_DB_SCALE_ITEM(-2000, 2000, 1),
MAX9860_PAM_MAX, MAX9860_PAM_MAX, TLV_DB_SCALE_ITEM(3000, 0, 0));
@@ -214,6 +215,11 @@ SOC_ENUM("ADC Filter", avflt_enum),
SOC_ENUM("DAC Filter", dvflt_enum),
};
+static const struct snd_kcontrol_new max9860_mixer_controls[] = {
+SOC_DAPM_SINGLE_TLV("Sidetone Volume", MAX9860_DACGAIN,
+ MAX9860_DVST_SHIFT, MAX9860_DVST_MIN, 1, dvst_tlv),
+};
+
static const struct snd_soc_dapm_widget max9860_dapm_widgets[] = {
SND_SOC_DAPM_INPUT("MICL"),
SND_SOC_DAPM_INPUT("MICR"),
@@ -224,6 +230,10 @@ SND_SOC_DAPM_ADC("ADCR", NULL, MAX9860_PWRMAN,
MAX9860_ADCREN_SHIFT, 0),
SND_SOC_DAPM_AIF_OUT("AIFOUTL", "Capture", 0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_OUT("AIFOUTR", "Capture", 1, SND_SOC_NOPM, 0, 0),
+SND_SOC_DAPM_MIXER("Mixer", SND_SOC_NOPM, 0, 0,
+ max9860_mixer_controls,
+ ARRAY_SIZE(max9860_mixer_controls)),
+
SND_SOC_DAPM_AIF_IN("AIFINL", "Playback", 0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_IN("AIFINR", "Playback", 1, SND_SOC_NOPM, 0, 0),
@@ -244,8 +254,10 @@ static const struct snd_soc_dapm_route
max9860_dapm_routes[] = {
{ "AIFOUTL", NULL, "ADCL" },
{ "AIFOUTR", NULL, "ADCR" },
- { "DAC", NULL, "AIFINL" },
- { "DAC", NULL, "AIFINR" },
+ { "Mixer", NULL, "AIFINL" },
+ { "Mixer", NULL, "AIFINR" },
+ { "Mixer", "Sidetone Volume", "ADCL" },
+ { "DAC", NULL, "Mixer" },
{ "OUT", NULL, "DAC" },
{ "Supply", NULL, "AVDD" },
--
2.1.4
[PATCH v4 1/4] dt-bindings: sound: add bindings for the max9860 codec
This adds the device tree binding documentation for the Maxim Integrated
MAX9860 mono audio voice codec.
Acked-by: Rob Herring
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/sound/max9860.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/max9860.txt
diff --git a/Documentation/devicetree/bindings/sound/max9860.txt
b/Documentation/devicetree/bindings/sound/max9860.txt
new file mode 100644
index ..e0d4e95e31b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/max9860.txt
@@ -0,0 +1,28 @@
+MAX9860 Mono Audio Voice Codec
+
+Required properties:
+
+ - compatible : "maxim,max9860"
+
+ - reg : the I2C address of the device
+
+ - AVDD-supply, DVDD-supply and DVDDIO-supply : power supplies for
+the device, as covered in bindings/regulator/regulator.txt
+
+ - clock-names : Required element: "mclk".
+
+ - clocks : A clock specifier for the clock connected as MCLK.
+
+Examples:
+
+ max9860: max9860@10 {
+ compatible = "maxim,max9860";
+ reg = <0x10>;
+
+ AVDD-supply = <®_1v8>;
+ DVDD-supply = <®_1v8>;
+ DVDDIO-supply = <®_3v0>;
+
+ clock-names = "mclk";
+ clocks = <&pck2>;
+ };
--
2.1.4
Re: [PATCH] usb: gadget: f_fs: report error if excess data received
On Fri, May 13 2016, Alan Stern wrote: > The point is that you don't know whether the host sent more data than > expected. All you know is that the host sent more data than the user > asked the kernel for -- but maybe the user didn't ask for all the data > that he expected. Maybe the user wanted to retrieve the full set of > data using two read() system calls. I was wondering about that for a while actually. So far, f_fs’ model was: one read, one request. Splitting requests would certainly be possible, but is that what f_fs’ users would expect to happen if host rounds the request up? -- Best regards ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ «If at first you don’t succeed, give up skydiving»
Re: [PATCH net-next] net: switchdev: Drop EXPERIMENTAL from description
Sat, May 14, 2016 at 09:49:54PM CEST, f.faine...@gmail.com wrote: >Switchdev has been around for quite a while now, putting "EXPERIMENTAL" >in the description is no longer accurate, drop it. > >Signed-off-by: Florian Fainelli Acked-by: Jiri Pirko
Re: [PATCH] iommu/rockchip: fix zap cache during device attach
Am Dienstag, 10. Mai 2016, 16:50:46 schrieb John Keeping:
> rk_iommu_command() takes a struct rk_iommu and iterates over the slave
> MMUs, so this is doubly wrong in that we're passing in the wrong pointer
> and talking to MMUs that we shouldn't be.
>
> Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi
> slaves") Signed-off-by: John Keeping
on a rk3288-veyron
Tested-by: Heiko Stuebner
Reviewed-by: Heiko Stuebner
I was wondering for a short time why this didn't spew warnings until I
realized that the iommu->bases[i] is of course a void* .
Heiko
[GIT] Networking
1) Fix mvneta/bm dependencies, from Arnd Bergmann.
2) RX completion hw bug workaround in bnxt_en, from Michael Chan.
3) Kernel pointer leak in nf_conntrack, from Linus.
4) Hoplimit route attribute limits not enforced properly, from
Paolo Abeni.
5) qlcnic driver NULL deref fix from Dan Carpenter.
Please pull, thanks a lot!
The following changes since commit 685764b108a7e5fe9f5ee213d6a627c1166d7c88:
Merge tag 'scsi-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi (2016-05-11 13:17:12
-0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 98397fc547e3f4553553a30ea56fa34d613f0a4c:
arm64: bpf: jit JMP_JSET_{X,K} (2016-05-14 16:11:45 -0400)
Arnd Bergmann (1):
net: mvneta: bm: fix dependencies again
Dan Carpenter (1):
qlcnic: potential NULL dereference in qlcnic_83xx_get_minidump_template()
David S. Miller (2):
Merge branch 'bnxt_en-fixes'
Merge branch 'xgene-fixes'
Iyappan Subramanian (5):
drivers: net: xgene: fix IPv4 forward crash
drivers: net: xgene: fix sharing of irqs
drivers: net: xgene: fix ununiform latency across queues
drivers: net: xgene: fix statistics counters race condition
drivers: net: xgene: fix register offset
Linus Torvalds (1):
nf_conntrack: avoid kernel pointer value leak in slab name
Michael Chan (2):
bnxt_en: Add workaround to detect bad opaque in rx completion (part 1)
bnxt_en: Add workaround to detect bad opaque in rx completion (part 2)
Paolo Abeni (1):
net/route: enforce hoplimit max value
Paul Durrant (1):
xen-netback: fix extra_info handling in xenvif_tx_err()
Zi Shen Lim (1):
arm64: bpf: jit JMP_JSET_{X,K}
arch/arm64/net/bpf_jit_comp.c| 1 +
drivers/net/ethernet/apm/xgene/xgene_enet_cle.c | 11 +-
drivers/net/ethernet/apm/xgene/xgene_enet_cle.h | 2 ++
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 19 ++---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 8 ---
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 75
+++--
drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 18
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.h| 2 +-
drivers/net/ethernet/broadcom/bnxt/bnxt.c| 63
++
drivers/net/ethernet/broadcom/bnxt/bnxt.h| 2 ++
drivers/net/ethernet/marvell/Kconfig | 2 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_minidump.c | 8 +--
drivers/net/xen-netback/netback.c| 1 +
net/ipv4/fib_semantics.c | 2 ++
net/ipv6/route.c | 2 ++
net/netfilter/nf_conntrack_core.c| 4 +++-
16 files changed, 175 insertions(+), 45 deletions(-)
Re: [PATCH v2] drm/amd/powerplay: use ARRAY_SIZE() to calculate array size.
Am 13.05.2016 um 19:36 schrieb Muhammad Falak R Wani:
It is preferred to use ARRAY_SIZE() for size calculation, instead
using sizeof(array)/sizeof(*array). It makes the code more readable.
Signed-off-by: Muhammad Falak R Wani
Reviewed-by: Christian König
Thanks for the cleanup,
Christian.
---
drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
index da18f44..87c023e 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
@@ -639,7 +639,7 @@ static int cz_smu_populate_firmware_entries(struct
pp_smumgr *smumgr)
cz_smu->driver_buffer_length = 0;
- for (i = 0; i < sizeof(firmware_list)/sizeof(*firmware_list); i++) {
+ for (i = 0; i < ARRAY_SIZE(firmware_list); i++) {
firmware_type = cz_translate_firmware_enum_to_arg(smumgr,
firmware_list[i]);
Re: [PATCH RFT 1/2] phylib: add device reset GPIO support
On Sat, May 14, 2016 at 10:36:38PM +0300, Sergei Shtylyov wrote: > Hello. > > On 05/14/2016 02:44 AM, Andrew Lunn wrote: > > >Another issue is that on some boards we have one reset line tied to > >multiple PHYs.How do we prevent multiple resets being taking place when > >each of > >the PHYs are registered? > > My patch just doesn't address this case -- it's about the > individual resets only. > >>> > >>>This actually needs to be addresses a layer above. What you have is a > >>>bus reset, not a device reset. > >> > >> No. > >> There's simply no such thing as a bus reset for the xMII/MDIO > >>busses, there's simply no reset signaling on them. Every device has > >>its own reset signal and its own timing requirements. > > > >Except in the case above, where two phys are sharing the same reset > >signal. So although it is not part of the mdio standard to have a bus > >reset, this is in effect what the gpio line is doing, resetting all > >devices on the bus. If you don't model that as a bus reset, how do you > >model it? > >I'm not suggesting that the shared reset should be handled by my > patch. Contrariwise, I suggested to use the mii_bus::reset() method I think we miss understood each other somewhere. Your code is great for one gpio reset line for one phy. I think there could be similar code one layer above to handle one gpio line for multiple phys. Andrew
[PATCH net-next] net: switchdev: Drop EXPERIMENTAL from description
Switchdev has been around for quite a while now, putting "EXPERIMENTAL" in the description is no longer accurate, drop it. Signed-off-by: Florian Fainelli --- net/switchdev/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/switchdev/Kconfig b/net/switchdev/Kconfig index 86a47e1..651fa20 100644 --- a/net/switchdev/Kconfig +++ b/net/switchdev/Kconfig @@ -3,7 +3,7 @@ # config NET_SWITCHDEV - bool "Switch (and switch-ish) device support (EXPERIMENTAL)" + bool "Switch (and switch-ish) device support" depends on INET ---help--- This module provides glue between core networking code and device -- 2.7.4
Re: QRTR merge conflict resolution (was: Re: linux-next: build failure after merge of the net-next tree)
On Friday 13 May 2016 17:47:17 Andy Gross wrote: > On 13 May 2016 at 17:19, Bjorn Andersson wrote: > > On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote: > > > >> On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote: > > [..] > >> > I assume we could have the QRTR go through Andy and arm-soc, with > >> > David's approval and this fix squashed in. But we're running rather late > >> > in this cycle, perhaps we should just back the QRTR patches out and I > >> > can respin and resend them after the merge window (for v4.8 instead)? > >> > >> I'd suggest you do a merge of next-next with the qcom/soc-2 branch that > >> we have in arm-soc and resolve the conflict in the merge, then send > >> a pull request with the merge to davem. > >> > > > > Hi David, > > > > In case you missed this thread, linux-next highlighted an upcoming merge > > conflict between the net-next and one of the branches included in the > > arm-soc trees. > > > > I have prepared the merge of net-next and the conflicting tag from the > > Qualcomm SOC, please include this in your pull towards Linus to avoid > > the merge conflict. > > > > Regards, > > Bjorn > > > > The following changes since commit ed7cbbce544856b20e5811de373cf92e92499771: > > > > udp: Resolve NULL pointer dereference over flow-based vxlan device > > (2016-05-13 01:56:14 -0400) > > > OK. The contents look good to me. > > Acked-by: Andy Gross Acked-by: Arnd Bergmann
Re: usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4
On Saturday 14 May 2016 15:11:34 Christian Lamparter wrote:
>
> +#ifdef CONFIG_MIPS
> +/*
> + * There are some MIPS machines that can run in either big-endian
> + * or little-endian mode and that use the dwc2 register without
> + * a byteswap in both ways.
> + * Unlike other architectures, MIPS apparently does not require a
> + * barrier before the __raw_writel() to synchronize with DMA but does
> + * require the barrier after the __raw_writel() to serialize a set of
> + * writes. This set of operations was added specifically for MIPS and
> + * should only be used there.
> + */
> +static inline u32 dwc2_readl(struct dwc2_hsotg *hsotg,
> +ptrdiff_t reg)
> +{
> + const void __iomem *addr = hsotg->regs + reg;
> + u32 value = __raw_readl(addr);
> +
>
I see you keep the special case for MIPS here, I'd vote for folding
that back into the architecture-independent version and not treating
MIPS any different from the others. With your endianness detection, MIPS
should have no way of getting the byteorder wrong, and on MIPS the
platform is responsible for adding the appropriate barriers to
readl/writel.
Other than this, the patch looks good to me.
Arnd
Re: [PATCH RFT 1/2] phylib: add device reset GPIO support
Hello. On 05/14/2016 02:44 AM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the individual resets only. This actually needs to be addresses a layer above. What you have is a bus reset, not a device reset. No. There's simply no such thing as a bus reset for the xMII/MDIO busses, there's simply no reset signaling on them. Every device has its own reset signal and its own timing requirements. Except in the case above, where two phys are sharing the same reset signal. So although it is not part of the mdio standard to have a bus reset, this is in effect what the gpio line is doing, resetting all devices on the bus. If you don't model that as a bus reset, how do you model it? I'm not suggesting that the shared reset should be handled by my patch. Contrariwise, I suggested to use the mii_bus::reset() method -- I see it as a necessary evil. However, in the more common case of a single PHY, this method simply doesn't scale -- you'd have to teach each and every individual MAC/ MDIO driver to do the GPIO reset trick. Andrew MBR, Sergei
Re: [PATCH 2/5] efibc: Fix excessive stack footprint warning
On Wed, 11 May, at 05:16:24PM, Jeremy Compostella wrote: > From 3a54e6872e220e1ac4db0eae126a20b5383dae3e Mon Sep 17 00:00:00 2001 > From: Jeremy Compostella > Date: Tue, 10 May 2016 10:34:21 +0200 > Subject: [PATCH] efibc: report more information in the error messages > > Report the name of the EFI variable if the value size is too large or > if efibc_set_variable() fails to allocate the struct efivar_entry > object. If efibc_set_variable() fails because the value size is too > large, it also reports the value size in the error message. > > Signed-off-by: Jeremy Compostella > --- > drivers/firmware/efi/efibc.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Applied, thanks Jeremy.
Re: [PATCH v4 3/5] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine
On Fri, May 13, 2016 at 12:36 AM, Appana Durga Kedareswara Rao wrote: > Hi Paul, > >> >> Nice Kedar! >> >> Is this getting applied? I would really like to see this get into the >> mainline. > > This patch got applied to the dma-next branch... > Here @ > http://git.kernel.org/cgit/linux/kernel/git/vkoul/slave-dma.git/log/?h=next > > Thanks, > Kedar. > I see, thanks! -Paul
[GIT PULL] EFI ARM Xen support
Folks,
Please pull the following branch which contains support for Xen on ARM
EFI platforms.
This merge includes a merge of Stefano's xen/linux-next branch to pull
in the prerequisites required for Shannon's commit:
11ee5491e5ff ("Xen: EFI: Parse DT parameters for Xen specific UEFI")
as it needs both the latest changes in the EFI 'next' branch (now
tip/efi/core) and xen/linux-next.
I have intentionally not included the individual patches as I would
normally do in a pull request, so that commit history created by my
merging of Stefano's branch is preserved, and so that there's no way
to accidentally apply the patches individually.
The following changes since commit 6c5450ef66816216e574885cf8d3ddb31ef77428:
efivarfs: Make efivarfs_file_ioctl() static (2016-05-07 07:06:13 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git efi/arm-xen
for you to fetch changes up to 11ee5491e5ff519e0d3a7018eb21351cb6955a98:
Xen: EFI: Parse DT parameters for Xen specific UEFI (2016-05-14 19:31:01
+0100)
David Vrabel (1):
xen/gntdev: reduce copy batch size to 16
Matt Fleming (1):
Merge branch 'xen/linux-next' into efi/arm-xen
Shannon Zhao (16):
Xen: ACPI: Hide UART used by Xen
xen/grant-table: Move xlated_setup_gnttab_pages to common place
Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
Xen: ARM: Add support for mapping platform device mmio
Xen: ARM: Add support for mapping AMBA device mmio
Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
xen/hvm/params: Add a new delivery type for event-channel in
HVM_PARAM_CALLBACK_IRQ
arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
ARM: XEN: Move xen_early_init() before efi_init()
ARM: Xen: Document UEFI support on Xen ARM virtual platforms
XEN: EFI: Move x86 specific codes to architecture directory
ARM64: XEN: Add a function to initialize Xen specific UEFI runtime
services
FDT: Add a helper to get the subnode by given name
Xen: EFI: Parse DT parameters for Xen specific UEFI
Stefano Stabellini (1):
xen/x86: don't lose event interrupts
Documentation/devicetree/bindings/arm/xen.txt | 35 +
arch/arm/include/asm/xen/xen-ops.h| 6 +
arch/arm/kernel/setup.c | 2 +-
arch/arm/xen/Makefile | 1 +
arch/arm/xen/efi.c| 40 ++
arch/arm/xen/enlighten.c | 125
arch/arm64/include/asm/xen/xen-ops.h | 6 +
arch/arm64/kernel/setup.c | 2 +-
arch/arm64/xen/Makefile | 1 +
arch/x86/xen/efi.c| 111 +++
arch/x86/xen/grant-table.c| 57 +---
arch/x86/xen/time.c | 6 +-
drivers/acpi/scan.c | 74 ++
drivers/firmware/efi/arm-runtime.c| 5 +
drivers/firmware/efi/efi.c| 81 ---
drivers/of/fdt.c | 13 ++
drivers/xen/Kconfig | 2 +-
drivers/xen/Makefile | 1 +
drivers/xen/arm-device.c | 196 ++
drivers/xen/efi.c | 173 +--
drivers/xen/gntdev.c | 2 +-
drivers/xen/xlate_mmu.c | 77 ++
include/linux/of_fdt.h| 2 +
include/xen/interface/hvm/params.h| 40 +-
include/xen/interface/memory.h| 1 +
include/xen/xen-ops.h | 32 +++--
26 files changed, 840 insertions(+), 251 deletions(-)
create mode 100644 arch/arm/include/asm/xen/xen-ops.h
create mode 100644 arch/arm/xen/efi.c
create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
create mode 100644 drivers/xen/arm-device.c
[git pull] vfs.git fixes for -final
Overlayfs fixes from Miklos, assorted fixes from me. -stable fodder of varying severity, all sat in -next for a while. The following changes since commit 44549e8f5eea4e0a41b487b63e616cb089922b99: Linux 4.6-rc7 (2016-05-08 14:38:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus for you to fetch changes up to e4d35be584be88a3db3fa5635a97c62a2ec5aafe: Merge branch 'ovl-fixes' into for-linus (2016-05-11 00:00:29 -0400) Al Viro (6): do_splice_to(): cap the size before passing to ->splice_read() fix the copy vs. map logics in blk_rq_map_user_iov() atomic_open(): fix the handling of create_error ecryptfs: fix handling of directory opening get_rock_ridge_filename(): handle malformed NM entries Merge branch 'ovl-fixes' into for-linus Miklos Szeredi (4): vfs: add vfs_select_inode() helper vfs: rename: check backing inode being equal vfs: add lookup_hash() helper ovl: ignore permissions on underlying lookup block/blk-map.c| 47 ++--- fs/ecryptfs/file.c | 71 ++ fs/isofs/rock.c| 13 ++--- fs/namei.c | 59 + fs/open.c | 12 +++-- fs/overlayfs/super.c | 4 +-- fs/splice.c| 3 +++ include/linux/dcache.h | 12 + include/linux/namei.h | 2 ++ include/linux/uio.h| 1 + lib/iov_iter.c | 19 ++ 11 files changed, 152 insertions(+), 91 deletions(-)
Re: [PATCH] Documentation: Add ebc-c384_wdt watchdog-parameters.txt entry
Hi William > The WinSystems EBC-C384 watchdog timer driver supports two module > parameters: timeout and nowayout. These parameters should be documented > in the watchdog-parameters.txt file. > > Signed-off-by: William Breathitt Gray > --- > Documentation/watchdog/watchdog-parameters.txt | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/watchdog/watchdog-parameters.txt > b/Documentation/watchdog/watchdog-parameters.txt > index c161399..a8d3642 100644 > --- a/Documentation/watchdog/watchdog-parameters.txt > +++ b/Documentation/watchdog/watchdog-parameters.txt > @@ -86,6 +86,10 @@ nowayout: Watchdog cannot be stopped once started > davinci_wdt: > heartbeat: Watchdog heartbeat period in seconds from 1 to 600, default 60 > - > +ebc-c384_wdt: > +timeout: Watchdog timeout in seconds. (1<=timeout<=15300, default=60) > +nowayout: Watchdog cannot be stopped once started > +- > ep93xx_wdt: > nowayout: Watchdog cannot be stopped once started > timeout: Watchdog timeout in seconds. (1<=timeout<=3600, default=TBD) > -- > 2.7.3 > This patch was added to linux-watchdog-next. Kind Regards, Wim.
Re: [PATCH 2/2] watchdog: shwdt: Use setup_timer()
Hi Muhammed, > The function setup_timer combines the initialization of a timer with > the initialization of the timer's function and data fields. > The multiline code for timer initialization is now replaced > with function setup_timer. > > Signed-off-by: Muhammad Falak R Wani > --- > drivers/watchdog/shwdt.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/watchdog/shwdt.c b/drivers/watchdog/shwdt.c > index f908121..517a733 100644 > --- a/drivers/watchdog/shwdt.c > +++ b/drivers/watchdog/shwdt.c > @@ -275,9 +275,7 @@ static int sh_wdt_probe(struct platform_device *pdev) > return rc; > } > > - init_timer(&wdt->timer); > - wdt->timer.function = sh_wdt_ping; > - wdt->timer.data = (unsigned long)wdt; > + setup_timer(&wdt->timer, sh_wdt_ping, (unsigned long)wdt); > wdt->timer.expires = next_ping_period(clock_division_ratio); > > dev_info(&pdev->dev, "initialized.\n"); > -- > 1.9.1 > This patch was added to linux-watchdog-next. Kind Regards, Wim.
Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism
On Fri, May 13, 2016 at 8:54 PM, George Spelvin wrote: > > There are exactly three architectures which (some models) don't have > an efficient 32x32->32-bit multiply: > > - arch/m58k: MC68000 (and 68010 and 68328) no-mmu > - arch/h8300: Most (all?) of the H8 processor series > - arch/microblaze: Depending on Verilog compilation options I wouldn't worry about it too much. The architectures where performance really matters are x86, ARM and powerpc. The rest need to *work* and not suck horribly, but we're not going to try to do cycle counting for them. It's not worth the pain. If an architecture doesn't have a barrel shifter, it's not going to have fast hash functions. So I'd be ok with just saying "32-bit architectures are going to use a multiply with non-sparse bits". Not a problem. We do want to make sure that hash_64 isn't totally disgusting on 32-bit architectures (but that's a fairly rare case), so we probably do want to have that function fall back on something else than a 64x64 multiply on a 32-bit architecture. Presumably just "mix the two 32-bit words into one, then use hash_32() on that" is good enough. Linus
Re: [PATCH 1/2] watchdog: cpwd: Use setup_timer()
Hi Muhammed,
> The function setup_timer combines the initialization of a timer with
> the initialization of the timer's function and data fields.
> The multiline code for timer initialization is now replaced
> with function setup_timer.
>
> Signed-off-by: Muhammad Falak R Wani
> ---
> drivers/watchdog/cpwd.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/watchdog/cpwd.c b/drivers/watchdog/cpwd.c
> index 0200768..71ee079 100644
> --- a/drivers/watchdog/cpwd.c
> +++ b/drivers/watchdog/cpwd.c
> @@ -611,9 +611,7 @@ static int cpwd_probe(struct platform_device *op)
> }
>
> if (p->broken) {
> - init_timer(&cpwd_timer);
> - cpwd_timer.function = cpwd_brokentimer;
> - cpwd_timer.data = (unsigned long) p;
> + setup_timer(&cpwd_timer, cpwd_brokentimer, (unsigned long)p);
> cpwd_timer.expires = WD_BTIMEOUT;
>
> pr_info("PLD defect workaround enabled for model %s\n",
> --
> 1.9.1
>
This patch was added to linux-watchdog-next.
Kind Regards,
Wim.
Re: [PATCH] watchdog: remove error message when unable to allocate watchdog device
Hi Colin,
> From: Colin Ian King
>
> The dev_err message is superfluous because the failure is already
> printed by dev_kzalloc, so remove it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/watchdog/jz4740_wdt.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
> index 6a7d5c3..c8d51dd 100644
> --- a/drivers/watchdog/jz4740_wdt.c
> +++ b/drivers/watchdog/jz4740_wdt.c
> @@ -160,10 +160,8 @@ static int jz4740_wdt_probe(struct platform_device *pdev)
>
> drvdata = devm_kzalloc(&pdev->dev, sizeof(struct jz4740_wdt_drvdata),
> GFP_KERNEL);
> - if (!drvdata) {
> - dev_err(&pdev->dev, "Unable to alloacate watchdog device\n");
> + if (!drvdata)
> return -ENOMEM;
> - }
>
> if (heartbeat < 1 || heartbeat > MAX_HEARTBEAT)
> heartbeat = DEFAULT_HEARTBEAT;
> --
> 2.7.4
>
This patch was added to linux-watchdog-next.
Kind Regards,
Wim.
Re: [PATCH] watchdog: core: Fix circular locking dependency
Hi Guenter, > On 05/14/2016 10:07 AM, Guenter Roeck wrote: > >Hi Wim, > > > >On 05/14/2016 09:41 AM, Wim Van Sebroeck wrote: > >>Hi Guenter, > >> > >>>lockdep reports the following circular locking dependency. > >>> > > > >You are faster than me this time. I was just about to send you a pull > >request. > >Sorry for being late. The watchdog-next branch in my repository on > >kernel.org > >has all patches in my queue, in case you want to have a look. > > > >I'll rebase my branch to yours and see if anything is missing, then send > >you a pull request on top of it if needed. > > > > All there. Looks like you picked it up right after I updated the branch > this morning. Correct ;-) Kind regards, Wim.
Re: Additional compiler barrier required in sched_preempt_enable_no_resched?
On 5/14/2016 8:39 AM, Thomas Gleixner wrote:
On Fri, 13 May 2016, Vikram Mulukutla wrote:
On 5/13/2016 7:58 AM, Peter Zijlstra wrote:
diff --git a/include/asm-generic/preempt.h b/include/asm-generic/preempt.h
index 5d8ffa3e6f8c..c1cde3577551 100644
--- a/include/asm-generic/preempt.h
+++ b/include/asm-generic/preempt.h
@@ -7,10 +7,10 @@
static __always_inline int preempt_count(void)
{
- return current_thread_info()->preempt_count;
+ return READ_ONCE(current_thread_info()->preempt_count);
}
-static __always_inline int *preempt_count_ptr(void)
+static __always_inline volatile int *preempt_count_ptr(void)
{
return ¤t_thread_info()->preempt_count;
}
Thanks Peter, this patch worked for me. The compiler no longer optimizes out
the increment/decrement of the preempt_count.
I have a hard time to understand why the compiler optimizes out stuff w/o that
patch.
We already have:
#define preempt_disable() \
do { \
preempt_count_inc(); \
barrier(); \
} while (0)
#define sched_preempt_enable_no_resched() \
do { \
barrier(); \
preempt_count_dec(); \
} while (0)
#define preempt_enable() \
do { \
barrier(); \
if (unlikely(preempt_count_dec_and_test())) \
__preempt_schedule(); \
} while (0)
So the barriers already forbid that the compiler reorders code. How on earth
is the compiler supposed to optimize the dec/inc out?
While I cannot claim more than a very rudimentary knowledge of
compilers, this was the initial reaction that I had as well. But then
the barriers are in the wrong spots for the way the code was used in the
driver in question. preempt_disable has the barrier() _after_ the
increment, and sched_preempt_enable_no_resched has it _before_ the
decrement. Therefore, if one were to use preempt_enable_no_resched
followed by preempt_disable, there is no compiler barrier between the
decrement and the increment statements. Whether this should translate to
such a seemingly aggressive optimization is something I'm not completely
sure of.
There is more code than the preempt stuff depending on barrier() and expecting
that the compiler does not optimize out things at will. Are we supposed to
hunt all occurences and amend them with READ_ONCE or whatever one by one?
I think the barrier is working as intended for the sequence of
preempt_disable followed by preempt_enable_no_resched.
Thanks,
tglx
As a simple experiment I used gcc on x86 on the following C program.
This was really to convince myself rather than you and Peter!
#include
#define barrier() __asm__ __volatile__("": : :"memory")
struct thread_info {
int pc;
};
#define preempt_count() \
ti_ptr->pc
#define preempt_disable() \
do \
{ \
preempt_count() += 1; \
barrier(); \
} \
while (0)
#define preempt_enable() \
do \
{ \
barrier(); \
preempt_count() -= 1; \
} \
while (0)
struct thread_info *ti_ptr;
int main(void)
{
struct thread_info ti;
ti_ptr = &ti;
int b;
preempt_enable();
b = b + 500;
preempt_disable();
printf("b = %d\n", b);
return 0;
}
With gcc -O2 I get this (the ARM compiler behaves similarly):
00400470 :
400470: 48 83 ec 18 sub$0x18,%rsp
400474: 48 89 25 cd 0b 20 00mov%rsp,0x200bcd(%rip)
40047b: ba f4 01 00 00 mov$0x1f4,%edx
400480: be 14 06 40 00 mov$0x400614,%esi
400485: bf 01 00 00 00 mov$0x1,%edi
40048a: 31 c0 xor%eax,%eax
40048c: e8 cf ff ff ff callq 400460 <__printf_chk@plt>
400491: 31 c0 xor%eax,%eax
400493: 48 83 c4 18 add$0x18,%rsp
400497: c3 retq
If I swap preempt_enable and preempt_disable I get this:
00400470 :
400470: 48 83 ec 18 sub$0x18,%rsp
400474: 48 89 25 cd 0b 20 00mov%rsp,0x200bcd(%rip)
40047b: 83 04 24 01 addl $0x1,(%rsp)
40047f: 48 8b 05 c2 0b 20 00mov0x200bc2(%rip),%rax
400486: ba f4 01 00 00 mov$0x1f4,%edx
40048b: be 14 06 40 00 mov$0x400614,%esi
400490: bf 01 00 00 00 mov$0x1,%edi
400495: 83 28 01subl $0x1,(%rax)
400498: 31 c0 xor%eax,%eax
40049a: e8 c1 ff ff ff callq 400460 <__printf_chk@plt>
40049f: 31 c0 xor%eax,%eax
4004a1: 48 83 c4 18 add$0x18,%rsp
4004a5: c3 retq
Note: If I place ti_ptr on the stack, the ordering/barriers no longer
matter, the inc/dec is always optimized out. I suppose the compiler does
treat current_thread_info as coming from a different memory location
rather than the current stack frame. In
Re: [PATCH v4] iio: accel: Add support for Freescale MMA7660FC
On 03/05/16 13:05, Constantin Musca wrote:
> Minimal implementation of an IIO driver for the Freescale
> MMA7660FC 3-axis accelerometer. Datasheet:
> http://www.nxp.com/files/sensors/doc/data_sheet/MMA7660FC.pdf
>
> Includes:
> - ACPI support;
> - read_raw for x,y,z axes;
> - reading and setting the scale (range) parameter.
> - power management
>
> Signed-off-by: Constantin Musca
Very nice - and thanks for the clear comments on the 'unusual'
corners.
I actually applied this last week whilst on a train but for
some reason my email to say so never went out (probably something
to do with flakey wifi at Gare du Nord)
Thanks,
Jonathan
> ---
> drivers/iio/accel/Kconfig | 10 ++
> drivers/iio/accel/Makefile | 2 +
> drivers/iio/accel/mma7660.c | 277
>
> 3 files changed, 289 insertions(+)
> create mode 100644 drivers/iio/accel/mma7660.c
>
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index e4a758c..1df6361 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -136,6 +136,16 @@ config MMA7455_SPI
> To compile this driver as a module, choose M here: the module
> will be called mma7455_spi.
>
> +config MMA7660
> + tristate "Freescale MMA7660FC 3-Axis Accelerometer Driver"
> + depends on I2C
> + help
> + Say yes here to get support for the Freescale MMA7660FC 3-Axis
> + accelerometer.
> +
> + Choosing M will build the driver as a module. If so, the module
> + will be called mma7660.
> +
> config MMA8452
> tristate "Freescale MMA8452Q and similar Accelerometers Driver"
> depends on I2C
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 71b6794..ba1165f 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -15,6 +15,8 @@ obj-$(CONFIG_MMA7455) += mma7455_core.o
> obj-$(CONFIG_MMA7455_I2C)+= mma7455_i2c.o
> obj-$(CONFIG_MMA7455_SPI)+= mma7455_spi.o
>
> +obj-$(CONFIG_MMA7660)+= mma7660.o
> +
> obj-$(CONFIG_MMA8452)+= mma8452.o
>
> obj-$(CONFIG_MMA9551_CORE) += mma9551_core.o
> diff --git a/drivers/iio/accel/mma7660.c b/drivers/iio/accel/mma7660.c
> new file mode 100644
> index 000..0acdee5
> --- /dev/null
> +++ b/drivers/iio/accel/mma7660.c
> @@ -0,0 +1,277 @@
> +/**
> + * Freescale MMA7660FC 3-Axis Accelerometer
> + *
> + * Copyright (c) 2016, Intel Corporation.
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License. See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * IIO driver for Freescale MMA7660FC; 7-bit I2C address: 0x4c.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MMA7660_DRIVER_NAME "mma7660"
> +
> +#define MMA7660_REG_XOUT 0x00
> +#define MMA7660_REG_YOUT 0x01
> +#define MMA7660_REG_ZOUT 0x02
> +#define MMA7660_REG_OUT_BIT_ALERTBIT(6)
> +
> +#define MMA7660_REG_MODE 0x07
> +#define MMA7660_REG_MODE_BIT_MODEBIT(0)
> +#define MMA7660_REG_MODE_BIT_TON BIT(2)
> +
> +#define MMA7660_I2C_READ_RETRIES 5
> +
> +/*
> + * The accelerometer has one measurement range:
> + *
> + * -1.5g - +1.5g (6-bit, signed)
> + *
> + * scale = (1.5 + 1.5) * 9.81 / (2^6 - 1)= 0.467142857
> + */
> +
> +#define MMA7660_SCALE_AVAIL "0.467142857"
> +
> +const int mma7660_nscale = 467142857;
> +
> +#define MMA7660_CHANNEL(reg, axis) { \
> + .type = IIO_ACCEL, \
> + .address = reg, \
> + .modified = 1, \
> + .channel2 = IIO_MOD_##axis, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> +}
> +
> +static const struct iio_chan_spec mma7660_channels[] = {
> + MMA7660_CHANNEL(MMA7660_REG_XOUT, X),
> + MMA7660_CHANNEL(MMA7660_REG_YOUT, Y),
> + MMA7660_CHANNEL(MMA7660_REG_ZOUT, Z),
> +};
> +
> +enum mma7660_mode {
> + MMA7660_MODE_STANDBY,
> + MMA7660_MODE_ACTIVE
> +};
> +
> +struct mma7660_data {
> + struct i2c_client *client;
> + struct mutex lock;
> + enum mma7660_mode mode;
> +};
> +
> +static IIO_CONST_ATTR(in_accel_scale_available, MMA7660_SCALE_AVAIL);
> +
> +static struct attribute *mma7660_attributes[] = {
> + &iio_const_attr_in_accel_scale_available.dev_attr.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group mma7660_attribute_group = {
> + .attrs = mma7660_attributes
> +};
> +
> +static int mma7660_set_mode(struct mma7660_data *data,
> + enum mma7660_mode mode)
> +{
> + int ret;
> + struct i2c_client *client = data->client;
> +
> + if (mode == data->mode)
> + return 0;
> +
> + ret = i2c_smbus_read_byte_data(client, MMA7660_REG_MODE);
> + if (ret < 0) {
> + dev_err(&client->dev, "failed to read sensor mode\n");
> + return ret;
> + }
>
[PATCH] regulator: axp20x: Add support for the (external) drivebus regulator
The axp20x pmics have 2 power inputs, one called ACIN which is intended
for to be supplied via a powerbarrel on the board and one called VBUS
which is intended to be supplied via an otg connector.
In the VBUS case the pmic needs to know if the board is supplying power
to the otg connector, because then it should not take any power from
its VBUS pin. The axp209 pmic has a N_VBUSEN input pin via which the
board can signal to the pmic whether the board is supplying power to the
otg connector or not.
On the axp221/axp223 this pin can alternatively be used as an output
which controls an external regulator which (optionally) supplies
power to the otg connector from the board. When the pin is used as
output it is called DRIVEBUS in the datasheet.
This commit adds support for the DRIVEBUS pin as an extra pmic
controlled regulator. Since this is optional a new x-powers,drivebus dt
property is added. When this is present the misc-control register is
written to change the N_VBUSEN input pin to DRIVEBUS output pin mode and
the extra drivebus regulator is registered with the regulator subsystem.
Signed-off-by: Hans de Goede
---
Documentation/devicetree/bindings/mfd/axp20x.txt | 5
drivers/regulator/axp20x-regulator.c | 30
2 files changed, 35 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index d20b103..7a88479 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -22,6 +22,11 @@ Optional properties:
AXP152/20X: range: 750-1875, Default: 1.5 MHz
AXP22X/80X: range: 1800-4050, Default: 3 MHz
+- x-powers,drivebus: axp221 / axp223 only boolean, set this when the N_VBUSEN
+ pin is used as an output pin to control an external regulator
+ to drive the OTG VBus, rather then as an input pin which
+ signals whether the board is driving OTG VBus or not.
+
- -supply: a phandle to the regulator supply node. May be omitted if
inputs are unregulated, such as using the IPSOUT output
from the PMIC.
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index 514a5e8..2422ddd 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -36,6 +36,8 @@
#define AXP20X_FREQ_DCDC_MASK 0x0f
+#define AXP22X_MISC_N_VBUSEN_FUNC BIT(4)
+
#define AXP_DESC_IO(_family, _id, _match, _supply, _min, _max, _step, _vreg,
\
_vmask, _ereg, _emask, _enable_val, _disable_val)
\
[_family##_##_id] = {
\
@@ -230,6 +232,18 @@ static const struct regulator_desc axp22x_regulators[] = {
AXP_DESC_FIXED(AXP22X, RTC_LDO, "rtc_ldo", "ips", 3000),
};
+static const struct regulator_desc axp22x_drivebus_regulator = {
+ .name = "drivebus",
+ .supply_name= "ips",
+ .of_match = of_match_ptr("drivebus"),
+ .regulators_node = of_match_ptr("regulators"),
+ .type = REGULATOR_VOLTAGE,
+ .owner = THIS_MODULE,
+ .enable_reg = AXP20X_VBUS_IPSOUT_MGMT,
+ .enable_mask= BIT(2),
+ .ops= &axp20x_ops_sw,
+};
+
static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
{
struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
@@ -354,6 +368,7 @@ static int axp20x_regulator_probe(struct platform_device
*pdev)
u32 workmode;
const char *axp22x_dc1_name = axp22x_regulators[AXP22X_DCDC1].name;
const char *axp22x_dc5_name = axp22x_regulators[AXP22X_DCDC5].name;
+ bool drivebus = false;
switch (axp20x->variant) {
case AXP202_ID:
@@ -365,6 +380,8 @@ static int axp20x_regulator_probe(struct platform_device
*pdev)
case AXP223_ID:
regulators = axp22x_regulators;
nregulators = AXP22X_REG_ID_MAX;
+ drivebus = of_property_read_bool(pdev->dev.parent->of_node,
+"x-powers,drivebus");
break;
default:
dev_err(&pdev->dev, "Unsupported AXP variant: %ld\n",
@@ -439,6 +456,19 @@ static int axp20x_regulator_probe(struct platform_device
*pdev)
}
}
+ if (drivebus) {
+ /* Change N_VBUSEN sense pin to DRIVEBUS output pin */
+ regmap_update_bits(axp20x->regmap, AXP20X_OVER_TMP,
+ AXP22X_MISC_N_VBUSEN_FUNC, 0);
+ rdev = devm_regulator_register(&pdev->dev,
+ &axp22x_drivebus_regulator,
+ &config);
+ if (IS_ERR(rdev)) {
+ dev_err(&pdev->dev,
Re: fuse: use afer free reading/writing
ping? I still see this in -next. On 04/19/2016 10:08 AM, Sasha Levin wrote: > Hi all, > > I've hit the following while fuzzing with syzkaller inside a KVM tools guest > running the latest -next kernel: > > [ 1065.365235] BUG: KASAN: use-after-free in > fuse_dev_do_read.constprop.5+0xfb0/0x1290 at addr 8800bad3fbf0 > [ 1065.365256] Read of size 8 by task syz-executor/2448 > [ 1065.365272] > = > [ 1065.365289] BUG fuse_request (Not tainted): kasan: bad access detected > [ 1065.365295] > - > [ 1065.365295] > [ 1065.365304] Disabling lock debugging due to kernel taint > [ 1065.365337] INFO: Allocated in 0x age=18446733319112207795 > cpu=2751490774 pid=-1 > [ 1065.365359] __fuse_request_alloc+0x2b/0xf0 > [ 1065.365397] ___slab_alloc+0x7af/0x870 > [ 1065.365419] __slab_alloc.isra.22+0xf4/0x130 > [ 1065.365440] kmem_cache_alloc+0x188/0x2b0 > [ 1065.365467] __fuse_request_alloc+0x2b/0xf0 > [ 1065.365496] __fuse_get_req+0x3f4/0x5b0 > [ 1065.365520] fuse_get_req_for_background+0x22/0x30 > [ 1065.365546] cuse_channel_open+0x210/0x830 > [ 1065.365590] misc_open+0x42f/0x460 > [ 1065.365616] chrdev_open+0x412/0x500 > [ 1065.365641] do_dentry_open+0x6cc/0xba0 > [ 1065.365667] vfs_open+0x1da/0x1f0 > [ 1065.365694] path_openat+0x3291/0x3d10 > [ 1065.365716] do_filp_open+0x1df/0x280 > [ 1065.365732] do_sys_open+0x25c/0x440 > [ 1065.365745] SyS_open+0x2d/0x40 > [ 1065.365759] INFO: Freed in 0x1000bad60 age=18446733319112207795 cpu=0 pid=0 > [ 1065.365772] fuse_request_free+0xa8/0xb0 > [ 1065.365784] __slab_free+0x6a/0x2f0 > [ 1065.365796] kmem_cache_free+0x257/0x2c0 > [ 1065.365809] fuse_request_free+0xa8/0xb0 > [ 1065.365823] fuse_put_request+0x2a3/0x310 > [ 1065.365836] request_end+0x66a/0x6b0 > [ 1065.365849] fuse_dev_do_write+0xa9d/0xc00 > [ 1065.365862] fuse_dev_write+0x195/0x1f0 > [ 1065.365875] __vfs_write+0x44b/0x520 > [ 1065.365888] vfs_write+0x225/0x4a0 > [ 1065.365901] SyS_write+0xe5/0x1b0 > [ 1065.365935] do_syscall_64+0x2a6/0x4a0 > [ 1065.365991] return_from_SYSCALL_64+0x0/0x6a > [ 1065.366010] INFO: Slab 0xea0002eb4f00 objects=22 used=1 > fp=0x8800bad3fbc0 flags=0x1f80004080 > [ 1065.366019] INFO: Object 0x8800bad3fbb8 @offset=15288 > fp=0x > [ 1065.366019] > [ 1065.366019] Redzone 8800bad3fbb0: f0 8e 01 00 00 00 00 00 > > [ 1065.366019] Object 8800bad3fbb8: bb bb bb bb bb bb bb bb e8 f8 d3 ba > 00 88 ff ff > [ 1065.366019] Object 8800bad3fbc8: c0 fb d3 ba 00 88 ff ff d0 fb d3 ba > 00 88 ff ff > [ 1065.366019] Object 8800bad3fbd8: d0 fb d3 ba 00 88 ff ff 00 00 00 00 > 00 00 00 00 > [ 1065.366019] Object 8800bad3fbe8: 00 00 00 00 00 00 00 00 01 03 00 00 > 00 00 00 00 > [ 1065.366019] Object 8800bad3fbf8: 38 00 00 00 00 10 00 00 01 00 00 00 > 00 00 00 00 8... > [ 1065.366019] Object 8800bad3fc08: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 1065.366019] Object 8800bad3fc18: c9 09 00 00 00 00 00 00 00 00 00 00 > 01 00 00 00 > [ 1065.366019] Object 8800bad3fc28: 10 00 00 00 00 00 00 00 a8 fc d3 ba > 00 88 ff ff > [ 1065.366019] Object 8800bad3fc38: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 1065.366019] Object 8800bad3fc48: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 1065.366019] Object 8800bad3fc58: 18 00 00 00 fb ff ff ff 01 00 00 00 > 00 00 00 00 > [ 1065.366019] Object 8800bad3fc68: 03 00 00 00 02 00 00 00 48 00 00 00 > 00 00 00 00 H... > [ 1065.366019] Object 8800bad3fc78: 98 90 2f b3 01 88 ff ff 00 10 00 00 > 00 00 00 00 ../. > [ 1065.366019] Object 8800bad3fc88: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 1065.366019] Object 8800bad3fc98: 98 fc d3 ba 00 88 ff ff 98 fc d3 ba > 00 88 ff ff > [ 1065.366019] Object 8800bad3fca8: 07 00 00 00 18 00 00 00 00 00 00 00 > 01 00 00 00 > [ 1065.366019] Object 8800bad3fcb8: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 1065.366019] Object 8800bad3fcc8: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 1065.366019] Object 8800bad3fcd8: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 1065.366019] Object 8800bad3fce8: 00 fd d3 ba 00 88 ff ff 08 fd d3 ba > 00 88 ff ff > [ 1065.366019] Object 8800bad3fcf8: 01 00 00 00 00 00 00 00 80 d4 ec 02 > 00 ea ff ff > [ 1065.366019] Object 8800bad3fd08: 00 10 00 00 00 00 00 00 01 00 00 00 > 00 00 00 00 > [ 1065.366019] Obj
Re: [PATCH] iio: light apds9960: Add the missing dev.parent
On 05/05/16 09:18, Matt Ranostay wrote: > Reviewed-By: Matt Ranostay > > On Thu, May 5, 2016 at 1:10 AM, Yong Li wrote: >> Without this, the iio:deviceX is missing in the /sys/bus/i2c/devices/0-0039 >> >> Signed-off-by: Yong Li Applied and marked for stable. I'd added a brief note that some userspace code may expect this path to work to justify the stable tag. Thanks, Jonathan >> --- >> drivers/iio/light/apds9960.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/iio/light/apds9960.c b/drivers/iio/light/apds9960.c >> index 35928fb..f47cc0a 100644 >> --- a/drivers/iio/light/apds9960.c >> +++ b/drivers/iio/light/apds9960.c >> @@ -1010,6 +1010,7 @@ static int apds9960_probe(struct i2c_client *client, >> >> iio_device_attach_buffer(indio_dev, buffer); >> >> + indio_dev->dev.parent = &client->dev; >> indio_dev->info = &apds9960_info; >> indio_dev->name = APDS9960_DRV_NAME; >> indio_dev->channels = apds9960_channels; >> -- >> 2.5.0 >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [RFC PATCH 1/3] reset: Add support for the Amlogic Meson GXBB Reset Controller
Neil Armstrong writes:
> This patch adds the platform driver for the Amlogic Meson GXBB Reset
> Controller.
>
> Signed-off-by: Neil Armstrong
[...]
> +struct meson_gxbb_reset {
> + void *reg_base;
nit: along wit the readw/writel, this should be void __iomem *.
> + struct reset_controller_dev rcdev;
> +};
Kevin
[PATCH] Fix RC5 decoding with Fintek CIR chipset
Fix RC5 decoding with Fintek CIR chipset
Commit e87b540be2dd02552fb9244d50ae8b4e4619a34b tightened up the RC5
decoding by adding a check for trailing silence to ensure a valid RC5
command had been received. Unfortunately the trailer length checked was
10 units and the Fintek CIR device does not want to provide details of a
space longer than 6350us. This meant that RC5 remotes working on a
Fintek setup on 3.16 failed on 3.17 and later. Fix this by shortening
the trailer check to 6 units (allowing for a previous space in the
received remote command).
Signed-off-by: Jonathan McDowell
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117221
Cc: sta...@vger.kernel.org
-
diff --git a/drivers/media/rc/ir-rc5-decoder.c
b/drivers/media/rc/ir-rc5-decoder.c
index 6ffe776..a0fd4e6 100644
--- a/drivers/media/rc/ir-rc5-decoder.c
+++ b/drivers/media/rc/ir-rc5-decoder.c
@@ -29,7 +29,7 @@
#define RC5_BIT_START (1 * RC5_UNIT)
#define RC5_BIT_END(1 * RC5_UNIT)
#define RC5X_SPACE (4 * RC5_UNIT)
-#define RC5_TRAILER(10 * RC5_UNIT) /* In reality, approx 100 */
+#define RC5_TRAILER(6 * RC5_UNIT) /* In reality, approx 100 */
enum rc5_state {
STATE_INACTIVE,
-
J.
--
What did the first punk rock girl wear to your school?
Re: dlopen() and ELF alternatives
On Sat, May 14, 2016 at 11:41:54AM -0500, Chad Brewbaker wrote: > In 2016 we are still relying on flat file databases to store binaries. This is not a discussion club; cut the rethorics if you want to be taken seriously. You sound as if the only problem you have is that format is insufficiently buzzword-compliant; if that's the case, nobody is going to give a damn, obviously. If you *do* have more specific problem, have a courtesy to describe it... > I am looking for prior attempts at alternative interfaces to dlopen(), and > alternative formats for object files. There had been a plenty of object file formats; take a look at libbfd for a sample of that panopticum.
Re: [PATCH] watchdog: core: Fix circular locking dependency
On 05/14/2016 10:07 AM, Guenter Roeck wrote: Hi Wim, On 05/14/2016 09:41 AM, Wim Van Sebroeck wrote: Hi Guenter, lockdep reports the following circular locking dependency. You are faster than me this time. I was just about to send you a pull request. Sorry for being late. The watchdog-next branch in my repository on kernel.org has all patches in my queue, in case you want to have a look. I'll rebase my branch to yours and see if anything is missing, then send you a pull request on top of it if needed. All there. Looks like you picked it up right after I updated the branch this morning. This patch has been added to linux-watchdog-next. This patch should probably be tagged for v4.6. Turns out it has a Fixes: tag, so an additional tag should not be necessary. Thanks, Guenter
Re: [PATCH] watchdog: core: Fix circular locking dependency
Hi Wim, On 05/14/2016 09:41 AM, Wim Van Sebroeck wrote: Hi Guenter, lockdep reports the following circular locking dependency. You are faster than me this time. I was just about to send you a pull request. Sorry for being late. The watchdog-next branch in my repository on kernel.org has all patches in my queue, in case you want to have a look. I'll rebase my branch to yours and see if anything is missing, then send you a pull request on top of it if needed. This patch has been added to linux-watchdog-next. This patch should probably be tagged for v4.6. Thanks, Guenter
Re: [PATCH v4 1/3] ARM64: dts: rockchip: make rk3399's grf a "simple-mfd"
Am Freitag, 13. Mai 2016, 15:12:02 schrieb Brian Norris: > Per the examples in > Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt, we need the > grf node to be a simple-mfd in order to properly enumerate child devices > like our eMMC PHY. > > Signed-off-by: Brian Norris applied all 3 for 4.8 with the received Reviews. Please keep the arm64 lower-case and carry over already received Acks/Reviews (Shawn and Doug on patch2 in v2). Thanks Heiko
Re: [PATCH] watchdog: qcom: Report reboot reason
Hi Guenter, > The Qualcom watchdog timer block reports if the system was reset by the > watchdog. Pass the information to user space. > > Cc: Grant Grundler > Signed-off-by: Guenter Roeck > --- > drivers/watchdog/qcom-wdt.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) This patch has been added into linux-watchdog-next. Kind regards, Wim.
Re: [PATCH 2/5] watchdog: octeon: Handle the FROZEN hot plug notifier actions.
Hi Richard, > When performing a suspend operation, the kernel brings all of the > non-boot CPUs offline, calling the hot plug notifiers with the flag, > CPU_TASKS_FROZEN, set in the action code. Similarly, during resume, > the CPUs are brought back online, but again the notifiers have the > FROZEN flag set. > > While some very few drivers really need to treat suspend/resume > specially, this driver unintentionally ignores the notifications. > > This patch changes the driver to disable the watchdog interrupt > whenever the CPU goes offline, and to enable it whenever the CPU goes > back online. As a result, the suspended state is no longer a special > case that leaves the watchdog active. > > Cc: Wim Van Sebroeck > Cc: Guenter Roeck > Cc: linux-watch...@vger.kernel.org > Signed-off-by: Richard Cochran > --- > drivers/watchdog/octeon-wdt-main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) This patch has been added to linux-watchdog-next. Kind regards, Wim.
Re: [PATCH 2/3] iio: st_sensors: Disable DRDY at init time
On 13/05/16 19:43, Crestez Dan Leonard wrote:
> This fixes odd behavior after reboot.
>
> The fact that we set the device to powerdown mode is not sufficient to
> prevent DRDY being active because we might still have an unread sample.
>
> Even if powerdown was sufficient keeping DRDY disabled while trigger is
> not active is a good idea.
>
> Cc: Linus Walleij
> Cc: Giuseppe Barba
> Cc: Denis Ciocca
> Signed-off-by: Crestez Dan Leonard
Again, this one seems obviously correct to me, but would like Denis Ack.
Jonathan
> ---
> drivers/iio/common/st_sensors/st_sensors_core.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c
> b/drivers/iio/common/st_sensors/st_sensors_core.c
> index 928ee68..9e59c90 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_core.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_core.c
> @@ -363,6 +363,11 @@ int st_sensors_init_sensor(struct iio_dev *indio_dev,
> if (err < 0)
> return err;
>
> + /* Disable DRDY, this might be still be enabled after reboot. */
> + err = st_sensors_set_dataready_irq(indio_dev, false);
> + if (err < 0)
> + return err;
> +
> if (sdata->current_fullscale) {
> err = st_sensors_set_fullscale(indio_dev,
> sdata->current_fullscale->num);
>
Re: [PATCH 1/3] iio: st_sensors: Init trigger before irq request
On 13/05/16 19:43, Crestez Dan Leonard wrote:
> This fixes a possible race where an interrupt arrives before complete
> initialization and crashes because iio_trigger_get_drvdata returns NULL.
>
> Cc: Linus Walleij
> Cc: Giuseppe Barba
> Cc: Denis Ciocca
> Signed-off-by: Crestez Dan Leonard
Looks 'obviously' correct to me, but I'd like Denis to confirm on this one.
Jonathan
> ---
> I ran into this while breaking the driver. But since the interrupt line can be
> shared the handler should always be able to accept and ignore a call.
>
> drivers/iio/common/st_sensors/st_sensors_trigger.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/common/st_sensors/st_sensors_trigger.c
> b/drivers/iio/common/st_sensors/st_sensors_trigger.c
> index 98bd5b3..7c2e6ab 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_trigger.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_trigger.c
> @@ -89,6 +89,10 @@ int st_sensors_allocate_trigger(struct iio_dev *indio_dev,
> return -ENOMEM;
> }
>
> + iio_trigger_set_drvdata(sdata->trig, indio_dev);
> + sdata->trig->ops = trigger_ops;
> + sdata->trig->dev.parent = sdata->dev;
> +
> irq = sdata->get_irq_data_ready(indio_dev);
> irq_trig = irqd_get_trigger_type(irq_get_irq_data(irq));
> /*
> @@ -150,10 +154,6 @@ int st_sensors_allocate_trigger(struct iio_dev
> *indio_dev,
> goto iio_trigger_free;
> }
>
> - iio_trigger_set_drvdata(sdata->trig, indio_dev);
> - sdata->trig->ops = trigger_ops;
> - sdata->trig->dev.parent = sdata->dev;
> -
> err = iio_trigger_register(sdata->trig);
> if (err < 0) {
> dev_err(&indio_dev->dev, "failed to register iio trigger.\n");
>
Re: [v4.6-rc7-183-g1410b74e4061]
On Sat, May 14, 2016 at 2:22 AM, Sedat Dilek wrote:
> Hi,
>
> as Linux v4.6 is very near, I decided to write this bug report (only
> drunk one coffee).
>
> First, I am not absolutely sure if this is a real issue as...
> #1: This is only a (lockdep) warning.
> #2: I have not a "vanilla" Linux v4.6-rc7+ here (see P.S. and attached patch)
>
> For a more helpful feedback I should test a...
> #1: vanilla v4.6-rc7-183-g1410b74e4061
> #2: net.git#master on top of #1
>
> What I am seeing is this while surfing with a UMTS/HSPA internet-stick
> (using PPP) and running Firefox on Ubuntu/precise AMD64...
>
> [ 423.484105] [ cut here ]
> [ 423.484119] WARNING: CPU: 2 PID: 2392 at
> kernel/locking/lockdep.c:2098 __lock_acquire
> [ 423.484123] DEBUG_LOCKS_WARN_ON(chain_hlocks[chain->base
> [ 423.484125] Modules linked in: btrfs xor raid6_pq ntfs xfs
> libcrc32c ppp_deflate bsd_comp ppp_async crc_ccitt option usb_wwan
> cdc_ether usbserial usbnet snd_hda_codec_hdmi i915
> snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel
> snd_hda_codec arc4 uvcvideo iwldvm snd_hwdep joydev mac80211
> videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core
> videodev rfcomm bnep kvm_intel kvm usb_storage btusb i2c_algo_bit
> iwlwifi btrtl snd_hda_core drm_kms_helper btbcm snd_pcm parport_pc
> btintel syscopyarea irqbypass ppdev snd_seq_midi bluetooth sysfillrect
> psmouse snd_seq_midi_event sysimgblt snd_rawmidi fb_sys_fops cfg80211
> snd_seq drm serio_raw snd_timer samsung_laptop snd_seq_device snd
> soundcore wmi mac_hid video intel_rst lpc_ich lp parport binfmt_misc
> hid_generic usbhid hid r8169 mii
> [ 423.484241] CPU: 2 PID: 2392 Comm: firefox Not tainted
> 4.6.0-rc7-183.1-iniza-small #1
> [ 423.484244] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> [ 423.484247] 88011fa83910 81413825
> 88011fa83960
> [ 423.484253] 88011fa83950 81083ea1
> 083282f34ec0
> [ 423.484259] 0005 880082f34540
> 0027
> [ 423.484265] Call Trace:
> [ 423.484268][] dump_stack
> [ 423.484280] [] __warn
> [ 423.484285] [] warn_slowpath_fmt
> [ 423.484289] [] __lock_acquire
> [ 423.484294] [] ? __lock_acquire
> [ 423.484298] [] ? __lock_acquire
> [ 423.484302] [] lock_acquire
> [ 423.484307] [] ? __dev_queue_xmit
> [ 423.484313] [] _raw_spin_lock
> [ 423.484317] [] ? __dev_queue_xmit
> [ 423.484321] [] __dev_queue_xmit
> [ 423.484326] [] ? __dev_queue_xmit
> [ 423.484330] [] dev_queue_xmit
> [ 423.484334] [] neigh_direct_output
> [ 423.484339] [] ip_finish_output2
> [ 423.484344] [] ? ip_finish_output2
> [ 423.484349] [] ip_finish_output
> [ 423.484353] [] ip_output
> [ 423.484357] [] ? __lock_is_held
> [ 423.484362] [] ip_local_out
> [ 423.484366] [] ip_queue_xmit
> [ 423.484371] [] ? ip_queue_xmit
> [ 423.484376] [] tcp_transmit_skb
> [ 423.484380] [] __tcp_retransmit_skb
> [ 423.484385] [] tcp_retransmit_skb
> [ 423.484389] [] tcp_retransmit_timer
> [ 423.484394] [] ? tcp_write_timer_handler
> [ 423.484398] [] tcp_write_timer_handler
> [ 423.484402] [] tcp_write_timer
> [ 423.484407] [] call_timer_fn
> [ 423.484411] [] ? call_timer_fn
> [ 423.484416] [] ? tcp_write_timer_handler
> [ 423.484419] [] run_timer_softirq
> [ 423.484424] [] __do_softirq
> [ 423.484428] [] irq_exit
> [ 423.484432] [] smp_apic_timer_interrupt
> [ 423.484437] [] apic_timer_interrupt
> [ 423.484439]
> [ 423.484443] ---[ end trace a29d8ee0ef420d5c ]---
> [ 423.484446]
> [ 423.484447] ==
> [ 423.484449] [chain_key collision ]
> [ 423.484452] 4.6.0-rc7-183.1-iniza-small #1 Tainted: GW
> [ 423.484454] --
> [ 423.484457] firefox/2392: Hash chain already cached but the
> contents don't match!
> [ 423.484460] Held locks:depth: 6
> [ 423.484463] class_idx:1993 -> chain_key:07c9
> (((&icsk->icsk_retransmit_timer))){
> [ 423.484473] class_idx:1334 -> chain_key:00f92536 (slock-AF_INET){
> [ 423.484482] class_idx:33 -> chain_key:001f24a6c021
> (rcu_read_lock){..}, at: [] ip_queue_xmit
> [ 423.484492] class_idx:1005 -> chain_key:0003e494d80423ed
> (rcu_read_lock_bh){..}, at: [] ip_finish_output2
> [ 423.484500] class_idx:1005 -> chain_key:7c929b00847da3ed
> (rcu_read_lock_bh){..}, at: [] __dev_queue_xmit
> [ 423.484509] class_idx:1996 -> chain_key:5360108fb47da85e
> (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){
> [ 423.484517] Locks in cached chain:depth: 6
> [ 423.484520] class_idx:1998 -> chain_key:07ce
> (((&sk->sk_timer))){
> [ 423.484525] class_idx:1334 -> chain_key:00f9c536 (slock-AF_INET){
> [ 423.484531] class_idx:33 -> chain_key:001f38a6c021
> (rcu_read_lock){..}
> [ 423.484536] class_idx:1005 -> chain_key:0003e714d80423ed
> (rcu_read_lock_
Re: [PATCH] sp5100_tco: properly check for new register layouts
Hi Lucas, > Commits 190aa4304de6 (Add AMD Mullins platform support) and > cca118fa2a0a94 (Add AMD Carrizo platform support) enabled the > driver on a lot more devices, but the following commit missed > a single location in the code when checking if the SB800 register > offsets should be used. This leads to the wrong register being > written which in turn causes ACPI to go haywire. > > Fix this by introducing a helper function to check for the new > register layout and use this consistently. > > https://bugzilla.kernel.org/show_bug.cgi?id=114201 > https://bugzilla.redhat.com/show_bug.cgi?id=1329910 > Fixes: bdecfcdb5461 (sp5100_tco: fix the device check for SB800 > and later chipsets) > Cc: sta...@vger.kernel.org (4.5+) > Signed-off-by: Lucas Stach > --- > drivers/watchdog/sp5100_tco.c | 15 ++- > 1 file changed, 10 insertions(+), 5 deletions(-) > This patch has been added to linux-watchdog-next. Kind regards, Wim.
dlopen() and ELF alternatives
In 2016 we are still relying on flat file databases to store binaries. I am looking for prior attempts at alternative interfaces to dlopen(), and alternative formats for object files. Gist link if you would like to discuss off-list: https://gist.github.com/chadbrewbaker/e7020383c4a37e84414a7cf3cdab7b32
Re: [PATCH] watchdog: core: Fix circular locking dependency
Hi Guenter,
> lockdep reports the following circular locking dependency.
>
> ==
> INFO: possible circular locking dependency detected ]
> 4.6.0-rc3-00191-gfabf418 #162 Not tainted
> ---
> systemd/1 is trying to acquire lock:
> ((&(&wd_data->work)->work)){+.+...}, at: [<80141650>] flush_work+0x0/0x280
>
> but task is already holding lock:
>
> (&wd_data->lock){+.+...}, at: [<804acfa8>] watchdog_release+0x18/0x190
>
> which lock already depends on the new lock.
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&wd_data->lock){+.+...}:
> [<80662310>] mutex_lock_nested+0x64/0x4a8
> [<804aca4c>] watchdog_ping_work+0x18/0x4c
> [<80143128>] process_one_work+0x1ac/0x500
> [<801434b4>] worker_thread+0x38/0x554
> [<80149510>] kthread+0xf4/0x108
> [<80107c10>] ret_from_fork+0x14/0x24
>
> -> #0 ((&(&wd_data->work)->work)){+.+...}:
> [<8017c4e8>] lock_acquire+0x70/0x90
> [<8014169c>] flush_work+0x4c/0x280
> [<801440f8>] __cancel_work_timer+0x9c/0x1e0
> [<804acfcc>] watchdog_release+0x3c/0x190
> [<8022c5e8>] __fput+0x80/0x1c8
> [<80147b28>] task_work_run+0x94/0xc8
> [<8010b998>] do_work_pending+0x8c/0xb4
> [<80107ba8>] slow_work_pending+0xc/0x20
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0CPU1
>
> lock(&wd_data->lock);
> lock((&(&wd_data->work)->work));
> lock(&wd_data->lock);
> lock((&(&wd_data->work)->work));
>
> *** DEADLOCK ***
>
> 1 lock held by systemd/1:
>
> stack backtrace:
> CPU: 2 PID: 1 Comm: systemd Not tainted 4.6.0-rc3-00191-gfabf418 #162
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [<8010f5e4>] (unwind_backtrace) from [<8010c038>] (show_stack+0x10/0x14)
> [<8010c038>] (show_stack) from [<8039d7fc>] (dump_stack+0xa8/0xd4)
> [<8039d7fc>] (dump_stack) from [<80177ee0>] (print_circular_bug+0x214/0x334)
> [<80177ee0>] (print_circular_bug) from [<80179230>]
> (check_prevs_add+0x4dc/0x8e8)
> [<80179230>] (check_prevs_add) from [<8017b3d8>] (__lock_acquire+0xc6c/0x14ec)
> [<8017b3d8>] (__lock_acquire) from [<8017c4e8>] (lock_acquire+0x70/0x90)
> [<8017c4e8>] (lock_acquire) from [<8014169c>] (flush_work+0x4c/0x280)
> [<8014169c>] (flush_work) from [<801440f8>] (__cancel_work_timer+0x9c/0x1e0)
> [<801440f8>] (__cancel_work_timer) from [<804acfcc>]
> (watchdog_release+0x3c/0x190)
> [<804acfcc>] (watchdog_release) from [<8022c5e8>] (__fput+0x80/0x1c8)
> [<8022c5e8>] (__fput) from [<80147b28>] (task_work_run+0x94/0xc8)
> [<80147b28>] (task_work_run) from [<8010b998>] (do_work_pending+0x8c/0xb4)
> [<8010b998>] (do_work_pending) from [<80107ba8>] (slow_work_pending+0xc/0x20)
>
> Turns out the call to cancel_delayed_work_sync() in watchdog_release()
> is not necessary and can be dropped. If the worker is no longer necessary,
> the subsequent call to watchdog_update_worker() will cancel it. If it is
> already running, it won't do anything, since the worker function checks
> if it needs to ping the watchdog or not.
>
> Reported-by: Clemens Gruber
> Tested-by: Clemens Gruber
> Fixes: 11d7aba9ceb7 ("watchdog: imx2: Convert to use infrastructure triggered
> keepalives")
> Signed-off-by: Guenter Roeck
> ---
> drivers/watchdog/watchdog_dev.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index e2c5abbb45ff..3595cffa24ea 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -736,7 +736,6 @@ static int watchdog_release(struct inode *inode, struct
> file *file)
> watchdog_ping(wdd);
> }
>
> - cancel_delayed_work_sync(&wd_data->work);
> watchdog_update_worker(wdd);
>
> /* make sure that /dev/watchdog can be re-opened */
> --
> 2.5.0
>
This patch has been added to linux-watchdog-next.
Kind regards,
Wim.
Re: [PATCH 1/4] signals/sigaltstack: If SS_AUTODISARM, bypass on_sig_stack
On May 14, 2016 4:18 AM, "Stas Sergeev" wrote:
>
> 14.05.2016 07:18, Andy Lutomirski пишет:
>
>> On May 8, 2016 7:05 PM, "Stas Sergeev" wrote:
>>>
>>> 09.05.2016 04:32, Andy Lutomirski пишет:
>>>
On May 7, 2016 7:38 AM, "Stas Sergeev" wrote:
>
> 03.05.2016 20:31, Andy Lutomirski пишет:
>
>> If a signal stack is set up with SS_AUTODISARM, then the kernel
>> inherently avoids incorrectly resetting the signal stack if signals
>> recurse: the signal stack will be reset on the first signal
>> delivery. This means that we don't need check the stack pointer
>> when delivering signals if SS_AUTODISARM is set.
>>
>> This will make segmented x86 programs more robust: currently there's
>> a hole that could be triggered if ESP/RSP appears to point to the
>> signal stack but actually doesn't due to a nonzero SS base.
>>
>> Signed-off-by: Stas Sergeev
>> Cc: Al Viro
>> Cc: Aleksa Sarai
>> Cc: Amanieu d'Antras
>> Cc: Andrea Arcangeli
>> Cc: Andrew Morton
>> Cc: Andy Lutomirski
>> Cc: Borislav Petkov
>> Cc: Brian Gerst
>> Cc: Denys Vlasenko
>> Cc: Eric W. Biederman
>> Cc: Frederic Weisbecker
>> Cc: H. Peter Anvin
>> Cc: Heinrich Schuchardt
>> Cc: Jason Low
>> Cc: Josh Triplett
>> Cc: Konstantin Khlebnikov
>> Cc: Linus Torvalds
>> Cc: Oleg Nesterov
>> Cc: Palmer Dabbelt
>> Cc: Paul Moore
>> Cc: Pavel Emelyanov
>> Cc: Peter Zijlstra
>> Cc: Richard Weinberger
>> Cc: Sasha Levin
>> Cc: Shuah Khan
>> Cc: Tejun Heo
>> Cc: Thomas Gleixner
>> Cc: Vladimir Davydov
>> Cc: linux-...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Andy Lutomirski
>> ---
>> include/linux/sched.h | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>> index 2950c5cd3005..8f03a93348b9 100644
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -2576,6 +2576,18 @@ static inline int kill_cad_pid(int sig, int priv)
>> */
>> static inline int on_sig_stack(unsigned long sp)
>> {
>> + /*
>> +* If the signal stack is AUTODISARM then, by construction, we
>> +* can't be on the signal stack unless user code deliberately set
>> +* SS_AUTODISARM when we were already on the it.
>
> "on the it" -> "on it".
>
> Anyway, I am a bit puzzled with this patch.
> You say "unless user code deliberately set
>
> SS_AUTODISARM when we were already on the it"
> so what happens in case it actually does?
>
Stack corruption. Don't do that.
>>>
>>> Only after your change, I have to admit. :)
>>>
>>>
> Without your patch: if user sets up the same sas - no stack switch.
> if user sets up different sas - stack switch on nested signal.
>
> With your patch: stack switch in any case, so if user
> set up same sas - stack corruption by nested signal.
>
> Or am I missing the intention?
The intention is to make everything completely explicit. With
SS_AUTODISARM, the kernel knows directly whether you're on the signal
stack, and there should be no need to look at sp. If you set
SS_AUTODISARM and get a signal, the signal stack gets disarmed. If
you take a nested signal, it's delivered normally. When you return
all the way out, the signal stack is re-armed.
For DOSEMU, this means that no 16-bit register state can possibly
cause a signal to be delivered wrong, because the register state when
a signal is raised won't affect delivery, which seems like a good
thing to me.
>>>
>>> Yes, but doesn't affect dosemu1 which doesn't use SS_AUTODISARM.
>>> So IMHO the SS check should still be added, even if not for dosemu2.
>>>
>>>
If this behavior would be problematic for you, can you explain why?
>>>
>>> Only theoretically: if someone sets SS_AUTODISARM inside a
>>> sighandler. Since this doesn't give EPERM, I wouldn't deliberately
>>> make it a broken scenario (esp if it wasn't before the particular change).
>>> Ideally it would give EPERM, but we can't, so doesn't matter much.
>>> I just wanted to warn about the possible regression.
>>
>> I suppose we could return an error if you are on the sigstack when
>> setting SS_AUTODISARM, although I was hoping to avoid yet more special
>> cases.
>
> Hmm.
> How about extending the generic check then?
> Currently it is roughly:
> if (on_sig_stack(sp)) return -EPERM;
>
> and we could do:
> if (on_sig_stack(sp) || on_new_sas(new_sas, sp)) return -EPERM;
>
> Looks like it will close the potential hole opened by your commit
> without introducing the special case for SS_AUTODISARM.
> What do you think?
>
It's still a wee bit ugly. Also, doesn't that change existing
behavior for the existing non-AUTODISARM
Re: next: Build errors due to 'MIPS: Add probing & defs for VZ & guest features'
Hi James, On 05/14/2016 08:52 AM, James Hogan wrote: On Sat, May 14, 2016 at 08:19:50AM -0700, Guenter Roeck wrote: James, your patch 'MIPS: Add probing & defs for VZ & guest features' causes build errors in -next when using gcc 4.7.4 / binutils 2.24. This affects almost all mips builds. Thanks Guenter. Hmm, I thought virt extensions were supported since binutils 2.24, odd. Actually, turns out it was binutils 2.22 (from the compiler that came with poky 1.3). Sorry for the confusion. Guenter
Re: [PATCH 3/3] iio: st_sensors: Use level interrupts
On 13/05/16 19:43, Crestez Dan Leonard wrote: > As far as I can tell DRDY for ST sensors behaves as a level rather than > edge interrupt. Registering for IRQF_TRIGGER_RISING instead of > IRQF_TRIGGER_HIGH mostly works except when the sampling frequency is > high enough that new samples come before the new ones are read > completely. In that case the interrupt line remains high, no more rising > edges occur and the iio buffer stalls. > > Configuring the interrupt as IRQF_TRIGGER_HIGH makes it work as > expected. This patch makes it so that st_sensors_trigger interrupt > request code doesn't mangle the request flags into IRQF_TRIGGER_RISING. > > Cc: Linus Walleij > Cc: Giuseppe Barba > Cc: Denis Ciocca > Signed-off-by: Crestez Dan Leonard > --- > This is an alternative fix to this patch: > https://www.spinics.net/lists/linux-iio/msg24722.html > [PATCH 2/2 v6] iio: st_sensors: read surplus samples in trigger. > > It's not clear if all st_sensors behave this way on DRDY. If they do it might > be better to always request HIGH even if the interrupt is initially configured > for RISING. > > I tested on MinnowBoard Max which uses pinctrl-baytrail for gpio irqs. I > initially tested hacking the irq_trig to IRQF_TRIGGER_HIGH with an usb adaptor > (gpio-dln2) and it didn't work but I think that's because that driver doesn't > handle persistently high irqs properly. Hi Leonard / Linus, I thought my memory was failing me a little when I read Linus' patch description where he mentioned that we were missing pulsed interrupts. Years ago (probably at least 8) I ran into this exact issue with the lis3l02dq and spent sometime with a scope tracking down the cause (this was way before threaded interrupt etc were in mainline). Anyhow, my recollection was that we didn't always get a gap between the pulses. Hence it was possible to cross reading the registers with new data coming in for other channels and never see it drop. Distinctly remember scratching my head over how to deal with this for some time. The snag I had was that I was working with an intel stargate 2 with a pxa27x which didn't have any level interrupt support. Hence I ended up with a cludge that checked the gpio itself (was easier back then as you could get the gpio from the IRQ :) and did a bonus read with no processing to hammer it down and get out of being stuck. Linus' checking the data ready register and firing another trigger was the equivalent of this (back then we didn't have the two polling methods). You can still see my hack in staging/iio/accel/lis3l02dq_ring.c in try_reenable. Note the tryreenable was an attempt to bring sanity checking whether we need a repeat poll into one place and push the repeat polling into the core - which only works if all drivers hanging off the trigger can work fine with threaded interrupts only. Right now I think the try_reenable stuff has been broken for a long time... It will call iio_trigger_poll from a thread (typically). Obviously missed this one when we converted over to threaded interrupts (hmm) Need to audit if that can ever be called from interrupt context (to avoid making things worse!) If that was fixed then we could use it for Linus's reread but it suffers the same issue with no limit on the number of times it can go around (so that would want fixing as well!) This patch doesn't make things worse as I read it - except in the case where no interrupt type is specified... In that case it will try to make it high which may not be supported. Note that (if I'd merged the lis3l02dq driver in as I've been meaning too for a long time) this would just have broken my boards.. (can we check if the interrupt supports it and fall back to the original default if not? - it's even more comic on my board as IIRC the interrupt is shared via a discrete NAND gate with a tsl2561 so everything is flipped as well) The other question is how many users have one of these hooked up to an irq that doesn't support level interrupts (such as my pxa27x - which I fire up every few months - or your gpio-dln2 adapter). If so I guess we aren't making things any worse for them but the issue you had still exists + I still can't port my lis3l02dq driver over... I wonder if we ultimately end up having to support both fixes (though the one I did originally and Linus effectively reinvented is hideous :) If level interrupts are specified then yours is great and simple, if we edge interrupts are specified we have to play games to fake a level interrupt. Note that way back when I asked if anyone had any generic code for doing exactly this and got the answer 'It's too fiddly' IIRC - and I don't think anyone has ever taken it on since... I'm also inclined on this fix in general to send it the slow route (next merge window) rather than rushing it through. It's invasive and it's not as though we are looking at a regression here. The other fix is a totally different matter and I'll pick that up shortly. So in conclusion
Re: [PATCH 0/9] kernel-doc/docproc prep work for reStructuredText
On Thu, 12 May 2016 16:15:35 +0300 Jani Nikula wrote: > Jon, I was hoping we could consider nudging things forward a bit in the > kernel-doc and docproc reStructuredText front already in 4.7. I know > it's a bit close to the merge window, but this should not interfere with > anything else, and some of it are just trivial cleanups that I've been > carrying around locally. > > Obviously this doesn't actually add anything that uses them yet, but I > think it would be helpful to have some common base in to ease > collaboration. Yeah, I think I agree; it's really time to make something actually happen here. I'll push these into linux-next and, almost certainly, into 4.7 as well. Thanks for putting the series together. jon
Re: next: Build errors due to 'MIPS: Add probing & defs for VZ & guest features'
On Sat, May 14, 2016 at 08:19:50AM -0700, Guenter Roeck wrote:
> James,
>
> your patch 'MIPS: Add probing & defs for VZ & guest features' causes build
> errors
> in -next when using gcc 4.7.4 / binutils 2.24. This affects almost all mips
> builds.
Thanks Guenter. Hmm, I thought virt extensions were supported since
binutils 2.24, odd.
I'll look into implementing a workaround for toolchains that don't
support it.
Cheers
James
>
> {standard input}: Assembler messages:
> {standard input}:3306: Warning: Tried to set unrecognized symbol: virt
> {standard input}:3307: Error: Unrecognized opcode `mfgc0 $3,$16,0'
>
> and lots of similar messages when building arch/mips/kernel/cpu-probe.o.
>
> Build is fine with gcc 5.2.0 and binutils 2.5.
>
> Bisect log is attached.
>
> Guenter
>
> ---
> Bisect log:
>
> # bad: [7fd1a8676b7f573be6aa8072e8fa1d4f1bbf8ea7] Add linux-next specific
> files for 20160513
> # good: [44549e8f5eea4e0a41b487b63e616cb089922b99] Linux 4.6-rc7
> git bisect start 'HEAD' 'v4.6-rc7'
> # bad: [d573c57f72f32687ed2d11ba60ee5e6f5746ccde] Merge remote-tracking
> branch 'crypto/master'
> git bisect bad d573c57f72f32687ed2d11ba60ee5e6f5746ccde
> # bad: [cea0bc891cbcb9cd57a95c0fe03cb16ce3716125] Merge branch
> 'jdelvare-hwmon/master'
> git bisect bad cea0bc891cbcb9cd57a95c0fe03cb16ce3716125
> # good: [ffa24f116d6f3925e0eebcd4d4ae30d9ac237459] Merge remote-tracking
> branch 'tegra/for-next'
> git bisect good ffa24f116d6f3925e0eebcd4d4ae30d9ac237459
> # bad: [cb4699056080a4a094be6080e10c692af0794d93] Merge remote-tracking
> branch 'btrfs-kdave/for-next'
> git bisect bad cb4699056080a4a094be6080e10c692af0794d93
> # bad: [9f2e34d4ff5756624948fe7976866749664793c7] Merge remote-tracking
> branch 'mips/mips-for-linux-next'
> git bisect bad 9f2e34d4ff5756624948fe7976866749664793c7
> # good: [fe33223366b2c02394274395f4ac43e48c453654] MIPS: Separate XPA CPU
> feature into LPA and MVH
> git bisect good fe33223366b2c02394274395f4ac43e48c453654
> # good: [5eae0ba2589f767b5c9c14e662f972084b4a46d7] Merge remote-tracking
> branch 'arm64/for-next/core'
> git bisect good 5eae0ba2589f767b5c9c14e662f972084b4a46d7
> # bad: [9ca0b767b011347402eb083f887629b27c8eda54] Merge branch '4.6-fixes'
> into mips-for-linux-next
> git bisect bad 9ca0b767b011347402eb083f887629b27c8eda54
> # good: [128639395b2ceacc6a56a0141d0261012bfe04d3] MIPS: Adjust set_pte() SMP
> fix to handle R1_LLSC_WAR
> git bisect good 128639395b2ceacc6a56a0141d0261012bfe04d3
> # good: [6768a2c2e1310acb3e8e8e63a6e2caa146d19d0e] MIPS: BMIPS: BMIPS4380 and
> BMIPS5000 support RIXI
> git bisect good 6768a2c2e1310acb3e8e8e63a6e2caa146d19d0e
> # good: [c1b01a9f21daaf269d77683a4f91f423254f0c3e] MIPS: Add perf counter
> feature
> git bisect good c1b01a9f21daaf269d77683a4f91f423254f0c3e
> # bad: [354d36f4304a14aced7e4ffb0d27038cd19b532f] MIPS: Add probing & defs
> for VZ & guest features
> git bisect bad 354d36f4304a14aced7e4ffb0d27038cd19b532f
> # good: [b7c0199bf7404e87839ad633e699370ed397d548] MIPS: Add register
> definitions for VZ ASE registers
> git bisect good b7c0199bf7404e87839ad633e699370ed397d548
> # good: [cf5c5ac39a33127caa3e4e97f52754a6feede8fd] MIPS: Add guest CP0
> accessors
> git bisect good cf5c5ac39a33127caa3e4e97f52754a6feede8fd
> # first bad commit: [354d36f4304a14aced7e4ffb0d27038cd19b532f] MIPS: Add
> probing & defs for VZ & guest features
>
signature.asc
Description: Digital signature
Re: next: suspicious RCU usage message since commit 'rcu: Remove superfluous versions of rcu_read_lock_sched_held()'
On 04/25/2016 01:49 PM, Paul E. McKenney wrote: On Mon, Apr 25, 2016 at 01:25:10PM -0700, Guenter Roeck wrote: On Mon, Apr 25, 2016 at 10:12:39AM -0700, Paul E. McKenney wrote: On Sun, Apr 24, 2016 at 11:26:41PM -0700, Guenter Roeck wrote: On 04/24/2016 10:49 PM, Paul E. McKenney wrote: On Sun, Apr 24, 2016 at 10:37:25PM -0700, Guenter Roeck wrote: On 04/24/2016 10:28 PM, Paul E. McKenney wrote: On Sun, Apr 24, 2016 at 04:56:38PM -0700, Guenter Roeck wrote: [ . . . ] After making the same change in _pwrdm_state_switch(), the traceback is gone >from my tests (beagle, beagle-xm, and overo-tobi). Very good! (And yes, you normally find these one at a time...) Are you going to submit a formal patch ? I can, but please feel free to send mine along with yours, if you wish. I think it would be best if you send a single patch which fixes both calls. Like this one? If so, could you please run it to make sure that it actually fixes the problem? And if it does, would you be willing to give me a Tested-by? It does. Tested-by: inline below. Got it, thank you! If the ARM guys are willing to take this, it might hit the next merge window, or perhaps they will take it as an exception. If I push it up my usual route, it will be a bit later. I just now sent it out, so hopefully they will grab it. ;-) The problem is still seen in next-20160513, so it looks like the patch was not accepted. I recently learned that arm has a special way of submitting patches. See http://www.arm.linux.org.uk/developer/patches/ for details. If I understand correctly, you'll have to send the patch to patc...@arm.linux.org.uk, and it has to be formatted correctly (eg no "[PATCH]" in the subject line, and some other information added). I never tried it myself, so I don't really know how exactly it works. Guenter
Re: Additional compiler barrier required in sched_preempt_enable_no_resched?
On Fri, 13 May 2016, Vikram Mulukutla wrote:
> On 5/13/2016 7:58 AM, Peter Zijlstra wrote:
> > diff --git a/include/asm-generic/preempt.h b/include/asm-generic/preempt.h
> > index 5d8ffa3e6f8c..c1cde3577551 100644
> > --- a/include/asm-generic/preempt.h
> > +++ b/include/asm-generic/preempt.h
> > @@ -7,10 +7,10 @@
> >
> > static __always_inline int preempt_count(void)
> > {
> > - return current_thread_info()->preempt_count;
> > + return READ_ONCE(current_thread_info()->preempt_count);
> > }
> >
> > -static __always_inline int *preempt_count_ptr(void)
> > +static __always_inline volatile int *preempt_count_ptr(void)
> > {
> > return ¤t_thread_info()->preempt_count;
> > }
> >
>
> Thanks Peter, this patch worked for me. The compiler no longer optimizes out
> the increment/decrement of the preempt_count.
I have a hard time to understand why the compiler optimizes out stuff w/o that
patch.
We already have:
#define preempt_disable() \
do { \
preempt_count_inc(); \
barrier(); \
} while (0)
#define sched_preempt_enable_no_resched() \
do { \
barrier(); \
preempt_count_dec(); \
} while (0)
#define preempt_enable() \
do { \
barrier(); \
if (unlikely(preempt_count_dec_and_test())) \
__preempt_schedule(); \
} while (0)
So the barriers already forbid that the compiler reorders code. How on earth
is the compiler supposed to optimize the dec/inc out?
There is more code than the preempt stuff depending on barrier() and expecting
that the compiler does not optimize out things at will. Are we supposed to
hunt all occurences and amend them with READ_ONCE or whatever one by one?
Thanks,
tglx
Re: [linux-next: May 13] intel/iwlwifi/mvm/mvm.h:1069 suspicious rcu_dereference_protected() usage
On (05/15/16 01:31), Sergey Senozhatsky wrote:
> [11455.550649] ===
> [11455.550652] [ INFO: suspicious RCU usage. ]
> [11455.550657] 4.6.0-rc7-next-20160513-dbg-4-g8de8b92-dirty #655 Not
> tainted
> [11455.550660] ---
> [11455.550664] drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:1069 suspicious
> rcu_dereference_protected() usage!
> [11455.550667]
>other info that might help us debug this:
>
> [11455.550671]
>rcu_scheduler_active = 1, debug_locks = 0
> [11455.550675] 5 locks held by irq/29-iwlwifi/247:
> [11455.550677] #0: (sync_cmd_lockdep_map){..}, at: []
> iwl_pcie_irq_handler+0x0/0x635 [iwlwifi]
> [11455.550705] #1: (&(&rxq->lock)->rlock){+.+...}, at: []
> iwl_pcie_rx_handle+0x38/0x5d5 [iwlwifi]
> [11455.550725] #2: (rcu_read_lock){..}, at: []
> ieee80211_rx_napi+0x152/0x8e2 [mac80211]
> [11455.550768] #3: (&(&local->rx_path_lock)->rlock){+.-...}, at:
> [] ieee80211_rx_handlers+0x2e/0x1fe1 [mac80211]
> [11455.550804] #4: (rcu_read_lock){..}, at: []
> iwl_mvm_update_tkip_key+0x0/0x162 [iwlmvm]
> [11455.550833]
[ 5406.034379] iwlwifi :02:00.0: Queue 16 stuck for 1 ms.
[ 5406.034385] iwlwifi :02:00.0: Current SW read_ptr 98 write_ptr 125
[ 5406.034431] iwl data: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
[ 5406.034454] iwlwifi :02:00.0: FH TRBs(0) = 0x8000300f
[ 5406.034475] iwlwifi :02:00.0: FH TRBs(1) = 0xc0110071
[ 5406.034491] iwlwifi :02:00.0: FH TRBs(2) = 0x
[ 5406.034505] iwlwifi :02:00.0: FH TRBs(3) = 0x8030001e
[ 5406.034520] iwlwifi :02:00.0: FH TRBs(4) = 0x
[ 5406.034536] iwlwifi :02:00.0: FH TRBs(5) = 0x
[ 5406.034551] iwlwifi :02:00.0: FH TRBs(6) = 0x
[ 5406.034566] iwlwifi :02:00.0: FH TRBs(7) = 0x00709087
[ 5406.034625] iwlwifi :02:00.0: Q 0 is active and mapped to fifo 3 ra_tid
0x [31,31]
[ 5406.034690] iwlwifi :02:00.0: Q 1 is active and mapped to fifo 2 ra_tid
0x [0,0]
[ 5406.034756] iwlwifi :02:00.0: Q 2 is active and mapped to fifo 1 ra_tid
0x [17,17]
[ 5406.034821] iwlwifi :02:00.0: Q 3 is active and mapped to fifo 0 ra_tid
0x [16,16]
[ 5406.034886] iwlwifi :02:00.0: Q 4 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.034944] iwlwifi :02:00.0: Q 5 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.035010] iwlwifi :02:00.0: Q 6 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.035068] iwlwifi :02:00.0: Q 7 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.035133] iwlwifi :02:00.0: Q 8 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.035192] iwlwifi :02:00.0: Q 9 is active and mapped to fifo 7 ra_tid
0x [136,136]
[ 5406.035257] iwlwifi :02:00.0: Q 10 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.035323] iwlwifi :02:00.0: Q 11 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.035388] iwlwifi :02:00.0: Q 12 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.035446] iwlwifi :02:00.0: Q 13 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.035505] iwlwifi :02:00.0: Q 14 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.035563] iwlwifi :02:00.0: Q 15 is active and mapped to fifo 5 ra_tid
0x [0,0]
[ 5406.035622] iwlwifi :02:00.0: Q 16 is active and mapped to fifo 1 ra_tid
0x [98,125]
[ 5406.035687] iwlwifi :02:00.0: Q 17 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.035752] iwlwifi :02:00.0: Q 18 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.035817] iwlwifi :02:00.0: Q 19 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.035883] iwlwifi :02:00.0: Q 20 is inactive and mapped to fifo 0
ra_tid 0xfffc [0,0]
[ 5406.035940] iwlwifi :02:00.0: Q 21 is inactive and mapped to fifo 0
ra_tid 0x0003 [0,0]
[ 5406.035999] iwlwifi :02:00.0: Q 22 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.036064] iwlwifi :02:00.0: Q 23 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.036122] iwlwifi :02:00.0: Q 24 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.036188] iwlwifi :02:00.0: Q 25 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.036246] iwlwifi :02:00.0: Q 26 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.036305] iwlwifi :02:00.0: Q 27 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.036370] iwlwifi :02:00.0: Q 28 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.036428] iwlwifi :02:00.0: Q 29 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.036487] iwlwifi :02:00.0: Q 30 is inactive and mapped to fifo 0
ra_tid 0x [0,0]
[ 5406.036555] iwlwifi :02:00.0: Microcode SW error detected. Restarting
0x200.
[ 5406.036558] iwlwifi :02:00.0: CSR values:
[ 5406.0
[linux-next: May 13] intel/iwlwifi/mvm/mvm.h:1069 suspicious rcu_dereference_protected() usage
Hello,
[11455.550649] ===
[11455.550652] [ INFO: suspicious RCU usage. ]
[11455.550657] 4.6.0-rc7-next-20160513-dbg-4-g8de8b92-dirty #655 Not tainted
[11455.550660] ---
[11455.550664] drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:1069 suspicious
rcu_dereference_protected() usage!
[11455.550667]
other info that might help us debug this:
[11455.550671]
rcu_scheduler_active = 1, debug_locks = 0
[11455.550675] 5 locks held by irq/29-iwlwifi/247:
[11455.550677] #0: (sync_cmd_lockdep_map){..}, at: []
iwl_pcie_irq_handler+0x0/0x635 [iwlwifi]
[11455.550705] #1: (&(&rxq->lock)->rlock){+.+...}, at: []
iwl_pcie_rx_handle+0x38/0x5d5 [iwlwifi]
[11455.550725] #2: (rcu_read_lock){..}, at: []
ieee80211_rx_napi+0x152/0x8e2 [mac80211]
[11455.550768] #3: (&(&local->rx_path_lock)->rlock){+.-...}, at:
[] ieee80211_rx_handlers+0x2e/0x1fe1 [mac80211]
[11455.550804] #4: (rcu_read_lock){..}, at: []
iwl_mvm_update_tkip_key+0x0/0x162 [iwlmvm]
[11455.550833]
stack backtrace:
[11455.550840] CPU: 4 PID: 247 Comm: irq/29-iwlwifi Not tainted
4.6.0-rc7-next-20160513-dbg-4-g8de8b92-dirty #655
[11455.550844] 880037ff78e8 81187f9c
88041b7ea980
[11455.550854] 0001 880037ff7918 8106b836
88041bc0e028
[11455.550863] 88041d247878 88041bc0e028
880037ff7938
[11455.550872] Call Trace:
[11455.550883] [] dump_stack+0x68/0x92
[11455.550890] [] lockdep_rcu_suspicious+0xf7/0x100
[11455.550911] [] iwl_mvm_get_key_sta.part.0+0x5d/0x80
[iwlmvm]
[11455.550930] [] iwl_mvm_update_tkip_key+0xd3/0x162 [iwlmvm]
[11455.550945] [] iwl_mvm_mac_update_tkip_key+0x17/0x19
[iwlmvm]
[11455.550973] [] ieee80211_tkip_decrypt_data+0x22c/0x24b
[mac80211]
[11455.550996] [] ieee80211_crypto_tkip_decrypt+0xc5/0x110
[mac80211]
[11455.551026] [] ieee80211_rx_handlers+0x9bb/0x1fe1
[mac80211]
[11455.551035] [] ? __lock_is_held+0x3c/0x57
[11455.551063] []
ieee80211_prepare_and_rx_handle+0xe89/0xf33 [mac80211]
[11455.551071] [] ? debug_smp_processor_id+0x17/0x19
[11455.551098] [] ieee80211_rx_napi+0x4bf/0x8e2 [mac80211]
[11455.551119] [] iwl_mvm_rx_rx_mpdu+0x6af/0x754 [iwlmvm]
[11455.551134] [] iwl_mvm_rx+0x44/0x6d [iwlmvm]
[11455.551147] [] iwl_pcie_rx_handle+0x461/0x5d5 [iwlwifi]
[11455.551160] [] iwl_pcie_irq_handler+0x452/0x635 [iwlwifi]
[11455.551167] [] ? irq_finalize_oneshot+0xc9/0xc9
[11455.551172] [] irq_thread_fn+0x18/0x2f
[11455.551176] [] irq_thread+0x108/0x1b0
[11455.551183] [] ? __schedule+0x48d/0x58f
[11455.551188] [] ? wake_threads_waitq+0x28/0x28
[11455.551193] [] ? irq_thread_dtor+0x93/0x93
[11455.551198] [] kthread+0xf3/0xfb
[11455.551205] [] ? _raw_spin_unlock_irq+0x27/0x45
[11455.551212] [] ret_from_fork+0x1f/0x40
[11455.551217] [] ? kthread_create_on_node+0x1ca/0x1ca
-ss
Re: [PATCH] genirq: export __irq_set_affinity symbol
On Thu, 12 May 2016, Xie XiuQi wrote: > On 2016/5/12 15:43, Thomas Gleixner wrote: > > On Thu, 12 May 2016, Xie XiuQi wrote: > > > >> __irq_set_affinity is declared in include/linux/interrupt.h, but not > >> been exported. > >> > >> We export it now, so we could use __irq_set_affinity, irq_set_affinity > >> and irq_force_affinity in kernel modules. > > > > Please show the code using the exports first. We don't export symbols w/o > > knowing the usecase. > > The default affinity of the interrupts for all devices is always CPU0, > this may cause the latency on CPU0 is very high when some interrupt > occurs very frequently. > > I want to migrate an interrupt to another cpu when the driver loading. What's wrong with setting the affinity from user space? > My code like this: > > /* I want to bind irq_vector to cpu 3 */ And that CPU 3 is hard coded into the driver? That's just wrong. Thanks, tglx
Re: UBSAN: Undefined behaviour in kernel/signal.c:911:6
On 05/12, Meelis Roos wrote: > > This is from a 32-bit x86 computer with 4.6-rc* and UBSAN enabled. I am > also seeing it on some other 32-bit x86 machines. This one is SMP > AthlonMP. > > [ 211.406263] > > [ 211.406327] UBSAN: Undefined behaviour in kernel/signal.c:911:6 > [ 211.406365] shift exponent 32 is too large for 32-bit type 'long unsigned > int' Hmm, indeed... Oh, and this needs other cleanups. Thanks! I'll send the fix. > [ 211.406407] CPU: 1 PID: 1769 Comm: aptitude Not tainted > 4.6.0-rc6-00072-g33656a1 #22 > [ 211.406445] Hardware name: Unknown Unknown/S2462 THUNDER K7, BIOS > Guinness-804/07/2003 > [ 211.406486] c134beac 0007 f441be04 0001 c1381f8b > f441bdf8 0020 > [ 211.406724] c1382516 c1700128 f441be08 0020 c17b5288 0002 > 3233 c1a3d9c0 > [ 211.406959] 0001 024280ca 00363335 0100 f441bea8 c11bf41b > > [ 211.407194] Call Trace: > [ 211.407240] [] ? dump_stack+0x45/0x69 > [ 211.407278] [] ? ubsan_epilogue+0xb/0x40 > [ 211.407313] [] ? __ubsan_handle_shift_out_of_bounds+0xd6/0x120 > [ 211.407355] [] ? path_openat+0x1db/0x1930 > [ 211.407396] [] ? __sigqueue_alloc+0x75/0x190 > [ 211.407495] [] ? complete_signal+0x29c/0x3a0 > [ 211.407593] [] ? __send_signal.constprop.27+0x167/0x3b0 > [ 211.407690] [] ? do_send_sig_info+0x33/0x80 > [ 211.407786] [] ? do_send_specific+0x5e/0x90 > [ 211.407881] [] ? do_tkill+0x83/0xc0 > [ 211.407978] [] ? SyS_tgkill+0x19/0x30 > [ 211.408073] [] ? do_fast_syscall_32+0xb6/0x1d0 > [ 211.408172] [] ? sysenter_past_esp+0x40/0x6a > [ 211.408266] > > > > -- > Meelis Roos (mr...@linux.ee)
next: Build errors due to 'MIPS: Add probing & defs for VZ & guest features'
James,
your patch 'MIPS: Add probing & defs for VZ & guest features' causes build
errors
in -next when using gcc 4.7.4 / binutils 2.24. This affects almost all mips
builds.
{standard input}: Assembler messages:
{standard input}:3306: Warning: Tried to set unrecognized symbol: virt
{standard input}:3307: Error: Unrecognized opcode `mfgc0 $3,$16,0'
and lots of similar messages when building arch/mips/kernel/cpu-probe.o.
Build is fine with gcc 5.2.0 and binutils 2.5.
Bisect log is attached.
Guenter
---
Bisect log:
# bad: [7fd1a8676b7f573be6aa8072e8fa1d4f1bbf8ea7] Add linux-next specific files
for 20160513
# good: [44549e8f5eea4e0a41b487b63e616cb089922b99] Linux 4.6-rc7
git bisect start 'HEAD' 'v4.6-rc7'
# bad: [d573c57f72f32687ed2d11ba60ee5e6f5746ccde] Merge remote-tracking branch
'crypto/master'
git bisect bad d573c57f72f32687ed2d11ba60ee5e6f5746ccde
# bad: [cea0bc891cbcb9cd57a95c0fe03cb16ce3716125] Merge branch
'jdelvare-hwmon/master'
git bisect bad cea0bc891cbcb9cd57a95c0fe03cb16ce3716125
# good: [ffa24f116d6f3925e0eebcd4d4ae30d9ac237459] Merge remote-tracking branch
'tegra/for-next'
git bisect good ffa24f116d6f3925e0eebcd4d4ae30d9ac237459
# bad: [cb4699056080a4a094be6080e10c692af0794d93] Merge remote-tracking branch
'btrfs-kdave/for-next'
git bisect bad cb4699056080a4a094be6080e10c692af0794d93
# bad: [9f2e34d4ff5756624948fe7976866749664793c7] Merge remote-tracking branch
'mips/mips-for-linux-next'
git bisect bad 9f2e34d4ff5756624948fe7976866749664793c7
# good: [fe33223366b2c02394274395f4ac43e48c453654] MIPS: Separate XPA CPU
feature into LPA and MVH
git bisect good fe33223366b2c02394274395f4ac43e48c453654
# good: [5eae0ba2589f767b5c9c14e662f972084b4a46d7] Merge remote-tracking branch
'arm64/for-next/core'
git bisect good 5eae0ba2589f767b5c9c14e662f972084b4a46d7
# bad: [9ca0b767b011347402eb083f887629b27c8eda54] Merge branch '4.6-fixes' into
mips-for-linux-next
git bisect bad 9ca0b767b011347402eb083f887629b27c8eda54
# good: [128639395b2ceacc6a56a0141d0261012bfe04d3] MIPS: Adjust set_pte() SMP
fix to handle R1_LLSC_WAR
git bisect good 128639395b2ceacc6a56a0141d0261012bfe04d3
# good: [6768a2c2e1310acb3e8e8e63a6e2caa146d19d0e] MIPS: BMIPS: BMIPS4380 and
BMIPS5000 support RIXI
git bisect good 6768a2c2e1310acb3e8e8e63a6e2caa146d19d0e
# good: [c1b01a9f21daaf269d77683a4f91f423254f0c3e] MIPS: Add perf counter
feature
git bisect good c1b01a9f21daaf269d77683a4f91f423254f0c3e
# bad: [354d36f4304a14aced7e4ffb0d27038cd19b532f] MIPS: Add probing & defs for VZ
& guest features
git bisect bad 354d36f4304a14aced7e4ffb0d27038cd19b532f
# good: [b7c0199bf7404e87839ad633e699370ed397d548] MIPS: Add register
definitions for VZ ASE registers
git bisect good b7c0199bf7404e87839ad633e699370ed397d548
# good: [cf5c5ac39a33127caa3e4e97f52754a6feede8fd] MIPS: Add guest CP0 accessors
git bisect good cf5c5ac39a33127caa3e4e97f52754a6feede8fd
# first bad commit: [354d36f4304a14aced7e4ffb0d27038cd19b532f] MIPS: Add probing &
defs for VZ & guest features
Re: [RFC PATCH 2/7] ALSA: ac97: add an ac97 bus
On Sat, 14 May 2016 11:50:50 +0200,
Robert Jarzmik wrote:
> >> +unsigned int ac97_bus_scan_one(struct ac97_controller *ac97,
> >> +int codec_num)
> >> +{
> >> + struct ac97_codec_device codec;
> >> + unsigned short vid1, vid2;
> >> + int ret;
> >> +
> >> + codec.dev = *ac97->dev;
> >> + codec.num = codec_num;
> >> + ret = ac97->ops->read(&codec, AC97_VENDOR_ID1);
> >> + vid1 = (ret & 0x);
> >> + if (ret < 0)
> >> + return 0;
> >
> > Hmm. This looks pretty hackish and dangerous.
> You mean returning 0 even if the read failed, right ?
No, my concern is that it's creating a dummy codec object temporarily
on the stack just by copying some fields and calling the ops with it.
(And actually the current code may work wrongly because lack of
zero-clear of the object.)
IMO, a cleaner way would be to define the ops passed with both
controller and codec objects as arguments, and pass NULL codec here.
Takashi
Re: [RFC PATCH 0/3] Amlogic: GXBB: Add reset controller
Hi Neil, Neil Armstrong writes: > Patchset to add and enable the reset controller driver on GXBB platforms. Looking closer at the vendor BSP reset driver, I realized that that kernel doesn't seem to be using this reset IP at all. Their reset driver is actually just using clock gating in the HHI_GCLK_MPEGx registers. I'm not sure I understand why they made that choice (I've asked off-list), but we'll need to keep in mind that any usage of the reset driver in the vendor DTs corresponds do clock gating, and not this reset IP. In any case, other than the minor comments, this looks like a good driver for the reset IP in the S905/GXBB. Also, I gave this driver a quick test with the network driver support I recently posted. When the network driver is loaded, it deasserts the reset and when unloaded, it asserts the reset. Interestingly, the assert cases a full system lockup. :( I've asked some Amlogic folks off-list about this issue too, and hope to get some more clarifcation (and ideally docs) about this reset IP soon. Kevin
