[PATCH] memstick: fix a potential NULL pointer dereference

2019-03-08 Thread Kangjie Lu
In case alloc_ordered_workqueue fails, the fix returns ENOMEM to
avoid potential NULL pointer dereference.

Signed-off-by: Kangjie Lu 
---
 drivers/memstick/core/ms_block.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/memstick/core/ms_block.c b/drivers/memstick/core/ms_block.c
index 82daccc9ea62..8e00de414567 100644
--- a/drivers/memstick/core/ms_block.c
+++ b/drivers/memstick/core/ms_block.c
@@ -2149,6 +2149,11 @@ static int msb_init_disk(struct memstick_dev *card)
 
msb->usage_count = 1;
msb->io_queue = alloc_ordered_workqueue("ms_block", WQ_MEM_RECLAIM);
+   if (!msb->io_queue) {
+   rc = -ENOMEM;
+   goto out_put_disk;
+   }
+
INIT_WORK(>io_work, msb_io_work);
sg_init_table(msb->prealloc_sg, MS_BLOCK_MAX_SEGS+1);
 
-- 
2.17.1



Re: [PATCH v4 07/15] perf tools report: Use less for scripts output

2019-03-08 Thread Feng Tang
On Fri, Mar 08, 2019 at 10:47:54AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Mar 05, 2019 at 06:47:50AM -0800, Andi Kleen escreveu:
> > From: Andi Kleen 
> > 
> > The UI viewer for scripts output has a lot of limitations: limited size,
> > no search or save function, slow, and various other issues.
> > 
> > Just use 'less' to display directly on the terminal instead.
> 
> I'm ok with this, CCing Feng tho since he contributed this browser, to
> let him know.

Thanks for the note!

> 
> - Arnaldo
>  
> > This won't work in gtk mode, but gtk doesn't support these
> > context menus anyways. If that is ever done could use an terminal
> > for the output.
> > 
> > Signed-off-by: Andi Kleen 
> > 

Looks good to me.

Acked-by: Feng Tang 

Thanks,
Feng



[PATCH] media: usbvision: fix a potential NULL pointer dereference

2019-03-08 Thread Kangjie Lu
In case usb_alloc_coherent fails, the fix returns -ENOMEM to
avoid a potential NULL pointer dereference.

Signed-off-by: Kangjie Lu 
---
 drivers/media/usb/usbvision/usbvision-core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/usb/usbvision/usbvision-core.c 
b/drivers/media/usb/usbvision/usbvision-core.c
index 31e0e98d6daf..1b0d0a0f0e87 100644
--- a/drivers/media/usb/usbvision/usbvision-core.c
+++ b/drivers/media/usb/usbvision/usbvision-core.c
@@ -2302,6 +2302,9 @@ int usbvision_init_isoc(struct usb_usbvision *usbvision)
   sb_size,
   GFP_KERNEL,
   >transfer_dma);
+   if (!usbvision->sbuf[buf_idx].data)
+   return -ENOMEM;
+
urb->dev = dev;
urb->context = usbvision;
urb->pipe = usb_rcvisocpipe(dev, usbvision->video_endp);
-- 
2.17.1



general protection fault in ipv6_rcv

2019-03-08 Thread syzbot

Hello,

syzbot found the following crash on:

HEAD commit:d9862cfb Merge tag 'mips_5.1' of git://git.kernel.org/pub/..
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15d1e5ad20
kernel config:  https://syzkaller.appspot.com/x/.config?x=73d88a42238825ad
dashboard link: https://syzkaller.appspot.com/bug?extid=6c54e67cc0b0c896aa4b
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
userspace arch: amd64

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+6c54e67cc0b0c896a...@syzkaller.appspotmail.com

netlink: 3 bytes leftover after parsing attributes in process  
`syz-executor.3'.

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
Enabling of bearer <::�> rejected, illegal name
general protection fault:  [#1] PREEMPT SMP KASAN
CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.0.0+ #97
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:__x86_indirect_thunk_rax+0x10/0x20 arch/x86/lib/retpoline.S:32
netlink: 3 bytes leftover after parsing attributes in process  
`syz-executor.3'.
Code: c4 ff 48 8d 0c ca e9 bd 42 c4 ff bb f2 ff ff ff 45 30 ff e9 63 47 c4  
ff 90 90 e8 07 00 00 00 f3 90 0f ae e8 eb f9 48 89 04 24  0f 1f 44 00  
00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3

RSP: 0018:8880aa2c7a20 EFLAGS: 00010246
RAX: 8607 RBX: 888096e276ca RCX: 8607ee22
RDX: 111012dc4ede RSI: 8607edc8 RDI: 88806509fd40
RBP: 8880aa2c7a58 R08: 8880aa2b2440 R09: ed1015d25bd0
R10: ed1015d25bcf R11: 8880ae92de7b R12: 88806509fd40
R13: 0001 R14: 88806509fd98 R15: 
FS:  () GS:8880ae90() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fed7c51a518 CR3: 4654c000 CR4: 001406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 NF_HOOK include/linux/netfilter.h:289 [inline]
 NF_HOOK include/linux/netfilter.h:283 [inline]
 ipv6_rcv+0x10e/0x420 net/ipv6/ip6_input.c:272
 __netif_receive_skb_one_core+0x115/0x1a0 net/core/dev.c:4973
 __netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5083
 process_backlog+0x206/0x750 net/core/dev.c:5923
 napi_poll net/core/dev.c:6346 [inline]
 net_rx_action+0x4fa/0x1070 net/core/dev.c:6412
 __do_softirq+0x266/0x95a kernel/softirq.c:292
 run_ksoftirqd kernel/softirq.c:654 [inline]
 run_ksoftirqd+0x8e/0x110 kernel/softirq.c:646
 smpboot_thread_fn+0x6ab/0xa10 kernel/smpboot.c:164
 kthread+0x357/0x430 kernel/kthread.c:246
 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace 1ebaef9e8c3600e4 ]---
RIP: 0010:__x86_indirect_thunk_rax+0x10/0x20 arch/x86/lib/retpoline.S:32
Code: c4 ff 48 8d 0c ca e9 bd 42 c4 ff bb f2 ff ff ff 45 30 ff e9 63 47 c4  
ff 90 90 e8 07 00 00 00 f3 90 0f ae e8 eb f9 48 89 04 24  0f 1f 44 00  
00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3

Enabling of bearer <::�> rejected, illegal name
RSP: 0018:8880aa2c7a20 EFLAGS: 00010246
RAX: 8607 RBX: 888096e276ca RCX: 8607ee22
RDX: 111012dc4ede RSI: 8607edc8 RDI: 88806509fd40
RBP: 8880aa2c7a58 R08: 8880aa2b2440 R09: ed1015d25bd0
R10: ed1015d25bcf R11: 8880ae92de7b R12: 88806509fd40
R13: 0001 R14: 88806509fd98 R15: 
FS:  () GS:8880ae90() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fed7c51a518 CR3: 4654c000 CR4: 001406e0
DR0:  DR1:  DR2: 
kobject: 'loop0' (152428b3): kobject_uevent_env
DR3:  DR6: fffe0ff0 DR7: 0400


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.


Re: [PATCH 5.0 00/46] 5.0.1-stable review

2019-03-08 Thread Greg Kroah-Hartman
On Sat, Mar 09, 2019 at 12:40:51PM +0530, Naresh Kamboju wrote:
> On Fri, 8 Mar 2019 at 18:23, Greg Kroah-Hartman
>  wrote:
> >
> > This is the start of the stable review cycle for the 5.0.1 release.
> > There are 46 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Mar 10 12:48:36 UTC 2019.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.0.1-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-5.0.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

Great, thanks for testing all of these and letting me know.

greg k-h


Re: [PATCH v5] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used

2019-03-08 Thread Greg KH
On Fri, Mar 08, 2019 at 05:46:11PM -0500, Kimberly Brown wrote:
>  static struct kobj_type vmbus_chan_ktype = {
>   .sysfs_ops = _chan_sysfs_ops,
>   .release = vmbus_chan_release,
> - .default_attrs = vmbus_chan_attrs,

As discussed on IRC, a kobj_type needs to get an attribute group one of
these days, not just a attribute list :)

So thanks for persisting with this, sorry for the earlier review
comments, you were totally right about this, nice work.

Minor review comments below:

>  };
>  
>  /*
> @@ -1571,11 +1624,34 @@ int vmbus_add_channel_kobj(struct hv_device *dev, 
> struct vmbus_channel *channel)
>   if (ret)
>   return ret;
>  
> + ret = sysfs_create_group(kobj, _chan_group);
> + channel->sysfs_group_ready = !ret;

Why do you need this flag?

> +
> + if (ret) {
> + /*
> +  * If an error is returned to the calling functions, those
> +  * functions will call kobject_put() on the channel kobject,
> +  * which will cleanup the empty channel directory created by
> +  * kobject_init_and_add().

Why is this comment needed?

> +  */
> + pr_err("Unable to set up channel sysfs files\n");

dev_err() to show who had the problem with the files?

> + return ret;
> + }
> +
>   kobject_uevent(kobj, KOBJ_ADD);
>  
>   return 0;
>  }
>  
> +/*
> + * vmbus_remove_channel_attr_group - remove the channel's attribute group
> + */
> +void vmbus_remove_channel_attr_group(struct vmbus_channel *channel)
> +{
> + if (channel->sysfs_group_ready)
> + sysfs_remove_group(>kobj, _chan_group);

You should be able to just always remove these, no need for a flag to
say you have created them or not, right?

thanks,

greg k-h


[PATCH] media: video-mux: fix null pointer dereferences

2019-03-08 Thread Kangjie Lu
devm_kcalloc may fail and return a null pointer. The fix returns
-ENOMEM upon failures to avoid null pointer dereferences.

Signed-off-by: Kangjie Lu 
---
 drivers/media/platform/video-mux.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/video-mux.c 
b/drivers/media/platform/video-mux.c
index c33900e3c23e..4135165cdabe 100644
--- a/drivers/media/platform/video-mux.c
+++ b/drivers/media/platform/video-mux.c
@@ -399,9 +399,14 @@ static int video_mux_probe(struct platform_device *pdev)
vmux->active = -1;
vmux->pads = devm_kcalloc(dev, num_pads, sizeof(*vmux->pads),
  GFP_KERNEL);
+   if (!vmux->pads)
+   return -ENOMEM;
+
vmux->format_mbus = devm_kcalloc(dev, num_pads,
 sizeof(*vmux->format_mbus),
 GFP_KERNEL);
+   if (!vmux->format_mbus)
+   return -ENOMEM;
 
for (i = 0; i < num_pads; i++) {
vmux->pads[i].flags = (i < num_pads - 1) ? MEDIA_PAD_FL_SINK
-- 
2.17.1



RE: [PATCH] virtio_pci: fix a NULL pointer reference in vp_del_vqs

2019-03-08 Thread Gonglei (Arei)



> -Original Message-
> From: longpeng
> Sent: Saturday, March 09, 2019 3:18 PM
> To: m...@redhat.com; jasow...@redhat.com
> Cc: virtualizat...@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> longpeng ; Gonglei (Arei)
> 
> Subject: [PATCH] virtio_pci: fix a NULL pointer reference in vp_del_vqs
> 
> From: Longpeng 
> 
> If the msix_affinity_masks is alloced failed, then we'll
> try to free some resources in vp_free_vectors() that may
> access it directly.
> 
> We met the following stack in our production:
> [   29.296767] BUG: unable to handle kernel NULL pointer dereference at
> (null)
> [   29.311151] IP: [] vp_free_vectors+0x6a/0x150 
> [virtio_pci]
> [   29.324787] PGD 0
> [   29.333224] Oops:  [#1] SMP
> [...]
> [   29.425175] RIP: 0010:[]  []
> vp_free_vectors+0x6a/0x150 [virtio_pci]
> [   29.441405] RSP: 0018:9a55c2dcfa10  EFLAGS: 00010206
> [   29.453491] RAX:  RBX: 9a55c322c400 RCX:
> 
> [   29.467488] RDX:  RSI:  RDI:
> 9a55c322c400
> [   29.481461] RBP: 9a55c2dcfa20 R08:  R09:
> c1b6806ff020
> [   29.495427] R10: 0e95 R11: 00aa R12:
> 
> [   29.509414] R13: 0001 R14: 9a55bd2d9e98 R15:
> 9a55c322c400
> [   29.523407] FS:  7fdcba69f8c0() GS:9a55c284()
> knlGS:
> [   29.538472] CS:  0010 DS:  ES:  CR0: 80050033
> [   29.551621] CR2:  CR3: 3ce52000 CR4:
> 003607a0
> [   29.565886] DR0:  DR1:  DR2:
> 
> [   29.580055] DR3:  DR6: fffe0ff0 DR7:
> 0400
> [   29.594122] Call Trace:
> [   29.603446]  [] vp_request_msix_vectors+0xe2/0x260
> [virtio_pci]
> [   29.618017]  [] vp_try_to_find_vqs+0x95/0x3b0
> [virtio_pci]
> [   29.632152]  [] vp_find_vqs+0x37/0xb0 [virtio_pci]
> [   29.645582]  [] init_vq+0x153/0x260 [virtio_blk]
> [   29.658831]  [] virtblk_probe+0xe8/0x87f [virtio_blk]
> [...]
> 
> Cc: Gonglei 
> Signed-off-by: Longpeng 
> ---
>  drivers/virtio/virtio_pci_common.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 

Reviewed-by: Gonglei 

Thanks,
-Gonglei

> diff --git a/drivers/virtio/virtio_pci_common.c
> b/drivers/virtio/virtio_pci_common.c
> index d0584c0..7a0398b 100644
> --- a/drivers/virtio/virtio_pci_common.c
> +++ b/drivers/virtio/virtio_pci_common.c
> @@ -255,9 +255,11 @@ void vp_del_vqs(struct virtio_device *vdev)
>   for (i = 0; i < vp_dev->msix_used_vectors; ++i)
>   free_irq(pci_irq_vector(vp_dev->pci_dev, i), vp_dev);
> 
> - for (i = 0; i < vp_dev->msix_vectors; i++)
> - if (vp_dev->msix_affinity_masks[i])
> - free_cpumask_var(vp_dev->msix_affinity_masks[i]);
> + if (vp_dev->msix_affinity_masks) {
> + for (i = 0; i < vp_dev->msix_vectors; i++)
> + if (vp_dev->msix_affinity_masks[i])
> + 
> free_cpumask_var(vp_dev->msix_affinity_masks[i]);
> + }
> 
>   if (vp_dev->msix_enabled) {
>   /* Disable the vector used for configuration */
> --
> 1.8.3.1
> 



Re: [PATCH] net: stmmac: Avoid one more sometimes uninitialized Clang warning

2019-03-08 Thread David Miller
From: Nathan Chancellor 
Date: Thu,  7 Mar 2019 21:02:39 -0700

> When building with -Wsometimes-uninitialized, Clang warns:
> 
> drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c:111:2: error: variable
> 'ns' is used uninitialized whenever 'if' condition is false
> [-Werror,-Wsometimes-uninitialized]
> drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c:111:2: error: variable
> 'ns' is used uninitialized whenever '&&' condition is false
> [-Werror,-Wsometimes-uninitialized]
> 
> Clang is concerned with the use of stmmac_do_void_callback (which
> stmmac_get_systime wraps), as it may fail to initialize these values if
> the if condition was ever false (meaning the callback doesn't exist).
> It's not wrong because the callback is what initializes ns. While it's
> unlikely that the callback is going to disappear at some point and make
> that condition false, we can easily avoid this warning by zero
> initializing the variable.
> 
> Link: https://github.com/ClangBuiltLinux/linux/issues/384
> Fixes: df103170854e ("net: stmmac: Avoid sometimes uninitialized Clang 
> warnings")
> Suggested-by: Nick Desaulniers 
> Signed-off-by: Nathan Chancellor 

Applied, thanks Nathan.


[PATCH] virtio_pci: fix a NULL pointer reference in vp_del_vqs

2019-03-08 Thread Longpeng(Mike)
From: Longpeng 

If the msix_affinity_masks is alloced failed, then we'll
try to free some resources in vp_free_vectors() that may
access it directly.

We met the following stack in our production:
[   29.296767] BUG: unable to handle kernel NULL pointer dereference at  (null)
[   29.311151] IP: [] vp_free_vectors+0x6a/0x150 [virtio_pci]
[   29.324787] PGD 0
[   29.333224] Oops:  [#1] SMP
[...]
[   29.425175] RIP: 0010:[]  [] 
vp_free_vectors+0x6a/0x150 [virtio_pci]
[   29.441405] RSP: 0018:9a55c2dcfa10  EFLAGS: 00010206
[   29.453491] RAX:  RBX: 9a55c322c400 RCX: 
[   29.467488] RDX:  RSI:  RDI: 9a55c322c400
[   29.481461] RBP: 9a55c2dcfa20 R08:  R09: c1b6806ff020
[   29.495427] R10: 0e95 R11: 00aa R12: 
[   29.509414] R13: 0001 R14: 9a55bd2d9e98 R15: 9a55c322c400
[   29.523407] FS:  7fdcba69f8c0() GS:9a55c284() 
knlGS:
[   29.538472] CS:  0010 DS:  ES:  CR0: 80050033
[   29.551621] CR2:  CR3: 3ce52000 CR4: 003607a0
[   29.565886] DR0:  DR1:  DR2: 
[   29.580055] DR3:  DR6: fffe0ff0 DR7: 0400
[   29.594122] Call Trace:
[   29.603446]  [] vp_request_msix_vectors+0xe2/0x260 
[virtio_pci]
[   29.618017]  [] vp_try_to_find_vqs+0x95/0x3b0 [virtio_pci]
[   29.632152]  [] vp_find_vqs+0x37/0xb0 [virtio_pci]
[   29.645582]  [] init_vq+0x153/0x260 [virtio_blk]
[   29.658831]  [] virtblk_probe+0xe8/0x87f [virtio_blk]
[...]

Cc: Gonglei 
Signed-off-by: Longpeng 
---
 drivers/virtio/virtio_pci_common.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/virtio/virtio_pci_common.c 
b/drivers/virtio/virtio_pci_common.c
index d0584c0..7a0398b 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -255,9 +255,11 @@ void vp_del_vqs(struct virtio_device *vdev)
for (i = 0; i < vp_dev->msix_used_vectors; ++i)
free_irq(pci_irq_vector(vp_dev->pci_dev, i), vp_dev);
 
-   for (i = 0; i < vp_dev->msix_vectors; i++)
-   if (vp_dev->msix_affinity_masks[i])
-   free_cpumask_var(vp_dev->msix_affinity_masks[i]);
+   if (vp_dev->msix_affinity_masks) {
+   for (i = 0; i < vp_dev->msix_vectors; i++)
+   if (vp_dev->msix_affinity_masks[i])
+   
free_cpumask_var(vp_dev->msix_affinity_masks[i]);
+   }
 
if (vp_dev->msix_enabled) {
/* Disable the vector used for configuration */
-- 
1.8.3.1




Re: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel

2019-03-08 Thread Greg KH
On Fri, Mar 08, 2019 at 06:59:23PM +0100, Geert Uytterhoeven wrote:
> Hi Greg,
> 
> On Fri, Mar 8, 2019 at 6:05 PM Greg KH  wrote:
> > On Fri, Mar 08, 2019 at 05:42:32AM -0800, Joel Fernandes wrote:
> > > On Fri, Mar 8, 2019, 3:53 AM Geert Uytterhoeven  
> > > wrote:
> > > > > It is just so much easier to use tar + xz at build time, and leave the
> > > > > decompression task to the user. After decompression, the files will 
> > > > > live on
> > > > > the disk and the page-cache mechanism will free memory when/if the 
> > > > > files fall
> > > > > off the LRUs.
> > > >
> > > > I'm also considering how generic and extensible the solution is.
> > > > What if people need other build artifacts in the future (e.g. signing 
> > > > key to
> > > > load signed modules)?
> > >
> > > That sounds like it could be useful. I don't see any reason off the
> > > top why that would not be possible to add to the list of archived
> > > files in the future. The patch allows populating the list of files
> > > from Kbuild using ikh_file_list variable.
> >
> > Um, no, you don't want the signing key in the kernel itself, as that
> > totally defeats the purpose of the signing key :)
> 
> In a loadable module?
> He who has the module, can build and sign more modules.

Again, that's pretty foolish.

Signing keys should be kept secure, or better yet, just deleted entirely
after creating and signing with them.  That's what I do for my kernels
and I'm pretty sure that some distros also do this.  That way there's no
chance that someone else can sign a module and have it loaded without
detection, which is what signing is supposed to prevent from happening.

thanks,

greg k-h


[PATCH] media: renesas-ceu: fix a potential NULL pointer dereference

2019-03-08 Thread Kangjie Lu
In case of_match_device cannot find a match, the check returns
-EINVAL to avoid a potential NULL pointer dereference

Signed-off-by: Kangjie Lu 
---
 drivers/media/platform/renesas-ceu.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/renesas-ceu.c 
b/drivers/media/platform/renesas-ceu.c
index 150196f7cf96..4aa807c0b6c7 100644
--- a/drivers/media/platform/renesas-ceu.c
+++ b/drivers/media/platform/renesas-ceu.c
@@ -1682,7 +1682,10 @@ static int ceu_probe(struct platform_device *pdev)
 
if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
ceu_data = of_match_device(ceu_of_match, dev)->data;
-   num_subdevs = ceu_parse_dt(ceudev);
+   if (unlikely(!ceu_data))
+   num_subdevs = -EINVAL;
+   else
+   num_subdevs = ceu_parse_dt(ceudev);
} else if (dev->platform_data) {
/* Assume SH4 if booting with platform data. */
ceu_data = _data_sh4;
-- 
2.17.1



Re: [PATCH 5.0 00/46] 5.0.1-stable review

2019-03-08 Thread Naresh Kamboju
On Fri, 8 Mar 2019 at 18:23, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 5.0.1 release.
> There are 46 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Mar 10 12:48:36 UTC 2019.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.0.1-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.0.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 5.0.1-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.0.y
git commit: be3f50196584696914e058aaa2aa5b06a4662f2a
git describe: v5.0-47-gbe3f50196584
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.0-oe/build/v5.0-47-gbe3f50196584

No regressions (compared to build v5.0-17-g4b26bbfb55b6)

No fixes (compared to build v5.0-17-g4b26bbfb55b6)

Ran 23152 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
---
* boot
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* spectre-meltdown-checker-test
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org


[PATCH] media: rcar-vin: fix a potential NULL pointer dereference

2019-03-08 Thread Kangjie Lu
In case of_match_node cannot find a match, the fix returns
-EINVAL to avoid NULL pointer dereference.

Signed-off-by: Kangjie Lu 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index f0719ce24b97..a058e2023ca8 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -266,6 +266,8 @@ static int rvin_group_init(struct rvin_group *group, struct 
rvin_dev *vin)
 
match = of_match_node(vin->dev->driver->of_match_table,
  vin->dev->of_node);
+   if (unlikely(!match))
+   return -EINVAL;
 
strscpy(mdev->driver_name, KBUILD_MODNAME, sizeof(mdev->driver_name));
strscpy(mdev->model, match->compatible, sizeof(mdev->model));
-- 
2.17.1



[PATCH] media: vpss: fix a potential NULL pointer dereference

2019-03-08 Thread Kangjie Lu
In case ioremap fails, the fix returns -ENOMEM to avoid NULL
pointer dereference.

Signed-off-by: Kangjie Lu 
---
 drivers/media/platform/davinci/vpss.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/davinci/vpss.c 
b/drivers/media/platform/davinci/vpss.c
index 19cf6853411e..f7beed2de9cb 100644
--- a/drivers/media/platform/davinci/vpss.c
+++ b/drivers/media/platform/davinci/vpss.c
@@ -518,6 +518,9 @@ static int __init vpss_init(void)
return -EBUSY;
 
oper_cfg.vpss_regs_base2 = ioremap(VPSS_CLK_CTRL, 4);
+   if (unlikely(!oper_cfg.vpss_regs_base2))
+   return -ENOMEM;
+
writel(VPSS_CLK_CTRL_VENCCLKEN |
 VPSS_CLK_CTRL_DACCLKEN, oper_cfg.vpss_regs_base2);
 
-- 
2.17.1



Re: [PATCH 5.0 00/46] 5.0.1-stable review

2019-03-08 Thread Greg Kroah-Hartman
On Fri, Mar 08, 2019 at 01:58:36PM -0700, shuah wrote:
> On 3/8/19 5:49 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.0.1 release.
> > There are 46 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Mar 10 12:48:36 UTC 2019.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.0.1-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-5.0.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all three of these and letting me know.

greg k-h


Re: [PATCH 4.20 00/76] 4.20.15-stable review

2019-03-08 Thread Naresh Kamboju
On Fri, 8 Mar 2019 at 18:25, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.20.15 release.
> There are 76 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Mar 10 12:48:49 UTC 2019.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.20.15-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.20.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.20.15-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.20.y
git commit: b80b02d1b1651606ab4c202888512583ffcc6bf3
git describe: v4.20.13-166-gb80b02d1b165
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.20-oe/build/v4.20.13-166-gb80b02d1b165


No regressions (compared to build v4.20.13)

No fixes (compared to build v4.20.13)


Ran 20015 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* spectre-meltdown-checker-test
* ltp-fs-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native

-- 
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.19 00/68] 4.19.28-stable review

2019-03-08 Thread Naresh Kamboju
On Fri, 8 Mar 2019 at 18:29, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.19.28 release.
> There are 68 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Mar 10 12:48:45 UTC 2019.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.28-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.19.28-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 838c866ce1705a8e395223329e59c4db2eaf78d8
git describe: v4.19.26-148-g838c866ce170
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.26-148-g838c866ce170


No regressions (compared to build v4.19.26)

No fixes (compared to build v4.19.26)



Ran 21748 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* spectre-meltdown-checker-test
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org


[PATCH] media: rga: fix NULL pointer dereferences

2019-03-08 Thread Kangjie Lu
In case __get_free_pages fails, return -ENOMEM to avoid NULL
pointer dereferences.

Signed-off-by: Kangjie Lu 
---
 drivers/media/platform/rockchip/rga/rga.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/rockchip/rga/rga.c 
b/drivers/media/platform/rockchip/rga/rga.c
index 5c653287185f..d42b214977a9 100644
--- a/drivers/media/platform/rockchip/rga/rga.c
+++ b/drivers/media/platform/rockchip/rga/rga.c
@@ -892,8 +892,13 @@ static int rga_probe(struct platform_device *pdev)
 
rga->src_mmu_pages =
(unsigned int *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 3);
+   if (!rga->src_mmu_pages)
+   return -ENOMEM;
+
rga->dst_mmu_pages =
(unsigned int *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 3);
+   if (!rga->dst_mmu_pages)
+   return -ENOMEM;
 
def_frame.stride = (def_frame.width * def_frame.fmt->depth) >> 3;
def_frame.size = def_frame.stride * def_frame.height;
-- 
2.17.1



[PATCH] media: stv090x: add missed checks for STV090x_WRITE_DEMOD

2019-03-08 Thread Kangjie Lu
Conservatively check return value of STV090x_WRITE_DEMOD in case
it fails.

Signed-off-by: Kangjie Lu 
---
 drivers/media/dvb-frontends/stv090x.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv090x.c 
b/drivers/media/dvb-frontends/stv090x.c
index a0622bb71803..3e2af3969e16 100644
--- a/drivers/media/dvb-frontends/stv090x.c
+++ b/drivers/media/dvb-frontends/stv090x.c
@@ -1446,14 +1446,17 @@ static int stv090x_start_search(struct stv090x_state 
*state)
/* >= Cut 3 */
if (state->srate <= 500) {
/* enlarge the timing bandwidth for Low SR */
-   STV090x_WRITE_DEMOD(state, RTCS2, 0x68);
+   if (STV090x_WRITE_DEMOD(state, RTCS2, 0x68) < 0)
+   goto err;
} else {
/* reduce timing bandwidth for high SR */
-   STV090x_WRITE_DEMOD(state, RTCS2, 0x44);
+   if (STV090x_WRITE_DEMOD(state, RTCS2, 0x44) < 0)
+   goto err;
}
 
/* Set CFR min and max to manual mode */
-   STV090x_WRITE_DEMOD(state, CARCFG, 0x46);
+   if (STV090x_WRITE_DEMOD(state, CARCFG, 0x46) < 0)
+   goto err;
 
if (state->algo == STV090x_WARM_SEARCH) {
/* WARM Start
@@ -2604,7 +2607,8 @@ static enum stv090x_signal_state 
stv090x_get_sig_params(struct stv090x_state *st
 
if (state->algo == STV090x_BLIND_SEARCH) {
tmg = STV090x_READ_DEMOD(state, TMGREG2);
-   STV090x_WRITE_DEMOD(state, SFRSTEP, 0x5c);
+   if (STV090x_WRITE_DEMOD(state, SFRSTEP, 0x5c) < 0)
+   goto err;
while ((i <= 50) && (tmg != 0) && (tmg != 0xff)) {
tmg = STV090x_READ_DEMOD(state, TMGREG2);
msleep(5);
@@ -2910,7 +2914,9 @@ static int stv090x_optimize_track(struct stv090x_state 
*state)
pilots = STV090x_GETFIELD_Px(reg, DEMOD_TYPE_FIELD) & 
0x01;
aclc = stv090x_optimize_carloop(state, modcod, pilots);
if (modcod <= STV090x_QPSK_910) {
-   STV090x_WRITE_DEMOD(state, ACLC2S2Q, aclc);
+   if (STV090x_WRITE_DEMOD(state, ACLC2S2Q, aclc)
+   < 0)
+   goto err;
} else if (modcod <= STV090x_8PSK_910) {
if (STV090x_WRITE_DEMOD(state, ACLC2S2Q, 0x2a) 
< 0)
goto err;
@@ -2972,7 +2978,8 @@ static int stv090x_optimize_track(struct stv090x_state 
*state)
reg = STV090x_READ_DEMOD(state, TMGOBS);
 
if (state->algo == STV090x_BLIND_SEARCH) {
-   STV090x_WRITE_DEMOD(state, SFRSTEP, 0x00);
+   if (STV090x_WRITE_DEMOD(state, SFRSTEP, 0x00) < 0)
+   goto err;
reg = STV090x_READ_DEMOD(state, DMDCFGMD);
STV090x_SETFIELD_Px(reg, SCAN_ENABLE_FIELD, 0x00);
STV090x_SETFIELD_Px(reg, CFR_AUTOSCAN_FIELD, 0x00);
-- 
2.17.1



[PATCH] leds: fix a potential NULL pointer dereference

2019-03-08 Thread Kangjie Lu
In case of_match_device cannot find a match, the fixes returns
-EINVAL to avoid NULL pointer dereference.

Signed-off-by: Kangjie Lu 
---
 drivers/leds/leds-pca9532.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/leds/leds-pca9532.c b/drivers/leds/leds-pca9532.c
index 7fea18b0c15d..4b0335591728 100644
--- a/drivers/leds/leds-pca9532.c
+++ b/drivers/leds/leds-pca9532.c
@@ -513,6 +513,7 @@ static int pca9532_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
int devid;
+   const struct of_device_id *of_id;
struct pca9532_data *data = i2c_get_clientdata(client);
struct pca9532_platform_data *pca9532_pdata =
dev_get_platdata(>dev);
@@ -528,8 +529,11 @@ static int pca9532_probe(struct i2c_client *client,
dev_err(>dev, "no platform data\n");
return -EINVAL;
}
-   devid = (int)(uintptr_t)of_match_device(
-   of_pca9532_leds_match, >dev)->data;
+   of_id = of_match_device(of_pca9532_leds_match,
+   >dev);
+   if (unlikely(!of_id))
+   return -EINVAL;
+   devid = (int)of_id->data;
} else {
devid = id->driver_data;
}
-- 
2.17.1



[PATCH v5 06/15] perf tools report: Support time sort key

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

Add a time sort key to perf report to display samples for
different time quantums separately. This allows easier
analysis of workloads that change over time, and also
will allow looking at the context of samples.

% perf record ...
% perf report --sort time,overhead,symbol --time-quantum 1ms --stdio
...
 0.67%  277061.87300  [.] _dl_start
 0.50%  277061.87300  [.] f1
 0.50%  277061.87300  [.] f2
 0.33%  277061.87300  [.] main
 0.29%  277061.87300  [.] _dl_lookup_symbol_x
 0.29%  277061.87300  [.] dl_main
 0.29%  277061.87300  [.] do_lookup_x
 0.17%  277061.87300  [.] _dl_debug_initialize
 0.17%  277061.87300  [.] _dl_init_paths
 0.08%  277061.87300  [.] check_match
 0.04%  277061.87300  [.] _dl_count_modids
 1.33%  277061.87400  [.] f1
 1.33%  277061.87400  [.] f2
 1.33%  277061.87400  [.] main
 1.17%  277061.87500  [.] main
 1.08%  277061.87500  [.] f1
 1.08%  277061.87500  [.] f2
 1.00%  277061.87600  [.] main
 0.83%  277061.87600  [.] f1
 0.83%  277061.87600  [.] f2
 1.00%  277061.87700  [.] main

Signed-off-by: Andi Kleen 

---
v2:
Use symbol_conf.time_quantum
v3:
Use _PER_NSEC defines
Fix fallback path for zero quantum
---
 tools/perf/Documentation/perf-report.txt |  2 ++
 tools/perf/util/hist.c   | 11 +++
 tools/perf/util/hist.h   |  1 +
 tools/perf/util/sort.c   | 39 
 tools/perf/util/sort.h   |  2 ++
 5 files changed, 55 insertions(+)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index 9ec1702bccdd..546d87221ad8 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -105,6 +105,8 @@ OPTIONS
guest machine
- sample: Number of sample
- period: Raw number of event count of sample
+   - time: Separate the samples by time stamp with the resolution 
specified by
+   --time-quantum (default 100ms). Specify with overhead and before it.
 
By default, comm, dso and symbol keys are used.
(i.e. --sort comm,dso,symbol)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 669f961316f0..08e2b3be4c1b 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static bool hists__filter_entry_by_dso(struct hists *hists,
   struct hist_entry *he);
@@ -192,6 +193,7 @@ void hists__calc_col_len(struct hists *hists, struct 
hist_entry *h)
hists__new_col_len(hists, HISTC_MEM_LVL, 21 + 3);
hists__new_col_len(hists, HISTC_LOCAL_WEIGHT, 12);
hists__new_col_len(hists, HISTC_GLOBAL_WEIGHT, 12);
+   hists__new_col_len(hists, HISTC_TIME, 12);
 
if (h->srcline) {
len = MAX(strlen(h->srcline), strlen(sort_srcline.se_header));
@@ -246,6 +248,14 @@ static void he_stat__add_cpumode_period(struct he_stat 
*he_stat,
}
 }
 
+static long hist_time(unsigned long time)
+{
+   unsigned long time_quantum = symbol_conf.time_quantum;
+   if (time_quantum)
+   return (time / time_quantum) * time_quantum;
+   return time;
+}
+
 static void he_stat__add_period(struct he_stat *he_stat, u64 period,
u64 weight)
 {
@@ -626,6 +636,7 @@ __hists__add_entry(struct hists *hists,
.raw_data = sample->raw_data,
.raw_size = sample->raw_size,
.ops = ops,
+   .time = hist_time(sample->time),
}, *he = hists__findnew_entry(hists, , al, sample_self);
 
if (!hists->has_callchains && he && he->callchain_size != 0)
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 4af27fbab24f..6279eca56409 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -31,6 +31,7 @@ enum hist_filter {
 
 enum hist_column {
HISTC_SYMBOL,
+   HISTC_TIME,
HISTC_DSO,
HISTC_THREAD,
HISTC_COMM,
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index d2299e912e59..bdd30cab51cb 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "sort.h"
 #include "hist.h"
 #include "comm.h"
@@ -15,6 +16,7 @@
 #include 
 #include "mem-events.h"
 #include "annotate.h"
+#include "time-utils.h"
 #include 
 
 regex_tparent_regex;
@@ -654,6 +656,42 @@ struct sort_entry sort_socket = {
.se_width_idx   = HISTC_SOCKET,
 };
 
+/* --sort time */
+
+static int64_t
+sort__time_cmp(struct hist_entry *left, struct hist_entry *right)
+{
+   return right->time - left->time;
+}
+
+static int hist_entry__time_snprintf(struct hist_entry *he, char *bf,
+   size_t size, unsigned int width)
+{
+   unsigned long secs;
+   unsigned long long nsecs;
+   char 

[PATCH v5 11/15] perf tools report: Implement browsing of individual samples

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

Now report can show whole time periods with perf script,
but the user still has to find individual samples of interest
manually.

It would be expensive and complicated to search for the
right samples in the whole perf file. Typically users
only need to look at a small number of samples for useful
analysis.

Also the full scripts tend to show samples of all CPUs and all
threads mixed up, which can be very confusing on larger systems.

Add a new --samples option to save a small random number of samples
per hist entry

Use a reservoir sample technique to select a representatve
number of samples.

Then allow browsing the samples using perf script
as part of the hist entry context menu. This automatically
adds the right filters, so only the thread or cpu of the sample
is displayed. Then we use less' search functionality
to directly jump the to the time stamp of the selected
sample.

It uses different menus for assembler and source display.
Assembler needs xed installed and source needs debuginfo.

Currently it only supports as many samples as fit on
the screen due to some limitations in the slang ui code.

Signed-off-by: Andi Kleen 

---
v2:
Free names on error path
Pass --inline and --show-*-event to child perf as needed.
v3:
Don't use num_res to keep track of total samples
Don't pass -1 cpus to perf script.
Don't pass extra event option with tid filtering.
Fix sampling bug.
v4:
Add perfconfig option for context
Use _PER_NSEC defines
---
 tools/perf/Documentation/perf-config.txt |  6 ++
 tools/perf/Documentation/perf-report.txt |  4 +
 tools/perf/builtin-report.c  |  2 +
 tools/perf/ui/browsers/Build |  1 +
 tools/perf/ui/browsers/hists.c   | 47 
 tools/perf/ui/browsers/res_sample.c  | 95 
 tools/perf/ui/browsers/scripts.c |  2 +-
 tools/perf/util/hist.c   | 36 +
 tools/perf/util/hist.h   | 22 ++
 tools/perf/util/sort.h   |  8 ++
 tools/perf/util/symbol.c |  1 +
 tools/perf/util/symbol_conf.h|  1 +
 12 files changed, 224 insertions(+), 1 deletion(-)
 create mode 100644 tools/perf/ui/browsers/res_sample.c

diff --git a/tools/perf/Documentation/perf-config.txt 
b/tools/perf/Documentation/perf-config.txt
index 86f3dcc15f83..2d0fb7613134 100644
--- a/tools/perf/Documentation/perf-config.txt
+++ b/tools/perf/Documentation/perf-config.txt
@@ -584,6 +584,12 @@ llvm.*::
llvm.opts::
Options passed to llc.
 
+samples.*::
+
+   samples.context::
+   Define how many ns worth of time to show
+   around samples in perf report sample context browser.
+
 SEE ALSO
 
 linkperf:perf[1]
diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index 546d87221ad8..f441baa794ce 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -461,6 +461,10 @@ include::itrace.txt[]
 --socket-filter::
Only report the samples on the processor socket that match with this 
filter
 
+--samples=N::
+   Save N individual samples for each histogram entry to show context in 
perf
+   report tui browser.
+
 --raw-trace::
When displaying traceevent output, do not use print fmt or plugins.
 
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 46bd80363c90..9c57c0ccd673 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -1159,6 +1159,8 @@ int cmd_report(int argc, const char **argv)
OPT_BOOLEAN(0, "demangle-kernel", _conf.demangle_kernel,
"Enable kernel symbol demangling"),
OPT_BOOLEAN(0, "mem-mode", _mode, "mem access profile"),
+   OPT_INTEGER(0, "samples", _conf.res_sample,
+   "Number of samples to save per histogram entry for 
individual browsing"),
OPT_CALLBACK(0, "percent-limit", , "percent",
 "Don't show entries under that percent", 
parse_percent_limit),
OPT_CALLBACK(0, "percentage", NULL, "relative|absolute",
diff --git a/tools/perf/ui/browsers/Build b/tools/perf/ui/browsers/Build
index 8fee56b46502..fdf86f7981ca 100644
--- a/tools/perf/ui/browsers/Build
+++ b/tools/perf/ui/browsers/Build
@@ -3,6 +3,7 @@ perf-y += hists.o
 perf-y += map.o
 perf-y += scripts.o
 perf-y += header.o
+perf-y += res_sample.o
 
 CFLAGS_annotate.o += -DENABLE_SLFUTURE_CONST
 CFLAGS_hists.o+= -DENABLE_SLFUTURE_CONST
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index fb4430f8982c..3421ecbdd3f0 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1226,6 +1226,8 @@ void hist_browser__init_hpp(void)
hist_browser__hpp_color_overhead_guest_us;
perf_hpp__format[PERF_HPP__OVERHEAD_ACC].color =
hist_browser__hpp_color_overhead_acc;
+
+   

[PATCH v5 02/15] perf tools script: Support insn output for normal samples

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

perf script -F +insn was only working for PT traces because
the PT instruction decoder was filling in the insn/insn_len
sample attributes. Support it for non PT samples too on x86
using the existing x86 instruction decoder.

This adds some extra checking to ensure that we don't try
to decode instructions when using perf.data from a different
architecture.

% perf record -a sleep 1
% perf script -F ip,sym,insn --xed
 811704c9 remote_function   movl  %eax, 0x18(%rbx)
 8100bb50 intel_bts_enable_localretq
 81048612 native_apic_mem_write movl  %esi, 
-0xa04000(%rdi)
 81048612 native_apic_mem_write movl  %esi, 
-0xa04000(%rdi)
 81048612 native_apic_mem_write movl  %esi, 
-0xa04000(%rdi)
 810f1f79 generic_exec_single   xor %eax, %eax
 811704c9 remote_function   movl  %eax, 0x18(%rbx)
 8100bb34 intel_bts_enable_localmovl  0x2000(%rax), %edx
 81048610 native_apic_mem_write mov %edi, %edi
...

Signed-off-by: Andi Kleen 

---
v2:
Avoid printing instruction when empty
Only decode when perf.data file was collected on same architecture
---
 tools/perf/arch/x86/util/Build  |  1 +
 tools/perf/arch/x86/util/archinsn.c | 28 
 tools/perf/builtin-script.c | 21 -
 tools/perf/util/archinsn.h  | 12 
 4 files changed, 61 insertions(+), 1 deletion(-)
 create mode 100644 tools/perf/arch/x86/util/archinsn.c
 create mode 100644 tools/perf/util/archinsn.h

diff --git a/tools/perf/arch/x86/util/Build b/tools/perf/arch/x86/util/Build
index 7aab0be5fc5f..7b8e69bbbdfe 100644
--- a/tools/perf/arch/x86/util/Build
+++ b/tools/perf/arch/x86/util/Build
@@ -6,6 +6,7 @@ perf-y += perf_regs.o
 perf-y += group.o
 perf-y += machine.o
 perf-y += event.o
+perf-y += archinsn.o
 
 perf-$(CONFIG_DWARF) += dwarf-regs.o
 perf-$(CONFIG_BPF_PROLOGUE) += dwarf-regs.o
diff --git a/tools/perf/arch/x86/util/archinsn.c 
b/tools/perf/arch/x86/util/archinsn.c
new file mode 100644
index ..10b3c2a08b8f
--- /dev/null
+++ b/tools/perf/arch/x86/util/archinsn.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "perf.h"
+#include "archinsn.h"
+#include "fetch.h"
+#include "util/intel-pt-decoder/insn.h"
+#include "machine.h"
+#include "thread.h"
+#include "symbol.h"
+
+void arch_fetch_insn(struct perf_sample *sample,
+struct thread *thread,
+struct machine *machine)
+{
+   struct insn insn;
+   int len;
+   bool is64bit = false;
+
+   if (!sample->ip)
+   return;
+   len = fetch_exe(sample->ip, thread, machine, sample->insn,
+   sizeof(sample->insn), );
+   if (len <= 0)
+   return;
+   insn_init(, sample->insn, len, is64bit);
+   insn_get_length();
+   if (insn_complete() && insn.length <= len)
+   sample->insn_len = insn.length;
+}
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 2d8cb1d1682c..fbc440bdf880 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -29,10 +29,12 @@
 #include "util/time-utils.h"
 #include "util/path.h"
 #include "print_binary.h"
+#include "archinsn.h"
 #include 
 #include 
 #include 
 #include 
+#include 
 #include "asm/bug.h"
 #include "util/mem-events.h"
 #include "util/dump-insn.h"
@@ -63,6 +65,7 @@ static const char *cpu_list;
 static DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
 static struct perf_stat_config stat_config;
 static int max_blocks;
+static boolnative_arch;
 
 unsigned int scripting_max_stack = PERF_MAX_STACK_DEPTH;
 
@@ -1227,6 +1230,12 @@ static int perf_sample__fprintf_callindent(struct 
perf_sample *sample,
return len + dlen;
 }
 
+__weak void arch_fetch_insn(struct perf_sample *sample __maybe_unused,
+   struct thread *thread __maybe_unused,
+   struct machine *machine __maybe_unused)
+{
+}
+
 static int perf_sample__fprintf_insn(struct perf_sample *sample,
 struct perf_event_attr *attr,
 struct thread *thread,
@@ -1234,9 +1243,12 @@ static int perf_sample__fprintf_insn(struct perf_sample 
*sample,
 {
int printed = 0;
 
+   if (sample->insn_len == 0 && native_arch)
+   arch_fetch_insn(sample, thread, machine);
+
if (PRINT_FIELD(INSNLEN))
printed += fprintf(fp, " ilen: %d", sample->insn_len);
-   if (PRINT_FIELD(INSN)) {
+   if (PRINT_FIELD(INSN) && sample->insn_len) {
int i;
 
printed += fprintf(fp, " insn:");
@@ -3277,6 +3289,7 @@ int cmd_script(int argc, const char **argv)
.set = false,
.default_no_sample = true,
};
+

[PATCH v5 10/15] perf tools: Add utility function to print ns time stamps

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

Add a utility function to print nanosecond timestamps.

Signed-off-by: Andi Kleen 
---
 tools/perf/util/time-utils.c | 8 
 tools/perf/util/time-utils.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/tools/perf/util/time-utils.c b/tools/perf/util/time-utils.c
index 6193b46050a5..a63bdf4cfd1b 100644
--- a/tools/perf/util/time-utils.c
+++ b/tools/perf/util/time-utils.c
@@ -404,6 +404,14 @@ int timestamp__scnprintf_usec(u64 timestamp, char *buf, 
size_t sz)
return scnprintf(buf, sz, "%"PRIu64".%06"PRIu64, sec, usec);
 }
 
+int timestamp__scnprintf_nsec(u64 timestamp, char *buf, size_t sz)
+{
+   u64  sec = timestamp / NSEC_PER_SEC;
+   u64 nsec = timestamp % NSEC_PER_SEC;
+
+   return scnprintf(buf, sz, "%"PRIu64".%09"PRIu64, sec, nsec);
+}
+
 int fetch_current_timestamp(char *buf, size_t sz)
 {
struct timeval tv;
diff --git a/tools/perf/util/time-utils.h b/tools/perf/util/time-utils.h
index 70b177d2b98c..9266cf4a8e58 100644
--- a/tools/perf/util/time-utils.h
+++ b/tools/perf/util/time-utils.h
@@ -24,6 +24,7 @@ bool perf_time__ranges_skip_sample(struct perf_time_interval 
*ptime_buf,
   int num, u64 timestamp);
 
 int timestamp__scnprintf_usec(u64 timestamp, char *buf, size_t sz);
+int timestamp__scnprintf_nsec(u64 timestamp, char *buf, size_t sz);
 
 int fetch_current_timestamp(char *buf, size_t sz);
 
-- 
2.20.1



[PATCH v5 05/15] perf tools report: Parse time quantum

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

Many workloads change over time. perf report currently aggregates
the whole time range reported in perf.data.

This patch adds an option for a time quantum to quantisize the
perf.data over time.

This just adds the option, will be used in follow on patches
for a time sort key.

Signed-off-by: Andi Kleen 

---
v2:
Move time_quantum to symbol_conf. check for zero time quantum
v3:
Document s unit
v4:
Use _NSEC defines
---
 tools/perf/Documentation/perf-report.txt |  4 +++
 tools/perf/builtin-report.c  | 42 
 tools/perf/util/symbol.c |  2 ++
 tools/perf/util/symbol_conf.h|  1 +
 4 files changed, 49 insertions(+)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index 51dbc519dbce..9ec1702bccdd 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -497,6 +497,10 @@ include::itrace.txt[]
The period/hits keywords set the base the percentage is computed
on - the samples period or the number of samples (hits).
 
+--time-quantum::
+   Configure time quantum for time sort key. Default 100ms.
+   Accepts s, us, ms, ns units.
+
 include::callchain-overhead-calculation.txt[]
 
 SEE ALSO
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 09180e559ad6..46bd80363c90 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -47,9 +47,11 @@
 #include 
 #include 
 #include 
+#include "sane_ctype.h"
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -926,6 +928,43 @@ report_parse_callchain_opt(const struct option *opt, const 
char *arg, int unset)
return parse_callchain_report_opt(arg);
 }
 
+static int
+parse_time_quantum(const struct option *opt, const char *arg,
+  int unset __maybe_unused)
+{
+   unsigned long *time_q = opt->value;
+   char *end;
+
+   *time_q = strtoul(arg, , 0);
+   if (end == arg)
+   goto parse_err;
+   if (*time_q == 0) {
+   pr_err("time quantum cannot be 0");
+   return -1;
+   }
+   while (isspace(*end))
+   end++;
+   if (*end == 0)
+   return 0;
+   if (!strcmp(end, "s")) {
+   *time_q *= NSEC_PER_SEC;
+   return 0;
+   }
+   if (!strcmp(end, "ms")) {
+   *time_q *= NSEC_PER_MSEC;
+   return 0;
+   }
+   if (!strcmp(end, "us")) {
+   *time_q *= NSEC_PER_USEC;
+   return 0;
+   }
+   if (!strcmp(end, "ns"))
+   return 0;
+parse_err:
+   pr_err("Cannot parse time quantum `%s'\n", arg);
+   return -1;
+}
+
 int
 report_parse_ignore_callees_opt(const struct option *opt __maybe_unused,
const char *arg, int unset __maybe_unused)
@@ -1148,6 +1187,9 @@ int cmd_report(int argc, const char **argv)
 "Set percent type local/global-period/hits",
 annotate_parse_percent_type),
OPT_BOOLEAN(0, "ns", _conf.nanosecs, "Show times in nanosecs"),
+   OPT_CALLBACK(0, "time-quantum", _conf.time_quantum, "time 
(ms|us|ns|s)",
+"Set time quantum for time sort key (default 100ms)",
+parse_time_quantum),
OPT_END()
};
struct perf_data data = {
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index eb873ea1c405..913d24340d6b 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static int dso__load_kernel_sym(struct dso *dso, struct map *map);
@@ -45,6 +46,7 @@ struct symbol_conf symbol_conf = {
.demangle   = true,
.demangle_kernel= false,
.cumulate_callchain = true,
+   .time_quantum   = 100 * NSEC_PER_MSEC, /* 100ms */
.show_hist_headers  = true,
.symfs  = "",
.event_group= true,
diff --git a/tools/perf/util/symbol_conf.h b/tools/perf/util/symbol_conf.h
index 095a297c8b47..a5684a71b78e 100644
--- a/tools/perf/util/symbol_conf.h
+++ b/tools/perf/util/symbol_conf.h
@@ -56,6 +56,7 @@ struct symbol_conf {
*sym_list_str,
*col_width_list_str,
*bt_stop_list_str;
+   unsigned long   time_quantum;
struct strlist  *dso_list,
*comm_list,
*sym_list,
-- 
2.20.1



[PATCH v5 08/15] perf tools report: Support running scripts for current time range

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

When using the time sort key, add new context menus to run
scripts for only the currently selected time range. Compute
the correct range for the selection add pass it as the --time option to
perf script.

Signed-off-by: Andi Kleen 

---
v2:
Use symbol_conf.time_quantum
v3:
Work around broken gcc fortify code warning
Use _NSEC defines
---
 tools/perf/ui/browsers/hists.c | 83 +-
 1 file changed, 72 insertions(+), 11 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index aef800d97ea1..f98aeac607dd 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../../util/callchain.h"
 #include "../../util/evsel.h"
@@ -30,6 +31,7 @@
 #include "srcline.h"
 #include "string2.h"
 #include "units.h"
+#include "time-utils.h"
 
 #include "sane_ctype.h"
 
@@ -2338,6 +2340,7 @@ static int switch_data_file(void)
 }
 
 struct popup_action {
+   unsigned long   time;
struct thread   *thread;
struct map_symbol   ms;
int socket;
@@ -2527,36 +2530,64 @@ static int
 do_run_script(struct hist_browser *browser __maybe_unused,
  struct popup_action *act)
 {
-   char script_opt[64];
-   memset(script_opt, 0, sizeof(script_opt));
+   char *script_opt;
+   int len;
+   int n = 0;
+
+   len = 100;
+   if (act->thread)
+   len += strlen(thread__comm_str(act->thread));
+   else if (act->ms.sym)
+   len += strlen(act->ms.sym->name);
+   script_opt = malloc(len);
+   if (!script_opt)
+   return -1;
 
+   script_opt[0] = 0;
if (act->thread) {
-   scnprintf(script_opt, sizeof(script_opt), " -c %s ",
+   n = scnprintf(script_opt, len, " -c %s ",
  thread__comm_str(act->thread));
} else if (act->ms.sym) {
-   scnprintf(script_opt, sizeof(script_opt), " -S %s ",
+   n = scnprintf(script_opt, len, " -S %s ",
  act->ms.sym->name);
}
 
+   if (act->time) {
+   char start[32], end[32];
+   unsigned long starttime = act->time;
+   unsigned long endtime = act->time + symbol_conf.time_quantum;
+
+   if (starttime == endtime) { /* Display 1ms as fallback */
+   starttime -= 1*NSEC_PER_MSEC;
+   endtime += 1*NSEC_PER_MSEC;
+   }
+   timestamp__scnprintf_usec(starttime, start, sizeof start);
+   timestamp__scnprintf_usec(endtime, end, sizeof end);
+   n += snprintf(script_opt + n, len - n, " --time %s,%s", start, 
end);
+   }
+
script_browse(script_opt);
+   free(script_opt);
return 0;
 }
 
 static int
-add_script_opt(struct hist_browser *browser __maybe_unused,
+add_script_opt_2(struct hist_browser *browser __maybe_unused,
   struct popup_action *act, char **optstr,
-  struct thread *thread, struct symbol *sym)
+  struct thread *thread, struct symbol *sym,
+  const char *tstr)
 {
+
if (thread) {
-   if (asprintf(optstr, "Run scripts for samples of thread [%s]",
-thread__comm_str(thread)) < 0)
+   if (asprintf(optstr, "Run scripts for samples of thread [%s]%s",
+thread__comm_str(thread), tstr) < 0)
return 0;
} else if (sym) {
-   if (asprintf(optstr, "Run scripts for samples of symbol [%s]",
-sym->name) < 0)
+   if (asprintf(optstr, "Run scripts for samples of symbol [%s]%s",
+sym->name, tstr) < 0)
return 0;
} else {
-   if (asprintf(optstr, "Run scripts for all samples") < 0)
+   if (asprintf(optstr, "Run scripts for all samples%s", tstr) < 0)
return 0;
}
 
@@ -2566,6 +2597,36 @@ add_script_opt(struct hist_browser *browser 
__maybe_unused,
return 1;
 }
 
+static int
+add_script_opt(struct hist_browser *browser,
+  struct popup_action *act, char **optstr,
+  struct thread *thread, struct symbol *sym)
+{
+   int n, j;
+   struct hist_entry *he;
+
+   n = add_script_opt_2(browser, act, optstr, thread, sym, "");
+
+   he = hist_browser__selected_entry(browser);
+   if (sort_order && strstr(sort_order, "time")) {
+   char tstr[128];
+
+   optstr++;
+   act++;
+   j = sprintf(tstr, " in ");
+   j += timestamp__scnprintf_usec(he->time, tstr + j,
+  sizeof tstr - j);
+   j += sprintf(tstr + j, "-");
+   

[PATCH v5 03/15] perf tools script: Filter COMM/FORK/.. events by CPU

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

The --cpu option only filtered samples. Filter other perf events,
such as COMM, FORK, SWITCH by the CPU too.

Reported-by: Jiri Olsa 
Signed-off-by: Andi Kleen 

---
v2: Only filter printf output
---
 tools/perf/builtin-script.c | 62 +++--
 1 file changed, 39 insertions(+), 23 deletions(-)

diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index fbc440bdf880..f6b5b19b3307 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -2053,9 +2053,11 @@ static int process_comm_event(struct perf_tool *tool,
sample->tid = event->comm.tid;
sample->pid = event->comm.pid;
}
-   perf_sample__fprintf_start(sample, thread, evsel,
+   if (!cpu_list || test_bit(sample->cpu, cpu_bitmap)) {
+   perf_sample__fprintf_start(sample, thread, evsel,
   PERF_RECORD_COMM, stdout);
-   perf_event__fprintf(event, stdout);
+   perf_event__fprintf(event, stdout);
+   }
ret = 0;
 out:
thread__put(thread);
@@ -2089,9 +2091,11 @@ static int process_namespaces_event(struct perf_tool 
*tool,
sample->tid = event->namespaces.tid;
sample->pid = event->namespaces.pid;
}
-   perf_sample__fprintf_start(sample, thread, evsel,
-  PERF_RECORD_NAMESPACES, stdout);
-   perf_event__fprintf(event, stdout);
+   if (!cpu_list || test_bit(sample->cpu, cpu_bitmap)) {
+   perf_sample__fprintf_start(sample, thread, evsel,
+  PERF_RECORD_NAMESPACES, stdout);
+   perf_event__fprintf(event, stdout);
+   }
ret = 0;
 out:
thread__put(thread);
@@ -2123,9 +2127,11 @@ static int process_fork_event(struct perf_tool *tool,
sample->tid = event->fork.tid;
sample->pid = event->fork.pid;
}
-   perf_sample__fprintf_start(sample, thread, evsel,
-  PERF_RECORD_FORK, stdout);
-   perf_event__fprintf(event, stdout);
+   if (!cpu_list || test_bit(sample->cpu, cpu_bitmap)) {
+   perf_sample__fprintf_start(sample, thread, evsel,
+  PERF_RECORD_FORK, stdout);
+   perf_event__fprintf(event, stdout);
+   }
thread__put(thread);
 
return 0;
@@ -2153,9 +2159,11 @@ static int process_exit_event(struct perf_tool *tool,
sample->tid = event->fork.tid;
sample->pid = event->fork.pid;
}
-   perf_sample__fprintf_start(sample, thread, evsel,
-  PERF_RECORD_EXIT, stdout);
-   perf_event__fprintf(event, stdout);
+   if (!cpu_list || test_bit(sample->cpu, cpu_bitmap)) {
+   perf_sample__fprintf_start(sample, thread, evsel,
+  PERF_RECORD_EXIT, stdout);
+   perf_event__fprintf(event, stdout);
+   }
 
if (perf_event__process_exit(tool, event, sample, machine) < 0)
err = -1;
@@ -2189,9 +2197,11 @@ static int process_mmap_event(struct perf_tool *tool,
sample->tid = event->mmap.tid;
sample->pid = event->mmap.pid;
}
-   perf_sample__fprintf_start(sample, thread, evsel,
-  PERF_RECORD_MMAP, stdout);
-   perf_event__fprintf(event, stdout);
+   if (!cpu_list || test_bit(sample->cpu, cpu_bitmap)) {
+   perf_sample__fprintf_start(sample, thread, evsel,
+  PERF_RECORD_MMAP, stdout);
+   perf_event__fprintf(event, stdout);
+   }
thread__put(thread);
return 0;
 }
@@ -2221,9 +2231,11 @@ static int process_mmap2_event(struct perf_tool *tool,
sample->tid = event->mmap2.tid;
sample->pid = event->mmap2.pid;
}
-   perf_sample__fprintf_start(sample, thread, evsel,
-  PERF_RECORD_MMAP2, stdout);
-   perf_event__fprintf(event, stdout);
+   if (!cpu_list || test_bit(sample->cpu, cpu_bitmap)) {
+   perf_sample__fprintf_start(sample, thread, evsel,
+  PERF_RECORD_MMAP2, stdout);
+   perf_event__fprintf(event, stdout);
+   }
thread__put(thread);
return 0;
 }
@@ -2248,9 +2260,11 @@ static int process_switch_event(struct perf_tool *tool,
return -1;
}
 
-   perf_sample__fprintf_start(sample, thread, evsel,
-  PERF_RECORD_SWITCH, stdout);
-   perf_event__fprintf(event, stdout);
+   if (!cpu_list || test_bit(sample->cpu, cpu_bitmap)) {
+   perf_sample__fprintf_start(sample, thread, evsel,
+  PERF_RECORD_SWITCH, stdout);
+   perf_event__fprintf(event, 

[PATCH v5 04/15] perf tools report: Support nano seconds

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

Upcoming changes add timestamp output in perf report. Add a --ns
argument similar to perf script to support nanoseconds resolution
when needed.

Signed-off-by: Andi Kleen 

---
v2:
Move flag into symbol_conf and change all users
---
 tools/perf/Documentation/perf-report.txt |  3 +++
 tools/perf/builtin-report.c  |  1 +
 tools/perf/builtin-script.c  | 11 +--
 tools/perf/util/symbol.c |  1 +
 tools/perf/util/symbol_conf.h|  1 +
 5 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index 1a27bfe05039..51dbc519dbce 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -477,6 +477,9 @@ include::itrace.txt[]
Please note that not all mmaps are stored, options affecting which ones
are include 'perf record --data', for instance.
 
+--ns::
+   Show time stamps in nanoseconds.
+
 --stats::
Display overall events statistics without any further processing.
(like the one at the end of the perf report -D command)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 1532ebde6c4b..09180e559ad6 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -1147,6 +1147,7 @@ int cmd_report(int argc, const char **argv)
OPT_CALLBACK(0, "percent-type", _opts, "local-period",
 "Set percent type local/global-period/hits",
 annotate_parse_percent_type),
+   OPT_BOOLEAN(0, "ns", _conf.nanosecs, "Show times in nanosecs"),
OPT_END()
};
struct perf_data data = {
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index f6b5b19b3307..77cc014ff8d0 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -60,7 +60,6 @@ static bool   no_callchain;
 static boollatency_format;
 static boolsystem_wide;
 static boolprint_flags;
-static boolnanosecs;
 static const char  *cpu_list;
 static DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
 static struct perf_stat_config stat_config;
@@ -691,7 +690,7 @@ static int perf_sample__fprintf_start(struct perf_sample 
*sample,
secs = nsecs / NSEC_PER_SEC;
nsecs -= secs * NSEC_PER_SEC;
 
-   if (nanosecs)
+   if (symbol_conf.nanosecs)
printed += fprintf(fp, "%5lu.%09llu: ", secs, nsecs);
else {
char sample_time[32];
@@ -3260,7 +3259,7 @@ static int parse_insn_trace(const struct option *opt 
__maybe_unused,
 {
parse_output_fields(NULL, "+insn,-event,-period", 0);
itrace_parse_synth_opts(opt, "i0ns", 0);
-   nanosecs = true;
+   symbol_conf.nanosecs = true;
return 0;
 }
 
@@ -3278,7 +3277,7 @@ static int parse_call_trace(const struct option *opt 
__maybe_unused,
 {
parse_output_fields(NULL, "-ip,-addr,-event,-period,+callindent", 0);
itrace_parse_synth_opts(opt, "cewp", 0);
-   nanosecs = true;
+   symbol_conf.nanosecs = true;
return 0;
 }
 
@@ -3288,7 +3287,7 @@ static int parse_callret_trace(const struct option *opt 
__maybe_unused,
 {
parse_output_fields(NULL, 
"-ip,-addr,-event,-period,+callindent,+flags", 0);
itrace_parse_synth_opts(opt, "crewp", 0);
-   nanosecs = true;
+   symbol_conf.nanosecs = true;
return 0;
 }
 
@@ -3424,7 +3423,7 @@ int cmd_script(int argc, const char **argv)
OPT_BOOLEAN('f', "force", _conf.force, "don't complain, do it"),
OPT_INTEGER(0, "max-blocks", _blocks,
"Maximum number of code blocks to dump with brstackinsn"),
-   OPT_BOOLEAN(0, "ns", ,
+   OPT_BOOLEAN(0, "ns", _conf.nanosecs,
"Use 9 decimal places when displaying time"),
OPT_CALLBACK_OPTARG(0, "itrace", _synth_opts, NULL, "opts",
"Instruction Tracing options\n" ITRACE_HELP,
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 758bf5f74e6e..eb873ea1c405 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -39,6 +39,7 @@ int vmlinux_path__nr_entries;
 char **vmlinux_path;
 
 struct symbol_conf symbol_conf = {
+   .nanosecs   = false,
.use_modules= true,
.try_vmlinux_path   = true,
.demangle   = true,
diff --git a/tools/perf/util/symbol_conf.h b/tools/perf/util/symbol_conf.h
index fffea68c1203..095a297c8b47 100644
--- a/tools/perf/util/symbol_conf.h
+++ b/tools/perf/util/symbol_conf.h
@@ -8,6 +8,7 @@ struct strlist;
 struct intlist;
 
 struct symbol_conf {
+   boolnanosecs;
unsigned short  priv_size;
booltry_vmlinux_path,

[PATCH v5 12/15] perf tools: Add some new tips describing the new options

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

Signed-off-by: Andi Kleen 

---
v2:
Even more tips.
v3:
Even more tips
---
 tools/perf/Documentation/tips.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/perf/Documentation/tips.txt 
b/tools/perf/Documentation/tips.txt
index 849599f39c5e..869965d629ce 100644
--- a/tools/perf/Documentation/tips.txt
+++ b/tools/perf/Documentation/tips.txt
@@ -15,6 +15,7 @@ To see callchains in a more compact form: perf report -g 
folded
 Show individual samples with: perf script
 Limit to show entries above 5% only: perf report --percent-limit 5
 Profiling branch (mis)predictions with: perf record -b / perf report
+To show assembler sample contexts use perf record -b / perf script -F 
+brstackinsn --xed
 Treat branches as callchains: perf report --branch-history
 To count events in every 1000 msec: perf stat -I 1000
 Print event counts in CSV format with: perf stat -x,
@@ -34,3 +35,9 @@ Show current config key-value pairs: perf config --list
 Show user configuration overrides: perf config --user --list
 To add Node.js USDT(User-Level Statically Defined Tracing): perf buildid-cache 
--add `which node`
 To report cacheline events from previous recording: perf c2c report
+To browse sample contexts use perf report --sample 10 and select in context 
menu
+To separate samples by time use perf report --sort time,overhead,sym
+To set sample time separation other than 100ms with --sort time use 
--time-quantum
+Add -I to perf report to sample register values visible in perf report context.
+To show IPC for sampling periods use perf record -e '{cycles,instructions}:S' 
and then browse context
+To show context switches in perf report sample context add --switch-events to 
perf record.
-- 
2.20.1



[PATCH v5 01/15] perf tools: Add utility function to fetch executable

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

Add a utility function to fetch executable code. Convert one
user over to it. There are more places doing that, but they
do significantly different actions, so they are not
easy to fit into a single library function.

Signed-off-by: Andi Kleen 
---
 tools/perf/util/Build   |  1 +
 tools/perf/util/fetch.c | 28 
 tools/perf/util/fetch.h |  7 +++
 tools/perf/util/intel-bts.c | 21 +++--
 4 files changed, 39 insertions(+), 18 deletions(-)
 create mode 100644 tools/perf/util/fetch.c
 create mode 100644 tools/perf/util/fetch.h

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 8dd3102301ea..649321fc3fb9 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -65,6 +65,7 @@ perf-y += trace-event-scripting.o
 perf-y += trace-event.o
 perf-y += svghelper.o
 perf-y += sort.o
+perf-y += fetch.o
 perf-y += hist.o
 perf-y += util.o
 perf-y += xyarray.o
diff --git a/tools/perf/util/fetch.c b/tools/perf/util/fetch.c
new file mode 100644
index ..1430083e7eca
--- /dev/null
+++ b/tools/perf/util/fetch.c
@@ -0,0 +1,28 @@
+#include "perf.h"
+#include "machine.h"
+#include "thread.h"
+#include "symbol.h"
+#include "map.h"
+#include "fetch.h"
+
+int fetch_exe(u64 ip, struct thread *thread, struct machine *machine,
+ char *buf, int len, bool *is64bit)
+{
+   struct addr_location al;
+   u8 cpumode;
+   long offset;
+
+   if (machine__kernel_ip(machine, ip))
+   cpumode = PERF_RECORD_MISC_KERNEL;
+   else
+   cpumode = PERF_RECORD_MISC_USER;
+   if (!thread__find_map(thread, cpumode, ip, ) || !al.map->dso)
+   return -1;
+   if (al.map->dso->data.status == DSO_DATA_STATUS_ERROR)
+   return -1;
+   map__load(al.map);
+   offset = al.map->map_ip(al.map, ip);
+   if (is64bit)
+   *is64bit = al.map->dso->is_64_bit;
+   return dso__data_read_offset(al.map->dso, machine, offset, (u8 *)buf, 
len);
+}
diff --git a/tools/perf/util/fetch.h b/tools/perf/util/fetch.h
new file mode 100644
index ..7b77b8cee55a
--- /dev/null
+++ b/tools/perf/util/fetch.h
@@ -0,0 +1,7 @@
+#ifndef FETCH_H
+#define FETCH_H 1
+
+int fetch_exe(u64 ip, struct thread *thread, struct machine *machine,
+ char *buf, int len, bool *is64bit);
+
+#endif
diff --git a/tools/perf/util/intel-bts.c b/tools/perf/util/intel-bts.c
index 0c0180c67574..915f4662e52e 100644
--- a/tools/perf/util/intel-bts.c
+++ b/tools/perf/util/intel-bts.c
@@ -38,6 +38,7 @@
 #include "auxtrace.h"
 #include "intel-pt-decoder/intel-pt-insn-decoder.h"
 #include "intel-bts.h"
+#include "fetch.h"
 
 #define MAX_TIMESTAMP (~0ULL)
 
@@ -328,35 +329,19 @@ static int intel_bts_get_next_insn(struct intel_bts_queue 
*btsq, u64 ip)
 {
struct machine *machine = btsq->bts->machine;
struct thread *thread;
-   struct addr_location al;
unsigned char buf[INTEL_PT_INSN_BUF_SZ];
ssize_t len;
-   int x86_64;
-   uint8_t cpumode;
+   bool x86_64;
int err = -1;
 
-   if (machine__kernel_ip(machine, ip))
-   cpumode = PERF_RECORD_MISC_KERNEL;
-   else
-   cpumode = PERF_RECORD_MISC_USER;
-
thread = machine__find_thread(machine, -1, btsq->tid);
if (!thread)
return -1;
 
-   if (!thread__find_map(thread, cpumode, ip, ) || !al.map->dso)
-   goto out_put;
-
-   len = dso__data_read_addr(al.map->dso, al.map, machine, ip, buf,
- INTEL_PT_INSN_BUF_SZ);
+   len = fetch_exe(ip, thread, machine, (char*)buf, INTEL_PT_INSN_BUF_SZ, 
_64);
if (len <= 0)
goto out_put;
 
-   /* Load maps to ensure dso->is_64_bit has been updated */
-   map__load(al.map);
-
-   x86_64 = al.map->dso->is_64_bit;
-
if (intel_pt_get_insn(buf, len, x86_64, >intel_pt_insn))
goto out_put;
 
-- 
2.20.1



[PATCH v5 14/15] perf tools script: Add array bound checking to list_scripts

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

Don't overflow array when the scripts directory is too large,
or the script file name is too long.

Signed-off-by: Andi Kleen 
---
 tools/perf/builtin-script.c  | 8 ++--
 tools/perf/builtin.h | 3 ++-
 tools/perf/ui/browsers/scripts.c | 3 ++-
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 77cc014ff8d0..389118500694 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -2975,7 +2975,8 @@ static int check_ev_match(char *dir_name, char 
*scriptname,
  * will list all statically runnable scripts, select one, execute it and
  * show the output in a perf browser.
  */
-int find_scripts(char **scripts_array, char **scripts_path_array)
+int find_scripts(char **scripts_array, char **scripts_path_array, int num,
+int pathlen)
 {
struct dirent *script_dirent, *lang_dirent;
char scripts_path[MAXPATHLEN], lang_path[MAXPATHLEN];
@@ -3020,7 +3021,10 @@ int find_scripts(char **scripts_array, char 
**scripts_path_array)
/* Skip those real time scripts: xxxtop.p[yl] */
if (strstr(script_dirent->d_name, "top."))
continue;
-   sprintf(scripts_path_array[i], "%s/%s", lang_path,
+   if (i >= num)
+   break;
+   snprintf(scripts_path_array[i], pathlen, "%s/%s",
+   lang_path,
script_dirent->d_name);
temp = strchr(script_dirent->d_name, '.');
snprintf(scripts_array[i],
diff --git a/tools/perf/builtin.h b/tools/perf/builtin.h
index 05745f3ce912..999fe9170122 100644
--- a/tools/perf/builtin.h
+++ b/tools/perf/builtin.h
@@ -40,5 +40,6 @@ int cmd_mem(int argc, const char **argv);
 int cmd_data(int argc, const char **argv);
 int cmd_ftrace(int argc, const char **argv);
 
-int find_scripts(char **scripts_array, char **scripts_path_array);
+int find_scripts(char **scripts_array, char **scripts_path_array, int num,
+int pathlen);
 #endif
diff --git a/tools/perf/ui/browsers/scripts.c b/tools/perf/ui/browsers/scripts.c
index 5d407ab834b5..6759d6657e1a 100644
--- a/tools/perf/ui/browsers/scripts.c
+++ b/tools/perf/ui/browsers/scripts.c
@@ -117,7 +117,8 @@ static int list_scripts(char *script_name, bool *custom,
paths[i] = names[i] + SCRIPT_NAMELEN;
}
 
-   num = find_scripts(names + max_std, paths + max_std);
+   num = find_scripts(names + max_std, paths + max_std, SCRIPT_MAX_NO - 
max_std,
+   SCRIPT_FULLPATH_LEN);
if (num < 0)
num = 0;
choice = ui__popup_menu(num + max_std, (char * const *)names);
-- 
2.20.1



[PATCH v5 15/15] perf tools ui: Fix ui popup browser for many entries

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

Fix the argv ui browser code to correctly display more entries
than fit on the screen without crashing. The problem was some type
confusion with pointer types in the ->seek function. Do
the argv arithmetic correctly with char ** pointers. Also
add some asserts to find overruns and limit the display function
correctly.

Then finally remove a workaround for this in the res sample
browser.

Signed-off-by: Andi Kleen 
---
 tools/perf/ui/browser.c | 10 +++---
 tools/perf/ui/browsers/res_sample.c |  3 ---
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c
index 4f75561424ed..4ad37d8c7d6a 100644
--- a/tools/perf/ui/browser.c
+++ b/tools/perf/ui/browser.c
@@ -611,14 +611,16 @@ void ui_browser__argv_seek(struct ui_browser *browser, 
off_t offset, int whence)
browser->top = browser->entries;
break;
case SEEK_CUR:
-   browser->top = browser->top + browser->top_idx + offset;
+   browser->top = (char **)browser->top + offset;
break;
case SEEK_END:
-   browser->top = browser->top + browser->nr_entries - 1 + offset;
+   browser->top = (char **)browser->entries + browser->nr_entries 
- 1 + offset;
break;
default:
return;
}
+   assert((char **)browser->top < (char **)browser->entries + 
browser->nr_entries);
+   assert((char **)browser->top >= (char **)browser->entries);
 }
 
 unsigned int ui_browser__argv_refresh(struct ui_browser *browser)
@@ -630,7 +632,9 @@ unsigned int ui_browser__argv_refresh(struct ui_browser 
*browser)
browser->top = browser->entries;
 
pos = (char **)browser->top;
-   while (idx < browser->nr_entries) {
+   while (idx < browser->nr_entries &&
+  row < (unsigned)SLtt_Screen_Rows - 1) {
+   assert(pos < (char **)browser->entries + browser->nr_entries);
if (!browser->filter || !browser->filter(browser, *pos)) {
ui_browser__gotorc(browser, row, 0);
browser->write(browser, pos, row);
diff --git a/tools/perf/ui/browsers/res_sample.c 
b/tools/perf/ui/browsers/res_sample.c
index c2a8536904bc..8befd8e984ab 100644
--- a/tools/perf/ui/browsers/res_sample.c
+++ b/tools/perf/ui/browsers/res_sample.c
@@ -37,9 +37,6 @@ int res_sample_browse(struct res_sample *res_samples, int 
num_res,
struct res_sample *r;
char extra_format[256];
 
-   /* For now since ui__popup_menu doesn't like lists that don't fit */
-   num_res = max(min(SLtt_Screen_Rows - 4, num_res), 0);
-
names = calloc(num_res, sizeof(char *));
if (!names)
return -1;
-- 
2.20.1



Support sample context in perf report

2019-03-08 Thread Andi Kleen
[Changes: 
v5:
Address review comments.
Fix perf script --cpu filtering
Use _NSEC defines.
Fix DEBUG=0 build again
Make sample context size configurable.
Some minor improvements.
]

We currently have two ways to look at sample data in perf:
either use perf report to aggregate everything, or use
perf script to look at all individual samples.

Both ways are useful. Of course aggregation is useful
to quickly find the most expensive part of the code.

But sometimes a single sample is not good enough to
determine the problem and we need to look at context, either
through branch contexts, or other previous samples (e.g. for
correlating different micro architecture events or computing
metrics)

This can be done through perf script today, but it can
be rather cumbersome to find the right samples to look
at.

Another problem with perf report is that it aggregates
the whole measurement period. But many real workloads
have phases where they behave quite differently, and it is
often not useful to combine them into a single histogram.

While this can be worked around with the --time option
to report, it can be quite cumbersome.

This patch kit attempts to address some of these
problems in perf report by making it time aware.

- It adds a new time sort key that allows perf report
to separate samples from different regions. The time
regions can be defined with a new --time-quantum option.

- Then it extends the perf script support in the
tui record browser to allow browsing samples for 
different time regions from within a perf report
session.

- Extends the report browser script display
to automatically select sensible defaults
based on what was recorded. For example it will
automatically show branch contexts with -b.

- Support browsing the context of individual samples.
perf report can save a limited number of random samples
per histogram entry with the new --samples option.
Then the browser allows directly jumping to any
of the saved samples and browsing the context on the current
thread or CPU.

There could be probably be done more to make
perf report even better for such use cases (e.g. a real
time line display), but this basic support is good
enough for many useful usages.

Also available in
git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git perf/streams-5




[PATCH v5 07/15] perf tools report: Use less for scripts output

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

The UI viewer for scripts output has a lot of limitations: limited size,
no search or save function, slow, and various other issues.

Just use 'less' to display directly on the terminal instead.

This won't work in gtk mode, but gtk doesn't support these
context menus anyways. If that is ever done could use an terminal
for the output.

Signed-off-by: Andi Kleen 

---

v2:
Remove some unneeded headers
---
 tools/perf/ui/browsers/scripts.c | 130 ---
 1 file changed, 17 insertions(+), 113 deletions(-)

diff --git a/tools/perf/ui/browsers/scripts.c b/tools/perf/ui/browsers/scripts.c
index 90a32ac69e76..7f36630694bf 100644
--- a/tools/perf/ui/browsers/scripts.c
+++ b/tools/perf/ui/browsers/scripts.c
@@ -1,35 +1,12 @@
 // SPDX-License-Identifier: GPL-2.0
-#include 
-#include 
-#include 
-#include 
 #include "../../util/sort.h"
 #include "../../util/util.h"
 #include "../../util/hist.h"
 #include "../../util/debug.h"
 #include "../../util/symbol.h"
 #include "../browser.h"
-#include "../helpline.h"
 #include "../libslang.h"
 
-/* 2048 lines should be enough for a script output */
-#define MAX_LINES  2048
-
-/* 160 bytes for one output line */
-#define AVERAGE_LINE_LEN   160
-
-struct script_line {
-   struct list_head node;
-   char line[AVERAGE_LINE_LEN];
-};
-
-struct perf_script_browser {
-   struct ui_browser b;
-   struct list_head entries;
-   const char *script_name;
-   int nr_lines;
-};
-
 #define SCRIPT_NAMELEN 128
 #define SCRIPT_MAX_NO  64
 /*
@@ -73,69 +50,29 @@ static int list_scripts(char *script_name)
return ret;
 }
 
-static void script_browser__write(struct ui_browser *browser,
-  void *entry, int row)
+static void run_script(char *cmd)
 {
-   struct script_line *sline = list_entry(entry, struct script_line, node);
-   bool current_entry = ui_browser__is_current_entry(browser, row);
-
-   ui_browser__set_color(browser, current_entry ? HE_COLORSET_SELECTED :
-  HE_COLORSET_NORMAL);
-
-   ui_browser__write_nstring(browser, sline->line, browser->width);
+   pr_debug("Running %s\n", cmd);
+   SLang_reset_tty();
+   if (system(cmd) < 0)
+   pr_warning("Cannot run %s\n", cmd);
+   /*
+* SLang doesn't seem to reset the whole terminal, so be more
+* forceful to get back to the original state.
+*/
+   printf("\033[c\033[H\033[J");
+   fflush(stdout);
+   SLang_init_tty(0, 0, 0);
+   SLsmg_refresh();
 }
 
-static int script_browser__run(struct perf_script_browser *browser)
-{
-   int key;
-
-   if (ui_browser__show(>b, browser->script_name,
-"Press ESC to exit") < 0)
-   return -1;
-
-   while (1) {
-   key = ui_browser__run(>b, 0);
-
-   /* We can add some special key handling here if needed */
-   break;
-   }
-
-   ui_browser__hide(>b);
-   return key;
-}
-
-
 int script_browse(const char *script_opt)
 {
char cmd[SCRIPT_FULLPATH_LEN*2], script_name[SCRIPT_FULLPATH_LEN];
-   char *line = NULL;
-   size_t len = 0;
-   ssize_t retlen;
-   int ret = -1, nr_entries = 0;
-   FILE *fp;
-   void *buf;
-   struct script_line *sline;
-
-   struct perf_script_browser script = {
-   .b = {
-   .refresh= ui_browser__list_head_refresh,
-   .seek   = ui_browser__list_head_seek,
-   .write  = script_browser__write,
-   },
-   .script_name = script_name,
-   };
-
-   INIT_LIST_HEAD();
-
-   /* Save each line of the output in one struct script_line object. */
-   buf = zalloc((sizeof(*sline)) * MAX_LINES);
-   if (!buf)
-   return -1;
-   sline = buf;
 
memset(script_name, 0, SCRIPT_FULLPATH_LEN);
if (list_scripts(script_name))
-   goto exit;
+   return -1;
 
sprintf(cmd, "perf script -s %s ", script_name);
 
@@ -147,42 +84,9 @@ int script_browse(const char *script_opt)
strcat(cmd, input_name);
}
 
-   strcat(cmd, " 2>&1");
-
-   fp = popen(cmd, "r");
-   if (!fp)
-   goto exit;
-
-   while ((retlen = getline(, , fp)) != -1) {
-   strncpy(sline->line, line, AVERAGE_LINE_LEN);
-
-   /* If one output line is very large, just cut it short */
-   if (retlen >= AVERAGE_LINE_LEN) {
-   sline->line[AVERAGE_LINE_LEN - 1] = '\0';
-   sline->line[AVERAGE_LINE_LEN - 2] = '\n';
-   }
-   list_add_tail(>node, );
-
-   if (script.b.width < retlen)
-   script.b.width = retlen;
-
-   if (nr_entries++ >= MAX_LINES - 1)
-   break;
-  

[PATCH v5 09/15] perf tools report: Support builtin perf script in scripts menu

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

The scripts menu traditionally only showed custom perf scripts.

Allow to run standard perf script with useful default options too.

- Normal perf script
- perf script with assembler (needs xed installed)
- perf script with source code output (needs debuginfo)
- perf script with custom arguments

Then we automatically select the right options to
display the information in the perf.data file.

For example with -b display branch contexts.

It's not easily possible to check for xed's existence
in advance.  perf script usually gives sensible error messages when
it's not available.

Signed-off-by: Andi Kleen 

---
v2:
Pass --inline if needed
v3:
Avoid compiler warnings. Allocate cmd buffer dynamically.
Change formatting
---
 tools/perf/ui/browsers/annotate.c |   2 +-
 tools/perf/ui/browsers/hists.c|  23 +++---
 tools/perf/ui/browsers/scripts.c  | 127 +++---
 tools/perf/util/hist.h|   8 +-
 4 files changed, 120 insertions(+), 40 deletions(-)

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 35bdfd8b1e71..98d934a36d86 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -750,7 +750,7 @@ static int annotate_browser__run(struct annotate_browser 
*browser,
continue;
case 'r':
{
-   script_browse(NULL);
+   script_browse(NULL, NULL);
continue;
}
case 'k':
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index f98aeac607dd..fb4430f8982c 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -2344,6 +2344,7 @@ struct popup_action {
struct thread   *thread;
struct map_symbol   ms;
int socket;
+   struct perf_evsel   *evsel;
 
int (*fn)(struct hist_browser *browser, struct popup_action *act);
 };
@@ -2566,7 +2567,7 @@ do_run_script(struct hist_browser *browser __maybe_unused,
n += snprintf(script_opt + n, len - n, " --time %s,%s", start, 
end);
}
 
-   script_browse(script_opt);
+   script_browse(script_opt, act->evsel);
free(script_opt);
return 0;
 }
@@ -2575,7 +2576,7 @@ static int
 add_script_opt_2(struct hist_browser *browser __maybe_unused,
   struct popup_action *act, char **optstr,
   struct thread *thread, struct symbol *sym,
-  const char *tstr)
+  struct perf_evsel *evsel, const char *tstr)
 {
 
if (thread) {
@@ -2593,6 +2594,7 @@ add_script_opt_2(struct hist_browser *browser 
__maybe_unused,
 
act->thread = thread;
act->ms.sym = sym;
+   act->evsel = evsel;
act->fn = do_run_script;
return 1;
 }
@@ -2600,12 +2602,13 @@ add_script_opt_2(struct hist_browser *browser 
__maybe_unused,
 static int
 add_script_opt(struct hist_browser *browser,
   struct popup_action *act, char **optstr,
-  struct thread *thread, struct symbol *sym)
+  struct thread *thread, struct symbol *sym,
+  struct perf_evsel *evsel)
 {
int n, j;
struct hist_entry *he;
 
-   n = add_script_opt_2(browser, act, optstr, thread, sym, "");
+   n = add_script_opt_2(browser, act, optstr, thread, sym, evsel, "");
 
he = hist_browser__selected_entry(browser);
if (sort_order && strstr(sort_order, "time")) {
@@ -2618,10 +2621,9 @@ add_script_opt(struct hist_browser *browser,
   sizeof tstr - j);
j += sprintf(tstr + j, "-");
timestamp__scnprintf_usec(he->time + symbol_conf.time_quantum,
- tstr + j,
- sizeof tstr - j);
+ tstr + j, sizeof tstr - j);
n += add_script_opt_2(browser, act, optstr, thread, sym,
- tstr);
+ evsel, tstr);
act->time = he->time;
}
return n;
@@ -3092,7 +3094,7 @@ static int perf_evsel__hists_browse(struct perf_evsel 
*evsel, int nr_events,
nr_options += add_script_opt(browser,
 
[nr_options],
 
[nr_options],
-thread, NULL);
+thread, NULL, 
evsel);
}
/*
 * Note that browser->selection != NULL
@@ -3107,11 +3109,12 @@ static int perf_evsel__hists_browse(struct perf_evsel 
*evsel, int nr_events,
  

[PATCH v5 13/15] perf tools report: Add custom scripts to script menu

2019-03-08 Thread Andi Kleen
From: Andi Kleen 

Add a way to define custom scripts through ~/.perfconfig, which
are then added to the scripts menu. The scripts get the same
arguments as perf script, in particular -i, --cpu, --tid.

Signed-off-by: Andi Kleen 
---
 tools/perf/Documentation/perf-config.txt |  8 
 tools/perf/ui/browsers/scripts.c | 20 
 2 files changed, 28 insertions(+)

diff --git a/tools/perf/Documentation/perf-config.txt 
b/tools/perf/Documentation/perf-config.txt
index 2d0fb7613134..c3323228d3d0 100644
--- a/tools/perf/Documentation/perf-config.txt
+++ b/tools/perf/Documentation/perf-config.txt
@@ -590,6 +590,14 @@ samples.*::
Define how many ns worth of time to show
around samples in perf report sample context browser.
 
+script.*::
+
+   Any option defines a script that is added to the scripts menu
+   in the interactive perf browser and whose output is displayed.
+   The name of the option is the name, the value is a script command line.
+   The script gets the same options passed as a full perf script,
+   in particular -i perfdata file, --cpu, --tid
+
 SEE ALSO
 
 linkperf:perf[1]
diff --git a/tools/perf/ui/browsers/scripts.c b/tools/perf/ui/browsers/scripts.c
index cdba58447b85..5d407ab834b5 100644
--- a/tools/perf/ui/browsers/scripts.c
+++ b/tools/perf/ui/browsers/scripts.c
@@ -6,6 +6,7 @@
 #include "../../util/symbol.h"
 #include "../browser.h"
 #include "../libslang.h"
+#include "config.h"
 
 #define SCRIPT_NAMELEN 128
 #define SCRIPT_MAX_NO  64
@@ -53,6 +54,24 @@ static int add_script_option(const char *name, const char 
*opt,
return 0;
 }
 
+static int scripts_config(const char *var, const char *value, void *data)
+{
+   struct script_config *c = data;
+
+   if (!strstarts(var, "script."))
+   return -1;
+   if (c->index >= SCRIPT_MAX_NO)
+   return -1;
+   c->names[c->index] = strdup(var + 7);
+   if (!c->names[c->index])
+   return -1;
+   if (asprintf(>paths[c->index], "%s %s", value,
+c->extra_format) < 0)
+   return -1;
+   c->index++;
+   return 0;
+}
+
 /*
  * When success, will copy the full path of the selected script
  * into  the buffer pointed by script_name, and return 0.
@@ -87,6 +106,7 @@ static int list_scripts(char *script_name, bool *custom,
  );
add_script_option("Show individual samples with source", "-F 
+srcline,+srccode",
  );
+   perf_config(scripts_config, );
custom_perf = scriptc.index;
add_script_option("Show samples with custom perf script arguments", "", 
);
i = scriptc.index;
-- 
2.20.1



[PATCH] isdn: mISDNinfineon: fix potential NULL pointer dereference

2019-03-08 Thread Kangjie Lu
In case ioremap fails, the fix returns -ENOMEM to avoid NULL
pointer dereference.

Signed-off-by: Kangjie Lu 
---
 drivers/isdn/hardware/mISDN/mISDNinfineon.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/isdn/hardware/mISDN/mISDNinfineon.c 
b/drivers/isdn/hardware/mISDN/mISDNinfineon.c
index 3e01012be4ab..0fe6ddcb3fdc 100644
--- a/drivers/isdn/hardware/mISDN/mISDNinfineon.c
+++ b/drivers/isdn/hardware/mISDN/mISDNinfineon.c
@@ -712,8 +712,11 @@ setup_io(struct inf_hw *hw)
(ulong)hw->addr.start, (ulong)hw->addr.size);
return err;
}
-   if (hw->ci->addr_mode == AM_MEMIO)
+   if (hw->ci->addr_mode == AM_MEMIO) {
hw->addr.p = ioremap(hw->addr.start, hw->addr.size);
+   if (unlikely(!hw->addr.p))
+   return -ENOMEM;
+   }
hw->addr.mode = hw->ci->addr_mode;
if (debug & DEBUG_HW)
pr_notice("%s: IO addr %lx (%lu bytes) mode%d\n",
-- 
2.17.1



[PATCH] isdn: hfcpci: fix potential NULL pointer dereference

2019-03-08 Thread Kangjie Lu
In case ioremap fails, the fix reports an error and returns.

Signed-off-by: Kangjie Lu 
---
 drivers/isdn/hardware/mISDN/hfcpci.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/isdn/hardware/mISDN/hfcpci.c 
b/drivers/isdn/hardware/mISDN/hfcpci.c
index ebb3fa2e1d00..b400d6528a56 100644
--- a/drivers/isdn/hardware/mISDN/hfcpci.c
+++ b/drivers/isdn/hardware/mISDN/hfcpci.c
@@ -2036,6 +2036,11 @@ setup_hw(struct hfc_pci *hc)
   "HFC-PCI: defined at mem %#lx fifo %#lx(%#lx) IRQ %d HZ %d\n",
   (u_long) hc->hw.pci_io, (u_long) hc->hw.fifos,
   (u_long) hc->hw.dmahandle, hc->irq, HZ);
+   if (unlikely(!hc->hw.pci_io)) {
+   printk(KERN_WARNING
+  "HFC-PCI: ioremap failed!\n");
+   return 1;
+   }
/* enable memory mapped ports, disable busmaster */
pci_write_config_word(hc->pdev, PCI_COMMAND, PCI_ENA_MEMIO);
hc->hw.int_m2 = 0;
-- 
2.17.1



[PATCH] input: pm8xxx-vibrator: fix a potential NULL pointer dereference

2019-03-08 Thread Kangjie Lu
In case of_device_get_match_data fails to find the matched data,
returns -ENODEV

Signed-off-by: Kangjie Lu 
---
 drivers/input/misc/pm8xxx-vibrator.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/input/misc/pm8xxx-vibrator.c 
b/drivers/input/misc/pm8xxx-vibrator.c
index 7dd1c1fbe42a..740e59c11808 100644
--- a/drivers/input/misc/pm8xxx-vibrator.c
+++ b/drivers/input/misc/pm8xxx-vibrator.c
@@ -196,6 +196,8 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
vib->vib_input_dev = input_dev;
 
regs = of_device_get_match_data(>dev);
+   if (unlikely(!regs))
+   return -ENODEV;
 
/* operate in manual mode */
error = regmap_read(vib->regmap, regs->drv_addr, );
-- 
2.17.1



[PATCH] infiniband: i40iw: fix potential NULL pointer dereferences

2019-03-08 Thread Kangjie Lu
alloc_ordered_workqueue may fail and return NULL. Let's check
its return value to ensure it is not NULL so as to avoid
potential NULL pointer dereferences.

Signed-off-by: Kangjie Lu 
---
 drivers/infiniband/hw/i40iw/i40iw_cm.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c 
b/drivers/infiniband/hw/i40iw/i40iw_cm.c
index 206cfb0016f8..ad9b4f235e30 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
@@ -3256,9 +3256,21 @@ void i40iw_setup_cm_core(struct i40iw_device *iwdev)
 
cm_core->event_wq = alloc_ordered_workqueue("iwewq",
WQ_MEM_RECLAIM);
+   if (!cm_core->event_wq) {
+   i40iw_debug(cm_core->dev,
+   I40IW_DEBUG_CM,
+   "%s allocate event work queue failed\n",
+   __func__);
+   }
 
cm_core->disconn_wq = alloc_ordered_workqueue("iwdwq",
  WQ_MEM_RECLAIM);
+   if (!cm_core->disconn_wq) {
+   i40iw_debug(cm_core->dev,
+   I40IW_DEBUG_CM,
+   "%s allocate disconnect work queue failed\n",
+   __func__);
+   }
 }
 
 /**
-- 
2.17.1



[PATCH] infiniband: cxgb4: fix a potential NULL pointer dereference

2019-03-08 Thread Kangjie Lu
get_skb may fail and return NULL. The fix returns "ENOMEM"
when it fails to avoid NULL dereference.

Signed-off-by: Kangjie Lu 
---
 drivers/infiniband/hw/cxgb4/cm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c
index 8221813219e5..502a54d57e2c 100644
--- a/drivers/infiniband/hw/cxgb4/cm.c
+++ b/drivers/infiniband/hw/cxgb4/cm.c
@@ -1919,6 +1919,9 @@ static int send_fw_act_open_req(struct c4iw_ep *ep, 
unsigned int atid)
int win;
 
skb = get_skb(NULL, sizeof(*req), GFP_KERNEL);
+   if (!skb)
+   return -ENOMEM;
+
req = __skb_put_zero(skb, sizeof(*req));
req->op_compl = htonl(WR_OP_V(FW_OFLD_CONNECTION_WR));
req->len16_pkd = htonl(FW_WR_LEN16_V(DIV_ROUND_UP(sizeof(*req), 16)));
-- 
2.17.1



[PATCH] iio: hmc: fix a potential NULL pointer dereference

2019-03-08 Thread Kangjie Lu
devm_regmap_init_i2c may fail and return NULL. The fix returns
the error when it fails.

Signed-off-by: Kangjie Lu 
---
 drivers/iio/magnetometer/hmc5843_i2c.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/magnetometer/hmc5843_i2c.c 
b/drivers/iio/magnetometer/hmc5843_i2c.c
index 3de7f4426ac4..c0cd0823f8d5 100644
--- a/drivers/iio/magnetometer/hmc5843_i2c.c
+++ b/drivers/iio/magnetometer/hmc5843_i2c.c
@@ -58,8 +58,13 @@ static const struct regmap_config hmc5843_i2c_regmap_config 
= {
 static int hmc5843_i2c_probe(struct i2c_client *cli,
 const struct i2c_device_id *id)
 {
+   struct regmap *devm_regmap = devm_regmap_init_i2c(cli,
+   _i2c_regmap_config);
+   if (IS_ERR(devm_regmap))
+   return PTR_ERR(devm_regmap);
+
return hmc5843_common_probe(>dev,
-   devm_regmap_init_i2c(cli, _i2c_regmap_config),
+   devm_regmap,
id->driver_data, id->name);
 }
 
-- 
2.17.1



RE: [PATCH V1 07/11] mmc: cqhci: add quirk for setting DCMD CMD_TIMING

2019-03-08 Thread Sowjanya Komatineni
> On 7/03/19 8:16 PM, Sowjanya Komatineni wrote:
>> 
>>> On 3/6/2019 6:30 PM, Adrian Hunter wrote:
 On 2/03/19 7:20 AM, Sowjanya Komatineni wrote:
> This patch adds a quirk for setting CMD_TIMING to 1 in descriptor 
> for DCMD with R1B response type to allow the command to be sent to 
> device during data activity or busy time.
>
> Tegra186 CQHCI host has bug where it selects DATA_PRESENT_SELECT to 
> 1 by CQHCI controller for DCMDs with R1B response type and since 
> DCMD does not trigger any data transfer, DCMD task complete happens 
> leaving the DATA FSM of host controller in wait state for data.
>
> This effects the data transfer task issued after R1B DCMD task and 
> no interrupt is generated for the data transfer task.
>
> SW WAR for this issue is to set CMD_TIMING bit to 1 in DCMD task 
> descriptor and as DCMD task descriptor preparation is done by cqhci 
> driver, this patch adds cqequirk to handle this.
>
> Signed-off-by: Sowjanya Komatineni 
> ---
>   drivers/mmc/host/cqhci.c | 5 -
>   drivers/mmc/host/cqhci.h | 1 +
>   2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/host/cqhci.c 
> index a8af682a9182..b34c07125f32 100644
> --- a/drivers/mmc/host/cqhci.c
> +++ b/drivers/mmc/host/cqhci.c
> @@ -521,7 +521,10 @@ static void cqhci_prep_dcmd_desc(struct mmc_host 
> *mmc,
>   } else {
>   if (mrq->cmd->flags & MMC_RSP_R1B) {
>   resp_type = 0x3;
> - timing = 0x0;
> + if (cq_host->quirks & CQHCI_QUIRK_CMD_TIMING_R1B_DCMD)
> + timing = 0x1;
> + else
> + timing = 0x0;
 I was thinking it would be nice if there was a generic way for 
 drivers to make changes to descriptors before a task is started.  
 Currently there is
 host->ops->write_l() which would make it possible by checking for 
 host->ops->CQHCI_TDBR
 register and, in this case, the DCMD tag.  We would need to export 
 get_desc(), perhaps rename it cqhci_get_desc() and put it in cqhci.h 
 since it is an inline function.
>>>
>>> We take spin_lock_irqsave after the descriptor is prepared and before 
>>> writing to TDBR.
>>> Not sure but tomorrow this may become a limitation for drivers to make 
>>> changes to descriptors if they edit descriptors in host->ops->write_l() 
>>> call.
>>> Though in this case it is not required here.
>>>

 Alternatively we could add host->ops for descriptor preparation.
>>>
>>> Both ways sounds good to me.
>>> But maybe adding a host->ops for descriptor preparation is better way 
>>> to go, since that will be the right interface exposed to make changes 
>>> to descriptors.
>>>
>> 
>> DCMD descriptor attributes remain same for any host and also task parameters 
>> as QBR need to be enabled with DCMD.
>> So I believe it should be ok if we just add callback to allow hosts to 
>> update command parameters of DCMD descriptor only thru cqhci_host_ops.
>
>That sounds fine to me.  Maybe do that for the next version of this patchset.

Thanks Adrian. Actually, DCMD command parameters include opcode, timing, and 
response type where opcode and response type stays same.
So I only see need for hosts to choose cmd timing to control if hardware should 
wait for busy time or not basically to send command during busy or idle time.

Will add cqhci_host_ops interface to allow host driver to choose cmd timing and 
will send along with the other tuning related feedback fixes of this series.

>> 
>> Also, don’t see any requirement for host specific Task parameter updates in 
>> Task descriptor so not sure if there is any need to provide callback for 
>> task descriptor data preparation to hosts.
>> Please confirm.
>> 

 What do people think?

>   } else {
>   resp_type = 0x2;
>   timing = 0x1;
> diff --git a/drivers/mmc/host/cqhci.h b/drivers/mmc/host/cqhci.h 
> index 9e68286a07b4..f96d8565cc07 100644
> --- a/drivers/mmc/host/cqhci.h
> +++ b/drivers/mmc/host/cqhci.h
> @@ -170,6 +170,7 @@ struct cqhci_host {
>   
>   u32 quirks;
>   #define CQHCI_QUIRK_SHORT_TXFR_DESC_SZ  0x1
> +#define CQHCI_QUIRK_CMD_TIMING_R1B_DCMD  0x2
>   
>   bool enabled;
>   bool halted;
>



[PATCH] iio: adc: fix a potential NULL pointer dereference

2019-03-08 Thread Kangjie Lu
devm_iio_trigger_alloc may fail and return NULL. The fix returns
ENOMEM when it fails.

Signed-off-by: Kangjie Lu 
---
 drivers/iio/adc/mxs-lradc-adc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iio/adc/mxs-lradc-adc.c b/drivers/iio/adc/mxs-lradc-adc.c
index c627513d9f0f..5384472b6c4d 100644
--- a/drivers/iio/adc/mxs-lradc-adc.c
+++ b/drivers/iio/adc/mxs-lradc-adc.c
@@ -465,6 +465,8 @@ static int mxs_lradc_adc_trigger_init(struct iio_dev *iio)
 
trig = devm_iio_trigger_alloc(>dev, "%s-dev%i", iio->name,
  iio->id);
+   if (!trig)
+   return -ENOMEM;
 
trig->dev.parent = adc->dev;
iio_trigger_set_drvdata(trig, iio);
-- 
2.17.1



[PATCH] iio: max9611: fix a NULL pointer dereference

2019-03-08 Thread Kangjie Lu
of_match_device may return NULL when it fails, and in this case,
there will be a NULL pointer dereference. The fix returns
EINVAL when of_match_device returns NULL.

Signed-off-by: Kangjie Lu 
---
 drivers/iio/adc/max9611.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/max9611.c b/drivers/iio/adc/max9611.c
index 917223d5ff5b..531b6614ea29 100644
--- a/drivers/iio/adc/max9611.c
+++ b/drivers/iio/adc/max9611.c
@@ -524,13 +524,16 @@ static int max9611_probe(struct i2c_client *client,
 {
const char * const shunt_res_prop = "shunt-resistor-micro-ohms";
const struct device_node *of_node = client->dev.of_node;
-   const struct of_device_id *of_id =
-   of_match_device(max9611_of_table, >dev);
+   const struct of_device_id *of_id;
struct max9611_dev *max9611;
struct iio_dev *indio_dev;
unsigned int of_shunt;
int ret;
 
+   of_id = of_match_device(max9611_of_table, >dev);
+   if (!of_id)
+   return -EINVAL;
+
indio_dev = devm_iio_device_alloc(>dev, sizeof(*max9611));
if (!indio_dev)
return -ENOMEM;
-- 
2.17.1



Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

2019-03-08 Thread James Morris
On Fri, 8 Mar 2019, Matthew Garrett wrote:

> On Fri, Mar 8, 2019 at 3:00 PM James Morris  wrote:
> >
> > On Wed, 6 Mar 2019, Matthew Garrett wrote:
> >
> > > From: David Howells 
> > >
> > > If the kernel is locked down, require that all modules have valid
> > > signatures that we can verify.
> >
> > Perhaps note that this won't cover the case where folk are using DM-Verity
> > with a signed root hash for verifying kernel modules.
> 
> Mm. I can't see a terribly good way of doing this generically -
> loadpin gives no indication to the module loading code that it comes
> from a trusted source. Would making the lockdown/module signature
> enforcement a separate config option be reasonable?

I was just suggest documenting this.

-- 
James Morris




[PATCH] hid: logitech: check the return value of create_singlethread_workqueue

2019-03-08 Thread Kangjie Lu
create_singlethread_workqueue may fail and return NULL. The fix
checks if it is NULL to avoid NULL pointer dereference.

Signed-off-by: Kangjie Lu 
---
 drivers/hid/hid-logitech-hidpp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 15ed6177a7a3..efbc39b92aa2 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -2156,6 +2156,9 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8 
feature_index)
 
/* init the hardware command queue */
data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue");
+   if (!data->wq)
+   return -ENOMEM;
+
atomic_set(>workqueue_size, 0);
 
/* initialize with zero autocenter to get wheel in usable state */
-- 
2.17.1



[PATCH] drm: vkms: check status of alloc_ordered_workqueue

2019-03-08 Thread Kangjie Lu
alloc_ordered_workqueue may fail and return NULL.
The fix returns ENOMEM when it fails to avoid potential NULL
pointer dereference.

Signed-off-by: Kangjie Lu 
---
 drivers/gpu/drm/vkms/vkms_crtc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 8a9aeb0a9ea8..bb66dbcd5e3f 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -219,6 +219,8 @@ int vkms_crtc_init(struct drm_device *dev, struct drm_crtc 
*crtc,
spin_lock_init(_out->state_lock);
 
vkms_out->crc_workq = alloc_ordered_workqueue("vkms_crc_workq", 0);
+   if (!vkms_out->crc_workq)
+   return -ENOMEM;
 
return ret;
 }
-- 
2.17.1



[PATCH] drm: check if alloc_workqueue fails

2019-03-08 Thread Kangjie Lu
alloc_workqueue may fail. The fix checks its status. We probably
need to add a return value for radeon_crtc_init, so that we can
pass an error code upstream.

Signed-off-by: Kangjie Lu 
---
 drivers/gpu/drm/radeon/radeon_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index aa898c699101..16f95bde8c2e 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -678,6 +678,8 @@ static void radeon_crtc_init(struct drm_device *dev, int 
index)
drm_mode_crtc_set_gamma_size(_crtc->base, 256);
radeon_crtc->crtc_id = index;
radeon_crtc->flip_queue = alloc_workqueue("radeon-crtc", WQ_HIGHPRI, 0);
+   if (!radeon_crtc->flip_queue)
+   DRM_ERROR("failed to allocate the flip queue\n");
rdev->mode_info.crtcs[index] = radeon_crtc;
 
if (rdev->family >= CHIP_BONAIRE) {
-- 
2.17.1



[PATCH] gpu: i915: fix a missing check of get_free_page

2019-03-08 Thread Kangjie Lu
If the allocation fails, return false to avoid potential
NULL pointer dereference

Signed-off-by: Kangjie Lu 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9a65341fec09..ad54fc3551df 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -227,8 +227,11 @@ static bool compress_init(struct compress *c)
}
 
c->tmp = NULL;
-   if (i915_has_memcpy_from_wc())
+   if (i915_has_memcpy_from_wc()) {
c->tmp = (void *)__get_free_page(GFP_ATOMIC | __GFP_NOWARN);
+   if (!c->tmp)
+   return false;
+   }
 
return true;
 }
-- 
2.17.1



[PATCH] gpu: amdkfd: fix a missing check of kmemdup

2019-03-08 Thread Kangjie Lu
kmemdup could fail and return NULL. To avoid null pointer
dereference, the fix checkes its return value and returns
ENOMEM upon failures.

Signed-off-by: Kangjie Lu 
---
 drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
index 2e7c44955f43..7ef62d4e7598 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
@@ -404,6 +404,9 @@ static int kfd_parse_subtype_iolink(struct 
crat_subtype_iolink *iolink,
return -ENODEV;
/* same everything but the other direction */
props2 = kmemdup(props, sizeof(*props2), GFP_KERNEL);
+   if (!props2)
+   return -ENOMEM;
+
props2->node_from = id_to;
props2->node_to = id_from;
props2->kobj = NULL;
-- 
2.17.1



Re: [PATCH] workqueue: unregister wq lockdep on error path in alloc_workqueue()

2019-03-08 Thread Kefeng Wang


On 2019/3/8 22:45, Bart Van Assche wrote:
> On 3/7/19 11:37 PM, Kefeng Wang wrote:
>> syzkaller report an issue "KASAN: use-after-free Read in alloc_workqueue",
>>
>> alloc_workqueue
>>   - kzalloc wq
>>   - wq_init_lockdep(wq);
>>     - lockdep_register_key(>key);  // add to hlist
>>   - kfree wq
>>
>> But forget to call wq_unregister_lockdep()->lockdep_unregister_key(), it
>> will delete the entry from hlist.
>>
>> Reported-by: syzbot+17335689e239ce135...@syzkaller.appspotmail.com
>> Fixes: 669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys for 
>> workqueues")
>> Signed-off-by: Kefeng Wang 
>> ---
>>   kernel/workqueue.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>> index 7abbeed13421..9209d25dfade 100644
>> --- a/kernel/workqueue.c
>> +++ b/kernel/workqueue.c
>> @@ -4291,6 +4291,7 @@ struct workqueue_struct *alloc_workqueue(const char 
>> *fmt,
>>   return wq;
>>     err_free_wq:
>> +    wq_unregister_lockdep(wq);
>>   free_workqueue_attrs(wq->unbound_attrs);
>>   kfree(wq);
>>   return NULL;
>
> Hi Kefeng,
>
> Five days ago I had posted a similar but slightly different patch. Can you 
> have a look at it? See also 
> https://lore.kernel.org/lkml/20190303220046.29448-1-bvanass...@acm.org/  
I don't notice your patch due to no subscribe lkml,  that is better, 
wq->lock_name should be freed too; )
>
> Thanks,
>
> Bart.
>
>
>
> .
>



[PATCH] gpio: add a check for the return value of ida_simple_get fails

2019-03-08 Thread Kangjie Lu
ida_simple_get may fail and return a negative error number.
The fix checks its return value; if it fails, go to err_destroy.

Signed-off-by: Kangjie Lu 
---
 drivers/gpio/gpio-exar.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 0ecd2369c2ca..a09d2f9ebacc 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -148,6 +148,8 @@ static int gpio_exar_probe(struct platform_device *pdev)
mutex_init(_gpio->lock);
 
index = ida_simple_get(_index, 0, 0, GFP_KERNEL);
+   if (index < 0)
+   goto err_destroy;
 
sprintf(exar_gpio->name, "exar_gpio%d", index);
exar_gpio->gpio_chip.label = exar_gpio->name;
-- 
2.17.1



Re: [PATCH v2 1/3] arm64: mm: use appropriate ctors for page tables

2019-03-08 Thread Yu Zhao
On Tue, Feb 26, 2019 at 03:12:31PM +, Mark Rutland wrote:
> Hi,
> 
> On Mon, Feb 18, 2019 at 04:13:17PM -0700, Yu Zhao wrote:
> > For pte page, use pgtable_page_ctor(); for pmd page, use
> > pgtable_pmd_page_ctor() if not folded; and for the rest (pud,
> > p4d and pgd), don't use any.
> > 
> > Signed-off-by: Yu Zhao 
> > ---
> >  arch/arm64/mm/mmu.c | 33 +
> >  1 file changed, 21 insertions(+), 12 deletions(-)
> 
> [...]
> 
> > -static phys_addr_t pgd_pgtable_alloc(void)
> > +static phys_addr_t pgd_pgtable_alloc(int shift)
> >  {
> > void *ptr = (void *)__get_free_page(PGALLOC_GFP);
> > -   if (!ptr || !pgtable_page_ctor(virt_to_page(ptr)))
> > -   BUG();
> > +   BUG_ON(!ptr);
> > +
> > +   /*
> > +* Initialize page table locks in case later we need to
> > +* call core mm functions like apply_to_page_range() on
> > +* this pre-allocated page table.
> > +*/
> > +   if (shift == PAGE_SHIFT)
> > +   BUG_ON(!pgtable_page_ctor(virt_to_page(ptr)));
> > +   else if (shift == PMD_SHIFT && PMD_SHIFT != PUD_SHIFT)
> > +   BUG_ON(!pgtable_pmd_page_ctor(virt_to_page(ptr)));
> 
> IIUC, this is for nopmd kernels, where we only have real PGD and PTE
> levels of table. From my PoV, that would be clearer if we did:
> 
>   else if (shift == PMD_SHIFT && !is_defined(__PAGETABLE_PMD_FOLDED))
> 
> ... though IMO it would be a bit nicer if the generic
> pgtable_pmd_page_ctor() were nop'd out for __PAGETABLE_PMD_FOLDED
> builds, so that callers don't have to be aware of folding.

Agreed. Will make pgtable_pmd_page_ctor() nop when pmd is folded.

> I couldn't think of a nicer way of distinguishing levels of table, and
> having separate function pointers for each level seems over-the-top, so
> otehr than that this looks good to me.
> 
> Assuming you're happy with the above change:
> 
> Acked-by: Mark Rutland 
> 
> Thanks,
> Mark.


[PATCH] firmware: arm_scmi: check return value of idr_find

2019-03-08 Thread Kangjie Lu
idr_find may return NULL, so check its return value and return an
error code.

Signed-off-by: Kangjie Lu 
---
 drivers/firmware/arm_scmi/driver.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/firmware/arm_scmi/driver.c 
b/drivers/firmware/arm_scmi/driver.c
index 8f952f2f1a29..35faa203d549 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -709,6 +709,8 @@ scmi_mbox_chan_setup(struct scmi_info *info, struct device 
*dev, int prot_id)
 
if (scmi_mailbox_check(np)) {
cinfo = idr_find(>tx_idr, SCMI_PROTOCOL_BASE);
+   if (!cinfo)
+   return -EINVAL;
goto idr_alloc;
}
 
-- 
2.17.1



RE: [RFC net-next v1 1/3] vfio/mdev: Inherit dma masks of parent device

2019-03-08 Thread Parav Pandit



> -Original Message-
> From: Alex Williamson 
> Sent: Friday, March 8, 2019 4:33 PM
> To: Parav Pandit 
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> michal.l...@markovi.net; da...@davemloft.net;
> gre...@linuxfoundation.org; Jiri Pirko ;
> kwankh...@nvidia.com; Vu Pham ; Yuval Avnery
> ; jakub.kicin...@netronome.com;
> k...@vger.kernel.org
> Subject: Re: [RFC net-next v1 1/3] vfio/mdev: Inherit dma masks of parent
> device
> 
> On Fri,  8 Mar 2019 16:07:54 -0600
> Parav Pandit  wrote:
> 
> > Inherit dma mask of parent device in child mdev devices, so that
> > protocol stack can use right dma mask while doing dma mappings.
> >
> > Signed-off-by: Parav Pandit 
> > ---
> >  drivers/vfio/mdev/mdev_core.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/vfio/mdev/mdev_core.c
> > b/drivers/vfio/mdev/mdev_core.c index 0212f0e..9b8bdc9 100644
> > --- a/drivers/vfio/mdev/mdev_core.c
> > +++ b/drivers/vfio/mdev/mdev_core.c
> > @@ -315,6 +315,10 @@ int mdev_device_create(struct kobject *kobj,
> struct device *dev, uuid_le uuid)
> > mdev->dev.parent  = dev;
> > mdev->dev.bus = _bus_type;
> > mdev->dev.release = mdev_device_release;
> > +   mdev->dev.dma_mask = dev->dma_mask;
> > +   mdev->dev.dma_parms = dev->dma_parms;
> > +   mdev->dev.coherent_dma_mask = dev->coherent_dma_mask;
> > +
> > dev_set_name(>dev, "%pUl", uuid.b);
> >
> > ret = device_register(>dev);
> 
> This seems like a rather large assumption and none of the existing mdev
> drivers even make use of DMA ops.
So its non-harmful anyway.

> Why shouldn't this be done in mdev_parent_ops.create?  Thanks,
> 
Struct device should be setup correctly before calling device_register().
That is the sane way to access device_register() API.
Doing this under mdev_parent_ops.create() will do it after device_register().
If you want to make it optional, mdev_register_device() can pass a bool flag to 
setup dma params or not which can be applied conditionally in 
mdev_device_create() before device_register().


Re: [PATCH v2 2/3] arm64: mm: don't call page table ctors for init_mm

2019-03-08 Thread Yu Zhao
On Tue, Feb 26, 2019 at 03:13:07PM +, Mark Rutland wrote:
> Hi,
> 
> On Mon, Feb 18, 2019 at 04:13:18PM -0700, Yu Zhao wrote:
> > init_mm doesn't require page table lock to be initialized at
> > any level. Add a separate page table allocator for it, and the
> > new one skips page table ctors.
> 
> Just to check, in a previous reply you mentioned we need to call the
> ctors for our efi_mm, since we use apply_to_page_range() on that. Is
> that only because apply_to_pte_range() tries to take the ptl for non
> init_mm?

Precisely.

> ... or did I miss something else?
> 
> > The ctors allocate memory when ALLOC_SPLIT_PTLOCKS is set. Not
> > calling them avoids memory leak in case we call pte_free_kernel()
> > on init_mm.
> > 
> > Signed-off-by: Yu Zhao 
> 
> Assuming that was all, this patch makes sense to me. FWIW:
> 
> Acked-by: Mark Rutland 

Thanks.

> Thanks,
> Mark.
> 
> > ---
> >  arch/arm64/mm/mmu.c | 15 +--
> >  1 file changed, 13 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index fa7351877af3..e8bf8a6300e8 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -370,6 +370,16 @@ static void __create_pgd_mapping(pgd_t *pgdir, 
> > phys_addr_t phys,
> > } while (pgdp++, addr = next, addr != end);
> >  }
> >  
> > +static phys_addr_t pgd_kernel_pgtable_alloc(int shift)
> > +{
> > +   void *ptr = (void *)__get_free_page(PGALLOC_GFP);
> > +   BUG_ON(!ptr);
> > +
> > +   /* Ensure the zeroed page is visible to the page table walker */
> > +   dsb(ishst);
> > +   return __pa(ptr);
> > +}
> > +
> >  static phys_addr_t pgd_pgtable_alloc(int shift)
> >  {
> > void *ptr = (void *)__get_free_page(PGALLOC_GFP);
> > @@ -591,7 +601,7 @@ static int __init map_entry_trampoline(void)
> > /* Map only the text into the trampoline page table */
> > memset(tramp_pg_dir, 0, PGD_SIZE);
> > __create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
> > -prot, pgd_pgtable_alloc, 0);
> > +prot, pgd_kernel_pgtable_alloc, 0);
> >  
> > /* Map both the text and data into the kernel page table */
> > __set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
> > @@ -1067,7 +1077,8 @@ int arch_add_memory(int nid, u64 start, u64 size, 
> > struct vmem_altmap *altmap,
> > flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
> >  
> > __create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
> > -size, PAGE_KERNEL, pgd_pgtable_alloc, flags);
> > +size, PAGE_KERNEL, pgd_kernel_pgtable_alloc,
> > +flags);
> >  
> > return __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT,
> >altmap, want_memblock);
> > -- 
> > 2.21.0.rc0.258.g878e2cd30e-goog
> > 


[PATCH] char: hpet: fix a missing check of ioremap

2019-03-08 Thread Kangjie Lu
Check if ioremap fails, and if so, return AE_ERROR.

Signed-off-by: Kangjie Lu 
---
 drivers/char/hpet.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index d0ad85900b79..3a1e6b3ccd10 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -973,6 +973,8 @@ static acpi_status hpet_resources(struct acpi_resource 
*res, void *data)
if (ACPI_SUCCESS(status)) {
hdp->hd_phys_address = addr.address.minimum;
hdp->hd_address = ioremap(addr.address.minimum, 
addr.address.address_length);
+   if (!hdp->hd_address)
+   return AE_ERROR;
 
if (hpet_is_known(hdp)) {
iounmap(hdp->hd_address);
-- 
2.17.1



[PATCH] can: af_can: Fix possible NULL pointer dereference in can_exit

2019-03-08 Thread Yue Haibing
From: YueHaibing 

Syzkaller report this:

kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN PTI
CPU: 0 PID: 9400 Comm: syz-executor.0 Tainted: G C5.0.0-rc8+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 
04/01/2014
RIP: 0010:__list_del include/linux/list.h:105 [inline]
RIP: 0010:__list_del_entry include/linux/list.h:120 [inline]
RIP: 0010:list_del include/linux/list.h:125 [inline]
RIP: 0010:__unregister_pernet_operations net/core/net_namespace.c:1075 [inline]
RIP: 0010:unregister_pernet_operations+0x124/0x540 net/core/net_namespace.c:1137
Code: 89 c1 48 c1 e9 03 80 3c 11 00 0f 85 38 03 00 00 48 8d 7d 08 48 ba 00 00 
00 00 00 fc ff df 4d 8b 7c 24 08 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f 85 02 03 
00 00 48 8d 9c 24 b8 00 00 00 48 ba 00 00
RSP: 0018:8881b871fbb0 EFLAGS: 00010a06
RAX: c198c4c8 RBX: dc00 RCX: 1bd5a021
RDX: dc00 RSI: c900014c4000 RDI: dead0108
RBP: dead0100 R08: 0001 R09: 
R10: 8881b871fb30 R11:  R12: c198c4c0
R13: 8881b871fbe8 R14: 1110370e3f79 R15: dead0200
FS:  7f029df32700() GS:8881f700() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ffc85454218 CR3: 0001e0ff4004 CR4: 007606f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
PKRU: 5554
Call Trace:
 unregister_pernet_subsys+0x1d/0x30 net/core/net_namespace.c:1184
 can_exit+0x3f/0x56 [can]
 __do_sys_delete_module kernel/module.c:1018 [inline]
 __se_sys_delete_module kernel/module.c:961 [inline]
 __x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961
 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 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 73 01 
c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:7f029df31c58 EFLAGS: 0246 ORIG_RAX: 00b0
RAX: ffda RBX: 0073bf00 RCX: 00462e99
RDX:  RSI:  RDI: 20c0
RBP: 0002 R08:  R09: 
R10:  R11: 0246 R12: 7f029df326bc
R13: 004bcca9 R14: 006f6b48 R15: 

register_pernet_subsys may fails in can_init,then can_exit calls
unregister_pernet_subsys when unloading, it can trigger a NULL
pointer dereference while doing list_del.This patch fix error
cleanup path of can_init to avoid this.

Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
---
 net/can/af_can.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/net/can/af_can.c b/net/can/af_can.c
index 1684ba5..5d75685 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -958,6 +958,8 @@ static struct pernet_operations can_pernet_ops 
__read_mostly = {
 
 static __init int can_init(void)
 {
+   int rc;
+
/* check for correct padding to be able to use the structs similarly */
BUILD_BUG_ON(offsetof(struct can_frame, can_dlc) !=
 offsetof(struct canfd_frame, len) ||
@@ -971,15 +973,31 @@ static __init int can_init(void)
if (!rcv_cache)
return -ENOMEM;
 
-   register_pernet_subsys(_pernet_ops);
+   rc = register_pernet_subsys(_pernet_ops);
+   if (rc)
+   goto free_cache;
 
/* protocol register */
-   sock_register(_family_ops);
-   register_netdevice_notifier(_netdev_notifier);
+   rc = sock_register(_family_ops);
+   if (rc)
+   goto unregister_pernet;
+
+   rc = register_netdevice_notifier(_netdev_notifier);
+   if (rc)
+   goto sock_unregister;
+
dev_add_pack(_packet);
dev_add_pack(_packet);
 
return 0;
+
+sock_unregister:
+   sock_unregister(PF_CAN);
+unregister_pernet:
+   unregister_pernet_subsys(_pernet_ops);
+free_cache:
+   kmem_cache_destroy(rcv_cache);
+   return rc;
 }
 
 static __exit void can_exit(void)
-- 
2.7.0




Re: [PATCH] rcu/tree_plugin: Fix nohz status in stall warning

2019-03-08 Thread Neeraj Upadhyay




On 3/9/19 2:48 AM, Paul E. McKenney wrote:

On Fri, Mar 08, 2019 at 11:51:49PM +0530, Neeraj Upadhyay wrote:

Fix stall warning, to show correct nohz marker.

Signed-off-by: Neeraj Upadhyay 


Good eyes, thank you!

I applied and pushed all three with modified commit logs.  Please check
to make sure that I didn't mess anything up.  If testing and reviews
are OK, I expect to submit them for the v5.2 merge window.

I had to hand-apply this one, so in future patches could you please
generate them against -rcu?  It may be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git

Thanx, Paul



Thanks Paul, I reviewed the patches on -rcu; they look good. Thanks for 
applying them! I will move my codebase to  -rcu, for all future work.


Thanks
Neeraj


---
  kernel/rcu/tree_plugin.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 97dba50..93da32c 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1659,7 +1659,7 @@ static void print_cpu_stall_fast_no_hz(char *cp, int cpu)
rdp->last_accelerate & 0x, jiffies & 0x,
".l"[rdp->all_lazy],
".L"[!rcu_segcblist_n_nonlazy_cbs(>cblist)],
-   ".D"[!rdp->tick_nohz_enabled_snap]);
+   ".D"[!!rdp->tick_nohz_enabled_snap]);
  }

  #else /* #ifdef CONFIG_RCU_FAST_NO_HZ */
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation





--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation


[PATCH] net: ixgbevf: fix a missing check of ixgbevf_write_msg_read_ack

2019-03-08 Thread Kangjie Lu
If ixgbevf_write_msg_read_ack fails, return its error code upstream

Signed-off-by: Kangjie Lu 
---
 drivers/net/ethernet/intel/ixgbevf/vf.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c 
b/drivers/net/ethernet/intel/ixgbevf/vf.c
index cd3b81300cc7..d5ce49636548 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -508,9 +508,8 @@ static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw 
*hw,
vector_list[i++] = ixgbevf_mta_vector(hw, ha->addr);
}
 
-   ixgbevf_write_msg_read_ack(hw, msgbuf, msgbuf, IXGBE_VFMAILBOX_SIZE);
-
-   return 0;
+   return ixgbevf_write_msg_read_ack(hw, msgbuf, msgbuf,
+   IXGBE_VFMAILBOX_SIZE);
 }
 
 /**
-- 
2.17.1



Re: Smarter Kconfig help

2019-03-08 Thread Randy Dunlap
On 3/6/19 12:22 PM, Russell King - ARM Linux admin wrote:
> On Wed, Mar 06, 2019 at 09:16:02PM +0100, Enrico Weigelt, metux IT consult 
> wrote:
>> On 06.03.19 13:42, Russell King - ARM Linux admin wrote:
>>
>>> In case it isn't clear, this is the *exact* point here - I don't know> 
>>> whether this option should be enabled for iMX6 or not, and the only>
>> way I found out was to grep the dts files in arch/arm/boot/dts for> the
>> driver's compatible string.  What that reveals is that *no* 32-bit> dts
>> files contain the compatible string, and so I summise that *no*> 32-bit
>> iMX SoC should have this driver enabled.
>> The problem is a bit more generic. I often have to spend lots of time
>> to find out which configs to enable on a specific board, to get certain
>> features (eg. network, sata, display, gpu, ...). Even worse: many
>> options require other stuff enabled before even showing up. And when
>> disabling unneeded stuff, it leaves lots of other things enabled.
>> (we don't have some `apt autoremove` kconfig counterpart :().
>>
>> I've decided to cope w/ that on a higher level and written a little
>> config generator tool for that - here you can enable high level
>> features (eg. 'network' or 'display', etc) and it will generate the
>> actual .config:
>>
>>  https://github.com/metux/kmct
>>
>>> The excuse that "we can't list the explicit SoCs" to me seems to be> a very 
>>> lame excuse
>>
>> Maybe this actually means "nobody here volounteered to actually maintain
>> these help texts" ?
>>
>>> The best that I can come up with right now, given what little I know> from 
>>> grepping the 32-bit DTS files, is that the help text should at>
>> least indicate that it *isn't* applicable to 32-bit SoCs, or if you>
>> prefer, *is* applicable to 64-bit SoCs.  Beyond that, I have no>
>> information to formulate a better suggestion.
>> Perhaps just fix the text based on your knowledge and send a patch to
>> the maintainers. They'll propably tell you if it's incorrect.
> 
> Frankly, no.  I don't want to be going round endlessly writing help
> texts.
> 
> We need the effort to be properly distributed - we need those who
> _know_ the feature they're developing to write a proper help text.
> One way to achieve that is to make a proper informative help text
> a pre-requisit of accepting the code.

Ack.

> The quality of the help text is just as important as the quality of
> the code, and we really should be paying the same amount of attention
> to both.

It goes much further than this IMHO, such as:

- #including the needed header files and not #including header files that
  are not used.

- using the correct Kconfig dependencies and selects

- testing builds with multiple kconfig settings (as applicable)

- builds should be clean, and that means without newly added warnings as
  well as build errors

I.e., the build testing that the 0day kernel robot does and that Arnd
and I do and that a few other people do should not catch nearly as many build
problems as they do.  The developer who knows the code should put due
diligence into the entire package, not just the (driver) source code and
building/testing with one default config.


Documentation/process/submit-checklist.rst has a more thorough list.


-- 
~Randy


[PATCH 1/5] lib/sort: Make swap functions more generic

2019-03-08 Thread George Spelvin
Rather than u32_swap and u64_swap working on 4- and 8-byte objects
directly, let them handle any multiple of 4 or 8 bytes.  This speeds
up most users of sort() by avoiding fallback to the byte copy loop.

Despite what commit ca96ab859ab4 ("lib/sort: Add 64 bit swap function")
claims, very few users of sort() sort pointers (or pointer-sized
objects); most sort structures containing at least two words.
(E.g. drivers/acpi/fan.c:acpi_fan_get_fps() sorts an array of 40-byte
struct acpi_fan_fps.)

x86-64 code size 872 -> 885 bytes (+8)

Signed-off-by: George Spelvin 
---
 lib/sort.c | 117 +++--
 1 file changed, 96 insertions(+), 21 deletions(-)

diff --git a/lib/sort.c b/lib/sort.c
index d6b7a202b0b6..dff2ab2e196e 100644
--- a/lib/sort.c
+++ b/lib/sort.c
@@ -11,35 +11,110 @@
 #include 
 #include 
 
-static int alignment_ok(const void *base, int align)
+/**
+ * alignment_ok - is this pointer & size okay for word-wide copying?
+ * @base: pointer to data
+ * @size: size of each element
+ * @align: required aignment (typically 4 or 8)
+ *
+ * Returns true if elements can be copied using word loads and stores.
+ * The size must be a multiple of the alignment, and the base address must
+ * be if we do not have CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS.
+ *
+ * For some reason, gcc doesn't know to optimize "if (a & mask || b & mask)"
+ * to "if ((a | b) & mask)", so we do that by hand.
+ */
+static bool __attribute_const__
+alignment_ok(const void *base, size_t size, unsigned int align)
 {
-   return IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) ||
-   ((unsigned long)base & (align - 1)) == 0;
+   unsigned int lsbits = (unsigned int)size;
+#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+   (void)base;
+#else
+   lsbits |= (unsigned int)(size_t)base;
+#endif
+   lsbits &= align - 1;
+   return lsbits == 0;
 }
 
+/**
+ * u32_swap - swap two elements in 32-bit chunks
+ * @a, @b: pointers to the elements
+ * @size: element size (must be a multiple of 4)
+ *
+ * Exchange the two objects in memory.  This exploits base+index addressing,
+ * which basically all CPUs have, to minimize loop overhead computations.
+ *
+ * For some reason, on x86 gcc 7.3.0 adds a redundant test of n at the
+ * bottom of the loop, even though the zero flag is stil valid from the
+ * subtract (since the intervening mov instructions don't alter the flags).
+ * Gcc 8.1.0 doesn't have that problem.
+ */
 static void u32_swap(void *a, void *b, int size)
 {
-   u32 t = *(u32 *)a;
-   *(u32 *)a = *(u32 *)b;
-   *(u32 *)b = t;
+   size_t n = size;
+
+   do {
+   u32 t = *(u32 *)(a + (n -= 4));
+   *(u32 *)(a + n) = *(u32 *)(b + n);
+   *(u32 *)(b + n) = t;
+   } while (n);
 }
 
+/**
+ * u64_swap - swap two elements in 64-bit chunks
+ * @a, @b: pointers to the elements
+ * @size: element size (must be a multiple of 8)
+ *
+ * Exchange the two objects in memory.  This exploits base+index
+ * addressing, which basically all CPUs have, to minimize loop overhead
+ * computations.
+ *
+ * We'd like to use 64-bit loads if possible.  If they're not, emulating
+ * one requires base+index+4 addressing which x86 has but most other
+ * processors do not.  If CONFIG_64BIT, we definitely have 64-bit loads,
+ * but it's possible to have 64-bit loads without 64-bit pointers (e.g.
+ * x32 ABI).  Are there any cases the kernel needs to worry about?
+ */
+
 static void u64_swap(void *a, void *b, int size)
 {
-   u64 t = *(u64 *)a;
-   *(u64 *)a = *(u64 *)b;
-   *(u64 *)b = t;
-}
-
-static void generic_swap(void *a, void *b, int size)
-{
-   char t;
+   size_t n = size;
 
do {
-   t = *(char *)a;
-   *(char *)a++ = *(char *)b;
-   *(char *)b++ = t;
-   } while (--size > 0);
+#ifdef CONFIG_64BIT
+   u64 t = *(u64 *)(a + (n -= 8));
+   *(u64 *)(a + n) = *(u64 *)(b + n);
+   *(u64 *)(b + n) = t;
+#else
+   /* Use two 32-bit transfers to avoid base+index+4 addressing */
+   u32 t = *(u32 *)(a + (n -= 4));
+   *(u32 *)(a + n) = *(u32 *)(b + n);
+   *(u32 *)(b + n) = t;
+
+   t = *(u32 *)(a + (n -= 4));
+   *(u32 *)(a + n) = *(u32 *)(b + n);
+   *(u32 *)(b + n) = t;
+#endif
+   } while (n);
+}
+
+/**
+ * generic_swap - swap two elements a byte at a time
+ * @a, @b: pointers to the elements
+ * @size: element size
+ *
+ * This is the fallback if alignment doesn't allow using larger chunks.
+ */
+static void generic_swap(void *a, void *b, int size)
+{
+   size_t n = size;
+
+   do {
+   char t = ((char *)a)[--n];
+   ((char *)a)[n] = ((char *)b)[n];
+   ((char *)b)[n] = t;
+   } while (n);
 }
 
 /**
@@ -67,10 +142,10 @@ void sort(void *base, size_t num, size_t size,
int i = (num/2 - 1) * size, n = 

[PATCH 4/5] lib/list_sort: Simplify and remove MAX_LIST_LENGTH_BITS

2019-03-08 Thread George Spelvin
Rather than a fixed-size array of pending sorted runs, use the ->prev
links to keep track of things.  This reduces stack usage, eliminates
some ugly overflow handling, and reduces the code size.

Also:
* merge() no longer needs to handle NULL inputs, so simplify.
* The same applies to merge_and_restore_back_links(), which is renamed
  to the less ponderous merge_final().  (It's a static helper function,
  so we don't need a super-descriptive name; comments will do.)

x86-64 code size 1086 -> 740 bytes (-346)

(Yes, I see checkpatch complaining about no space after comma in
"__attribute__((nonnull(2,3,4,5)))".  Checkpatch is wrong.)

Signed-off-by: George Spelvin 
---
 include/linux/list_sort.h |   1 +
 lib/list_sort.c   | 152 --
 2 files changed, 96 insertions(+), 57 deletions(-)

diff --git a/include/linux/list_sort.h b/include/linux/list_sort.h
index ba79956e848d..20f178c24e9d 100644
--- a/include/linux/list_sort.h
+++ b/include/linux/list_sort.h
@@ -6,6 +6,7 @@
 
 struct list_head;
 
+__attribute__((nonnull(2,3)))
 void list_sort(void *priv, struct list_head *head,
   int (*cmp)(void *priv, struct list_head *a,
  struct list_head *b));
diff --git a/lib/list_sort.c b/lib/list_sort.c
index 85759928215b..e4819ef0426b 100644
--- a/lib/list_sort.c
+++ b/lib/list_sort.c
@@ -7,33 +7,47 @@
 #include 
 #include 
 
-#define MAX_LIST_LENGTH_BITS 20
+/*
+ * By declaring the compare function with the __pure attribute, we give
+ * the compiler more opportunity to optimize.  Ideally, we'd use this in
+ * the prototype of list_sort(), but that would involve a lot of churn
+ * at all call sites, so just cast the function pointer passed in.
+ */
+typedef int __pure __attribute__((nonnull(2,3))) (*cmp_func)(void *,
+   struct list_head const *, struct list_head const *);
 
 /*
  * Returns a list organized in an intermediate format suited
  * to chaining of merge() calls: null-terminated, no reserved or
  * sentinel head node, "prev" links not maintained.
  */
-static struct list_head *merge(void *priv,
-   int (*cmp)(void *priv, struct list_head *a,
-   struct list_head *b),
+__attribute__((nonnull(2,3,4)))
+static struct list_head *merge(void *priv, cmp_func cmp,
struct list_head *a, struct list_head *b)
 {
-   struct list_head head, *tail = 
+   struct list_head *head, **tail = 
 
-   while (a && b) {
+   for (;;) {
/* if equal, take 'a' -- important for sort stability */
-   if ((*cmp)(priv, a, b) <= 0) {
-   tail->next = a;
+   if (cmp(priv, a, b) <= 0) {
+   *tail = a;
+   tail = >next;
a = a->next;
+   if (!a) {
+   *tail = b;
+   break;
+   }
} else {
-   tail->next = b;
+   *tail = b;
+   tail = >next;
b = b->next;
+   if (!b) {
+   *tail = a;
+   break;
+   }
}
-   tail = tail->next;
}
-   tail->next = a?:b;
-   return head.next;
+   return head;
 }
 
 /*
@@ -43,44 +57,52 @@ static struct list_head *merge(void *priv,
  * prev-link restoration pass, or maintaining the prev links
  * throughout.
  */
-static void merge_and_restore_back_links(void *priv,
-   int (*cmp)(void *priv, struct list_head *a,
-   struct list_head *b),
-   struct list_head *head,
-   struct list_head *a, struct list_head *b)
+__attribute__((nonnull(2,3,4,5)))
+static void merge_final(void *priv, cmp_func cmp, struct list_head *head,
+   struct list_head *a, struct list_head *b)
 {
struct list_head *tail = head;
u8 count = 0;
 
-   while (a && b) {
+   for (;;) {
/* if equal, take 'a' -- important for sort stability */
-   if ((*cmp)(priv, a, b) <= 0) {
+   if (cmp(priv, a, b) <= 0) {
tail->next = a;
a->prev = tail;
+   tail = a;
a = a->next;
+   if (!a)
+   break;
} else {
tail->next = b;
b->prev = tail;
+   tail = b;
b = b->next;
+   if (!b) {
+   b = a;
+   break;
+   }
}
-   tail = tail->next;
}
-   

[PATCH 5/5] lib/list_sort: Optimize number of calls to comparison function

2019-03-08 Thread George Spelvin
CONFIG_RETPOLINE has severely degraded indirect function call
performance, so it's worth putting some effort into reducing
the number of times cmp() is called.

This patch avoids badly unbalanced merges on unlucky input sizes.
It slightly increases the code size, but saves an average of 0.2*n
calls to cmp().

x86-64 code size 740 -> 820 bytes (+80)

Unfortunately, there's not a lot of low-hanging fruit in a merge sort;
it already performs only n*log2(n) - K*n + O(1) compares.  The leading
coefficient is already the lowest theoretically possible (log2(n!)
corresponds to K=1.4427), so we're fighting over the linear term, and
the best mergesort can do is K=1.2645, achieved when n is a power of 2.

The differences between mergesort variants appear when n is *not*
a power of 2; K is a function of the fractional part of log2(n).
Top-down mergesort does best of all, achieving a minimum K=1.2408, and
an average (over all sizes) K=1.248.  However, that requires knowing the
number of entries to be sorted ahead of time, and making a full pass
over the input to count it conflicts with a second performance goal,
which is cache blocking.

Obviously, we have to read the entire list into L1 cache at some point,
and performance is best if it fits.  But if it doesn't fit, each full
pass over the input causes a cache miss per element, which is undesirable.

While textbooks explain bottom-up mergesort as a succession of merging
passes, practical implementations do merging in depth-first order:
as soon as two lists of the same size are available, they are merged.
This allows as many merge passes as possible to fit into L1; only the
final few merges force cache misses.

This cache-friendly depth-first merge order depends on us merging the
beginning of the input as much as possible before we've even seen the
end of the input (and thus know its size).

The simple eager merge pattern causes bad performance when n is just
over a power of 2.  If n=1028, the final merge is between 1024- and
4-element lists, which is wasteful of comparisons.  (This is actually
worse on average than n=1025, because a 1204:1 merge will, on average,
end after 512 compares, while 1024:4 will walk 4/5 of the list.)

Because of this, bottom-up mergesort achieves K < 0.5 for such sizes,
and has an average (over all sizes) K of around 1.  (My experiments
show K=1.01, while theory predicts K=0.965.)

There are "worst-case optimal" variants of bottom-up mergesort which
avoid this bad performance, but the algorithms given in the literature,
such as queue-mergesort and boustrodephonic mergesort, depend on the
breadth-first multi-pass structure that we are trying to avoid.

This implementation is as eager as possible while ensuring that all merge
passes are at worst 1:2 unbalanced.  This achieves the same average
K=1.207 as queue-mergesort, which is 0.2*n better then bottom-up, and
only 0.04*n behind top-down mergesort.

Specifically, it merges two lists of size 2^k as soon as it is known
that there are 2^k additional inputs following.  This ensures that the
final uneven merges triggered by reaching the end of the input will be
at worst 2:1.  This will avoid cache misses as long as 3*2^k elements
fit into the cache.

(I confess to being more than a little bit proud of how clean this
code turned out.  It took a lot of thinking, but the resultant inner
loop is very simple and efficient.)

Refs:
  Bottom-up Mergesort: A Detailed Analysis
  Wolfgang Panny, Helmut Prodinger
  Algorithmica 14(4):340--354, October 1995
  https://doi.org/10.1007/BF01294131
  https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.6.5260

  The cost distribution of queue-mergesort, optimal mergesorts, and
  power-of-two rules
  Wei-Mei Chen, Hsien-Kuei Hwang, Gen-Huey Chen
  Journal of Algorithms 30(2); Pages 423--448, February 1999
  https://doi.org/10.1006/jagm.1998.0986
  https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.4.5380

  Queue-Mergesort
  Mordecai J. Golin, Robert Sedgewick
  Information Processing Letters, 48(5):253--259, 10 December 1993
  https://doi.org/10.1016/0020-0190(93)90088-q
  https://sci-hub.tw/10.1016/0020-0190(93)90088-Q

Signed-off-by: George Spelvin 
---
 lib/list_sort.c | 111 ++--
 1 file changed, 88 insertions(+), 23 deletions(-)

diff --git a/lib/list_sort.c b/lib/list_sort.c
index e4819ef0426b..06df9b283c40 100644
--- a/lib/list_sort.c
+++ b/lib/list_sort.c
@@ -113,11 +113,6 @@ static void merge_final(void *priv, cmp_func cmp, struct 
list_head *head,
  * @head: the list to sort
  * @cmp: the elements comparison function
  *
- * This function implements a bottom-up merge sort, which has O(nlog(n))
- * complexity.  We use depth-first order to take advantage of cacheing.
- * (I.e. when we get to the fourth element, we immediately merge the
- * first two 2-element lists.)
- *
  * The comparison function @cmp must return a negative value if @a
  * should sort before @b, and a positive value if @a should sort 

[PATCH 2/5] lib/sort: Use more efficient bottom-up heapsort variant

2019-03-08 Thread George Spelvin
This uses fewer comparisons than the previous code (61% as
many for large random inputs), but produces identical results;
it actually performs the exact same series of swap operations.

Standard heapsort, when sifting down, performs two comparisons
per level: One to find the greater child, and a second to see
if the current node should be exchanged with that child.

Bottom-up heapsort observes that it's better to postpone the second
comparison and search for the leaf where -infinity would be sent to,
then search back *up* for the current node's destination.

Since sifting down usually proceeds to the leaf level (that's where
half the nodes are), this does many fewer second comparisons.  That
saves a lot of (expensive since Spectre) indirect function calls.

The one time it's worse than the previous code is if there are large
numbers of duplicate keys, when the top-down algorithm is O(n) and
bottom-up is O(n log n).  For distinct keys, it's provably always better.

(The code is not significantly more complex.  This patch also merges
the heap-building and -extracting sift-down loops, resulting in a
net code size savings.)

x86-64 code size 885 -> 770 bytes (-115)

(I see the checkpatch complaint about "else if (n -= size)".
The alternative is significantly uglier.)

Signed-off-by: George Spelvin 
---
 lib/sort.c | 102 +++--
 1 file changed, 75 insertions(+), 27 deletions(-)

diff --git a/lib/sort.c b/lib/sort.c
index dff2ab2e196e..2aef4631e7d3 100644
--- a/lib/sort.c
+++ b/lib/sort.c
@@ -117,6 +117,32 @@ static void generic_swap(void *a, void *b, int size)
} while (n);
 }
 
+/**
+ * parent - given the offset of the child, find the offset of the parent.
+ * @i: the offset of the heap element whose parent is sought.  Non-zero.
+ * @lsbit: a precomputed 1-bit mask, equal to "size & -size"
+ * @size: size of each element
+ *
+ * In terms of array indexes, the parent of element j = i/size is simply
+ * (j-1)/2.  But when working in byte offsets, we can't use implicit
+ * truncation of integer divides.
+ *
+ * Fortunately, we only need one bit of the quotient, not the full divide.
+ * size has a least significant bit.  That bit will be clear if i is
+ * an even multiple of size, and set if it's an odd multiple.
+ *
+ * Logically, we're doing "if (i & lsbit) i -= size;", but since the
+ * branch is unpredictable, it's done with a bit of clever branch-free
+ * code instead.
+ */
+__attribute_const__ __always_inline
+static size_t parent(size_t i, unsigned int lsbit, size_t size)
+{
+   i -= size;
+   i -= size & -(i & lsbit);
+   return i / 2;
+}
+
 /**
  * sort - sort an array of elements
  * @base: pointer to data to sort
@@ -125,21 +151,26 @@ static void generic_swap(void *a, void *b, int size)
  * @cmp_func: pointer to comparison function
  * @swap_func: pointer to swap function or NULL
  *
- * This function does a heapsort on the given array. You may provide a
- * swap_func function optimized to your element type.
+ * This function does a heapsort on the given array.  You may provide a
+ * swap_func function if you need to do something more than a memory copy
+ * (e.g. fix up pointers or auxiliary data), but the built-in swap isn't
+ * usually a bottleneck.
  *
  * Sorting time is O(n log n) both on average and worst-case. While
  * qsort is about 20% faster on average, it suffers from exploitable
  * O(n*n) worst-case behavior and extra memory requirements that make
  * it less suitable for kernel use.
  */
-
 void sort(void *base, size_t num, size_t size,
  int (*cmp_func)(const void *, const void *),
  void (*swap_func)(void *, void *, int size))
 {
/* pre-scale counters for performance */
-   int i = (num/2 - 1) * size, n = num * size, c, r;
+   size_t n = num * size, a = (num/2) * size;
+   unsigned const lsbit = size & -size;/* Used to find parent */
+
+   if (!n)
+   return;
 
if (!swap_func) {
if (alignment_ok(base, size, 8))
@@ -150,30 +181,47 @@ void sort(void *base, size_t num, size_t size,
swap_func = generic_swap;
}
 
-   /* heapify */
-   for ( ; i >= 0; i -= size) {
-   for (r = i; r * 2 + size < n; r  = c) {
-   c = r * 2 + size;
-   if (c < n - size &&
-   cmp_func(base + c, base + c + size) < 0)
-   c += size;
-   if (cmp_func(base + r, base + c) >= 0)
-   break;
-   swap_func(base + r, base + c, size);
-   }
-   }
+   /*
+* Loop invariants:
+* 1. elements [a,n) satisfy the heap property (compare greater than
+*all of their children),
+* 2. elements [n,num*size) are sorted, and
+* 3. a <= b <= c <= d <= n (whenever they are valid).
+*/
+   for (;;) {
+  

[PATCH 3/5] lib/sort: Avoid indirect calls to built-in swap

2019-03-08 Thread George Spelvin
Similar to what's being done in the net code, this takes advantage of
the fact that most invocations use only a few common swap functions, and
replaces indirect calls to them with (highly predictable) conditional
branches.  (The downside, of course, is that if you *do* use a custom
swap function, there are a few additional (highly predictable) conditional
branches on the code path.)

This actually *shrinks* the x86-64 code, because it inlines the various
swap functions inside do_swap, eliding function prologues & epilogues.

x86-64 code size 770 -> 709 bytes (-61)

Signed-off-by: George Spelvin 
---
 lib/sort.c | 45 -
 1 file changed, 36 insertions(+), 9 deletions(-)

diff --git a/lib/sort.c b/lib/sort.c
index 2aef4631e7d3..226a8c7e4b9a 100644
--- a/lib/sort.c
+++ b/lib/sort.c
@@ -117,6 +117,33 @@ static void generic_swap(void *a, void *b, int size)
} while (n);
 }
 
+typedef void (*swap_func_t)(void *a, void *b, int size);
+
+/*
+ * The values are arbitrary as long as they can't be confused with
+ * a pointer, but small integers make for the smallest compare
+ * instructions.
+ */
+#define U64_SWAP (swap_func_t)0
+#define U32_SWAP (swap_func_t)1
+#define GENERIC_SWAP (swap_func_t)2
+
+/*
+ * The function pointer is last to make tail calls most efficient if the
+ * compiler decides not to inline this function.
+ */
+static void do_swap(void *a, void *b, int size, swap_func_t swap_func)
+{
+   if (swap_func == U64_SWAP)
+   u64_swap(a, b, size);
+   else if (swap_func == U32_SWAP)
+   u32_swap(a, b, size);
+   else if (swap_func == GENERIC_SWAP)
+   generic_swap(a, b, size);
+   else
+   swap_func(a, b, size);
+}
+
 /**
  * parent - given the offset of the child, find the offset of the parent.
  * @i: the offset of the heap element whose parent is sought.  Non-zero.
@@ -151,10 +178,10 @@ static size_t parent(size_t i, unsigned int lsbit, size_t 
size)
  * @cmp_func: pointer to comparison function
  * @swap_func: pointer to swap function or NULL
  *
- * This function does a heapsort on the given array.  You may provide a
- * swap_func function if you need to do something more than a memory copy
- * (e.g. fix up pointers or auxiliary data), but the built-in swap isn't
- * usually a bottleneck.
+ * This function does a heapsort on the given array.  You may provide
+ * a swap_func function if you need to do something more than a memory
+ * copy (e.g. fix up pointers or auxiliary data), but the built-in swap
+ * avoids a slow retpoline and so is significantly faster.
  *
  * Sorting time is O(n log n) both on average and worst-case. While
  * qsort is about 20% faster on average, it suffers from exploitable
@@ -174,11 +201,11 @@ void sort(void *base, size_t num, size_t size,
 
if (!swap_func) {
if (alignment_ok(base, size, 8))
-   swap_func = u64_swap;
+   swap_func = U64_SWAP;
else if (alignment_ok(base, size, 4))
-   swap_func = u32_swap;
+   swap_func = U32_SWAP;
else
-   swap_func = generic_swap;
+   swap_func = GENERIC_SWAP;
}
 
/*
@@ -194,7 +221,7 @@ void sort(void *base, size_t num, size_t size,
if (a)  /* Building heap: sift down --a */
a -= size;
else if (n -= size) /* Sorting: Extract root to --n */
-   swap_func(base, base + n, size);
+   do_swap(base, base + n, size, swap_func);
else/* Sort complete */
break;
 
@@ -221,7 +248,7 @@ void sort(void *base, size_t num, size_t size,
c = b;  /* Where "a" belongs */
while (b != a) {/* Shift it into place */
b = parent(b, lsbit, size);
-   swap_func(base + b, base + c, size);
+   do_swap(base + b, base + c, size, swap_func);
}
}
 }
-- 
2.20.1



[PATCH 0/5] lib/sort & lib/list_sort: faster and smaller

2019-03-08 Thread George Spelvin
Because CONFIG_RETPOLINE has made indirect calls much more expensive,
I thought I'd try to reduce the number made by the library sort
functions.

The first three patches apply to lib/sort.c.

Patch #1 is a simple optimization.  The built-in swap has rarely-used
special cases for aligned 4- and 8-byte objects.  But that case almost
never happens; most calls to sort() work on larger structures, which
fall back to the byte-at-a-time loop.  This generalizes them to aligned
*multiples* of 4 and 8 bytes.  (If nothing else, it saves an awful lot
of energy by not thrashing the store buffers as much.)

(Issue for disussion: should the special-case swap loops be reduced to
two, an aligned-word and generic byte verison?)

Patch #2 grabs a juicy piece of low-hanging fruit.  I agree that
nice simple solid heapsort is preferable to more complex algorithms
(sorry, Andrey), but it's possible to implement heapsort with 40% fewer
comparisons than the way it's been done up to now.  And with some care,
the code ends up smaller, as well.  This is the "big win" patch.

Patch #3 adds the same sort of indirect call bypass that has been added
to the net code of late.  The great majority of the callers use the
builtin swap functions, so replace the indirect call to sort_func with a
(highly preditable) series of if() statements.  Rather surprisingly,
this decreased code size, as the swap functions were inlined and their
prologue & epilogue code eliminated.

lib/list_sort.c is a bit trickier, as merge sort is already close to
optimal, and we don't want to introduce triumphs of theory over
practicality like the Ford-Johnson merge-insertion sort.

Patch #4, without changing the algorithm, chops 32% off the code size and
removes the part[MAX_LIST_LENGTH+1] pointer array (and the corresponding
upper limit on efficiently sortable input size).

Patch #5 improves the algorithm.  The previous code is already optimal
for power-of-two (or slightly smaller) size inputs, but when the input
size is just over a power of 2, there's a very unbalanced final merge.

There are, in the literature, several algorithms which solve this, but
they all depend on the "breadth-first" merge order which was replaced
by commit 835cc0c8477f with a more cache-friendly "depth-first" order.
Some hard thinking came up with a depth-first algorithm which defers
merges as little as possible while avoiding bad merges.  This saves
0.2*n compares, averaged over all sizes.

The code size increase is minimal (80 bytes on x86-64, reducing the net
savings to 24%), but the comments expanded significantly to document
the clever algorithm.


TESTING NOTES: I have some ugly user-space benchmarking code
which I used for testing before moving this code into the kernel.
Shout if you want a copy.

I'm running this code right now, with CONFIG_TEST_SORT and
CONFIG_TEST_LIST_SORT, but I confess I haven't rebooted since
the last round of minor edits to quell checkpatch.  I figure there
will be at least one round of comments and final testing.

George Spelvin (5):
  lib/sort: Make swap functions more generic
  lib/sort: Use more efficient bottom-up heapsort variant
  lib/sort: Avoid indirect calls to built-in swap
  lib/list_sort: Simplify and remove MAX_LIST_LENGTH_BITS
  lib/list_sort: Optimize number of calls to comparison function

 include/linux/list_sort.h |   1 +
 lib/list_sort.c   | 225 --
 lib/sort.c| 250 ++
 3 files changed, 365 insertions(+), 111 deletions(-)

-- 
2.20.1



Re: [PATCH 3/4] Add header file,Kconfig and Makefile

2019-03-08 Thread Randy Dunlap
On 3/8/19 4:35 AM, Morris Ku wrote:
> This patch add header file, Kconfig and Makefile. 
> 
> Signed-off-by: Morris Ku 
> ---

> diff --git a/char/snx/Kconfig b/char/snx/Kconfig
> new file mode 100644
> index ..86f38352
> --- /dev/null
> +++ b/char/snx/Kconfig
> @@ -0,0 +1,15 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Character device configuration
> +#
> +
> +config SNX
> + tristate "SUNIX Multi-IO Board Drvier"

   Driver

> + Driver for SUNIX Multi-I/O Board device driver Based on
> + drivers/char/serial.c, parport_pc.c, ppdev.c and lp.c by Linus
> + Torvalds, Theodore Ts'o.

kconfig does not like those 3 lines above.  That indicates some lack of
testing.

They could be put under "help", but they really should just be deleted or
moved to some source file if you think that they are needed.

> + help
> +Say Y here if you have a SUNIX Multi-IO card.

Indent with tab + 2 spaces, not 3 spaces.

> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called snx.


-- 
~Randy


[PATCH net] staging: rtl8188eu: use is_zero_ether_addr() instead of memcmp()

2019-03-08 Thread Mao Wenan
Using is_zero_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is all
zeros.

Signed-off-by: Mao Wenan 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 714f7a70ed64..beae367df93b 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -180,9 +180,8 @@ struct wlan_network *rtw_find_network(struct __queue 
*scanned_queue, u8 *addr)
 {
struct list_head *phead, *plist;
struct wlan_network *pnetwork = NULL;
-   u8 zero_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
 
-   if (!memcmp(zero_addr, addr, ETH_ALEN)) {
+   if (is_zero_ether_addr(addr)) {
pnetwork = NULL;
goto exit;
}
-- 
2.20.1



Re: [PATCH] arm64: dts: rockchip: Fix vcc_host1_5v GPIO polarity on rk3328-rock64

2019-03-08 Thread Katsuhiro Suzuki

Hello Mayama-san,

On 2019/03/08 1:18, Tomohiro Mayama wrote:

This patch makes USB ports functioning again.

Signed-off-by: Tomohiro Mayama 
---
  arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index 21107d0f4378..7f365e448867 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -45,8 +45,7 @@
  
  	vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {

compatible = "regulator-fixed";
-   enable-active-high;
-   gpio = < RK_PA2 GPIO_ACTIVE_HIGH>;
+   gpio = < RK_PA2 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <_host_drv>;
regulator-name = "vcc_host1_5v";



After this patch applied, USB and S/PDIF both work well.

Tested-by: Katsuhiro Suzuki 


$ lsusb
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 046d:c526 Logitech, Inc. Nano Receiver
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Best Regards,
Katsuhiro Suzuki


[PATCH serial v2] sc16is7xx: missing unregister/delete driver on error in sc16is7xx_init()

2019-03-08 Thread Mao Wenan
Add the missing uart_unregister_driver() and i2c_del_driver() before return
from sc16is7xx_init() in the error handling case.

Reviewed-by: Vladimir Zapolskiy 
Signed-off-by: Mao Wenan 
---
 v1->v2: fix compile warning if CONFIG_SERIAL_SC16IS7XX_SPI is not exist.
 drivers/tty/serial/sc16is7xx.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 268098681856..b9e5941ce767 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -1509,7 +1509,7 @@ static int __init sc16is7xx_init(void)
ret = i2c_add_driver(_i2c_uart_driver);
if (ret < 0) {
pr_err("failed to init sc16is7xx i2c --> %d\n", ret);
-   return ret;
+   goto err_i2c;
}
 #endif
 
@@ -1517,10 +1517,20 @@ static int __init sc16is7xx_init(void)
ret = spi_register_driver(_spi_uart_driver);
if (ret < 0) {
pr_err("failed to init sc16is7xx spi --> %d\n", ret);
-   return ret;
+   goto err_spi;
}
 #endif
return ret;
+
+#ifdef CONFIG_SERIAL_SC16IS7XX_SPI
+err_spi:
+#endif
+#ifdef CONFIG_SERIAL_SC16IS7XX_I2C
+   i2c_del_driver(_i2c_uart_driver);
+err_i2c:
+#endif
+   uart_unregister_driver(_uart);
+   return ret;
 }
 module_init(sc16is7xx_init);
 
-- 
2.20.1



Re: [PATCH v4 17/17] kvm: vmx: Emulate TEST_CTL MSR

2019-03-08 Thread Xiaoyao Li
Hi, Paolo,

Do you have any comments on this patch?

We are preparing v5 patches for split lock detection, if you have any comments
about this one, please let me know.

Thanks,
Xiaoyao

On Fri, 2019-03-01 at 18:45 -0800, Fenghua Yu wrote:
> From: Xiaoyao Li 
> 
> A control bit (bit 29) in TEST_CTL MSR 0x33 will be introduced in
> future x86 processors. When bit 29 is set, the processor causes #AC
> exception for split locked accesses at all CPL.
> 
> Please check the latest Intel Software Developer's Manual
> for more detailed information on the MSR and the split lock bit.
> 
> 1. Since the kernel chooses to enable AC split lock by default, which
> means if we don't emulate TEST_CTL MSR for guest, guest will run with
> this feature enable while does not known it. Thus existing guests with
> buggy firmware (like OVMF) and old kernels having the cross cache line
> issues will fail the boot due to #AC.
> 
> So we should emulate TEST_CTL MSR, and set it zero to disable AC split
> lock by default. Whether and when to enable it is left to guest firmware
> and guest kernel.
> 
> 2. Host and guest can enable AC split lock independently, so using
> msr autoload to switch it during VM entry/exit.
> 
> Signed-off-by: Xiaoyao Li 
> Signed-off-by: Fenghua Yu 
> ---
>  arch/x86/kvm/vmx/vmx.c | 35 +++
>  arch/x86/kvm/vmx/vmx.h |  1 +
>  2 files changed, 36 insertions(+)
> 
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 3e03c6e1e558..c0c5e8621afa 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -1659,6 +1659,12 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct
> msr_data *msr_info)
>   u32 index;
>  
>   switch (msr_info->index) {
> + case MSR_TEST_CTL:
> + if (!msr_info->host_initiated &&
> + !(vmx->core_capability & CORE_CAP_SPLIT_LOCK_DETECT))
> + return 1;
> + msr_info->data = vmx->msr_test_ctl;
> + break;
>  #ifdef CONFIG_X86_64
>   case MSR_FS_BASE:
>   msr_info->data = vmcs_readl(GUEST_FS_BASE);
> @@ -1805,6 +1811,14 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct
> msr_data *msr_info)
>   u32 index;
>  
>   switch (msr_index) {
> + case MSR_TEST_CTL:
> + if (!(vmx->core_capability & CORE_CAP_SPLIT_LOCK_DETECT))
> + return 1;
> +
> + if (data & ~TEST_CTL_ENABLE_SPLIT_LOCK_DETECT)
> + return 1;
> + vmx->msr_test_ctl = data;
> + break;
>   case MSR_EFER:
>   ret = kvm_set_msr_common(vcpu, msr_info);
>   break;
> @@ -4108,6 +4122,9 @@ static void vmx_vcpu_setup(struct vcpu_vmx *vmx)
>  
>   vmx->arch_capabilities = kvm_get_arch_capabilities();
>  
> + /* disable AC split lock by default */
> + vmx->msr_test_ctl = 0;
> +
>   vm_exit_controls_init(vmx, vmx_vmexit_ctrl());
>  
>   /* 22.2.1, 20.8.1 */
> @@ -4145,6 +4162,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool
> init_event)
>  
>   vmx->rmode.vm86_active = 0;
>   vmx->spec_ctrl = 0;
> + vmx->msr_test_ctl = 0;
>  
>   vcpu->arch.microcode_version = 0x1ULL;
>   vmx->vcpu.arch.regs[VCPU_REGS_RDX] = get_rdx_init_val();
> @@ -6344,6 +6362,21 @@ static void atomic_switch_perf_msrs(struct vcpu_vmx
> *vmx)
>   msrs[i].host, false);
>  }
>  
> +static void atomic_switch_msr_test_ctl(struct vcpu_vmx *vmx)
> +{
> + u64 host_msr_test_ctl;
> +
> + if (!boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT))
> + return;
> +
> + rdmsrl(MSR_TEST_CTL, host_msr_test_ctl);
> + if (host_msr_test_ctl == vmx->msr_test_ctl)
> + clear_atomic_switch_msr(vmx, MSR_TEST_CTL);
> + else
> + add_atomic_switch_msr(vmx, MSR_TEST_CTL, vmx->msr_test_ctl,
> +   host_msr_test_ctl, false);
> +}
> +
>  static void vmx_arm_hv_timer(struct vcpu_vmx *vmx, u32 val)
>  {
>   vmcs_write32(VMX_PREEMPTION_TIMER_VALUE, val);
> @@ -6585,6 +6618,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
>  
>   atomic_switch_perf_msrs(vmx);
>  
> + atomic_switch_msr_test_ctl(vmx);
> +
>   vmx_update_hv_timer(vcpu);
>  
>   /*
> diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
> index cc22379991f3..e8831609c6c3 100644
> --- a/arch/x86/kvm/vmx/vmx.h
> +++ b/arch/x86/kvm/vmx/vmx.h
> @@ -191,6 +191,7 @@ struct vcpu_vmx {
>   u64   msr_guest_kernel_gs_base;
>  #endif
>  
> + u64   msr_test_ctl;
>   u64   core_capability;
>   u64   arch_capabilities;
>   u64   spec_ctrl;



[PATCH] arm64: dts: freescale: Enable PCI-E controller for Oxalis board

2019-03-08 Thread Manivannan Sadhasivam
Enable PCI-E controller for Oxalis board based on NXP/Freescale LS1012a
SoC available as the Mini PCI-E connector on the bottom side.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts | 4 
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi   | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts
index 760a3e258c96..5f9cde402744 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dts
@@ -87,6 +87,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 816f3a4537e3..d48b0df1da6d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -474,7 +474,7 @@
interrupts = <0 126 IRQ_TYPE_LEVEL_HIGH>;
};
 
-   pcie@340 {
+   pcie: pcie@340 {
compatible = "fsl,ls1012a-pcie";
reg = <0x00 0x0340 0x0 0x0010   /* controller 
registers */
   0x40 0x 0x0 0x2000>; /* 
configuration space */
-- 
2.17.1



Re: [PATCH net] rxrpc: Fix client call queueing, waiting for channel

2019-03-08 Thread David Miller
From: David Howells 
Date: Sat, 09 Mar 2019 00:29:58 +

> rxrpc_get_client_conn() adds a new call to the front of the waiting_calls
> queue if the connection it's going to use already exists.  This is bad as
> it allows calls to get starved out.
> 
> Fix this by adding to the tail instead.
> 
> Also change the other enqueue point in the same function to put it on the
> front (ie. when we have a new connection).  This makes the point that in
> the case of a new connection the new call goes at the front (though it
> doesn't actually matter since the queue should be unoccupied).
> 
> Fixes: 45025bceef17 ("rxrpc: Improve management and caching of client 
> connection objects")
> Signed-off-by: David Howells 
> Reviewed-by: Marc Dionne 

Applied and queued up for -stable, thanks David.


Re: [PATCH v2 01/15] ARM: actions: fix a leaked reference by adding missing of_node_put

2019-03-08 Thread Manivannan Sadhasivam
Hi Russel,

On Tue, Mar 05, 2019 at 11:40:48AM +, Russell King - ARM Linux admin wrote:
> On Tue, Mar 05, 2019 at 07:33:52PM +0800, Wen Yang wrote:
> > The call to of_get_next_child returns a node pointer with refcount
> > incremented thus it must be explicitly decremented after the last
> > usage.
> > 
> > Detected by coccinelle with the following warnings:
> > ./arch/arm/mach-actions/platsmp.c:112:2-8: ERROR: missing of_node_put; 
> > acquired a node pointer with refcount incremented on line 103, but without 
> > a corresponding object release within this function.
> > ./arch/arm/mach-actions/platsmp.c:124:2-8: ERROR: missing of_node_put; 
> > acquired a node pointer with refcount incremented on line 115, but without 
> > a corresponding object release within this function.
> > ./arch/arm/mach-actions/platsmp.c:137:3-9: ERROR: missing of_node_put; 
> > acquired a node pointer with refcount incremented on line 128, but without 
> > a corresponding object release within this function.
> 
> I question this.  Your reasoning is that the node is no longer used
> so the reference count needs to be put.
> 
> However, in all these cases, data is read from the nodes properties
> and the device remains in-use for the life of the kernel.  There is
> a big difference here.
> 
> With normal drivers, each device is bound to their associated device
> node associated with the device.  When the device node goes away, then
> the corresponding device goes away too, which causes the driver to be
> unbound from the device.
> 
> However, there is another class of "driver" which are the ones below,
> where they are "permanent" devices.  These can never go away, even if
> the device node refcount hits zero and the device node is freed - the
> device is still present and in-use in the system.  So, having the
> device node refcount hit zero is actually a bug: what that's saying
> is the system device (eg, SCU) has gone away.  If you somehow were to
> remove the SCU from the system, you'd end up severing the connection
> between the CPU cores and the rest of the system - obviously resulting
> in a dead system!
> 
> So, what is the point of dropping these refcounts for devices that can
> never go away - and thus their associated device_node should also never
> go away?
> 

Yes, practically we would never hit this case but theoretically we should
decrement the refcount for nodes/properties whenever we are done with it.
As you know, there are 'n' number of places in kernel where we can see the
refcount not being put after use. So I would welcome these kind of patches
to set an example for someone who tries to use the of_* calls in future.

IMO, DT should've handled the refcount internally without exposing the
pointers to external world.

Thanks,
Mani

> > 
> > Signed-off-by: Wen Yang 
> > Reviewed-by: Florian Fainelli 
> > Cc: "Andreas Färber" 
> > Cc: Manivannan Sadhasivam 
> > Cc: Russell King 
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > v2->v1: add a missing space between "adding" and "missing"
> > 
> >  arch/arm/mach-actions/platsmp.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/arch/arm/mach-actions/platsmp.c 
> > b/arch/arm/mach-actions/platsmp.c
> > index 4fd479c..1a8e078 100644
> > --- a/arch/arm/mach-actions/platsmp.c
> > +++ b/arch/arm/mach-actions/platsmp.c
> > @@ -107,6 +107,7 @@ static void __init s500_smp_prepare_cpus(unsigned int 
> > max_cpus)
> > }
> >  
> > timer_base_addr = of_iomap(node, 0);
> > +   of_node_put(node);
> > if (!timer_base_addr) {
> > pr_err("%s: could not map timer registers\n", __func__);
> > return;
> > @@ -119,6 +120,7 @@ static void __init s500_smp_prepare_cpus(unsigned int 
> > max_cpus)
> > }
> >  
> > sps_base_addr = of_iomap(node, 0);
> > +   of_node_put(node);
> > if (!sps_base_addr) {
> > pr_err("%s: could not map sps registers\n", __func__);
> > return;
> > @@ -132,6 +134,7 @@ static void __init s500_smp_prepare_cpus(unsigned int 
> > max_cpus)
> > }
> >  
> > scu_base_addr = of_iomap(node, 0);
> > +   of_node_put(node);
> > if (!scu_base_addr) {
> > pr_err("%s: could not map scu registers\n", __func__);
> > return;
> > -- 
> > 2.9.5
> > 
> > 
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up


r8169 only works in promisc mode

2019-03-08 Thread Alex Xu (Hello71)
After suspending, my r8169 (not actually 8169, just that driver) only 
receives packets when in promiscuous mode. I have tried disabling all 
offload features except highdma [fixed], and it doesn't fix the issue.

I am using torvalds/linux, compiled about two days ago (not sure which 
commit). I think this happened after a recent upgrade (some time in the 
past week). Given the long testing cycle, I don't really want to bisect; 
I am hoping someone has some idea of where the issue could be.

Please CC me on replies.

Thanks,
Alex.


Re: [PATCH] proc/sysctl: Fix NULL pointer dereference in put_links

2019-03-08 Thread YueHaibing
+cc Al Viro

On 2019/3/4 21:54, Yue Haibing wrote:
> From: YueHaibing 
> 
> Syzkaller report this:
> 
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN PTI
> CPU: 1 PID: 5373 Comm: syz-executor.0 Not tainted 5.0.0-rc8+ #3
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 
> 04/01/2014
> RIP: 0010:put_links+0x101/0x440 fs/proc/proc_sysctl.c:1599
> Code: 00 0f 85 3a 03 00 00 48 8b 43 38 48 89 44 24 20 48 83 c0 38 48 89 c2 48 
> 89 44 24 28 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 fe 
> 02 00 00 48 8b 74 24 20 48 c7 c7 60 2a 9d 91
> RSP: 0018:8881d828f238 EFLAGS: 00010202
> RAX: dc00 RBX: 8881e01b1140 RCX: 8ee98267
> RDX: 0007 RSI: c90001479000 RDI: 8881e01b1178
> RBP: dc00 R08: ed103ee27259 R09: ed103ee27259
> R10: 0001 R11: ed103ee27258 R12: fff4
> R13: 0006 R14: 8881f59838c0 R15: dc00
> FS:  7f072254f700() GS:8881f710() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7fff8b286668 CR3: 0001f0542002 CR4: 007606e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> PKRU: 5554
> Call Trace:
>  drop_sysctl_table+0x152/0x9f0 fs/proc/proc_sysctl.c:1629
>  get_subdir fs/proc/proc_sysctl.c:1022 [inline]
>  __register_sysctl_table+0xd65/0x1090 fs/proc/proc_sysctl.c:1335
>  ? 0xc1a18000
>  br_netfilter_init+0xbc/0x1000 [br_netfilter]
>  ? 0xc1a18000
>  ? 0xc1a18000
>  do_one_initcall+0xfa/0x5ca init/main.c:887
>  do_init_module+0x204/0x5f6 kernel/module.c:3460
>  load_module+0x66b2/0x8570 kernel/module.c:3808
>  __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
>  do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x462e99
> Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 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 73 
> 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
> RSP: 002b:7f072254ec58 EFLAGS: 0246 ORIG_RAX: 0139
> RAX: ffda RBX: 0073bf00 RCX: 00462e99
> RDX:  RSI: 2280 RDI: 0003
> RBP: 7f072254ec70 R08:  R09: 
> R10:  R11: 0246 R12: 7f072254f6bc
> R13: 004bcefa R14: 006f6fb0 R15: 0004
> Modules linked in: br_netfilter(+) dvb_usb_dibusb_mc_common dib3000mc 
> dibx000_common dvb_usb_dibusb_common dvb_usb_dw2102 dvb_usb classmate_laptop 
> palmas_regulator cn videobuf2_v4l2 v4l2_common snd_soc_bd28623 mptbase 
> snd_usb_usx2y snd_usbmidi_lib snd_rawmidi wmi libnvdimm lockd sunrpc grace 
> rc_kworld_pc150u rc_core rtc_da9063 sha1_ssse3 i2c_cros_ec_tunnel adxl34x_spi 
> adxl34x nfnetlink lib80211 i5500_temp dvb_as102 dvb_core videobuf2_common 
> videodev media videobuf2_vmalloc videobuf2_memops udc_core lnbp22 leds_lp3952 
> hid_roccat_ryos s1d13xxxfb mtd vport_geneve openvswitch nf_conncount 
> nf_nat_ipv6 nsh geneve udp_tunnel ip6_udp_tunnel snd_soc_mt6351 sis_agp 
> phylink snd_soc_adau1761_spi snd_soc_adau1761 snd_soc_adau17x1 snd_soc_core 
> snd_pcm_dmaengine ac97_bus snd_compress snd_soc_adau_utils 
> snd_soc_sigmadsp_regmap snd_soc_sigmadsp raid_class hid_roccat_konepure 
> hid_roccat_common hid_roccat c2port_duramar2150 core mdio_bcm_unimac 
> iptable_security iptable_raw iptable_mangle
>  iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 
> iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr 
> veth netdevsim devlink vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon 
> dummy team bonding vcan bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun 
> crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel joydev 
> mousedev ide_pci_generic piix aesni_intel aes_x86_64 ide_core crypto_simd 
> atkbd cryptd glue_helper serio_raw ata_generic pata_acpi i2c_piix4 floppy 
> sch_fq_codel ip_tables x_tables ipv6 [last unloaded: lm73]
> Dumping ftrace buffer:
>(ftrace buffer empty)
> ---[ end trace 770020de38961fd0 ]---
> 
> A new dir entry can be created in get_subdir and its header->parent is set
> to NULL. Only after insert_header success, it will be set to 'dir'.
> However in err handling path of get_subdir, drop_sysctl_table maybe called
> on 'new->header' regardless value of header->parent. Then put_links
> be called, which triggers NULL-ptr deref when access the member of
> header->parent in xlate_dir.
> 
> Reported-by: Hulk Robot 
> Fixes: 0e47c99d7fe25 ("sysctl: Replace root_list with links between 
> sysctl_table_sets")
> Signed-off-by: YueHaibing 
> ---
>  fs/proc/proc_sysctl.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 

[PATCH 2/2] arm64: dts: hisilicon: Add reset properties for HI6220 I2C and SPI

2019-03-08 Thread Manivannan Sadhasivam
Both I2C and SPI needs to be taken out of reset before being used. Earlier,
we relied on the bootloader to do the job but a more cleaner approach would
be to handle the reset in kernel. Hence, add the reset properties to
the nodes to let the corresponding drivers take the peripherals out of
reset.

Suggested-by: Daniel Thompson 
Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 108e2a4227f6..b071dc466374 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -730,6 +730,8 @@
pinctrl-0 = <_pmx_func _cfg_func>;
num-cs = <1>;
cs-gpios = < 2 0>;
+   resets = <_ctrl PERIPH_RSTEN3_SSP>;
+   reset-names = "reset";
status = "disabled";
};
 
@@ -741,6 +743,8 @@
i2c-sda-hold-time-ns = <300>;
pinctrl-names = "default";
pinctrl-0 = <_pmx_func _cfg_func>;
+   resets = <_ctrl PERIPH_RSTEN3_I2C0>;
+   reset-names = "reset";
status = "disabled";
};
 
@@ -752,6 +756,8 @@
i2c-sda-hold-time-ns = <300>;
pinctrl-names = "default";
pinctrl-0 = <_pmx_func _cfg_func>;
+   resets = <_ctrl PERIPH_RSTEN3_I2C1>;
+   reset-names = "reset";
status = "disabled";
};
 
@@ -763,6 +769,8 @@
i2c-sda-hold-time-ns = <300>;
pinctrl-names = "default";
pinctrl-0 = <_pmx_func _cfg_func>;
+   resets = <_ctrl PERIPH_RSTEN3_I2C2>;
+   reset-names = "reset";
status = "disabled";
};
 
-- 
2.17.1



[PATCH 1/2] amba: Take device out of reset before reading pid and cid values

2019-03-08 Thread Manivannan Sadhasivam
For the AMBA Primecell devices having the reset lines wired, it is
necessary to take them out of reset before reading the pid and cid values.
Earlier we were dependent on the bootloader to do this but a more cleaner
approach would be to do it in the kernel itself. Hence, this commit
deasserts the reset line just before reading the pid and cid values.

Suggested-by: Daniel Thompson 
Signed-off-by: Manivannan Sadhasivam 
---
 drivers/amba/bus.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 41b706403ef7..da8f1aac5315 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -352,6 +353,7 @@ static void amba_device_release(struct device *dev)
 
 static int amba_device_try_add(struct amba_device *dev, struct resource 
*parent)
 {
+   struct reset_control *rst;
u32 size;
void __iomem *tmp;
int i, ret;
@@ -388,6 +390,13 @@ static int amba_device_try_add(struct amba_device *dev, 
struct resource *parent)
if (ret == 0) {
u32 pid, cid;
 
+   /* De-assert the reset line to take the device out of reset */
+   rst = reset_control_get_optional_exclusive(>dev, NULL);
+   if (IS_ERR(rst))
+   return PTR_ERR(rst);
+
+   reset_control_deassert(rst);
+
/*
 * Read pid and cid based on size of resource
 * they are located at end of region
-- 
2.17.1



Re: [PATCH 4/4] iommu/vt-d: Remove lazy allocation of domains

2019-03-08 Thread Lu Baolu

Hi James,

On 3/9/19 12:57 AM, James Sewart wrote:

Hey Lu,


On 8 Mar 2019, at 03:09, Lu Baolu  wrote:


Do you mind if I work on top of your patches for further cleanups and
sign off a v2 together with you?

Sure, sounds good. I’ll fixup patch 3 and have a go at integrating
iommu_prepare_isa into get_resv_regions. This should make the initial
domain logic here quite concise.

Here attached three extra patches which I think should be added before
PATCH 3/4, and some further cleanup changes which you can merge with
PATCH 4/4.



0006-iommu-Add-ops-entry-for-vendor-specific-default-doma.patch
0007-iommu-vt-d-Add-is_identity_map-ops-entry.patch

These two patches aim to add a generic method for vendor specific iommu
drivers to specify the type of the default domain for a device. Intel
iommu driver will register an ops for this since it already has its own
identity map adjudicator for a long time.

This seems like a good idea, but as domain alloc is only called for the
default domain on first device attached to a group, we may miss checking
whether a device added later should have an identity domain. Should there
be paths to downgrade a groups domain if one of the devices requires one?



Good catch!

This is supposed to be handled in iommu_no_mapping(). But, obviously
current code sticks to lazy domain allocation. I'm not sure whether
there are any real such cases, but we should handle it in a clean way.
My idea is that we could downgrade to multiple domains per group (just
like what we have now) in this case and print a kernel message for this.

Or any other thoughts?

Best regards,
Lu Baolu


[PATCH 0/2] Handle I2C and SPI reset on HI6220 SoC

2019-03-08 Thread Manivannan Sadhasivam
Hello,

This small patchset adds the reset functionality to the I2C and SPI
peripherals on HI6220 SoC from HiSilicon. Those peripherals needs to be
taken out of reset before being used. But earlier we were depending on the
bootloader to do the job but as suggested by Daniel Thompson, a more
cleaner approach would be to handle the reset in corresponding drivers.

Hence, one of the patch adds reset properties to the I2C and SPI nodes
and the other one adds missing reset functionality to the AMBA Primecell
bus driver. Because the AMBA devices are being accessed before the driver
probe (reading pid and cid values), we need to deassert the reset line in
the bus driver itself just before the read.

I'd expect the patch 1 to go via arm tree and patch 2 via hisi tree.

Thanks,
Mani

Manivannan Sadhasivam (2):
  amba: Take device out of reset before reading pid and cid values
  arm64: dts: hisilicon: Add reset properties for HI6220 I2C and SPI

 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8 
 drivers/amba/bus.c| 9 +
 2 files changed, 17 insertions(+)

-- 
2.17.1



Re: [PATCH] proc/sysctl: Fix NULL pointer dereference in put_links

2019-03-08 Thread YueHaibing
ping.

On 2019/3/4 21:54, Yue Haibing wrote:
> From: YueHaibing 
> 
> Syzkaller report this:
> 
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN PTI
> CPU: 1 PID: 5373 Comm: syz-executor.0 Not tainted 5.0.0-rc8+ #3
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 
> 04/01/2014
> RIP: 0010:put_links+0x101/0x440 fs/proc/proc_sysctl.c:1599
> Code: 00 0f 85 3a 03 00 00 48 8b 43 38 48 89 44 24 20 48 83 c0 38 48 89 c2 48 
> 89 44 24 28 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 fe 
> 02 00 00 48 8b 74 24 20 48 c7 c7 60 2a 9d 91
> RSP: 0018:8881d828f238 EFLAGS: 00010202
> RAX: dc00 RBX: 8881e01b1140 RCX: 8ee98267
> RDX: 0007 RSI: c90001479000 RDI: 8881e01b1178
> RBP: dc00 R08: ed103ee27259 R09: ed103ee27259
> R10: 0001 R11: ed103ee27258 R12: fff4
> R13: 0006 R14: 8881f59838c0 R15: dc00
> FS:  7f072254f700() GS:8881f710() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7fff8b286668 CR3: 0001f0542002 CR4: 007606e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> PKRU: 5554
> Call Trace:
>  drop_sysctl_table+0x152/0x9f0 fs/proc/proc_sysctl.c:1629
>  get_subdir fs/proc/proc_sysctl.c:1022 [inline]
>  __register_sysctl_table+0xd65/0x1090 fs/proc/proc_sysctl.c:1335
>  ? 0xc1a18000
>  br_netfilter_init+0xbc/0x1000 [br_netfilter]
>  ? 0xc1a18000
>  ? 0xc1a18000
>  do_one_initcall+0xfa/0x5ca init/main.c:887
>  do_init_module+0x204/0x5f6 kernel/module.c:3460
>  load_module+0x66b2/0x8570 kernel/module.c:3808
>  __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
>  do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x462e99
> Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 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 73 
> 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
> RSP: 002b:7f072254ec58 EFLAGS: 0246 ORIG_RAX: 0139
> RAX: ffda RBX: 0073bf00 RCX: 00462e99
> RDX:  RSI: 2280 RDI: 0003
> RBP: 7f072254ec70 R08:  R09: 
> R10:  R11: 0246 R12: 7f072254f6bc
> R13: 004bcefa R14: 006f6fb0 R15: 0004
> Modules linked in: br_netfilter(+) dvb_usb_dibusb_mc_common dib3000mc 
> dibx000_common dvb_usb_dibusb_common dvb_usb_dw2102 dvb_usb classmate_laptop 
> palmas_regulator cn videobuf2_v4l2 v4l2_common snd_soc_bd28623 mptbase 
> snd_usb_usx2y snd_usbmidi_lib snd_rawmidi wmi libnvdimm lockd sunrpc grace 
> rc_kworld_pc150u rc_core rtc_da9063 sha1_ssse3 i2c_cros_ec_tunnel adxl34x_spi 
> adxl34x nfnetlink lib80211 i5500_temp dvb_as102 dvb_core videobuf2_common 
> videodev media videobuf2_vmalloc videobuf2_memops udc_core lnbp22 leds_lp3952 
> hid_roccat_ryos s1d13xxxfb mtd vport_geneve openvswitch nf_conncount 
> nf_nat_ipv6 nsh geneve udp_tunnel ip6_udp_tunnel snd_soc_mt6351 sis_agp 
> phylink snd_soc_adau1761_spi snd_soc_adau1761 snd_soc_adau17x1 snd_soc_core 
> snd_pcm_dmaengine ac97_bus snd_compress snd_soc_adau_utils 
> snd_soc_sigmadsp_regmap snd_soc_sigmadsp raid_class hid_roccat_konepure 
> hid_roccat_common hid_roccat c2port_duramar2150 core mdio_bcm_unimac 
> iptable_security iptable_raw iptable_mangle
>  iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 
> iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr 
> veth netdevsim devlink vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon 
> dummy team bonding vcan bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun 
> crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel joydev 
> mousedev ide_pci_generic piix aesni_intel aes_x86_64 ide_core crypto_simd 
> atkbd cryptd glue_helper serio_raw ata_generic pata_acpi i2c_piix4 floppy 
> sch_fq_codel ip_tables x_tables ipv6 [last unloaded: lm73]
> Dumping ftrace buffer:
>(ftrace buffer empty)
> ---[ end trace 770020de38961fd0 ]---
> 
> A new dir entry can be created in get_subdir and its header->parent is set
> to NULL. Only after insert_header success, it will be set to 'dir'.
> However in err handling path of get_subdir, drop_sysctl_table maybe called
> on 'new->header' regardless value of header->parent. Then put_links
> be called, which triggers NULL-ptr deref when access the member of
> header->parent in xlate_dir.
> 
> Reported-by: Hulk Robot 
> Fixes: 0e47c99d7fe25 ("sysctl: Replace root_list with links between 
> sysctl_table_sets")
> Signed-off-by: YueHaibing 
> ---
>  fs/proc/proc_sysctl.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 

Re: [PATCH V3] cros_ec: Expose sysfile to force battery cut-off on shutdown.

2019-03-08 Thread Ravi Chandra Sadineni
Hi Enric,

Thanks for the review.

On Thu, Mar 7, 2019 at 3:57 AM Enric Balletbo i Serra
 wrote:
>
> Hi RaviChandra,
>
> Some few comments below ...
>
>
> On 5/3/19 1:53, RaviChandra Sadineni wrote:
> > On chromebooks, power_manager daemon normally shutsdown(S5) the device
> > when the battery charge falls below 4% threshold. Chromeos EC then
> > normally spends an hour in S5 before hibernating. If the battery charge
> > falls below critical threshold in the mean time, EC does a battery cutoff
>
> Be coherent using the same spelling along all the patch for cutoff.
Done.
>
>
> > instead of hibernating. On some chromebooks, S5 is optimal enough
> > resulting in EC hibernating without battery cut-off. This results in
>
> s/cut-off/cutoff/
Done.
>
> > battery deep-discharging. This is a bad user experience as battery
> > has to trickle charge before booting when the A.C is plugged in the next
> > time.
> >
> > This patch exposes a sysfs file for an userland daemon to suggest EC if it
> > has to do a battery cut-off instead of hibernating when the system enters
>
> s/cut-off/cutoff/
Done.
>
> > S5 next time.
> >
> > Signed-off-by: RaviChandra Sadineni 
> > ---
> >
> > V3: Make battery-cutoff generic and expose 'at-shutdown' flag.
> > V2: Use kstrtobool() instead of kstrtou8() and add documentation.
> >
> >
> > .../ABI/testing/sysfs-class-chromeos  | 10 
> >  drivers/platform/chrome/cros_ec_sysfs.c   | 48 +++
> >  2 files changed, 58 insertions(+)
> >  create mode 100644 Documentation/ABI/testing/sysfs-class-chromeos
> >
> > diff --git a/Documentation/ABI/testing/sysfs-class-chromeos 
> > b/Documentation/ABI/testing/sysfs-class-chromeos
> > new file mode 100644
> > index ..d5ab22c44977
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-class-chromeos
>
> Please rebase the patch on top of chrome-platform for-next [1] or 5.1-rc1 when
> released, so it applies cleanly.
Done.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git/log/?h=for-next
>
> > @@ -0,0 +1,10 @@
> > +What:   /sys/class/chromeos/cros_ec/battery-cuttoff
>
> The name should match with the attribute name, so battery_cutoff in this case 
> as
> you defined the attribute name as battery_cutoff
>
> Is this a common property for all the EC devices?
>
> Note that we have
>
> /sys/class/chromeos//...
>
> where  can be cros_ec|cros_pd and many others in the future
>
> On those devices that more than one EC is present we will have. E.g
>
>  cros_ec/battery_cutoff and cros_pd/battery_cutoff
>  cros_ec/battery_cutoff and cros_ish/battery_cutoff
>
> Which I think is not what you want. Ideally I'd like to see visible the
> attribute only on those ECs that support that feature. Is this command
> associated with an EC feature?
Yes with EC_FEATURE_BATTERY.  Now checking if EC supports EC_FEATURE_BATTERY.
>
> If that's not possible I can assume writing to battery_cutoff for ECs that 
> don't
> implement it would return a protocol/command error.

>
>
> > +Date:   February 2019
> > +Contact:Ravi Chandra Sadineni 
> > +Description:
> > +cros_ec battery cuttoff configuration. Only option
> > +currently exposed is 'at-shutdown'.
> > +
> > +'at-shutdown' sends a host command to EC requesting
> > +battery cutoff on next shutdown. If AC is plugged
> > +in before next shutdown, EC ignores the request.
> > diff --git a/drivers/platform/chrome/cros_ec_sysfs.c 
> > b/drivers/platform/chrome/cros_ec_sysfs.c
> > index f34a50121064..6ef6b860c818 100644
> > --- a/drivers/platform/chrome/cros_ec_sysfs.c
> > +++ b/drivers/platform/chrome/cros_ec_sysfs.c
> > @@ -322,14 +322,62 @@ static ssize_t kb_wake_angle_store(struct device *dev,
> >   return count;
> >  }
> >
> > +/* Battery cut-off control */
>
> s/cut-off/cutoff/
Done.
>
> > +static ssize_t battery_cutoff_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t count)
> > +{
> > + struct ec_params_battery_cutoff *param;
> > + struct cros_ec_command *msg;
> > + int ret;
> > + struct cros_ec_dev *ec =
> > + container_of(dev, struct cros_ec_dev, class_dev);
>
> use to_cros_ec_dev instead of container_of
>
> > + char *p;
> > + int len;
> > +
> > + msg = kmalloc(sizeof(*msg) + EC_HOST_PARAM_SIZE, GFP_KERNEL);
> > + if (!msg)
> > + return -ENOMEM;
> > +
> > + param = (struct ec_params_battery_cutoff *)msg->data;
> > + msg->command = EC_CMD_BATTERY_CUT_OFF + ec->cmd_offset;
> > + msg->version = 1;
> > + msg->outsize = sizeof(*param);
> > + msg->insize = 0;
> > +
> > + p = memchr(buf, '\n', count);
> > + len = p ? p - buf : count;
> > +
> > + if (len == 11 && !strncmp(buf, "at-shutdown", len)) {
> > + param->flags = 

[PATCH V5] platform/chrome: mfd/cros_ec_dev: Add sysfile to force

2019-03-08 Thread RaviChandra Sadineni
On chromebooks, power_manager daemon normally shuts down(S5) the device
when the battery charge falls below 4% threshold. ChromeOS EC then
normally spends an hour in S5 before hibernating. If the battery charge
falls below critical threshold in the mean time, EC does a battery cutoff
instead of hibernating. On some chromebooks, S5 is optimal enough
resulting in EC hibernating without battery cutoff. This results in
battery deep discharging. This is a bad user experience as battery
has to trickle charge before booting when the AC is plugged in the next
time.

This patch exposes a sysfs file for an userland daemon to suggest EC if it
has to do a battery cutoff instead of hibernating when the system enters
S5 next time.

This attribute is present only if EC supports EC_FEATURE_BATTERY.

Signed-off-by: RaviChandra Sadineni 
---
V5: Expose flag only when EC_FEATURE_BATTERY is supported.
V4: Addressed comments from Enric.
V3: Make battery-cutoff generic and expose 'at-shutdown' flag.
V2: Use kstrtobool() instead of kstrtou8() and add documentation.

.../ABI/testing/sysfs-class-chromeos  | 16 ++
 drivers/mfd/cros_ec_dev.c |  4 ++
 drivers/platform/chrome/cros_ec_sysfs.c   | 49 +++
 include/linux/mfd/cros_ec.h   |  2 +
 4 files changed, 71 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-chromeos 
b/Documentation/ABI/testing/sysfs-class-chromeos
index 5819699d66ec..0927704d1629 100644
--- a/Documentation/ABI/testing/sysfs-class-chromeos
+++ b/Documentation/ABI/testing/sysfs-class-chromeos
@@ -30,3 +30,19 @@ Date:August 2015
 KernelVersion: 4.2
 Description:
Show the information about the EC software and hardware.
+
+What:   /sys/class/chromeos//battery_cuttoff
+Date:   February 2019
+Contact:Ravi Chandra Sadineni 
+Description:
+cros_ec battery cuttoff configuration. Only option
+currently exposed is 'at-shutdown'.
+
+'at-shutdown' sends a host command to EC requesting
+battery cutoff on next shutdown. If AC is plugged
+in before next shutdown, EC ignores the request and
+resets the flag.
+
+Currently EC does not expose a host command to read
+the status of battery cutoff configuration. Thus this
+flag is write-only.
diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index ed809fc97df8..7580be23dfb3 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -502,6 +502,10 @@ static int ec_device_probe(struct platform_device *pdev)
 retval);
}
 
+   /* check whether EC_FEATURE_BATTERY is supported. */
+   if (cros_ec_check_features(ec, EC_FEATURE_BATTERY))
+   ec->has_battery = true;
+
return 0;
 
 failed:
diff --git a/drivers/platform/chrome/cros_ec_sysfs.c 
b/drivers/platform/chrome/cros_ec_sysfs.c
index fe0b7614ae1b..3d9ab55dddc0 100644
--- a/drivers/platform/chrome/cros_ec_sysfs.c
+++ b/drivers/platform/chrome/cros_ec_sysfs.c
@@ -308,14 +308,61 @@ static ssize_t kb_wake_angle_store(struct device *dev,
return count;
 }
 
+/* Battery cutoff control */
+static ssize_t battery_cutoff_store(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct ec_params_battery_cutoff *param;
+   struct cros_ec_command *msg;
+   int ret;
+   struct cros_ec_dev *ec = to_cros_ec_dev(dev);
+   char *p;
+   int len;
+
+   msg = kmalloc(sizeof(*msg) + EC_HOST_PARAM_SIZE, GFP_KERNEL);
+   if (!msg)
+   return -ENOMEM;
+
+   param = (struct ec_params_battery_cutoff *)msg->data;
+   msg->command = EC_CMD_BATTERY_CUT_OFF + ec->cmd_offset;
+   msg->version = 1;
+   msg->outsize = sizeof(*param);
+   msg->insize = 0;
+
+   p = memchr(buf, '\n', count);
+   len = p ? p - buf : count;
+
+   if (len == 11 && !strncmp(buf, "at-shutdown", len)) {
+   param->flags = EC_BATTERY_CUTOFF_FLAG_AT_SHUTDOWN;
+   } else {
+   count = -EINVAL;
+   goto exit;
+   }
+
+   ret = cros_ec_cmd_xfer_status(ec->ec_dev, msg);
+   if (ret < 0)
+   count = ret;
+exit:
+   kfree(msg);
+   return count;
+}
+
 /* Module initialization */
 
 static DEVICE_ATTR_RW(reboot);
 static DEVICE_ATTR_RO(version);
 static DEVICE_ATTR_RO(flashinfo);
 static DEVICE_ATTR_RW(kb_wake_angle);
+/*
+ * Currently EC does not expose a host command to read the status of
+ * battery cutoff configuration. Also there is no requirement to read
+ * the flag from userland. So marking this attribute as write-only.
+ */
+static DEVICE_ATTR_WO(battery_cutoff);
 
 static struct attribute *__ec_attrs[] = {
+   _attr_battery_cutoff.attr,

Re: [PATCH v2] appletalk: Correctly check return value of register_snap_client

2019-03-08 Thread YueHaibing
ping.

On 2019/3/7 10:22, Yue Haibing wrote:
> From: YueHaibing 
> 
> register_snap_client may return NULL, all the callers
> check it, but only print a warning. This will result in
> NULL pointer dereference in unregister_snap_client and other
> places.
> 
> It has always been used like this since v2.6
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: YueHaibing 
> ---
> v2: fix aarp_dl leak
> ---
>  include/linux/atalk.h |  2 +-
>  net/appletalk/aarp.c  | 13 ++---
>  net/appletalk/ddp.c   | 20 
>  3 files changed, 23 insertions(+), 12 deletions(-)
> 
> diff --git a/include/linux/atalk.h b/include/linux/atalk.h
> index 5a90f28..0e5265a 100644
> --- a/include/linux/atalk.h
> +++ b/include/linux/atalk.h
> @@ -108,7 +108,7 @@ static __inline__ struct elapaarp *aarp_hdr(struct 
> sk_buff *skb)
>  #define AARP_RESOLVE_TIME(10 * HZ)
>  
>  extern struct datalink_proto *ddp_dl, *aarp_dl;
> -extern void aarp_proto_init(void);
> +extern int aarp_proto_init(void);
>  
>  /* Inter module exports */
>  
> diff --git a/net/appletalk/aarp.c b/net/appletalk/aarp.c
> index 49a16ce..d11372d 100644
> --- a/net/appletalk/aarp.c
> +++ b/net/appletalk/aarp.c
> @@ -879,15 +879,22 @@ static struct notifier_block aarp_notifier = {
>  
>  static unsigned char aarp_snap_id[] = { 0x00, 0x00, 0x00, 0x80, 0xF3 };
>  
> -void __init aarp_proto_init(void)
> +int __init aarp_proto_init(void)
>  {
> + int rc;
> +
>   aarp_dl = register_snap_client(aarp_snap_id, aarp_rcv);
> - if (!aarp_dl)
> + if (!aarp_dl) {
>   printk(KERN_CRIT "Unable to register AARP with SNAP.\n");
> + return -ENOMEM;
> + }
>   timer_setup(_timer, aarp_expire_timeout, 0);
>   aarp_timer.expires  = jiffies + sysctl_aarp_expiry_time;
>   add_timer(_timer);
> - register_netdevice_notifier(_notifier);
> + rc = register_netdevice_notifier(_notifier);
> + if (rc)
> + unregister_snap_client(aarp_dl);
> + return rc;
>  }
>  
>  /* Remove the AARP entries associated with a device. */
> diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
> index 795fbc6..709d254 100644
> --- a/net/appletalk/ddp.c
> +++ b/net/appletalk/ddp.c
> @@ -1904,9 +1904,6 @@ static unsigned char ddp_snap_id[] = { 0x08, 0x00, 
> 0x07, 0x80, 0x9B };
>  EXPORT_SYMBOL(atrtr_get_dev);
>  EXPORT_SYMBOL(atalk_find_dev_addr);
>  
> -static const char atalk_err_snap[] __initconst =
> - KERN_CRIT "Unable to register DDP with SNAP.\n";
> -
>  /* Called by proto.c on kernel start up */
>  static int __init atalk_init(void)
>  {
> @@ -1921,17 +1918,22 @@ static int __init atalk_init(void)
>   goto out_proto;
>  
>   ddp_dl = register_snap_client(ddp_snap_id, atalk_rcv);
> - if (!ddp_dl)
> - printk(atalk_err_snap);
> + if (!ddp_dl) {
> + pr_crit("Unable to register DDP with SNAP.\n");
> + goto out_sock;
> + }
>  
>   dev_add_pack(_packet_type);
>   dev_add_pack(_packet_type);
>  
>   rc = register_netdevice_notifier(_notifier);
>   if (rc)
> - goto out_sock;
> + goto out_snap;
> +
> + rc = aarp_proto_init();
> + if (rc)
> + goto out_dev;
>  
> - aarp_proto_init();
>   rc = atalk_proc_init();
>   if (rc)
>   goto out_aarp;
> @@ -1945,11 +1947,13 @@ static int __init atalk_init(void)
>   atalk_proc_exit();
>  out_aarp:
>   aarp_cleanup_module();
> +out_dev:
>   unregister_netdevice_notifier(_notifier);
> -out_sock:
> +out_snap:
>   dev_remove_pack(_packet_type);
>   dev_remove_pack(_packet_type);
>   unregister_snap_client(ddp_dl);
> +out_sock:
>   sock_unregister(PF_APPLETALK);
>  out_proto:
>   proto_unregister(_proto);
> 



[GIT PULL] Kbuild updates for v5.1

2019-03-08 Thread Masahiro Yamada
Hi Linus,

Please pull Kbuild updates for v5.1


You will see a merge conflict in ./Kbuild

The fixup is available in linux-next.


Thanks!





The following changes since commit f17b5f06cb92ef2250513a1e154c47b78df07d40:

  Linux 5.0-rc4 (2019-01-27 15:18:05 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
tags/kbuild-v5.1

for you to fetch changes up to 9250d20e9ecedab6aa331a127fbfc1272383ed72:

  kbuild: remove scripts/basic/% build target (2019-03-05 02:02:44 +0900)


Kbuild updates for v5.1

 - do not generate unneeded top-level built-in.a

 - let git ignore O= directory entirely

 - optimize scripts/kallsyms slightly

 - exclude DWARF info from *.s regardless of config options

 - fix GCC toolchain search path for Clang to prepare ld.lld support

 - do not generate modules.order when CONFIG_MODULES is disabled

 - simplify single target rules and remove VPATH for external module build

 - allow to add optional flags to dpkg-buildpackage when building deb-pkg

 - move some compiler option tests from Makefile to Kconfig

 - various Makefile cleanups


Kacper Kołodziej (1):
  kbuild: [bin]deb-pkg: add DPKG_FLAGS variable

Luc Van Oostenryck (1):
  kbuild: use -Werror=implicit-... instead of -Werror-implicit-...

Masahiro Yamada (36):
  kbuild: skip 'addtree' and 'flags' magic for external module build
  kbuild: remove top-level built-in.a
  kbuild: merge KBUILD_VMLINUX_{INIT,MAIN} into KBUILD_VMLINUX_OBJS
  kbuild: simplify rules of data compression with size appending
  s390: make built-in.a not directly depend on *.o.chkbss files
  kbuild: add real-prereqs shorthand for $(filter-out FORCE,$^)
  kbuild: remove unnecessary in-subshell execution
  kbuild: remove meaningless prepare2 target
  kallsyms: add static qualifiers where missing
  kallsyms: remove unneeded memset() calls
  kallsyms: include  instead of 
  kbuild: Disable extra debugging info in .s output
  kbuild: pkg: use -f $(srctree)/Makefile to recurse to top Makefile
  kbuild: generate modules.order only when CONFIG_MODULES=y
  kbuild: set KBUILD_MODULES=1 all the time for single target %/
  kbuild: turn '/' into an alias of './'
  scripts/gdb: delay generation of gdb constants.py
  kbuild: remove unimportant comments from ./Kbuild
  scripts/gdb: do not descend into scripts/gdb from scripts
  kbuild: create symlink to vmlinux-gdb.py in scripts_gdb target
  scripts/gdb: refactor rules for symlink creation
  kbuild: hardcode genksyms path and remove GENKSYMS variable
  kbuild: refactor cc-cross-prefix implementation
  kbuild: compute false-positive -Wmaybe-uninitialized cases in Kconfig
  kbuild: move tools_silent to a more relevant place
  kbuild: make -r/-R effective in top Makefile for old Make versions
  kbuild: remove empty rules for makefiles
  kbuild: simplify single target rules
  kbuild: invoke syncconfig if include/config/auto.conf.cmd is missing
  kbuild: move ".config not found!" message from Kconfig to Makefile
  kbuild: move -gsplit-dwarf, -gdwarf-4 option tests to Kconfig
  kbuild: remove commented-out INITRD_COMPRESS
  kbuild: update comment block of scripts/clang-version.sh
  kbuild: remove cc-version macro
  kbuild: clean up scripts/gcc-version.sh
  kbuild: remove scripts/basic/% build target

Nick Desaulniers (1):
  kbuild: clang: choose GCC_TOOLCHAIN_DIR not on LD

Vladimir Kondratiev (1):
  kbuild: gitignore output directory

 Documentation/devicetree/bindings/Makefile |   2 +-
 Documentation/kbuild/kbuild.txt|  15 ++--
 Documentation/kbuild/makefiles.txt |  26 +--
 Documentation/kbuild/modules.txt   |   2 +-
 Kbuild |  25 +--
 Makefile   | 219
++
 arch/mips/boot/Makefile|   2 +-
 arch/powerpc/boot/Makefile |   2 +-
 arch/s390/boot/Makefile|   6 +-
 arch/s390/boot/compressed/Makefile |   4 +-
 arch/s390/scripts/Makefile.chkbss  |  25 +++
 arch/x86/realmode/rm/Makefile  |   3 +-
 init/Kconfig   |  19 -
 kernel/trace/Kconfig   |   1 +
 lib/Kconfig.debug  |   2 +
 scripts/Kbuild.include |  21 +++---
 scripts/Kconfig.include|   2 +-
 scripts/Makefile   |   3 +-
 scripts/Makefile.build |  29 
 scripts/Makefile.host  |   6 +-
 scripts/Makefile.lib   |  42 +--
 scripts/Makefile.modpost   |   2 +-
 

Re: [PATCH v6 5/7] gpu: ipu-v3: ipu-ic: Add support for limited range encoding

2019-03-08 Thread Steve Longerbeam




On 3/8/19 3:57 AM, Philipp Zabel wrote:

On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:

Add support for the following conversions:

- YUV full-range to YUV limited-range
- YUV limited-range to YUV full-range
- YUV limited-range to RGB full-range
- RGB full-range to YUV limited-range

The last two conversions require operating on the YUV full-range
encoding and inverse encoding coefficients, with the YUV-to-YUV
limited<->full coefficients. The formula to convert is

M_c = M_a * M_b
O_c = M_a * O_b + O_a

For calculating the RGB full-range to YUV limited-range coefficients:

[M_a, O_a] = YUV full-range to YUV limited-range coefficients.
[M_b, O_b] = RGB full-range to YUV full-range coefficients.

For calculating the YUV limited-range to RGB full-range coefficients:

[M_a, O_a] = YUV full-range to RGB full-range coefficients.
[M_b, O_b] = YUV limited-range to YUV full-range coefficients.

The calculation of [M_c, O_c] is carried out by the function
transform_coeffs().

In the future if RGB limited range encoding is required, the same
function can be used. And cascaded to create all combinations of
encoding for YUV limited/full range <-> RGB limited/full range,
passing the output coefficients from one call as the input for the
next.

For example, to create YUV full-range to RGB limited-range coefficients:

[M_a, O_a] = RGB full-range to RGB limited-range coefficients.
[M_b, O_b] = YUV full-range to RGB full-range coefficients.

and that output sent as input to create YUV limited-range to RGB
limited-range coefficients:

[M_a, O_a] = YUV full-range to RGB limited-range coefficients.
[M_b, O_b] = YUV limited-range to YUV full-range coefficients.

Signed-off-by: Steve Longerbeam 

I'm not a big fan of this. Wouldn't it be much easier to compute all
necessary task parameter sets offline with high precision, and store the
precomputed sets in the compact representation?


I am thinking of when support might be added for the other encoding 
standards. With this transform function, only two new task parameter 
structs need to be added, one for yuv-full-to-rgb-full, and one for 
rgb-full-to-yuv-full. Without transform_coeffs(), four structs would 
have to be added (adding encoding to and from yuv-limited). And if 
rgb-limited support is added, it would mean a total of eight new structs 
for a new encoding standard. But with transform_coeffs(), still only the 
two structs above are needed, and the function would compute the others 
automatically in runtime.


Steve





---
  drivers/gpu/ipu-v3/ipu-ic.c | 281 +---
  1 file changed, 263 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 1460901af9b5..a7dd85f8d832 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -178,10 +178,10 @@ static inline void ipu_ic_write(struct ipu_ic *ic, u32 
value, unsigned offset)
  }
  
  struct ic_encode_coeff {

-   s16 coeff[3][3];/* signed 9-bit integer coefficients */
-   s16 offset[3];  /* signed 11+2-bit fixed point offset */
-   u8 scale:2; /* scale coefficients * 2^(scale-1) */
-   bool sat:1; /* saturate to (16, 235(Y) / 240(U, V)) */
+   int coeff[3][3];/* signed 9-bit integer coefficients */
+   int offset[3];  /* signed 13-bit integer offset */
+   int scale;  /* scale coefficients * 2^(scale-1) */
+   bool sat;   /* saturate to (16, 235(Y) / 240(U, V)) */
  };
  
  /*

@@ -277,6 +277,231 @@ static const struct ic_encode_coeff 
ic_encode_ycbcr2rgb_709 = {
.scale = 2,
  };
  
+/*

+ * YUV full range to YUV limited range:
+ *
+ * Y_lim  = 0.8588 * Y_full + 16
+ * Cb_lim = 0.8784 * (Cb_full - 128) + 128
+ * Cr_lim = 0.8784 * (Cr_full - 128) + 128
+ */
+static const struct ic_encode_coeff ic_encode_ycbcr_full2lim = {
+   .coeff = {
+   { 219, 0, 0 },
+   { 0, 224, 0 },
+   { 0, 0, 224 },
+   },
+   .offset = { 64, 62, 62 },
+   .scale = 1,
+};
+
+/*
+ * YUV limited range to YUV full range:
+ *
+ * Y_full  = 1.1644 * (Y_lim - 16)
+ * Cb_full = 1.1384 * (Cb_lim - 128) + 128
+ * Cr_full = 1.1384 * (Cr_lim - 128) + 128
+ */
+static const struct ic_encode_coeff ic_encode_ycbcr_lim2full = {
+   .coeff = {
+   { 149, 0, 0 },
+   { 0, 145, 0 },
+   { 0, 0, 145 },
+   },
+   .offset = { -37, -35, -35 },
+   .scale = 2,
+};
+
+/*
+ * RGB full range to RGB limited range:
+ *
+ * R_lim = 0.8588 * R_full + 16
+ * G_lim = 0.8588 * G_full + 16
+ * B_lim = 0.8588 * B_full + 16
+ */
+static const struct ic_encode_coeff
+ic_encode_rgb_full2lim __maybe_unused = {
+   .coeff = {
+   { 220, 0, 0 },
+   { 0, 220, 0 },
+   { 0, 0, 220 },
+   },
+   .offset = { 64, 64, 64 },
+   .scale = 1,
+};
+
+/*
+ * RGB limited range to RGB full range:
+ *
+ * 

Re: [PATCH v6 3/7] gpu: ipu-v3: ipu-ic: Fully describe colorspace conversions

2019-03-08 Thread Steve Longerbeam




On 3/8/19 3:46 AM, Philipp Zabel wrote:

On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:

Only providing the input and output RGB/YUV space to the IC task init
functions is not sufficient. To fully characterize a colorspace
conversion, the colorspace (chromaticities), Y'CbCr encoding standard,
and quantization also need to be specified.

Define a 'struct ipu_ic_colorspace' that includes all the above, and pass
the input and output ipu_ic_colorspace to the IC task init functions.

This allows to actually enforce the fact that the IC:

- can only encode to/from YUV full range (follow-up patch will remove
   this restriction).
- can only encode to/from RGB full range.
- can only encode using BT.601 standard (follow-up patch will add
   Rec.709 encoding support).
- cannot convert colorspaces from input to output, the
   input and output colorspace chromaticities must be the same.

The determination of the CSC coefficients based on the input/output
colorspace parameters are moved to a new function calc_csc_coeffs(),
called by init_csc().

Signed-off-by: Steve Longerbeam 
---
  drivers/gpu/ipu-v3/ipu-ic.c | 136 +---
  drivers/gpu/ipu-v3/ipu-image-convert.c  |  27 ++--
  drivers/staging/media/imx/imx-ic-prpencvf.c |  22 +++-
  include/video/imx-ipu-v3.h  |  37 +-
  4 files changed, 154 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index b63a2826b629..c4048c921801 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -146,8 +146,10 @@ struct ipu_ic {
const struct ic_task_regoffs *reg;
const struct ic_task_bitfields *bit;
  
-	enum ipu_color_space in_cs, g_in_cs;

-   enum ipu_color_space out_cs;
+   struct ipu_ic_colorspace in_cs;
+   struct ipu_ic_colorspace g_in_cs;
+   struct ipu_ic_colorspace out_cs;
+
bool graphics;
bool rotation;
bool in_use;
@@ -235,42 +237,83 @@ static const struct ic_encode_coeff 
ic_encode_ycbcr2rgb_601 = {
.scale = 2,
  };
  
+static int calc_csc_coeffs(struct ipu_ic_priv *priv,

+  struct ic_encode_coeff *coeff_out,
+  const struct ipu_ic_colorspace *in,
+  const struct ipu_ic_colorspace *out)
+{
+   bool inverse_encode;
+
+   if (in->colorspace != out->colorspace) {
+   dev_err(priv->ipu->dev, "Cannot convert colorspaces\n");
+   return -ENOTSUPP;
+   }

I don't think this is useful enough to warrant having the colorspace
field in ipu_ic_colorspace. Let the caller make sure of this, same as
for xfer_func.


Ok, for xfer_func it is implicit that the gamma function must be the 
same for input and output, so I agree it might as well be implicit for 
chromaticities too.






+   if (out->enc != V4L2_YCBCR_ENC_601) {
+   dev_err(priv->ipu->dev, "Only BT.601 encoding supported\n");
+   return -ENOTSUPP;
+   }

This is only important if out->cs is IPUV3_COLORSPACE_YUV, right? If the
output is RGB this field shouldn't matter.


It matters for encoding YUV to RGB, or the inverse RGB to YUV. The 
encoding standard doesn't matter only if no encoding/inverse encoding is 
requested (YUV to YUV or RGB to RGB).





+
+   if ((in->cs == IPUV3_COLORSPACE_YUV &&
+in->quant != V4L2_QUANTIZATION_FULL_RANGE) ||
+   (out->cs == IPUV3_COLORSPACE_YUV &&
+out->quant != V4L2_QUANTIZATION_FULL_RANGE)) {
+   dev_err(priv->ipu->dev, "Limited range YUV not supported\n");
+   return -ENOTSUPP;
+   }
+
+   if ((in->cs == IPUV3_COLORSPACE_RGB &&
+in->quant != V4L2_QUANTIZATION_FULL_RANGE) ||
+   (out->cs == IPUV3_COLORSPACE_RGB &&
+out->quant != V4L2_QUANTIZATION_FULL_RANGE)) {
+   dev_err(priv->ipu->dev, "Limited range RGB not supported\n");
+   return -ENOTSUPP;
+   }
+
+   if (in->cs == out->cs) {
+   *coeff_out = ic_encode_identity;
+
+   return 0;
+   }
+
+   inverse_encode = (in->cs == IPUV3_COLORSPACE_YUV);

What does inverse_encode mean in this context?


It means YUV to RGB. At this point in the function it is determined that 
encoding or inverse encoding is requested.





+
+   *coeff_out = inverse_encode ?
+   ic_encode_ycbcr2rgb_601 : ic_encode_rgb2ycbcr_601;
+
+   return 0;
+}
+
  static int init_csc(struct ipu_ic *ic,
-   enum ipu_color_space inf,
-   enum ipu_color_space outf,
+   const struct ipu_ic_colorspace *in,
+   const struct ipu_ic_colorspace *out,
int csc_index)
  {
struct ipu_ic_priv *priv = ic->priv;
-   const struct ic_encode_coeff *coeff;
+   struct ic_encode_coeff coeff;

I understand this is a preparation for patch 5, but on its own this
introduces an 

Re: [PATCH v6 2/7] gpu: ipu-v3: ipu-ic: Fix BT.601 coefficients

2019-03-08 Thread Steve Longerbeam




On 3/8/19 2:23 AM, Philipp Zabel wrote:

Hi Steve,

On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:

The ycbcr2rgb and inverse rgb2ycbcr tables define the BT.601 Y'CbCr
encoding coefficients.

The rgb2ycbcr table specifically describes the BT.601 encoding from
full range RGB to full range YUV. Add table comments to make this more
clear.

The ycbcr2rgb inverse table describes encoding YUV limited range to RGB
full range. To be consistent with the rgb2ycbcr table, convert this to
YUV full range to RGB full range, and adjust/expand on the comments.

The ic_csc_rgb2rgb table is just an identity matrix, so rename to
ic_encode_identity.

Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter unit")

Suggested-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
Cc: sta...@vger.kernel.org
---
  drivers/gpu/ipu-v3/ipu-ic.c | 61 ++---
  1 file changed, 37 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 18816ccf600e..b63a2826b629 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -175,7 +175,7 @@ static inline void ipu_ic_write(struct ipu_ic *ic, u32 
value, unsigned offset)
writel(value, ic->priv->base + offset);
  }
  
-struct ic_csc_params {

+struct ic_encode_coeff {

This less accurate. These are called IC (Task) Parameters in the
reference manual, the 64-bit aligned words are called CSC words. Beside
the coefficients, this structure also contains the coefficient scale,
the offsets, and the saturation mode flag.


It seemed to me the renaming was more clear, but I agree the former name 
conforms better to the manual nomenclature. I will revert this renaming.






s16 coeff[3][3];/* signed 9-bit integer coefficients */
s16 offset[3];  /* signed 11+2-bit fixed point offset */
u8 scale:2; /* scale coefficients * 2^(scale-1) */
@@ -183,13 +183,15 @@ struct ic_csc_params {
  };
  
  /*

- * Y = R *  .299 + G *  .587 + B *  .114;
- * U = R * -.169 + G * -.332 + B *  .500 + 128.;
- * V = R *  .500 + G * -.419 + B * -.0813 + 128.;
+ * BT.601 encoding from RGB full range to YUV full range:
+ *
+ * Y =  .2990 * R + .5870 * G + .1140 * B
+ * U = -.1687 * R - .3313 * G + .5000 * B + 128
+ * V =  .5000 * R - .4187 * G - .0813 * B + 128
   */
-static const struct ic_csc_params ic_csc_rgb2ycbcr = {
+static const struct ic_encode_coeff ic_encode_rgb2ycbcr_601 = {
.coeff = {
-   { 77, 150, 29 },
+   {  77, 150,  29 },
{ 469, 427, 128 },
{ 128, 405, 491 },

We could subtract 512 from the negative values, to improve readability.


Agreed.




},
@@ -197,8 +199,11 @@ static const struct ic_csc_params ic_csc_rgb2ycbcr = {
.scale = 1,
  };
  
-/* transparent RGB->RGB matrix for graphics combining */

-static const struct ic_csc_params ic_csc_rgb2rgb = {
+/*
+ * identity matrix, used for transparent RGB->RGB graphics
+ * combining.
+ */
+static const struct ic_encode_coeff ic_encode_identity = {
.coeff = {
{ 128, 0, 0 },
{ 0, 128, 0 },
@@ -208,17 +213,25 @@ static const struct ic_csc_params ic_csc_rgb2rgb = {
  };
  
  /*

- * R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));
- * G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));
- * B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128);
+ * Inverse BT.601 encoding from YUV full range to RGB full range:
+ *
+ * R = 1. * Y +  0 * (Cb - 128) + 1.4020 * (Cr - 128)
+ * G = 1. * Y -  .3442 * (Cb - 128) - 0.7142 * (Cr - 128)

Should that be  ^ .3441   and ^ .7141 ?
The coefficients and offsets after rounding should end up the same.


Ok.



Also, let's consistently either add the leading zero, or leave it out.


Yes.




+ * B = 1. * Y + 1.7720 * (Cb - 128) +  0 * (Cr - 128)
+ *
+ * equivalently (factoring out the offsets):
+ *
+ * R = 1. * Y  +  0 * Cb + 1.4020 * Cr - 179.456
+ * G = 1. * Y  -  .3442 * Cb - 0.7142 * Cr + 135.475
+ * B = 1. * Y  + 1.7720 * Cb +  0 * Cr - 226.816
   */
-static const struct ic_csc_params ic_csc_ycbcr2rgb = {
+static const struct ic_encode_coeff ic_encode_ycbcr2rgb_601 = {
.coeff = {
-   { 149, 0, 204 },
-   { 149, 462, 408 },
-   { 149, 255, 0 },
+   { 128,   0, 179 },
+   { 128, 468, 421 },
+   { 128, 227,   0 },
},
-   .offset = { -446, 266, -554 },
+   .offset = { -359, 271, -454 },

These seem to be correct. Again, I think this would be easier to read if
the negative coefficients were written with a sign as well.


.scale = 2,
  };
  
@@ -228,7 +241,7 @@ static int init_csc(struct ipu_ic *ic,

int csc_index)
  {
struct ipu_ic_priv *priv = ic->priv;
-   const struct ic_csc_params *params;
+   const struct ic_encode_coeff *coeff;
u32 __iomem *base;
const 

Re: [PATCH] kbuild: Speed up install, modules_install and kernelrelease

2019-03-08 Thread Masahiro Yamada
On Sat, Mar 9, 2019 at 7:34 AM Doug Anderson  wrote:
>
> Hi,
>
> On Fri, Mar 8, 2019 at 2:29 PM Guenter Roeck  wrote:
> >
> > On Fri, Mar 8, 2019 at 1:25 PM Douglas Anderson  
> > wrote:
> > >
> > > As per the description of the old commit 3298b690b21c ("kbuild: Add a
> > > cache for generated variables"), calling the C compiler lots of times
> > > during the parsing stage of the Makefile can be a little slow.  If you
> > > happen to have a C compiler whose fork/exec time isn't optimized
> > > (perhaps it was linked dynamically, or perhaps it's called through
> > > several wrappers, or ...) then this can be more than a little slow, it
> > > can be very slow.
> > >
> > > The above slowness was addressed with the old Makefile cache, but the
> > > cache was reverted in commit e08d6de4e532 ("kbuild: remove kbuild
> > > cache").  That commit indicated that we expected to get the speed
> > > gains back because "the result of compiler tests will be naturally
> > > cached in the .config file", but as of the latest mainline there are
> > > still lots of direct calls to the C compiler that happen in the
> > > Makefile parsing stage.
> > >
> > > Perhaps we could try re-introducing the Makefile cache and fix the
> > > problems it was causing, but this patch codes up another solution that
> > > gets some of the speed gains back, perhaps with less complexity.
> > >
> > > Specifically I observed that by timing the parsing stage of the
> > > Makefile by adding statements like this to the beginning and end of
> > > the Makefile:
> > >   ZZZ := $(shell echo "$$(date '+%T.%N'): ..." >> /tmp/timing.txt)
> > >
> > > ...that three targets were spending 3 seconds each parsing the
> > > Makefile in my environment (building a Chrome OS kernel with clang)
> > > when it felt like they ought to be quick.  These were: install,
> > > modules_install and kernelrelease
> > >
> > > I saw timings that looked like:
> > >   09:23:08.903204451: Parsing Makefile, goals: install
> > >   09:23:11.960515772: Done parsing Makefile, goals: install
> > >
> > > Given that the kbuild system doesn't sync the config for any of these
> > > options I believe it is safe to say that it can't compile any code.
> > > Thus if we can avoid the C compiler invocation here we'll save time.
> > >
> > > The simplest way to accomplish this is to neuter all the calls to the
> > > compiler by stubbing them out.  After doing so (AKA applying this
> > > change) the same timing looks like:
> > >   09:28:04.929252271: Parsing Makefile, goals: install
> > >   09:28:05.107468449: Done parsing Makefile, goals: install
> > >
> > > During an incremental kernel build/install on Chrome OS we call
> > > install once, modules_install twice (once to keep unstripped), and
> > > kernelrelease once.  Thus this saves ~12 seconds on an incremental
> > > kernel build/install.  With my current setup, this brings it from ~40
> > > seconds to ~28 seconds.  Re-introducing the Makefile cache would
> > > likely save us an extra ~3 seconds since we'd avoid the parsing in the
> > > compile stage.
> > >
> > > Signed-off-by: Douglas Anderson 
> > > ---
> > >
> > >  Makefile | 14 ++
> > >  1 file changed, 14 insertions(+)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index f070e0d65186..5f7532d9be65 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -304,6 +304,20 @@ else
> > >  scripts/Kbuild.include: ;
> > >  include scripts/Kbuild.include
> > >
> > > +# If we can't sync the config then we know we can't compile code.
> > > +# Replace the slow option-testing commands with stubs to significantly
> > > +# speed up the Makefile parsing stage of the build.
> > > +ifeq ($(may-sync-config),0)
> >
> > I think that breaks KBUILD_EXTMOD, which sets the variable to 0.
>
> Yup, thanks for catching--I should have realized that from the code
> but somehow skimmed over the KBUILD_EXTMOD bits.  I confirmed that
> this is broken.
>
> I can certainly add an extra check to confirm that '$(KBUILD_EXTMOD)'
> is unset and I'll do that in a v2 if I don't hear anything, but before
> sending that I'll give folks a little bit of time to smack down my
> general approach.  To be honest my approach is a bit of a hack so if
> others can think of better ways to avoid all the unnecessary work
> during install / modules_install / kernelrelease then I'm all ears!
> :-)


I think 3 sec is better than your previous report.

I do not think the current situation is painful level
for other general users.
The parse stage takes less than 0.5 sec even on my
old, cheap machine.

Upstream code will continue to improve, but the progress
will be slow.

Given that this pain comes from wrapping CC with script,
may I ask you to solve this on Chrome OS side meanwhile?


For example, pass cc-option= from the command line etc.


 make modules_install cc-option=


will give you better result.



--
Best Regards
Masahiro Yamada


[PATCH net] rxrpc: Fix client call queueing, waiting for channel

2019-03-08 Thread David Howells
rxrpc_get_client_conn() adds a new call to the front of the waiting_calls
queue if the connection it's going to use already exists.  This is bad as
it allows calls to get starved out.

Fix this by adding to the tail instead.

Also change the other enqueue point in the same function to put it on the
front (ie. when we have a new connection).  This makes the point that in
the case of a new connection the new call goes at the front (though it
doesn't actually matter since the queue should be unoccupied).

Fixes: 45025bceef17 ("rxrpc: Improve management and caching of client 
connection objects")
Signed-off-by: David Howells 
Reviewed-by: Marc Dionne 
---

 net/rxrpc/conn_client.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/rxrpc/conn_client.c b/net/rxrpc/conn_client.c
index 505690dbd0be..04e62afea063 100644
--- a/net/rxrpc/conn_client.c
+++ b/net/rxrpc/conn_client.c
@@ -354,7 +354,7 @@ static int rxrpc_get_client_conn(struct rxrpc_sock *rx,
 * normally have to take channel_lock but we do this before anyone else
 * can see the connection.
 */
-   list_add_tail(>chan_wait_link, >waiting_calls);
+   list_add(>chan_wait_link, >waiting_calls);
 
if (cp->exclusive) {
call->conn = candidate;
@@ -433,7 +433,7 @@ static int rxrpc_get_client_conn(struct rxrpc_sock *rx,
call->conn = conn;
call->security_ix = conn->security_ix;
call->service_id = conn->service_id;
-   list_add(>chan_wait_link, >waiting_calls);
+   list_add_tail(>chan_wait_link, >waiting_calls);
spin_unlock(>channel_lock);
_leave(" = 0 [extant %d]", conn->debug_id);
return 0;



Re: [PATCH] mm/compaction: fix an undefined behaviour

2019-03-08 Thread Mel Gorman
On Fri, Mar 08, 2019 at 05:46:50PM -0500, Qian Cai wrote:
> In a low-memory situation, cc->fast_search_fail can keep increasing as
> it is unable to find an available page to isolate in
> fast_isolate_freepages(). As the result, it could trigger an error
> below, so just compare with the maximum bits can be shifted first.
> 
> UBSAN: Undefined behaviour in mm/compaction.c:1160:30
> shift exponent 64 is too large for 64-bit type 'unsigned long'
> CPU: 131 PID: 1308 Comm: kcompactd1 Kdump: loaded Tainted: G
> WL5.0.0+ #17
> Call trace:
>  dump_backtrace+0x0/0x450
>  show_stack+0x20/0x2c
>  dump_stack+0xc8/0x14c
>  __ubsan_handle_shift_out_of_bounds+0x7e8/0x8c4
>  compaction_alloc+0x2344/0x2484
>  unmap_and_move+0xdc/0x1dbc
>  migrate_pages+0x274/0x1310
>  compact_zone+0x26ec/0x43bc
>  kcompactd+0x15b8/0x1a24
>  kthread+0x374/0x390
>  ret_from_fork+0x10/0x18
> 
> Fixes: 70b44595eafe ("mm, compaction: use free lists to quickly locate a 
> migration source")
> Signed-off-by: Qian Cai 

Acked-by: Mel Gorman 

FWIW, I had seen the same message when trying to isolate potential
corruption (still unsuccessful, the tests always complete) but
considered it relatively benign and harmless. Still worth fixing so
thanks.

-- 
Mel Gorman
SUSE Labs


Re: [PATCH][next] net/mlx5e: Remove redundant assignment

2019-03-08 Thread Saeed Mahameed
On Tue, 2019-03-05 at 19:03 -0800, David Miller wrote:
> From: Saeed Mahameed 
> Date: Tue, 5 Mar 2019 22:21:39 +
> 
> > On Mon, 2019-03-04 at 08:26 +0200, Leon Romanovsky wrote:
> > > On Sun, Mar 03, 2019 at 03:20:57PM +, Roi Dayan wrote:
> > > > On 02/03/2019 21:39, Gustavo A. R. Silva wrote:
> > > > > Remove redundant assignment to tun_entropy->enabled.
> > > > > 
> > > > > Addesses-Coverity-ID: 1477328 ("Unused value")
> > > > > Fixes: 97417f6182f8 ("net/mlx5e: Fix GRE key by controlling
> > > > > port
> > > > > tunnel entropy calculation")
> > > > 
> > > > the commit doesn't fix any real issue but is more of a cleanup.
> > > > so I'm not sure if fixes line is relevant or not.
> > > > beside that looks ok.
> > > 
> > > It doesn't matter if it is real issue or not, the code is wrong
> > > and
> > > should be fixed. This alone is enough to see the Fixes line.
> > > 
> > > Thanks,
> > > Acked-by: Leon Romanovsky 
> > 
> > Acked-by: Saeed Mahameed 
> > Dave, Do you think such patch should go to net, or do you want me
> > to
> > send it in my next pull request to net-next, once it is open of
> > course
> > ?
> 
> This feels more like net-next stuff to me, thanks for asking.

Applied to net-next-mlx5, will be sent in the next pull request when
net-next reopens, Thanks!



Re: [PATCH 1/3] dt-bindings: Add doc for the ingenic-drm driver

2019-03-08 Thread Rob Herring
On Thu, Feb 28, 2019 at 4:08 PM Paul Cercueil  wrote:
>
> Add documentation for the devicetree bindings of the DRM driver for the
> JZ47xx family of SoCs from Ingenic.
>
> Signed-off-by: Paul Cercueil 
> Tested-by: Artur Rojek 
> ---
>  .../devicetree/bindings/display/ingenic,drm.txt| 30 
> ++
>  1 file changed, 30 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/ingenic,drm.txt
>
> diff --git a/Documentation/devicetree/bindings/display/ingenic,drm.txt 
> b/Documentation/devicetree/bindings/display/ingenic,drm.txt
> new file mode 100644
> index ..52a368ec35cd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/ingenic,drm.txt
> @@ -0,0 +1,30 @@
> +Ingenic JZ47xx DRM driver
> +
> +Required properties:
> +- compatible: one of:
> +  * ingenic,jz4740-drm
> +  * ingenic,jz4725b-drm

DRM is a kernel thing. What's the h/w called?

> +- reg: LCD registers location and length
> +- clocks: LCD pixclock and device clock specifiers.
> +  The device clock is only required on the JZ4740.
> +- clock-names: "lcd_pclk" and "lcd"
> +- interrupts: Specifies the interrupt line the LCD controller is connected 
> to.
> +
> +Optional properties:
> +- ingenic,panel: phandle to a display panel, if one is present

Use the graph binding or a child node. See other bindings.

> +- ingenic,lcd-mode: LCD mode to use with the display panel.
> +   See  for all the
> +   possible values.
> +
> +Example:
> +
> +lcd: lcd-controller@1305 {
> +   compatible = "ingenic,jz4725b-drm";
> +   reg = <0x1305 0x1000>;
> +
> +   interrupt-parent = <>;
> +   interrupts = <31>;
> +
> +   clocks = < JZ4725B_CLK_LCD>;
> +   clock-names = "lcd";
> +};
> --
> 2.11.0
>


Re: [PATCH v4 4/9] staging:iio:ad7780: add chip ID values and mask

2019-03-08 Thread Renato Lui Geh

On 03/04, Ardelean, Alexandru wrote:

On Sun, 2019-03-03 at 14:53 +, Jonathan Cameron wrote:

[External]


On Sun, 3 Mar 2019 11:01:09 -0300
Renato Lui Geh  wrote:

> On 03/01, Ardelean, Alexandru wrote:
> > On Thu, 2019-02-28 at 11:24 -0300, Renato Lui Geh wrote:
> > >
> > >
> > > The ad7780 supports both the ad778x and ad717x families. Each chip
> > > has
> > > a corresponding ID. This patch provides a mask for extracting ID
> > > values
> > > from the status bits and also macros for the correct values for the
> > > ad7170, ad7171, ad7780 and ad7781.
> > >
> > > Signed-off-by: Renato Lui Geh 
> > > ---
> > >  drivers/staging/iio/adc/ad7780.c | 8 ++--
> > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/staging/iio/adc/ad7780.c
> > > b/drivers/staging/iio/adc/ad7780.c
> > > index 56c49e28f432..ad7617a3a141 100644
> > > --- a/drivers/staging/iio/adc/ad7780.c
> > > +++ b/drivers/staging/iio/adc/ad7780.c
> > > @@ -26,10 +26,14 @@
> > >  #define AD7780_RDY BIT(7)
> > >  #define AD7780_FILTER  BIT(6)
> > >  #define AD7780_ERR BIT(5)
> > > -#define AD7780_ID1 BIT(4)
> > > -#define AD7780_ID0 BIT(3)
> > >  #define AD7780_GAINBIT(2)
> > >
> > > +#define AD7170_ID  0
> > > +#define AD7171_ID  1
> > > +#define AD7780_ID  1
> > > +#define AD7781_ID  0
> > > +
> > > +#define AD7780_ID_MASK (BIT(3) | BIT(4))
> >
> > This also doesn't have any functionality change.
> > The AD7170_ID, AD7171_ID, AD7780_ID & AD7781_ID IDs are also unused
> > (maybe
> > in a later patch they are ?).
>
> They aren't. I added them following a previous review suggestion.
> Should
> I remove them?

Can we check them?  It's always useful to confirm that the device is
the one you think it is.  Then we can either use what is there
with a suitable warning, or if that is tricky just fault out as the
dt is giving us the wrong part number.

J


I guess `dev_warn_ratelimited()` could be used to make sure syslog isn't
spammed-to-death when doing multiple conversions, and the ID isn't correct.
Since these IDs are read after you get a sample, I'm a bit fearful of log-
spam.

I wouldn't throw an error in the ad7780_postprocess_sample() for this, but
warning [with rate-limit] sounds reasonable.


Looking at dev_warn_ratelimited's definition (and its use in other parts
of the kernel), I see that we'd need the device to be stored somewhere
(perhaps in ad7780_state?) in order for us to pass it as argument to
dev_warn from within postprocess_sample. Should this be stored in
ad7780_state?  Or can I get the spi_device some other way?




> >
> > I would also leave the AD7780_ID1 & AD7780_ID0 definitions in place,
> > since
> > they're easier matched with the datasheet.
> >
> > >
> > >  #define AD7780_PATTERN_GOOD1
> > >  #define AD7780_PATTERN_MASKGENMASK(1, 0)
> > > --
> > > 2.21.0
> > >




Re: [PATCH v3 3/6] clk: change rates via list iteration

2019-03-08 Thread dbasehore .
On Mon, Mar 4, 2019 at 8:49 PM Derek Basehore  wrote:
>
> This changes the clk_set_rate code to use lists instead of recursion.
> While making this change, also add error handling for clk_set_rate.
> This means that errors in the set_rate/set_parent/set_rate_and_parent
> functions will not longer be ignored. When an error occurs, the clk
> rates and parents are reset, unless an error occurs here, in which we
> bail and cross our fingers.
>
> Signed-off-by: Derek Basehore 
> ---
>  drivers/clk/clk.c | 256 +++---
>  1 file changed, 176 insertions(+), 80 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index e20364812b54..1637dc262884 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -39,6 +39,13 @@ static LIST_HEAD(clk_notifier_list);
>
>  /***private data structures***/
>
> +struct clk_change {
> +   struct list_headchange_list;
> +   unsigned long   rate;
> +   struct clk_core *core;
> +   struct clk_core *parent;
> +};
> +
>  struct clk_core {
> const char  *name;
> const struct clk_ops*ops;
> @@ -49,11 +56,9 @@ struct clk_core {
> const char  **parent_names;
> struct clk_core **parents;
> u8  num_parents;
> -   u8  new_parent_index;
> unsigned long   rate;
> unsigned long   req_rate;
> -   unsigned long   new_rate;
> -   struct clk_core *new_parent;
> +   struct clk_change   change;
> struct clk_core *new_child;
> unsigned long   flags;
> boolorphan;
> @@ -1735,19 +1740,52 @@ static int __clk_speculate_rates(struct clk_core 
> *core,
>  static void clk_calc_subtree(struct clk_core *core)
>  {
> struct clk_core *child;
> +   LIST_HEAD(tmp_list);
>
> -   hlist_for_each_entry(child, >children, child_node) {
> -   child->new_rate = clk_recalc(child, core->new_rate);
> -   clk_calc_subtree(child);
> +   list_add(>prepare_list, _list);
> +   while (!list_empty(_list)) {
> +   core = list_first_entry(_list, struct clk_core,
> +   prepare_list);
> +
> +   hlist_for_each_entry(child, >children, child_node) {
> +   child->change.rate = clk_recalc(child,
> +   core->change.rate);
> +   list_add_tail(>prepare_list, _list);
> +   }
> +
> +   list_del(>prepare_list);
> +   }
> +}
> +
> +static void clk_prepare_changes(struct list_head *change_list,
> +   struct clk_core *core)
> +{
> +   struct clk_change *change;
> +   struct clk_core *tmp, *child;
> +   LIST_HEAD(tmp_list);
> +
> +   list_add(>change.change_list, _list);
> +   while (!list_empty(_list)) {
> +   change = list_first_entry(_list, struct clk_change,
> + change_list);
> +   tmp = change->core;
> +
> +   hlist_for_each_entry(child, >children, child_node)
> +   list_add_tail(>change.change_list, _list);
> +
> +   child = tmp->new_child;
> +   if (child)
> +   list_add_tail(>change.change_list, _list);
> +
> +   list_move_tail(>change.change_list, change_list);
> }
>  }
>
>  static void clk_set_change(struct clk_core *core, unsigned long new_rate,
> -  struct clk_core *new_parent, u8 p_index)
> +  struct clk_core *new_parent)
>  {
> -   core->new_rate = new_rate;
> -   core->new_parent = new_parent;
> -   core->new_parent_index = p_index;
> +   core->change.rate = new_rate;
> +   core->change.parent = new_parent;
> /* include clk in new parent's PRE_RATE_CHANGE notifications */
> core->new_child = NULL;
> if (new_parent && new_parent != core->parent)
> @@ -1767,7 +1805,6 @@ static struct clk_core *clk_calc_new_rates(struct 
> clk_core *core,
> unsigned long new_rate;
> unsigned long min_rate;
> unsigned long max_rate;
> -   int p_index = 0;
> long ret;
>
> /* sanity */
> @@ -1803,17 +1840,15 @@ static struct clk_core *clk_calc_new_rates(struct 
> clk_core *core,
> return NULL;
> } else if (!parent || !(core->flags & CLK_SET_RATE_PARENT)) {
> /* pass-through clock without adjustable parent */
> -   core->new_rate = core->rate;
> return NULL;
> } else {
> /* pass-through clock with adjustable parent */
> top = clk_calc_new_rates(parent, rate);
> -   new_rate = parent->new_rate;
> +   new_rate 

[PATCH v3 4/4] perf script python: add printdate function to SQL exporters

2019-03-08 Thread Tony Jones
Introduce a printdate function to eliminate the repetitive use of
datetime.datetime.today() in the SQL exporting scripts.

Signed-off-by: Tony Jones 
Acked-by: Adrian Hunter 
---
 tools/perf/scripts/python/export-to-postgresql.py | 19 +++
 tools/perf/scripts/python/export-to-sqlite.py | 13 -
 2 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/tools/perf/scripts/python/export-to-postgresql.py 
b/tools/perf/scripts/python/export-to-postgresql.py
index 00ab972a2eba..c3eae1d77d36 100644
--- a/tools/perf/scripts/python/export-to-postgresql.py
+++ b/tools/perf/scripts/python/export-to-postgresql.py
@@ -251,6 +251,9 @@ perf_db_export_callchains = False
 def printerr(*args, **kw_args):
print(*args, file=sys.stderr, **kw_args)
 
+def printdate(*args, **kw_args):
+print(datetime.datetime.today(), *args, sep=' ', **kw_args)
+
 def usage():
printerr("Usage is: export-to-postgresql.py  [] 
[] []")
printerr("where:columns 'all' or 'branches'")
@@ -289,7 +292,7 @@ def do_query(q, s):
return
raise Exception("Query failed: " + q.lastError().text())
 
-print(datetime.datetime.today(), "Creating database...")
+printdate("Creating database...")
 
 db = QSqlDatabase.addDatabase('QPSQL')
 query = QSqlQuery(db)
@@ -582,7 +585,7 @@ if perf_db_export_calls:
call_file   = open_output_file("call_table.bin")
 
 def trace_begin():
-   print(datetime.datetime.today(), "Writing to intermediate files...")
+   printdate("Writing to intermediate files...")
# id == 0 means unknown.  It is easier to create records for them than 
replace the zeroes with NULLs
evsel_table(0, "unknown")
machine_table(0, 0, "unknown")
@@ -598,7 +601,7 @@ def trace_begin():
 unhandled_count = 0
 
 def trace_end():
-   print(datetime.datetime.today(), "Copying to database...")
+   printdate("Copying to database...")
copy_output_file(evsel_file,"selected_events")
copy_output_file(machine_file,  "machines")
copy_output_file(thread_file,   "threads")
@@ -613,7 +616,7 @@ def trace_end():
if perf_db_export_calls:
copy_output_file(call_file, "calls")
 
-   print(datetime.datetime.today(), "Removing intermediate files...")
+   printdate("Removing intermediate files...")
remove_output_file(evsel_file)
remove_output_file(machine_file)
remove_output_file(thread_file)
@@ -628,7 +631,7 @@ def trace_end():
if perf_db_export_calls:
remove_output_file(call_file)
os.rmdir(output_dir_name)
-   print(datetime.datetime.today(), "Adding primary keys")
+   printdate("Adding primary keys")
do_query(query, 'ALTER TABLE selected_events ADD PRIMARY KEY (id)')
do_query(query, 'ALTER TABLE machinesADD PRIMARY KEY (id)')
do_query(query, 'ALTER TABLE threads ADD PRIMARY KEY (id)')
@@ -643,7 +646,7 @@ def trace_end():
if perf_db_export_calls:
do_query(query, 'ALTER TABLE calls   ADD PRIMARY KEY 
(id)')
 
-   print(datetime.datetime.today(), "Adding foreign keys")
+   printdate("Adding foreign keys")
do_query(query, 'ALTER TABLE threads '
'ADD CONSTRAINT machinefk  FOREIGN KEY 
(machine_id)   REFERENCES machines   (id),'
'ADD CONSTRAINT processfk  FOREIGN KEY 
(process_id)   REFERENCES threads(id)')
@@ -679,8 +682,8 @@ def trace_end():
do_query(query, 'CREATE INDEX pid_idx ON calls (parent_id)')
 
if (unhandled_count):
-   print(datetime.datetime.today(), "Warning: ", unhandled_count, 
" unhandled events")
-   print(datetime.datetime.today(), "Done")
+   printdate("Warning: ", unhandled_count, " unhandled events")
+   printdate("Done")
 
 def trace_unhandled(event_name, context, event_fields_dict):
global unhandled_count
diff --git a/tools/perf/scripts/python/export-to-sqlite.py 
b/tools/perf/scripts/python/export-to-sqlite.py
index 3da338243aed..3b71902a5a21 100644
--- a/tools/perf/scripts/python/export-to-sqlite.py
+++ b/tools/perf/scripts/python/export-to-sqlite.py
@@ -65,6 +65,9 @@ perf_db_export_callchains = False
 def printerr(*args, **keyword_args):
print(*args, file=sys.stderr, **keyword_args)
 
+def printdate(*args, **kw_args):
+print(datetime.datetime.today(), *args, sep=' ', **kw_args)
+
 def usage():
printerr("Usage is: export-to-sqlite.py  [] 
[] []");
printerr("where:columns 'all' or 'branches'");
@@ -105,7 +108,7 @@ def do_query_(q):
return
raise Exception("Query failed: " + q.lastError().text())
 
-print(datetime.datetime.today(), "Creating database ...")
+printdate("Creating database ...")
 
 db_exists = False
 try:
@@ -383,7 +386,7 @@ if 

[PATCH v3 2/4] perf script python: add Python3 support to export-to-postgresql.py

2019-03-08 Thread Tony Jones
Support both Python2 and Python3 in the export-to-postgresql.py script.

The use of 'from __future__' implies the minimum supported Python2 version
is now v2.6

Signed-off-by: Tony Jones 
Signed-off-by: Adrian Hunter 
Signed-off-by: Seeteena Thoufeek 
---
 tools/perf/scripts/python/export-to-postgresql.py | 58 ---
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/tools/perf/scripts/python/export-to-postgresql.py 
b/tools/perf/scripts/python/export-to-postgresql.py
index 390a351d15ea..00ab972a2eba 100644
--- a/tools/perf/scripts/python/export-to-postgresql.py
+++ b/tools/perf/scripts/python/export-to-postgresql.py
@@ -10,6 +10,8 @@
 # FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 # more details.
 
+from __future__ import print_function
+
 import os
 import sys
 import struct
@@ -199,6 +201,18 @@ import datetime
 
 from PySide.QtSql import *
 
+if sys.version_info < (3, 0):
+   def toserverstr(str):
+   return str
+   def toclientstr(str):
+   return str
+else:
+   # Assume UTF-8 server_encoding and client_encoding
+   def toserverstr(str):
+   return bytes(str, "UTF_8")
+   def toclientstr(str):
+   return bytes(str, "UTF_8")
+
 # Need to access PostgreSQL C library directly to use COPY FROM STDIN
 from ctypes import *
 libpq = CDLL("libpq.so.5")
@@ -234,12 +248,14 @@ perf_db_export_mode = True
 perf_db_export_calls = False
 perf_db_export_callchains = False
 
+def printerr(*args, **kw_args):
+   print(*args, file=sys.stderr, **kw_args)
 
 def usage():
-   print >> sys.stderr, "Usage is: export-to-postgresql.py  
[] [] []"
-   print >> sys.stderr, "where:columns 'all' or 'branches'"
-   print >> sys.stderr, "  calls   'calls' => create calls 
and call_paths table"
-   print >> sys.stderr, "  callchains  'callchains' => create 
call_paths table"
+   printerr("Usage is: export-to-postgresql.py  [] 
[] []")
+   printerr("where:columns 'all' or 'branches'")
+   printerr("  calls   'calls' => create calls and 
call_paths table")
+   printerr("  callchains  'callchains' => create 
call_paths table")
raise Exception("Too few arguments")
 
 if (len(sys.argv) < 2):
@@ -273,7 +289,7 @@ def do_query(q, s):
return
raise Exception("Query failed: " + q.lastError().text())
 
-print datetime.datetime.today(), "Creating database..."
+print(datetime.datetime.today(), "Creating database...")
 
 db = QSqlDatabase.addDatabase('QPSQL')
 query = QSqlQuery(db)
@@ -506,12 +522,12 @@ do_query(query, 'CREATE VIEW samples_view AS '
' FROM samples')
 
 
-file_header = struct.pack("!11sii", "PGCOPY\n\377\r\n\0", 0, 0)
-file_trailer = "\377\377"
+file_header = struct.pack("!11sii", b"PGCOPY\n\377\r\n\0", 0, 0)
+file_trailer = b"\377\377"
 
 def open_output_file(file_name):
path_name = output_dir_name + "/" + file_name
-   file = open(path_name, "w+")
+   file = open(path_name, "wb+")
file.write(file_header)
return file
 
@@ -526,13 +542,13 @@ def copy_output_file_direct(file, table_name):
 
 # Use COPY FROM STDIN because security may prevent postgres from accessing the 
files directly
 def copy_output_file(file, table_name):
-   conn = PQconnectdb("dbname = " + dbname)
+   conn = PQconnectdb(toclientstr("dbname = " + dbname))
if (PQstatus(conn)):
raise Exception("COPY FROM STDIN PQconnectdb failed")
file.write(file_trailer)
file.seek(0)
sql = "COPY " + table_name + " FROM STDIN (FORMAT 'binary')"
-   res = PQexec(conn, sql)
+   res = PQexec(conn, toclientstr(sql))
if (PQresultStatus(res) != 4):
raise Exception("COPY FROM STDIN PQexec failed")
data = file.read(65536)
@@ -566,7 +582,7 @@ if perf_db_export_calls:
call_file   = open_output_file("call_table.bin")
 
 def trace_begin():
-   print datetime.datetime.today(), "Writing to intermediate files..."
+   print(datetime.datetime.today(), "Writing to intermediate files...")
# id == 0 means unknown.  It is easier to create records for them than 
replace the zeroes with NULLs
evsel_table(0, "unknown")
machine_table(0, 0, "unknown")
@@ -582,7 +598,7 @@ def trace_begin():
 unhandled_count = 0
 
 def trace_end():
-   print datetime.datetime.today(), "Copying to database..."
+   print(datetime.datetime.today(), "Copying to database...")
copy_output_file(evsel_file,"selected_events")
copy_output_file(machine_file,  "machines")
copy_output_file(thread_file,   "threads")
@@ -597,7 +613,7 @@ def trace_end():
if perf_db_export_calls:
copy_output_file(call_file, "calls")
 
-   print datetime.datetime.today(), "Removing intermediate 

  1   2   3   4   5   6   7   8   9   10   >