Re: [PATCH 7/7] Documentation: devicetree: Add Xilinx R5 rproc binding
On Fri, Aug 17, 2018 at 9:31 AM, Moritz Fischer
wrote:
> Hi Wendy,
>
> couple of minor stuff inline.
>
> On Thu, Aug 16, 2018 at 12:06 AM, Wendy Liang wrote:
>> Add device tree binding for Xilinx Cortex-r5 remoteproc.
>>
>> Signed-off-by: Wendy Liang
>> ---
>> .../remoteproc/xlnx,zynqmp-r5-remoteproc.txt | 81
>> ++
>> 1 file changed, 81 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
>> new file mode 100644
>> index 000..3940019
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
>> @@ -0,0 +1,81 @@
>> +Xilinx ARM Cortex A53-R5 remoteproc driver
>> +==
>> +
>> +ZynqMP family of devices use two Cortex R5 processors to help with various
>> +low power / real time tasks.
>
> The ZynqMP family [..] uses [..]
Will update in next version
>> +
>> +This driver requires specific ZynqMP hardware design.
>
> *a* specific ZynqMP hardware design. What does that mean?
>> +
>> +ZynqMP R5 RemoteProc Device Node:
>> +=
>> +A zynqmp_r5_remoteproc device node is used to represent a R5 IP instance
>> +within ZynqMP SoC.
>> +
>> +Required properties:
>> +
>> + - compatible : Should be "xlnx,zynqmp-r5-remoteproc-1.0"
>> + - reg : Address and length of the register set for the device. It
>> +contains in the same order as described reg-names
>
> ?
>> + - reg-names: Contain the register set names.
>
> Contains
Will update in next version
>
>> + "tcm_a" and "tcm_b" for TCM memories.
>> + If the user uses the remoteproc driver with the RPMsg kernel
>> + driver,"ipi" for the IPI register used to communicate with RPU
>> + is also required.
>> + Otherwise, if user only uses the remoteproc driver to boot RPU
>> + firmware, "ipi" is not required.
>> + - tcm-pnode-id: TCM resources power nodes IDs which are used to request TCM
>> + resources for the remoteproc driver to access.
>> + - rpu-pnode-id : RPU power node id which is used by the remoteproc driver
>> + to start RPU or shut it down.
>> +
>> +Optional properties:
>> +
>> + - core_conf : R5 core configuration (valid string - split0 or split1 or
>> + lock-step), default is lock-step.
>> + - memory-region: memories regions for RPU executable and DMA memory.
>> + - interrupts : Interrupt mapping for remoteproc IPI. It is required if the
>> +user uses the remoteproc driver with the RPMsg kernel
>> driver.
>> + - interrupt-parent : Phandle for the interrupt controller. It is required
>> if
>> + the user uses the remoteproc driver with the RPMsg
>> kernel
>> + kernel driver.
>> +
>> +Example:
>> +
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> + rproc_0_fw_reserved: rproc@3ed00 {
>> + compatible = "rproc-prog-memory";
>> + no-map;
>> + reg = <0x0 0x3ed0 0x0 0x4>;
>> + };
>> + rproc_0_dma_reserved: rproc@3ed40 {
>> + compatible = "shared-dma-pool";
>> + no-map;
>> + reg = <0x0 0x3ed4 0x0 0x8>;
>> + };
>> + };
>> +
>> + firmware {
>> + zynqmp_firmware: zynqmp-firmware {
>> + compatible = "xlnx,zynqmp-firmware";
>> + method = "smc";
>> + };
>> + };
>> +
>> + zynqmp-r5-remoteproc@0 {
>> + compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
>> + reg = <0x0 0xFFE0 0x0 0x1>,
>> + <0x0 0xFFE2 0x0 0x1>,
>> + <0x0 0xff34 0x0 0x100>;
>> + reg-names = "tcm_a", "tcm_b", "ipi";
>> + dma-ranges;
>> + core_conf = "split0";
>> + memory-region = <_0_fw_reserved>,
>> + <_0_dma_reserved>;
>> + tcm-pnode-id = <0xf>, <0x10>;
>> + rpu-pnode-id = <0x7>;
>> + interrupt-parent = <>;
>> + interrupts = <0 29 4>;
>> + } ;
>> --
>> 2.7.4
>>
>
> Cheers,
> Moritz
Re: [PATCH 7/7] Documentation: devicetree: Add Xilinx R5 rproc binding
On Fri, Aug 17, 2018 at 9:31 AM, Moritz Fischer
wrote:
> Hi Wendy,
>
> couple of minor stuff inline.
>
> On Thu, Aug 16, 2018 at 12:06 AM, Wendy Liang wrote:
>> Add device tree binding for Xilinx Cortex-r5 remoteproc.
>>
>> Signed-off-by: Wendy Liang
>> ---
>> .../remoteproc/xlnx,zynqmp-r5-remoteproc.txt | 81
>> ++
>> 1 file changed, 81 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
>> new file mode 100644
>> index 000..3940019
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
>> @@ -0,0 +1,81 @@
>> +Xilinx ARM Cortex A53-R5 remoteproc driver
>> +==
>> +
>> +ZynqMP family of devices use two Cortex R5 processors to help with various
>> +low power / real time tasks.
>
> The ZynqMP family [..] uses [..]
Will update in next version
>> +
>> +This driver requires specific ZynqMP hardware design.
>
> *a* specific ZynqMP hardware design. What does that mean?
>> +
>> +ZynqMP R5 RemoteProc Device Node:
>> +=
>> +A zynqmp_r5_remoteproc device node is used to represent a R5 IP instance
>> +within ZynqMP SoC.
>> +
>> +Required properties:
>> +
>> + - compatible : Should be "xlnx,zynqmp-r5-remoteproc-1.0"
>> + - reg : Address and length of the register set for the device. It
>> +contains in the same order as described reg-names
>
> ?
>> + - reg-names: Contain the register set names.
>
> Contains
Will update in next version
>
>> + "tcm_a" and "tcm_b" for TCM memories.
>> + If the user uses the remoteproc driver with the RPMsg kernel
>> + driver,"ipi" for the IPI register used to communicate with RPU
>> + is also required.
>> + Otherwise, if user only uses the remoteproc driver to boot RPU
>> + firmware, "ipi" is not required.
>> + - tcm-pnode-id: TCM resources power nodes IDs which are used to request TCM
>> + resources for the remoteproc driver to access.
>> + - rpu-pnode-id : RPU power node id which is used by the remoteproc driver
>> + to start RPU or shut it down.
>> +
>> +Optional properties:
>> +
>> + - core_conf : R5 core configuration (valid string - split0 or split1 or
>> + lock-step), default is lock-step.
>> + - memory-region: memories regions for RPU executable and DMA memory.
>> + - interrupts : Interrupt mapping for remoteproc IPI. It is required if the
>> +user uses the remoteproc driver with the RPMsg kernel
>> driver.
>> + - interrupt-parent : Phandle for the interrupt controller. It is required
>> if
>> + the user uses the remoteproc driver with the RPMsg
>> kernel
>> + kernel driver.
>> +
>> +Example:
>> +
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> + rproc_0_fw_reserved: rproc@3ed00 {
>> + compatible = "rproc-prog-memory";
>> + no-map;
>> + reg = <0x0 0x3ed0 0x0 0x4>;
>> + };
>> + rproc_0_dma_reserved: rproc@3ed40 {
>> + compatible = "shared-dma-pool";
>> + no-map;
>> + reg = <0x0 0x3ed4 0x0 0x8>;
>> + };
>> + };
>> +
>> + firmware {
>> + zynqmp_firmware: zynqmp-firmware {
>> + compatible = "xlnx,zynqmp-firmware";
>> + method = "smc";
>> + };
>> + };
>> +
>> + zynqmp-r5-remoteproc@0 {
>> + compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
>> + reg = <0x0 0xFFE0 0x0 0x1>,
>> + <0x0 0xFFE2 0x0 0x1>,
>> + <0x0 0xff34 0x0 0x100>;
>> + reg-names = "tcm_a", "tcm_b", "ipi";
>> + dma-ranges;
>> + core_conf = "split0";
>> + memory-region = <_0_fw_reserved>,
>> + <_0_dma_reserved>;
>> + tcm-pnode-id = <0xf>, <0x10>;
>> + rpu-pnode-id = <0x7>;
>> + interrupt-parent = <>;
>> + interrupts = <0 29 4>;
>> + } ;
>> --
>> 2.7.4
>>
>
> Cheers,
> Moritz
Re: [PATCH 7/7] Documentation: devicetree: Add Xilinx R5 rproc binding
On Fri, Aug 17, 2018 at 8:09 AM, Rob Herring wrote: > Hi, this email is from Rob's (experimental) review bot. I found a couple > of common problems with your patch. Please see below. > > On Thu, 16 Aug 2018 00:06:30 -0700, Wendy Liang wrote: >> Add device tree binding for Xilinx Cortex-r5 remoteproc. >> >> Signed-off-by: Wendy Liang > > The preferred subject prefix is "dt-bindings: : ...". Will updated in the next release > >> --- >> .../remoteproc/xlnx,zynqmp-r5-remoteproc.txt | 81 >> ++ >> 1 file changed, 81 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt >>
Re: [PATCH 7/7] Documentation: devicetree: Add Xilinx R5 rproc binding
On Fri, Aug 17, 2018 at 8:09 AM, Rob Herring wrote: > Hi, this email is from Rob's (experimental) review bot. I found a couple > of common problems with your patch. Please see below. > > On Thu, 16 Aug 2018 00:06:30 -0700, Wendy Liang wrote: >> Add device tree binding for Xilinx Cortex-r5 remoteproc. >> >> Signed-off-by: Wendy Liang > > The preferred subject prefix is "dt-bindings: : ...". Will updated in the next release > >> --- >> .../remoteproc/xlnx,zynqmp-r5-remoteproc.txt | 81 >> ++ >> 1 file changed, 81 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt >>
Re: [PATCH v9 2/4] Uprobes/sdt: Prevent multiple reference counter for same uprobe
On Sun, Aug 19, 2018 at 9:42 PM, Ravi Bangoria
wrote:
> We assume to have only one reference counter for one uprobe.
> Don't allow user to register multiple uprobes having same
> inode+offset but different reference counter.
>
> Signed-off-by: Ravi Bangoria
> Acked-by: Srikar Dronamraju
> Reviewed-by: Oleg Nesterov
Reviewed-by: Song Liu
> ---
> kernel/events/uprobes.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 35065febcb6c..ecee371a59c7 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -679,6 +679,16 @@ static struct uprobe *insert_uprobe(struct uprobe
> *uprobe)
> return u;
> }
>
> +static void
> +ref_ctr_mismatch_warn(struct uprobe *cur_uprobe, struct uprobe *uprobe)
> +{
> + pr_warn("ref_ctr_offset mismatch. inode: 0x%lx offset: 0x%llx "
> + "ref_ctr_offset(old): 0x%llx ref_ctr_offset(new): 0x%llx\n",
> + uprobe->inode->i_ino, (unsigned long long) uprobe->offset,
> + (unsigned long long) cur_uprobe->ref_ctr_offset,
> + (unsigned long long) uprobe->ref_ctr_offset);
> +}
> +
> static struct uprobe *alloc_uprobe(struct inode *inode, loff_t offset,
>loff_t ref_ctr_offset)
> {
> @@ -698,6 +708,12 @@ static struct uprobe *alloc_uprobe(struct inode *inode,
> loff_t offset,
> cur_uprobe = insert_uprobe(uprobe);
> /* a uprobe exists for this inode:offset combination */
> if (cur_uprobe) {
> + if (cur_uprobe->ref_ctr_offset != uprobe->ref_ctr_offset) {
> + ref_ctr_mismatch_warn(cur_uprobe, uprobe);
> + put_uprobe(cur_uprobe);
> + kfree(uprobe);
> + return ERR_PTR(-EINVAL);
> + }
> kfree(uprobe);
> uprobe = cur_uprobe;
> }
> @@ -1112,6 +1128,9 @@ static int __uprobe_register(struct inode *inode,
> loff_t offset,
> uprobe = alloc_uprobe(inode, offset, ref_ctr_offset);
> if (!uprobe)
> return -ENOMEM;
> + if (IS_ERR(uprobe))
> + return PTR_ERR(uprobe);
> +
> /*
> * We can race with uprobe_unregister()->delete_uprobe().
> * Check uprobe_is_active() and retry if it is false.
> --
> 2.14.4
>
Re: [PATCH v9 2/4] Uprobes/sdt: Prevent multiple reference counter for same uprobe
On Sun, Aug 19, 2018 at 9:42 PM, Ravi Bangoria
wrote:
> We assume to have only one reference counter for one uprobe.
> Don't allow user to register multiple uprobes having same
> inode+offset but different reference counter.
>
> Signed-off-by: Ravi Bangoria
> Acked-by: Srikar Dronamraju
> Reviewed-by: Oleg Nesterov
Reviewed-by: Song Liu
> ---
> kernel/events/uprobes.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 35065febcb6c..ecee371a59c7 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -679,6 +679,16 @@ static struct uprobe *insert_uprobe(struct uprobe
> *uprobe)
> return u;
> }
>
> +static void
> +ref_ctr_mismatch_warn(struct uprobe *cur_uprobe, struct uprobe *uprobe)
> +{
> + pr_warn("ref_ctr_offset mismatch. inode: 0x%lx offset: 0x%llx "
> + "ref_ctr_offset(old): 0x%llx ref_ctr_offset(new): 0x%llx\n",
> + uprobe->inode->i_ino, (unsigned long long) uprobe->offset,
> + (unsigned long long) cur_uprobe->ref_ctr_offset,
> + (unsigned long long) uprobe->ref_ctr_offset);
> +}
> +
> static struct uprobe *alloc_uprobe(struct inode *inode, loff_t offset,
>loff_t ref_ctr_offset)
> {
> @@ -698,6 +708,12 @@ static struct uprobe *alloc_uprobe(struct inode *inode,
> loff_t offset,
> cur_uprobe = insert_uprobe(uprobe);
> /* a uprobe exists for this inode:offset combination */
> if (cur_uprobe) {
> + if (cur_uprobe->ref_ctr_offset != uprobe->ref_ctr_offset) {
> + ref_ctr_mismatch_warn(cur_uprobe, uprobe);
> + put_uprobe(cur_uprobe);
> + kfree(uprobe);
> + return ERR_PTR(-EINVAL);
> + }
> kfree(uprobe);
> uprobe = cur_uprobe;
> }
> @@ -1112,6 +1128,9 @@ static int __uprobe_register(struct inode *inode,
> loff_t offset,
> uprobe = alloc_uprobe(inode, offset, ref_ctr_offset);
> if (!uprobe)
> return -ENOMEM;
> + if (IS_ERR(uprobe))
> + return PTR_ERR(uprobe);
> +
> /*
> * We can race with uprobe_unregister()->delete_uprobe().
> * Check uprobe_is_active() and retry if it is false.
> --
> 2.14.4
>
Re: [PATCH v9 1/4] Uprobes: Support SDT markers having reference count (semaphore)
On Sun, Aug 19, 2018 at 9:42 PM, Ravi Bangoria
wrote:
> Userspace Statically Defined Tracepoints[1] are dtrace style markers
> inside userspace applications. Applications like PostgreSQL, MySQL,
> Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
> have these markers embedded in them. These markers are added by developer
> at important places in the code. Each marker source expands to a single
> nop instruction in the compiled code but there may be additional
> overhead for computing the marker arguments which expands to couple of
> instructions. In case the overhead is more, execution of it can be
> omitted by runtime if() condition when no one is tracing on the marker:
>
> if (reference_counter > 0) {
> Execute marker instructions;
> }
>
> Default value of reference counter is 0. Tracer has to increment the
> reference counter before tracing on a marker and decrement it when
> done with the tracing.
>
> Implement the reference counter logic in core uprobe. User will be
> able to use it from trace_uprobe as well as from kernel module. New
> trace_uprobe definition with reference counter will now be:
>
> :[(ref_ctr_offset)]
>
> where ref_ctr_offset is an optional field. For kernel module, new
> variant of uprobe_register() has been introduced:
>
> uprobe_register_refctr(inode, offset, ref_ctr_offset, consumer)
>
> No new variant for uprobe_unregister() because it's assumed to have
> only one reference counter for one uprobe.
>
> [1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
>
> Note: 'reference counter' is called as 'semaphore' in original Dtrace
> (or Systemtap, bcc and even in ELF) documentation and code. But the
> term 'semaphore' is misleading in this context. This is just a counter
> used to hold number of tracers tracing on a marker. This is not really
> used for any synchronization. So we are calling it a 'reference counter'
> in kernel / perf code.
>
> Signed-off-by: Ravi Bangoria
> Reviewed-by: Masami Hiramatsu
> [Only trace_uprobe.c]
> Reviewed-by: Oleg Nesterov
Reviewed-by: Song Liu
> ---
> include/linux/uprobes.h | 5 +
> kernel/events/uprobes.c | 259
> ++--
> kernel/trace/trace.c| 2 +-
> kernel/trace/trace_uprobe.c | 38 ++-
> 4 files changed, 293 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
> index bb9d2084af03..103a48a48872 100644
> --- a/include/linux/uprobes.h
> +++ b/include/linux/uprobes.h
> @@ -123,6 +123,7 @@ extern unsigned long uprobe_get_swbp_addr(struct pt_regs
> *regs);
> extern unsigned long uprobe_get_trap_addr(struct pt_regs *regs);
> extern int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct
> *mm, unsigned long vaddr, uprobe_opcode_t);
> extern int uprobe_register(struct inode *inode, loff_t offset, struct
> uprobe_consumer *uc);
> +extern int uprobe_register_refctr(struct inode *inode, loff_t offset, loff_t
> ref_ctr_offset, struct uprobe_consumer *uc);
> extern int uprobe_apply(struct inode *inode, loff_t offset, struct
> uprobe_consumer *uc, bool);
> extern void uprobe_unregister(struct inode *inode, loff_t offset, struct
> uprobe_consumer *uc);
> extern int uprobe_mmap(struct vm_area_struct *vma);
> @@ -160,6 +161,10 @@ uprobe_register(struct inode *inode, loff_t offset,
> struct uprobe_consumer *uc)
> {
> return -ENOSYS;
> }
> +static inline int uprobe_register_refctr(struct inode *inode, loff_t offset,
> loff_t ref_ctr_offset, struct uprobe_consumer *uc)
> +{
> + return -ENOSYS;
> +}
> static inline int
> uprobe_apply(struct inode *inode, loff_t offset, struct uprobe_consumer *uc,
> bool add)
> {
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 919c1ce32beb..35065febcb6c 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -73,6 +73,7 @@ struct uprobe {
> struct uprobe_consumer *consumers;
> struct inode*inode; /* Also hold a ref to inode */
> loff_t offset;
> + loff_t ref_ctr_offset;
> unsigned long flags;
>
> /*
> @@ -88,6 +89,15 @@ struct uprobe {
> struct arch_uprobe arch;
> };
>
> +struct delayed_uprobe {
> + struct list_head list;
> + struct uprobe *uprobe;
> + struct mm_struct *mm;
> +};
> +
> +static DEFINE_MUTEX(delayed_uprobe_lock);
> +static LIST_HEAD(delayed_uprobe_list);
> +
> /*
> * Execute out of line area: anonymous executable mapping installed
> * by the probed task to execute the copy of the original instruction
> @@ -282,6 +292,166 @@ static int verify_opcode(struct page *page, unsigned
> long vaddr, uprobe_opcode_t
> return 1;
> }
>
> +static struct delayed_uprobe *
> +delayed_uprobe_check(struct uprobe *uprobe, struct mm_struct *mm)
> +{
> + struct delayed_uprobe *du;
> +
> +
Re: [PATCH v9 1/4] Uprobes: Support SDT markers having reference count (semaphore)
On Sun, Aug 19, 2018 at 9:42 PM, Ravi Bangoria
wrote:
> Userspace Statically Defined Tracepoints[1] are dtrace style markers
> inside userspace applications. Applications like PostgreSQL, MySQL,
> Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
> have these markers embedded in them. These markers are added by developer
> at important places in the code. Each marker source expands to a single
> nop instruction in the compiled code but there may be additional
> overhead for computing the marker arguments which expands to couple of
> instructions. In case the overhead is more, execution of it can be
> omitted by runtime if() condition when no one is tracing on the marker:
>
> if (reference_counter > 0) {
> Execute marker instructions;
> }
>
> Default value of reference counter is 0. Tracer has to increment the
> reference counter before tracing on a marker and decrement it when
> done with the tracing.
>
> Implement the reference counter logic in core uprobe. User will be
> able to use it from trace_uprobe as well as from kernel module. New
> trace_uprobe definition with reference counter will now be:
>
> :[(ref_ctr_offset)]
>
> where ref_ctr_offset is an optional field. For kernel module, new
> variant of uprobe_register() has been introduced:
>
> uprobe_register_refctr(inode, offset, ref_ctr_offset, consumer)
>
> No new variant for uprobe_unregister() because it's assumed to have
> only one reference counter for one uprobe.
>
> [1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
>
> Note: 'reference counter' is called as 'semaphore' in original Dtrace
> (or Systemtap, bcc and even in ELF) documentation and code. But the
> term 'semaphore' is misleading in this context. This is just a counter
> used to hold number of tracers tracing on a marker. This is not really
> used for any synchronization. So we are calling it a 'reference counter'
> in kernel / perf code.
>
> Signed-off-by: Ravi Bangoria
> Reviewed-by: Masami Hiramatsu
> [Only trace_uprobe.c]
> Reviewed-by: Oleg Nesterov
Reviewed-by: Song Liu
> ---
> include/linux/uprobes.h | 5 +
> kernel/events/uprobes.c | 259
> ++--
> kernel/trace/trace.c| 2 +-
> kernel/trace/trace_uprobe.c | 38 ++-
> 4 files changed, 293 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
> index bb9d2084af03..103a48a48872 100644
> --- a/include/linux/uprobes.h
> +++ b/include/linux/uprobes.h
> @@ -123,6 +123,7 @@ extern unsigned long uprobe_get_swbp_addr(struct pt_regs
> *regs);
> extern unsigned long uprobe_get_trap_addr(struct pt_regs *regs);
> extern int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct
> *mm, unsigned long vaddr, uprobe_opcode_t);
> extern int uprobe_register(struct inode *inode, loff_t offset, struct
> uprobe_consumer *uc);
> +extern int uprobe_register_refctr(struct inode *inode, loff_t offset, loff_t
> ref_ctr_offset, struct uprobe_consumer *uc);
> extern int uprobe_apply(struct inode *inode, loff_t offset, struct
> uprobe_consumer *uc, bool);
> extern void uprobe_unregister(struct inode *inode, loff_t offset, struct
> uprobe_consumer *uc);
> extern int uprobe_mmap(struct vm_area_struct *vma);
> @@ -160,6 +161,10 @@ uprobe_register(struct inode *inode, loff_t offset,
> struct uprobe_consumer *uc)
> {
> return -ENOSYS;
> }
> +static inline int uprobe_register_refctr(struct inode *inode, loff_t offset,
> loff_t ref_ctr_offset, struct uprobe_consumer *uc)
> +{
> + return -ENOSYS;
> +}
> static inline int
> uprobe_apply(struct inode *inode, loff_t offset, struct uprobe_consumer *uc,
> bool add)
> {
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 919c1ce32beb..35065febcb6c 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -73,6 +73,7 @@ struct uprobe {
> struct uprobe_consumer *consumers;
> struct inode*inode; /* Also hold a ref to inode */
> loff_t offset;
> + loff_t ref_ctr_offset;
> unsigned long flags;
>
> /*
> @@ -88,6 +89,15 @@ struct uprobe {
> struct arch_uprobe arch;
> };
>
> +struct delayed_uprobe {
> + struct list_head list;
> + struct uprobe *uprobe;
> + struct mm_struct *mm;
> +};
> +
> +static DEFINE_MUTEX(delayed_uprobe_lock);
> +static LIST_HEAD(delayed_uprobe_list);
> +
> /*
> * Execute out of line area: anonymous executable mapping installed
> * by the probed task to execute the copy of the original instruction
> @@ -282,6 +292,166 @@ static int verify_opcode(struct page *page, unsigned
> long vaddr, uprobe_opcode_t
> return 1;
> }
>
> +static struct delayed_uprobe *
> +delayed_uprobe_check(struct uprobe *uprobe, struct mm_struct *mm)
> +{
> + struct delayed_uprobe *du;
> +
> +
linux-next: Tree for Aug 20
Hi all, Please do not add any v4.20 material to your linux-next included branches until after v4.19-rc1 has been released. Changes since 20180817: The akpm-current tree gained conflicts against the tip tree. Non-merge commits (relative to Linus' tree): 2346 2426 files changed, 93635 insertions(+), 35418 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 286 trees (counting Linus' and 65 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (2ad0d5269970 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (08b5fa819970 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging arc-current/for-curr (fce0d0affdc5 ARC: cleanup show_faulting_vma()) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (5ad356eabc47 arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()) Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs for v4.18-rc6) Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global invalidations when removing copro) Merging sparc/master (c1d61e7fe376 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (e2948e5af8ee ip6_vti: fix creating fallback tunnel device for vti6) Merging bpf/master (f6069b9aa993 bpf: fix redirect to map under tail calls) Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for new entries) Merging netfilter/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (299b6365a3b7 brcmfmac: fix regression in parsing NVRAM for multiple devices) Merging mac80211/master (484004339d45 mac80211_hwsim: require at least one channel) Merging rdma-fixes/for-rc (addb8a6559f0 RDMA/uverbs: Expand primary and alt AV port checks) Merging sound-current/for-linus (250ea7c5f56e ALSA: ac97: fix unbalanced pm_runtime_enable) Merging sound-asoc-fixes/for-linus (ba095ffc9324 Merge branch 'asoc-4.18' into asoc-linus) Merging regmap-fixes/for-linus (94710cac0ef4 Linux 4.18) Merging regulator-fixes/for-linus (84d77c5ab32d Merge branch 'regulator-4.18' into regulator-linus) Merging spi-fixes/for-linus (8a7c14551b9b Merge branch 'spi-4.18' into spi-linus) Merging pci-current/for-linus (44bda4b7d26e PCI: Fix is_added/is_busmaster race condition) Merging driver-core.current/driver-core-linus (08b5fa819970 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging tty.current/tty-linus (08b5fa819970 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging usb.current/usb-linus (08b5fa819970 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging usb-gadget-fixes/fixes (acb1872577b3 Linux 4.18-rc7) Merging usb-serial-fixes/usb-linus (9d3cce1e8b85 Linux
linux-next: Tree for Aug 20
Hi all, Please do not add any v4.20 material to your linux-next included branches until after v4.19-rc1 has been released. Changes since 20180817: The akpm-current tree gained conflicts against the tip tree. Non-merge commits (relative to Linus' tree): 2346 2426 files changed, 93635 insertions(+), 35418 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 286 trees (counting Linus' and 65 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (2ad0d5269970 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (08b5fa819970 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging arc-current/for-curr (fce0d0affdc5 ARC: cleanup show_faulting_vma()) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (5ad356eabc47 arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()) Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs for v4.18-rc6) Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global invalidations when removing copro) Merging sparc/master (c1d61e7fe376 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (e2948e5af8ee ip6_vti: fix creating fallback tunnel device for vti6) Merging bpf/master (f6069b9aa993 bpf: fix redirect to map under tail calls) Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for new entries) Merging netfilter/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (299b6365a3b7 brcmfmac: fix regression in parsing NVRAM for multiple devices) Merging mac80211/master (484004339d45 mac80211_hwsim: require at least one channel) Merging rdma-fixes/for-rc (addb8a6559f0 RDMA/uverbs: Expand primary and alt AV port checks) Merging sound-current/for-linus (250ea7c5f56e ALSA: ac97: fix unbalanced pm_runtime_enable) Merging sound-asoc-fixes/for-linus (ba095ffc9324 Merge branch 'asoc-4.18' into asoc-linus) Merging regmap-fixes/for-linus (94710cac0ef4 Linux 4.18) Merging regulator-fixes/for-linus (84d77c5ab32d Merge branch 'regulator-4.18' into regulator-linus) Merging spi-fixes/for-linus (8a7c14551b9b Merge branch 'spi-4.18' into spi-linus) Merging pci-current/for-linus (44bda4b7d26e PCI: Fix is_added/is_busmaster race condition) Merging driver-core.current/driver-core-linus (08b5fa819970 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging tty.current/tty-linus (08b5fa819970 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging usb.current/usb-linus (08b5fa819970 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging usb-gadget-fixes/fixes (acb1872577b3 Linux 4.18-rc7) Merging usb-serial-fixes/usb-linus (9d3cce1e8b85 Linux
Re: [PATCH v8 1/2] kbuild: Allow asm-specific compiler_types.h
Hi Paul,
2018-08-19 3:10 GMT+09:00 Paul Burton :
> We have a need to override the definition of
> barrier_before_unreachable() for MIPS, which means we either need to add
> architecture-specific code into linux/compiler-gcc.h or we need to allow
> the architecture to provide a header that can define the macro before
> the generic definition. The latter seems like the better approach.
>
> A straightforward approach to the per-arch header is to make use of
> asm-generic to provide a default empty header & adjust architectures
> which don't need anything specific to make use of that by adding the
> header to generic-y. Unfortunately this doesn't work so well due to
> commit a95b37e20db9 ("kbuild: get out of
> ") which moved the inclusion of linux/compiler.h to
> cflags using the -include compiler flag.
>
> Because the -include flag is present for all C files we compile, we need
> the architecture-provided header to be present before any C files are
> compiled. If any C files can be compiled prior to the asm-generic header
> wrappers being generated then we hit a build failure due to missing
> header. Such cases do exist - one pointed out by the kbuild test robot
> is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
> of the archprepare target [1].
>
> This leaves us with a few options:
>
> 1) Use generic-y & fix any build failures we find by enforcing
> ordering such that the asm-generic target occurs before any C
> compilation, such that linux/compiler_types.h can always include
> the generated asm-generic wrapper which in turn includes the empty
> asm-generic header. This would rely on us finding all the
> problematic cases - I don't know for sure that the ia64 issue is
> the only one.
>
> 2) Add an actual empty header to each architecture, so that we don't
> need the generated asm-generic wrapper. This seems messy.
>
> 3) Give up & add #ifdef CONFIG_MIPS or similar to
> linux/compiler_types.h. This seems messy too.
>
> 4) Include the arch header only when it's actually needed, removing
> the need for the asm-generic wrapper for all other architectures.
>
> This patch allows us to use approach 4, by including an
> asm/compiler_types.h header using the -include flag in the same way we
> do for linux/compiler_types.h, but only if the header actually exists.
I agree with the approach 4),
but I am of two minds about how to implement it.
I guess the cost of evaluating 'wildcard' for each C file
is unnoticeable level, but I am slightly in favor of
including from
conditionally.
I am not sure about the CONFIG name, but for example, like this.
#ifdef CONFIG_HAVE_ARCH_COMPILER_TYPES
#include
#endif
What do you think?
> [1] https://lists.01.org/pipermail/kbuild-all/2018-August/051175.html
>
> Signed-off-by: Paul Burton
> Cc: Arnd Bergmann
> Cc: James Hogan
> Cc: Masahiro Yamada
> Cc: Ralf Baechle
> Cc: linux-a...@vger.kernel.org
> Cc: linux-kbu...@vger.kernel.org
> Cc: linux-m...@linux-mips.org
>
> ---
> Any thoughts anyone?
>
> This isn't the prettiest it could possibly be but it's a small change &
> clearly shouldn't break anything, which are good qualities for a patch
> fixing build failures that we'd ideally backport as far as 4.16.
>
> Changes in v8:
> - New patch.
>
> scripts/Makefile.lib | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 1bb594fcfe12..4e7b41ef029b 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -151,8 +151,11 @@ __a_flags = $(call flags,_a_flags)
> __cpp_flags = $(call flags,_cpp_flags)
> endif
>
> +c_includes = $(wildcard
> $(srctree)/arch/$(SRCARCH)/include/asm/compiler_types.h)
> +c_includes += $(srctree)/include/linux/compiler_types.h
> +
> c_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
> --include $(srctree)/include/linux/compiler_types.h \
> +$(addprefix -include ,$(c_includes)) \
> $(__c_flags) $(modkern_cflags) \
> $(basename_flags) $(modname_flags)
>
> --
> 2.18.0
>
--
Best Regards
Masahiro Yamada
Re: [PATCH v8 1/2] kbuild: Allow asm-specific compiler_types.h
Hi Paul,
2018-08-19 3:10 GMT+09:00 Paul Burton :
> We have a need to override the definition of
> barrier_before_unreachable() for MIPS, which means we either need to add
> architecture-specific code into linux/compiler-gcc.h or we need to allow
> the architecture to provide a header that can define the macro before
> the generic definition. The latter seems like the better approach.
>
> A straightforward approach to the per-arch header is to make use of
> asm-generic to provide a default empty header & adjust architectures
> which don't need anything specific to make use of that by adding the
> header to generic-y. Unfortunately this doesn't work so well due to
> commit a95b37e20db9 ("kbuild: get out of
> ") which moved the inclusion of linux/compiler.h to
> cflags using the -include compiler flag.
>
> Because the -include flag is present for all C files we compile, we need
> the architecture-provided header to be present before any C files are
> compiled. If any C files can be compiled prior to the asm-generic header
> wrappers being generated then we hit a build failure due to missing
> header. Such cases do exist - one pointed out by the kbuild test robot
> is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
> of the archprepare target [1].
>
> This leaves us with a few options:
>
> 1) Use generic-y & fix any build failures we find by enforcing
> ordering such that the asm-generic target occurs before any C
> compilation, such that linux/compiler_types.h can always include
> the generated asm-generic wrapper which in turn includes the empty
> asm-generic header. This would rely on us finding all the
> problematic cases - I don't know for sure that the ia64 issue is
> the only one.
>
> 2) Add an actual empty header to each architecture, so that we don't
> need the generated asm-generic wrapper. This seems messy.
>
> 3) Give up & add #ifdef CONFIG_MIPS or similar to
> linux/compiler_types.h. This seems messy too.
>
> 4) Include the arch header only when it's actually needed, removing
> the need for the asm-generic wrapper for all other architectures.
>
> This patch allows us to use approach 4, by including an
> asm/compiler_types.h header using the -include flag in the same way we
> do for linux/compiler_types.h, but only if the header actually exists.
I agree with the approach 4),
but I am of two minds about how to implement it.
I guess the cost of evaluating 'wildcard' for each C file
is unnoticeable level, but I am slightly in favor of
including from
conditionally.
I am not sure about the CONFIG name, but for example, like this.
#ifdef CONFIG_HAVE_ARCH_COMPILER_TYPES
#include
#endif
What do you think?
> [1] https://lists.01.org/pipermail/kbuild-all/2018-August/051175.html
>
> Signed-off-by: Paul Burton
> Cc: Arnd Bergmann
> Cc: James Hogan
> Cc: Masahiro Yamada
> Cc: Ralf Baechle
> Cc: linux-a...@vger.kernel.org
> Cc: linux-kbu...@vger.kernel.org
> Cc: linux-m...@linux-mips.org
>
> ---
> Any thoughts anyone?
>
> This isn't the prettiest it could possibly be but it's a small change &
> clearly shouldn't break anything, which are good qualities for a patch
> fixing build failures that we'd ideally backport as far as 4.16.
>
> Changes in v8:
> - New patch.
>
> scripts/Makefile.lib | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 1bb594fcfe12..4e7b41ef029b 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -151,8 +151,11 @@ __a_flags = $(call flags,_a_flags)
> __cpp_flags = $(call flags,_cpp_flags)
> endif
>
> +c_includes = $(wildcard
> $(srctree)/arch/$(SRCARCH)/include/asm/compiler_types.h)
> +c_includes += $(srctree)/include/linux/compiler_types.h
> +
> c_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
> --include $(srctree)/include/linux/compiler_types.h \
> +$(addprefix -include ,$(c_includes)) \
> $(__c_flags) $(modkern_cflags) \
> $(basename_flags) $(modname_flags)
>
> --
> 2.18.0
>
--
Best Regards
Masahiro Yamada
[PATCH v9 4/4] perf probe: Support SDT markers having reference counter (semaphore)
With this, perf buildid-cache will save SDT markers with reference
counter in probe cache. Perf probe will be able to probe markers
having reference counter. Ex,
# readelf -n /tmp/tick | grep -A1 loop2
Name: loop2
... Semaphore: 0x10020036
# ./perf buildid-cache --add /tmp/tick
# ./perf probe sdt_tick:loop2
# ./perf stat -e sdt_tick:loop2 /tmp/tick
hi: 0
hi: 1
hi: 2
^C
Performance counter stats for '/tmp/tick':
3 sdt_tick:loop2
2.561851452 seconds time elapsed
Signed-off-by: Ravi Bangoria
Acked-by: Masami Hiramatsu
Acked-by: Srikar Dronamraju
---
tools/perf/util/probe-event.c | 39
tools/perf/util/probe-event.h | 1 +
tools/perf/util/probe-file.c | 34 ++--
tools/perf/util/probe-file.h | 1 +
tools/perf/util/symbol-elf.c | 46 ---
tools/perf/util/symbol.h | 7 +++
6 files changed, 106 insertions(+), 22 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index f119eb628dbb..e86f8be89157 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1819,6 +1819,12 @@ int parse_probe_trace_command(const char *cmd, struct
probe_trace_event *tev)
tp->offset = strtoul(fmt2_str, NULL, 10);
}
+ if (tev->uprobes) {
+ fmt2_str = strchr(p, '(');
+ if (fmt2_str)
+ tp->ref_ctr_offset = strtoul(fmt2_str + 1, NULL, 0);
+ }
+
tev->nargs = argc - 2;
tev->args = zalloc(sizeof(struct probe_trace_arg) * tev->nargs);
if (tev->args == NULL) {
@@ -2012,6 +2018,22 @@ static int synthesize_probe_trace_arg(struct
probe_trace_arg *arg,
return err;
}
+static int
+synthesize_uprobe_trace_def(struct probe_trace_event *tev, struct strbuf *buf)
+{
+ struct probe_trace_point *tp = >point;
+ int err;
+
+ err = strbuf_addf(buf, "%s:0x%lx", tp->module, tp->address);
+
+ if (err >= 0 && tp->ref_ctr_offset) {
+ if (!uprobe_ref_ctr_is_supported())
+ return -1;
+ err = strbuf_addf(buf, "(0x%lx)", tp->ref_ctr_offset);
+ }
+ return err >= 0 ? 0 : -1;
+}
+
char *synthesize_probe_trace_command(struct probe_trace_event *tev)
{
struct probe_trace_point *tp = >point;
@@ -2041,15 +2063,17 @@ char *synthesize_probe_trace_command(struct
probe_trace_event *tev)
}
/* Use the tp->address for uprobes */
- if (tev->uprobes)
- err = strbuf_addf(, "%s:0x%lx", tp->module, tp->address);
- else if (!strncmp(tp->symbol, "0x", 2))
+ if (tev->uprobes) {
+ err = synthesize_uprobe_trace_def(tev, );
+ } else if (!strncmp(tp->symbol, "0x", 2)) {
/* Absolute address. See try_to_find_absolute_address() */
err = strbuf_addf(, "%s%s0x%lx", tp->module ?: "",
tp->module ? ":" : "", tp->address);
- else
+ } else {
err = strbuf_addf(, "%s%s%s+%lu", tp->module ?: "",
tp->module ? ":" : "", tp->symbol, tp->offset);
+ }
+
if (err)
goto error;
@@ -2633,6 +2657,13 @@ static void warn_uprobe_event_compat(struct
probe_trace_event *tev)
{
int i;
char *buf = synthesize_probe_trace_command(tev);
+ struct probe_trace_point *tp = >point;
+
+ if (tp->ref_ctr_offset && !uprobe_ref_ctr_is_supported()) {
+ pr_warning("A semaphore is associated with %s:%s and "
+ "seems your kernel doesn't support it.\n",
+ tev->group, tev->event);
+ }
/* Old uprobe event doesn't support memory dereference */
if (!tev->uprobes || tev->nargs == 0 || !buf)
diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
index 45b14f020558..15a98c3a2a2f 100644
--- a/tools/perf/util/probe-event.h
+++ b/tools/perf/util/probe-event.h
@@ -27,6 +27,7 @@ struct probe_trace_point {
char*symbol;/* Base symbol */
char*module;/* Module name */
unsigned long offset; /* Offset from symbol */
+ unsigned long ref_ctr_offset; /* SDT reference counter offset */
unsigned long address;/* Actual address of the trace point */
boolretprobe; /* Return probe flag */
};
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index b76088fadf3d..aac7817d9e14 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -696,8 +696,16 @@ int probe_cache__add_entry(struct probe_cache *pcache,
#ifdef HAVE_GELF_GETNOTE_SUPPORT
static unsigned long long sdt_note__get_addr(struct sdt_note *note)
{
- return note->bit32 ? (unsigned long
[PATCH v9 3/4] trace_uprobe/sdt: Prevent multiple reference counter for same uprobe
We assume to have only one reference counter for one uprobe.
Don't allow user to add multiple trace_uprobe entries having
same inode+offset but different reference counter.
Ex,
# echo "p:sdt_tick/loop2 /home/ravi/tick:0x6e4(0x10036)" > uprobe_events
# echo "p:sdt_tick/loop2_1 /home/ravi/tick:0x6e4(0xf)" >> uprobe_events
bash: echo: write error: Invalid argument
# dmesg
trace_kprobe: Reference counter offset mismatch.
There is one exception though:
When user is trying to replace the old entry with the new
one, we allow this if the new entry does not conflict with
any other existing entries.
Signed-off-by: Ravi Bangoria
Acked-by: Srikar Dronamraju
Reviewed-by: Song Liu
Reviewed-by: Oleg Nesterov
---
kernel/trace/trace_uprobe.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index a7ef6c4ca16e..21d9fffaa096 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -324,6 +324,35 @@ static int unregister_trace_uprobe(struct trace_uprobe *tu)
return 0;
}
+/*
+ * Uprobe with multiple reference counter is not allowed. i.e.
+ * If inode and offset matches, reference counter offset *must*
+ * match as well. Though, there is one exception: If user is
+ * replacing old trace_uprobe with new one(same group/event),
+ * then we allow same uprobe with new reference counter as far
+ * as the new one does not conflict with any other existing
+ * ones.
+ */
+static struct trace_uprobe *find_old_trace_uprobe(struct trace_uprobe *new)
+{
+ struct trace_uprobe *tmp, *old = NULL;
+ struct inode *new_inode = d_real_inode(new->path.dentry);
+
+ old = find_probe_event(trace_event_name(>tp.call),
+ new->tp.call.class->system);
+
+ list_for_each_entry(tmp, _list, list) {
+ if ((old ? old != tmp : true) &&
+ new_inode == d_real_inode(tmp->path.dentry) &&
+ new->offset == tmp->offset &&
+ new->ref_ctr_offset != tmp->ref_ctr_offset) {
+ pr_warn("Reference counter offset mismatch.");
+ return ERR_PTR(-EINVAL);
+ }
+ }
+ return old;
+}
+
/* Register a trace_uprobe and probe_event */
static int register_trace_uprobe(struct trace_uprobe *tu)
{
@@ -333,8 +362,12 @@ static int register_trace_uprobe(struct trace_uprobe *tu)
mutex_lock(_lock);
/* register as an event */
- old_tu = find_probe_event(trace_event_name(>tp.call),
- tu->tp.call.class->system);
+ old_tu = find_old_trace_uprobe(tu);
+ if (IS_ERR(old_tu)) {
+ ret = PTR_ERR(old_tu);
+ goto end;
+ }
+
if (old_tu) {
/* delete old event */
ret = unregister_trace_uprobe(old_tu);
--
2.14.4
[PATCH v9 4/4] perf probe: Support SDT markers having reference counter (semaphore)
With this, perf buildid-cache will save SDT markers with reference
counter in probe cache. Perf probe will be able to probe markers
having reference counter. Ex,
# readelf -n /tmp/tick | grep -A1 loop2
Name: loop2
... Semaphore: 0x10020036
# ./perf buildid-cache --add /tmp/tick
# ./perf probe sdt_tick:loop2
# ./perf stat -e sdt_tick:loop2 /tmp/tick
hi: 0
hi: 1
hi: 2
^C
Performance counter stats for '/tmp/tick':
3 sdt_tick:loop2
2.561851452 seconds time elapsed
Signed-off-by: Ravi Bangoria
Acked-by: Masami Hiramatsu
Acked-by: Srikar Dronamraju
---
tools/perf/util/probe-event.c | 39
tools/perf/util/probe-event.h | 1 +
tools/perf/util/probe-file.c | 34 ++--
tools/perf/util/probe-file.h | 1 +
tools/perf/util/symbol-elf.c | 46 ---
tools/perf/util/symbol.h | 7 +++
6 files changed, 106 insertions(+), 22 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index f119eb628dbb..e86f8be89157 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1819,6 +1819,12 @@ int parse_probe_trace_command(const char *cmd, struct
probe_trace_event *tev)
tp->offset = strtoul(fmt2_str, NULL, 10);
}
+ if (tev->uprobes) {
+ fmt2_str = strchr(p, '(');
+ if (fmt2_str)
+ tp->ref_ctr_offset = strtoul(fmt2_str + 1, NULL, 0);
+ }
+
tev->nargs = argc - 2;
tev->args = zalloc(sizeof(struct probe_trace_arg) * tev->nargs);
if (tev->args == NULL) {
@@ -2012,6 +2018,22 @@ static int synthesize_probe_trace_arg(struct
probe_trace_arg *arg,
return err;
}
+static int
+synthesize_uprobe_trace_def(struct probe_trace_event *tev, struct strbuf *buf)
+{
+ struct probe_trace_point *tp = >point;
+ int err;
+
+ err = strbuf_addf(buf, "%s:0x%lx", tp->module, tp->address);
+
+ if (err >= 0 && tp->ref_ctr_offset) {
+ if (!uprobe_ref_ctr_is_supported())
+ return -1;
+ err = strbuf_addf(buf, "(0x%lx)", tp->ref_ctr_offset);
+ }
+ return err >= 0 ? 0 : -1;
+}
+
char *synthesize_probe_trace_command(struct probe_trace_event *tev)
{
struct probe_trace_point *tp = >point;
@@ -2041,15 +2063,17 @@ char *synthesize_probe_trace_command(struct
probe_trace_event *tev)
}
/* Use the tp->address for uprobes */
- if (tev->uprobes)
- err = strbuf_addf(, "%s:0x%lx", tp->module, tp->address);
- else if (!strncmp(tp->symbol, "0x", 2))
+ if (tev->uprobes) {
+ err = synthesize_uprobe_trace_def(tev, );
+ } else if (!strncmp(tp->symbol, "0x", 2)) {
/* Absolute address. See try_to_find_absolute_address() */
err = strbuf_addf(, "%s%s0x%lx", tp->module ?: "",
tp->module ? ":" : "", tp->address);
- else
+ } else {
err = strbuf_addf(, "%s%s%s+%lu", tp->module ?: "",
tp->module ? ":" : "", tp->symbol, tp->offset);
+ }
+
if (err)
goto error;
@@ -2633,6 +2657,13 @@ static void warn_uprobe_event_compat(struct
probe_trace_event *tev)
{
int i;
char *buf = synthesize_probe_trace_command(tev);
+ struct probe_trace_point *tp = >point;
+
+ if (tp->ref_ctr_offset && !uprobe_ref_ctr_is_supported()) {
+ pr_warning("A semaphore is associated with %s:%s and "
+ "seems your kernel doesn't support it.\n",
+ tev->group, tev->event);
+ }
/* Old uprobe event doesn't support memory dereference */
if (!tev->uprobes || tev->nargs == 0 || !buf)
diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
index 45b14f020558..15a98c3a2a2f 100644
--- a/tools/perf/util/probe-event.h
+++ b/tools/perf/util/probe-event.h
@@ -27,6 +27,7 @@ struct probe_trace_point {
char*symbol;/* Base symbol */
char*module;/* Module name */
unsigned long offset; /* Offset from symbol */
+ unsigned long ref_ctr_offset; /* SDT reference counter offset */
unsigned long address;/* Actual address of the trace point */
boolretprobe; /* Return probe flag */
};
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index b76088fadf3d..aac7817d9e14 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -696,8 +696,16 @@ int probe_cache__add_entry(struct probe_cache *pcache,
#ifdef HAVE_GELF_GETNOTE_SUPPORT
static unsigned long long sdt_note__get_addr(struct sdt_note *note)
{
- return note->bit32 ? (unsigned long
[PATCH v9 3/4] trace_uprobe/sdt: Prevent multiple reference counter for same uprobe
We assume to have only one reference counter for one uprobe.
Don't allow user to add multiple trace_uprobe entries having
same inode+offset but different reference counter.
Ex,
# echo "p:sdt_tick/loop2 /home/ravi/tick:0x6e4(0x10036)" > uprobe_events
# echo "p:sdt_tick/loop2_1 /home/ravi/tick:0x6e4(0xf)" >> uprobe_events
bash: echo: write error: Invalid argument
# dmesg
trace_kprobe: Reference counter offset mismatch.
There is one exception though:
When user is trying to replace the old entry with the new
one, we allow this if the new entry does not conflict with
any other existing entries.
Signed-off-by: Ravi Bangoria
Acked-by: Srikar Dronamraju
Reviewed-by: Song Liu
Reviewed-by: Oleg Nesterov
---
kernel/trace/trace_uprobe.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index a7ef6c4ca16e..21d9fffaa096 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -324,6 +324,35 @@ static int unregister_trace_uprobe(struct trace_uprobe *tu)
return 0;
}
+/*
+ * Uprobe with multiple reference counter is not allowed. i.e.
+ * If inode and offset matches, reference counter offset *must*
+ * match as well. Though, there is one exception: If user is
+ * replacing old trace_uprobe with new one(same group/event),
+ * then we allow same uprobe with new reference counter as far
+ * as the new one does not conflict with any other existing
+ * ones.
+ */
+static struct trace_uprobe *find_old_trace_uprobe(struct trace_uprobe *new)
+{
+ struct trace_uprobe *tmp, *old = NULL;
+ struct inode *new_inode = d_real_inode(new->path.dentry);
+
+ old = find_probe_event(trace_event_name(>tp.call),
+ new->tp.call.class->system);
+
+ list_for_each_entry(tmp, _list, list) {
+ if ((old ? old != tmp : true) &&
+ new_inode == d_real_inode(tmp->path.dentry) &&
+ new->offset == tmp->offset &&
+ new->ref_ctr_offset != tmp->ref_ctr_offset) {
+ pr_warn("Reference counter offset mismatch.");
+ return ERR_PTR(-EINVAL);
+ }
+ }
+ return old;
+}
+
/* Register a trace_uprobe and probe_event */
static int register_trace_uprobe(struct trace_uprobe *tu)
{
@@ -333,8 +362,12 @@ static int register_trace_uprobe(struct trace_uprobe *tu)
mutex_lock(_lock);
/* register as an event */
- old_tu = find_probe_event(trace_event_name(>tp.call),
- tu->tp.call.class->system);
+ old_tu = find_old_trace_uprobe(tu);
+ if (IS_ERR(old_tu)) {
+ ret = PTR_ERR(old_tu);
+ goto end;
+ }
+
if (old_tu) {
/* delete old event */
ret = unregister_trace_uprobe(old_tu);
--
2.14.4
[PATCH v9 2/4] Uprobes/sdt: Prevent multiple reference counter for same uprobe
We assume to have only one reference counter for one uprobe.
Don't allow user to register multiple uprobes having same
inode+offset but different reference counter.
Signed-off-by: Ravi Bangoria
Acked-by: Srikar Dronamraju
Reviewed-by: Oleg Nesterov
---
kernel/events/uprobes.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 35065febcb6c..ecee371a59c7 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -679,6 +679,16 @@ static struct uprobe *insert_uprobe(struct uprobe *uprobe)
return u;
}
+static void
+ref_ctr_mismatch_warn(struct uprobe *cur_uprobe, struct uprobe *uprobe)
+{
+ pr_warn("ref_ctr_offset mismatch. inode: 0x%lx offset: 0x%llx "
+ "ref_ctr_offset(old): 0x%llx ref_ctr_offset(new): 0x%llx\n",
+ uprobe->inode->i_ino, (unsigned long long) uprobe->offset,
+ (unsigned long long) cur_uprobe->ref_ctr_offset,
+ (unsigned long long) uprobe->ref_ctr_offset);
+}
+
static struct uprobe *alloc_uprobe(struct inode *inode, loff_t offset,
loff_t ref_ctr_offset)
{
@@ -698,6 +708,12 @@ static struct uprobe *alloc_uprobe(struct inode *inode,
loff_t offset,
cur_uprobe = insert_uprobe(uprobe);
/* a uprobe exists for this inode:offset combination */
if (cur_uprobe) {
+ if (cur_uprobe->ref_ctr_offset != uprobe->ref_ctr_offset) {
+ ref_ctr_mismatch_warn(cur_uprobe, uprobe);
+ put_uprobe(cur_uprobe);
+ kfree(uprobe);
+ return ERR_PTR(-EINVAL);
+ }
kfree(uprobe);
uprobe = cur_uprobe;
}
@@ -1112,6 +1128,9 @@ static int __uprobe_register(struct inode *inode, loff_t
offset,
uprobe = alloc_uprobe(inode, offset, ref_ctr_offset);
if (!uprobe)
return -ENOMEM;
+ if (IS_ERR(uprobe))
+ return PTR_ERR(uprobe);
+
/*
* We can race with uprobe_unregister()->delete_uprobe().
* Check uprobe_is_active() and retry if it is false.
--
2.14.4
[PATCH v9 1/4] Uprobes: Support SDT markers having reference count (semaphore)
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. Applications like PostgreSQL, MySQL,
Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
have these markers embedded in them. These markers are added by developer
at important places in the code. Each marker source expands to a single
nop instruction in the compiled code but there may be additional
overhead for computing the marker arguments which expands to couple of
instructions. In case the overhead is more, execution of it can be
omitted by runtime if() condition when no one is tracing on the marker:
if (reference_counter > 0) {
Execute marker instructions;
}
Default value of reference counter is 0. Tracer has to increment the
reference counter before tracing on a marker and decrement it when
done with the tracing.
Implement the reference counter logic in core uprobe. User will be
able to use it from trace_uprobe as well as from kernel module. New
trace_uprobe definition with reference counter will now be:
:[(ref_ctr_offset)]
where ref_ctr_offset is an optional field. For kernel module, new
variant of uprobe_register() has been introduced:
uprobe_register_refctr(inode, offset, ref_ctr_offset, consumer)
No new variant for uprobe_unregister() because it's assumed to have
only one reference counter for one uprobe.
[1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
Note: 'reference counter' is called as 'semaphore' in original Dtrace
(or Systemtap, bcc and even in ELF) documentation and code. But the
term 'semaphore' is misleading in this context. This is just a counter
used to hold number of tracers tracing on a marker. This is not really
used for any synchronization. So we are calling it a 'reference counter'
in kernel / perf code.
Signed-off-by: Ravi Bangoria
Reviewed-by: Masami Hiramatsu
[Only trace_uprobe.c]
Reviewed-by: Oleg Nesterov
---
include/linux/uprobes.h | 5 +
kernel/events/uprobes.c | 259 ++--
kernel/trace/trace.c| 2 +-
kernel/trace/trace_uprobe.c | 38 ++-
4 files changed, 293 insertions(+), 11 deletions(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index bb9d2084af03..103a48a48872 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -123,6 +123,7 @@ extern unsigned long uprobe_get_swbp_addr(struct pt_regs
*regs);
extern unsigned long uprobe_get_trap_addr(struct pt_regs *regs);
extern int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct
*mm, unsigned long vaddr, uprobe_opcode_t);
extern int uprobe_register(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc);
+extern int uprobe_register_refctr(struct inode *inode, loff_t offset, loff_t
ref_ctr_offset, struct uprobe_consumer *uc);
extern int uprobe_apply(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc, bool);
extern void uprobe_unregister(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc);
extern int uprobe_mmap(struct vm_area_struct *vma);
@@ -160,6 +161,10 @@ uprobe_register(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc)
{
return -ENOSYS;
}
+static inline int uprobe_register_refctr(struct inode *inode, loff_t offset,
loff_t ref_ctr_offset, struct uprobe_consumer *uc)
+{
+ return -ENOSYS;
+}
static inline int
uprobe_apply(struct inode *inode, loff_t offset, struct uprobe_consumer *uc,
bool add)
{
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 919c1ce32beb..35065febcb6c 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -73,6 +73,7 @@ struct uprobe {
struct uprobe_consumer *consumers;
struct inode*inode; /* Also hold a ref to inode */
loff_t offset;
+ loff_t ref_ctr_offset;
unsigned long flags;
/*
@@ -88,6 +89,15 @@ struct uprobe {
struct arch_uprobe arch;
};
+struct delayed_uprobe {
+ struct list_head list;
+ struct uprobe *uprobe;
+ struct mm_struct *mm;
+};
+
+static DEFINE_MUTEX(delayed_uprobe_lock);
+static LIST_HEAD(delayed_uprobe_list);
+
/*
* Execute out of line area: anonymous executable mapping installed
* by the probed task to execute the copy of the original instruction
@@ -282,6 +292,166 @@ static int verify_opcode(struct page *page, unsigned long
vaddr, uprobe_opcode_t
return 1;
}
+static struct delayed_uprobe *
+delayed_uprobe_check(struct uprobe *uprobe, struct mm_struct *mm)
+{
+ struct delayed_uprobe *du;
+
+ list_for_each_entry(du, _uprobe_list, list)
+ if (du->uprobe == uprobe && du->mm == mm)
+ return du;
+ return NULL;
+}
+
+static int delayed_uprobe_add(struct uprobe *uprobe, struct mm_struct *mm)
+{
+ struct delayed_uprobe *du;
+
+ if (delayed_uprobe_check(uprobe, mm))
+
[PATCH v9 2/4] Uprobes/sdt: Prevent multiple reference counter for same uprobe
We assume to have only one reference counter for one uprobe.
Don't allow user to register multiple uprobes having same
inode+offset but different reference counter.
Signed-off-by: Ravi Bangoria
Acked-by: Srikar Dronamraju
Reviewed-by: Oleg Nesterov
---
kernel/events/uprobes.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 35065febcb6c..ecee371a59c7 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -679,6 +679,16 @@ static struct uprobe *insert_uprobe(struct uprobe *uprobe)
return u;
}
+static void
+ref_ctr_mismatch_warn(struct uprobe *cur_uprobe, struct uprobe *uprobe)
+{
+ pr_warn("ref_ctr_offset mismatch. inode: 0x%lx offset: 0x%llx "
+ "ref_ctr_offset(old): 0x%llx ref_ctr_offset(new): 0x%llx\n",
+ uprobe->inode->i_ino, (unsigned long long) uprobe->offset,
+ (unsigned long long) cur_uprobe->ref_ctr_offset,
+ (unsigned long long) uprobe->ref_ctr_offset);
+}
+
static struct uprobe *alloc_uprobe(struct inode *inode, loff_t offset,
loff_t ref_ctr_offset)
{
@@ -698,6 +708,12 @@ static struct uprobe *alloc_uprobe(struct inode *inode,
loff_t offset,
cur_uprobe = insert_uprobe(uprobe);
/* a uprobe exists for this inode:offset combination */
if (cur_uprobe) {
+ if (cur_uprobe->ref_ctr_offset != uprobe->ref_ctr_offset) {
+ ref_ctr_mismatch_warn(cur_uprobe, uprobe);
+ put_uprobe(cur_uprobe);
+ kfree(uprobe);
+ return ERR_PTR(-EINVAL);
+ }
kfree(uprobe);
uprobe = cur_uprobe;
}
@@ -1112,6 +1128,9 @@ static int __uprobe_register(struct inode *inode, loff_t
offset,
uprobe = alloc_uprobe(inode, offset, ref_ctr_offset);
if (!uprobe)
return -ENOMEM;
+ if (IS_ERR(uprobe))
+ return PTR_ERR(uprobe);
+
/*
* We can race with uprobe_unregister()->delete_uprobe().
* Check uprobe_is_active() and retry if it is false.
--
2.14.4
[PATCH v9 1/4] Uprobes: Support SDT markers having reference count (semaphore)
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. Applications like PostgreSQL, MySQL,
Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
have these markers embedded in them. These markers are added by developer
at important places in the code. Each marker source expands to a single
nop instruction in the compiled code but there may be additional
overhead for computing the marker arguments which expands to couple of
instructions. In case the overhead is more, execution of it can be
omitted by runtime if() condition when no one is tracing on the marker:
if (reference_counter > 0) {
Execute marker instructions;
}
Default value of reference counter is 0. Tracer has to increment the
reference counter before tracing on a marker and decrement it when
done with the tracing.
Implement the reference counter logic in core uprobe. User will be
able to use it from trace_uprobe as well as from kernel module. New
trace_uprobe definition with reference counter will now be:
:[(ref_ctr_offset)]
where ref_ctr_offset is an optional field. For kernel module, new
variant of uprobe_register() has been introduced:
uprobe_register_refctr(inode, offset, ref_ctr_offset, consumer)
No new variant for uprobe_unregister() because it's assumed to have
only one reference counter for one uprobe.
[1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
Note: 'reference counter' is called as 'semaphore' in original Dtrace
(or Systemtap, bcc and even in ELF) documentation and code. But the
term 'semaphore' is misleading in this context. This is just a counter
used to hold number of tracers tracing on a marker. This is not really
used for any synchronization. So we are calling it a 'reference counter'
in kernel / perf code.
Signed-off-by: Ravi Bangoria
Reviewed-by: Masami Hiramatsu
[Only trace_uprobe.c]
Reviewed-by: Oleg Nesterov
---
include/linux/uprobes.h | 5 +
kernel/events/uprobes.c | 259 ++--
kernel/trace/trace.c| 2 +-
kernel/trace/trace_uprobe.c | 38 ++-
4 files changed, 293 insertions(+), 11 deletions(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index bb9d2084af03..103a48a48872 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -123,6 +123,7 @@ extern unsigned long uprobe_get_swbp_addr(struct pt_regs
*regs);
extern unsigned long uprobe_get_trap_addr(struct pt_regs *regs);
extern int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct
*mm, unsigned long vaddr, uprobe_opcode_t);
extern int uprobe_register(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc);
+extern int uprobe_register_refctr(struct inode *inode, loff_t offset, loff_t
ref_ctr_offset, struct uprobe_consumer *uc);
extern int uprobe_apply(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc, bool);
extern void uprobe_unregister(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc);
extern int uprobe_mmap(struct vm_area_struct *vma);
@@ -160,6 +161,10 @@ uprobe_register(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc)
{
return -ENOSYS;
}
+static inline int uprobe_register_refctr(struct inode *inode, loff_t offset,
loff_t ref_ctr_offset, struct uprobe_consumer *uc)
+{
+ return -ENOSYS;
+}
static inline int
uprobe_apply(struct inode *inode, loff_t offset, struct uprobe_consumer *uc,
bool add)
{
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 919c1ce32beb..35065febcb6c 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -73,6 +73,7 @@ struct uprobe {
struct uprobe_consumer *consumers;
struct inode*inode; /* Also hold a ref to inode */
loff_t offset;
+ loff_t ref_ctr_offset;
unsigned long flags;
/*
@@ -88,6 +89,15 @@ struct uprobe {
struct arch_uprobe arch;
};
+struct delayed_uprobe {
+ struct list_head list;
+ struct uprobe *uprobe;
+ struct mm_struct *mm;
+};
+
+static DEFINE_MUTEX(delayed_uprobe_lock);
+static LIST_HEAD(delayed_uprobe_list);
+
/*
* Execute out of line area: anonymous executable mapping installed
* by the probed task to execute the copy of the original instruction
@@ -282,6 +292,166 @@ static int verify_opcode(struct page *page, unsigned long
vaddr, uprobe_opcode_t
return 1;
}
+static struct delayed_uprobe *
+delayed_uprobe_check(struct uprobe *uprobe, struct mm_struct *mm)
+{
+ struct delayed_uprobe *du;
+
+ list_for_each_entry(du, _uprobe_list, list)
+ if (du->uprobe == uprobe && du->mm == mm)
+ return du;
+ return NULL;
+}
+
+static int delayed_uprobe_add(struct uprobe *uprobe, struct mm_struct *mm)
+{
+ struct delayed_uprobe *du;
+
+ if (delayed_uprobe_check(uprobe, mm))
+
[PATCH v9 0/4] Uprobes: Support SDT markers having reference count (semaphore)
v8 -> v9:
- Rebased to rostedt/for-next (Commit bb730b5833b5 to be precise)
- Not including first two patches now. They are already pulled by
Steven.
- Change delayed_uprobe_remove() function as suggested by Oleg
- Dump inode, offset, ref_ctr_offset, mm etc if we fail to update
reference counter.
- Rename delayed_uprobe_install() to delayed_ref_ctr_inc()
- Use 'short d' (delta) in update_ref_ctr() in place of 'bool
is_register'.
v8: https://lkml.org/lkml/2018/8/9/81
Future work:
- Optimize uprobe_mmap()->delayed_ref_ctr_inc() by making
delayed_uprobe_list per mm.
Description:
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. Applications like PostgreSQL, MySQL,
Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
have these markers embedded in them. These markers are added by developer
at important places in the code. Each marker source expands to a single
nop instruction in the compiled code but there may be additional
overhead for computing the marker arguments which expands to couple of
instructions. In case the overhead is more, execution of it can be
omitted by runtime if() condition when no one is tracing on the marker:
if (reference_counter > 0) {
Execute marker instructions;
}
Default value of reference counter is 0. Tracer has to increment the
reference counter before tracing on a marker and decrement it when
done with the tracing.
Currently, perf tool has limited supports for SDT markers. I.e. it
can not trace markers surrounded by reference counter. Also, it's
not easy to add reference counter logic in userspace tool like perf,
so basic idea for this patchset is to add reference counter logic in
the a uprobe infrastructure. Ex,[2]
# cat tick.c
...
for (i = 0; i < 100; i++) {
DTRACE_PROBE1(tick, loop1, i);
if (TICK_LOOP2_ENABLED()) {
DTRACE_PROBE1(tick, loop2, i);
}
printf("hi: %d\n", i);
sleep(1);
}
...
Here tick:loop1 is marker without reference counter where as tick:loop2
is surrounded by reference counter condition.
# perf buildid-cache --add /tmp/tick
# perf probe sdt_tick:loop1
# perf probe sdt_tick:loop2
# perf stat -e sdt_tick:loop1,sdt_tick:loop2 -- /tmp/tick
hi: 0
hi: 1
hi: 2
^C
Performance counter stats for '/tmp/tick':
3 sdt_tick:loop1
0 sdt_tick:loop2
2.747086086 seconds time elapsed
Perf failed to record data for tick:loop2. Same experiment with this
patch series:
# ./perf buildid-cache --add /tmp/tick
# ./perf probe sdt_tick:loop2
# ./perf stat -e sdt_tick:loop2 /tmp/tick
hi: 0
hi: 1
hi: 2
^C
Performance counter stats for '/tmp/tick':
3 sdt_tick:loop2
2.561851452 seconds time elapsed
[1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
[2] https://github.com/iovisor/bcc/issues/327#issuecomment-200576506
Ravi Bangoria (4):
Uprobes: Support SDT markers having reference count (semaphore)
Uprobes/sdt: Prevent multiple reference counter for same uprobe
trace_uprobe/sdt: Prevent multiple reference counter for same uprobe
perf probe: Support SDT markers having reference counter (semaphore)
include/linux/uprobes.h | 5 +
kernel/events/uprobes.c | 278 --
kernel/trace/trace.c | 2 +-
kernel/trace/trace_uprobe.c | 75 +++-
tools/perf/util/probe-event.c | 39 +-
tools/perf/util/probe-event.h | 1 +
tools/perf/util/probe-file.c | 34 +-
tools/perf/util/probe-file.h | 1 +
tools/perf/util/symbol-elf.c | 46 +--
tools/perf/util/symbol.h | 7 ++
10 files changed, 453 insertions(+), 35 deletions(-)
--
2.14.4
[PATCH v9 0/4] Uprobes: Support SDT markers having reference count (semaphore)
v8 -> v9:
- Rebased to rostedt/for-next (Commit bb730b5833b5 to be precise)
- Not including first two patches now. They are already pulled by
Steven.
- Change delayed_uprobe_remove() function as suggested by Oleg
- Dump inode, offset, ref_ctr_offset, mm etc if we fail to update
reference counter.
- Rename delayed_uprobe_install() to delayed_ref_ctr_inc()
- Use 'short d' (delta) in update_ref_ctr() in place of 'bool
is_register'.
v8: https://lkml.org/lkml/2018/8/9/81
Future work:
- Optimize uprobe_mmap()->delayed_ref_ctr_inc() by making
delayed_uprobe_list per mm.
Description:
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. Applications like PostgreSQL, MySQL,
Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
have these markers embedded in them. These markers are added by developer
at important places in the code. Each marker source expands to a single
nop instruction in the compiled code but there may be additional
overhead for computing the marker arguments which expands to couple of
instructions. In case the overhead is more, execution of it can be
omitted by runtime if() condition when no one is tracing on the marker:
if (reference_counter > 0) {
Execute marker instructions;
}
Default value of reference counter is 0. Tracer has to increment the
reference counter before tracing on a marker and decrement it when
done with the tracing.
Currently, perf tool has limited supports for SDT markers. I.e. it
can not trace markers surrounded by reference counter. Also, it's
not easy to add reference counter logic in userspace tool like perf,
so basic idea for this patchset is to add reference counter logic in
the a uprobe infrastructure. Ex,[2]
# cat tick.c
...
for (i = 0; i < 100; i++) {
DTRACE_PROBE1(tick, loop1, i);
if (TICK_LOOP2_ENABLED()) {
DTRACE_PROBE1(tick, loop2, i);
}
printf("hi: %d\n", i);
sleep(1);
}
...
Here tick:loop1 is marker without reference counter where as tick:loop2
is surrounded by reference counter condition.
# perf buildid-cache --add /tmp/tick
# perf probe sdt_tick:loop1
# perf probe sdt_tick:loop2
# perf stat -e sdt_tick:loop1,sdt_tick:loop2 -- /tmp/tick
hi: 0
hi: 1
hi: 2
^C
Performance counter stats for '/tmp/tick':
3 sdt_tick:loop1
0 sdt_tick:loop2
2.747086086 seconds time elapsed
Perf failed to record data for tick:loop2. Same experiment with this
patch series:
# ./perf buildid-cache --add /tmp/tick
# ./perf probe sdt_tick:loop2
# ./perf stat -e sdt_tick:loop2 /tmp/tick
hi: 0
hi: 1
hi: 2
^C
Performance counter stats for '/tmp/tick':
3 sdt_tick:loop2
2.561851452 seconds time elapsed
[1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
[2] https://github.com/iovisor/bcc/issues/327#issuecomment-200576506
Ravi Bangoria (4):
Uprobes: Support SDT markers having reference count (semaphore)
Uprobes/sdt: Prevent multiple reference counter for same uprobe
trace_uprobe/sdt: Prevent multiple reference counter for same uprobe
perf probe: Support SDT markers having reference counter (semaphore)
include/linux/uprobes.h | 5 +
kernel/events/uprobes.c | 278 --
kernel/trace/trace.c | 2 +-
kernel/trace/trace_uprobe.c | 75 +++-
tools/perf/util/probe-event.c | 39 +-
tools/perf/util/probe-event.h | 1 +
tools/perf/util/probe-file.c | 34 +-
tools/perf/util/probe-file.h | 1 +
tools/perf/util/symbol-elf.c | 46 +--
tools/perf/util/symbol.h | 7 ++
10 files changed, 453 insertions(+), 35 deletions(-)
--
2.14.4
Re: [PATCH] x86/process: Export start_thread()
On 2018-08-19 19:29, Andy Lutomirski wrote:
On Aug 19, 2018, at 4:08 PM, Rian Hunter wrote:
Commit e634d8fc792c ("x86-64: merge the standard and compat
start_thread() functions") removed exporting for the start_thread()
function in what seems like a typo. Add it back to
arch/x86/kernel/process_64.c for parity with process_32.c and other
arch.
What for? Perhaps 32-bit could remove it instead?
Came across this while writing a binfmt module. Useful for me but
probably no one else on Earth, at least for another ~9 years on average.
Signed-off-by: Rian Hunter
---
arch/x86/kernel/process_64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/process_64.c
b/arch/x86/kernel/process_64.c
index 476e3ddf8890..a451bc374b9b 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -384,6 +384,7 @@ start_thread(struct pt_regs *regs, unsigned long
new_ip, unsigned long new_sp)
start_thread_common(regs, new_ip, new_sp,
__USER_CS, __USER_DS, 0);
}
+EXPORT_SYMBOL_GPL(start_thread);
#ifdef CONFIG_COMPAT
void compat_start_thread(struct pt_regs *regs, u32 new_ip, u32 new_sp)
--
2.16.3
Re: [PATCH] x86/process: Export start_thread()
On 2018-08-19 19:29, Andy Lutomirski wrote:
On Aug 19, 2018, at 4:08 PM, Rian Hunter wrote:
Commit e634d8fc792c ("x86-64: merge the standard and compat
start_thread() functions") removed exporting for the start_thread()
function in what seems like a typo. Add it back to
arch/x86/kernel/process_64.c for parity with process_32.c and other
arch.
What for? Perhaps 32-bit could remove it instead?
Came across this while writing a binfmt module. Useful for me but
probably no one else on Earth, at least for another ~9 years on average.
Signed-off-by: Rian Hunter
---
arch/x86/kernel/process_64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/process_64.c
b/arch/x86/kernel/process_64.c
index 476e3ddf8890..a451bc374b9b 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -384,6 +384,7 @@ start_thread(struct pt_regs *regs, unsigned long
new_ip, unsigned long new_sp)
start_thread_common(regs, new_ip, new_sp,
__USER_CS, __USER_DS, 0);
}
+EXPORT_SYMBOL_GPL(start_thread);
#ifdef CONFIG_COMPAT
void compat_start_thread(struct pt_regs *regs, u32 new_ip, u32 new_sp)
--
2.16.3
linux-next: manual merge of the akpm-current tree with the tip tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got conflicts in:
fs/proc/kcore.c
include/linux/kcore.h
between commit:
6855dc41b246 ("x86: Add entry trampolines to kcore")
from the tip tree and commits:
4eb27c275abf ("fs/proc/kcore.c: use __pa_symbol() for KCORE_TEXT list
entries")
ea551910d3f4 ("proc/kcore: clean up ELF header generation")
537412a2958f ("proc/kcore: don't grab lock for kclist_add()")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/proc/kcore.c
index 00282f134336,80464432dfe6..
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@@ -448,53 -291,148 +291,151 @@@ static ssize_
read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t
*fpos)
{
char *buf = file->private_data;
- ssize_t acc = 0;
- size_t size, tsz;
- size_t elf_buflen;
+ size_t phdrs_offset, notes_offset, data_offset;
+ size_t phdrs_len, notes_len;
+ struct kcore_list *m;
+ size_t tsz;
int nphdr;
unsigned long start;
+ size_t orig_buflen = buflen;
+ int ret = 0;
- read_lock(_lock);
- size = get_kcore_size(, _buflen);
+ down_read(_lock);
+
+ get_kcore_size(, _len, _len, _offset);
+ phdrs_offset = sizeof(struct elfhdr);
+ notes_offset = phdrs_offset + phdrs_len;
+
+ /* ELF file header. */
+ if (buflen && *fpos < sizeof(struct elfhdr)) {
+ struct elfhdr ehdr = {
+ .e_ident = {
+ [EI_MAG0] = ELFMAG0,
+ [EI_MAG1] = ELFMAG1,
+ [EI_MAG2] = ELFMAG2,
+ [EI_MAG3] = ELFMAG3,
+ [EI_CLASS] = ELF_CLASS,
+ [EI_DATA] = ELF_DATA,
+ [EI_VERSION] = EV_CURRENT,
+ [EI_OSABI] = ELF_OSABI,
+ },
+ .e_type = ET_CORE,
+ .e_machine = ELF_ARCH,
+ .e_version = EV_CURRENT,
+ .e_phoff = sizeof(struct elfhdr),
+ .e_flags = ELF_CORE_EFLAGS,
+ .e_ehsize = sizeof(struct elfhdr),
+ .e_phentsize = sizeof(struct elf_phdr),
+ .e_phnum = nphdr,
+ };
+
+ tsz = min_t(size_t, buflen, sizeof(struct elfhdr) - *fpos);
+ if (copy_to_user(buffer, (char *) + *fpos, tsz)) {
+ ret = -EFAULT;
+ goto out;
+ }
- if (buflen == 0 || *fpos >= size) {
- read_unlock(_lock);
- return 0;
+ buffer += tsz;
+ buflen -= tsz;
+ *fpos += tsz;
}
- /* trim buflen to not go beyond EOF */
- if (buflen > size - *fpos)
- buflen = size - *fpos;
-
- /* construct an ELF core header if we'll need some of it */
- if (*fpos < elf_buflen) {
- char * elf_buf;
-
- tsz = elf_buflen - *fpos;
- if (buflen < tsz)
- tsz = buflen;
- elf_buf = kzalloc(elf_buflen, GFP_ATOMIC);
- if (!elf_buf) {
- read_unlock(_lock);
- return -ENOMEM;
+ /* ELF program headers. */
+ if (buflen && *fpos < phdrs_offset + phdrs_len) {
+ struct elf_phdr *phdrs, *phdr;
+
+ phdrs = kzalloc(phdrs_len, GFP_KERNEL);
+ if (!phdrs) {
+ ret = -ENOMEM;
+ goto out;
}
- elf_kcore_store_hdr(elf_buf, nphdr, elf_buflen);
- read_unlock(_lock);
- if (copy_to_user(buffer, elf_buf + *fpos, tsz)) {
- kfree(elf_buf);
- return -EFAULT;
+
+ phdrs[0].p_type = PT_NOTE;
+ phdrs[0].p_offset = notes_offset;
+ phdrs[0].p_filesz = notes_len;
+
+ phdr = [1];
+ list_for_each_entry(m, _head, list) {
+ phdr->p_type = PT_LOAD;
+ phdr->p_flags = PF_R | PF_W | PF_X;
+ phdr->p_offset = kc_vaddr_to_offset(m->addr) +
data_offset;
- phdr->p_vaddr = (size_t)m->addr;
- if (m->type == KCORE_RAM)
++ if (m->type == KCORE_REMAP)
++ phdr->p_vaddr =
linux-next: manual merge of the akpm-current tree with the tip tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got conflicts in:
fs/proc/kcore.c
include/linux/kcore.h
between commit:
6855dc41b246 ("x86: Add entry trampolines to kcore")
from the tip tree and commits:
4eb27c275abf ("fs/proc/kcore.c: use __pa_symbol() for KCORE_TEXT list
entries")
ea551910d3f4 ("proc/kcore: clean up ELF header generation")
537412a2958f ("proc/kcore: don't grab lock for kclist_add()")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/proc/kcore.c
index 00282f134336,80464432dfe6..
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@@ -448,53 -291,148 +291,151 @@@ static ssize_
read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t
*fpos)
{
char *buf = file->private_data;
- ssize_t acc = 0;
- size_t size, tsz;
- size_t elf_buflen;
+ size_t phdrs_offset, notes_offset, data_offset;
+ size_t phdrs_len, notes_len;
+ struct kcore_list *m;
+ size_t tsz;
int nphdr;
unsigned long start;
+ size_t orig_buflen = buflen;
+ int ret = 0;
- read_lock(_lock);
- size = get_kcore_size(, _buflen);
+ down_read(_lock);
+
+ get_kcore_size(, _len, _len, _offset);
+ phdrs_offset = sizeof(struct elfhdr);
+ notes_offset = phdrs_offset + phdrs_len;
+
+ /* ELF file header. */
+ if (buflen && *fpos < sizeof(struct elfhdr)) {
+ struct elfhdr ehdr = {
+ .e_ident = {
+ [EI_MAG0] = ELFMAG0,
+ [EI_MAG1] = ELFMAG1,
+ [EI_MAG2] = ELFMAG2,
+ [EI_MAG3] = ELFMAG3,
+ [EI_CLASS] = ELF_CLASS,
+ [EI_DATA] = ELF_DATA,
+ [EI_VERSION] = EV_CURRENT,
+ [EI_OSABI] = ELF_OSABI,
+ },
+ .e_type = ET_CORE,
+ .e_machine = ELF_ARCH,
+ .e_version = EV_CURRENT,
+ .e_phoff = sizeof(struct elfhdr),
+ .e_flags = ELF_CORE_EFLAGS,
+ .e_ehsize = sizeof(struct elfhdr),
+ .e_phentsize = sizeof(struct elf_phdr),
+ .e_phnum = nphdr,
+ };
+
+ tsz = min_t(size_t, buflen, sizeof(struct elfhdr) - *fpos);
+ if (copy_to_user(buffer, (char *) + *fpos, tsz)) {
+ ret = -EFAULT;
+ goto out;
+ }
- if (buflen == 0 || *fpos >= size) {
- read_unlock(_lock);
- return 0;
+ buffer += tsz;
+ buflen -= tsz;
+ *fpos += tsz;
}
- /* trim buflen to not go beyond EOF */
- if (buflen > size - *fpos)
- buflen = size - *fpos;
-
- /* construct an ELF core header if we'll need some of it */
- if (*fpos < elf_buflen) {
- char * elf_buf;
-
- tsz = elf_buflen - *fpos;
- if (buflen < tsz)
- tsz = buflen;
- elf_buf = kzalloc(elf_buflen, GFP_ATOMIC);
- if (!elf_buf) {
- read_unlock(_lock);
- return -ENOMEM;
+ /* ELF program headers. */
+ if (buflen && *fpos < phdrs_offset + phdrs_len) {
+ struct elf_phdr *phdrs, *phdr;
+
+ phdrs = kzalloc(phdrs_len, GFP_KERNEL);
+ if (!phdrs) {
+ ret = -ENOMEM;
+ goto out;
}
- elf_kcore_store_hdr(elf_buf, nphdr, elf_buflen);
- read_unlock(_lock);
- if (copy_to_user(buffer, elf_buf + *fpos, tsz)) {
- kfree(elf_buf);
- return -EFAULT;
+
+ phdrs[0].p_type = PT_NOTE;
+ phdrs[0].p_offset = notes_offset;
+ phdrs[0].p_filesz = notes_len;
+
+ phdr = [1];
+ list_for_each_entry(m, _head, list) {
+ phdr->p_type = PT_LOAD;
+ phdr->p_flags = PF_R | PF_W | PF_X;
+ phdr->p_offset = kc_vaddr_to_offset(m->addr) +
data_offset;
- phdr->p_vaddr = (size_t)m->addr;
- if (m->type == KCORE_RAM)
++ if (m->type == KCORE_REMAP)
++ phdr->p_vaddr =
KASAN: slab-out-of-bounds Read in rdma_listen
Hello, syzbot found the following crash on: HEAD commit:5c60a7389d79 Merge tag 'for-linus-4.19-ofs1' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10bf9aee40 kernel config: https://syzkaller.appspot.com/x/.config?x=4fd89f99c889a184 dashboard link: https://syzkaller.appspot.com/bug?extid=c92378b32760a4eef756 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c92378b32760a4eef...@syzkaller.appspotmail.com == BUG: KASAN: slab-out-of-bounds in __list_add_valid+0x8f/0xb0 lib/list_debug.c:26 Read of size 8 at addr 880188b13098 by task syz-executor6/27383 CPU: 1 PID: 27383 Comm: syz-executor6 Not tainted 4.18.0+ #193 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 __list_add_valid+0x8f/0xb0 lib/list_debug.c:26 __list_add include/linux/list.h:60 [inline] list_add_tail include/linux/list.h:93 [inline] cma_listen_on_all drivers/infiniband/core/cma.c:2328 [inline] rdma_listen+0x6dc/0x990 drivers/infiniband/core/cma.c:3354 ucma_listen+0x1a4/0x260 drivers/infiniband/core/ucma.c:1096 ucma_write+0x336/0x420 drivers/infiniband/core/ucma.c:1680 __vfs_write+0x117/0x9d0 fs/read_write.c:485 vfs_write+0x1f8/0x560 fs/read_write.c:549 ksys_write+0x101/0x260 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457089 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f211d28dc78 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: 7f211d28e6d4 RCX: 00457089 RDX: 0010 RSI: 2080 RDI: 0004 RBP: 009300a0 R08: R09: R10: R11: 0246 R12: R13: 004d7448 R14: 004ca592 R15: Allocated by task 2291: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554 getname_flags+0xd0/0x5a0 fs/namei.c:140 getname+0x19/0x20 fs/namei.c:211 do_sys_open+0x3a2/0x760 fs/open.c:1055 __do_sys_open fs/open.c:1079 [inline] __se_sys_open fs/open.c:1074 [inline] __x64_sys_open+0x7e/0xc0 fs/open.c:1074 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 2291: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x86/0x2d0 mm/slab.c:3756 putname+0xf2/0x130 fs/namei.c:261 do_sys_open+0x569/0x760 fs/open.c:1070 __do_sys_open fs/open.c:1079 [inline] __se_sys_open fs/open.c:1074 [inline] __x64_sys_open+0x7e/0xc0 fs/open.c:1074 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at 880188b12000 which belongs to the cache names_cache of size 4096 The buggy address is located 152 bytes to the right of 4096-byte region [880188b12000, 880188b13000) The buggy address belongs to the page: page:ea000622c480 count:1 mapcount:0 mapping:8801dad85dc0 index:0x0 compound_mapcount: 0 flags: 0x2fffc008100(slab|head) raw: 02fffc008100 ea00074e8708 ea00073cdb08 8801dad85dc0 raw: 880188b12000 00010001 page dumped because: kasan: bad access detected Memory state around the buggy address: 880188b12f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 880188b13000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 880188b13080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ 880188b13100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 880188b13180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc == --- This bug is generated by a bot. It may contain
KASAN: slab-out-of-bounds Read in rdma_listen
Hello, syzbot found the following crash on: HEAD commit:5c60a7389d79 Merge tag 'for-linus-4.19-ofs1' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10bf9aee40 kernel config: https://syzkaller.appspot.com/x/.config?x=4fd89f99c889a184 dashboard link: https://syzkaller.appspot.com/bug?extid=c92378b32760a4eef756 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c92378b32760a4eef...@syzkaller.appspotmail.com == BUG: KASAN: slab-out-of-bounds in __list_add_valid+0x8f/0xb0 lib/list_debug.c:26 Read of size 8 at addr 880188b13098 by task syz-executor6/27383 CPU: 1 PID: 27383 Comm: syz-executor6 Not tainted 4.18.0+ #193 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 __list_add_valid+0x8f/0xb0 lib/list_debug.c:26 __list_add include/linux/list.h:60 [inline] list_add_tail include/linux/list.h:93 [inline] cma_listen_on_all drivers/infiniband/core/cma.c:2328 [inline] rdma_listen+0x6dc/0x990 drivers/infiniband/core/cma.c:3354 ucma_listen+0x1a4/0x260 drivers/infiniband/core/ucma.c:1096 ucma_write+0x336/0x420 drivers/infiniband/core/ucma.c:1680 __vfs_write+0x117/0x9d0 fs/read_write.c:485 vfs_write+0x1f8/0x560 fs/read_write.c:549 ksys_write+0x101/0x260 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457089 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f211d28dc78 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: 7f211d28e6d4 RCX: 00457089 RDX: 0010 RSI: 2080 RDI: 0004 RBP: 009300a0 R08: R09: R10: R11: 0246 R12: R13: 004d7448 R14: 004ca592 R15: Allocated by task 2291: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554 getname_flags+0xd0/0x5a0 fs/namei.c:140 getname+0x19/0x20 fs/namei.c:211 do_sys_open+0x3a2/0x760 fs/open.c:1055 __do_sys_open fs/open.c:1079 [inline] __se_sys_open fs/open.c:1074 [inline] __x64_sys_open+0x7e/0xc0 fs/open.c:1074 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 2291: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x86/0x2d0 mm/slab.c:3756 putname+0xf2/0x130 fs/namei.c:261 do_sys_open+0x569/0x760 fs/open.c:1070 __do_sys_open fs/open.c:1079 [inline] __se_sys_open fs/open.c:1074 [inline] __x64_sys_open+0x7e/0xc0 fs/open.c:1074 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at 880188b12000 which belongs to the cache names_cache of size 4096 The buggy address is located 152 bytes to the right of 4096-byte region [880188b12000, 880188b13000) The buggy address belongs to the page: page:ea000622c480 count:1 mapcount:0 mapping:8801dad85dc0 index:0x0 compound_mapcount: 0 flags: 0x2fffc008100(slab|head) raw: 02fffc008100 ea00074e8708 ea00073cdb08 8801dad85dc0 raw: 880188b12000 00010001 page dumped because: kasan: bad access detected Memory state around the buggy address: 880188b12f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 880188b13000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 880188b13080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ 880188b13100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 880188b13180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc == --- This bug is generated by a bot. It may contain
[PATCH] UBIFS: Fix typo of output in get_cs_sqnum
"Not a CS node" makes more sense than "Node a CS node".
Signed-off-by: Liu Song
Reviewed-by: Jiang Biao
---
fs/ubifs/recovery.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ubifs/recovery.c b/fs/ubifs/recovery.c
index 3af4472061cc..400163dc7022 100644
--- a/fs/ubifs/recovery.c
+++ b/fs/ubifs/recovery.c
@@ -829,7 +829,7 @@ static int get_cs_sqnum(struct ubifs_info *c, int lnum, int
offs,
goto out_err;
}
if (cs_node->ch.node_type != UBIFS_CS_NODE) {
- ubifs_err(c, "Node a CS node, type is %d",
cs_node->ch.node_type);
+ ubifs_err(c, "Not a CS node, type is %d",
cs_node->ch.node_type);
goto out_err;
}
if (le64_to_cpu(cs_node->cmt_no) != c->cmt_no) {
--
2.17.1
[PATCH] UBIFS: Fix typo of output in get_cs_sqnum
"Not a CS node" makes more sense than "Node a CS node".
Signed-off-by: Liu Song
Reviewed-by: Jiang Biao
---
fs/ubifs/recovery.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ubifs/recovery.c b/fs/ubifs/recovery.c
index 3af4472061cc..400163dc7022 100644
--- a/fs/ubifs/recovery.c
+++ b/fs/ubifs/recovery.c
@@ -829,7 +829,7 @@ static int get_cs_sqnum(struct ubifs_info *c, int lnum, int
offs,
goto out_err;
}
if (cs_node->ch.node_type != UBIFS_CS_NODE) {
- ubifs_err(c, "Node a CS node, type is %d",
cs_node->ch.node_type);
+ ubifs_err(c, "Not a CS node, type is %d",
cs_node->ch.node_type);
goto out_err;
}
if (le64_to_cpu(cs_node->cmt_no) != c->cmt_no) {
--
2.17.1
[PATCH] mtd: nand: denali: use SPDX-License-Identifier and fix license mismatch
Use SPDX-License-Identifier instead of the license boilerplates.
This conversion makes it easier for us to scan the license, then
I notice license mismatch problems.
The license blocks in denali* indicate GPL-2.0 "only", while the
MODULE_LICENSE in denali.c and denali_dt.c is GPL-2.0 "or later"
as explained in include/linux/module.h as follows:
"GPL" [GNU Public License v2 or later]
"GPL v2"[GNU Public License v2]
I fixed the MODULE_LICENSE tags, assuming the license blocks are
the authors' intention.
Also, add missing MODULE_DESCRIPTION/AUTHOR to denali.c
While I am touching the license things, I added my credit to denali.c
because this driver was largely re-written by me in 2017.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/raw/denali.c | 17 +++--
drivers/mtd/nand/raw/denali.h | 10 +-
drivers/mtd/nand/raw/denali_dt.c | 12 ++--
drivers/mtd/nand/raw/denali_pci.c | 10 +-
4 files changed, 11 insertions(+), 38 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index ca18612..9f432f0 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -1,15 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* NAND Flash Controller Device Driver
* Copyright © 2009-2010, Intel Corporation and its suppliers.
*
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.
+ * Copyright (c) 2017 Socionext Inc.
+ * Reworked by Masahiro Yamada
*/
#include
@@ -25,8 +20,6 @@
#include "denali.h"
-MODULE_LICENSE("GPL");
-
#define DENALI_NAND_NAME"denali-nand"
/* for Indexed Addressing */
@@ -1396,3 +1389,7 @@ void denali_remove(struct denali_nand_info *denali)
denali_disable_irq(denali);
}
EXPORT_SYMBOL(denali_remove);
+
+MODULE_DESCRIPTION("Driver core for Denali NAND controller");
+MODULE_AUTHOR("Intel Corporation and its suppliers");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/mtd/nand/raw/denali.h b/drivers/mtd/nand/raw/denali.h
index 1f8feaf..57a5498 100644
--- a/drivers/mtd/nand/raw/denali.h
+++ b/drivers/mtd/nand/raw/denali.h
@@ -1,15 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* NAND Flash Controller Device Driver
* Copyright (c) 2009 - 2010, Intel Corporation and its suppliers.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.
*/
#ifndef __DENALI_H__
diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c
index 0faaad0..7c6a8a4 100644
--- a/drivers/mtd/nand/raw/denali_dt.c
+++ b/drivers/mtd/nand/raw/denali_dt.c
@@ -1,16 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* NAND Flash Controller Device Driver for DT
*
* Copyright © 2011, Picochip.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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
@@ -202,6 +194,6 @@ static struct platform_driver denali_dt_driver = {
};
module_platform_driver(denali_dt_driver);
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Jamie Iles");
MODULE_DESCRIPTION("DT driver for Denali NAND controller");
diff --git a/drivers/mtd/nand/raw/denali_pci.c
b/drivers/mtd/nand/raw/denali_pci.c
index 7c8efc4..48e9ac5 100644
--- a/drivers/mtd/nand/raw/denali_pci.c
+++ b/drivers/mtd/nand/raw/denali_pci.c
@@ -1,15 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* NAND Flash Controller Device Driver
* Copyright © 2009-2010, Intel Corporation and its suppliers.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of
[PATCH] mtd: nand: denali: use SPDX-License-Identifier and fix license mismatch
Use SPDX-License-Identifier instead of the license boilerplates.
This conversion makes it easier for us to scan the license, then
I notice license mismatch problems.
The license blocks in denali* indicate GPL-2.0 "only", while the
MODULE_LICENSE in denali.c and denali_dt.c is GPL-2.0 "or later"
as explained in include/linux/module.h as follows:
"GPL" [GNU Public License v2 or later]
"GPL v2"[GNU Public License v2]
I fixed the MODULE_LICENSE tags, assuming the license blocks are
the authors' intention.
Also, add missing MODULE_DESCRIPTION/AUTHOR to denali.c
While I am touching the license things, I added my credit to denali.c
because this driver was largely re-written by me in 2017.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/raw/denali.c | 17 +++--
drivers/mtd/nand/raw/denali.h | 10 +-
drivers/mtd/nand/raw/denali_dt.c | 12 ++--
drivers/mtd/nand/raw/denali_pci.c | 10 +-
4 files changed, 11 insertions(+), 38 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index ca18612..9f432f0 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -1,15 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* NAND Flash Controller Device Driver
* Copyright © 2009-2010, Intel Corporation and its suppliers.
*
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.
+ * Copyright (c) 2017 Socionext Inc.
+ * Reworked by Masahiro Yamada
*/
#include
@@ -25,8 +20,6 @@
#include "denali.h"
-MODULE_LICENSE("GPL");
-
#define DENALI_NAND_NAME"denali-nand"
/* for Indexed Addressing */
@@ -1396,3 +1389,7 @@ void denali_remove(struct denali_nand_info *denali)
denali_disable_irq(denali);
}
EXPORT_SYMBOL(denali_remove);
+
+MODULE_DESCRIPTION("Driver core for Denali NAND controller");
+MODULE_AUTHOR("Intel Corporation and its suppliers");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/mtd/nand/raw/denali.h b/drivers/mtd/nand/raw/denali.h
index 1f8feaf..57a5498 100644
--- a/drivers/mtd/nand/raw/denali.h
+++ b/drivers/mtd/nand/raw/denali.h
@@ -1,15 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* NAND Flash Controller Device Driver
* Copyright (c) 2009 - 2010, Intel Corporation and its suppliers.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.
*/
#ifndef __DENALI_H__
diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c
index 0faaad0..7c6a8a4 100644
--- a/drivers/mtd/nand/raw/denali_dt.c
+++ b/drivers/mtd/nand/raw/denali_dt.c
@@ -1,16 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* NAND Flash Controller Device Driver for DT
*
* Copyright © 2011, Picochip.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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
@@ -202,6 +194,6 @@ static struct platform_driver denali_dt_driver = {
};
module_platform_driver(denali_dt_driver);
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Jamie Iles");
MODULE_DESCRIPTION("DT driver for Denali NAND controller");
diff --git a/drivers/mtd/nand/raw/denali_pci.c
b/drivers/mtd/nand/raw/denali_pci.c
index 7c8efc4..48e9ac5 100644
--- a/drivers/mtd/nand/raw/denali_pci.c
+++ b/drivers/mtd/nand/raw/denali_pci.c
@@ -1,15 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* NAND Flash Controller Device Driver
* Copyright © 2009-2010, Intel Corporation and its suppliers.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of
Re: [PATCH] x86/process: Export start_thread()
> On Aug 19, 2018, at 4:08 PM, Rian Hunter wrote:
>
> Commit e634d8fc792c ("x86-64: merge the standard and compat
> start_thread() functions") removed exporting for the start_thread()
> function in what seems like a typo. Add it back to
> arch/x86/kernel/process_64.c for parity with process_32.c and other
> arch.
What for? Perhaps 32-bit could remove it instead?
>
> Signed-off-by: Rian Hunter
> ---
> arch/x86/kernel/process_64.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index 476e3ddf8890..a451bc374b9b 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -384,6 +384,7 @@ start_thread(struct pt_regs *regs, unsigned long new_ip,
> unsigned long new_sp)
>start_thread_common(regs, new_ip, new_sp,
>__USER_CS, __USER_DS, 0);
> }
> +EXPORT_SYMBOL_GPL(start_thread);
>
> #ifdef CONFIG_COMPAT
> void compat_start_thread(struct pt_regs *regs, u32 new_ip, u32 new_sp)
> --
> 2.16.3
>
Re: [PATCH] x86/process: Export start_thread()
> On Aug 19, 2018, at 4:08 PM, Rian Hunter wrote:
>
> Commit e634d8fc792c ("x86-64: merge the standard and compat
> start_thread() functions") removed exporting for the start_thread()
> function in what seems like a typo. Add it back to
> arch/x86/kernel/process_64.c for parity with process_32.c and other
> arch.
What for? Perhaps 32-bit could remove it instead?
>
> Signed-off-by: Rian Hunter
> ---
> arch/x86/kernel/process_64.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index 476e3ddf8890..a451bc374b9b 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -384,6 +384,7 @@ start_thread(struct pt_regs *regs, unsigned long new_ip,
> unsigned long new_sp)
>start_thread_common(regs, new_ip, new_sp,
>__USER_CS, __USER_DS, 0);
> }
> +EXPORT_SYMBOL_GPL(start_thread);
>
> #ifdef CONFIG_COMPAT
> void compat_start_thread(struct pt_regs *regs, u32 new_ip, u32 new_sp)
> --
> 2.16.3
>
Re: linux-next: build warnings from Linus' tree
On Mon, Aug 20, 2018 at 03:33:19AM +0200, Adam Borowski wrote: > Valid uses of strncpy() do exist (such as SCSI structs), but those deal with > fixed-width fields. Thus, gcc is right for warning for at least some of > misuse of strncpy() for C strings. The function wasn't designed for them. The problem is that the kernel has a goodly share of fixed-width fields. The ext4 superblock is one of them. strncpy() is the most convenient function to do what is needed. If it's a valid use, then we need to have a way to get gcc to shut up about them. - Ted
Re: linux-next: build warnings from Linus' tree
On Mon, Aug 20, 2018 at 03:33:19AM +0200, Adam Borowski wrote: > Valid uses of strncpy() do exist (such as SCSI structs), but those deal with > fixed-width fields. Thus, gcc is right for warning for at least some of > misuse of strncpy() for C strings. The function wasn't designed for them. The problem is that the kernel has a goodly share of fixed-width fields. The ext4 superblock is one of them. strncpy() is the most convenient function to do what is needed. If it's a valid use, then we need to have a way to get gcc to shut up about them. - Ted
RE: [PATCHv4 00/12] sched/fair: Migrate 'misfit' tasks on asymmetric capacity systems
Hi, > -Original Message- > From: Morten Rasmussen > Sent: Wednesday, July 4, 2018 7:18 PM > To: pet...@infradead.org; mi...@redhat.com > Cc: valentin.schnei...@arm.com; dietmar.eggem...@arm.com; > vincent.guit...@linaro.org; Gaku Inami > ; linux-kernel@vger.kernel.org; Morten Rasmussen > > Subject: [PATCHv4 00/12] sched/fair: Migrate 'misfit' tasks on asymmetric > capacity systems [snip] > The patches have been tested on: >1. Arm Juno (r0): 2+4 Cortex A57/A53 >2. Hikey960: 4+4 Cortex A73/A53 > > Test case: > Big cpus are always kept busy. Pin a shorter running sysbench tasks to > big cpus, while creating a longer running set of unpinned sysbench > tasks. I have tested v4 patches on Renesas SoC again. It looks fine. You can add: Tested-by: Gaku Inami The patches have been tested on: 3. Renesas R-Car H3 : 4+4 Cortex A57/A53 Results: Single runs with completion time of each task R-Car H3 (tip) total time: 0.9488s total time: 0.9766s total time: 1.3243s total time: 1.6740s R-Car H3 (misfit) total time: 0.9313s total time: 0.9214s total time: 0.9493s total time: 0.9606s 10 run summary (tracking longest running task for each run) R-Car H3 avg max tip 1.6744 1.6780 misfit 0.9616 1.0290 Also, I confirmed that these patches bring performance improvement to some benchmarks(UnixBench, LMbench). So they have very useful for Renesas SoC. [snip] Regards, Inami
RE: [PATCHv4 00/12] sched/fair: Migrate 'misfit' tasks on asymmetric capacity systems
Hi, > -Original Message- > From: Morten Rasmussen > Sent: Wednesday, July 4, 2018 7:18 PM > To: pet...@infradead.org; mi...@redhat.com > Cc: valentin.schnei...@arm.com; dietmar.eggem...@arm.com; > vincent.guit...@linaro.org; Gaku Inami > ; linux-kernel@vger.kernel.org; Morten Rasmussen > > Subject: [PATCHv4 00/12] sched/fair: Migrate 'misfit' tasks on asymmetric > capacity systems [snip] > The patches have been tested on: >1. Arm Juno (r0): 2+4 Cortex A57/A53 >2. Hikey960: 4+4 Cortex A73/A53 > > Test case: > Big cpus are always kept busy. Pin a shorter running sysbench tasks to > big cpus, while creating a longer running set of unpinned sysbench > tasks. I have tested v4 patches on Renesas SoC again. It looks fine. You can add: Tested-by: Gaku Inami The patches have been tested on: 3. Renesas R-Car H3 : 4+4 Cortex A57/A53 Results: Single runs with completion time of each task R-Car H3 (tip) total time: 0.9488s total time: 0.9766s total time: 1.3243s total time: 1.6740s R-Car H3 (misfit) total time: 0.9313s total time: 0.9214s total time: 0.9493s total time: 0.9606s 10 run summary (tracking longest running task for each run) R-Car H3 avg max tip 1.6744 1.6780 misfit 0.9616 1.0290 Also, I confirmed that these patches bring performance improvement to some benchmarks(UnixBench, LMbench). So they have very useful for Renesas SoC. [snip] Regards, Inami
IF U ARE TOCH ON MY MESSAGE PLS REPLY ME,,
Friend, My name is Miss Qadesa AbdulAziz and I am 17 years old girl from Syria. There is serious war crisis here in Syria, and I have lost my parents and my two brothers in this war. I want you to help me and receive ($7.md) which my late father deposited with my name in a bank in London. I want to come to your country and start a new life and invest with you, because am the only survival in my family. I wait to hear from you, Please do not let me die here, I begging you the name of Almighty. please respond here my pirate email qad...@protonmail.com Regards Miss Qadesa AbdulAziz
IF U ARE TOCH ON MY MESSAGE PLS REPLY ME,,
Friend, My name is Miss Qadesa AbdulAziz and I am 17 years old girl from Syria. There is serious war crisis here in Syria, and I have lost my parents and my two brothers in this war. I want you to help me and receive ($7.md) which my late father deposited with my name in a bank in London. I want to come to your country and start a new life and invest with you, because am the only survival in my family. I wait to hear from you, Please do not let me die here, I begging you the name of Almighty. please respond here my pirate email qad...@protonmail.com Regards Miss Qadesa AbdulAziz
[PATCH 1/2] nds32: Remove the deprecated ABI implementation
We are not using NDS32 ABI 2 for now, just remove the preprocessor
directives __NDS32_ABI_2.
Signed-off-by: Zong Li
---
arch/nds32/kernel/traps.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index 7684c8f..f432310 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -117,13 +117,8 @@ static void __dump(struct task_struct *tsk, unsigned long
*base_reg)
!((unsigned long)base_reg & 0x3) &&
((unsigned long)base_reg >= TASK_SIZE)) {
unsigned long next_fp;
-#if !defined(__NDS32_ABI_2)
- ret_addr = base_reg[0];
- next_fp = base_reg[1];
-#else
ret_addr = base_reg[-1];
next_fp = base_reg[FP_OFFSET];
-#endif
if (__kernel_text_address(ret_addr)) {
ret_addr = ftrace_graph_ret_addr(
--
2.7.4
[PATCH 1/2] nds32: Remove the deprecated ABI implementation
We are not using NDS32 ABI 2 for now, just remove the preprocessor
directives __NDS32_ABI_2.
Signed-off-by: Zong Li
---
arch/nds32/kernel/traps.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index 7684c8f..f432310 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -117,13 +117,8 @@ static void __dump(struct task_struct *tsk, unsigned long
*base_reg)
!((unsigned long)base_reg & 0x3) &&
((unsigned long)base_reg >= TASK_SIZE)) {
unsigned long next_fp;
-#if !defined(__NDS32_ABI_2)
- ret_addr = base_reg[0];
- next_fp = base_reg[1];
-#else
ret_addr = base_reg[-1];
next_fp = base_reg[FP_OFFSET];
-#endif
if (__kernel_text_address(ret_addr)) {
ret_addr = ftrace_graph_ret_addr(
--
2.7.4
[PATCH 2/2] nds32: Add macro definition for offset of lp register on stack
Use macro to replace the magic number.
Signed-off-by: Zong Li
---
arch/nds32/include/asm/nds32.h | 1 +
arch/nds32/kernel/stacktrace.c | 2 +-
arch/nds32/kernel/traps.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/nds32/include/asm/nds32.h b/arch/nds32/include/asm/nds32.h
index 19b1939..68c3815 100644
--- a/arch/nds32/include/asm/nds32.h
+++ b/arch/nds32/include/asm/nds32.h
@@ -17,6 +17,7 @@
#else
#define FP_OFFSET (-2)
#endif
+#define LP_OFFSET (-1)
extern void __init early_trap_init(void);
static inline void GIE_ENABLE(void)
diff --git a/arch/nds32/kernel/stacktrace.c b/arch/nds32/kernel/stacktrace.c
index 36bc870..d974c0c 100644
--- a/arch/nds32/kernel/stacktrace.c
+++ b/arch/nds32/kernel/stacktrace.c
@@ -31,7 +31,7 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct
stack_trace *trace)
&& (fpn >= (unsigned long *)TASK_SIZE)) {
unsigned long lpp, fpp;
- lpp = fpn[-1];
+ lpp = fpn[LP_OFFSET];
fpp = fpn[FP_OFFSET];
if (!__kernel_text_address(lpp))
break;
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index f432310..b0b85b7 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -117,7 +117,7 @@ static void __dump(struct task_struct *tsk, unsigned long
*base_reg)
!((unsigned long)base_reg & 0x3) &&
((unsigned long)base_reg >= TASK_SIZE)) {
unsigned long next_fp;
- ret_addr = base_reg[-1];
+ ret_addr = base_reg[LP_OFFSET];
next_fp = base_reg[FP_OFFSET];
if (__kernel_text_address(ret_addr)) {
--
2.7.4
[PATCH 0/2] Remove the deprecated ABI implementation
This patches remove the implementation of NDS32_ABI_2 and replace the magic number of offset of lp on stack. In stacktrace.c, we dump the stack without considering the old ABI, it should be consistent in traps.c. Zong Li (2): nds32: Remove the deprecated ABI implementation nds32: Add macro definition for offset of lp register on stack arch/nds32/include/asm/nds32.h | 1 + arch/nds32/kernel/stacktrace.c | 2 +- arch/nds32/kernel/traps.c | 7 +-- 3 files changed, 3 insertions(+), 7 deletions(-) -- 2.7.4
[PATCH 2/2] nds32: Add macro definition for offset of lp register on stack
Use macro to replace the magic number.
Signed-off-by: Zong Li
---
arch/nds32/include/asm/nds32.h | 1 +
arch/nds32/kernel/stacktrace.c | 2 +-
arch/nds32/kernel/traps.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/nds32/include/asm/nds32.h b/arch/nds32/include/asm/nds32.h
index 19b1939..68c3815 100644
--- a/arch/nds32/include/asm/nds32.h
+++ b/arch/nds32/include/asm/nds32.h
@@ -17,6 +17,7 @@
#else
#define FP_OFFSET (-2)
#endif
+#define LP_OFFSET (-1)
extern void __init early_trap_init(void);
static inline void GIE_ENABLE(void)
diff --git a/arch/nds32/kernel/stacktrace.c b/arch/nds32/kernel/stacktrace.c
index 36bc870..d974c0c 100644
--- a/arch/nds32/kernel/stacktrace.c
+++ b/arch/nds32/kernel/stacktrace.c
@@ -31,7 +31,7 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct
stack_trace *trace)
&& (fpn >= (unsigned long *)TASK_SIZE)) {
unsigned long lpp, fpp;
- lpp = fpn[-1];
+ lpp = fpn[LP_OFFSET];
fpp = fpn[FP_OFFSET];
if (!__kernel_text_address(lpp))
break;
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index f432310..b0b85b7 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -117,7 +117,7 @@ static void __dump(struct task_struct *tsk, unsigned long
*base_reg)
!((unsigned long)base_reg & 0x3) &&
((unsigned long)base_reg >= TASK_SIZE)) {
unsigned long next_fp;
- ret_addr = base_reg[-1];
+ ret_addr = base_reg[LP_OFFSET];
next_fp = base_reg[FP_OFFSET];
if (__kernel_text_address(ret_addr)) {
--
2.7.4
[PATCH 0/2] Remove the deprecated ABI implementation
This patches remove the implementation of NDS32_ABI_2 and replace the magic number of offset of lp on stack. In stacktrace.c, we dump the stack without considering the old ABI, it should be consistent in traps.c. Zong Li (2): nds32: Remove the deprecated ABI implementation nds32: Add macro definition for offset of lp register on stack arch/nds32/include/asm/nds32.h | 1 + arch/nds32/kernel/stacktrace.c | 2 +- arch/nds32/kernel/traps.c | 7 +-- 3 files changed, 3 insertions(+), 7 deletions(-) -- 2.7.4
Re: [PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning
On Sun, 2018-08-19 at 09:46 -0700, Linus Torvalds wrote:
> On Sun, Aug 19, 2018 at 6:51 AM Sedat Dilek wrote:
> >
> > This can be dropped with commit 771c035372a036f83353eef46dbb829780330234
> > ("deprecate the '__deprecated' attribute warnings entirely and for good")
> > now in upstream.
>
> Could we please just remove the __deprecated use in i2c entirely?
>
> As fat as I can tell, it's used for one thing, which is the
> "attach_adapter" function pointer member in 'struct i2c_driver'.
>
> And I think there is _one_ remaining driver using it, namely the
> powermac "therm_windtunnel" driver.
>
> Could somebody who knows the i2c probing just a bit convert that *one*
> remaining driver, then remove the "attach_adapter" entirely, and also
> remove this thing?
>
> Alternatively, perhaps the driver should be removed? The last actual
> powermac change to that driver seems to be from August 2009.
> Everything since has been just cleanup unrelated to that driver code
> itself (ie spelling fixes, automated coccinelle scripts etc).
>
> Added a few people either because they're still officially maintainers
> of that file, or because they touched the code ten years ago.
Some people still use those old machines, I'll give a try at fixing the
driver.
Paul: Do you still have one of these machines ?
Cheers
Ben.
Re: [PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning
On Sun, 2018-08-19 at 09:46 -0700, Linus Torvalds wrote:
> On Sun, Aug 19, 2018 at 6:51 AM Sedat Dilek wrote:
> >
> > This can be dropped with commit 771c035372a036f83353eef46dbb829780330234
> > ("deprecate the '__deprecated' attribute warnings entirely and for good")
> > now in upstream.
>
> Could we please just remove the __deprecated use in i2c entirely?
>
> As fat as I can tell, it's used for one thing, which is the
> "attach_adapter" function pointer member in 'struct i2c_driver'.
>
> And I think there is _one_ remaining driver using it, namely the
> powermac "therm_windtunnel" driver.
>
> Could somebody who knows the i2c probing just a bit convert that *one*
> remaining driver, then remove the "attach_adapter" entirely, and also
> remove this thing?
>
> Alternatively, perhaps the driver should be removed? The last actual
> powermac change to that driver seems to be from August 2009.
> Everything since has been just cleanup unrelated to that driver code
> itself (ie spelling fixes, automated coccinelle scripts etc).
>
> Added a few people either because they're still officially maintainers
> of that file, or because they touched the code ten years ago.
Some people still use those old machines, I'll give a try at fixing the
driver.
Paul: Do you still have one of these machines ?
Cheers
Ben.
Re: [RFC PATCH 1/6] Revert "PCI: Fix is_added/is_busmaster race condition"
On Sat, 2018-08-18 at 21:24 -0500, Bjorn Helgaas wrote: > On Sat, Aug 18, 2018 at 01:24:51PM +1000, Benjamin Herrenschmidt wrote: > > On Fri, 2018-08-17 at 10:44 -0500, Bjorn Helgaas wrote: > > > On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote: > > > > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76. > > > > > > Just to be clear, if I understand correctly, this is a pure revert of > > > 44bda4b7d26e and as such it reintroduces the problem solved by that > > > commit. > > > > > > If your solution turns out to be better, that's great, but it would be > > > nice to avoid the bisection hole of reintroducing the problem, then > > > fixing it again later. > > > > There is no way to do that other than merging the revert and the fix > > into one. That said, the race is sufficiently hard to hit that I > > wouldn't worry too much about it. > > OK, then at least mention that in the changelog. Sure will do. This is just RFC at this stage :-) As for the race with enable, what's your take on my approach ? The basic premise is that we need some kind of mutex to make the updates to enable_cnt and the actual config space changes atomic. While at it we can fold pci_set_master vs. is_busmaster as well as those are racy too. I chose to create a new mutex which we should be able to address other similar races if we find them. The other solutions that I dismissed were: - Using the device_lock. A explained previously, this is tricky, I prefer not using this for anything other than locking against concurrent add/remove. The main issue is that drivers will be sometimes called in context where that's already held, so we can't take it inside pci_enable_device() and I'd rather not add new constraints such as "pci_enable_device() must be only called from probe() unless you also take the device lock". It would be tricky to audit everybody... - Using a global mutex. We could move the bridge lock from AER to core code for example, and use that. But it doesn't buy us much, and slightly redecuces parallelism. It also makes it a little bit more messy to walk up the bridge chain, we'd have to do a pci_enable_device_unlocked or something, messy. So are you ok with the approach ? Do you prefer one of the above regardless ? Something else ? Cheers, Ben.
Re: [RFC PATCH 1/6] Revert "PCI: Fix is_added/is_busmaster race condition"
On Sat, 2018-08-18 at 21:24 -0500, Bjorn Helgaas wrote: > On Sat, Aug 18, 2018 at 01:24:51PM +1000, Benjamin Herrenschmidt wrote: > > On Fri, 2018-08-17 at 10:44 -0500, Bjorn Helgaas wrote: > > > On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote: > > > > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76. > > > > > > Just to be clear, if I understand correctly, this is a pure revert of > > > 44bda4b7d26e and as such it reintroduces the problem solved by that > > > commit. > > > > > > If your solution turns out to be better, that's great, but it would be > > > nice to avoid the bisection hole of reintroducing the problem, then > > > fixing it again later. > > > > There is no way to do that other than merging the revert and the fix > > into one. That said, the race is sufficiently hard to hit that I > > wouldn't worry too much about it. > > OK, then at least mention that in the changelog. Sure will do. This is just RFC at this stage :-) As for the race with enable, what's your take on my approach ? The basic premise is that we need some kind of mutex to make the updates to enable_cnt and the actual config space changes atomic. While at it we can fold pci_set_master vs. is_busmaster as well as those are racy too. I chose to create a new mutex which we should be able to address other similar races if we find them. The other solutions that I dismissed were: - Using the device_lock. A explained previously, this is tricky, I prefer not using this for anything other than locking against concurrent add/remove. The main issue is that drivers will be sometimes called in context where that's already held, so we can't take it inside pci_enable_device() and I'd rather not add new constraints such as "pci_enable_device() must be only called from probe() unless you also take the device lock". It would be tricky to audit everybody... - Using a global mutex. We could move the bridge lock from AER to core code for example, and use that. But it doesn't buy us much, and slightly redecuces parallelism. It also makes it a little bit more messy to walk up the bridge chain, we'd have to do a pci_enable_device_unlocked or something, messy. So are you ok with the approach ? Do you prefer one of the above regardless ? Something else ? Cheers, Ben.
tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
Hi Alexei, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2ad0d52699700a91660a406a4046017a2d7f246a commit: 819dd92b9c0bc7bce9097d8c1f14240f471bb386 bpfilter: switch to CC from HOSTCC date: 3 months ago config: alpha-allyesconfig (attached as .config) compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 819dd92b9c0bc7bce9097d8c1f14240f471bb386 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=alpha All errors (new ones prefixed by >>): In file included from tools/include/uapi/asm/bitsperlong.h:17:0, from /usr/alpha-linux-gnu/include/asm-generic/int-l64.h:11, from /usr/alpha-linux-gnu/include/asm/types.h:12, from tools/include/linux/types.h:10, from ./include/uapi/linux/bpf.h:11, from net//bpfilter/main.c:9: >> tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent >> word size. Check asm/bitsperlong.h #error Inconsistent word size. Check asm/bitsperlong.h ^ vim +14 tools/include/asm-generic/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 12 2a00f026 Arnaldo Carvalho de Melo 2016-07-13 13 #if BITS_PER_LONG != __BITS_PER_LONG bb970707 Arnaldo Carvalho de Melo 2016-07-12 @14 #error Inconsistent word size. Check asm/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 15 #endif bb970707 Arnaldo Carvalho de Melo 2016-07-12 16 :: The code at line 14 was first introduced by commit :: bb9707077b4ee5f77bc9939b057ff8a0d410296f tools: Copy the bitsperlong.h files from the kernel :: TO: Arnaldo Carvalho de Melo :: CC: Arnaldo Carvalho de Melo --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
Hi Alexei, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2ad0d52699700a91660a406a4046017a2d7f246a commit: 819dd92b9c0bc7bce9097d8c1f14240f471bb386 bpfilter: switch to CC from HOSTCC date: 3 months ago config: alpha-allyesconfig (attached as .config) compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 819dd92b9c0bc7bce9097d8c1f14240f471bb386 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=alpha All errors (new ones prefixed by >>): In file included from tools/include/uapi/asm/bitsperlong.h:17:0, from /usr/alpha-linux-gnu/include/asm-generic/int-l64.h:11, from /usr/alpha-linux-gnu/include/asm/types.h:12, from tools/include/linux/types.h:10, from ./include/uapi/linux/bpf.h:11, from net//bpfilter/main.c:9: >> tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent >> word size. Check asm/bitsperlong.h #error Inconsistent word size. Check asm/bitsperlong.h ^ vim +14 tools/include/asm-generic/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 12 2a00f026 Arnaldo Carvalho de Melo 2016-07-13 13 #if BITS_PER_LONG != __BITS_PER_LONG bb970707 Arnaldo Carvalho de Melo 2016-07-12 @14 #error Inconsistent word size. Check asm/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 15 #endif bb970707 Arnaldo Carvalho de Melo 2016-07-12 16 :: The code at line 14 was first introduced by commit :: bb9707077b4ee5f77bc9939b057ff8a0d410296f tools: Copy the bitsperlong.h files from the kernel :: TO: Arnaldo Carvalho de Melo :: CC: Arnaldo Carvalho de Melo --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: linux-next: build warnings from Linus' tree
On Sun, Aug 19, 2018 at 04:21:57PM -0700, Linus Torvalds wrote:
> On Sun, Aug 19, 2018 at 3:13 PM Stephen Rothwell
> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) produced these
> > warnings:
> >
> > fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region
> > of size 1 overflows the destination [-Wstringop-overflow=]
> >strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
> >
> > Presumably caused by my update to gcc 8.2.0.
>
> Yeah. There are some patches to mark some arrays as non-strings to get
> rid of these, but we'll see. Maybe we'll just disable the new gcc
> warning if it causes more pain than it is worth.
Every single use of strncpy() for a C string is either a bug, inefficiency,
or both. In this particular case the code:
count = 0;
for (i = 0; i < CIFS_NUM_PROT; i++) {
strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
count += strlen(protocols[i].name) + 1;
/* null at end of source and target buffers anyway */
}
* pointlessly clears 16 bytes in every iteration
* calculates the string's length twice
* there's no protection against buffer overflow anyway
So what is the strncpy() there for, when an unbounded copy would be just as
good? For other cases, there's a bunch of better functions: strlcpy(),
snprintf(), even strlen()+memcpy(), etc.
Valid uses of strncpy() do exist (such as SCSI structs), but those deal with
fixed-width fields. Thus, gcc is right for warning for at least some of
misuse of strncpy() for C strings. The function wasn't designed for them.
(Skipped analysis why strncpy is always a bad choice for C strings.)
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
Re: linux-next: build warnings from Linus' tree
On Sun, Aug 19, 2018 at 04:21:57PM -0700, Linus Torvalds wrote:
> On Sun, Aug 19, 2018 at 3:13 PM Stephen Rothwell
> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) produced these
> > warnings:
> >
> > fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region
> > of size 1 overflows the destination [-Wstringop-overflow=]
> >strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
> >
> > Presumably caused by my update to gcc 8.2.0.
>
> Yeah. There are some patches to mark some arrays as non-strings to get
> rid of these, but we'll see. Maybe we'll just disable the new gcc
> warning if it causes more pain than it is worth.
Every single use of strncpy() for a C string is either a bug, inefficiency,
or both. In this particular case the code:
count = 0;
for (i = 0; i < CIFS_NUM_PROT; i++) {
strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
count += strlen(protocols[i].name) + 1;
/* null at end of source and target buffers anyway */
}
* pointlessly clears 16 bytes in every iteration
* calculates the string's length twice
* there's no protection against buffer overflow anyway
So what is the strncpy() there for, when an unbounded copy would be just as
good? For other cases, there's a bunch of better functions: strlcpy(),
snprintf(), even strlen()+memcpy(), etc.
Valid uses of strncpy() do exist (such as SCSI structs), but those deal with
fixed-width fields. Thus, gcc is right for warning for at least some of
misuse of strncpy() for C strings. The function wasn't designed for them.
(Skipped analysis why strncpy is always a bad choice for C strings.)
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
Re: [RFC PATCH] pci: Proof of concept at fixing pci_enable_device/bridge races
On Thu, Aug 16, 2018 at 09:38:41AM +1000, Benjamin Herrenschmidt wrote: > On Wed, 2018-08-15 at 15:40 -0700, Guenter Roeck wrote: > > On Thu, Aug 16, 2018 at 07:50:13AM +1000, Benjamin Herrenschmidt wrote: > > > (Resent with lkml on copy) > > > > > > [Note: This isn't meant to be merged, it need splitting at the very > > > least, see below] > > > > > > This is something I cooked up quickly today to test if that would fix > > > my problems with large number of switch and NVME devices on POWER. > > > > > > > Is that a problem that can be reproduced with a qemu setup ? > > With difficulty... mt-tcg might help, but you need a rather large > systems to reproduce it. > > My repro-case is a 2 socket POWER9 system (about 40 cores off the top > of my mind, so 160 threads) with 72 NVME devices underneath a tree of > switches (I don't have the system at hand today to check how many). > > It's possible to observe it I suppose on a smaller system (in theory a > single bridge with 2 devices is enough) but in practice the timing is > extremely hard to hit. > > You need a combination of: > > - The bridges come up disabled (which is the case when Linux does the > resource assignment, such as on POWER but not on x86 unless it's > hotplug) > > - The nvme devices try to enable them simultaneously > > Also the resulting error is a UR, I don't know how well qemu models > that. > Not well enough, apparently. I tried for a while, registering as many nvme drives as the system would take, but I was not able to reproduce the problem with qemu. It was worth a try, though. Guenter
Re: [RFC PATCH] pci: Proof of concept at fixing pci_enable_device/bridge races
On Thu, Aug 16, 2018 at 09:38:41AM +1000, Benjamin Herrenschmidt wrote: > On Wed, 2018-08-15 at 15:40 -0700, Guenter Roeck wrote: > > On Thu, Aug 16, 2018 at 07:50:13AM +1000, Benjamin Herrenschmidt wrote: > > > (Resent with lkml on copy) > > > > > > [Note: This isn't meant to be merged, it need splitting at the very > > > least, see below] > > > > > > This is something I cooked up quickly today to test if that would fix > > > my problems with large number of switch and NVME devices on POWER. > > > > > > > Is that a problem that can be reproduced with a qemu setup ? > > With difficulty... mt-tcg might help, but you need a rather large > systems to reproduce it. > > My repro-case is a 2 socket POWER9 system (about 40 cores off the top > of my mind, so 160 threads) with 72 NVME devices underneath a tree of > switches (I don't have the system at hand today to check how many). > > It's possible to observe it I suppose on a smaller system (in theory a > single bridge with 2 devices is enough) but in practice the timing is > extremely hard to hit. > > You need a combination of: > > - The bridges come up disabled (which is the case when Linux does the > resource assignment, such as on POWER but not on x86 unless it's > hotplug) > > - The nvme devices try to enable them simultaneously > > Also the resulting error is a UR, I don't know how well qemu models > that. > Not well enough, apparently. I tried for a while, registering as many nvme drives as the system would take, but I was not able to reproduce the problem with qemu. It was worth a try, though. Guenter
Re: [PATCH v2] ASoC: wm9712: fix replace codec to component
Hi
# I know it is very late response
Acked-by: Kuninori Morimoto
> From: Marcel Ziswiler
>
> Since commit 143b44845d87 ("ASoC: wm9712: replace codec to component")
> "wm9712-codec" got renamed to "wm9712-component", however, this change
> never got propagated down to the actual board/platform drivers. E.g. on
> Colibri T20 this lead to the following spew upon boot with sound/touch
> being broken:
>
> [2.214121] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [2.222137] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [2.344384] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [2.351885] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [2.668339] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [2.675811] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [3.208408] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [3.216312] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [3.235397] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [3.248938] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [ 14.970443] ALSA device list:
> [ 14.996628] No soundcards found.
>
> This commit finally fixes this again.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
Best regards
---
Kuninori Morimoto
Re: [PATCH v2] ASoC: wm9712: fix replace codec to component
Hi
# I know it is very late response
Acked-by: Kuninori Morimoto
> From: Marcel Ziswiler
>
> Since commit 143b44845d87 ("ASoC: wm9712: replace codec to component")
> "wm9712-codec" got renamed to "wm9712-component", however, this change
> never got propagated down to the actual board/platform drivers. E.g. on
> Colibri T20 this lead to the following spew upon boot with sound/touch
> being broken:
>
> [2.214121] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [2.222137] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [2.344384] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [2.351885] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [2.668339] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [2.675811] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [3.208408] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [3.216312] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [3.235397] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [3.248938] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [ 14.970443] ALSA device list:
> [ 14.996628] No soundcards found.
>
> This commit finally fixes this again.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
Best regards
---
Kuninori Morimoto
Re: [PATCH v8 2/2] PCI: pciehp: Mask AER surprise link down error if hotplug is enabled
Hi Sinan,
I love your patch! Yet something to improve:
[auto build test ERROR on pci/next]
[also build test ERROR on next-20180817]
[cannot apply to v4.18]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sinan-Kaya/PCI-pciehp-Ignore-link-events-when-there-is-a-fatal-error-pending/20180820-074636
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: i386-randconfig-x075-201833 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/pci/hotplug/pciehp_core.c: In function
'pciehp_control_surprise_error':
>> drivers/pci/hotplug/pciehp_core.c:241:14: error: 'struct pci_dev' has no
>> member named 'aer_cap'; did you mean 'ats_cap'?
pos = pdev->aer_cap;
^~~
ats_cap
vim +241 drivers/pci/hotplug/pciehp_core.c
231
232 static int pciehp_control_surprise_error(struct controller *ctrl, bool
enable)
233 {
234 struct pci_dev *pdev = ctrl->pcie->port;
235 u32 reg32;
236 int pos;
237
238 if (!pci_is_pcie(pdev))
239 return -ENODEV;
240
> 241 pos = pdev->aer_cap;
242 if (!pos)
243 return -ENODEV;
244
245 pci_read_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, );
246 if (enable)
247 reg32 &= ~PCI_ERR_UNC_SURPDN;
248 else
249 reg32 |= PCI_ERR_UNC_SURPDN;
250 pci_write_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, reg32);
251
252 return 0;
253 }
254
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v8 2/2] PCI: pciehp: Mask AER surprise link down error if hotplug is enabled
Hi Sinan,
I love your patch! Yet something to improve:
[auto build test ERROR on pci/next]
[also build test ERROR on next-20180817]
[cannot apply to v4.18]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sinan-Kaya/PCI-pciehp-Ignore-link-events-when-there-is-a-fatal-error-pending/20180820-074636
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: i386-randconfig-x075-201833 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/pci/hotplug/pciehp_core.c: In function
'pciehp_control_surprise_error':
>> drivers/pci/hotplug/pciehp_core.c:241:14: error: 'struct pci_dev' has no
>> member named 'aer_cap'; did you mean 'ats_cap'?
pos = pdev->aer_cap;
^~~
ats_cap
vim +241 drivers/pci/hotplug/pciehp_core.c
231
232 static int pciehp_control_surprise_error(struct controller *ctrl, bool
enable)
233 {
234 struct pci_dev *pdev = ctrl->pcie->port;
235 u32 reg32;
236 int pos;
237
238 if (!pci_is_pcie(pdev))
239 return -ENODEV;
240
> 241 pos = pdev->aer_cap;
242 if (!pos)
243 return -ENODEV;
244
245 pci_read_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, );
246 if (enable)
247 reg32 &= ~PCI_ERR_UNC_SURPDN;
248 else
249 reg32 |= PCI_ERR_UNC_SURPDN;
250 pci_write_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, reg32);
251
252 return 0;
253 }
254
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH V2] arm64: dts: sdm630 SoC and Sony Pioneer (Xperia XA2) support
Hi Craig, Thank you for the patch! Yet something to improve: [auto build test ERROR on agross/for-next] [also build test ERROR on v4.18 next-20180817] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Craig-Tatlor/arm64-dts-sdm630-SoC-and-Sony-Pioneer-Xperia-XA2-support/20180813-040803 base: https://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git for-next config: arm64-allnoconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=arm64 All errors (new ones prefixed by >>): In file included from arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi:4:0, from arch/arm64/boot/dts/qcom/sdm630-pioneer.dts:6: >> arch/arm64/boot/dts/qcom/sdm630.dtsi:5:10: fatal error: >> dt-bindings/clock/qcom,gcc-sdm660.h: No such file or directory #include ^ compilation terminated. vim +5 arch/arm64/boot/dts/qcom/sdm630.dtsi 3 4 #include > 5 #include 6 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH V2] arm64: dts: sdm630 SoC and Sony Pioneer (Xperia XA2) support
Hi Craig, Thank you for the patch! Yet something to improve: [auto build test ERROR on agross/for-next] [also build test ERROR on v4.18 next-20180817] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Craig-Tatlor/arm64-dts-sdm630-SoC-and-Sony-Pioneer-Xperia-XA2-support/20180813-040803 base: https://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git for-next config: arm64-allnoconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=arm64 All errors (new ones prefixed by >>): In file included from arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi:4:0, from arch/arm64/boot/dts/qcom/sdm630-pioneer.dts:6: >> arch/arm64/boot/dts/qcom/sdm630.dtsi:5:10: fatal error: >> dt-bindings/clock/qcom,gcc-sdm660.h: No such file or directory #include ^ compilation terminated. vim +5 arch/arm64/boot/dts/qcom/sdm630.dtsi 3 4 #include > 5 #include 6 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: linux-next: build warnings from Linus' tree
On Mon, Aug 20, 2018 at 08:13:23AM +1000, Stephen Rothwell wrote:
> fs/ext4/super.c: In function '__save_error_info':
> fs/ext4/super.c:344:2: warning: 'strncpy' specified bound 32 equals
> destination size [-Wstringop-truncation]
> strncpy(es->s_last_error_func, func, sizeof(es->s_last_error_func));
> ^~~
> fs/ext4/super.c:349:3: warning: 'strncpy' specified bound 32 equals
> destination size [-Wstringop-truncation]
>strncpy(es->s_first_error_func, func,
>^
> sizeof(es->s_first_error_func));
> ~~~
All of ext4 superblock char[] fields are not necessarily null
terminated, so this is a false positive. I suppose we could do
something like this:
inline char *
strncpy_I_solemnly_swear_I_know_what_I_am_doing(char *dest,
const char *src, size_t n)
{
#if __GNUC_PREREQ (8, 2)
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-truncate"
#endif
return strncpy(dest, src, n);
#if __GNUC_PREREQ (8, 2)
#pragma GCC diagnostic pop
#endif
}
(if we really think this warning is worthwhile enough that we don't
just want to globally disable it, of course)
- Ted
P.S. It's really, really too bad there isn't a simpler way to shut up
gcc. You need the #ifdef __GNUC_PREREQ nonsense because otherwise
older versions of gcc that don't understand the particular warning
you're trying to suppress will complain loudly. (Ask me how I
know)
Re: linux-next: build warnings from Linus' tree
On Mon, Aug 20, 2018 at 08:13:23AM +1000, Stephen Rothwell wrote:
> fs/ext4/super.c: In function '__save_error_info':
> fs/ext4/super.c:344:2: warning: 'strncpy' specified bound 32 equals
> destination size [-Wstringop-truncation]
> strncpy(es->s_last_error_func, func, sizeof(es->s_last_error_func));
> ^~~
> fs/ext4/super.c:349:3: warning: 'strncpy' specified bound 32 equals
> destination size [-Wstringop-truncation]
>strncpy(es->s_first_error_func, func,
>^
> sizeof(es->s_first_error_func));
> ~~~
All of ext4 superblock char[] fields are not necessarily null
terminated, so this is a false positive. I suppose we could do
something like this:
inline char *
strncpy_I_solemnly_swear_I_know_what_I_am_doing(char *dest,
const char *src, size_t n)
{
#if __GNUC_PREREQ (8, 2)
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-truncate"
#endif
return strncpy(dest, src, n);
#if __GNUC_PREREQ (8, 2)
#pragma GCC diagnostic pop
#endif
}
(if we really think this warning is worthwhile enough that we don't
just want to globally disable it, of course)
- Ted
P.S. It's really, really too bad there isn't a simpler way to shut up
gcc. You need the #ifdef __GNUC_PREREQ nonsense because otherwise
older versions of gcc that don't understand the particular warning
you're trying to suppress will complain loudly. (Ask me how I
know)
Re: [PATCH] gpio: 74x164: add lines-initial-states property
Hi Linus, On 8/16/18 10:11 AM, Linus Walleij wrote: > This sounds like something that should be generic, and not use > a bitmask, but offsets. It should work even if the number of > GPIOs from the chip is > 32. > > Is the usecase different from hogs? > See Documentation/devicetree/bindings/gpio.txt Thanks for pointing that out. Indeed for my use-case (Asserting single output to be high on driver probe) hogs are are sufficient solution. Best wishes David
Re: [PATCH] gpio: 74x164: add lines-initial-states property
Hi Linus, On 8/16/18 10:11 AM, Linus Walleij wrote: > This sounds like something that should be generic, and not use > a bitmask, but offsets. It should work even if the number of > GPIOs from the chip is > 32. > > Is the usecase different from hogs? > See Documentation/devicetree/bindings/gpio.txt Thanks for pointing that out. Indeed for my use-case (Asserting single output to be high on driver probe) hogs are are sufficient solution. Best wishes David
cgroup aware oom killer (was Re: [PATCH 0/3] introduce memory.oom.group)
Roman, have you had time to go through this?
On Tue, 7 Aug 2018, David Rientjes wrote:
> On Mon, 6 Aug 2018, Roman Gushchin wrote:
>
> > > In a cgroup-aware oom killer world, yes, we need the ability to specify
> > > that the usage of the entire subtree should be compared as a single
> > > entity with other cgroups. That is necessary for user subtrees but may
> > > not be necessary for top-level cgroups depending on how you structure
> > > your
> > > unified cgroup hierarchy. So it needs to be configurable, as you
> > > suggest,
> > > and you are correct it can be different than oom.group.
> > >
> > > That's not the only thing we need though, as I'm sure you were expecting
> > > me to say :)
> > >
> > > We need the ability to preserve existing behavior, i.e. process based and
> > > not cgroup aware, for subtrees so that our users who have clear
> > > expectations and tune their oom_score_adj accordingly based on how the
> > > oom
> > > killer has always chosen processes for oom kill do not suddenly regress.
> >
> > Isn't the combination of oom.group=0 and oom.evaluate_together=1 describing
> > this case? This basically means that if memcg is selected as target,
> > the process inside will be selected using traditional per-process approach.
> >
>
> No, that would overload the policy and mechanism. We want the ability to
> consider user-controlled subtrees as a single entity for comparison with
> other user subtrees to select which subtree to target. This does not
> imply that users want their entire subtree oom killed.
>
> > > So we need to define the policy for a subtree that is oom, and I suggest
> > > we do that as a characteristic of the cgroup that is oom ("process" vs
> > > "cgroup", and process would be the default to preserve what currently
> > > happens in a user subtree).
> >
> > I'm not entirely convinced here.
> > I do agree, that some sub-tree may have a well tuned oom_score_adj,
> > and it's preferable to keep the current behavior.
> >
> > At the same time I don't like the idea to look at the policy of the OOMing
> > cgroup. Why exceeding of one limit should be handled different to exceeding
> > of another? This seems to be a property of workload, not a limit.
> >
>
> The limit is the property of the mem cgroup, so it's logical that the
> policy when reaching that limit is a property of the same mem cgroup.
> Using the user-controlled subtree example, if we have /david and /roman,
> we can define our own policies on oom, we are not restricted to cgroup
> aware selection on the entire hierarchy. /david/oom.policy can be
> "process" so that I haven't regressed with earlier kernels, and
> /roman/oom.policy can be "cgroup" to target the largest cgroup in your
> subtree.
>
> Something needs to be oom killed when a mem cgroup at any level in the
> hierarchy is reached and reclaim has failed. What to do when that limit
> is reached is a property of that cgroup.
>
> > > Now, as users who rely on process selection are well aware, we have
> > > oom_score_adj to influence the decision of which process to oom kill. If
> > > our oom subtree is cgroup aware, we should have the ability to likewise
> > > influence that decision. For example, we have high priority applications
> > > that run at the top-level that use a lot of memory and strictly oom
> > > killing them in all scenarios because they use a lot of memory isn't
> > > appropriate. We need to be able to adjust the comparison of a cgroup (or
> > > subtree) when compared to other cgroups.
> > >
> > > I've also suggested, but did not implement in my patchset because I was
> > > trying to define the API and find common ground first, that we have a
> > > need
> > > for priority based selection. In other words, define the priority of a
> > > subtree regardless of cgroup usage.
> > >
> > > So with these four things, we have
> > >
> > > - an "oom.policy" tunable to define "cgroup" or "process" for that
> > >subtree (and plans for "priority" in the future),
> > >
> > > - your "oom.evaluate_as_group" tunable to account the usage of the
> > >subtree as the cgroup's own usage for comparison with others,
> > >
> > > - an "oom.adj" to adjust the usage of the cgroup (local or subtree)
> > >to protect important applications and bias against unimportant
> > >applications.
> > >
> > > This adds several tunables, which I didn't like, so I tried to overload
> > > oom.policy and oom.evaluate_as_group. When I referred to separating out
> > > the subtree usage accounting into a separate tunable, that is what I have
> > > referenced above.
> >
> > IMO, merging multiple tunables into one doesn't make it saner.
> > The real question how to make a reasonable interface with fever tunables.
> >
> > The reason behind introducing all these knobs is to provide
> > a generic solution to define OOM handling rules, but then the
> > question raises if the kernel is the best place for it.
> >
cgroup aware oom killer (was Re: [PATCH 0/3] introduce memory.oom.group)
Roman, have you had time to go through this?
On Tue, 7 Aug 2018, David Rientjes wrote:
> On Mon, 6 Aug 2018, Roman Gushchin wrote:
>
> > > In a cgroup-aware oom killer world, yes, we need the ability to specify
> > > that the usage of the entire subtree should be compared as a single
> > > entity with other cgroups. That is necessary for user subtrees but may
> > > not be necessary for top-level cgroups depending on how you structure
> > > your
> > > unified cgroup hierarchy. So it needs to be configurable, as you
> > > suggest,
> > > and you are correct it can be different than oom.group.
> > >
> > > That's not the only thing we need though, as I'm sure you were expecting
> > > me to say :)
> > >
> > > We need the ability to preserve existing behavior, i.e. process based and
> > > not cgroup aware, for subtrees so that our users who have clear
> > > expectations and tune their oom_score_adj accordingly based on how the
> > > oom
> > > killer has always chosen processes for oom kill do not suddenly regress.
> >
> > Isn't the combination of oom.group=0 and oom.evaluate_together=1 describing
> > this case? This basically means that if memcg is selected as target,
> > the process inside will be selected using traditional per-process approach.
> >
>
> No, that would overload the policy and mechanism. We want the ability to
> consider user-controlled subtrees as a single entity for comparison with
> other user subtrees to select which subtree to target. This does not
> imply that users want their entire subtree oom killed.
>
> > > So we need to define the policy for a subtree that is oom, and I suggest
> > > we do that as a characteristic of the cgroup that is oom ("process" vs
> > > "cgroup", and process would be the default to preserve what currently
> > > happens in a user subtree).
> >
> > I'm not entirely convinced here.
> > I do agree, that some sub-tree may have a well tuned oom_score_adj,
> > and it's preferable to keep the current behavior.
> >
> > At the same time I don't like the idea to look at the policy of the OOMing
> > cgroup. Why exceeding of one limit should be handled different to exceeding
> > of another? This seems to be a property of workload, not a limit.
> >
>
> The limit is the property of the mem cgroup, so it's logical that the
> policy when reaching that limit is a property of the same mem cgroup.
> Using the user-controlled subtree example, if we have /david and /roman,
> we can define our own policies on oom, we are not restricted to cgroup
> aware selection on the entire hierarchy. /david/oom.policy can be
> "process" so that I haven't regressed with earlier kernels, and
> /roman/oom.policy can be "cgroup" to target the largest cgroup in your
> subtree.
>
> Something needs to be oom killed when a mem cgroup at any level in the
> hierarchy is reached and reclaim has failed. What to do when that limit
> is reached is a property of that cgroup.
>
> > > Now, as users who rely on process selection are well aware, we have
> > > oom_score_adj to influence the decision of which process to oom kill. If
> > > our oom subtree is cgroup aware, we should have the ability to likewise
> > > influence that decision. For example, we have high priority applications
> > > that run at the top-level that use a lot of memory and strictly oom
> > > killing them in all scenarios because they use a lot of memory isn't
> > > appropriate. We need to be able to adjust the comparison of a cgroup (or
> > > subtree) when compared to other cgroups.
> > >
> > > I've also suggested, but did not implement in my patchset because I was
> > > trying to define the API and find common ground first, that we have a
> > > need
> > > for priority based selection. In other words, define the priority of a
> > > subtree regardless of cgroup usage.
> > >
> > > So with these four things, we have
> > >
> > > - an "oom.policy" tunable to define "cgroup" or "process" for that
> > >subtree (and plans for "priority" in the future),
> > >
> > > - your "oom.evaluate_as_group" tunable to account the usage of the
> > >subtree as the cgroup's own usage for comparison with others,
> > >
> > > - an "oom.adj" to adjust the usage of the cgroup (local or subtree)
> > >to protect important applications and bias against unimportant
> > >applications.
> > >
> > > This adds several tunables, which I didn't like, so I tried to overload
> > > oom.policy and oom.evaluate_as_group. When I referred to separating out
> > > the subtree usage accounting into a separate tunable, that is what I have
> > > referenced above.
> >
> > IMO, merging multiple tunables into one doesn't make it saner.
> > The real question how to make a reasonable interface with fever tunables.
> >
> > The reason behind introducing all these knobs is to provide
> > a generic solution to define OOM handling rules, but then the
> > question raises if the kernel is the best place for it.
> >
Re: [PATCH v8 2/2] PCI: pciehp: Mask AER surprise link down error if hotplug is enabled
On 8/18/2018 2:51 AM, Sinan Kaya wrote: cleanup_slot(ctrl); + pciehp_control_surprise_error(ctrl, true); I think I need to move this one line up but I'd like to see some input here and also ask for some testing. I don't have any hardware to test.
Re: [PATCH v8 2/2] PCI: pciehp: Mask AER surprise link down error if hotplug is enabled
On 8/18/2018 2:51 AM, Sinan Kaya wrote: cleanup_slot(ctrl); + pciehp_control_surprise_error(ctrl, true); I think I need to move this one line up but I'd like to see some input here and also ask for some testing. I don't have any hardware to test.
Re: linux-next: build warnings from Linus' tree
On Sun, Aug 19, 2018 at 3:13 PM Stephen Rothwell wrote: > > Today's linux-next build (powerpc ppc64_defconfig) produced these > warnings: > > fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region of > size 1 overflows the destination [-Wstringop-overflow=] >strncpy(pSMB->DialectsArray+count, protocols[i].name, 16); > > Presumably caused by my update to gcc 8.2.0. Yeah. There are some patches to mark some arrays as non-strings to get rid of these, but we'll see. Maybe we'll just disable the new gcc warning if it causes more pain than it is worth. Linus
Re: linux-next: build warnings from Linus' tree
On Sun, Aug 19, 2018 at 3:13 PM Stephen Rothwell wrote: > > Today's linux-next build (powerpc ppc64_defconfig) produced these > warnings: > > fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region of > size 1 overflows the destination [-Wstringop-overflow=] >strncpy(pSMB->DialectsArray+count, protocols[i].name, 16); > > Presumably caused by my update to gcc 8.2.0. Yeah. There are some patches to mark some arrays as non-strings to get rid of these, but we'll see. Maybe we'll just disable the new gcc warning if it causes more pain than it is worth. Linus
[PATCH v8 1/2] PCI: pciehp: Ignore link events when there is a fatal error pending
AER/DPC reset is known as warm-resets. HP link recovery is known as
cold-reset via power-off and power-on command to the PCI slot.
In the middle of a warm-reset operation (AER/DPC), we are:
1. turning off the slow power. Slot power needs to be kept on in order
for recovery to succeed.
2. performing a cold reset causing Fatal Error recovery to fail.
If link goes down due to a DPC event, it should be recovered by DPC
status trigger. Injecting a cold reset in the middle can cause a HW
lockup as it is an undefined behavior.
Similarly, If link goes down due to an AER secondary bus reset issue,
it should be recovered by HW. Injecting a cold reset in the middle of a
secondary bus reset can cause a HW lockup as it is an undefined behavior.
1. HP ISR observes link down interrupt.
2. HP ISR checks that there is a fatal error pending, it doesn't touch
the link.
3. HP ISR waits until link recovery happens.
4. HP ISR calls the read vendor id function.
5. If all fails, try the cold-reset approach.
If fatal error is pending and a fatal error service such as DPC or AER
is running, it is the responsibility of the fatal error service to
recover the link.
Signed-off-by: Sinan Kaya
---
drivers/pci/hotplug/pciehp_ctrl.c | 18
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/err.c| 34 +++
3 files changed, 54 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c
b/drivers/pci/hotplug/pciehp_ctrl.c
index da7c72372ffc..22354b6850c3 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -222,9 +222,27 @@ void pciehp_handle_disable_request(struct slot *slot)
void pciehp_handle_presence_or_link_change(struct slot *slot, u32 events)
{
struct controller *ctrl = slot->ctrl;
+ struct pci_dev *pdev = ctrl->pcie->port;
bool link_active;
u8 present;
+ /* If a fatal error is pending, wait for AER or DPC to handle it. */
+ if (pcie_fatal_error_pending(pdev)) {
+ bool recovered;
+
+ recovered = pcie_wait_fatal_error_clear(pdev);
+
+ /* If the fatal error is gone and the link is up, return */
+ if (recovered && pcie_wait_for_link(pdev, true)) {
+ ctrl_info(ctrl, "Slot(%s): Ignoring Link event due to
successful fatal error recovery\n",
+ slot_name(slot));
+ return;
+ }
+
+ ctrl_info(ctrl, "Slot(%s): Fatal error recovery failed for Link
event, trying hotplug reset\n",
+ slot_name(slot));
+ }
+
/*
* If the slot is on and presence or link has changed, turn it off.
* Even if it's occupied again, we cannot assume the card is the same.
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a07f3f..e2d98654630b 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -356,6 +356,8 @@ void pci_enable_acs(struct pci_dev *dev);
/* PCI error reporting and recovery */
void pcie_do_fatal_recovery(struct pci_dev *dev, u32 service);
void pcie_do_nonfatal_recovery(struct pci_dev *dev);
+bool pcie_fatal_error_pending(struct pci_dev *pdev);
+bool pcie_wait_fatal_error_clear(struct pci_dev *pdev);
bool pcie_wait_for_link(struct pci_dev *pdev, bool active);
#ifdef CONFIG_PCIEASPM
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index f7ce0cb0b0b7..b1b5604cb00b 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "portdrv.h"
#include "../pci.h"
@@ -386,3 +387,36 @@ void pcie_do_nonfatal_recovery(struct pci_dev *dev)
/* TODO: Should kernel panic here? */
pci_info(dev, "AER: Device recovery failed\n");
}
+
+bool pcie_fatal_error_pending(struct pci_dev *pdev)
+{
+ u16 err_status = 0;
+ int rc;
+
+ if (!pci_is_pcie(pdev))
+ return false;
+
+ rc = pcie_capability_read_word(pdev, PCI_EXP_DEVSTA, _status);
+ if (rc)
+ return false;
+
+ return !!(err_status & PCI_EXP_DEVSTA_FED);
+}
+
+bool pcie_wait_fatal_error_clear(struct pci_dev *pdev)
+{
+ int timeout = 1000;
+ bool ret;
+
+ for (;;) {
+ ret = pcie_fatal_error_pending(pdev);
+ if (ret == false)
+ return true;
+ if (timeout <= 0)
+ break;
+ msleep(20);
+ timeout -= 20;
+ }
+
+ return false;
+}
--
2.17.1
[PATCH v8 1/2] PCI: pciehp: Ignore link events when there is a fatal error pending
AER/DPC reset is known as warm-resets. HP link recovery is known as
cold-reset via power-off and power-on command to the PCI slot.
In the middle of a warm-reset operation (AER/DPC), we are:
1. turning off the slow power. Slot power needs to be kept on in order
for recovery to succeed.
2. performing a cold reset causing Fatal Error recovery to fail.
If link goes down due to a DPC event, it should be recovered by DPC
status trigger. Injecting a cold reset in the middle can cause a HW
lockup as it is an undefined behavior.
Similarly, If link goes down due to an AER secondary bus reset issue,
it should be recovered by HW. Injecting a cold reset in the middle of a
secondary bus reset can cause a HW lockup as it is an undefined behavior.
1. HP ISR observes link down interrupt.
2. HP ISR checks that there is a fatal error pending, it doesn't touch
the link.
3. HP ISR waits until link recovery happens.
4. HP ISR calls the read vendor id function.
5. If all fails, try the cold-reset approach.
If fatal error is pending and a fatal error service such as DPC or AER
is running, it is the responsibility of the fatal error service to
recover the link.
Signed-off-by: Sinan Kaya
---
drivers/pci/hotplug/pciehp_ctrl.c | 18
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/err.c| 34 +++
3 files changed, 54 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c
b/drivers/pci/hotplug/pciehp_ctrl.c
index da7c72372ffc..22354b6850c3 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -222,9 +222,27 @@ void pciehp_handle_disable_request(struct slot *slot)
void pciehp_handle_presence_or_link_change(struct slot *slot, u32 events)
{
struct controller *ctrl = slot->ctrl;
+ struct pci_dev *pdev = ctrl->pcie->port;
bool link_active;
u8 present;
+ /* If a fatal error is pending, wait for AER or DPC to handle it. */
+ if (pcie_fatal_error_pending(pdev)) {
+ bool recovered;
+
+ recovered = pcie_wait_fatal_error_clear(pdev);
+
+ /* If the fatal error is gone and the link is up, return */
+ if (recovered && pcie_wait_for_link(pdev, true)) {
+ ctrl_info(ctrl, "Slot(%s): Ignoring Link event due to
successful fatal error recovery\n",
+ slot_name(slot));
+ return;
+ }
+
+ ctrl_info(ctrl, "Slot(%s): Fatal error recovery failed for Link
event, trying hotplug reset\n",
+ slot_name(slot));
+ }
+
/*
* If the slot is on and presence or link has changed, turn it off.
* Even if it's occupied again, we cannot assume the card is the same.
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a07f3f..e2d98654630b 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -356,6 +356,8 @@ void pci_enable_acs(struct pci_dev *dev);
/* PCI error reporting and recovery */
void pcie_do_fatal_recovery(struct pci_dev *dev, u32 service);
void pcie_do_nonfatal_recovery(struct pci_dev *dev);
+bool pcie_fatal_error_pending(struct pci_dev *pdev);
+bool pcie_wait_fatal_error_clear(struct pci_dev *pdev);
bool pcie_wait_for_link(struct pci_dev *pdev, bool active);
#ifdef CONFIG_PCIEASPM
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index f7ce0cb0b0b7..b1b5604cb00b 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "portdrv.h"
#include "../pci.h"
@@ -386,3 +387,36 @@ void pcie_do_nonfatal_recovery(struct pci_dev *dev)
/* TODO: Should kernel panic here? */
pci_info(dev, "AER: Device recovery failed\n");
}
+
+bool pcie_fatal_error_pending(struct pci_dev *pdev)
+{
+ u16 err_status = 0;
+ int rc;
+
+ if (!pci_is_pcie(pdev))
+ return false;
+
+ rc = pcie_capability_read_word(pdev, PCI_EXP_DEVSTA, _status);
+ if (rc)
+ return false;
+
+ return !!(err_status & PCI_EXP_DEVSTA_FED);
+}
+
+bool pcie_wait_fatal_error_clear(struct pci_dev *pdev)
+{
+ int timeout = 1000;
+ bool ret;
+
+ for (;;) {
+ ret = pcie_fatal_error_pending(pdev);
+ if (ret == false)
+ return true;
+ if (timeout <= 0)
+ break;
+ msleep(20);
+ timeout -= 20;
+ }
+
+ return false;
+}
--
2.17.1
[PATCH v8 2/2] PCI: pciehp: Mask AER surprise link down error if hotplug is enabled
PCIe Spec 3.0. 7.10.2. Uncorrectable Error Status Register (Offset 04h)
defines link down errors as an AER error as bit 5 Surprise Down Error
Status.
If hotplug is supported by a particular port, we want hotplug driver
to handle the link down/up conditions via Data Link Layer Active
interrupt rather than the AER error interrupt. Mask the Surprise Down
Error during hotplug driver and re-enable it during remove.
Signed-off-by: Sinan Kaya
---
drivers/pci/hotplug/pciehp_core.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_core.c
b/drivers/pci/hotplug/pciehp_core.c
index ec48c9433ae5..8322db8f369a 100644
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -229,6 +229,29 @@ static void pciehp_check_presence(struct controller *ctrl)
up_read(>reset_lock);
}
+static int pciehp_control_surprise_error(struct controller *ctrl, bool enable)
+{
+ struct pci_dev *pdev = ctrl->pcie->port;
+ u32 reg32;
+ int pos;
+
+ if (!pci_is_pcie(pdev))
+ return -ENODEV;
+
+ pos = pdev->aer_cap;
+ if (!pos)
+ return -ENODEV;
+
+ pci_read_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, );
+ if (enable)
+ reg32 &= ~PCI_ERR_UNC_SURPDN;
+ else
+ reg32 |= PCI_ERR_UNC_SURPDN;
+ pci_write_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, reg32);
+
+ return 0;
+}
+
static int pciehp_probe(struct pcie_device *dev)
{
int rc;
@@ -280,6 +303,9 @@ static int pciehp_probe(struct pcie_device *dev)
pciehp_check_presence(ctrl);
+ /* We want exclusive control of link down events in hotplug driver */
+ pciehp_control_surprise_error(ctrl, false);
+
return 0;
err_out_shutdown_notification:
@@ -298,6 +324,7 @@ static void pciehp_remove(struct pcie_device *dev)
pci_hp_del(ctrl->slot->hotplug_slot);
pcie_shutdown_notification(ctrl);
cleanup_slot(ctrl);
+ pciehp_control_surprise_error(ctrl, true);
pciehp_release_ctrl(ctrl);
}
--
2.17.1
[PATCH v8 2/2] PCI: pciehp: Mask AER surprise link down error if hotplug is enabled
PCIe Spec 3.0. 7.10.2. Uncorrectable Error Status Register (Offset 04h)
defines link down errors as an AER error as bit 5 Surprise Down Error
Status.
If hotplug is supported by a particular port, we want hotplug driver
to handle the link down/up conditions via Data Link Layer Active
interrupt rather than the AER error interrupt. Mask the Surprise Down
Error during hotplug driver and re-enable it during remove.
Signed-off-by: Sinan Kaya
---
drivers/pci/hotplug/pciehp_core.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_core.c
b/drivers/pci/hotplug/pciehp_core.c
index ec48c9433ae5..8322db8f369a 100644
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -229,6 +229,29 @@ static void pciehp_check_presence(struct controller *ctrl)
up_read(>reset_lock);
}
+static int pciehp_control_surprise_error(struct controller *ctrl, bool enable)
+{
+ struct pci_dev *pdev = ctrl->pcie->port;
+ u32 reg32;
+ int pos;
+
+ if (!pci_is_pcie(pdev))
+ return -ENODEV;
+
+ pos = pdev->aer_cap;
+ if (!pos)
+ return -ENODEV;
+
+ pci_read_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, );
+ if (enable)
+ reg32 &= ~PCI_ERR_UNC_SURPDN;
+ else
+ reg32 |= PCI_ERR_UNC_SURPDN;
+ pci_write_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, reg32);
+
+ return 0;
+}
+
static int pciehp_probe(struct pcie_device *dev)
{
int rc;
@@ -280,6 +303,9 @@ static int pciehp_probe(struct pcie_device *dev)
pciehp_check_presence(ctrl);
+ /* We want exclusive control of link down events in hotplug driver */
+ pciehp_control_surprise_error(ctrl, false);
+
return 0;
err_out_shutdown_notification:
@@ -298,6 +324,7 @@ static void pciehp_remove(struct pcie_device *dev)
pci_hp_del(ctrl->slot->hotplug_slot);
pcie_shutdown_notification(ctrl);
cleanup_slot(ctrl);
+ pciehp_control_surprise_error(ctrl, true);
pciehp_release_ctrl(ctrl);
}
--
2.17.1
[PATCH] x86/process: Export start_thread()
Commit e634d8fc792c ("x86-64: merge the standard and compat
start_thread() functions") removed exporting for the start_thread()
function in what seems like a typo. Add it back to
arch/x86/kernel/process_64.c for parity with process_32.c and other
arch.
Signed-off-by: Rian Hunter
---
arch/x86/kernel/process_64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 476e3ddf8890..a451bc374b9b 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -384,6 +384,7 @@ start_thread(struct pt_regs *regs, unsigned long new_ip,
unsigned long new_sp)
start_thread_common(regs, new_ip, new_sp,
__USER_CS, __USER_DS, 0);
}
+EXPORT_SYMBOL_GPL(start_thread);
#ifdef CONFIG_COMPAT
void compat_start_thread(struct pt_regs *regs, u32 new_ip, u32 new_sp)
--
2.16.3
[PATCH] x86/process: Export start_thread()
Commit e634d8fc792c ("x86-64: merge the standard and compat
start_thread() functions") removed exporting for the start_thread()
function in what seems like a typo. Add it back to
arch/x86/kernel/process_64.c for parity with process_32.c and other
arch.
Signed-off-by: Rian Hunter
---
arch/x86/kernel/process_64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 476e3ddf8890..a451bc374b9b 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -384,6 +384,7 @@ start_thread(struct pt_regs *regs, unsigned long new_ip,
unsigned long new_sp)
start_thread_common(regs, new_ip, new_sp,
__USER_CS, __USER_DS, 0);
}
+EXPORT_SYMBOL_GPL(start_thread);
#ifdef CONFIG_COMPAT
void compat_start_thread(struct pt_regs *regs, u32 new_ip, u32 new_sp)
--
2.16.3
Re: linux-next: build warnings from Linus' tree
Hi all,
On Mon, 20 Aug 2018 08:16:18 +1000 Stephen Rothwell
wrote:
>
> On Mon, 20 Aug 2018 08:13:23 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) produced these
> > warnings:
> >
> ...
> >
> > Presumably caused by my update to gcc 8.2.0.
>
> And this from the x86_64 allmodconfig build:
>
> scripts/unifdef.c: In function 'Mpass':
> scripts/unifdef.c:453:28: warning: 'strncpy' output truncated before
> terminating nul copying 4 bytes from a string of the same length
> [-Wstringop-truncation]
> static void Mpass (void) { strncpy(keyword, "if ", 4); Pelif(); }
> ^~~
Note that I only upgraded my (host) powerpc compiler.
--
Cheers,
Stephen Rothwell
pgpeM_4obblHa.pgp
Description: OpenPGP digital signature
Re: linux-next: build warnings from Linus' tree
Hi all,
On Mon, 20 Aug 2018 08:16:18 +1000 Stephen Rothwell
wrote:
>
> On Mon, 20 Aug 2018 08:13:23 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) produced these
> > warnings:
> >
> ...
> >
> > Presumably caused by my update to gcc 8.2.0.
>
> And this from the x86_64 allmodconfig build:
>
> scripts/unifdef.c: In function 'Mpass':
> scripts/unifdef.c:453:28: warning: 'strncpy' output truncated before
> terminating nul copying 4 bytes from a string of the same length
> [-Wstringop-truncation]
> static void Mpass (void) { strncpy(keyword, "if ", 4); Pelif(); }
> ^~~
Note that I only upgraded my (host) powerpc compiler.
--
Cheers,
Stephen Rothwell
pgpeM_4obblHa.pgp
Description: OpenPGP digital signature
Re: linux-next: build warnings from Linus' tree
Hi all,
On Mon, 20 Aug 2018 08:13:23 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next build (powerpc ppc64_defconfig) produced these
> warnings:
>
...
>
> Presumably caused by my update to gcc 8.2.0.
And this from the x86_64 allmodconfig build:
scripts/unifdef.c: In function 'Mpass':
scripts/unifdef.c:453:28: warning: 'strncpy' output truncated before
terminating nul copying 4 bytes from a string of the same length
[-Wstringop-truncation]
static void Mpass (void) { strncpy(keyword, "if ", 4); Pelif(); }
^~~
--
Cheers,
Stephen Rothwell
pgpVPhNgYwUXE.pgp
Description: OpenPGP digital signature
Re: linux-next: build warnings from Linus' tree
Hi all,
On Mon, 20 Aug 2018 08:13:23 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next build (powerpc ppc64_defconfig) produced these
> warnings:
>
...
>
> Presumably caused by my update to gcc 8.2.0.
And this from the x86_64 allmodconfig build:
scripts/unifdef.c: In function 'Mpass':
scripts/unifdef.c:453:28: warning: 'strncpy' output truncated before
terminating nul copying 4 bytes from a string of the same length
[-Wstringop-truncation]
static void Mpass (void) { strncpy(keyword, "if ", 4); Pelif(); }
^~~
--
Cheers,
Stephen Rothwell
pgpVPhNgYwUXE.pgp
Description: OpenPGP digital signature
linux-next: build warnings from Linus' tree
Hi Linus,
Today's linux-next build (powerpc ppc64_defconfig) produced these
warnings:
fs/cifs/cifssmb.c: In function 'CIFSSMBNegotiate':
fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region of
size 1 overflows the destination [-Wstringop-overflow=]
strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
^
In function 'get_sensor_index_attr',
inlined from 'create_device_attrs' at drivers/hwmon/ibmpowernv.c:293:8,
inlined from 'ibmpowernv_probe' at drivers/hwmon/ibmpowernv.c:699:8:
drivers/hwmon/ibmpowernv.c:256:2: warning: 'strncpy' specified bound 32 equals
destination size [-Wstringop-truncation]
strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
^
fs/hfsplus/xattr.c: In function 'copy_name':
fs/hfsplus/xattr.c:416:3: warning: 'strncpy' output truncated before
terminating nul copying 4 bytes from a string of the same length
[-Wstringop-truncation]
strncpy(buffer, XATTR_MAC_OSX_PREFIX, XATTR_MAC_OSX_PREFIX_LEN);
^~~
fs/ext4/super.c: In function '__save_error_info':
fs/ext4/super.c:344:2: warning: 'strncpy' specified bound 32 equals destination
size [-Wstringop-truncation]
strncpy(es->s_last_error_func, func, sizeof(es->s_last_error_func));
^~~
fs/ext4/super.c:349:3: warning: 'strncpy' specified bound 32 equals destination
size [-Wstringop-truncation]
strncpy(es->s_first_error_func, func,
^
sizeof(es->s_first_error_func));
~~~
In file included from include/trace/define_trace.h:97,
from include/trace/events/writeback.h:762,
from fs/fs-writeback.c:98:
include/trace/events/writeback.h: In function 'perf_trace_writeback_work_class':
include/trace/events/writeback.h:223:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name,
^~
wb->bdi->dev ? dev_name(wb->bdi->dev) : "(unknown)", 32);
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/events/writeback.h:222:2: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
include/trace/events/writeback.h: In function 'perf_trace_writeback_class':
include/trace/events/writeback.h:277:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name, dev_name(wb->bdi->dev), 32);
^~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/events/writeback.h:276:2: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
include/trace/events/writeback.h: In function
'perf_trace_writeback_bdi_register':
include/trace/events/writeback.h:299:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name, dev_name(bdi->dev), 32);
^~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
include/trace/events/writeback.h:292:1: note: in expansion of macro
'TRACE_EVENT'
TRACE_EVENT(writeback_bdi_register,
^~~
include/trace/events/writeback.h:298:2: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
include/trace/events/writeback.h: In function 'perf_trace_wbc_class':
include/trace/events/writeback.h:324:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name, dev_name(bdi->dev), 32);
^~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/events/writeback.h:323:2: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
include/trace/events/writeback.h: In function 'perf_trace_writeback_queue_io':
include/trace/events/writeback.h:375:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name, dev_name(wb->bdi->dev), 32);
^~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
include/trace/events/writeback.h:360:1: note: in expansion of macro
'TRACE_EVENT'
linux-next: build warnings from Linus' tree
Hi Linus,
Today's linux-next build (powerpc ppc64_defconfig) produced these
warnings:
fs/cifs/cifssmb.c: In function 'CIFSSMBNegotiate':
fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region of
size 1 overflows the destination [-Wstringop-overflow=]
strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
^
In function 'get_sensor_index_attr',
inlined from 'create_device_attrs' at drivers/hwmon/ibmpowernv.c:293:8,
inlined from 'ibmpowernv_probe' at drivers/hwmon/ibmpowernv.c:699:8:
drivers/hwmon/ibmpowernv.c:256:2: warning: 'strncpy' specified bound 32 equals
destination size [-Wstringop-truncation]
strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
^
fs/hfsplus/xattr.c: In function 'copy_name':
fs/hfsplus/xattr.c:416:3: warning: 'strncpy' output truncated before
terminating nul copying 4 bytes from a string of the same length
[-Wstringop-truncation]
strncpy(buffer, XATTR_MAC_OSX_PREFIX, XATTR_MAC_OSX_PREFIX_LEN);
^~~
fs/ext4/super.c: In function '__save_error_info':
fs/ext4/super.c:344:2: warning: 'strncpy' specified bound 32 equals destination
size [-Wstringop-truncation]
strncpy(es->s_last_error_func, func, sizeof(es->s_last_error_func));
^~~
fs/ext4/super.c:349:3: warning: 'strncpy' specified bound 32 equals destination
size [-Wstringop-truncation]
strncpy(es->s_first_error_func, func,
^
sizeof(es->s_first_error_func));
~~~
In file included from include/trace/define_trace.h:97,
from include/trace/events/writeback.h:762,
from fs/fs-writeback.c:98:
include/trace/events/writeback.h: In function 'perf_trace_writeback_work_class':
include/trace/events/writeback.h:223:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name,
^~
wb->bdi->dev ? dev_name(wb->bdi->dev) : "(unknown)", 32);
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/events/writeback.h:222:2: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
include/trace/events/writeback.h: In function 'perf_trace_writeback_class':
include/trace/events/writeback.h:277:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name, dev_name(wb->bdi->dev), 32);
^~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/events/writeback.h:276:2: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
include/trace/events/writeback.h: In function
'perf_trace_writeback_bdi_register':
include/trace/events/writeback.h:299:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name, dev_name(bdi->dev), 32);
^~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
include/trace/events/writeback.h:292:1: note: in expansion of macro
'TRACE_EVENT'
TRACE_EVENT(writeback_bdi_register,
^~~
include/trace/events/writeback.h:298:2: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
include/trace/events/writeback.h: In function 'perf_trace_wbc_class':
include/trace/events/writeback.h:324:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name, dev_name(bdi->dev), 32);
^~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/events/writeback.h:323:2: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
include/trace/events/writeback.h: In function 'perf_trace_writeback_queue_io':
include/trace/events/writeback.h:375:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name, dev_name(wb->bdi->dev), 32);
^~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
include/trace/events/writeback.h:360:1: note: in expansion of macro
'TRACE_EVENT'
Re: [PATCH v6 1/2] iio: light: Add support for vishay vcnl4035
Hi, On Tue, Aug 07, 2018 at 12:27:03PM +0200, Parthiban Nallathambi wrote: > Add support for VCNL4035, which is capable of Ambient light > sensing (ALS) and proximity function. This patch adds support > only for ALS function > > Signed-off-by: Parthiban Nallathambi > > Changelog since v1: > > 1. Fixed 0-day warning on le16_to_cpu usage > 2. Persistence value is directly mapped to datasheet's value to > avoid confusions of usage from sysfs > > Changelog in v3: > - Usage of lock is not needed, removed mutex locking > - ALS threshold and persistence configuration available > as events and threshold events are notified to userspace > - Usage of devm_ is re-ordered and exit handling updated > - Complexity in timestamp calculation is removed and used > iio_get_time_ns > > Changelog in v4: > - New white light index is introduced for getting data from > white spectrum > - PM enable/disable is called from read_raw accordingly > - Probe exit handling re-ordered > > Changelog in v5: > - White spectrum is mesaured as "_CLEAR" intesity, so removed > white spectrum modifier > - Header re-ordering > - Trigger init and de-init into separate function > - Indentation correct and usage of dev_err in place of pr_err > > Changelog in v6: > - Usage of devm_ for trigger probing and cleanups > - pm_runtime re-order and exit patch corrections > - IIO_INTENSITY to IIO_LIGHT, lux/steps are fixed at IT cycle > lux can be calculated based on IT sensitivity > - _CLEAR to _BOTH although measurement is only WHITE spectrum > for traditional reasons > --- As Jonathan already pointed out, the changelog should go here. A tip is to use notes (see `man git-notes`) to add a changelog and then generate the patches with `git format-patch --notes `. I find it really neat. > drivers/iio/light/Kconfig| 12 + > drivers/iio/light/Makefile | 1 + > drivers/iio/light/vcnl4035.c | 686 > +++ > 3 files changed, 699 insertions(+) > create mode 100644 drivers/iio/light/vcnl4035.c > > diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig > index c7ef8d1862d6..b7069a4c28a2 100644 > --- a/drivers/iio/light/Kconfig > +++ b/drivers/iio/light/Kconfig > @@ -447,6 +447,18 @@ config VCNL4000 >To compile this driver as a module, choose M here: the >module will be called vcnl4000. > > +config VCNL4035 > + tristate "VCNL4035 combined ALS and proximity sensor" > + select REGMAP_I2C > + depends on I2C > + help > + Say Y here if you want to build a driver for the Vishay VCNL4035, > + combined ambient light (ALS) and proximity sensor. Currently only ALS > + function is available. > + > + To compile this driver as a module, choose M here: the > + module will be called vcnl4035. > + > config VEML6070 > tristate "VEML6070 UV A light sensor" > depends on I2C > diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile > index 80943af5d627..dce98511a59b 100644 > --- a/drivers/iio/light/Makefile > +++ b/drivers/iio/light/Makefile > @@ -44,6 +44,7 @@ obj-$(CONFIG_TSL2772) += tsl2772.o > obj-$(CONFIG_TSL4531)+= tsl4531.o > obj-$(CONFIG_US5182D)+= us5182d.o > obj-$(CONFIG_VCNL4000) += vcnl4000.o > +obj-$(CONFIG_VCNL4035) += vcnl4035.o > obj-$(CONFIG_VEML6070) += veml6070.o > obj-$(CONFIG_VL6180) += vl6180.o > obj-$(CONFIG_ZOPT2201) += zopt2201.o > diff --git a/drivers/iio/light/vcnl4035.c b/drivers/iio/light/vcnl4035.c > new file mode 100644 > index ..e9f471d93a15 > --- /dev/null > +++ b/drivers/iio/light/vcnl4035.c > @@ -0,0 +1,686 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * VCNL4035 Ambient Light and Proximity Sensor - 7-bit I2C slave address 0x60 > + * > + * Copyright (c) 2018, DENX Software Engineering GmbH > + * Author: Parthiban Nallathambi > + * > + * > + * TODO: Proximity > + */ > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define VCNL4035_DRV_NAME"vcnl4035" > +#define VCNL4035_IRQ_NAME"vcnl4035_event" > +#define VCNL4035_REGMAP_NAME "vcnl4035_regmap" > + > +/* Device registers */ > +#define VCNL4035_ALS_CONF0x00 > +#define VCNL4035_ALS_THDH0x01 > +#define VCNL4035_ALS_THDL0x02 > +#define VCNL4035_ALS_DATA0x0B > +#define VCNL4035_WHITE_DATA 0x0C > +#define VCNL4035_INT_FLAG0x0D > +#define VCNL4035_DEV_ID 0x0E > + > +/* Register masks */ > +#define VCNL4035_MODE_ALS_MASK BIT(0) > +#define VCNL4035_MODE_ALS_WHITE_CHAN BIT(8) > +#define VCNL4035_MODE_ALS_INT_MASK BIT(1) > +#define VCNL4035_ALS_IT_MASK GENMASK(7, 5) > +#define VCNL4035_ALS_PERS_MASK GENMASK(3, 2) > +#define VCNL4035_INT_ALS_IF_H_MASK BIT(12) > +#define VCNL4035_INT_ALS_IF_L_MASK BIT(13) > + > +/* Default values */
Re: [PATCH v6 1/2] iio: light: Add support for vishay vcnl4035
Hi, On Tue, Aug 07, 2018 at 12:27:03PM +0200, Parthiban Nallathambi wrote: > Add support for VCNL4035, which is capable of Ambient light > sensing (ALS) and proximity function. This patch adds support > only for ALS function > > Signed-off-by: Parthiban Nallathambi > > Changelog since v1: > > 1. Fixed 0-day warning on le16_to_cpu usage > 2. Persistence value is directly mapped to datasheet's value to > avoid confusions of usage from sysfs > > Changelog in v3: > - Usage of lock is not needed, removed mutex locking > - ALS threshold and persistence configuration available > as events and threshold events are notified to userspace > - Usage of devm_ is re-ordered and exit handling updated > - Complexity in timestamp calculation is removed and used > iio_get_time_ns > > Changelog in v4: > - New white light index is introduced for getting data from > white spectrum > - PM enable/disable is called from read_raw accordingly > - Probe exit handling re-ordered > > Changelog in v5: > - White spectrum is mesaured as "_CLEAR" intesity, so removed > white spectrum modifier > - Header re-ordering > - Trigger init and de-init into separate function > - Indentation correct and usage of dev_err in place of pr_err > > Changelog in v6: > - Usage of devm_ for trigger probing and cleanups > - pm_runtime re-order and exit patch corrections > - IIO_INTENSITY to IIO_LIGHT, lux/steps are fixed at IT cycle > lux can be calculated based on IT sensitivity > - _CLEAR to _BOTH although measurement is only WHITE spectrum > for traditional reasons > --- As Jonathan already pointed out, the changelog should go here. A tip is to use notes (see `man git-notes`) to add a changelog and then generate the patches with `git format-patch --notes `. I find it really neat. > drivers/iio/light/Kconfig| 12 + > drivers/iio/light/Makefile | 1 + > drivers/iio/light/vcnl4035.c | 686 > +++ > 3 files changed, 699 insertions(+) > create mode 100644 drivers/iio/light/vcnl4035.c > > diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig > index c7ef8d1862d6..b7069a4c28a2 100644 > --- a/drivers/iio/light/Kconfig > +++ b/drivers/iio/light/Kconfig > @@ -447,6 +447,18 @@ config VCNL4000 >To compile this driver as a module, choose M here: the >module will be called vcnl4000. > > +config VCNL4035 > + tristate "VCNL4035 combined ALS and proximity sensor" > + select REGMAP_I2C > + depends on I2C > + help > + Say Y here if you want to build a driver for the Vishay VCNL4035, > + combined ambient light (ALS) and proximity sensor. Currently only ALS > + function is available. > + > + To compile this driver as a module, choose M here: the > + module will be called vcnl4035. > + > config VEML6070 > tristate "VEML6070 UV A light sensor" > depends on I2C > diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile > index 80943af5d627..dce98511a59b 100644 > --- a/drivers/iio/light/Makefile > +++ b/drivers/iio/light/Makefile > @@ -44,6 +44,7 @@ obj-$(CONFIG_TSL2772) += tsl2772.o > obj-$(CONFIG_TSL4531)+= tsl4531.o > obj-$(CONFIG_US5182D)+= us5182d.o > obj-$(CONFIG_VCNL4000) += vcnl4000.o > +obj-$(CONFIG_VCNL4035) += vcnl4035.o > obj-$(CONFIG_VEML6070) += veml6070.o > obj-$(CONFIG_VL6180) += vl6180.o > obj-$(CONFIG_ZOPT2201) += zopt2201.o > diff --git a/drivers/iio/light/vcnl4035.c b/drivers/iio/light/vcnl4035.c > new file mode 100644 > index ..e9f471d93a15 > --- /dev/null > +++ b/drivers/iio/light/vcnl4035.c > @@ -0,0 +1,686 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * VCNL4035 Ambient Light and Proximity Sensor - 7-bit I2C slave address 0x60 > + * > + * Copyright (c) 2018, DENX Software Engineering GmbH > + * Author: Parthiban Nallathambi > + * > + * > + * TODO: Proximity > + */ > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define VCNL4035_DRV_NAME"vcnl4035" > +#define VCNL4035_IRQ_NAME"vcnl4035_event" > +#define VCNL4035_REGMAP_NAME "vcnl4035_regmap" > + > +/* Device registers */ > +#define VCNL4035_ALS_CONF0x00 > +#define VCNL4035_ALS_THDH0x01 > +#define VCNL4035_ALS_THDL0x02 > +#define VCNL4035_ALS_DATA0x0B > +#define VCNL4035_WHITE_DATA 0x0C > +#define VCNL4035_INT_FLAG0x0D > +#define VCNL4035_DEV_ID 0x0E > + > +/* Register masks */ > +#define VCNL4035_MODE_ALS_MASK BIT(0) > +#define VCNL4035_MODE_ALS_WHITE_CHAN BIT(8) > +#define VCNL4035_MODE_ALS_INT_MASK BIT(1) > +#define VCNL4035_ALS_IT_MASK GENMASK(7, 5) > +#define VCNL4035_ALS_PERS_MASK GENMASK(3, 2) > +#define VCNL4035_INT_ALS_IF_H_MASK BIT(12) > +#define VCNL4035_INT_ALS_IF_L_MASK BIT(13) > + > +/* Default values */
Re: Build failures with gcc 4.5 and older
On Tue, Aug 14, 2018 at 10:48 AM, Joe Perches wrote:
> On Tue, 2018-08-14 at 10:09 -0700, Guenter Roeck wrote:
>> Hi,
>>
>> Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask
>> (mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building
>> the Linux kernel with gcc version 4.5 and older fails as follows.
>>
>> In file included from ./include/linux/mm.h:17:0,
>> from ./include/linux/pid_namespace.h:7,
>>from ./include/linux/ptrace.h:10,
>>from arch/openrisc/kernel/asm-offsets.c:32:
>> ./include/linux/mm_types.h:497:16: error: flexible array member in otherwise
>> empty struct
>>
>> This is just an example with gcc 4.5.1 for or32. I have seen the problem
>> with gcc 4.4 (for unicore32) as well.
>>
>> Does that mean that gcc 4.5 and older are now officially no longer
>> supported for compiling the kernel ?
>>
>> If so, would it make sense to update include/linux/compiler-gcc.h
>> accordingly ?
>
> And Documentation/process/changes.rst which shows a
> minimum version required of gcc as 3.2, etc...
>
> With cleaning up now unnecessary version tests in
> compiler-gcc.h, something like:
I rejoice at raising the minimum gcc to version 4.6! :)
> ---
> Documentation/process/changes.rst | 2 +-
> include/linux/compiler-gcc.h | 86
> ---
> 2 files changed, 19 insertions(+), 69 deletions(-)
These look good, thanks:
Reviewed-by: Kees Cook
-Kees
>
> diff --git a/Documentation/process/changes.rst
> b/Documentation/process/changes.rst
> index 7a92a06f90de..61f918b10a0c 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
> @@ -29,7 +29,7 @@ you probably needn't concern yourself with isdn4k-utils.
> == ===
>
> ProgramMinimal version Command to check the version
> == ===
>
> -GNU C 3.2 gcc --version
> +GNU C 4.6 gcc --version
> GNU make 3.81 make --version
> binutils 2.20 ld -v
> flex 2.5.35 flex --version
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 573f5a7d42d4..020e4b9eee5c 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -10,6 +10,10 @@
> + __GNUC_MINOR__ * 100 \
> + __GNUC_PATCHLEVEL__)
>
> +#if GCC_VERSION < 40600
> +# error Sorry, your compiler is too old - please upgrade it.
> +#endif
> +
> /* Optimization barrier */
>
> /* The "volatile" is due to gcc bugs */
> @@ -58,6 +62,12 @@
> #define OPTIMIZER_HIDE_VAR(var)
> \
> __asm__ ("" : "=r" (var) : "0" (var))
>
> +/*
> + * A trick to suppress uninitialized variable warning without generating any
> + * code
> + */
> +#define uninitialized_var(x) x = x
> +
> #ifdef __CHECKER__
> #define __must_be_array(a) 0
> #else
> @@ -91,7 +101,7 @@
> * A lot of inline functions can cause havoc with function tracing.
> */
> #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \
> -!defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
> +!defined(CONFIG_OPTIMIZE_INLINING)
> #define inline \
> inline __attribute__((always_inline, unused)) notrace __gnu_inline
> #else
> @@ -148,47 +158,13 @@
> #define __always_unused__attribute__((unused))
> #define __mode(x) __attribute__((mode(x)))
>
> -/* gcc version specific checks */
> -
> -#if GCC_VERSION < 30200
> -# error Sorry, your compiler is too old - please upgrade it.
> -#endif
> -
> -#if GCC_VERSION < 30300
> -# define __used__attribute__((__unused__))
> -#else
> -# define __used__attribute__((__used__))
> -#endif
> -
> -#ifdef CONFIG_GCOV_KERNEL
> -# if GCC_VERSION < 30400
> -# error "GCOV profiling support for gcc versions below 3.4 not included"
> -# endif /* __GNUC_MINOR__ */
> -#endif /* CONFIG_GCOV_KERNEL */
> -
> -#if GCC_VERSION >= 30400
> #define __must_check __attribute__((warn_unused_result))
> #define __malloc __attribute__((__malloc__))
> -#endif
> -
> -#if GCC_VERSION >= 4
> -
> -/* GCC 4.1.[01] miscompiles __weak */
> -#ifdef __KERNEL__
> -# if GCC_VERSION >= 40100 && GCC_VERSION <= 40101
> -# error Your version of gcc miscompiles the __weak directive
> -# endif
> -#endif
>
> #define __used __attribute__((__used__))
> #define __compiler_offsetof(a, b) \
> __builtin_offsetof(a, b)
>
> -#if GCC_VERSION >= 40100
> -# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
> -#endif
> -
> -#if GCC_VERSION >= 40300
> /* Mark functions as cold. gcc will assume
Re: Build failures with gcc 4.5 and older
On Tue, Aug 14, 2018 at 10:48 AM, Joe Perches wrote:
> On Tue, 2018-08-14 at 10:09 -0700, Guenter Roeck wrote:
>> Hi,
>>
>> Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask
>> (mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building
>> the Linux kernel with gcc version 4.5 and older fails as follows.
>>
>> In file included from ./include/linux/mm.h:17:0,
>> from ./include/linux/pid_namespace.h:7,
>>from ./include/linux/ptrace.h:10,
>>from arch/openrisc/kernel/asm-offsets.c:32:
>> ./include/linux/mm_types.h:497:16: error: flexible array member in otherwise
>> empty struct
>>
>> This is just an example with gcc 4.5.1 for or32. I have seen the problem
>> with gcc 4.4 (for unicore32) as well.
>>
>> Does that mean that gcc 4.5 and older are now officially no longer
>> supported for compiling the kernel ?
>>
>> If so, would it make sense to update include/linux/compiler-gcc.h
>> accordingly ?
>
> And Documentation/process/changes.rst which shows a
> minimum version required of gcc as 3.2, etc...
>
> With cleaning up now unnecessary version tests in
> compiler-gcc.h, something like:
I rejoice at raising the minimum gcc to version 4.6! :)
> ---
> Documentation/process/changes.rst | 2 +-
> include/linux/compiler-gcc.h | 86
> ---
> 2 files changed, 19 insertions(+), 69 deletions(-)
These look good, thanks:
Reviewed-by: Kees Cook
-Kees
>
> diff --git a/Documentation/process/changes.rst
> b/Documentation/process/changes.rst
> index 7a92a06f90de..61f918b10a0c 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
> @@ -29,7 +29,7 @@ you probably needn't concern yourself with isdn4k-utils.
> == ===
>
> ProgramMinimal version Command to check the version
> == ===
>
> -GNU C 3.2 gcc --version
> +GNU C 4.6 gcc --version
> GNU make 3.81 make --version
> binutils 2.20 ld -v
> flex 2.5.35 flex --version
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 573f5a7d42d4..020e4b9eee5c 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -10,6 +10,10 @@
> + __GNUC_MINOR__ * 100 \
> + __GNUC_PATCHLEVEL__)
>
> +#if GCC_VERSION < 40600
> +# error Sorry, your compiler is too old - please upgrade it.
> +#endif
> +
> /* Optimization barrier */
>
> /* The "volatile" is due to gcc bugs */
> @@ -58,6 +62,12 @@
> #define OPTIMIZER_HIDE_VAR(var)
> \
> __asm__ ("" : "=r" (var) : "0" (var))
>
> +/*
> + * A trick to suppress uninitialized variable warning without generating any
> + * code
> + */
> +#define uninitialized_var(x) x = x
> +
> #ifdef __CHECKER__
> #define __must_be_array(a) 0
> #else
> @@ -91,7 +101,7 @@
> * A lot of inline functions can cause havoc with function tracing.
> */
> #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \
> -!defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
> +!defined(CONFIG_OPTIMIZE_INLINING)
> #define inline \
> inline __attribute__((always_inline, unused)) notrace __gnu_inline
> #else
> @@ -148,47 +158,13 @@
> #define __always_unused__attribute__((unused))
> #define __mode(x) __attribute__((mode(x)))
>
> -/* gcc version specific checks */
> -
> -#if GCC_VERSION < 30200
> -# error Sorry, your compiler is too old - please upgrade it.
> -#endif
> -
> -#if GCC_VERSION < 30300
> -# define __used__attribute__((__unused__))
> -#else
> -# define __used__attribute__((__used__))
> -#endif
> -
> -#ifdef CONFIG_GCOV_KERNEL
> -# if GCC_VERSION < 30400
> -# error "GCOV profiling support for gcc versions below 3.4 not included"
> -# endif /* __GNUC_MINOR__ */
> -#endif /* CONFIG_GCOV_KERNEL */
> -
> -#if GCC_VERSION >= 30400
> #define __must_check __attribute__((warn_unused_result))
> #define __malloc __attribute__((__malloc__))
> -#endif
> -
> -#if GCC_VERSION >= 4
> -
> -/* GCC 4.1.[01] miscompiles __weak */
> -#ifdef __KERNEL__
> -# if GCC_VERSION >= 40100 && GCC_VERSION <= 40101
> -# error Your version of gcc miscompiles the __weak directive
> -# endif
> -#endif
>
> #define __used __attribute__((__used__))
> #define __compiler_offsetof(a, b) \
> __builtin_offsetof(a, b)
>
> -#if GCC_VERSION >= 40100
> -# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
> -#endif
> -
> -#if GCC_VERSION >= 40300
> /* Mark functions as cold. gcc will assume
Re: [PATCH] Revert "Permit silencing of __deprecated warnings."
On Fri, 17 Aug 2018 20:45:06 -0600 Jason Gunthorpe wrote: > Jonathan: I'm not sure if you prefer diffs to documentation to be > minimal like this, or if should reflow the paragraph? I guess I've never really thought to develop a strong preference. But, in the end, the docs are meant to be read in their source form, so we want to keep them readable. If a paragraph needs to be refilled due to significant changes, just go ahead and do it... jon
Re: [PATCH] Revert "Permit silencing of __deprecated warnings."
On Fri, 17 Aug 2018 20:45:06 -0600 Jason Gunthorpe wrote: > Jonathan: I'm not sure if you prefer diffs to documentation to be > minimal like this, or if should reflow the paragraph? I guess I've never really thought to develop a strong preference. But, in the end, the docs are meant to be read in their source form, so we want to keep them readable. If a paragraph needs to be refilled due to significant changes, just go ahead and do it... jon
Re: [RFC PATCH] compiler.h: give up __compiletime_assert_fallback()
On Sun, Aug 19, 2018 at 1:36 PM Nick Desaulniers wrote: > > On Sun, Aug 19, 2018 at 1:28 PM Linus Torvalds > wrote: > > > > Well, it turns out that we effectively stopped supporting gcc < 4.6 > > during this merge window for other reasons, so.. > > For the whole kernel (or just a particular arch)? Which commit? Do > we keep track of minimal versions somewhere? It's effectively for the whole kernel right now. See: https://lore.kernel.org/lkml/20180814170904.ga12...@roeck-us.net/ although it might be fixable. Nobody really *wants* to fix it, though, because we've had that initializer issue before too, and various other issues with old gcc versions. So we have long had reasons why we'd _want_ to upgrade to at least gcc-4.6 The "we support gcc-3.2" in Documentation/process/changes.rst is complete fantasy. Linus
Re: [RFC PATCH] compiler.h: give up __compiletime_assert_fallback()
On Sun, Aug 19, 2018 at 1:36 PM Nick Desaulniers wrote: > > On Sun, Aug 19, 2018 at 1:28 PM Linus Torvalds > wrote: > > > > Well, it turns out that we effectively stopped supporting gcc < 4.6 > > during this merge window for other reasons, so.. > > For the whole kernel (or just a particular arch)? Which commit? Do > we keep track of minimal versions somewhere? It's effectively for the whole kernel right now. See: https://lore.kernel.org/lkml/20180814170904.ga12...@roeck-us.net/ although it might be fixable. Nobody really *wants* to fix it, though, because we've had that initializer issue before too, and various other issues with old gcc versions. So we have long had reasons why we'd _want_ to upgrade to at least gcc-4.6 The "we support gcc-3.2" in Documentation/process/changes.rst is complete fantasy. Linus
Re: [RFC PATCH] compiler.h: give up __compiletime_assert_fallback()
On Sun, Aug 19, 2018 at 1:28 PM Linus Torvalds wrote: > > On Sun, Aug 19, 2018 at 1:25 PM Nick Desaulniers > wrote: > > > > + gbiv who wrote this cool paste (showing alternatives to > > _Static_assert, which is supported by both compilers in -std=gnu89, > > but not until gcc 4.6): https://godbolt.org/g/DuLsxu > > > > I can't help but think that BUILD_BUG_ON_MSG should use > > _Static_assert, then have fallbacks for gcc < 4.6. > > Well, it turns out that we effectively stopped supporting gcc < 4.6 > during this merge window for other reasons, so.. For the whole kernel (or just a particular arch)? Which commit? Do we keep track of minimal versions somewhere? Documentation/process/changes.rst mentions gcc 3.2 (eek), but I assume there's a compiler version check somewhere (if you're using gcc and it's version is less than X, abort. Ditto for clang.) -- Thanks, ~Nick Desaulniers
Re: [RFC PATCH] compiler.h: give up __compiletime_assert_fallback()
On Sun, Aug 19, 2018 at 1:28 PM Linus Torvalds wrote: > > On Sun, Aug 19, 2018 at 1:25 PM Nick Desaulniers > wrote: > > > > + gbiv who wrote this cool paste (showing alternatives to > > _Static_assert, which is supported by both compilers in -std=gnu89, > > but not until gcc 4.6): https://godbolt.org/g/DuLsxu > > > > I can't help but think that BUILD_BUG_ON_MSG should use > > _Static_assert, then have fallbacks for gcc < 4.6. > > Well, it turns out that we effectively stopped supporting gcc < 4.6 > during this merge window for other reasons, so.. For the whole kernel (or just a particular arch)? Which commit? Do we keep track of minimal versions somewhere? Documentation/process/changes.rst mentions gcc 3.2 (eek), but I assume there's a compiler version check somewhere (if you're using gcc and it's version is less than X, abort. Ditto for clang.) -- Thanks, ~Nick Desaulniers
[PATCH v4 0/2] i2c: npcm7xx: new driver for I2C controller
Nuvoton NPCM7XX I2C Controller NPCM7xx includes 16 I2C controllers. This driver operates the controller. This module also includes a slave mode, which will be submitted later on. --- v4 -> v3: - typo on cover letter. v3 -> v2: - fix dt binding: compatible name: omit "bus" v2 -> v1: - run check patch in strict mode. - use linux crc. - define regs in constant offset without base. - remove debug prints. - no declarations for local functions. v1: initial version Signed-off-by: Tali Perry Reviewed-by: Rob Herring --- Tali Perry (2): dt-bindings: i2c: npcm7xx: add binding for i2c controller i2c: npcm7xx: add i2c controller master mode only .../devicetree/bindings/i2c/i2c-npcm7xx.txt| 29 + drivers/i2c/busses/Kconfig | 11 + drivers/i2c/busses/Makefile|1 + drivers/i2c/busses/i2c-npcm7xx.c | 2017 4 files changed, 2058 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt create mode 100644 drivers/i2c/busses/i2c-npcm7xx.c -- 2.14.1
[PATCH v4 2/2] i2c: npcm7xx: add i2c controller master mode only
Nuvoton NPCM7XX I2C Controller
NPCM7xx includes 16 I2C controllers. This driver operates the controller.
This module also includes a slave mode, which will be submitted later on.
---
v4 -> v3:
- typo on cover letter.
v3 -> v2:
- fix dt binding: compatible name: omit "bus"
v2 -> v1:
- run check patch in strict mode.
- use linux crc.
- define regs in constant offset without base.
- remove debug prints.
- no declarations for local functions.
v1: initial version
Signed-off-by: Tali Perry
Reviewed-by: Rob Herring
---
drivers/i2c/busses/Kconfig | 11 +
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-npcm7xx.c | 2017 ++
3 files changed, 2029 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-npcm7xx.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 4f8df2ec87b1..61862fed71fd 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -742,6 +742,17 @@ config I2C_NOMADIK
I2C interface from ST-Ericsson's Nomadik and Ux500 architectures,
as well as the STA2X11 PCIe I/O HUB.
+config I2C_NPCM7XX
+ tristate "Nuvoton I2C Controller"
+ depends on ARCH_NPCM7XX
+ select CRC8
+ help
+ If you say yes to this option, support will be included for the
+ Nuvoton I2C controller.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-npcm7xx.
+
config I2C_OCORES
tristate "OpenCores I2C Controller"
help
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 5a869144a0c5..80d4ec8908e1 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_I2C_MT65XX) += i2c-mt65xx.o
obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_MXS) += i2c-mxs.o
obj-$(CONFIG_I2C_NOMADIK) += i2c-nomadik.o
+obj-$(CONFIG_I2C_NPCM7XX) += i2c-npcm7xx.o
obj-$(CONFIG_I2C_OCORES) += i2c-ocores.o
obj-$(CONFIG_I2C_OMAP) += i2c-omap.o
obj-$(CONFIG_I2C_PASEMI) += i2c-pasemi.o
diff --git a/drivers/i2c/busses/i2c-npcm7xx.c b/drivers/i2c/busses/i2c-npcm7xx.c
new file mode 100644
index ..4dc766016031
--- /dev/null
+++ b/drivers/i2c/busses/i2c-npcm7xx.c
@@ -0,0 +1,2017 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Nuvoton NPCM7xx SMB Controller driver
+ *
+ * Copyright (C) 2018 Nuvoton Technologies tali.pe...@nuvoton.com
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define I2C_VERSION "0.0.3"
+
+enum smb_mode {
+ SMB_SLAVE = 1,
+ SMB_MASTER
+};
+
+/*
+ * External SMB Interface driver xfer indication values, which indicate status
+ * of the bus.
+ */
+enum smb_state_ind {
+ SMB_NO_STATUS_IND = 0,
+ SMB_SLAVE_RCV_IND = 1,
+ SMB_SLAVE_XMIT_IND = 2,
+ SMB_SLAVE_XMIT_MISSING_DATA_IND = 3,
+ SMB_SLAVE_RESTART_IND = 4,
+ SMB_SLAVE_DONE_IND = 5,
+ SMB_MASTER_DONE_IND = 6,
+ SMB_NO_DATA_IND = 7,
+ SMB_NACK_IND = 8,
+ SMB_BUS_ERR_IND = 9,
+ SMB_WAKE_UP_IND = 10,
+ SMB_MASTER_PEC_ERR_IND = 11,
+ SMB_BLOCK_BYTES_ERR_IND = 12,
+ SMB_SLAVE_PEC_ERR_IND = 13,
+ SMB_SLAVE_RCV_MISSING_DATA_IND = 14,
+};
+
+// SMBus Operation type values
+enum smb_oper {
+ SMB_NO_OPER = 0,
+ SMB_WRITE_OPER = 1,
+ SMB_READ_OPER = 2
+};
+
+// SMBus Bank (FIFO mode)
+enum smb_bank {
+ SMB_BANK_0 = 0,
+ SMB_BANK_1 = 1
+};
+
+// Internal SMB states values (for the SMB module state machine).
+enum smb_state {
+ SMB_DISABLE = 0,
+ SMB_IDLE,
+ SMB_MASTER_START,
+ SMB_SLAVE_MATCH,
+ SMB_OPER_STARTED,
+ SMB_REPEATED_START,
+ SMB_STOP_PENDING
+};
+
+// Module supports setting multiple own slave addresses:
+enum smb_addr {
+ SMB_SLAVE_ADDR1 = 0,
+ SMB_SLAVE_ADDR2,
+ SMB_SLAVE_ADDR3,
+ SMB_SLAVE_ADDR4,
+ SMB_SLAVE_ADDR5,
+ SMB_SLAVE_ADDR6,
+ SMB_SLAVE_ADDR7,
+ SMB_SLAVE_ADDR8,
+ SMB_SLAVE_ADDR9,
+ SMB_SLAVE_ADDR10,
+ SMB_GC_ADDR,
+ SMB_ARP_ADDR
+};
+
+// global regs
+static struct regmap *gcr_regmap;
+static struct regmap *clk_regmap;
+
+#define NPCM_I2CSEGCTL 0xE4
+#define NPCM_SECCNT0x68
+#define NPCM_CNTR25M 0x6C
+#define I2CSEGCTL_VAL 0x0333F000
+
+// Common regs
+#define NPCM_SMBSDA0x000
+#define NPCM_SMBST 0x002
+#define NPCM_SMBCST0x004
+#define NPCM_SMBCTL1 0x006
+#define NPCM_SMBADDR1 0x008
+#define NPCM_SMBCTL2 0x00A
+#define NPCM_SMBADDR2 0x00C
+#define NPCM_SMBCTL3 0x00E
+#define NPCM_SMBCST2 0x018
+#define NPCM_SMBCST3
[PATCH v4 1/2] dt-bindings: i2c: npcm7xx: add binding for i2c controller
Nuvoton NPCM7XX I2C Controller
NPCM7xx includes 16 I2C controllers. This driver operates the controller.
This module also includes a slave mode, which will be submitted later on.
---
v4 -> v3:
- typo on cover letter.
v3 -> v2:
- fix dt binding: compatible name: omit "bus"
v2 -> v1:
- run check patch in strict mode.
- use linux crc.
- define regs in constant offset without base.
- remove debug prints.
- no declarations for local functions.
v1: initial version
Signed-off-by: Tali Perry
Reviewed-by: Rob Herring
---
.../devicetree/bindings/i2c/i2c-npcm7xx.txt| 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt
b/Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt
new file mode 100644
index ..0ecae950748b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt
@@ -0,0 +1,29 @@
+Nuvoton NPCM7XX I2C bus
+
+The NPCM750x includes sixteen I2C bus controllers. All Controllers support
+both master and slave mode. Each controller has two 16 byte HW FIFO for TX and
+RX.
+
+Required properties:
+- compatible : must be "nuvoton,npcm750-i2c"
+- reg : Offset and length of the register set for the device.
+- interrupts : Contain the I2C interrupt with flags for falling edge.
+- clocks : phandle of I2C reference clock.
+
+Optional:
+- bus-frequency : Contain the I2C bus frequency,
+ the default I2C bus frequency is 10.
+- pinctrl-0 : must be <_pins>, X is module number
+ (on NPCM7XX it's 0 to 15)
+- pinctrl-names : should be set to "default"
+Example:
+
+ i2c0: i2c@8 {
+ compatible = "nuvoton,npcm750-i2c";
+ reg = <0x8 0x1000>;
+ clocks = < NPCM7XX_CLK_APB2>;
+ bus-frequency = <10>;
+ interrupts = ;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ };
--
2.14.1
[PATCH v4 0/2] i2c: npcm7xx: new driver for I2C controller
Nuvoton NPCM7XX I2C Controller NPCM7xx includes 16 I2C controllers. This driver operates the controller. This module also includes a slave mode, which will be submitted later on. --- v4 -> v3: - typo on cover letter. v3 -> v2: - fix dt binding: compatible name: omit "bus" v2 -> v1: - run check patch in strict mode. - use linux crc. - define regs in constant offset without base. - remove debug prints. - no declarations for local functions. v1: initial version Signed-off-by: Tali Perry Reviewed-by: Rob Herring --- Tali Perry (2): dt-bindings: i2c: npcm7xx: add binding for i2c controller i2c: npcm7xx: add i2c controller master mode only .../devicetree/bindings/i2c/i2c-npcm7xx.txt| 29 + drivers/i2c/busses/Kconfig | 11 + drivers/i2c/busses/Makefile|1 + drivers/i2c/busses/i2c-npcm7xx.c | 2017 4 files changed, 2058 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt create mode 100644 drivers/i2c/busses/i2c-npcm7xx.c -- 2.14.1
[PATCH v4 2/2] i2c: npcm7xx: add i2c controller master mode only
Nuvoton NPCM7XX I2C Controller
NPCM7xx includes 16 I2C controllers. This driver operates the controller.
This module also includes a slave mode, which will be submitted later on.
---
v4 -> v3:
- typo on cover letter.
v3 -> v2:
- fix dt binding: compatible name: omit "bus"
v2 -> v1:
- run check patch in strict mode.
- use linux crc.
- define regs in constant offset without base.
- remove debug prints.
- no declarations for local functions.
v1: initial version
Signed-off-by: Tali Perry
Reviewed-by: Rob Herring
---
drivers/i2c/busses/Kconfig | 11 +
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-npcm7xx.c | 2017 ++
3 files changed, 2029 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-npcm7xx.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 4f8df2ec87b1..61862fed71fd 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -742,6 +742,17 @@ config I2C_NOMADIK
I2C interface from ST-Ericsson's Nomadik and Ux500 architectures,
as well as the STA2X11 PCIe I/O HUB.
+config I2C_NPCM7XX
+ tristate "Nuvoton I2C Controller"
+ depends on ARCH_NPCM7XX
+ select CRC8
+ help
+ If you say yes to this option, support will be included for the
+ Nuvoton I2C controller.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-npcm7xx.
+
config I2C_OCORES
tristate "OpenCores I2C Controller"
help
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 5a869144a0c5..80d4ec8908e1 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_I2C_MT65XX) += i2c-mt65xx.o
obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_MXS) += i2c-mxs.o
obj-$(CONFIG_I2C_NOMADIK) += i2c-nomadik.o
+obj-$(CONFIG_I2C_NPCM7XX) += i2c-npcm7xx.o
obj-$(CONFIG_I2C_OCORES) += i2c-ocores.o
obj-$(CONFIG_I2C_OMAP) += i2c-omap.o
obj-$(CONFIG_I2C_PASEMI) += i2c-pasemi.o
diff --git a/drivers/i2c/busses/i2c-npcm7xx.c b/drivers/i2c/busses/i2c-npcm7xx.c
new file mode 100644
index ..4dc766016031
--- /dev/null
+++ b/drivers/i2c/busses/i2c-npcm7xx.c
@@ -0,0 +1,2017 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Nuvoton NPCM7xx SMB Controller driver
+ *
+ * Copyright (C) 2018 Nuvoton Technologies tali.pe...@nuvoton.com
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define I2C_VERSION "0.0.3"
+
+enum smb_mode {
+ SMB_SLAVE = 1,
+ SMB_MASTER
+};
+
+/*
+ * External SMB Interface driver xfer indication values, which indicate status
+ * of the bus.
+ */
+enum smb_state_ind {
+ SMB_NO_STATUS_IND = 0,
+ SMB_SLAVE_RCV_IND = 1,
+ SMB_SLAVE_XMIT_IND = 2,
+ SMB_SLAVE_XMIT_MISSING_DATA_IND = 3,
+ SMB_SLAVE_RESTART_IND = 4,
+ SMB_SLAVE_DONE_IND = 5,
+ SMB_MASTER_DONE_IND = 6,
+ SMB_NO_DATA_IND = 7,
+ SMB_NACK_IND = 8,
+ SMB_BUS_ERR_IND = 9,
+ SMB_WAKE_UP_IND = 10,
+ SMB_MASTER_PEC_ERR_IND = 11,
+ SMB_BLOCK_BYTES_ERR_IND = 12,
+ SMB_SLAVE_PEC_ERR_IND = 13,
+ SMB_SLAVE_RCV_MISSING_DATA_IND = 14,
+};
+
+// SMBus Operation type values
+enum smb_oper {
+ SMB_NO_OPER = 0,
+ SMB_WRITE_OPER = 1,
+ SMB_READ_OPER = 2
+};
+
+// SMBus Bank (FIFO mode)
+enum smb_bank {
+ SMB_BANK_0 = 0,
+ SMB_BANK_1 = 1
+};
+
+// Internal SMB states values (for the SMB module state machine).
+enum smb_state {
+ SMB_DISABLE = 0,
+ SMB_IDLE,
+ SMB_MASTER_START,
+ SMB_SLAVE_MATCH,
+ SMB_OPER_STARTED,
+ SMB_REPEATED_START,
+ SMB_STOP_PENDING
+};
+
+// Module supports setting multiple own slave addresses:
+enum smb_addr {
+ SMB_SLAVE_ADDR1 = 0,
+ SMB_SLAVE_ADDR2,
+ SMB_SLAVE_ADDR3,
+ SMB_SLAVE_ADDR4,
+ SMB_SLAVE_ADDR5,
+ SMB_SLAVE_ADDR6,
+ SMB_SLAVE_ADDR7,
+ SMB_SLAVE_ADDR8,
+ SMB_SLAVE_ADDR9,
+ SMB_SLAVE_ADDR10,
+ SMB_GC_ADDR,
+ SMB_ARP_ADDR
+};
+
+// global regs
+static struct regmap *gcr_regmap;
+static struct regmap *clk_regmap;
+
+#define NPCM_I2CSEGCTL 0xE4
+#define NPCM_SECCNT0x68
+#define NPCM_CNTR25M 0x6C
+#define I2CSEGCTL_VAL 0x0333F000
+
+// Common regs
+#define NPCM_SMBSDA0x000
+#define NPCM_SMBST 0x002
+#define NPCM_SMBCST0x004
+#define NPCM_SMBCTL1 0x006
+#define NPCM_SMBADDR1 0x008
+#define NPCM_SMBCTL2 0x00A
+#define NPCM_SMBADDR2 0x00C
+#define NPCM_SMBCTL3 0x00E
+#define NPCM_SMBCST2 0x018
+#define NPCM_SMBCST3
[PATCH v4 1/2] dt-bindings: i2c: npcm7xx: add binding for i2c controller
Nuvoton NPCM7XX I2C Controller
NPCM7xx includes 16 I2C controllers. This driver operates the controller.
This module also includes a slave mode, which will be submitted later on.
---
v4 -> v3:
- typo on cover letter.
v3 -> v2:
- fix dt binding: compatible name: omit "bus"
v2 -> v1:
- run check patch in strict mode.
- use linux crc.
- define regs in constant offset without base.
- remove debug prints.
- no declarations for local functions.
v1: initial version
Signed-off-by: Tali Perry
Reviewed-by: Rob Herring
---
.../devicetree/bindings/i2c/i2c-npcm7xx.txt| 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt
b/Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt
new file mode 100644
index ..0ecae950748b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt
@@ -0,0 +1,29 @@
+Nuvoton NPCM7XX I2C bus
+
+The NPCM750x includes sixteen I2C bus controllers. All Controllers support
+both master and slave mode. Each controller has two 16 byte HW FIFO for TX and
+RX.
+
+Required properties:
+- compatible : must be "nuvoton,npcm750-i2c"
+- reg : Offset and length of the register set for the device.
+- interrupts : Contain the I2C interrupt with flags for falling edge.
+- clocks : phandle of I2C reference clock.
+
+Optional:
+- bus-frequency : Contain the I2C bus frequency,
+ the default I2C bus frequency is 10.
+- pinctrl-0 : must be <_pins>, X is module number
+ (on NPCM7XX it's 0 to 15)
+- pinctrl-names : should be set to "default"
+Example:
+
+ i2c0: i2c@8 {
+ compatible = "nuvoton,npcm750-i2c";
+ reg = <0x8 0x1000>;
+ clocks = < NPCM7XX_CLK_APB2>;
+ bus-frequency = <10>;
+ interrupts = ;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ };
--
2.14.1
