QEMU ATA hard disk not detected

[Paul Menzel]

Dear Linux folks,


In QEMU 2.11 a disk is only detected by the AHCI driver and not by 
libata. On QEMU’s Standard PC (i440FX + PIIX, 1996), that causes an 
attached drive not to be detected as that machine doesn’t support AHCI.


Here is the output with the machine Standard PC (Q35 + ICH9, 2009), 
which does have AHCI support.



$ qemu-system-x86_64 -enable-kvm -M q35 -m 1G -serial stdio -hda /dev/shm/qemu-debian.img 
-kernel bzImage -append "console=ttyS0,115200 console=tty0" -initrd 
initrd.cpio.xz
WARNING: Image format was not specified for '/dev/shm/qemu-debian.img' and 
probing guessed raw.
 Automatically detecting the format is dangerous for raw images, write 
operations on block 0 will be restricted.
 Specify the 'raw' format explicitly to remove the restrictions.
qemu-system-x86_64: warning: host doesn't support requested feature: 
CPUID.8001H:ECX.svm [bit 2]
[0.00] Linux version 4.17.0-rc4-heads+ 
(pmen...@bohemianrhapsody.molgen.mpg.de) (gcc version 7.3.0 (GCC)) #1 SMP Sun 
May 13 10:11:43 CEST 2018
[0.00] Command line: console=ttyS0,115200 console=tty0
[…]
[0.250239] SCSI subsystem initialized
[0.252012] libata version 3.00 loaded.
[…]
[0.633761] ahci :00:1f.2: version 3.0
[0.635808] PCI Interrupt Link [LNKA] enabled at IRQ 10
[0.637935] PCI: setting IRQ 10 as level-triggered
[0.641276] ahci :00:1f.2: AHCI 0001. 32 slots 6 ports 1.5 Gbps 0x3f 
impl SATA mode
[0.644598] ahci :00:1f.2: flags: 64bit ncq only 
[0.647877] scsi host0: ahci

[0.649254] scsi host1: ahci
[0.650591] scsi host2: ahci
[0.652075] scsi host3: ahci
[0.653497] scsi host4: ahci
[0.654775] scsi host5: ahci
[0.656414] ata1: SATA max UDMA/133 abar m4096@0xfebb1000 port 0xfebb1100 
irq 24
[0.659847] ata2: SATA max UDMA/133 abar m4096@0xfebb1000 port 0xfebb1180 
irq 24
[0.664691] ata3: SATA max UDMA/133 abar m4096@0xfebb1000 port 0xfebb1200 
irq 24
[0.667730] ata4: SATA max UDMA/133 abar m4096@0xfebb1000 port 0xfebb1280 
irq 24
[0.670826] ata5: SATA max UDMA/133 abar m4096@0xfebb1000 port 0xfebb1300 
irq 24
[0.674341] ata6: SATA max UDMA/133 abar m4096@0xfebb1000 port 0xfebb1380 
irq 24
[0.678009] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[0.680694] e1000: Copyright (c) 1999-2006 Intel Corporation.
[0.683495] PCI Interrupt Link [LNKG] enabled at IRQ 11
[0.685429] PCI: setting IRQ 11 as level-triggered
[0.996760] ata6: SATA link down (SStatus 0 SControl 300)
[0.998724] ata5: SATA link down (SStatus 0 SControl 300)
[1.001077] ata4: SATA link down (SStatus 0 SControl 300)
[1.003553] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[1.006047] ata3.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100
[1.008241] ata3.00: applying bridge limits
[1.010322] ata2: SATA link down (SStatus 0 SControl 300)
[1.012609] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[1.014864] ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100
[1.016994] ata1.00: 6291456 sectors, multi 16: LBA48 NCQ (depth 31/32)
[1.019254] ata1.00: applying bridge limits
[1.028470] ata3.00: configured for UDMA/100
[1.030279] ata1.00: configured for UDMA/100
[1.032075] scsi 0:0:0:0: Direct-Access ATA  QEMU HARDDISK2.5+ 
PQ: 0 ANSI: 5
[1.040151] sd 0:0:0:0: Attached scsi generic sg0 type 0
[1.041985] sd 0:0:0:0: [sda] 6291456 512-byte logical blocks: (3.22 GB/3.00 
GiB)
[1.045002] sd 0:0:0:0: [sda] Write Protect is off
[1.046843] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[1.049064] scsi 2:0:0:0: CD-ROMQEMU QEMU DVD-ROM 2.5+ 
PQ: 0 ANSI: 5
[1.059073] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[1.067126]  sda: sda1
[1.068217] sd 0:0:0:0: [sda] Attached SCSI disk
[1.074848] sr 2:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
[1.076830] cdrom: Uniform CD-ROM driver Revision: 3.20
[1.078760] sr 2:0:0:0: Attached scsi CD-ROM sr0
[1.085017] sr 2:0:0:0: Attached scsi generic sg1 type 5


The Debian disk image was built with grml-debootstrap.

sudo grml-debootstrap --vmfile --vmsize 3G --target 
/dev/shm/qemu-debian.img -r sid


Is that a Linux or QEMU issue?


Kind regards,

Paul
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.17.0-rc4 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y

Re: [PATCH] swiotlb: Silent unwanted warning "buffer is full"

[Jean Delvare]

On Sat, 12 May 2018 12:02:40 +0200, Christoph Hellwig wrote:
> Thanks.
> 
> I manually applied this for 4.17-rc, as the mail unfortunately was
> garbled.

Sorry about that. Because of the umlauts in the Cc list, the mail was
encoded as quoted-printable instead of 7bit. I guess this is what
caused the problem on your end.

You would think our tools are able to deal with accentuated characters
properly in 2018 but apparently not :-(

-- 
Jean Delvare
SUSE L3 Support

Re: KASAN: use-after-free Write in irq_bypass_register_consumer

[Eric Biggers]

On Thu, Apr 05, 2018 at 08:15:24PM -0700, Eric Biggers wrote:
> On Mon, Jan 29, 2018 at 01:29:48PM +0800, Tianyu Lan wrote:
> > 
> > 
> > On 1/27/2018 7:27 AM, Eric Biggers wrote:
> > > On Sat, Dec 16, 2017 at 04:37:02PM +0800, Lan, Tianyu wrote:
> > > > The root cause is that kvm_irqfd_assign() and kvm_irqfd_deassign() can't
> > > > be run in parallel. Some data structure(e.g, irqfd->consumer) will be
> > > > crashed because irqfd may be freed in deassign path before they are used
> > > > in assign path. The other data maybe used in deassign path before
> > > > initialization. Syzbot test hit such case. Add mutx between
> > > > kvm_irqfd_assign() and kvm_irqfd_deassign() can fix such issue. Will
> > > > send patch to fix it.
> > > > 
> > > > On 12/16/2017 12:53 PM, Tianyu Lan wrote:
> > > > > I reproduced the issue. Will have a look.
> > > > > 
> > > > > -- Best regards Tianyu Lan 2017-12-15 18:14 GMT+08:00 syzbot
> > > > > :
> > > > > > syzkaller has found reproducer for the following crash on
> > > > > > 82bcf1def3b5f1251177ad47c44f7e17af039b4b
> > > > > > git://git.cmpxchg.org/linux-mmots.git/master
> > > > > > compiler: gcc (GCC) 7.1.1 20170620
> > > > > > .config is attached
> > > > > > Raw console output is attached.
> > > > > > C reproducer is attached
> > > > > > syzkaller reproducer is attached. Seehttps://goo.gl/kgGztJ
> > > > > > for information about syzkaller reproducers
> > > > > > 
> > > > > > 
> > > > > > ==
> > > > > > BUG: KASAN: use-after-free in __list_add include/linux/list.h:64 
> > > > > > [inline]
> > > > > > BUG: KASAN: use-after-free in list_add include/linux/list.h:79 
> > > > > > [inline]
> > > > > > BUG: KASAN: use-after-free in 
> > > > > > irq_bypass_register_consumer+0x4b4/0x500
> > > > > > virt/lib/irqbypass.c:217
> > > > > > Write of size 8 at addr 8801cdf51180 by task 
> > > > > > syzkaller436086/15031
> > > > > > 
> > > > > > CPU: 1 PID: 15031 Comm: syzkaller436086 Not tainted 4.15.0-rc2-mm1+ 
> > > > > > #39
> > > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, 
> > > > > > BIOS
> > > > > > Google 01/01/2011
> > > > > > Call Trace:
> > > > > >__dump_stack lib/dump_stack.c:17 [inline]
> > > > > >dump_stack+0x194/0x257 lib/dump_stack.c:53
> > > > > >print_address_description+0x73/0x250 mm/kasan/report.c:252
> > > > > >kasan_report_error mm/kasan/report.c:351 [inline]
> > > > > >kasan_report+0x25b/0x340 mm/kasan/report.c:409
> > > > > >__asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:435
> > > > > >__list_add include/linux/list.h:64 [inline]
> > > > > >list_add include/linux/list.h:79 [inline]
> > > > > >irq_bypass_register_consumer+0x4b4/0x500 virt/lib/irqbypass.c:217
> > > > > >kvm_irqfd_assign arch/x86/kvm/../../../virt/kvm/eventfd.c:417 
> > > > > > [inline]
> > > > > >kvm_irqfd+0x137f/0x1d50 
> > > > > > arch/x86/kvm/../../../virt/kvm/eventfd.c:572
> > > > > >kvm_vm_ioctl+0x1079/0x1c40 
> > > > > > arch/x86/kvm/../../../virt/kvm/kvm_main.c:2992
> > > > > >vfs_ioctl fs/ioctl.c:46 [inline]
> > > > > >do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
> > > > > >SYSC_ioctl fs/ioctl.c:701 [inline]
> > > > > >SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> > > > > >entry_SYSCALL_64_fastpath+0x1f/0x96
> > > > > > RIP: 0033:0x44d379
> > > > > > RSP: 002b:7fc5ff9a9d08 EFLAGS: 0246 ORIG_RAX: 
> > > > > > 0010
> > > > > > RAX: ffda RBX: 7fc5ff9aa700 RCX: 0044d379
> > > > > > RDX: 20080fe0 RSI: 4020ae76 RDI: 0005
> > > > > > RBP: 007ff900 R08: 7fc5ff9aa700 R09: 7fc5ff9aa700
> > > > > > R10: 7fc5ff9aa700 R11: 0246 R12: 
> > > > > > R13: 007ff8ff R14: 7fc5ff9aa9c0 R15: 
> > > > > > 
> > > > > > Allocated by task 15031:
> > > > > >save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> > > > > >set_track mm/kasan/kasan.c:459 [inline]
> > > > > >kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
> > > > > >kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3614
> > > > > >kmalloc include/linux/slab.h:516 [inline]
> > > > > >kzalloc include/linux/slab.h:705 [inline]
> > > > > >kvm_irqfd_assign arch/x86/kvm/../../../virt/kvm/eventfd.c:296 
> > > > > > [inline]
> > > > > >kvm_irqfd+0x16c/0x1d50 
> > > > > > arch/x86/kvm/../../../virt/kvm/eventfd.c:572
> > > > > >kvm_vm_ioctl+0x1079/0x1c40 
> > > > > > arch/x86/kvm/../../../virt/kvm/kvm_main.c:2992
> > > > > >vfs_ioctl fs/ioctl.c:46 [inline]
> > > > > >do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
> > > > > >SYSC_ioctl fs/ioctl.c:701 [inline]
> > > > > >SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> > > > > >entry_SYSCALL_64_fastpath+0x1f/0x96
> > > > > > 
> > > > > > Freed by task 1402:
> > > > > >save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> > > > > >   

Re: BUG: unable to handle kernel paging request in cgroup_mt_destroy_v1

[Eric Biggers]

On Wed, Jan 31, 2018 at 05:58:01PM -0800, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> 3da90b159b146672f830bcd2489dd3a1f4e9e089 (Wed Jan 31 03:07:32 2018 +)
> Merge tag 'f2fs-for-4.16-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs
> 
> So far this crash happened 3 times on net-next, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+eeed2602160e4cc17...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1517426494.787:7): avc:  denied  { map } for
> pid=4176 comm="syzkaller493328" path="/root/syzkaller493328633" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> BUG: unable to handle kernel paging request at ff6d
> IP: css_put include/linux/cgroup.h:386 [inline]
> IP: cgroup_put include/linux/cgroup.h:415 [inline]
> IP: cgroup_mt_destroy_v1+0xe5/0x310 net/netfilter/xt_cgroup.c:102
> PGD 6a25067 P4D 6a25067 PUD 6a27067 PMD 0
> Oops:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 4176 Comm: syzkaller493328 Not tainted 4.15.0+ #288
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:css_put include/linux/cgroup.h:386 [inline]
> RIP: 0010:cgroup_put include/linux/cgroup.h:415 [inline]
> RIP: 0010:cgroup_mt_destroy_v1+0xe5/0x310 net/netfilter/xt_cgroup.c:102
> RSP: 0018:8801b19e7958 EFLAGS: 00010246
> RAX: 0008 RBX: 11003633cf2b RCX: 847188c6
> RDX:  RSI: 8709b900 RDI: ff6d
> RBP: 8801b19e79e0 R08: 11003633cef9 R09: 
> R10:  R11:  R12: ff01
> R13: 8801b19e79b8 R14: dc00 R15: 84718810
> FS:  00c16880() GS:8801db40() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: ff6d CR3: 0001b1f38004 CR4: 001606f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  cleanup_match+0x14e/0x220 net/ipv6/netfilter/ip6_tables.c:481
>  cleanup_entry+0xcb/0x350 net/ipv4/netfilter/ip_tables.c:646
>  __do_replace+0x7d7/0xa90 net/ipv4/netfilter/ip_tables.c:1091
>  do_replace net/ipv4/netfilter/ip_tables.c:1147 [inline]
>  do_ipt_set_ctl+0x40f/0x5f0 net/ipv4/netfilter/ip_tables.c:1677
>  nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
>  nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115
>  ip_setsockopt+0xa1/0xb0 net/ipv4/ip_sockglue.c:1256
>  tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2875
>  sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2968
>  SYSC_setsockopt net/socket.c:1831 [inline]
>  SyS_setsockopt+0x189/0x360 net/socket.c:1810
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x4408a9
> RSP: 002b:7ffddd061cc8 EFLAGS: 0207 ORIG_RAX: 0036
> RAX: ffda RBX:  RCX: 004408a9
> RDX: 0040 RSI:  RDI: 0004
> RBP: faaff2414ccfc19e R08: 12f0 R09: 
> R10: 2000b000 R11: 0207 R12: 886f734548d4d66b
> R13: ff01 R14:  R15: 
> Code: 6c 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48
> 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 a6 01 00 00 <41> f6 44 24 6c
> 01 74 2e e8 be 06 ff fc 48 b8 00 00 00 00 00 fc
> RIP: css_put include/linux/cgroup.h:386 [inline] RSP: 8801b19e7958
> RIP: cgroup_put include/linux/cgroup.h:415 [inline] RSP: 8801b19e7958
> RIP: cgroup_mt_destroy_v1+0xe5/0x310 net/netfilter/xt_cgroup.c:102 RSP:
> 8801b19e7958
> CR2: ff6d
> ---[ end trace bfd8c145aa41ae03 ]---
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title

This was fixed by commit ba7cd5d95f25cc6:

#syz fix: netfilter: xt_cgroup: initialize info->priv in cgroup_mt_check_v1()

- Eric

another branch for linux-next

[Christoph Hellwig]

Hi Stephen,

can you please add the for-linus branch of

   git://git.infradead.org/users/hch/dma-mapping.git

to linux-next?  You already carry the for-next branch, but it turns
out I'll need another branch for late fixes so that for-next can
remain unmerged and unrebased.

[PATCH v2] {net, IB}/mlx5: Use 'kvfree()' for memory allocated by 'kvzalloc()'

[Christophe JAILLET]

When 'kvzalloc()' is used to allocate memory, 'kvfree()' must be used to
free it.

Signed-off-by: Christophe JAILLET 
---
v1 -> v2: More places to update have been added to the patch
---
 drivers/infiniband/hw/mlx5/cq.c| 2 +-
 drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 +-
 drivers/net/ethernet/mellanox/mlx5/core/vport.c| 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
index 77d257ec899b..6d52ea03574e 100644
--- a/drivers/infiniband/hw/mlx5/cq.c
+++ b/drivers/infiniband/hw/mlx5/cq.c
@@ -849,7 +849,7 @@ static int create_cq_user(struct mlx5_ib_dev *dev, struct 
ib_udata *udata,
return 0;
 
 err_cqb:
-   kfree(*cqb);
+   kvfree(*cqb);
 
 err_db:
mlx5_ib_db_unmap_user(to_mucontext(context), >db);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c 
b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 35e256eb2f6e..b123f8a52ad8 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -663,7 +663,7 @@ static int esw_create_vport_rx_group(struct mlx5_eswitch 
*esw)
 
esw->offloads.vport_rx_group = g;
 out:
-   kfree(flow_group_in);
+   kvfree(flow_group_in);
return err;
 }
 
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vport.c 
b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
index 177e076b8d17..719cecb182c6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/vport.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
@@ -511,7 +511,7 @@ int mlx5_query_nic_vport_system_image_guid(struct 
mlx5_core_dev *mdev,
*system_image_guid = MLX5_GET64(query_nic_vport_context_out, out,
nic_vport_context.system_image_guid);
 
-   kfree(out);
+   kvfree(out);
 
return 0;
 }
@@ -531,7 +531,7 @@ int mlx5_query_nic_vport_node_guid(struct mlx5_core_dev 
*mdev, u64 *node_guid)
*node_guid = MLX5_GET64(query_nic_vport_context_out, out,
nic_vport_context.node_guid);
 
-   kfree(out);
+   kvfree(out);
 
return 0;
 }
@@ -587,7 +587,7 @@ int mlx5_query_nic_vport_qkey_viol_cntr(struct 
mlx5_core_dev *mdev,
*qkey_viol_cntr = MLX5_GET(query_nic_vport_context_out, out,
   nic_vport_context.qkey_violation_counter);
 
-   kfree(out);
+   kvfree(out);
 
return 0;
 }
-- 
2.17.0

Re: [PATCH v3 0/3] mailbox: ACPI: Remove incorrect error message about parsing PCCT

[Rafael J. Wysocki]

On Tuesday, May 1, 2018 2:39:04 AM CEST Al Stone wrote:
> This set of patches provide some cleanup in ACPI for minor issues
> found while correcting a bogus error message (the first two patches),
> and the correction for the error message itself (patch 3/3).  Note
> that patches 1/3 and 2/3 are not required for 3/3 to work: 1/3 only
> changes a comment and 2/3 makes an ACPI table parsing loop a wee bit
> more robust.
> 
> For patch 3/3, many systems on boot have been reporting "Error parsing
> PCC subspaces from PCCT" which turns out to not be an error at all.
> The issue is that the probe for ACPI mailboxes defined in the PCCT
> (Platform Communications Channel Table) makes a faulty assumption about
> the content of the PCCT.  What's more, when the error is reported, no
> further PCC mailboxes are set up, even when they have been defined
> in the PCCT.  So, in the reported cases, there was no error and the
> data in the PCCT was being ignored.  This is described in more detail
> in patch 3/3.
> 
> Since these patches primarily involve ACPI usages, it may make
> sense for all of them to go through the linux-acpi tree; clearly,
> this is up to the maintainers, though.
> 
> v3:
>   -- properly format docbook info in patch 1/3
>   -- remove extra parens in patch 2/3
>   -- clean up formatting, remove pr_warn() calls used in debugging but
>  providing no value, clean up docbook info for count_pcc_subspaces()
>  and parse_pcc_subspaces(), all in patch 3/3
> 
> v2:
>   -- removed one extraneous '+' in a comment in patch 3/3
>   -- fixed an if test that had a predicate that kbuild pointed out would
>  always be zero
> 
> Al Stone (3):
>   ACPI: improve function documentation for acpi_parse_entries_array()
>   ACPI: ensure acpi_parse_entries_array() does not access non-existent
> table data
>   mailbox: ACPI: erroneous error message when parsing the ACPI PCCT
> 
>  drivers/acpi/tables.c | 12 ---
>  drivers/mailbox/pcc.c | 96 
> +--
>  2 files changed, 71 insertions(+), 37 deletions(-)

I've applied [1-2/3] and I'm waiting on input from Prashanth on the [3/3].

Thanks,
Rafael

KASAN: use-after-free Read in corrupted

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:427fbe89261d Merge branch 'next' of git://git.kernel.org/p..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=148eb01780
kernel config:  https://syzkaller.appspot.com/x/.config?x=fcce42b221691ff9
dashboard link: https://syzkaller.appspot.com/bug?extid=3417712847e7219a60ee
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1770c47780
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ecdbc780

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3417712847e7219a6...@syzkaller.appspotmail.com

R13:  R14:  R15: 
CPU: 0 PID: 4564 Comm: syz-executor214 Not tainted 4.17.0-rc4+ #44
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

==
Call Trace:
BUG: KASAN: use-after-free in __lock_acquire+0x3888/0x5140  
kernel/locking/lockdep.c:3310

Read of size 8 at addr 8801d8d69088 by task syz-executor214/4551
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113

 fail_dump lib/fault-inject.c:51 [inline]
 should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
 __should_failslab+0x124/0x180 mm/failslab.c:32
 should_failslab+0x9/0x14 mm/slab_common.c:1522
 slab_pre_alloc_hook mm/slab.h:423 [inline]
 slab_alloc mm/slab.c:3378 [inline]
 kmem_cache_alloc+0x2af/0x760 mm/slab.c:3552
 __d_alloc+0xc0/0xd30 fs/dcache.c:1638
 d_alloc_anon fs/dcache.c:1742 [inline]
 d_make_root+0x42/0x90 fs/dcache.c:1934
 fuse_fill_super+0x120e/0x1e20 fs/fuse/inode.c:1131
 mount_nodev+0x6b/0x110 fs/super.c:1210
 fuse_mount+0x2c/0x40 fs/fuse/inode.c:1192
 mount_fs+0xae/0x328 fs/super.c:1267
 vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037
 vfs_kern_mount fs/namespace.c:1027 [inline]
 do_new_mount fs/namespace.c:2518 [inline]
 do_mount+0x564/0x3070 fs/namespace.c:2848
 ksys_mount+0x12d/0x140 fs/namespace.c:3064
 __do_sys_mount fs/namespace.c:3078 [inline]
 __se_sys_mount fs/namespace.c:3075 [inline]
 __x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x447cb9
RSP: 002b:7f7a75bca918 EFLAGS: 0246 ORIG_RAX: 00a5
RAX: ffda RBX: 0005 RCX: 00447cb9
RDX: 004b08d6 RSI: 2340 RDI: 004c7485
RBP: a001 R08: 7f7a75bca930 R09: 
R10:  R11: 0246 R12: 
R13:  R14:  R15: 
CPU: 1 PID: 4551 Comm: syz-executor214 Not tainted 4.17.0-rc4+ #44
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
 print_address_description+0x6c/0x20b mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
 __lock_acquire+0x3888/0x5140 kernel/locking/lockdep.c:3310
 lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3920
 down_write+0x87/0x120 kernel/locking/rwsem.c:70
 fuse_kill_sb_anon+0x50/0xb0 fs/fuse/inode.c:1200
 deactivate_locked_super+0x97/0x100 fs/super.c:316
 mount_nodev+0xfa/0x110 fs/super.c:1212
 fuse_mount+0x2c/0x40 fs/fuse/inode.c:1192
 mount_fs+0xae/0x328 fs/super.c:1267
 vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037
 vfs_kern_mount fs/namespace.c:1027 [inline]
 do_new_mount fs/namespace.c:2518 [inline]
 do_mount+0x564/0x3070 fs/namespace.c:2848
 ksys_mount+0x12d/0x140 fs/namespace.c:3064
 __do_sys_mount fs/namespace.c:3078 [inline]
 __se_sys_mount fs/namespace.c:3075 [inline]
 __x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x447cb9
RSP: 002b:7f7a75bca918 EFLAGS: 0246 ORIG_RAX: 00a5
RAX: ffda RBX: 0005 RCX: 00447cb9
RDX: 004b08d6 RSI: 2340 RDI: 004c7485
RBP: a001 R08: 7f7a75bca930 R09: 
R10:  R11: 0246 R12: 
R13:  R14:  R15: 

CPU: 0 PID: 4580 Comm: syz-executor214 Not tainted 4.17.0-rc4+ #44
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Allocated by task 4551:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
Call Trace:
 set_track mm/kasan/kasan.c:460 [inline]
 kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
 kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620

Re: [PATCH v3] mm: Change return type to vm_fault_t

[Joe Perches]

On Sat, 2018-05-12 at 19:51 -0700, Dan Williams wrote:
> On Sat, May 12, 2018 at 12:14 PM, Souptick Joarder  
> wrote:
> > > > It'd be nicer to realign the 2nd and 3rd arguments
> > > > on the subsequent lines.
> > > > 
> > > >   vm_fault_t (*fault)(const struct vm_special_mapping *sm,
> > > >   struct vm_area_struct *vma,
> > > >   struct vm_fault *vmf);
> > > > 
> > > It'd be nicer if people didn't try to line up arguments at all and
> > > just indented by an extra two tabs when they had to break a logical
> > > line due to the 80-column limit.
> > 
> > Matthew, there are two different opinions. Which one to take ?
> 
> Unfortunately this is one of those "maintainer's choice" preferences
> that drives new contributors crazy. Just go with the two tabs like
> Matthew said and be done.

The only reason I mentioned it was the old function name
was aligned that way with arguments aligned to the open
parenthesis.

Renaming the function should keep the same alignment style
and not just rename the function.

-   int (*fault)(const struct vm_special_mapping *sm,
+   vm_fault_t (*fault)(const struct vm_special_mapping *sm,
 struct vm_area_struct *vma,
 struct vm_fault *vmf);

Here the previous indent was 2 tabs, 5 spaces

Re: [PATCH 1/2] KVM: X86: Fix CR3 reserve bits

[Wanpeng Li]

2018-05-13 16:28 GMT+08:00 Liran Alon :
>
> - kernel...@gmail.com wrote:
>
>> 2018-05-13 15:53 GMT+08:00 Liran Alon :
>> >
>> > - kernel...@gmail.com wrote:
>> >
>> >> From: Wanpeng Li 
>> >>
>> >> MSB of CR3 is a reserved bit if the PCIDE bit is not set in CR4.
>> >> It should be checked when PCIDE bit is not set, however commit
>> >> 'd1cd3ce900441 ("KVM: MMU: check guest CR3 reserved bits based on
>> >> its physical address width")' removes the bit 63 checking
>> >> unconditionally. This patch fixes it by checking bit 63 of CR3
>> >> when PCIDE bit is not set in CR4.
>> >>
>> >> Fixes: d1cd3ce900441 (KVM: MMU: check guest CR3 reserved bits based
>> on
>> >> its physical address width)
>> >> Cc: Paolo Bonzini 
>> >> Cc: Radim Krčmář 
>> >> Cc: Junaid Shahid 
>> >> Signed-off-by: Wanpeng Li 
>> >> ---
>> >>  arch/x86/kvm/emulate.c | 4 +++-
>> >>  arch/x86/kvm/x86.c | 2 +-
>> >>  2 files changed, 4 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
>> >> index b3705ae..b21f427 100644
>> >> --- a/arch/x86/kvm/emulate.c
>> >> +++ b/arch/x86/kvm/emulate.c
>> >> @@ -4189,7 +4189,9 @@ static int check_cr_write(struct
>> >> x86_emulate_ctxt *ctxt)
>> >>   maxphyaddr = eax & 0xff;
>> >>   else
>> >>   maxphyaddr = 36;
>> >> - rsvd = rsvd_bits(maxphyaddr, 62);
>> >> + if (ctxt->ops->get_cr(ctxt, 4) &
>> X86_CR4_PCIDE)
>> >> + new_val &= ~CR3_PCID_INVD;
>> >> + rsvd = rsvd_bits(maxphyaddr, 63);
>> >
>> > I would prefer instead to do this:
>> > if (ctxt->ops->get_cr(ctxt, 4) & X86_CR4_PCIDE)
>> > rsvd &= ~CR3_PCID_INVD;
>> > It makes more sense as opposed to temporary removing the
>> CR3_PCID_INVD bit from new_val.
>>
>> It tries the same way
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_virt_kvm_kvm.git_commit_-3Fid-3Dc19986fea873f3c745122bf79013a872a190f212=DwIFaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0=r52WDgKBorUHwe_B_5Nw2Le_F_E0ne8lqqWW6n-3bSg=ufTcXvhhAMkY3XP6gAx-HiKCT8ynPWo2fs2z9DqCzM4=
>> pointed out.
>>
>> Regards,
>> Wanpeng Li
>
> Yes but there it makes sense as new CR3 value should not have bit 63 set in 
> vcpu->arch.cr3.

When X86_CR4_PCIDE == 0 and CR3 63 bit is set, a #GP is missing in
your suggestion.

Regards,
Wanpeng Li

Re: [PATCH 3/3] sched/fair: schedutil: explicit update only when required

[Joel Fernandes]

On Thu, May 10, 2018 at 04:05:53PM +0100, Patrick Bellasi wrote:
> Schedutil updates for FAIR tasks are triggered implicitly each time a
> cfs_rq's utilization is updated via cfs_rq_util_change(), currently
> called by update_cfs_rq_load_avg(), when the utilization of a cfs_rq has
> changed, and {attach,detach}_entity_load_avg().
> 
> This design is based on the idea that "we should callback schedutil
> frequently enough" to properly update the CPU frequency at every
> utilization change. However, such an integration strategy has also
> some downsides:

Hi Patrick,

I agree making the call explicit would make schedutil integration easier so
that's really awesome. However I also fear that if some path in the fair
class in the future changes the utilization but forgets to update schedutil
explicitly (because they forgot to call the explicit public API) then the
schedutil update wouldn't go through. In this case the previous design of
doing the schedutil update in the wrapper kind of was a nice to have

Just thinking out loud but is there a way you could make the implicit call
anyway incase the explicit call wasn't requested for some reason? That's
probably hard to do correctly though..

Some more comments below:

> 
>  - schedutil updates are triggered by RQ's load updates, which makes
>sense in general but it does not allow to know exactly which other RQ
>related information have been updated.
>Recently, for example, we had issues due to schedutil dependencies on
>cfs_rq->h_nr_running and estimated utilization updates.
> 
>  - cfs_rq_util_change() is mainly a wrapper function for an already
>existing "public API", cpufreq_update_util(), which is required
>just to ensure we actually update schedutil only when we are updating
>a root cfs_rq.
>Thus, especially when task groups are in use, most of the calls to
>this wrapper function are not required.
> 
>  - the usage of a wrapper function is not completely consistent across
>fair.c, since we could still need additional explicit calls to
>cpufreq_update_util().
>For example this already happens to report the IOWAIT boot flag in
>the wakeup path.
> 
>  - it makes it hard to integrate new features since it could require to
>change other function prototypes just to pass in an additional flag,
>as it happened for example in commit:
> 
>   ea14b57e8a18 ("sched/cpufreq: Provide migration hint")
> 
> All the above considered, let's make schedutil updates more explicit in
> fair.c by removing the cfs_rq_util_change() wrapper function in favour
> of the existing cpufreq_update_util() public API.
> This can be done by calling cpufreq_update_util() explicitly in the few
> call sites where it really makes sense and when all the (potentially)
> required cfs_rq's information have been updated.
> 
> This patch mainly removes code and adds explicit schedutil updates
> only when we:
>  - {enqueue,dequeue}_task_fair() a task to/from the root cfs_rq
>  - (un)throttle_cfs_rq() a set of tasks up to the root cfs_rq
>  - task_tick_fair() to update the utilization of the root cfs_rq
> 
> All the other code paths, currently _indirectly_ covered by a call to
> update_load_avg(), are still covered. Indeed, some paths already imply
> enqueue/dequeue calls:
>  - switch_{to,from}_fair()
>  - sched_move_task()
> while others are followed by enqueue/dequeue calls:
>  - cpu_cgroup_fork() and
>post_init_entity_util_avg():
>  are used at wakeup_new_task() time and thus already followed by an
>  enqueue_task_fair()
>  - migrate_task_rq_fair():
>  updates the removed utilization but not the actual cfs_rq
>  utilization, which is updated by a following sched event
> 
> This new proposal allows also to better aggregate schedutil related
> flags, which are required only at enqueue_task_fair() time.
> IOWAIT and MIGRATION flags are now requested only when a task is
> actually visible at the root cfs_rq level.
> 
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: Joel Fernandes 
> Cc: Juri Lelli 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> 
> ---
> 
> NOTE: this patch changes the behavior of the IOWAIT flag: in case of a
> task waking up on a throttled RQ we do not assert the flag to schedutil
> anymore. However, this seems to make sense since the task will not be
> running anyway.
> ---
>  kernel/sched/fair.c | 81 
> -
>  1 file changed, 36 insertions(+), 45 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 01dfc47541e6..87f092151a6e 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -772,7 +772,7 @@ void post_init_entity_util_avg(struct sched_entity *se)
>  

Re: [PATCH v2 7/7] ALSA: usb: add UAC3 BADD profiles support

[Takashi Iwai]

On Fri, 11 May 2018 17:36:36 +0200,
Jorge wrote:
> 
> 
> 
> On 04/05/18 02:24, Ruslan Bilovol wrote:
> > Recently released USB Audio Class 3.0 specification
> > contains BADD (Basic Audio Device Definition) document
> > which describes pre-defined UAC3 configurations.
> >
> > BADD support is mandatory for UAC3 devices, it should be
> > implemented as a separate USB device configuration.
> > As per BADD document, class-specific descriptors
> > shall not be included in the Device’s Configuration
> > descriptor ("inferred"), but host can guess them
> > from BADD profile number, number of endpoints and
> > their max packed sizes.
> >
> > This patch adds support of all BADD profiles from the spec
> >
> > Signed-off-by: Ruslan Bilovol 
> 
> Tested-by: Jorge Sanjuan 

OK, I'll queue this one to for-next branch.
Thanks!


Takashi

Re: [PATCH] ALSA: control: fix a redundant-copy issue

[Takashi Iwai]

On Sat, 05 May 2018 20:38:03 +0200,
Wenwen Wang wrote:
> 
> In snd_ctl_elem_add_compat(), the fields of the struct 'data' need to be
> copied from the corresponding fields of the struct 'data32' in userspace.
> This is achieved by invoking copy_from_user() and get_user() functions. The
> problem here is that the 'type' field is copied twice. One is by
> copy_from_user() and one is by get_user(). Given that the 'type' field is
> not used between the two copies, the second copy is *completely* redundant
> and should be removed for better performance and cleanup. Also, these two
> copies can cause inconsistent data: as the struct 'data32' resides in
> userspace and a malicious userspace process can race to change the 'type'
> field between the two copies to cause inconsistent data. Depending on how
> the data is used in the future, such an inconsistency may cause potential
> security risks.
> 
> For above reasons, we should take out the second copy.
> 
> Signed-off-by: Wenwen Wang 

Applied now, thanks.


Takashi

Re: [PATCH v5 03/13] ALSA: hda/ca0132: Add PCI region2 iomap for SBZ

[Takashi Iwai]

On Tue, 08 May 2018 19:20:03 +0200,
Connor McAdams wrote:
> 
> This patch adds iomapping for the region2 section of memory on the SBZ.
> This memory region is used in later patches for setting inputs and
> outputs. If the mapping fails, the quirk is changed back to QUIRK_NONE
> to avoid attempts to write to uninitialized memory.
> 
> It also adds a new exit sequence to unmap the iomem for the SBZ.
> 
> Signed-off-by: Connor McAdams 
> ---
>  sound/pci/hda/patch_ca0132.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c
> index 02238fe..78d2c26 100644
> --- a/sound/pci/hda/patch_ca0132.c
> +++ b/sound/pci/hda/patch_ca0132.c
> @@ -29,6 +29,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include "hda_codec.h"
>  #include "hda_local.h"
>  #include "hda_auto_parser.h"

The linux/*.h inclusion should be before sound/*.h.
But never mind, I fixed it locally, so no need for resubmission.


thanks,

Takashi

Re: general protection fault in __radix_tree_delete

[Dmitry Vyukov]

On Sun, Apr 29, 2018 at 7:00 PM, syzbot
 wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> cdface5209349930ae1b51338763c8e029971b97 (Sun Apr 29 03:07:21 2018 +)
> Merge tag 'for_linus_stable' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=549decbd1891d501b6d5
>
> So far this crash happened 8 times on upstream.
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6647588371562496
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=4781854846615552
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=4580574157078528
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=7043958930931867332
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+549decbd1891d501b...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.


This crash was bisected as introduced by:

commit faeb7833eee0d6afe0ecb6bdfa6042556c2c352e
Author: Roman Kagan 
Date:   Thu Feb 1 16:48:32 2018 +0300

kvm: x86: hyperv: guest->host event signaling via eventfd

https://gist.githubusercontent.com/dvyukov/df4971d7dfd1b37bedb5bfa0c95f9ebc/raw/ee8b7804788049f80625563e0322090c798c4544/gistfile1.txt



> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 4525 Comm: syz-executor786 Not tainted 4.17.0-rc2+ #23
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
> RIP: 0010:__radix_tree_delete+0x74/0x230 lib/radix-tree.c:1989
> RSP: 0018:8801d9137108 EFLAGS: 00010206
> RAX: 0003 RBX: dc00 RCX: 11003b226e3e
> RDX:  RSI: 8768eeed RDI: 8801a7dac168
> RBP: 8801d91371a8 R08: 8801d962c1c0 R09: ed0034fb5811
> R10: 8801d91372b8 R11: 8801a7dac08f R12: 
> R13: 8801a7dac168 R14: 0018 R15: 8801d9137230
> FS:  01df3880() GS:8801dae0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 2100 CR3: 0001d9104000 CR4: 001426f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  radix_tree_delete_item+0x148/0x2d0 lib/radix-tree.c:2050
>  idr_remove+0x46/0x60 lib/idr.c:157
>  kvm_hv_eventfd_deassign arch/x86/kvm/hyperv.c:1433 [inline]
>  kvm_vm_ioctl_hv_eventfd+0x1df/0x24b arch/x86/kvm/hyperv.c:1451
>  kvm_arch_vm_ioctl+0x155e/0x2690 arch/x86/kvm/x86.c:4563
>  kvm_vm_ioctl+0x246/0x1d90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3100
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  file_ioctl fs/ioctl.c:500 [inline]
>  do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
>  ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
>  __do_sys_ioctl fs/ioctl.c:708 [inline]
>  __se_sys_ioctl fs/ioctl.c:706 [inline]
>  __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x440069
> RSP: 002b:7ffcf0b02cd8 EFLAGS: 0217 ORIG_RAX: 0010
> RAX: ffda RBX: 6d766b2f7665642f RCX: 00440069
> RDX: 2000 RSI: 4018aebd RDI: 00a9
> RBP: 006cb018 R08: 7ffcf0b02cf0 R09: 7ffcf0b02cf0
> R10: 7ffcf0b02cf0 R11: 0217 R12: 004018a0
> R13: 00401930 R14:  R15: 
> Code: 3f 9a 88 48 c7 45 88 80 ee 68 87 c7 00 f1 f1 f1 f1 c7 40 04 00 f2 f2
> f2 c7 40 08 f3 f3 f3 f3 e8 a3 51 10 fa 4c 89 f0 48 c1 e8 03 <80> 3c 18 00 0f
> 85 97 01 00 00 48 8d 55 d8 4c 8d 7a c0 49 8b 1e
> RIP: __read_once_size include/linux/compiler.h:188 [inline] RSP:
> 8801d9137108
> RIP: __radix_tree_delete+0x74/0x230 lib/radix-tree.c:1989 RSP:
> 8801d9137108
> ---[ end trace 79327005f044daef ]---
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> 

Re: [PATCH 1/2] KVM: X86: Fix CR3 reserve bits

[Wanpeng Li]

2018-05-13 15:53 GMT+08:00 Liran Alon :
>
> - kernel...@gmail.com wrote:
>
>> From: Wanpeng Li 
>>
>> MSB of CR3 is a reserved bit if the PCIDE bit is not set in CR4.
>> It should be checked when PCIDE bit is not set, however commit
>> 'd1cd3ce900441 ("KVM: MMU: check guest CR3 reserved bits based on
>> its physical address width")' removes the bit 63 checking
>> unconditionally. This patch fixes it by checking bit 63 of CR3
>> when PCIDE bit is not set in CR4.
>>
>> Fixes: d1cd3ce900441 (KVM: MMU: check guest CR3 reserved bits based on
>> its physical address width)
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Cc: Junaid Shahid 
>> Signed-off-by: Wanpeng Li 
>> ---
>>  arch/x86/kvm/emulate.c | 4 +++-
>>  arch/x86/kvm/x86.c | 2 +-
>>  2 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
>> index b3705ae..b21f427 100644
>> --- a/arch/x86/kvm/emulate.c
>> +++ b/arch/x86/kvm/emulate.c
>> @@ -4189,7 +4189,9 @@ static int check_cr_write(struct
>> x86_emulate_ctxt *ctxt)
>>   maxphyaddr = eax & 0xff;
>>   else
>>   maxphyaddr = 36;
>> - rsvd = rsvd_bits(maxphyaddr, 62);
>> + if (ctxt->ops->get_cr(ctxt, 4) & X86_CR4_PCIDE)
>> + new_val &= ~CR3_PCID_INVD;
>> + rsvd = rsvd_bits(maxphyaddr, 63);
>
> I would prefer instead to do this:
> if (ctxt->ops->get_cr(ctxt, 4) & X86_CR4_PCIDE)
> rsvd &= ~CR3_PCID_INVD;
> It makes more sense as opposed to temporary removing the CR3_PCID_INVD bit 
> from new_val.

It tries the same way
https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?id=c19986fea873f3c745122bf79013a872a190f212
pointed out.

Regards,
Wanpeng Li

>
>>   }
>>
>>   if (new_val & rsvd)
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 87e4805..9a90668 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -863,7 +863,7 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned
>> long cr3)
>>   }
>>
>>   if (is_long_mode(vcpu) &&
>> - (cr3 & rsvd_bits(cpuid_maxphyaddr(vcpu), 62)))
>> + (cr3 & rsvd_bits(cpuid_maxphyaddr(vcpu), 63)))
>>   return 1;
>>   else if (is_pae(vcpu) && is_paging(vcpu) &&
>>  !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
>> --
>> 2.7.4

Re: [PATCH v3] PM / wakeup: use seq_open() to show wakeup stats

[Rafael J. Wysocki]

On Wednesday, April 25, 2018 12:59:31 PM CEST Ganesh Mahendran wrote:
> single_open() interface requires that the whole output must
> fit into a single buffer. This will lead to timeout when
> system memory is not in a good situation.
> 
> This patch use seq_open() to show wakeup stats. This method
> need only one page, so timeout will not be observed.
> 
> Signed-off-by: Ganesh Mahendran 
> 
> v3: simplify wakeup_sources_stats_seq_start
> v2: use srcu_read_lock instead of rcu_read_lock
> ---
>  drivers/base/power/wakeup.c | 75 
> +++--
>  1 file changed, 59 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> index ea01621..5872705 100644
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c
> @@ -1029,32 +1029,75 @@ static int print_wakeup_source_stats(struct seq_file 
> *m,
>   return 0;
>  }
>  
> -/**
> - * wakeup_sources_stats_show - Print wakeup sources statistics information.
> - * @m: seq_file to print the statistics into.
> - */
> -static int wakeup_sources_stats_show(struct seq_file *m, void *unused)
> +static void *wakeup_sources_stats_seq_start(struct seq_file *m,
> + loff_t *pos)
>  {
>   struct wakeup_source *ws;
> - int srcuidx;
> + loff_t n = *pos;
> + int *srcuidx = m->private;
>  
> - seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
> - "expire_count\tactive_since\ttotal_time\tmax_time\t"
> - "last_change\tprevent_suspend_time\n");
> + if (n == 0) {
> + seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
> + "expire_count\tactive_since\ttotal_time\tmax_time\t"
> + "last_change\tprevent_suspend_time\n");
> + }
>  
> - srcuidx = srcu_read_lock(_srcu);
> - list_for_each_entry_rcu(ws, _sources, entry)
> - print_wakeup_source_stats(m, ws);
> - srcu_read_unlock(_srcu, srcuidx);
> + *srcuidx = srcu_read_lock(_srcu);
> + list_for_each_entry_rcu(ws, _sources, entry) {
> + if (n-- <= 0)
> + return ws;
> + }
> +
> + return NULL;
> +}
> +
> +static void *wakeup_sources_stats_seq_next(struct seq_file *m,
> + void *v, loff_t *pos)
> +{
> + struct wakeup_source *ws = v;
> + struct wakeup_source *next_ws = NULL;
> +
> + ++(*pos);
>  
> - print_wakeup_source_stats(m, _ws);
> + list_for_each_entry_continue_rcu(ws, _sources, entry) {
> + next_ws = ws;
> + break;
> + }
> +
> + return next_ws;
> +}
> +
> +static void wakeup_sources_stats_seq_stop(struct seq_file *m, void *v)
> +{
> + int *srcuidx = m->private;
> +
> + srcu_read_unlock(_srcu, *srcuidx);
> +}
> +
> +/**
> + * wakeup_sources_stats_seq_show - Print wakeup sources statistics 
> information.
> + * @m: seq_file to print the statistics into.
> + * @v: wakeup_source of each iteration
> + */
> +static int wakeup_sources_stats_seq_show(struct seq_file *m, void *v)
> +{
> + struct wakeup_source *ws = v;
> +
> + print_wakeup_source_stats(m, ws);
>  
>   return 0;
>  }
>  
> +static const struct seq_operations wakeup_sources_stats_seq_ops = {
> + .start = wakeup_sources_stats_seq_start,
> + .next  = wakeup_sources_stats_seq_next,
> + .stop  = wakeup_sources_stats_seq_stop,
> + .show  = wakeup_sources_stats_seq_show,
> +};
> +
>  static int wakeup_sources_stats_open(struct inode *inode, struct file *file)
>  {
> - return single_open(file, wakeup_sources_stats_show, NULL);
> + return seq_open_private(file, _sources_stats_seq_ops, 
> sizeof(int));
>  }
>  
>  static const struct file_operations wakeup_sources_stats_fops = {
> @@ -1062,7 +1105,7 @@ static int wakeup_sources_stats_open(struct inode 
> *inode, struct file *file)
>   .open = wakeup_sources_stats_open,
>   .read = seq_read,
>   .llseek = seq_lseek,
> - .release = single_release,
> + .release = seq_release_private,
>  };
>  
>  static int __init wakeup_sources_debugfs_init(void)
> 

Applied, thanks!

Re: [PATCH v3 4/6] KVM: x86: hyperv: simplistic HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST,SPACE} implementation

[Vitaly Kuznetsov]

Radim Krčmář  writes:

> 2018-04-16 13:08+0200, Vitaly Kuznetsov:
...
>
>> +/*
>> + * vcpu->arch.cr3 may not be up-to-date for running vCPUs so we
>> + * can't analyze it here, flush TLB regardless of the specified
>> + * address space.
>> + */
>> +kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
>> +
>> +/*
>> + * It is possible that vCPU will migrate and we will kick wrong
>> + * CPU but vCPU's TLB will anyway be flushed upon migration as
>> + * we already made KVM_REQ_TLB_FLUSH request.
>> + */
>> +cpu = vcpu->cpu;
>> +if (cpu != -1 && cpu != me && cpu_online(cpu) &&
>> +kvm_arch_vcpu_should_kick(vcpu))
>> +cpumask_set_cpu(cpu, _current->tlb_lush);
>> +}
>> +
>> +if (!cpumask_empty(_current->tlb_lush))
>> +smp_call_function_many(_current->tlb_lush, ack_flush,
>> +   NULL, true);
>
> Hm, quite a lot of code duplication with EX hypercall and also
> kvm_make_all_cpus_request ... I'm thinking about making something like
>
>   kvm_make_some_cpus_request(struct kvm *kvm, unsigned int req,
>  bool (*predicate)(struct kvm_vcpu *vcpu))
>
> or to implement a vp_index -> vcpu mapping and using
>
>   kvm_vcpu_request_mask(struct kvm *kvm, unsigned int req, long *vcpu_bitmap)
>
> The latter would probably simplify logic of the EX hypercall.

We really want to avoid memory allocation for cpumask on this path and
that's what kvm_make_all_cpus_request() currently does (when
CPUMASK_OFFSTACK). vcpu bitmap is probably OK as KVM_MAX_VCPUS is much
lower.

Making cpumask allocation avoidable leads us to the following API:

bool kvm_make_vcpus_request_mask(struct kvm *kvm, unsigned int req,
 long *vcpu_bitmap, cpumask_var_t tmp);

or, if we want to prettify this a little bit, we may end up with the
following pair:

bool kvm_make_vcpus_request_mask(struct kvm *kvm, unsigned int req,
 long *vcpu_bitmap);

bool __kvm_make_vcpus_request_mask(struct kvm *kvm, unsigned int req,
   long *vcpu_bitmap, cpumask_var_t tmp);

and from hyperv code we'll use the later. With this, no code duplication
is required.

Does this look acceptable?

-- 
  Vitaly

Re: [PATCH 0/3] PM / core: Clean up suspend/resume diagnostic messages

[Rafael J. Wysocki]

On Thursday, April 26, 2018 11:36:20 PM CEST Bjorn Helgaas wrote:
> These are pretty minor cleanups to the suspend/resume diagnostic messages.
> 
> The first two are trivial.  The third may break scripts that parse dmesg
> output.  I looked at scripts/bootgraph.pl, and I don't think it is
> affected, but there may be others I don't know about.  Let me know if there
> are.
> 
> ---
> 
> Bjorn Helgaas (3):
>   PM / core: Remove unused initcall_debug_report() arguments
>   PM / core: Simplify initcall_debug_report() timing
>   PM / core: Use dev_printk() and symbols in suspend/resume diagnostics
> 
> 
>  drivers/base/power/main.c |   37 +
>  1 file changed, 17 insertions(+), 20 deletions(-)
> 

All [1-3/3] applied, thanks!

Re: [PATCH] cpufreq: s3c2440: fix spelling mistake: "divsiors" -> "divisors"

[Rafael J. Wysocki]

On Wednesday, May 2, 2018 7:37:21 AM CEST Viresh Kumar wrote:
> On 30-04-18, 15:48, Colin King wrote:
> > From: Colin Ian King 
> > 
> > Trivial fix to spelling mistake in s3c_freq_dbg debug message text.
> > 
> > Signed-off-by: Colin Ian King 
> > ---
> >  drivers/cpufreq/s3c2440-cpufreq.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/cpufreq/s3c2440-cpufreq.c 
> > b/drivers/cpufreq/s3c2440-cpufreq.c
> > index d0d75b65ddd6..d2f67b7a20dd 100644
> > --- a/drivers/cpufreq/s3c2440-cpufreq.c
> > +++ b/drivers/cpufreq/s3c2440-cpufreq.c
> > @@ -143,7 +143,7 @@ static void s3c2440_cpufreq_setdivs(struct 
> > s3c_cpufreq_config *cfg)
> >  {
> > unsigned long clkdiv, camdiv;
> >  
> > -   s3c_freq_dbg("%s: divsiors: h=%d, p=%d\n", __func__,
> > +   s3c_freq_dbg("%s: divisors: h=%d, p=%d\n", __func__,
> >  cfg->divs.h_divisor, cfg->divs.p_divisor);
> >  
> > clkdiv = __raw_readl(S3C2410_CLKDIVN);
> 
> Acked-by: Viresh Kumar 
> 
> 

Applied, thanks!

Re: [Intel-wired-lan] [PATCH] e1000e: Ignore TSYNCRXCTL when getting I219 clock attributes

[Neftin, Sasha]

On 5/10/2018 21:42, Keller, Jacob E wrote:

-Original Message-
From: Benjamin Poirier [mailto:bpoir...@suse.com]
Sent: Thursday, May 10, 2018 12:29 AM
To: Kirsher, Jeffrey T 
Cc: Keller, Jacob E ; Achim Mildenberger
; olouvig...@gmail.com;
jaya...@goubiq.com; ehabk...@redhat.com; postmodern.m...@gmail.com;
bart.vanass...@wdc.com; intel-wired-...@lists.osuosl.org;
net...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: [PATCH] e1000e: Ignore TSYNCRXCTL when getting I219 clock attributes

There have been multiple reports of crashes that look like
kernel: RIP: 0010:[] timecounter_read+0xf/0x50
[...]
kernel: Call Trace:
kernel:  [] e1000e_phc_gettime+0x2f/0x60 [e1000e]
kernel:  [] e1000e_systim_overflow_work+0x1d/0x80 [e1000e]
kernel:  [] process_one_work+0x155/0x440
kernel:  [] worker_thread+0x116/0x4b0
kernel:  [] kthread+0xd2/0xf0
kernel:  [] ret_from_fork+0x3f/0x70

These can be traced back to the fact that e1000e_systim_reset() skips the
timecounter_init() call if e1000e_get_base_timinca() returns -EINVAL, which
leads to a null deref in timecounter_read().

Commit 83129b37ef35 ("e1000e: fix systim issues", v4.2-rc1) reworked
e1000e_get_base_timinca() in such a way that it can return -EINVAL for
e1000_pch_spt if the SYSCFI bit is not set in TSYNCRXCTL.

Some experimentation has shown that on I219 (e1000_pch_spt, "MAC: 12")
adapters, the E1000_TSYNCRXCTL_SYSCFI flag is unstable; TSYNCRXCTL reads
sometimes don't have the SYSCFI bit set. Retrying the read shortly after
finds the bit to be set. This was observed at boot (probe) but also link up
and link down.

Moreover, the phc (PTP Hardware Clock) seems to operate normally even after
reads where SYSCFI=0. Therefore, remove this register read and
unconditionally set the clock parameters.

Reported-by: Achim Mildenberger 
Message-Id: <20180425065243.g5mqewg5irkwgwgv@f2>
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1075876
Fixes: 83129b37ef35 ("e1000e: fix systim issues")
Signed-off-by: Benjamin Poirier 
---
  drivers/net/ethernet/intel/e1000e/netdev.c | 15 ++-
  1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index ec4a9759a6f2..3afb1f3b6f91 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3546,15 +3546,12 @@ s32 e1000e_get_base_timinca(struct e1000_adapter
*adapter, u32 *timinca)
}
break;
case e1000_pch_spt:
-   if (er32(TSYNCRXCTL) & E1000_TSYNCRXCTL_SYSCFI) {
-   /* Stable 24MHz frequency */
-   incperiod = INCPERIOD_24MHZ;
-   incvalue = INCVALUE_24MHZ;
-   shift = INCVALUE_SHIFT_24MHZ;
-   adapter->cc.shift = shift;
-   break;
-   }
-   return -EINVAL;
+   /* Stable 24MHz frequency */
+   incperiod = INCPERIOD_24MHZ;
+   incvalue = INCVALUE_24MHZ;
+   shift = INCVALUE_SHIFT_24MHZ;
+   adapter->cc.shift = shift;
+   break;
case e1000_pch_cnp:
if (er32(TSYNCRXCTL) & E1000_TSYNCRXCTL_SYSCFI) {
/* Stable 24MHz frequency */
--
2.16.3


Given testing showing that the clock operates fine regardless of the register 
read, I think this is probably fine. Normally I believe the register was used 
to check which frequency was in use, but it doesn't seem to serve that purpose 
here.

Thanks,
Jake
___
Intel-wired-lan mailing list
intel-wired-...@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

I've checked our specification, looks only 24MHz used for this product. 
Hope no different platform with another clock support has been 
distributed. So, let's pick up this change.

Re: [PATCH v5 00/13] ALSA: hda/ca0132: Patch Series for Recon3Di and Sound Blaster Z Support

[Takashi Iwai]

On Tue, 08 May 2018 19:20:00 +0200,
Connor McAdams wrote:
> 
> This patchset adds support for the Sound Blaster Z and the Recon3Di.
> 
> In order to figure out how to get these cards to work, I made a program called
> QemuHDADump[1], which uses the trace function of qemu to see interactions with
> the memory mapped pci BAR space of the card being used in the virtual machine.
> With this, I obtain the CORB buffer location to get the command verbs, and 
> then
> dump them each time the buffer rolls over. This program may be useful for 
> fixing
> other HDA related driver issues where there is no documentation for the 
> device.
> 
> So far, I have been able to get all features supported on the Sound Blaster Z
> and the Recon3Di. All output and input effects work, all inputs and outputs
> work, and just about anything else I can think of. I have also added new
> controls in order to select the new inputs and outputs, as well as controls to
> change the effect levels and presets.
> 
> I have also added the ability to use firmware taken from the Windows drivers 
> of
> both the Sound Blaster Z and Recon3Di. I am trying to get into contact with
> Creative to get permission to redistribute these along with the current
> file included with the Chromebook, but they have not been very responsive.
> Luckily, the cards work with the Chromebook firmware just fine, although I
> believe there has to be a reason they have different firmware in Windows. I
> will not link to the firmwares here, but if you look up my thread on Creative
> Labs forums, you will find the link to download the firmwares there.
> 
> I am willing to help get the other non-working cards such as the ZxR and the
> newer AE-5 working too, but I will need someone willing to run QemuHDADump in 
> a
> virtual machine in order to get the commands.
> 
> So, in summary:
> -This patchset makes the cards work better than they did before (they really
>  didn't work before)
> 
> -This patchset leaves the original chromebook related stuff alone.
> 
> Thanks.
> 
> [1] https://github.com/Conmanx360/QemuHDADump
> 
> Bugs:
> ---
> Recon3Di: (Reported by Mariusz Ceier)
> ***
> -Occasionally switching between rear and front mic breaks the input until
>  computer is shutdown or put to sleep.
> 
> -Surround Sound works, but is inconsistent. Sometimes, just updating the 
> volume
>  fixes it, and sometimes, it requires a restart.
> 
> Sound Blaster Z:
> ***
> -none that I'm aware of.
> 
> 
> Version changes:
> ---
> v1:
> ***
> -Massive patch formatting failure, please ignore v1.
> 
> v2:
> ***
> -Fixed patch formatting failure.
> 
> v3:
> ***
> -Fixed mem_base unmap, instead of checking for QUIRK_SBZ on exit, have it 
> check
>  if the area is mapped, and if it is, unmap it. Also make it unmap after all
>  other commands are finished.
> 
> -Change notification of failure to map mem_base from codec_dbg to codec_warn,
>  and use codec_info to tell the user that their card might have been 
> incorrectly
>  identified as a Sound Blaster Z.
> 
> -Remove commented out commands in sbz_exit_chip function, only reintroduce 
> them
>  when their functions are defined.
> 
> v4:
> ***
> -Split patch into smaller pieces.
> 
> -Added const to alt_out_presets array.
> 
> -Fixed command that was commented out and only put it in when
>  it was actually used.
> 
> v5:
> ***
> -Fixed issue identified by kbuild test robot, where patch 12 didn't compile
>  individually.
> 
> Connor McAdams (13):
>   ALSA: hda/ca0132: R3Di and SBZ quirk entires + alt firmware loading
>   ALSA: hda/ca0132: Add pincfg for SBZ + R3Di, add fp hp auto-detect
>   ALSA: hda/ca0132: Add PCI region2 iomap for SBZ
>   ALSA: hda/ca0132: Add extra exit functions for R3Di and SBZ
>   ALSA: hda/ca0132: add extra init functions for r3di + sbz
>   ALSA: hda/ca0132: update core functions for sbz + r3di
>   ALSA: hda/ca0132: add dsp setup related commands for the sbz
>   ALSA: hda/ca0132: Add dsp setup + gpio functions for r3di
>   ALSA: hda/ca0132: add the ability to set src_id on scp commands
>   ALSA: hda/ca0132: add alt_select_in/out for R3Di + SBZ
>   ALSA: hda/ca0132: Add DSP Volume set and New mixers for SBZ + R3Di
>   ALSA: hda/ca0132: add ca0132_alt_set_vipsource
>   ALSA: hda/ca0132: Add new control changes for SBZ + R3Di

Now I applied all patches to for-next branch.
Thanks for your work, it has been a PITA for long time!


Takashi

Re: [PATCH v5 03/23] iommu/vt-d: add a flag for pasid table bound status

[Lu Baolu]

Hi,

On 05/12/2018 04:53 AM, Jacob Pan wrote:
> Adding a flag in device domain into to track whether a guest or
typo:   ^^info

Best regards,
Lu Baolu

> user PASID table is bound to a device.
>
> Signed-off-by: Jacob Pan 
> ---
>  include/linux/intel-iommu.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> index 304afae..ddc7d79 100644
> --- a/include/linux/intel-iommu.h
> +++ b/include/linux/intel-iommu.h
> @@ -473,6 +473,7 @@ struct device_domain_info {
>   u8 pri_enabled:1;
>   u8 ats_supported:1;
>   u8 ats_enabled:1;
> + u8 pasid_table_bound:1;
>   u8 ats_qdep;
>   u64 fault_mask; /* selected IOMMU faults to be reported */
>   struct device *dev; /* it's NULL for PCIe-to-PCI bridge */

Re: KASAN: null-ptr-deref Write in linear_transfer

[Takashi Iwai]

On Sun, 13 May 2018 09:36:36 +0200,
Eric Biggers wrote:
> 
> On Wed, Jan 10, 2018 at 10:58:43AM +0100, Takashi Iwai wrote:
> > On Wed, 10 Jan 2018 09:08:00 +0100,
> > Eric Biggers wrote:
> > > 
> > > On Fri, Jan 05, 2018 at 02:58:02AM -0800, syzbot wrote:
> > > > Hello,
> > > > 
> > > > syzkaller hit the following crash on
> > > > 30a7acd573899fd8b8ac39236eff6468b195ac7d
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > > > compiler: gcc (GCC) 7.1.1 20170620
> > > > .config is attached
> > > > Raw console output is attached.
> > > > C reproducer is attached
> > > > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > > > for information about syzkaller reproducers
> > > > 
> > > > 
> > > > IMPORTANT: if you fix the bug, please add the following tag to the 
> > > > commit:
> > > > Reported-by: syzbot+a8f5641f452c7e6ab...@syzkaller.appspotmail.com
> > > > It will help syzbot understand when the bug is fixed. See footer for
> > > > details.
> > > > If you forward the report, please keep this part and the footer.
> > > > 
> > > > ==
> > > > BUG: KASAN: null-ptr-deref in memcpy include/linux/string.h:344 [inline]
> > > > BUG: KASAN: null-ptr-deref in do_convert sound/core/oss/linear.c:52 
> > > > [inline]
> > > > BUG: KASAN: null-ptr-deref in convert sound/core/oss/linear.c:81 
> > > > [inline]
> > > > BUG: KASAN: null-ptr-deref in linear_transfer+0x634/0x900
> > > > sound/core/oss/linear.c:110
> > > > Write of size 2 at addr   (null) by task syzkaller360172/7860
> > > > 
> > > > CPU: 0 PID: 7860 Comm: syzkaller360172 Not tainted 4.15.0-rc6+ #155
> > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > Google 01/01/2011
> > > > Call Trace:
> > > >  __dump_stack lib/dump_stack.c:17 [inline]
> > > >  dump_stack+0x194/0x257 lib/dump_stack.c:53
> > > >  kasan_report_error mm/kasan/report.c:349 [inline]
> > > >  kasan_report+0x13b/0x340 mm/kasan/report.c:409
> > > >  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
> > > >  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
> > > >  memcpy+0x37/0x50 mm/kasan/kasan.c:303
> > > >  memcpy include/linux/string.h:344 [inline]
> > > >  do_convert sound/core/oss/linear.c:52 [inline]
> > > >  convert sound/core/oss/linear.c:81 [inline]
> > > >  linear_transfer+0x634/0x900 sound/core/oss/linear.c:110
> > > >  snd_pcm_plug_write_transfer+0x22d/0x420 sound/core/oss/pcm_plugin.c:611
> > > >  snd_pcm_oss_write2+0x260/0x420 sound/core/oss/pcm_oss.c:1311
> > > >  snd_pcm_oss_sync1+0x1cc/0x550 sound/core/oss/pcm_oss.c:1530
> > > >  snd_pcm_oss_sync+0x5b6/0x830 sound/core/oss/pcm_oss.c:1604
> > > >  snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431
> > > >  __fput+0x327/0x7e0 fs/file_table.c:210
> > > >  fput+0x15/0x20 fs/file_table.c:244
> > > >  task_work_run+0x199/0x270 kernel/task_work.c:113
> > > >  exit_task_work include/linux/task_work.h:22 [inline]
> > > >  do_exit+0x9bb/0x1ad0 kernel/exit.c:865
> > > >  do_group_exit+0x149/0x400 kernel/exit.c:968
> > > >  get_signal+0x73f/0x16c0 kernel/signal.c:2335
> > > >  do_signal+0x90/0x1eb0 arch/x86/kernel/signal.c:809
> > > >  exit_to_usermode_loop+0x214/0x310 arch/x86/entry/common.c:158
> > > >  prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
> > > >  syscall_return_slowpath arch/x86/entry/common.c:264 [inline]
> > > >  do_syscall_32_irqs_on arch/x86/entry/common.c:333 [inline]
> > > >  do_fast_syscall_32+0xbfd/0xf9d arch/x86/entry/common.c:389
> > > >  entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:129
> > > 
> > > Still reproducible even after all the fixes currently in sound/for-linus.
> > 
> > Interesting, I can't reproduce it on my VM any longer...
> > 
> 
> No longer occurring, last occurrence was Mar 29 on commit a2601d78b77aa.
> Seems to have been fixed by commit 02a5d6925cd3:
> 
> #syz fix: ALSA: pcm: Avoid potential races between OSS ioctls and read/write
> 
> The reproducer was opening /dev/dsp1, then concurrently writing to it and
> calling the SNDCTL_DSP_SPEED ioctl.

Good to hear.  Yes, this should have been covered by the change.
Thanks for checking!


Takashi

Re: [PATCH 1/2] KVM: X86: Fix CR3 reserve bits

[Liran Alon]

- kernel...@gmail.com wrote:

> From: Wanpeng Li 
> 
> MSB of CR3 is a reserved bit if the PCIDE bit is not set in CR4. 
> It should be checked when PCIDE bit is not set, however commit 
> 'd1cd3ce900441 ("KVM: MMU: check guest CR3 reserved bits based on 
> its physical address width")' removes the bit 63 checking 
> unconditionally. This patch fixes it by checking bit 63 of CR3 
> when PCIDE bit is not set in CR4.
> 
> Fixes: d1cd3ce900441 (KVM: MMU: check guest CR3 reserved bits based on
> its physical address width)
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Junaid Shahid 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/emulate.c | 4 +++-
>  arch/x86/kvm/x86.c | 2 +-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index b3705ae..b21f427 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -4189,7 +4189,9 @@ static int check_cr_write(struct
> x86_emulate_ctxt *ctxt)
>   maxphyaddr = eax & 0xff;
>   else
>   maxphyaddr = 36;
> - rsvd = rsvd_bits(maxphyaddr, 62);
> + if (ctxt->ops->get_cr(ctxt, 4) & X86_CR4_PCIDE)
> + new_val &= ~CR3_PCID_INVD;
> + rsvd = rsvd_bits(maxphyaddr, 63);

I would prefer instead to do this:
if (ctxt->ops->get_cr(ctxt, 4) & X86_CR4_PCIDE)
rsvd &= ~CR3_PCID_INVD;
It makes more sense as opposed to temporary removing the CR3_PCID_INVD bit from 
new_val.

>   }
>  
>   if (new_val & rsvd)
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 87e4805..9a90668 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -863,7 +863,7 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned
> long cr3)
>   }
>  
>   if (is_long_mode(vcpu) &&
> - (cr3 & rsvd_bits(cpuid_maxphyaddr(vcpu), 62)))
> + (cr3 & rsvd_bits(cpuid_maxphyaddr(vcpu), 63)))
>   return 1;
>   else if (is_pae(vcpu) && is_paging(vcpu) &&
>  !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
> -- 
> 2.7.4

Re: [PATCH 3/3] arm64: dts: renesas: draak: Describe HDMI input

[Simon Horman]

On Fri, May 11, 2018 at 12:00:02PM +0200, Jacopo Mondi wrote:
> Describe HDMI input connected to VIN4 interface for R-Car D3 Draak
> development board.
> 
> Signed-off-by: Jacopo Mondi 

Hi Niklas,

As you reviewed the rest of the series I'm wondering if you're planning
to review this patch too.

Re: [PATCH V5] cpufreq: intel_pstate: allow trace in passive mode

[Rafael J. Wysocki]

On Thursday, May 3, 2018 8:22:47 AM CEST Doug Smythies wrote:
> Allow use of the trace_pstate_sample trace function
> when the intel_pstate driver is in passive mode.
> Since the core_busy and scaled_busy fields are not
> used, and it might be desirable to know which path
> through the driver was used, either intel_cpufreq_target
> or intel_cpufreq_fast_switch, re-task the core_busy
> field as a flag indicator.
> 
> The user can then use the intel_pstate_tracer.py utility
> to summarize and plot the trace.
> 
> Note: The core_busy feild still goes by that name
> in include/trace/events/power.h and within the
> intel_pstate_tracer.py script and csv file headers,
> but it is graphed as "performance", and called
> core_avg_perf now in the intel_pstate driver.
> 
> Sometimes, in passive mode, the driver is not called for
> many tens or even hundreds of seconds. The user
> needs to understand, and not be confused by, this limitation.
> 
> Signed-off-by: Doug Smythies 

Srinivas, any comments or concerns?

> 
> ---
> 
> V5: Changes as per Rafael J. Wysocki feedback.
> See: https://lkml.org/lkml/2018/1/7/270
> 
> V4: Only execute the trace specific overhead code if trace
> is enabled. Suggested by Srinivas Pandruvada.
> 
> V3: Move largely duplicate code to a subroutine.
> Suggested by Rafael J. Wysocki.
> 
> V2: prepare for resend. Rebase to current kernel, 4.15-rc3.
> 
> ---
>  drivers/cpufreq/intel_pstate.c | 44 
> --
>  1 file changed, 42 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 17e566af..4a08686 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1939,13 +1939,49 @@ static int intel_cpufreq_verify_policy(struct 
> cpufreq_policy *policy)
>   return 0;
>  }
>  
> +/* Use of trace in passive mode:
> + *
> + * In passive mode the trace core_busy field (also known as the
> + * performance field, and lablelled as such on the graphs; also known as
> + * core_avg_perf) is not needed and so is re-assigned to indicate if the
> + * driver call was via the normal or fast switch path. Various graphs
> + * output from the intel_pstate_tracer.py utility that include core_busy
> + * (or performance or core_avg_perf) have a fixed y-axis from 0 to 100%,
> + * so we use 10 to indicate the the normal path through the driver, and
> + * 90 to indicate the fast switch path through the driver.
> + * The scaled_busy field is not used, and is set to 0.
> + */
> +
> +#define  INTEL_PSTATE_TRACE_TARGET 10
> +#define  INTEL_PSTATE_TRACE_FAST_SWITCH 90
> +
> +static void intel_cpufreq_trace(struct cpudata *cpu, unsigned int 
> trace_type, int old_pstate)
> +{
> + struct sample *sample;
> +
> + if (!trace_pstate_sample_enabled())
> + return;
> + if (!intel_pstate_sample(cpu, ktime_get()))
> + return;
> + sample = >sample;
> + trace_pstate_sample(trace_type,
> + 0,
> + old_pstate,
> + cpu->pstate.current_pstate,
> + sample->mperf,
> + sample->aperf,
> + sample->tsc,
> + get_avg_frequency(cpu),
> + fp_toint(cpu->iowait_boost * 100));
> +}
> +
>  static int intel_cpufreq_target(struct cpufreq_policy *policy,
>   unsigned int target_freq,
>   unsigned int relation)
>  {
>   struct cpudata *cpu = all_cpu_data[policy->cpu];
>   struct cpufreq_freqs freqs;
> - int target_pstate;
> + int target_pstate, old_pstate;
>  
>   update_turbo_state();
>  
> @@ -1965,12 +2001,14 @@ static int intel_cpufreq_target(struct cpufreq_policy 
> *policy,
>   break;
>   }
>   target_pstate = intel_pstate_prepare_request(cpu, target_pstate);
> + old_pstate = cpu->pstate.current_pstate;
>   if (target_pstate != cpu->pstate.current_pstate) {
>   cpu->pstate.current_pstate = target_pstate;
>   wrmsrl_on_cpu(policy->cpu, MSR_IA32_PERF_CTL,
> pstate_funcs.get_val(cpu, target_pstate));
>   }
>   freqs.new = target_pstate * cpu->pstate.scaling;
> + intel_cpufreq_trace(cpu, INTEL_PSTATE_TRACE_TARGET, old_pstate);
>   cpufreq_freq_transition_end(policy, , false);
>  
>   return 0;
> @@ -1980,13 +2018,15 @@ static unsigned int intel_cpufreq_fast_switch(struct 
> cpufreq_policy *policy,
> unsigned int target_freq)
>  {
>   struct cpudata *cpu = all_cpu_data[policy->cpu];
> - int target_pstate;
> + int target_pstate, old_pstate;
>  
>   update_turbo_state();
>  
>   target_pstate = DIV_ROUND_UP(target_freq, cpu->pstate.scaling);
>   target_pstate = intel_pstate_prepare_request(cpu, target_pstate);
> + old_pstate = cpu->pstate.current_pstate;
>   intel_pstate_update_pstate(cpu, 

Re: [PATCH 2/2] KVM: X86: Fix loss of CR3_PCID_INVD bit when guest writes CR3

[Wanpeng Li]

2018-05-13 16:03 GMT+08:00 Liran Alon :
>
> - kernel...@gmail.com wrote:
>
>> From: Wanpeng Li 
>>
>> SDM volume 3, section 4.10.4:
>>
>> * MOV to CR3. The behavior of the instruction depends on the value of
>> CR4.PCIDE:
>> — If CR4.PCIDE = 1 and bit 63 of the instruction’s source operand is
>> 1, the
>>   instruction is not required to invalidate any TLB entries or entries
>> in
>>   paging-structure caches.
>>
>> The CR3_PCID_INVD bit should not be removed if CR4.PCIDE = 1 when
>> guest writes
>> CR3, this patch fixes it.
>>
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Cc: Junaid Shahid 
>> Signed-off-by: Wanpeng Li 
>> ---
>>  arch/x86/kvm/x86.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 9a90668..438f140 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -849,11 +849,13 @@ EXPORT_SYMBOL_GPL(kvm_set_cr4);
>>
>>  int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
>>  {
>> + unsigned long cr3_check = cr3;
>> +
>>  #ifdef CONFIG_X86_64
>>   bool pcid_enabled = kvm_read_cr4_bits(vcpu, X86_CR4_PCIDE);
>>
>>   if (pcid_enabled)
>> - cr3 &= ~CR3_PCID_INVD;
>> + cr3_check &= ~CR3_PCID_INVD;
>>  #endif
>>
>>   if (cr3 == kvm_read_cr3(vcpu) && !pdptrs_changed(vcpu)) {
>> @@ -863,7 +865,7 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned
>> long cr3)
>>   }
>>
>>   if (is_long_mode(vcpu) &&
>> - (cr3 & rsvd_bits(cpuid_maxphyaddr(vcpu), 63)))
>> + (cr3_check & rsvd_bits(cpuid_maxphyaddr(vcpu), 63)))
>>   return 1;
>>   else if (is_pae(vcpu) && is_paging(vcpu) &&
>>  !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
>> --
>> 2.7.4
>
> This commit doesn't seem correct to me.
>
> According to Intel SDM "MOV—Move to/from Control Registers":
> "If CR4.PCIDE = 1, bit 63 of the source operand to MOV to CR3 determines 
> whether the instruction
> invalidates entries in the TLBs and the paging-structure caches
> (see Section 4.10.4.1, “Operations that Invalidate TLBs and Paging-Structure 
> Caches,”
> in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 
> 3A).
> The instruction does not modify bit 63 of CR3, which is reserved and always 
> 0."
>
> However, after this commit kvm_set_cr3() will update vcpu->arch.cr3 to have 
> bit CR3_PCID_INVD set.
> Which is wrong as it should be reserved and always 0.

You are right, thanks Liran.

Regards,
Wanpeng Li

Re: [PATCH] tools/power/x86/intel_pstate_tracer: Add optional setting of trace buffer memory allocation

[Rafael J. Wysocki]

On Friday, May 4, 2018 3:46:22 PM CEST Doug Smythies wrote:
> Allow the user to override the default trace buffer memory allocation
> by adding a command line option to override the default.
> 
> The patch also:
> 
> Adds a SIGINT (i.e. CTRL C exit) handler,
> so that things can be cleaned up before exit.
> 
> Moves the postion of some other cleanup from after to
> before the potential "No valid data to plot" exit.
> 
> Replaces all quit() calls with sys.exit, because
> quit() is not supposed to be used in scripts.
> 
> Signed-off-by: Doug Smythies 

Srinivas, any comments here?

> ---
>  .../x86/intel_pstate_tracer/intel_pstate_tracer.py | 54 
> ++
>  1 file changed, 35 insertions(+), 19 deletions(-)
> 
> diff --git a/tools/power/x86/intel_pstate_tracer/intel_pstate_tracer.py 
> b/tools/power/x86/intel_pstate_tracer/intel_pstate_tracer.py
> index 29f50d4..84e2b64 100755
> --- a/tools/power/x86/intel_pstate_tracer/intel_pstate_tracer.py
> +++ b/tools/power/x86/intel_pstate_tracer/intel_pstate_tracer.py
> @@ -28,6 +28,7 @@ import subprocess
>  import os
>  import time
>  import re
> +import signal
>  import sys
>  import getopt
>  import Gnuplot
> @@ -78,11 +79,12 @@ def print_help():
>  print('Or')
>  print('  ./intel_pstate_tracer.py [--cpu cpus] ---trace_file 
>  --name ')
>  print('To generate trace file, parse and plot, use (sudo required):')
> -print('  sudo ./intel_pstate_tracer.py [-c cpus] -i  -n 
> ')
> +print('  sudo ./intel_pstate_tracer.py [-c cpus] -i  -n 
>  -m ')
>  print('Or')
> -print('  sudo ./intel_pstate_tracer.py [--cpu cpus] --interval 
>  --name ')
> +print('  sudo ./intel_pstate_tracer.py [--cpu cpus] --interval 
>  --name  --memory ')
>  print('Optional argument:')
> -print('  cpus:  comma separated list of CPUs')
> +print('  cpus:   comma separated list of CPUs')
> +print('  kbytes: Kilo bytes of memory per CPU to allocate to the 
> trace buffer. Default: 10240')
>  print('  Output:')
>  print('If not already present, creates a "results/test_name" folder 
> in the current working directory with:')
>  print('  cpu.csv - comma seperated values file with trace contents 
> and some additional calculations.')
> @@ -379,7 +381,7 @@ def clear_trace_file():
>  f_handle.close()
>  except:
>  print('IO error clearing trace file ')
> -quit()
> +sys.exit(2)
>  
>  def enable_trace():
>  """ Enable trace """
> @@ -389,7 +391,7 @@ def enable_trace():
>   , 'w').write("1")
>  except:
>  print('IO error enabling trace ')
> -quit()
> +sys.exit(2)
>  
>  def disable_trace():
>  """ Disable trace """
> @@ -399,17 +401,17 @@ def disable_trace():
>   , 'w').write("0")
>  except:
>  print('IO error disabling trace ')
> -quit()
> +sys.exit(2)
>  
>  def set_trace_buffer_size():
>  """ Set trace buffer size """
>  
>  try:
> -   open('/sys/kernel/debug/tracing/buffer_size_kb'
> - , 'w').write("10240")
> +   with open('/sys/kernel/debug/tracing/buffer_size_kb', 'w') as fp:
> +  fp.write(memory)
>  except:
> -print('IO error setting trace buffer size ')
> -quit()
> +   print('IO error setting trace buffer size ')
> +   sys.exit(2)
>  
>  def free_trace_buffer():
>  """ Free the trace buffer memory """
> @@ -418,8 +420,8 @@ def free_trace_buffer():
> open('/sys/kernel/debug/tracing/buffer_size_kb'
>   , 'w').write("1")
>  except:
> -print('IO error setting trace buffer size ')
> -quit()
> +print('IO error freeing trace buffer ')
> +sys.exit(2)
>  
>  def read_trace_data(filename):
>  """ Read and parse trace data """
> @@ -431,7 +433,7 @@ def read_trace_data(filename):
>  data = open(filename, 'r').read()
>  except:
>  print('Error opening ', filename)
> -quit()
> +sys.exit(2)
>  
>  for line in data.splitlines():
>  search_obj = \
> @@ -489,10 +491,22 @@ def read_trace_data(filename):
>  # Now seperate the main overall csv file into per CPU csv files.
>  split_csv()
>  
> +def signal_handler(signal, frame):
> +print(' SIGINT: Forcing cleanup before exit.')
> +if interval:
> +disable_trace()
> +clear_trace_file()
> +# Free the memory
> +free_trace_buffer()
> +sys.exit(0)
> +
> +signal.signal(signal.SIGINT, signal_handler)
> +
>  interval = ""
>  filename = ""
>  cpu_list = ""
>  testname = ""
> +memory = "10240"
>  graph_data_present = False;
>  
>  valid1 = False
> @@ -501,7 +515,7 @@ valid2 = False
>  cpu_mask = zeros((MAX_CPUS,), dtype=int)
>  
>  try:
> -opts, args = 
> getopt.getopt(sys.argv[1:],"ht:i:c:n:",["help","trace_file=","interval=","cpu=","name="])
> +opts, args = 
> 

Re: [PATCH] cpufreq: fix speedstep_detect_processor()'s return type

[Rafael J. Wysocki]

On Wednesday, April 25, 2018 4:46:47 AM CEST Viresh Kumar wrote:
> On 24-04-18, 15:14, Luc Van Oostenryck wrote:
> > speedstep_detect_processor() is declared as returing an
> > 'enum speedstep_processor' but use an 'int' in its definition.
> > 
> > Fix this by using 'enum speedstep_processor' in its definition too.
> > 
> > Signed-off-by: Luc Van Oostenryck 
> > ---
> >  drivers/cpufreq/speedstep-lib.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/cpufreq/speedstep-lib.c 
> > b/drivers/cpufreq/speedstep-lib.c
> > index e3a9962ee..cabb6f48e 100644
> > --- a/drivers/cpufreq/speedstep-lib.c
> > +++ b/drivers/cpufreq/speedstep-lib.c
> > @@ -252,7 +252,7 @@ EXPORT_SYMBOL_GPL(speedstep_get_frequency);
> >   */
> >  
> >  /* Keep in sync with the x86_cpu_id tables in the different modules */
> > -unsigned int speedstep_detect_processor(void)
> > +enum speedstep_processor speedstep_detect_processor(void)
> >  {
> > struct cpuinfo_x86 *c = _data(0);
> > u32 ebx, msr_lo, msr_hi;
> 
> Acked-by: Viresh Kumar 
> 
> 

Applied, thanks!

Re: [PATCH] net/mlx4_core: Fix error handling in mlx4_init_port_info.

[Tariq Toukan]

On 02/05/2018 4:31 PM, Tariq Toukan wrote:



On 27/04/2018 6:20 PM, Tarick Bedeir wrote:

Avoid exiting the function with a lingering sysfs file (if the first
call to device_create_file() fails while the second succeeds), and avoid
calling devlink_port_unregister() twice.

In other words, either mlx4_init_port_info() succeeds and returns 
zero, or

it fails, returns non-zero, and requires no cleanup.

Signed-off-by: Tarick Bedeir 
---
  drivers/net/ethernet/mellanox/mlx4/main.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c 
b/drivers/net/ethernet/mellanox/mlx4/main.c

index 4d84cab77105..e8a3a45d0b53 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -3007,6 +3007,7 @@ static int mlx4_init_port_info(struct mlx4_dev 
*dev, int port)

  mlx4_err(dev, "Failed to create file for port %d\n", port);
  devlink_port_unregister(>devlink_port);
  info->port = -1;
+    return err;
  }
  sprintf(info->dev_mtu_name, "mlx4_port%d_mtu", port);
@@ -3028,9 +3029,10 @@ static int mlx4_init_port_info(struct mlx4_dev 
*dev, int port)

 >port_attr);
  devlink_port_unregister(>devlink_port);
  info->port = -1;
+    return err;
  }
-    return err;
+    return 0;
  }
  static void mlx4_cleanup_port_info(struct mlx4_port_info *info)


Acked-by: Tariq Toukan 

Thanks Tarick.


Actually, you need to add a Fixes line:

Fixes: 096335b3f983 ("mlx4_core: Allow dynamic MTU configuration for IB 
ports")

[PATCH] remoteproc: Add APSS based Qualcomm ADSP PIL driver for SDM845

[Rohit kumar]

This adds Qualcomm ADSP PIL driver support for SDM845 with ADSP bootup
and shutdown operation handled from Application Processor SubSystem(APSS).

Signed-off-by: Rohit kumar 
Signed-off-by: RajendraBabu Medisetti 
Signed-off-by: Krishnamurthy Renu 
---
 .../devicetree/bindings/remoteproc/qcom,adsp.txt   |   1 +
 drivers/remoteproc/Makefile|   3 +-
 drivers/remoteproc/qcom_adsp_pil.c | 122 -
 drivers/remoteproc/qcom_adsp_pil.h |  86 ++
 drivers/remoteproc/qcom_adsp_pil_sdm845.c  | 304 +
 5 files changed, 454 insertions(+), 62 deletions(-)
 create mode 100644 drivers/remoteproc/qcom_adsp_pil.h
 create mode 100644 drivers/remoteproc/qcom_adsp_pil_sdm845.c

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt 
b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
index 728e419..a9fe033 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
@@ -10,6 +10,7 @@ on the Qualcomm ADSP Hexagon core.
"qcom,msm8974-adsp-pil"
"qcom,msm8996-adsp-pil"
"qcom,msm8996-slpi-pil"
+   "qcom,sdm845-apss-adsp-pil"
 
 - interrupts-extended:
Usage: required
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 02627ed..759831b 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,7 +14,8 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
 obj-$(CONFIG_KEYSTONE_REMOTEPROC)  += keystone_remoteproc.o
-obj-$(CONFIG_QCOM_ADSP_PIL)+= qcom_adsp_pil.o
+obj-$(CONFIG_QCOM_ADSP_PIL)+= qcom_adsp.o
+qcom_adsp-objs += qcom_adsp_pil.o 
qcom_adsp_pil_sdm845.o
 obj-$(CONFIG_QCOM_RPROC_COMMON)+= qcom_common.o
 obj-$(CONFIG_QCOM_Q6V5_PIL)+= qcom_q6v5_pil.o
 obj-$(CONFIG_QCOM_SYSMON)  += qcom_sysmon.o
diff --git a/drivers/remoteproc/qcom_adsp_pil.c 
b/drivers/remoteproc/qcom_adsp_pil.c
index 89a86ce..9ab3698 100644
--- a/drivers/remoteproc/qcom_adsp_pil.c
+++ b/drivers/remoteproc/qcom_adsp_pil.c
@@ -1,5 +1,5 @@
 /*
- * Qualcomm ADSP/SLPI Peripheral Image Loader for MSM8974 and MSM8996
+ * Qualcomm ADSP/SLPI Peripheral Image Loader for MSM8974, MSM8996 and SDM845.
  *
  * Copyright (C) 2016 Linaro Ltd
  * Copyright (C) 2014 Sony Mobile Communications AB
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -30,56 +29,8 @@
 #include 
 #include 
 
-#include "qcom_common.h"
 #include "remoteproc_internal.h"
-
-struct adsp_data {
-   int crash_reason_smem;
-   const char *firmware_name;
-   int pas_id;
-   bool has_aggre2_clk;
-
-   const char *ssr_name;
-   const char *sysmon_name;
-   int ssctl_id;
-};
-
-struct qcom_adsp {
-   struct device *dev;
-   struct rproc *rproc;
-
-   int wdog_irq;
-   int fatal_irq;
-   int ready_irq;
-   int handover_irq;
-   int stop_ack_irq;
-
-   struct qcom_smem_state *state;
-   unsigned stop_bit;
-
-   struct clk *xo;
-   struct clk *aggre2_clk;
-
-   struct regulator *cx_supply;
-   struct regulator *px_supply;
-
-   int pas_id;
-   int crash_reason_smem;
-   bool has_aggre2_clk;
-
-   struct completion start_done;
-   struct completion stop_done;
-
-   phys_addr_t mem_phys;
-   phys_addr_t mem_reloc;
-   void *mem_region;
-   size_t mem_size;
-
-   struct qcom_rproc_glink glink_subdev;
-   struct qcom_rproc_subdev smd_subdev;
-   struct qcom_rproc_ssr ssr_subdev;
-   struct qcom_sysmon *sysmon;
-};
+#include "qcom_adsp_pil.h"
 
 static int adsp_load(struct rproc *rproc, const struct firmware *fw)
 {
@@ -112,18 +63,32 @@ static int adsp_start(struct rproc *rproc)
if (ret)
goto disable_cx_supply;
 
-   ret = qcom_scm_pas_auth_and_reset(adsp->pas_id);
-   if (ret) {
-   dev_err(adsp->dev,
-   "failed to authenticate image and release reset\n");
-   goto disable_px_supply;
+   if (adsp->is_apss_controlled) {
+   ret = adsp->ops->bringup(adsp);
+   if (ret) {
+   dev_err(adsp->dev, "adsp bringup failed\n");
+   adsp->ops->bringdown(adsp);
+   goto disable_px_supply;
+   }
+   } else {
+   ret = qcom_scm_pas_auth_and_reset(adsp->pas_id);
+   if (ret) {
+   dev_err(adsp->dev,
+   "failed to authenticate image and release 
reset\n");
+   goto 

[GIT PULL] dma mapping fix for 4.17-rc5

[Christoph Hellwig]

Hi Linus,

one trivial dma-mapping regression fix for you.  Note that this has
NOT been in linux-next as I didn't want to disturb the branch in
there which has the 4.18 material.  I've asked Stephen to add the
for-linus branch in addition to for-next so that this doesn't happen
again.  In addition to being entirely trivial I also made sure it
passed the 0-day build bot.

The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb:

  Linux 4.17-rc4 (2018-05-06 16:57:38 -1000)

are available in the Git repository at:

  git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-4.17-5

for you to fetch changes up to 05e13bb57e6f181d7605f8608181c7e6fb7f591d:

  swiotlb: silent unwanted warning "buffer is full" (2018-05-12 11:57:37 +0200)


another dma-mapping fix for 4.17-rc:

 - just one little fix from Jean to avoid a harmless but very annoying
   warning, especially for the drm code


Jean Delvare (1):
  swiotlb: silent unwanted warning "buffer is full"

 lib/swiotlb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: KASAN: null-ptr-deref Write in linear_transfer

[Eric Biggers]

On Wed, Jan 10, 2018 at 10:58:43AM +0100, Takashi Iwai wrote:
> On Wed, 10 Jan 2018 09:08:00 +0100,
> Eric Biggers wrote:
> > 
> > On Fri, Jan 05, 2018 at 02:58:02AM -0800, syzbot wrote:
> > > Hello,
> > > 
> > > syzkaller hit the following crash on
> > > 30a7acd573899fd8b8ac39236eff6468b195ac7d
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > > compiler: gcc (GCC) 7.1.1 20170620
> > > .config is attached
> > > Raw console output is attached.
> > > C reproducer is attached
> > > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > > for information about syzkaller reproducers
> > > 
> > > 
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+a8f5641f452c7e6ab...@syzkaller.appspotmail.com
> > > It will help syzbot understand when the bug is fixed. See footer for
> > > details.
> > > If you forward the report, please keep this part and the footer.
> > > 
> > > ==
> > > BUG: KASAN: null-ptr-deref in memcpy include/linux/string.h:344 [inline]
> > > BUG: KASAN: null-ptr-deref in do_convert sound/core/oss/linear.c:52 
> > > [inline]
> > > BUG: KASAN: null-ptr-deref in convert sound/core/oss/linear.c:81 [inline]
> > > BUG: KASAN: null-ptr-deref in linear_transfer+0x634/0x900
> > > sound/core/oss/linear.c:110
> > > Write of size 2 at addr   (null) by task syzkaller360172/7860
> > > 
> > > CPU: 0 PID: 7860 Comm: syzkaller360172 Not tainted 4.15.0-rc6+ #155
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Call Trace:
> > >  __dump_stack lib/dump_stack.c:17 [inline]
> > >  dump_stack+0x194/0x257 lib/dump_stack.c:53
> > >  kasan_report_error mm/kasan/report.c:349 [inline]
> > >  kasan_report+0x13b/0x340 mm/kasan/report.c:409
> > >  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
> > >  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
> > >  memcpy+0x37/0x50 mm/kasan/kasan.c:303
> > >  memcpy include/linux/string.h:344 [inline]
> > >  do_convert sound/core/oss/linear.c:52 [inline]
> > >  convert sound/core/oss/linear.c:81 [inline]
> > >  linear_transfer+0x634/0x900 sound/core/oss/linear.c:110
> > >  snd_pcm_plug_write_transfer+0x22d/0x420 sound/core/oss/pcm_plugin.c:611
> > >  snd_pcm_oss_write2+0x260/0x420 sound/core/oss/pcm_oss.c:1311
> > >  snd_pcm_oss_sync1+0x1cc/0x550 sound/core/oss/pcm_oss.c:1530
> > >  snd_pcm_oss_sync+0x5b6/0x830 sound/core/oss/pcm_oss.c:1604
> > >  snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431
> > >  __fput+0x327/0x7e0 fs/file_table.c:210
> > >  fput+0x15/0x20 fs/file_table.c:244
> > >  task_work_run+0x199/0x270 kernel/task_work.c:113
> > >  exit_task_work include/linux/task_work.h:22 [inline]
> > >  do_exit+0x9bb/0x1ad0 kernel/exit.c:865
> > >  do_group_exit+0x149/0x400 kernel/exit.c:968
> > >  get_signal+0x73f/0x16c0 kernel/signal.c:2335
> > >  do_signal+0x90/0x1eb0 arch/x86/kernel/signal.c:809
> > >  exit_to_usermode_loop+0x214/0x310 arch/x86/entry/common.c:158
> > >  prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
> > >  syscall_return_slowpath arch/x86/entry/common.c:264 [inline]
> > >  do_syscall_32_irqs_on arch/x86/entry/common.c:333 [inline]
> > >  do_fast_syscall_32+0xbfd/0xf9d arch/x86/entry/common.c:389
> > >  entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:129
> > 
> > Still reproducible even after all the fixes currently in sound/for-linus.
> 
> Interesting, I can't reproduce it on my VM any longer...
> 

No longer occurring, last occurrence was Mar 29 on commit a2601d78b77aa.
Seems to have been fixed by commit 02a5d6925cd3:

#syz fix: ALSA: pcm: Avoid potential races between OSS ioctls and read/write

The reproducer was opening /dev/dsp1, then concurrently writing to it and
calling the SNDCTL_DSP_SPEED ioctl.

- Eric

Re: [PATCH] Documentation/admin-guide/pm/intel_pstate: fix Active Mode w/o HWP paragraph

[Rafael J. Wysocki]

On Tuesday, May 8, 2018 8:36:44 PM CEST Srinivas Pandruvada wrote:
> On Tue, 2018-05-08 at 17:12 +0200, Juri Lelli wrote:
> > P-state selection algorithm (powersave or performance) is selected by
> > echoing the desired choice to scaling_governor sysfs attribute and
> > not
> > to scaling_cur_freq (as currently stated).
> > 
> > Fix it.
> Thanks for the fix.
> 
> > 
> > Signed-off-by: Juri Lelli 
> > Cc: Jonathan Corbet 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Srinivas Pandruvada 
> > Cc: linux-...@vger.kernel.org
> > Cc: linux...@vger.kernel.org
> Reviewed-by: Srinivas Pandruvada 
> 
> 
> > 
> > ---
> >  Documentation/admin-guide/pm/intel_pstate.rst | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/admin-guide/pm/intel_pstate.rst
> > b/Documentation/admin-guide/pm/intel_pstate.rst
> > index d2b6fda3d67b..ab2fe0eda1d7 100644
> > --- a/Documentation/admin-guide/pm/intel_pstate.rst
> > +++ b/Documentation/admin-guide/pm/intel_pstate.rst
> > @@ -145,7 +145,7 @@ feature enabled.]
> >  
> >  In this mode ``intel_pstate`` registers utilization update callbacks
> > with the
> >  CPU scheduler in order to run a P-state selection algorithm, either
> > -``powersave`` or ``performance``, depending on the
> > ``scaling_cur_freq`` policy
> > +``powersave`` or ``performance``, depending on the
> > ``scaling_governor`` policy
> >  setting in ``sysfs``.  The current CPU frequency information to be
> > made
> >  available from the ``scaling_cur_freq`` policy attribute in
> > ``sysfs`` is
> >  periodically updated by those utilization update callbacks too.
> 

Applied and pushed for 4.17-rc5, thanks!

[PATCH 2/2] arm64: Clear the stack

[Alexander Popov]

Hello Mark,

Thanks a lot for your reply!

On 11.05.2018 19:13, Mark Rutland wrote:
> On Fri, May 11, 2018 at 06:50:09PM +0300, Alexander Popov wrote:
>> On 06.05.2018 11:22, Alexander Popov wrote:
>>> On 04.05.2018 14:09, Mark Rutland wrote:
>>> +   stack_left = sp & (THREAD_SIZE - 1);
>>> +   BUG_ON(stack_left < 256 || size >= stack_left - 256);
>>
>> Is this arbitrary, or is there something special about 256?
>>
>> Even if this is arbitrary, can we give it some mnemonic?
>
> It's just a reasonable number. We can introduce a macro for it.

 I'm just not sure I see the point in the offset, given things like
 VMAP_STACK exist. BUG_ON() handling will likely require *more* than 256
 bytes of stack, so it seems superfluous, as we'd be relying on stack
 overflow detection at that point.

 I can see that we should take the CONFIG_SCHED_STACK_END_CHECK offset
 into account, though.
>>>
>>> Mark, thank you for such an important remark!
>>>
>>> In Kconfig STACKLEAK implies but doesn't depend on VMAP_STACK. In fact 
>>> x86_32
>>> doesn't have VMAP_STACK at all but can have STACKLEAK.
>>>
>>> [Adding Andy Lutomirski]
>>>
>>> I've made some additional experiments: I exhaust the thread stack to have 
>>> only
>>> (MIN_STACK_LEFT - 1) bytes left and then force alloca. If VMAP_STACK is
>>> disabled, BUG_ON() handling causes stack depth overflow, which is detected 
>>> by
>>> SCHED_STACK_END_CHECK. If VMAP_STACK is enabled, the kernel hangs on 
>>> BUG_ON()
>>> handling! Enabling CONFIG_PROVE_LOCKING gives the needed report from 
>>> VMAP_STACK:
> 
> I can't see why CONFIG_VMAP_STACK would only work in conjunction with
> CONFIG_PROVE_LOCKING.
> 
> On arm64 at least, if we overflow the stack while handling a BUG(), we
> *should* trigger the overflow handler as usual, and that should work,
> unless I'm missing something.
> 
> Maybe it gets part-way into panic(), sets up some state,
> stack-overflows, and we get wedged because we're already in a panic?
> Perhaps CONFIG_PROVE_LOCKING causes more stack to be used, so it dies a
> little earlier in panic(), before setting up some state that causes
> wedging.

That seems likely. I later noticed that I had oops=panic kernel parameter.

> ... which sounds like something best fixed in those code paths, and not
> here.
> 
>> [...]
>>
>>> I can't say why VMAP_STACK report hangs during BUG_ON() handling on 
>>> defconfig.
>>> Andy, can you give a clue?
>>>
>>> I see that MIN_STACK_LEFT = 2048 is enough for BUG_ON() handling on both 
>>> x86_64
>>> and x86_32. So I'm going to:
>>>  - set MIN_STACK_LEFT to 2048;
>>>  - improve the lkdtm test to cover this case.
>>>
>>> Mark, Kees, Laura, does it sound good?
>>
>>
>> Could you have a look at the following changes in check_alloca() before I 
>> send
>> the next version?
>>
>> If VMAP_STACK is enabled and alloca causes stack depth overflow, I write to
>> guard page below the thread stack to cause double fault and VMAP_STACK 
>> report.
> 
> On arm64 at least, writing to the guard page will not itself trigger a
> stack overflow, but will trigger a data abort. I suspect similar is true
> on x86, if the stack pointer is sufficiently far above the guard page.

Yes, you are right, my mistake.

The comment about CONFIG_VMAP_STACK in arch/x86/kernel/traps.c says:
"If we overflow the stack into a guard page, the CPU will fail to deliver #PF
and will send #DF instead."

>> If VMAP_STACK is disabled, I use MIN_STACK_LEFT = 2048, which seems to be 
>> enough
>> for BUG_ON() handling both on x86_32 and x86_64. Unfortunately, I can't
>> guarantee that it is always enough.
> 
> I don't think that we can choose something that's guaranteed to be
> sufficient for BUG() handling and also not wasting a tonne of space
> under normal operation.
> 
> Let's figure out what's going wrong on x86 in the case that you mention,
> and try to solve that.
> 
> Here I don't think we should reserve space at all -- it's completely
> arbitrary, and as above we can't guarantee that it's sufficient anyway.
> 
>>  #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> -#define MIN_STACK_LEFT 256
>> +#define MIN_STACK_LEFT 2048
>>
>>  void __used check_alloca(unsigned long size)
>>  {
>> unsigned long sp = (unsigned long)
>> struct stack_info stack_info = {0};
>> unsigned long visit_mask = 0;
>> unsigned long stack_left;
>>
>> BUG_ON(get_stack_info(, current, _info, _mask));
>>
>> stack_left = sp - (unsigned long)stack_info.begin;
>> +
>> +#ifdef CONFIG_VMAP_STACK
>> +   /*
>> +* If alloca oversteps the thread stack boundary, we touch the guard
>> +* page provided by VMAP_STACK to trigger handle_stack_overflow().
>> +*/
>> +   if (size >= stack_left)
>> +   *(stack_info.begin - 1) = 42;
>> +#else
> 
> On arm64, this won't trigger our stack overflow handler, unless the SP
> is already very close to the boundary.
> 
> Please just use 

Re: [PATCH] kernel/sched/cpufreq_schedutil: remove stale comment

[Rafael J. Wysocki]

On Wednesday, May 9, 2018 10:41:54 AM CEST Viresh Kumar wrote:
> On 09-05-18, 10:40, Juri Lelli wrote:
> > After commit 794a56ebd9a57 ("sched/cpufreq: Change the worker kthread to
> > SCHED_DEADLINE") schedutil kthreads are "ignored" for a clock frequency
> > selection point of view, so the potential corner case for RT tasks is not
> > possible at all now.
> > 
> > Remove the stale comment mentioning it.
> > 
> > Signed-off-by: Juri Lelli 
> > Cc: Ingo Molnar 
> > Cc: Peter Zijlstra 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Viresh Kumar 
> > Cc: Claudio Scordino 
> > Cc: Luca Abeni 
> > ---
> >  kernel/sched/cpufreq_schedutil.c | 13 -
> >  1 file changed, 13 deletions(-)
> > 
> > diff --git a/kernel/sched/cpufreq_schedutil.c 
> > b/kernel/sched/cpufreq_schedutil.c
> > index d2c6083304b4..23ef19070137 100644
> > --- a/kernel/sched/cpufreq_schedutil.c
> > +++ b/kernel/sched/cpufreq_schedutil.c
> > @@ -396,19 +396,6 @@ static void sugov_irq_work(struct irq_work *irq_work)
> >  
> > sg_policy = container_of(irq_work, struct sugov_policy, irq_work);
> >  
> > -   /*
> > -* For RT tasks, the schedutil governor shoots the frequency to maximum.
> > -* Special care must be taken to ensure that this kthread doesn't result
> > -* in the same behavior.
> > -*
> > -* This is (mostly) guaranteed by the work_in_progress flag. The flag is
> > -* updated only at the end of the sugov_work() function and before that
> > -* the schedutil governor rejects all other frequency scaling requests.
> > -*
> > -* There is a very rare case though, where the RT thread yields right
> > -* after the work_in_progress flag is cleared. The effects of that are
> > -* neglected for now.
> > -*/
> > kthread_queue_work(_policy->worker, _policy->work);
> >  }
> 
> Acked-by: Viresh Kumar 

Applied and pushed for 4.17-rc5.

Re: [PATCH] PM: docs: sleep-states: Fix a typo ("includig")

[Rafael J. Wysocki]

On Wednesday, April 25, 2018 12:07:03 PM CEST Jonathan Neuschäfer wrote:
> Signed-off-by: Jonathan Neuschäfer 
> ---
>  Documentation/admin-guide/pm/sleep-states.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/admin-guide/pm/sleep-states.rst 
> b/Documentation/admin-guide/pm/sleep-states.rst
> index 1e5c0f00cb2f..dbf5acd49f35 100644
> --- a/Documentation/admin-guide/pm/sleep-states.rst
> +++ b/Documentation/admin-guide/pm/sleep-states.rst
> @@ -15,7 +15,7 @@ Sleep States That Can Be Supported
>  ==
>  
>  Depending on its configuration and the capabilities of the platform it runs 
> on,
> -the Linux kernel can support up to four system sleep states, includig
> +the Linux kernel can support up to four system sleep states, including
>  hibernation and up to three variants of system suspend.  The sleep states 
> that
>  can be supported by the kernel are listed below.
>  
> 

Applied and pushed for 4.17-rc5, thanks!

Re: KASAN: use-after-free Read in corrupted

[Dmitry Vyukov]

On Sun, May 13, 2018 at 10:56 AM, syzbot
 wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:427fbe89261d Merge branch 'next' of git://git.kernel.org/p..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=148eb01780
> kernel config:  https://syzkaller.appspot.com/x/.config?x=fcce42b221691ff9
> dashboard link: https://syzkaller.appspot.com/bug?extid=3417712847e7219a60ee
> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1770c47780
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ecdbc780
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3417712847e7219a6...@syzkaller.appspotmail.com

Tetsuo,

This looks very similar to "KASAN: use-after-free Read in fuse_kill_sb_blk":
https://groups.google.com/d/msg/syzkaller-bugs/4C4oiBX8vZ0/0NTQRcUYBgAJ

which you fixed with "fuse: don't keep dead fuse_conn at fuse_fill_super().":
https://groups.google.com/d/msg/syzkaller-bugs/4C4oiBX8vZ0/W6pi8NdbBgAJ

However, here we have use-after-free in fuse_kill_sb_anon instead of
use_kill_sb_blk. Do you think your patch will fix this as well?



> R13:  R14:  R15: 
> CPU: 0 PID: 4564 Comm: syz-executor214 Not tainted 4.17.0-rc4+ #44
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> ==
> Call Trace:
> BUG: KASAN: use-after-free in __lock_acquire+0x3888/0x5140
> kernel/locking/lockdep.c:3310
> Read of size 8 at addr 8801d8d69088 by task syz-executor214/4551
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>
>  fail_dump lib/fault-inject.c:51 [inline]
>  should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
>  __should_failslab+0x124/0x180 mm/failslab.c:32
>  should_failslab+0x9/0x14 mm/slab_common.c:1522
>  slab_pre_alloc_hook mm/slab.h:423 [inline]
>  slab_alloc mm/slab.c:3378 [inline]
>  kmem_cache_alloc+0x2af/0x760 mm/slab.c:3552
>  __d_alloc+0xc0/0xd30 fs/dcache.c:1638
>  d_alloc_anon fs/dcache.c:1742 [inline]
>  d_make_root+0x42/0x90 fs/dcache.c:1934
>  fuse_fill_super+0x120e/0x1e20 fs/fuse/inode.c:1131
>  mount_nodev+0x6b/0x110 fs/super.c:1210
>  fuse_mount+0x2c/0x40 fs/fuse/inode.c:1192
>  mount_fs+0xae/0x328 fs/super.c:1267
>  vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037
>  vfs_kern_mount fs/namespace.c:1027 [inline]
>  do_new_mount fs/namespace.c:2518 [inline]
>  do_mount+0x564/0x3070 fs/namespace.c:2848
>  ksys_mount+0x12d/0x140 fs/namespace.c:3064
>  __do_sys_mount fs/namespace.c:3078 [inline]
>  __se_sys_mount fs/namespace.c:3075 [inline]
>  __x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x447cb9
> RSP: 002b:7f7a75bca918 EFLAGS: 0246 ORIG_RAX: 00a5
> RAX: ffda RBX: 0005 RCX: 00447cb9
> RDX: 004b08d6 RSI: 2340 RDI: 004c7485
> RBP: a001 R08: 7f7a75bca930 R09: 
> R10:  R11: 0246 R12: 
> R13:  R14:  R15: 
> CPU: 1 PID: 4551 Comm: syz-executor214 Not tainted 4.17.0-rc4+ #44
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> FAULT_INJECTION: forcing a failure.
> name failslab, interval 1, probability 0, space 0, times 0
>  print_address_description+0x6c/0x20b mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>  __lock_acquire+0x3888/0x5140 kernel/locking/lockdep.c:3310
>  lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3920
>  down_write+0x87/0x120 kernel/locking/rwsem.c:70
>  fuse_kill_sb_anon+0x50/0xb0 fs/fuse/inode.c:1200
>  deactivate_locked_super+0x97/0x100 fs/super.c:316
>  mount_nodev+0xfa/0x110 fs/super.c:1212
>  fuse_mount+0x2c/0x40 fs/fuse/inode.c:1192
>  mount_fs+0xae/0x328 fs/super.c:1267
>  vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037
>  vfs_kern_mount fs/namespace.c:1027 [inline]
>  do_new_mount fs/namespace.c:2518 [inline]
>  do_mount+0x564/0x3070 fs/namespace.c:2848
>  ksys_mount+0x12d/0x140 fs/namespace.c:3064
>  __do_sys_mount fs/namespace.c:3078 [inline]
>  __se_sys_mount fs/namespace.c:3075 [inline]
>  __x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x447cb9
> RSP: 002b:7f7a75bca918 EFLAGS: 0246 ORIG_RAX: 

Re: [PATCH V2] mlx4_core: allocate ICM memory in page size chunks

[Tariq Toukan]

On 11/05/2018 10:23 PM, Qing Huang wrote:

When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk allocations will likely trigger kernel
memory management to enter slow path doing memory compact/migration
ops in order to complete high order memory allocations.

When that happens, user processes calling uverb APIs may get stuck
for more than 120s easily even though there are a lot of free pages
in smaller chunks available in the system.

Syslog:
...
Dec 10 09:04:51 slcc03db02 kernel: [397078.572732] INFO: task
oracle_205573_e:205573 blocked for more than 120 seconds.
...

With 4KB ICM chunk size on x86_64 arch, the above issue is fixed.

However in order to support smaller ICM chunk size, we need to fix
another issue in large size kcalloc allocations.

E.g.
Setting log_num_mtt=30 requires 1G mtt entries. With the 4KB ICM chunk
size, each ICM chunk can only hold 512 mtt entries (8 bytes for each mtt
entry). So we need a 16MB allocation for a table->icm pointer array to
hold 2M pointers which can easily cause kcalloc to fail.

The solution is to use vzalloc to replace kcalloc. There is no need
for contiguous memory pages for a driver meta data structure (no need
of DMA ops).

Signed-off-by: Qing Huang 
Acked-by: Daniel Jurgens 
Reviewed-by: Zhu Yanjun 
---
v2 -> v1: adjusted chunk size to reflect different architectures.

  drivers/net/ethernet/mellanox/mlx4/icm.c | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c 
b/drivers/net/ethernet/mellanox/mlx4/icm.c
index a822f7a..ccb62b8 100644
--- a/drivers/net/ethernet/mellanox/mlx4/icm.c
+++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
@@ -43,12 +43,12 @@
  #include "fw.h"
  
  /*

- * We allocate in as big chunks as we can, up to a maximum of 256 KB
- * per chunk.
+ * We allocate in page size (default 4KB on many archs) chunks to avoid high
+ * order memory allocations in fragmented/high usage memory situation.
   */
  enum {
-   MLX4_ICM_ALLOC_SIZE = 1 << 18,
-   MLX4_TABLE_CHUNK_SIZE   = 1 << 18
+   MLX4_ICM_ALLOC_SIZE = 1 << PAGE_SHIFT,
+   MLX4_TABLE_CHUNK_SIZE   = 1 << PAGE_SHIFT


Which is actually PAGE_SIZE.
Also, please add a comma at the end of the last entry.


  };
  
  static void mlx4_free_icm_pages(struct mlx4_dev *dev, struct mlx4_icm_chunk *chunk)

@@ -400,7 +400,7 @@ int mlx4_init_icm_table(struct mlx4_dev *dev, struct 
mlx4_icm_table *table,
obj_per_chunk = MLX4_TABLE_CHUNK_SIZE / obj_size;
num_icm = (nobj + obj_per_chunk - 1) / obj_per_chunk;
  
-	table->icm  = kcalloc(num_icm, sizeof(*table->icm), GFP_KERNEL);

+   table->icm  = vzalloc(num_icm * sizeof(*table->icm));


Why not kvzalloc ?


if (!table->icm)
return -ENOMEM;
table->virt = virt;
@@ -446,7 +446,7 @@ int mlx4_init_icm_table(struct mlx4_dev *dev, struct 
mlx4_icm_table *table,
mlx4_free_icm(dev, table->icm[i], use_coherent);
}
  
-	kfree(table->icm);

+   vfree(table->icm);
  
  	return -ENOMEM;

  }
@@ -462,5 +462,5 @@ void mlx4_cleanup_icm_table(struct mlx4_dev *dev, struct 
mlx4_icm_table *table)
mlx4_free_icm(dev, table->icm[i], table->coherent);
}
  
-	kfree(table->icm);

+   vfree(table->icm);
  }



Thanks for your patch.

I need to verify there is no dramatic performance degradation here.
You can prepare and send a v3 in the meanwhile.

Thanks,
Tariq

Re: [PATCH v2] x86/io: Define readq()/writeq() to use 64-bit type

[Thomas Gleixner]

On Thu, 3 May 2018, Andy Shevchenko wrote:
>  #ifdef CONFIG_X86_64
>  
> -build_mmio_read(readq, "q", unsigned long, "=r", :"memory")
> -build_mmio_read(__readq, "q", unsigned long, "=r", )
> -build_mmio_write(writeq, "q", unsigned long, "r", :"memory")
> -build_mmio_write(__writeq, "q", unsigned long, "r", )
> +build_mmio_read(readq, "q", unsigned long long, "=r", :"memory")
> +build_mmio_read(__readq, "q", unsigned long long, "=r", )
> +build_mmio_write(writeq, "q", unsigned long long, "r", :"memory")
> +build_mmio_write(__writeq, "q", unsigned long long, "r", )

What's wrong with u64 which we use for expressing io access to a 64bit wide
resource?

Thanks,

tglx

[tip:x86/cleanups] x86/early-quirks: Rename duplicate define of dev_err

[tip-bot for Joe Perches]

Commit-ID:  a7a3153a98d581196ce092e0b83cac2c4ee1fd1f
Gitweb: https://git.kernel.org/tip/a7a3153a98d581196ce092e0b83cac2c4ee1fd1f
Author: Joe Perches 
AuthorDate: Wed, 9 May 2018 08:15:45 -0700
Committer:  Thomas Gleixner 
CommitDate: Sun, 13 May 2018 20:04:35 +0200

x86/early-quirks: Rename duplicate define of dev_err

dev_err is becoming a macro calling _dev_err to allow prefixing of
dev_fmt to any dev_ use that has a #define dev_fmt(fmt) similar
to the existing #define pr_fmt(fmt) uses.

Remove this dev_err macro and convert the existing two uses to pr_err.
This allows clean compilation in the patch that introduces dev_fmt which
can prefix dev_ logging macros with arbitrary content similar to
the #define pr_fmt macro.

Signed-off-by: Joe Perches 
Signed-off-by: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Link: 
https://lkml.kernel.org/r/8fb4b2a77d50e21ae1f7e4e267e68691efe2c270.1525878372.git@perches.com

---
 arch/x86/kernel/early-quirks.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index bae0d32e327b..da5d8ac60062 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -28,8 +28,6 @@
 #include 
 #include 
 
-#define dev_err(msg)  pr_err("pci :%02x:%02x.%d: %s", bus, slot, func, msg)
-
 static void __init fix_hypertransport_config(int num, int slot, int func)
 {
u32 htcfg;
@@ -617,7 +615,8 @@ static void __init apple_airport_reset(int bus, int slot, 
int func)
 
pmcsr = read_pci_config_16(bus, slot, func, BCM4331_PM_CAP + 
PCI_PM_CTRL);
if ((pmcsr & PCI_PM_CTRL_STATE_MASK) != PCI_D0) {
-   dev_err("Cannot power up Apple AirPort card\n");
+   pr_err("pci :%02x:%02x.%d: Cannot power up Apple 
AirPort card\n",
+  bus, slot, func);
return;
}
}
@@ -628,7 +627,8 @@ static void __init apple_airport_reset(int bus, int slot, 
int func)
 
mmio = early_ioremap(addr, BCM4331_MMIO_SIZE);
if (!mmio) {
-   dev_err("Cannot iomap Apple AirPort card\n");
+   pr_err("pci :%02x:%02x.%d: Cannot iomap Apple AirPort 
card\n",
+  bus, slot, func);
return;
}
 

[PATCH] libata: Apply NOLPM quirk for SAMSUNG PM830 CXM13D1Q.

[fcami]

From: François Cami 

Without this patch the drive errors out regularly:

[1.090154] ata1.00: ATA-8: SAMSUNG SSD PM830 mSATA 256GB,
CXM13D1Q, max UDMA/133
(...)
[  345.154996] ata1.00: exception Emask 0x40 SAct 0x0 SErr 0xc0800 action 0x6
[  345.155006] ata1.00: irq_stat 0x4001
[  345.155013] ata1: SError: { HostInt CommWake 10B8B }
[  345.155018] ata1.00: failed command: SET FEATURES
[  345.155032] ata1.00: cmd ef/05:e1:00:00:00/00:00:00:00:00/40 tag 7
res 51/04:e1:00:00:00/00:00:00:00:00/40 Emask 0x41 
(internal error)
[  345.155038] ata1.00: status: { DRDY ERR }
[  345.155042] ata1.00: error: { ABRT }
[  345.155051] ata1: hard resetting link
[  345.465661] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[  345.466955] ata1.00: configured for UDMA/133
[  345.467085] ata1: EH complete

Signed-off-by: François Cami 
Acked-by: Hans de Goede 
---
 drivers/ata/libata-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 68596bd4cf06..1ca365f13040 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4549,8 +4549,9 @@ static const struct ata_blacklist_entry 
ata_device_blacklist [] = {
ATA_HORKAGE_ZERO_AFTER_TRIM |
ATA_HORKAGE_NOLPM, },
 
-   /* This specific Samsung model/firmware-rev does not handle LPM well */
+   /* These specific Samsung models/firmware-revs do not handle LPM well */
{ "SAMSUNG MZMPC128HBFU-000MV", "CXM14M1Q", ATA_HORKAGE_NOLPM, },
+   { "SAMSUNG SSD PM830 mSATA *",  "CXM13D1Q", ATA_HORKAGE_NOLPM, },
 
/* Sandisk devices which are known to not handle LPM well */
{ "SanDisk SD7UB3Q*G1001",  NULL,   ATA_HORKAGE_NOLPM, },
-- 
2.17.0

Re: [PATCH 2/3] arm64: dts: renesas: r8a77995: Add VIN4

[jacopo mondi]

Hi Simon,

On Fri, May 11, 2018 at 03:45:16PM +0200, Simon Horman wrote:
> On Fri, May 11, 2018 at 01:25:23PM +0200, Niklas Söderlund wrote:
> > Hi Jacopo,
> > 
> > Thanks for your work.
> > 
> > On 2018-05-11 12:00:01 +0200, Jacopo Mondi wrote:
> > > Describe VIN4 interface for R-Car D3 R8A77995 SoC.
> > > 
> > > Signed-off-by: Jacopo Mondi 
> > 
> > Acked-by: Niklas Söderlund 
> > 
> > > ---
> > >  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 +++
> > >  1 file changed, 11 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
> > > b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > > index 82aed7e..bdf7017 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > > @@ -783,6 +783,17 @@
> > >   };
> > >   };
> > >   };
> > > +
> > > + vin4: video@e6ef4000 {
> > > + compatible = "renesas,vin-r8a77995";
> > > + reg = <0 0xe6ef4000 0 0x1000>;
> > > + interrupts = ;
> > > + clocks = < CPG_MOD 807>;
> > > + power-domains = < R8A77995_PD_ALWAYS_ON>;
> > > + resets = < 807>;
> > > + renesas,id = <4>;
> > > + status = "disabled";
> > > + };
> > >   };
> 
> Thanks, I have moved the new node to preserve sorting of nodes by bus
> address and applied the result. It is as follows:

Great, thanks for doing this, I should have take care of sorting nodes
opprtunely.

Thanks
   j

> 
> From: Jacopo Mondi 
> Subject: [PATCH] arm64: dts: renesas: r8a77995: Add VIN4
> 
> Describe VIN4 interface for R-Car D3 R8A77995 SoC.
> 
> Signed-off-by: Jacopo Mondi 
> Acked-by: Niklas Söderlund 
> [simon: sorted node by bus address]
> Signed-off-by: Simon Horman 
> ---
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> index ba98865b0c9b..2506f46293e8 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -610,6 +610,17 @@
>   status = "disabled";
>   };
s  
> + vin4: video@e6ef4000 {
> + compatible = "renesas,vin-r8a77995";
> + reg = <0 0xe6ef4000 0 0x1000>;
> + interrupts = ;
> + clocks = < CPG_MOD 807>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 807>;
> + renesas,id = <4>;
> + status = "disabled";
> + };
> +
>   ohci0: usb@ee08 {
>   compatible = "generic-ohci";
>   reg = <0 0xee08 0 0x100>;
> -- 
> 2.11.0
> 

Re: WARNING in dev_vprintk_emit

[Eric Biggers]

[+MAC80211 list and maintainer]

On Wed, Jan 17, 2018 at 05:58:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> c92a9a461dff6140c539c61e457aa97df29517d6
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e64565577af34b376...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> WARNING: CPU: 1 PID: 3652 at drivers/base/core.c:2884 create_syslog_header
> drivers/base/core.c:2884 [inline]
> WARNING: CPU: 1 PID: 3652 at drivers/base/core.c:2884
> dev_vprintk_emit+0x159/0x510 drivers/base/core.c:2894
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 1 PID: 3652 Comm: syzkaller376059 Not tainted 4.15.0-rc7+ #260
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  panic+0x1e4/0x41c kernel/panic.c:183
>  __warn+0x1dc/0x200 kernel/panic.c:547
>  report_bug+0x211/0x2d0 lib/bug.c:184
>  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
>  fixup_bug arch/x86/kernel/traps.c:247 [inline]
>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
> RIP: 0010:create_syslog_header drivers/base/core.c:2884 [inline]
> RIP: 0010:dev_vprintk_emit+0x159/0x510 drivers/base/core.c:2894
> RSP: 0018:8801bc40ee68 EFLAGS: 00010286
> RAX: dc08 RBX: 8801bc080980 RCX: 8159da9e
> RDX:  RSI: 1100378f9d2d RDI: 0293
> RBP: 8801bc40efa8 R08: 110037881d60 R09: 
> R10: 8801bc40f090 R11:  R12: 110037881dd4
> R13: 8801d472c400 R14: 8801bc40eec0 R15: 8801bc40efe0
>  dev_printk_emit+0xc0/0xf0 drivers/base/core.c:2907
>  __dev_printk+0xa7/0x120 drivers/base/core.c:2919
>  dev_printk+0x111/0x170 drivers/base/core.c:2936
>  ieee80211_init_rate_ctrl_alg+0x2d5/0x4a0 net/mac80211/rate.c:978
>  ieee80211_register_hw+0x1448/0x3100 net/mac80211/main.c:1091
>  mac80211_hwsim_new_radio+0x1b2e/0x2b90
> drivers/net/wireless/mac80211_hwsim.c:2700
>  hwsim_new_radio_nl+0x5b7/0x7c0 drivers/net/wireless/mac80211_hwsim.c:3152
>  genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:599
>  genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
>  netlink_rcv_skb+0x224/0x470 net/netlink/af_netlink.c:2408
>  genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
>  netlink_unicast_kernel net/netlink/af_netlink.c:1275 [inline]
>  netlink_unicast+0x4ee/0x700 net/netlink/af_netlink.c:1301
>  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1864
>  sock_sendmsg_nosec net/socket.c:638 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:648
>  ___sys_sendmsg+0x767/0x8b0 net/socket.c:2028
>  __sys_sendmsg+0xe5/0x210 net/socket.c:2062
>  SYSC_sendmsg net/socket.c:2073 [inline]
>  SyS_sendmsg+0x2d/0x50 net/socket.c:2069
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x43fd89
> RSP: 002b:7ffe0ab23e98 EFLAGS: 0203 ORIG_RAX: 002e
> RAX: ffda RBX: 004002c8 RCX: 0043fd89
> RDX:  RSI: 20b3dfc8 RDI: 0003
> RBP: 006ca018 R08:  R09: 
> R10:  R11: 0203 R12: 004016f0
> R13: 00401780 R14:  R15: 
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.

The bug is that mac80211_hwsim allows creating device names that are too long,
via HWSIM_CMD_NEW_RADIO.  Commit a7cfebcb7594a2 

Re: [tip/core/rcu,16/21] rcu: Add funnel locking to rcu_start_this_gp()

[Paul E. McKenney]

On Sun, May 13, 2018 at 09:49:53AM -0700, Joel Fernandes wrote:
> On Sun, May 13, 2018 at 08:38:42AM -0700, Paul E. McKenney wrote:
> > On Sat, May 12, 2018 at 04:53:01PM -0700, Joel Fernandes wrote:
> > > On Sat, May 12, 2018 at 07:44:38AM -0700, Paul E. McKenney wrote:
> > > > On Sat, May 12, 2018 at 07:40:02AM -0700, Paul E. McKenney wrote:
> > > > > On Fri, May 11, 2018 at 11:03:25PM -0700, Joel Fernandes wrote:
> > > > > > On Sun, Apr 22, 2018 at 08:03:39PM -0700, Paul E. McKenney wrote:
> > > > > > > The rcu_start_this_gp() function had a simple form of funnel 
> > > > > > > locking that
> > > > > > > used only the leaves and root of the rcu_node tree, which is fine 
> > > > > > > for
> > > > > > > systems with only a few hundred CPUs, but sub-optimal for systems 
> > > > > > > having
> > > > > > > thousands of CPUs.  This commit therefore adds full-tree funnel 
> > > > > > > locking.
> > > > > > > 
> > > > > > > This variant of funnel locking is unusual in the following ways:
> > > > > > > 
> > > > > > > 1.The leaf-level rcu_node structure's ->lock is held 
> > > > > > > throughout.
> > > > > > >   Other funnel-locking implementations drop the leaf-level lock
> > > > > > >   before progressing to the next level of the tree.
> > > > > > > 
> > > > > > > 2.Funnel locking can be started at the root, which is 
> > > > > > > convenient
> > > > > > >   for code that already holds the root rcu_node structure's 
> > > > > > > ->lock.
> > > > > > >   Other funnel-locking implementations start at the leaves.
> > > > > > > 
> > > > > > > 3.If an rcu_node structure other than the initial one 
> > > > > > > believes
> > > > > > >   that a grace period is in progress, it is not necessary to
> > > > > > >   go further up the tree.  This is because grace-period cleanup
> > > > > > >   scans the full tree, so that marking the need for a subsequent
> > > > > > >   grace period anywhere in the tree suffices -- but only if
> > > > > > >   a grace period is currently in progress.
> > > > > > > 
> > > > > > > 4.It is possible that the RCU grace-period kthread has 
> > > > > > > not yet
> > > > > > >   started, and this case must be handled appropriately.
> > > > > > > 
> > > > > > > However, the general approach of using a tree to control lock 
> > > > > > > contention
> > > > > > > is still in place.
> > > > > > > 
> > > > > > > Signed-off-by: Paul E. McKenney 
> > > > > > > ---
> > > > > > >  kernel/rcu/tree.c | 92 
> > > > > > > +--
> > > > > > >  1 file changed, 35 insertions(+), 57 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > > > > > index 94519c7d552f..d3c769502929 100644
> > > > > > > --- a/kernel/rcu/tree.c
> > > > > > > +++ b/kernel/rcu/tree.c
> > > > > > > @@ -1682,74 +1682,52 @@ static bool rcu_start_this_gp(struct 
> > > > > > > rcu_node *rnp, struct rcu_data *rdp,
> > > > > > >  {
> > > > > > >   bool ret = false;
> > > > > > >   struct rcu_state *rsp = rdp->rsp;
> > > > > > > - struct rcu_node *rnp_root = rcu_get_root(rsp);
> > > > > > > -
> > > > > > > - raw_lockdep_assert_held_rcu_node(rnp);
> > > > > > > -
> > > > > > > - /* If the specified GP is already known needed, return to 
> > > > > > > caller. */
> > > > > > > - trace_rcu_this_gp(rnp, rdp, c, TPS("Startleaf"));
> > > > > > > - if (need_future_gp_element(rnp, c)) {
> > > > > > > - trace_rcu_this_gp(rnp, rdp, c, TPS("Prestartleaf"));
> > > > > > > - goto out;
> > > > > > > - }
> > > > > > > + struct rcu_node *rnp_root;
> > > > > > >  
> > > > > > >   /*
> > > > > > > -  * If this rcu_node structure believes that a grace period is in
> > > > > > > -  * progress, then we must wait for the one following, which is 
> > > > > > > in
> > > > > > > -  * "c".  Because our request will be noticed at the end of the
> > > > > > > -  * current grace period, we don't need to explicitly start one.
> > > > > > > +  * Use funnel locking to either acquire the root rcu_node
> > > > > > > +  * structure's lock or bail out if the need for this grace 
> > > > > > > period
> > > > > > > +  * has already been recorded -- or has already started.  If 
> > > > > > > there
> > > > > > > +  * is already a grace period in progress in a non-leaf node, no
> > > > > > > +  * recording is needed because the end of the grace period will
> > > > > > > +  * scan the leaf rcu_node structures.  Note that rnp->lock must
> > > > > > > +  * not be released.
> > > > > > >*/
> > > > > > > - if (rnp->gpnum != rnp->completed) {
> > > > > > > - need_future_gp_element(rnp, c) = true;
> > > > > > > - trace_rcu_this_gp(rnp, rdp, c, TPS("Startedleaf"));
> > > > > > > - goto out;
> > > > > > 
> > > > > > Referring to the above negative diff as [1] (which I wanted to 
> > > > > > refer to later
> > > > > > in this message..)
> > > > > > 
> > > > > > > + raw_lockdep_assert_held_rcu_node(rnp);

Re: general protection fault in rdma_addr_size

[Eric Biggers]

On Fri, Mar 23, 2018 at 01:01:02PM -0700, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> 8f5fd927c3a7576d57248a2d7a0861c3f2795973 (Fri Mar 16 20:37:42 2018 +)
> Merge tag 'for-4.16-rc5-tag' of
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=2a2c48fc189ed5125b9c
> 
> So far this crash happened 2 times on upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> .config is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+2a2c48fc189ed5125...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1521277737.761:7): avc:  denied  { map } for
> pid=4234 comm="syzkaller098821" path="/root/syzkaller098821515" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 4236 Comm: syzkaller098821 Not tainted 4.16.0-rc5+ #357
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:rdma_addr_size+0x1e/0x70 drivers/infiniband/core/addr.c:197
> RSP: 0018:8801b9cc7870 EFLAGS: 00010202
> RAX: dc00 RBX: 0020 RCX: 841374bd
> RDX: 0004 RSI:  RDI: 0020
> RBP: 8801b9cc7878 R08: ed0037398f3a R09: 8801b9cc78c0
> R10: 0022 R11: ed0037398f39 R12: 8801b9cc78c0
> R13: 8801b260a1f0 R14: 8801b9cc7a00 R15: 0020
> FS:  7fd9212b2700() GS:8801db20() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7fd9212b1e78 CR3: 0001b7af4006 CR4: 001606f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  ucma_query_addr.isra.7+0xce/0x4f0 drivers/infiniband/core/ucma.c:871
>  ucma_query+0x1bb/0x230 drivers/infiniband/core/ucma.c:991
>  ucma_write+0x2d6/0x3d0 drivers/infiniband/core/ucma.c:1633
>  __vfs_write+0xef/0x970 fs/read_write.c:480
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:581
>  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x445959
> RSP: 002b:7fd9212b1da8 EFLAGS: 0297 ORIG_RAX: 0001
> RAX: ffda RBX: 006dac5c RCX: 00445959
> RDX: 0018 RSI: 200022c0 RDI: 0003
> RBP: 006dac58 R08:  R09: 
> R10:  R11: 0297 R12: 006d635f616d6472
> R13: 2f646e6162696e69 R14: 666e692f7665642f R15: 0008
> Code: 29 e4 95 fd e9 f8 fe ff ff 90 90 90 90 55 48 89 e5 53 48 89 fb e8 e3
> a2 5d fd 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <0f> b6 14 02 48
> 89 d8 83 e0 07 83 c0 01 38 d0 7c 04 84 d2 75 2f
> RIP: rdma_addr_size+0x1e/0x70 drivers/infiniband/core/addr.c:197 RSP:
> 8801b9cc7870
> ---[ end trace 6c753cc522bb59ed ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title

This seems to have been fixed by commit e8980d67d6017:

#syz fix: RDMA/ucma: Ensure that CM_ID exists prior to access it

- Eric

[PATCH] net: ipv4: ipconfig: fix unused variable

[Anders Roxell]

When CONFIG_PROC_FS isn't set, variable ipconfig_dir isn't used.
net/ipv4/ipconfig.c:167:31: warning: ‘ipconfig_dir’ defined but not used 
[-Wunused-variable]
 static struct proc_dir_entry *ipconfig_dir;
   ^~~~
Move the declaration of ipconfig_dir inside the CONFIG_PROC_FS ifdef to
fix the warning.

Fixes: c04d2cb2009f ("ipconfig: Write NTP server IPs to 
/proc/net/ipconfig/ntp_servers")
Signed-off-by: Anders Roxell 
---
 net/ipv4/ipconfig.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index d839d74853fc..86c9f755de3d 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -163,9 +163,6 @@ static u8 ic_domain[64];/* DNS (not NIS) domain 
name */
  * Private state.
  */
 
-/* proc_dir_entry for /proc/net/ipconfig */
-static struct proc_dir_entry *ipconfig_dir;
-
 /* Name of user-selected boot device */
 static char user_dev_name[IFNAMSIZ] __initdata = { 0, };
 
@@ -1292,6 +1289,8 @@ static int __init ic_dynamic(void)
 #endif /* IPCONFIG_DYNAMIC */
 
 #ifdef CONFIG_PROC_FS
+/* proc_dir_entry for /proc/net/ipconfig */
+static struct proc_dir_entry *ipconfig_dir;
 
 /* Name servers: */
 static int pnp_seq_show(struct seq_file *seq, void *v)
-- 
2.17.0

Re: [PATCH 6/8] serial: Add Tegra Combined UART driver

[Mikko Perttunen]

On 05/13/2018 05:16 PM, Andy Shevchenko wrote:

On Tue, May 8, 2018 at 2:44 PM, Mikko Perttunen  wrote:

The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows
multiplexing multiple "virtual UARTs" into a single hardware serial
port. The TCU is the primary serial port on Tegra194 devices.

Add a TCU driver utilizing the mailbox framework, as the used mailboxes
are part of Tegra HSP blocks that are already controlled by the Tegra
HSP mailbox driver.


First question, can it be done utilizing SERDEV framework?


Based on some brief research, the SERDEV framework is for devices that 
are behind some UART interface. In this case, this driver implements the 
UART interface itself, so by my understanding SERDEV is not appropriate. 
Please correct me if I'm wrong.





+static void tegra_tcu_uart_set_mctrl(struct uart_port *port, unsigned int 
mctrl)
+{



+   (void)port;
+   (void)mctrl;


Huh?


The serial core calls these callbacks without checking if they are set. 
They don't make sense for this driver so they are stubbed out.





+}



+static void tegra_tcu_uart_stop_tx(struct uart_port *port)
+{
+   (void)port;
+}


Ditto.


+   if (written == 3) {
+   value |= 3 << 24;
+   value |= BIT(26);
+   mbox_send_message(tcu->tx, );



+   }


(1)


+   }
+
+   if (written) {
+   value |= written << 24;
+   value |= BIT(26);
+   mbox_send_message(tcu->tx, );
+   }


(2)

These are code duplications.


Indeed - the length of the duplicated code is so short, and the 
instances are so close to each other, that I don't find it necessary (or 
clearer) to have an extra function.





+static void tegra_tcu_uart_stop_rx(struct uart_port *port)
+{
+   (void)port;
+}
+
+static void tegra_tcu_uart_break_ctl(struct uart_port *port, int ctl)
+{
+   (void)port;
+   (void)ctl;
+}
+
+static int tegra_tcu_uart_startup(struct uart_port *port)
+{
+   (void)port;
+
+   return 0;
+}
+
+static void tegra_tcu_uart_shutdown(struct uart_port *port)
+{
+   (void)port;
+}
+
+static void tegra_tcu_uart_set_termios(struct uart_port *port,
+  struct ktermios *new,
+  struct ktermios *old)
+{
+   (void)port;
+   (void)new;
+   (void)old;
+}


Remove those unused stub contents.


Sure. I had these here so that we don't get unused parameter warnings, 
but I can just as well remove the parameter names.





+   return uart_set_options(_tcu_uart_port, cons,
+   115200, 'n', 8, 'n');


Can't it be one line?


It would be a total of 81 characters in length on one line, so no.




+static void tegra_tcu_receive(struct mbox_client *client, void *msg_p)
+{
+   struct tty_port *port = _tcu_uart_port.state->port;



+   uint32_t msg = *(uint32_t *)msg_p;


Redundant casting.


Will remove.




+   unsigned int num_bytes;
+   int i;
+



+   num_bytes = (msg >> 24) & 0x3;


Two magic numbers.


Sure, will add defines.




+   for (i = 0; i < num_bytes; i++)
+   tty_insert_flip_char(port, (msg >> (i*8)) & 0xff, TTY_NORMAL);
+
+   tty_flip_buffer_push(port);
+}



+MODULE_AUTHOR("Mikko Perttunen ");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("NVIDIA Tegra Combined UART driver");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index dce5f9dae121..eaf3c303cba6 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -281,4 +281,7 @@
  /* MediaTek BTIF */
  #define PORT_MTK_BTIF  117

+/* NVIDIA Tegra Combined UART */
+#define PORT_TEGRA_TCU 118


Check if there is an unused gap. IIRC we still have one near to 40ish.



Correct, looks like 41-43 are unused. I'll change this 41.

Thanks for reviewing!

Mikko

Re: [PATCH 6/8] serial: Add Tegra Combined UART driver

[Mikko Perttunen]

On 05/13/2018 06:36 PM, Jassi Brar wrote:

On Tue, May 8, 2018 at 5:14 PM, Mikko Perttunen  wrote:




+config SERIAL_TEGRA_TCU
+   tristate "NVIDIA Tegra Combined UART"
+   depends on ARCH_TEGRA && MAILBOX
+   select SERIAL_CORE
+   help
+ Support for the mailbox-based TCU (Tegra Combined UART) serial port.
+ TCU is a virtual serial port that allows multiplexing multiple data
+ streams into a single hardware serial port.
+

Maybe make it depend upon TEGRA_HSP_MBOX ?


Yeah, that probably makes more sense. MAILBOX is enough to build it but 
it won't be of any use without TEGRA_HSP_MBOX.




..


+
+static void tegra_tcu_write(const char *s, unsigned int count)
+{
+   struct tegra_tcu *tcu = tegra_tcu_uart_port.private_data;
+   unsigned int written = 0, i = 0;
+   bool insert_nl = false;
+   uint32_t value = 0;
+
+   while (i < count) {
+   if (insert_nl) {
+   value |= '\n' << (written++ * 8);
+   insert_nl = false;
+   i++;
+   } else if (s[i] == '\n') {
+   value |= '\r' << (written++ * 8);
+   insert_nl = true;
+   } else {
+   value |= s[i++] << (written++ * 8);
+   }
+
+   if (written == 3) {
+   value |= 3 << 24;
+   value |= BIT(26);
+   mbox_send_message(tcu->tx, );


How is this supposed to work? tegra_hsp_doorbell_send_data() ignores
the second argument.


The previous patch in the series adds support for what are called 
"shared mailboxes" to the tegra-hsp driver. For these the second 
argument is used.


Thanks,
Mikko


--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: for_each_cpu() is buggy for UP kernel?

[Linus Torvalds]

On Tue, May 8, 2018 at 11:24 PM Dexuan Cui  wrote:

> Should we fix the for_each_cpu() in include/linux/cpumask.h for UP?

As Thomas points out, this has come up before.

One of the issues is historical - we tried very hard to make the SMP code
not cause code generation problems for UP, and part of that was just that
all these loops were literally designed to entirely go away under UP. It
still *looks* syntactically like a loop, but an optimizing compiler will
see that there's nothing there, and "for_each_cpu(...) x" essentially just
turns into "x" on UP.  An empty mask simply generally doesn't make sense,
since opn UP you also don't have any masking of CPU ops, so the mask is
ignored, and that helps the code generation immensely.

If you have to load and test the mask, you immediately lose out badly in
code generation.

So honestly, I'd really prefer to keep our current behavior. Perhaps with a
debug option that actually tests (on SMP - because that's what every
developer is actually _using_ these days) that the mask isn't empty. But
I'm not sure that would find this case, since presumably on SMP it might
never be empty.

Now, there is likely a fairly good argument that UP is getting _so_
uninteresting that we shouldn't even worry about code generation. But the
counter-argument to that is that if people are using UP in this day and
age, they probably are using some really crappy hardware that needs all the
help it can get.

At least for now, I'd rather have this inconsistency, because it really
makes a surprisingly *big* difference in code generation.  From the little
test I just did, adding that mask testing to a *single* case of
for_each_cpu() added 20 instructions.  I didn't look at exactly why that
happened (because the code generation was so radically different), but it
was very noticeable. I used your macro replacement in kernel/taskstats.c in
case you want to try to dig into what happened, but I'm not surprised. It
really turns an unconditional trivial loop into a much more complex thing
that needs to look at and test a value that we didn't care about before.

Maybe we should introduce a "for_each_cpu_maybe_empty()" helper for cases
like this?

Linus

Re: [PATCH 1/2] x86/boot/compressed/64: Set up GOT for paging_prepare() and cleanup_trampoline()

[Thomas Gleixner]

On Thu, 10 May 2018, Kirill A. Shutemov wrote:

> + /*
> +  * paging_prepare() and cleanup_trampoline() below can have GOT
> +  * references. Adjust the table with address we are running at.
> +  */
> +
> + /* The GOP was not adjusted before */

GOP == EFI speak for Graphics Output Protocol. What the heck? 

> + xorq%rax, %rax

And this clearing of RAX is related to this because? Sure you need it for
adjust_got() but adding a comment to that is too much asked for, right?

> + /* Calculate the address the binary is loaded at. */
> + call1f
> +1:   popq%rdi
> + subq$1b, %rdi
> +
> + calladjust_gop
> +
>   /*
>* At this point we are in long mode with 4-level paging enabled,
>* but we might want to enable 5-level paging or vice versa.
> @@ -381,6 +396,24 @@ trampoline_return:
>   pushq   $0
>   popfq
>  
> + /*
> +  * Previously we've adjusted the GOT with address the binary was
> +  * loaded at. Now we need to re-adjust for relocation address.
> +  */

Breaking up those comments makes it more readable, right?

> + /*
> +  * Calculate the address the binary is loaded at.
> +  * This address was used to adjust the table before and we need to
> +  * undo the change.
> +  */
> + call1f
> +1:   popq%rax
> + subq$1b, %rax
> +
> + /* The new adjustment is relocation address */

  is the relocation address

> + movq%rbx, %rdi
> + calladjust_gop
> +
>  /*
>   * Copy the compressed kernel to the end of our buffer
>   * where decompression in place becomes safe.
> @@ -481,19 +514,6 @@ relocated:
>   shrq$3, %rcx
>   rep stosq
>  
> -/*
> - * Adjust our own GOT
> - */
> - leaq_got(%rip), %rdx
> - leaq_egot(%rip), %rcx
> -1:
> - cmpq%rcx, %rdx
> - jae 2f
> - addq%rbx, (%rdx)
> - addq$8, %rdx
> - jmp 1b
> -2:
> - 
>  /*
>   * Do the extraction, and jump to the new kernel..
>   */
> @@ -512,6 +532,26 @@ relocated:
>   */
>   jmp *%rax
>  
> +/*
> + * Adjust global offest table

offest? 

> + *
> + * RAX is previous adjustment of the table to undo (0 if it's the first time 
> we touch GOP).

  is the previous

And there is no reason to make that line overly long.

> + * RDI is the new adjustment to apply.
> + */
> +adjust_gop:
> + /* Walk through the GOT adding the address to the entries */
> + leaq_got(%rip), %rdx
> + leaq_egot(%rip), %rcx
> +1:
> + cmpq%rcx, %rdx
> + jae 2f
> + subq%rax, (%rdx)/* Undo previous adjustment */
> + addq%rdi, (%rdx)/* Apply the new adjustment */
> + addq$8, %rdx
> + jmp 1b
> +2:
> + ret

I'm really tired of your carelessness. The amount of half baken stuff you
submit is way above the tolerance level by now. I asked you several times
to be more careful, but you simply do not care at all. Get your act
together finally.

Thanks,

tglx

Re: [PATCH 2/2] x86/boot/compressed/64: Fix moving page table out of trampoline memory

[Thomas Gleixner]

On Thu, 10 May 2018, Kirill A. Shutemov wrote:

> top_pgtable address has to be calculated relative to where the kernel
> image will be relocated for decompression, not relative to position of
> kernel is running at the moment. We do the same for the rest of page
> table we use the stage. It makes them safe from being overwritten during
> decompression.
> 
> Calculate the address of top_pgtable in assembly and pass down to
> cleanup_trampoline().
> 
> Move the page table to .pgtable section where the rest of page tables
> are. The section is @nobits so we save 4k in kernel image.

So this is supposed to be a fix, but the whole changelog talks about WHAT
the patch does and not WHY. Darn, we need proper description of the failure
which is about to be fixed.

It's not that hard and I'm really tired to tell you that over and over.

>   /*
>* cleanup_trampoline() would restore trampoline memory.
>*
> +  * RDI is address of the page table to use instead of page table
> +  * in trampoline memory (if required).

Do you really believe that you understand that comment 6 month from now?

Thanks,

tglx

Re: [PATCH 01/18] kernel: Use pr_fmt

[Jessica Yu]

+++ Joe Perches [10/05/18 08:45 -0700]:

Sometime in the future, it would be useful to convert pr_fmt from a
default simple define to use a default prefix with KBUILD_MODNAME.

There are files in kernel/ that use pr_, some with an embedded
prefix, that also do not have a specific pr_fmt define.

Add pr_fmt for those files.

There are some differences in output as some messages are now prefixed
with their KBUILD_MODNAME.

Miscellanea:

o Align multiline statements to open parenthesis
o Wrap and realign arguments to 80 columns where sensible
o Coalesce formats

Signed-off-by: Joe Perches 


Acked-by: Jessica Yu  (for module.c)


---
kernel/acct.c  |  2 ++
kernel/async.c | 14 ++--
kernel/audit_tree.c|  2 +-
kernel/backtracetest.c |  8 +++
kernel/crash_core.c| 29 ++---
kernel/exit.c  |  2 ++
kernel/hung_task.c | 13 +--
kernel/kprobes.c   | 20 ++---
kernel/module.c| 59 +++---
kernel/panic.c |  3 +++
kernel/params.c| 13 ++-
kernel/pid.c   |  2 ++
kernel/profile.c   |  2 ++
kernel/range.c |  2 +-
kernel/relay.c |  5 -
kernel/seccomp.c   |  4 +++-
kernel/signal.c| 10 +
kernel/smpboot.c   |  5 -
kernel/taskstats.c |  4 +++-
kernel/torture.c   |  6 +++--
kernel/tracepoint.c|  3 +++
kernel/workqueue.c |  2 ++
22 files changed, 122 insertions(+), 88 deletions(-)

diff --git a/kernel/acct.c b/kernel/acct.c
index addf7732fb56..c3d393655f11 100644
--- a/kernel/acct.c
+++ b/kernel/acct.c
@@ -44,6 +44,8 @@
 * a struct file opened for write. Fixed. 2/6/2000, AV.
 */

+#define pr_fmt(fmt) fmt
+
#include 
#include 
#include 
diff --git a/kernel/async.c b/kernel/async.c
index a893d6170944..9a6ab6016713 100644
--- a/kernel/async.c
+++ b/kernel/async.c
@@ -120,8 +120,8 @@ static void async_run_entry_fn(struct work_struct *work)
/* 1) run (and print duration) */
if (initcall_debug && system_state < SYSTEM_RUNNING) {
pr_debug("calling  %lli_%pF @ %i\n",
-   (long long)entry->cookie,
-   entry->func, task_pid_nr(current));
+(long long)entry->cookie,
+entry->func, task_pid_nr(current));
calltime = ktime_get();
}
entry->func(entry->data, entry->cookie);
@@ -129,9 +129,9 @@ static void async_run_entry_fn(struct work_struct *work)
rettime = ktime_get();
delta = ktime_sub(rettime, calltime);
pr_debug("initcall %lli_%pF returned 0 after %lld usecs\n",
-   (long long)entry->cookie,
-   entry->func,
-   (long long)ktime_to_ns(delta) >> 10);
+(long long)entry->cookie,
+entry->func,
+(long long)ktime_to_ns(delta) >> 10);
}

/* 2) remove self from the pending queues */
@@ -300,8 +300,8 @@ void async_synchronize_cookie_domain(async_cookie_t cookie, 
struct async_domain
delta = ktime_sub(endtime, starttime);

pr_debug("async_continuing @ %i after %lli usec\n",
-   task_pid_nr(current),
-   (long long)ktime_to_ns(delta) >> 10);
+task_pid_nr(current),
+(long long)ktime_to_ns(delta) >> 10);
}
}
EXPORT_SYMBOL_GPL(async_synchronize_cookie_domain);
diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
index 67e6956c0b61..f34f90b4a346 100644
--- a/kernel/audit_tree.c
+++ b/kernel/audit_tree.c
@@ -739,7 +739,7 @@ static int audit_launch_prune(void)
prune_thread = kthread_run(prune_tree_thread, NULL,
"audit_prune_tree");
if (IS_ERR(prune_thread)) {
-   pr_err("cannot start thread audit_prune_tree");
+   pr_err("cannot start thread audit_prune_tree\n");
prune_thread = NULL;
return -ENOMEM;
}
diff --git a/kernel/backtracetest.c b/kernel/backtracetest.c
index 1323360d90e3..d10cc39b0134 100644
--- a/kernel/backtracetest.c
+++ b/kernel/backtracetest.c
@@ -19,7 +19,7 @@

static void backtrace_test_normal(void)
{
-   pr_info("Testing a backtrace from process context.\n");
+   pr_info("Testing a backtrace from process context\n");
pr_info("The following trace is a kernel self test and not a bug!\n");

dump_stack();
@@ -37,7 +37,7 @@ static DECLARE_TASKLET(backtrace_tasklet, 
_test_irq_callback, 0);

static void backtrace_test_irq(void)
{
-   pr_info("Testing a backtrace from irq context.\n");
+   pr_info("Testing a backtrace from irq context\n");
pr_info("The following trace is a kernel self test and not a bug!\n");

init_completion(_work);
@@ -51,7 +51,7 @@ 

Re: [PATCH v1] x86/mtrr: Convert to use match_string() helper

[Thomas Gleixner]

On Fri, 4 May 2018, Andy Shevchenko wrote:

> The new helper returns index of the matching string in an array.

new helper? match_string() is in tree for 2 years.

> We are going to use it here.

Are we going to use it ? When?

"Replace the open coded array lookup." or something like that would be more
appropriate.

Thanks,

tglx

[tip:x86/cleanups] x86: Remove pr_fmt duplicate logging prefixes

[tip-bot for Joe Perches]

Commit-ID:  1de392f5d5e803663abbd8ed084233f154152bcd
Gitweb: https://git.kernel.org/tip/1de392f5d5e803663abbd8ed084233f154152bcd
Author: Joe Perches 
AuthorDate: Thu, 10 May 2018 08:45:30 -0700
Committer:  Thomas Gleixner 
CommitDate: Sun, 13 May 2018 21:25:18 +0200

x86: Remove pr_fmt duplicate logging prefixes

Converting pr_fmt from a default simple #define to use KBUILD_MODNAME
added some duplicate prefixes.

Remove the duplicate prefixes.

Signed-off-by: Joe Perches 
Signed-off-by: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Link: 
https://lkml.kernel.org/r/e7b709a2b040af7faa81b0aa2c3a125aed628a82.1525964383.git@perches.com

---
 arch/x86/events/amd/ibs.c |  2 +-
 arch/x86/kernel/e820.c| 32 +---
 arch/x86/kernel/hpet.c|  5 ++---
 arch/x86/kernel/uprobes.c |  4 ++--
 arch/x86/mm/numa.c| 22 +++---
 5 files changed, 33 insertions(+), 32 deletions(-)

diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 786fd875de92..4b98101209a1 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -889,7 +889,7 @@ static void force_ibs_eilvt_setup(void)
if (!ibs_eilvt_valid())
goto out;
 
-   pr_info("IBS: LVT offset %d assigned\n", offset);
+   pr_info("LVT offset %d assigned\n", offset);
 
return;
 out:
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 6a2cb1442e05..d1f25c831447 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -155,7 +155,8 @@ static void __init __e820__range_add(struct e820_table 
*table, u64 start, u64 si
int x = table->nr_entries;
 
if (x >= ARRAY_SIZE(table->entries)) {
-   pr_err("e820: too many entries; ignoring [mem 
%#010llx-%#010llx]\n", start, start + size - 1);
+   pr_err("too many entries; ignoring [mem %#010llx-%#010llx]\n",
+  start, start + size - 1);
return;
}
 
@@ -190,9 +191,10 @@ void __init e820__print_table(char *who)
int i;
 
for (i = 0; i < e820_table->nr_entries; i++) {
-   pr_info("%s: [mem %#018Lx-%#018Lx] ", who,
-  e820_table->entries[i].addr,
-  e820_table->entries[i].addr + 
e820_table->entries[i].size - 1);
+   pr_info("%s: [mem %#018Lx-%#018Lx] ",
+   who,
+   e820_table->entries[i].addr,
+   e820_table->entries[i].addr + 
e820_table->entries[i].size - 1);
 
e820_print_type(e820_table->entries[i].type);
pr_cont("\n");
@@ -574,7 +576,7 @@ void __init e820__update_table_print(void)
if (e820__update_table(e820_table))
return;
 
-   pr_info("e820: modified physical RAM map:\n");
+   pr_info("modified physical RAM map:\n");
e820__print_table("modified");
 }
 
@@ -636,9 +638,8 @@ __init void e820__setup_pci_gap(void)
if (!found) {
 #ifdef CONFIG_X86_64
gapstart = (max_pfn << PAGE_SHIFT) + 1024*1024;
-   pr_err(
-   "e820: Cannot find an available gap in the 32-bit 
address range\n"
-   "e820: PCI devices with unassigned 32-bit BARs may not 
work!\n");
+   pr_err("Cannot find an available gap in the 32-bit address 
range\n");
+   pr_err("PCI devices with unassigned 32-bit BARs may not 
work!\n");
 #else
gapstart = 0x1000;
 #endif
@@ -649,7 +650,8 @@ __init void e820__setup_pci_gap(void)
 */
pci_mem_start = gapstart;
 
-   pr_info("e820: [mem %#010lx-%#010lx] available for PCI devices\n", 
gapstart, gapstart + gapsize - 1);
+   pr_info("[mem %#010lx-%#010lx] available for PCI devices\n",
+   gapstart, gapstart + gapsize - 1);
 }
 
 /*
@@ -711,7 +713,7 @@ void __init e820__memory_setup_extended(u64 phys_addr, u32 
data_len)
memcpy(e820_table_firmware, e820_table, sizeof(*e820_table_firmware));
 
early_memunmap(sdata, data_len);
-   pr_info("e820: extended physical RAM map:\n");
+   pr_info("extended physical RAM map:\n");
e820__print_table("extended");
 }
 
@@ -780,7 +782,7 @@ u64 __init e820__memblock_alloc_reserved(u64 size, u64 
align)
addr = __memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ACCESSIBLE);
if (addr) {
e820__range_update_kexec(addr, size, E820_TYPE_RAM, 
E820_TYPE_RESERVED);
-   pr_info("e820: update e820_table_kexec for 
e820__memblock_alloc_reserved()\n");
+   pr_info("update e820_table_kexec for 
e820__memblock_alloc_reserved()\n");
e820__update_table_kexec();
}
 
@@ -830,8 +832,8 @@ static unsigned long __init e820_end_pfn(unsigned long 
limit_pfn, enum e820_type
if (last_pfn > max_arch_pfn)
last_pfn = 

[tip:x86/cleanups] x86/mtrr: Rename main.c to mtrr.c and remove duplicate prefixes

[tip-bot for Joe Perches]

Commit-ID:  e6d8c84a58380030457759ad6085f3792a76b2ce
Gitweb: https://git.kernel.org/tip/e6d8c84a58380030457759ad6085f3792a76b2ce
Author: Joe Perches 
AuthorDate: Thu, 10 May 2018 08:45:31 -0700
Committer:  Thomas Gleixner 
CommitDate: Sun, 13 May 2018 21:25:18 +0200

x86/mtrr: Rename main.c to mtrr.c and remove duplicate prefixes

Kbuild uses the first file as the name for KBUILD_MODNAME.
mtrr uses main.c as its first file, so rename that file to mtrr.c
and fixup the Makefile.

Remove the now duplicate "mtrr: " prefixes from the logging calls.

Signed-off-by: Joe Perches 
Signed-off-by: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Link: 
https://lkml.kernel.org/r/ae1fa81a0d1fad87571967b91ea90f70f486e853.1525964384.git@perches.com

---
 arch/x86/kernel/cpu/mtrr/Makefile   |  2 +-
 arch/x86/kernel/cpu/mtrr/{main.c => mtrr.c} | 33 ++---
 2 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kernel/cpu/mtrr/Makefile 
b/arch/x86/kernel/cpu/mtrr/Makefile
index ad9e5ed81181..2ad9107ee980 100644
--- a/arch/x86/kernel/cpu/mtrr/Makefile
+++ b/arch/x86/kernel/cpu/mtrr/Makefile
@@ -1,3 +1,3 @@
-obj-y  := main.o if.o generic.o cleanup.o
+obj-y  := mtrr.o if.o generic.o cleanup.o
 obj-$(CONFIG_X86_32) += amd.o cyrix.o centaur.o
 
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/mtrr.c
similarity index 96%
rename from arch/x86/kernel/cpu/mtrr/main.c
rename to arch/x86/kernel/cpu/mtrr/mtrr.c
index 7468de429087..0c4f4fba9ec1 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/mtrr.c
@@ -100,7 +100,7 @@ static int have_wrcomb(void)
if (dev->vendor == PCI_VENDOR_ID_SERVERWORKS &&
dev->device == PCI_DEVICE_ID_SERVERWORKS_LE &&
dev->revision <= 5) {
-   pr_info("mtrr: Serverworks LE rev < 6 detected. 
Write-combining disabled.\n");
+   pr_info("Serverworks LE rev < 6 detected. 
Write-combining disabled.\n");
pci_dev_put(dev);
return 0;
}
@@ -110,7 +110,7 @@ static int have_wrcomb(void)
 */
if (dev->vendor == PCI_VENDOR_ID_INTEL &&
dev->device == PCI_DEVICE_ID_INTEL_82451NX) {
-   pr_info("mtrr: Intel 450NX MMC detected. 
Write-combining disabled.\n");
+   pr_info("Intel 450NX MMC detected. Write-combining 
disabled.\n");
pci_dev_put(dev);
return 0;
}
@@ -312,24 +312,24 @@ int mtrr_add_page(unsigned long base, unsigned long size,
return error;
 
if (type >= MTRR_NUM_TYPES) {
-   pr_warn("mtrr: type: %u invalid\n", type);
+   pr_warn("type: %u invalid\n", type);
return -EINVAL;
}
 
/* If the type is WC, check that this processor supports it */
if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) {
-   pr_warn("mtrr: your processor doesn't support 
write-combining\n");
+   pr_warn("your processor doesn't support write-combining\n");
return -ENOSYS;
}
 
if (!size) {
-   pr_warn("mtrr: zero sized request\n");
+   pr_warn("zero sized request\n");
return -EINVAL;
}
 
if ((base | (base + size - 1)) >>
(boot_cpu_data.x86_phys_bits - PAGE_SHIFT)) {
-   pr_warn("mtrr: base or size exceeds the MTRR width\n");
+   pr_warn("base or size exceeds the MTRR width\n");
return -EINVAL;
}
 
@@ -360,8 +360,7 @@ int mtrr_add_page(unsigned long base, unsigned long size,
} else if (types_compatible(type, ltype))
continue;
}
-   pr_warn("mtrr: 0x%lx000,0x%lx000 overlaps existing"
-   " 0x%lx000,0x%lx000\n", base, size, lbase,
+   pr_warn("0x%lx000,0x%lx000 overlaps existing 
0x%lx000,0x%lx000\n", base, size, lbase,
lsize);
goto out;
}
@@ -369,7 +368,7 @@ int mtrr_add_page(unsigned long base, unsigned long size,
if (ltype != type) {
if (types_compatible(type, ltype))
continue;
-   pr_warn("mtrr: type mismatch for %lx000,%lx000 old: %s 
new: %s\n",
+   pr_warn("type mismatch for %lx000,%lx000 old: %s new: 
%s\n",
base, size, mtrr_attrib_to_str(ltype),
mtrr_attrib_to_str(type));
goto out;
@@ -395,7 +394,7 @@ int mtrr_add_page(unsigned long base, unsigned 

Re: [PATCH 2/6] x86/intel_rdt/mba_sc: Enable/disable MBA software controller

[Thomas Gleixner]

On Fri, 20 Apr 2018, Vikas Shivappa wrote:
> +/*
> + * Enable or disable the MBA software controller
> + * which helps user specify bandwidth in MBps.
> + * MBA software controller is supported only if
> + * MBM is supported and MBA is in linear scale.
> + */
> +static int set_mba_sc(bool mba_sc)
> +{
> + struct rdt_resource *r = _resources_all[RDT_RESOURCE_MBA];
> +
> + if (!is_mbm_enabled() || !is_mba_linear() ||
> + mba_sc == is_mba_sc(r))
> + return -1;

Please use a proper return value as this gets propagated.

Thanks,

tglx

Re: [tip/core/rcu,16/21] rcu: Add funnel locking to rcu_start_this_gp()

[Joel Fernandes]

On Sun, May 13, 2018 at 12:09:06PM -0700, Paul E. McKenney wrote:
> On Sun, May 13, 2018 at 09:49:53AM -0700, Joel Fernandes wrote:
> > On Sun, May 13, 2018 at 08:38:42AM -0700, Paul E. McKenney wrote:
> > > On Sat, May 12, 2018 at 04:53:01PM -0700, Joel Fernandes wrote:
> > > > On Sat, May 12, 2018 at 07:44:38AM -0700, Paul E. McKenney wrote:
> > > > > On Sat, May 12, 2018 at 07:40:02AM -0700, Paul E. McKenney wrote:
> > > > > > On Fri, May 11, 2018 at 11:03:25PM -0700, Joel Fernandes wrote:
> > > > > > > On Sun, Apr 22, 2018 at 08:03:39PM -0700, Paul E. McKenney wrote:
> > > > > > > > The rcu_start_this_gp() function had a simple form of funnel 
> > > > > > > > locking that
> > > > > > > > used only the leaves and root of the rcu_node tree, which is 
> > > > > > > > fine for
> > > > > > > > systems with only a few hundred CPUs, but sub-optimal for 
> > > > > > > > systems having
> > > > > > > > thousands of CPUs.  This commit therefore adds full-tree funnel 
> > > > > > > > locking.
> > > > > > > > 
> > > > > > > > This variant of funnel locking is unusual in the following ways:
> > > > > > > > 
> > > > > > > > 1.  The leaf-level rcu_node structure's ->lock is held 
> > > > > > > > throughout.
> > > > > > > > Other funnel-locking implementations drop the 
> > > > > > > > leaf-level lock
> > > > > > > > before progressing to the next level of the tree.
> > > > > > > > 
> > > > > > > > 2.  Funnel locking can be started at the root, which is 
> > > > > > > > convenient
> > > > > > > > for code that already holds the root rcu_node 
> > > > > > > > structure's ->lock.
> > > > > > > > Other funnel-locking implementations start at the 
> > > > > > > > leaves.
> > > > > > > > 
> > > > > > > > 3.  If an rcu_node structure other than the initial one 
> > > > > > > > believes
> > > > > > > > that a grace period is in progress, it is not necessary 
> > > > > > > > to
> > > > > > > > go further up the tree.  This is because grace-period 
> > > > > > > > cleanup
> > > > > > > > scans the full tree, so that marking the need for a 
> > > > > > > > subsequent
> > > > > > > > grace period anywhere in the tree suffices -- but only 
> > > > > > > > if
> > > > > > > > a grace period is currently in progress.
> > > > > > > > 
> > > > > > > > 4.  It is possible that the RCU grace-period kthread has 
> > > > > > > > not yet
> > > > > > > > started, and this case must be handled appropriately.
> > > > > > > > 
> > > > > > > > However, the general approach of using a tree to control lock 
> > > > > > > > contention
> > > > > > > > is still in place.
> > > > > > > > 
> > > > > > > > Signed-off-by: Paul E. McKenney 
> > > > > > > > ---
> > > > > > > >  kernel/rcu/tree.c | 92 
> > > > > > > > +--
> > > > > > > >  1 file changed, 35 insertions(+), 57 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > > > > > > index 94519c7d552f..d3c769502929 100644
> > > > > > > > --- a/kernel/rcu/tree.c
> > > > > > > > +++ b/kernel/rcu/tree.c
> > > > > > > > @@ -1682,74 +1682,52 @@ static bool rcu_start_this_gp(struct 
> > > > > > > > rcu_node *rnp, struct rcu_data *rdp,
> > > > > > > >  {
> > > > > > > > bool ret = false;
> > > > > > > > struct rcu_state *rsp = rdp->rsp;
> > > > > > > > -   struct rcu_node *rnp_root = rcu_get_root(rsp);
> > > > > > > > -
> > > > > > > > -   raw_lockdep_assert_held_rcu_node(rnp);
> > > > > > > > -
> > > > > > > > -   /* If the specified GP is already known needed, return 
> > > > > > > > to caller. */
> > > > > > > > -   trace_rcu_this_gp(rnp, rdp, c, TPS("Startleaf"));
> > > > > > > > -   if (need_future_gp_element(rnp, c)) {
> > > > > > > > -   trace_rcu_this_gp(rnp, rdp, c, 
> > > > > > > > TPS("Prestartleaf"));
> > > > > > > > -   goto out;
> > > > > > > > -   }
> > > > > > > > +   struct rcu_node *rnp_root;
> > > > > > > >  
> > > > > > > > /*
> > > > > > > > -* If this rcu_node structure believes that a grace 
> > > > > > > > period is in
> > > > > > > > -* progress, then we must wait for the one following, 
> > > > > > > > which is in
> > > > > > > > -* "c".  Because our request will be noticed at the end 
> > > > > > > > of the
> > > > > > > > -* current grace period, we don't need to explicitly 
> > > > > > > > start one.
> > > > > > > > +* Use funnel locking to either acquire the root 
> > > > > > > > rcu_node
> > > > > > > > +* structure's lock or bail out if the need for this 
> > > > > > > > grace period
> > > > > > > > +* has already been recorded -- or has already started. 
> > > > > > > >  If there
> > > > > > > > +* is already a grace period in progress in a non-leaf 
> > > > > > > > node, no
> > > > > > > > +* recording is 

[tip:x86/urgent] x86/cpufeature: Guard asm_volatile_goto usage for BPF compilation

[tip-bot for Alexei Starovoitov]

Commit-ID:  b1ae32dbab50ed19cfc16d225b0fb0114fb13025
Gitweb: https://git.kernel.org/tip/b1ae32dbab50ed19cfc16d225b0fb0114fb13025
Author: Alexei Starovoitov 
AuthorDate: Sun, 13 May 2018 12:32:22 -0700
Committer:  Thomas Gleixner 
CommitDate: Sun, 13 May 2018 21:49:14 +0200

x86/cpufeature: Guard asm_volatile_goto usage for BPF compilation

Workaround for the sake of BPF compilation which utilizes kernel
headers, but clang does not support ASM GOTO and fails the build.

Fixes: d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
Suggested-by: Thomas Gleixner 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Thomas Gleixner 
Cc: dan...@iogearbox.net
Cc: pet...@infradead.org
Cc: net...@vger.kernel.org
Cc: b...@alien8.de
Cc: y...@fb.com
Cc: kernel-t...@fb.com
Cc: torva...@linux-foundation.org
Cc: da...@davemloft.net
Link: https://lkml.kernel.org/r/20180513193222.1997938-1-...@kernel.org

---
 arch/x86/include/asm/cpufeature.h | 15 +++
 samples/bpf/Makefile  |  2 +-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index b27da9602a6d..aced6c9290d6 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -140,6 +140,20 @@ extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned 
int bit);
 
 #define setup_force_cpu_bug(bit) setup_force_cpu_cap(bit)
 
+#if defined(__clang__) && !defined(CC_HAVE_ASM_GOTO)
+
+/*
+ * Workaround for the sake of BPF compilation which utilizes kernel
+ * headers, but clang does not support ASM GOTO and fails the build.
+ */
+#ifndef __BPF_TRACING__
+#warning "Compiler lacks ASM_GOTO support. Add -D __BPF_TRACING__ to your 
compiler arguments"
+#endif
+
+#define static_cpu_has(bit)boot_cpu_has(bit)
+
+#else
+
 /*
  * Static testing of CPU features.  Used the same as boot_cpu_has().
  * These will statically patch the target code for additional
@@ -195,6 +209,7 @@ t_no:
boot_cpu_has(bit) : \
_static_cpu_has(bit)\
 )
+#endif
 
 #define cpu_has_bug(c, bit)cpu_has(c, (bit))
 #define set_cpu_bug(c, bit)set_cpu_cap(c, (bit))
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 4d6a6edd4bf6..092947676143 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -255,7 +255,7 @@ $(obj)/tracex5_kern.o: $(obj)/syscall_nrs.h
 $(obj)/%.o: $(src)/%.c
$(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) -I$(obj) \
-I$(srctree)/tools/testing/selftests/bpf/ \
-   -D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \
+   -D__KERNEL__ -D__BPF_TRACING__ -Wno-unused-value 
-Wno-pointer-sign \
-D__TARGET_ARCH_$(ARCH) -Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \

Re: [RFC PATCH -tip 2/4] kprobes: Remove jprobe generic code

[Thomas Gleixner]

On Tue, 8 May 2018, Masami Hiramatsu wrote:

> Remove jprobe arch independent generic code
> from kernel/kprobes.c.

# git grep register_jprobes
include/linux/kprobes.h:static inline int register_jprobes(struct jprobe **jps, 
int num)
include/linux/kprobes.h:static inline void unregister_jprobes(struct jprobe 
**jps, int num)
kernel/test_kprobes.c:  ret = register_jprobes(jps, 2);
kernel/test_kprobes.c:  pr_err("register_jprobes returned %d\n", ret);
kernel/test_kprobes.c:  unregister_jprobes(jps, 2);

You forgot to remove a few things ...

Thanks,

tglx

Re: serial: custom baud rate

[Alan Cox]

On Thu, 3 May 2018 18:27:14 + (UTC)
Grant Edwards  wrote:

> On 2018-05-03, Muni Sekhar  wrote:
> 
> > If I need to set a custom baud rates(e.g. 14400, 128000, 256000), does
> > Linux serial framework has any supporting method?  
> 
> Sure, use the termios2 structure instead of the termios structure:
> 
>   #include 
> 
>   struct termios2 t;
> 
>   ioctl(fd, TCGETS2, )
> 
>   t.c_cflag &= ~CBAUD;
>   t.c_cflag |= BOTHER;
>   t.c_ispeed = baud;
>   t.c_ospeed = baud;
> 
>   ioctl(fd, TCSETS2, )
> 
> [Not all devices/drivers support termios2]

That shouldn't be true - all devices get passed ispeed/ospeed and
everything in tree was using the correct fields as far as I could tell
last time I checked this

Alan

Re: INFO: trying to register non-static key in del_timer_sync

[Eric Biggers]

On Sun, Jan 28, 2018 at 10:58:01AM -0800, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> c4e0ca7fa24137e372d6135fe16e8df8e123f116 (Fri Jan 26 23:10:50 2018 +)
> Merge tag 'riscv-for-linus-4.15-maintainers' of
> git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux
> 
> So far this crash happened 3 times on net-next, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3659f05802671eb8a...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1517074079.617:7): avc:  denied  { map } for
> pid=3685 comm="syzkaller985951" path="/root/syzkaller985951088" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> CPU: 1 PID: 3685 Comm: syzkaller985951 Not tainted 4.15.0-rc9+ #283
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  register_lock_class+0x542/0x2cd0 kernel/locking/lockdep.c:752
>  __lock_acquire+0x1de/0x3e00 kernel/locking/lockdep.c:3314
>  lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3914
>  del_timer_sync+0xba/0x240 kernel/time/timer.c:1275
>  led_tg_destroy+0x2dd/0x3f0 net/netfilter/xt_LED.c:185
>  cleanup_entry+0x218/0x350 net/ipv4/netfilter/ip_tables.c:659
>  __do_replace+0x7d7/0xa90 net/ipv4/netfilter/ip_tables.c:1096
>  do_replace net/ipv4/netfilter/ip_tables.c:1152 [inline]
>  do_ipt_set_ctl+0x40f/0x5f0 net/ipv4/netfilter/ip_tables.c:1682
>  nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
>  nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115
>  ip_setsockopt+0xa1/0xb0 net/ipv4/ip_sockglue.c:1256
>  tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2875
>  sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2968
>  SYSC_setsockopt net/socket.c:1831 [inline]
>  SyS_setsockopt+0x189/0x360 net/socket.c:1810
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x4449fa
> RSP: 002b:7ffee653a948 EFLAGS: 0206 ORIG_RAX: 0036
> RAX: ffda RBX: 006cd0fc RCX: 004449fa
> RDX: 0040 RSI:  RDI: 0003
> RBP: 006cd0fc R08: 02d8 R09: 0117c880
> R10: 006cd528 R11: 0206 R12: 0003
> R13: 006d00a4 R14: 006d0050 R15: 004a39ae
> [ cut here ]
> ODEBUG: assert_init not available (active state 0) object type: timer_list
> hint:   (null)
> WARNING: CPU: 1 PID: 3685 at lib/debugobjects.c:291
> debug_print_object+0x166/0x220 lib/debugobjects.c:288
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 1 PID: 3685 Comm: syzkaller985951 Not tainted 4.15.0-rc9+ #283
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  panic+0x1e4/0x41c kernel/panic.c:183
>  __warn+0x1dc/0x200 kernel/panic.c:547
>  report_bug+0x211/0x2d0 lib/bug.c:184
>  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
>  fixup_bug arch/x86/kernel/traps.c:247 [inline]
>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1096
> RIP: 0010:debug_print_object+0x166/0x220 lib/debugobjects.c:288
> RSP: 0018:8801d9adf7d0 EFLAGS: 00010282
> RAX: dc08 RBX: 0005 RCX: 8159ebae
> RDX:  RSI: 0001 RDI: 0293
> RBP: 8801d9adf810 R08:  R09: 11003b35be97
> R10: 8801d9adf6d0 R11: 86b38678 R12: 0001
> R13: 86b49d00 R14: 86010440 R15: 815f1530
>  debug_object_assert_init+0x303/0x570 lib/debugobjects.c:654
>  debug_timer_assert_init kernel/time/timer.c:707 [inline]
>  debug_assert_init kernel/time/timer.c:759 [inline]
>  try_to_del_timer_sync+0x74/0x130 kernel/time/timer.c:1215
>  del_timer_sync+0x18a/0x240 kernel/time/timer.c:1285
>  led_tg_destroy+0x2dd/0x3f0 net/netfilter/xt_LED.c:185
>  cleanup_entry+0x218/0x350 net/ipv4/netfilter/ip_tables.c:659
>  __do_replace+0x7d7/0xa90 net/ipv4/netfilter/ip_tables.c:1096
>  do_replace net/ipv4/netfilter/ip_tables.c:1152 [inline]
>  do_ipt_set_ctl+0x40f/0x5f0 net/ipv4/netfilter/ip_tables.c:1682
>  nf_sockopt net/netfilter/nf_sockopt.c:106 

[tip:x86/cpu] x86/CPU: Move cpu_detect_cache_sizes() into init_intel_cacheinfo()

[tip-bot for David Wang]

Commit-ID:  807e9bc8e2fe6b4907f9f77fd073f7ef5073af29
Gitweb: https://git.kernel.org/tip/807e9bc8e2fe6b4907f9f77fd073f7ef5073af29
Author: David Wang 
AuthorDate: Thu, 3 May 2018 10:32:45 +0800
Committer:  Thomas Gleixner 
CommitDate: Sun, 13 May 2018 16:14:24 +0200

x86/CPU: Move cpu_detect_cache_sizes() into init_intel_cacheinfo()

There is no point in having the conditional cpu_detect_cache_sizes() call
at the callsite of init_intel_cacheinfo().

Move it into init_intel_cacheinfo() and make init_intel_cacheinfo() void.

[ tglx: Made the init_intel_cacheinfo() void as the return value was
pointless. Adjust changelog accordingly ]

Signed-off-by: David Wang 
Signed-off-by: Thomas Gleixner 
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1525314766-18910-3-git-send-email-davidw...@zhaoxin.com


---
 arch/x86/kernel/cpu/cacheinfo.c |  5 +++--
 arch/x86/kernel/cpu/cpu.h   |  2 +-
 arch/x86/kernel/cpu/intel.c | 14 --
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 58d472c84ba2..38354c66df81 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -691,7 +691,7 @@ void init_amd_cacheinfo(struct cpuinfo_x86 *c)
}
 }
 
-unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
+void init_intel_cacheinfo(struct cpuinfo_x86 *c)
 {
/* Cache sizes */
unsigned int trace = 0, l1i = 0, l1d = 0, l2 = 0, l3 = 0;
@@ -843,7 +843,8 @@ unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
 
c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i+l1d));
 
-   return l2;
+   if (!l2)
+   cpu_detect_cache_sizes(c);
 }
 
 static int __cache_amd_cpumap_setup(unsigned int cpu, int index,
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index efd6ef8ad14e..49bf8a080105 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -51,7 +51,7 @@ extern void init_scattered_cpuid_features(struct cpuinfo_x86 
*c);
 extern u32 get_scattered_cpuid_leaf(unsigned int level,
unsigned int sub_leaf,
enum cpuid_regs_idx reg);
-extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
+extern void init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
 
 extern int detect_num_cpu_cores(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index b54535be254a..ca141d159be1 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -635,8 +635,6 @@ static void init_intel_misc_features(struct cpuinfo_x86 *c)
 
 static void init_intel(struct cpuinfo_x86 *c)
 {
-   unsigned int l2 = 0;
-
early_init_intel(c);
 
intel_workarounds(c);
@@ -659,13 +657,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 #endif
}
 
-   l2 = init_intel_cacheinfo(c);
-
-   /* Detect legacy cache sizes if init_intel_cacheinfo did not */
-   if (l2 == 0) {
-   cpu_detect_cache_sizes(c);
-   l2 = c->x86_cache_size;
-   }
+   init_intel_cacheinfo(c);
 
if (c->cpuid_level > 9) {
unsigned eax = cpuid_eax(10);
@@ -678,7 +670,8 @@ static void init_intel(struct cpuinfo_x86 *c)
set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 
if (boot_cpu_has(X86_FEATURE_DS)) {
-   unsigned int l1;
+   unsigned int l1, l2;
+
rdmsr(MSR_IA32_MISC_ENABLE, l1, l2);
if (!(l1 & (1<<11)))
set_cpu_cap(c, X86_FEATURE_BTS);
@@ -706,6 +699,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 * Dixon is NOT a Celeron.
 */
if (c->x86 == 6) {
+   unsigned int l2 = c->x86_cache_size;
char *p = NULL;
 
switch (c->x86_model) {

[tip:x86/cpu] x86/Centaur: Report correct CPU/cache topology

[tip-bot for David Wang]

Commit-ID:  a2aa578fec8c29436bce5e6c15e1e31729d539a3
Gitweb: https://git.kernel.org/tip/a2aa578fec8c29436bce5e6c15e1e31729d539a3
Author: David Wang 
AuthorDate: Thu, 3 May 2018 10:32:46 +0800
Committer:  Thomas Gleixner 
CommitDate: Sun, 13 May 2018 16:14:24 +0200

x86/Centaur: Report correct CPU/cache topology

Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
but the function is unused so for. The Centaur init code also misses to
initialize x86_info::max_cores, so the CPU topology can't be described
correctly.

Initialize x86_info::max_cores and invoke init_cacheinfo() to make
CPU and cache topology information available and correct.

Signed-off-by: David Wang 
Signed-off-by: Thomas Gleixner 
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1525314766-18910-4-git-send-email-davidw...@zhaoxin.com


---
 arch/x86/kernel/cpu/centaur.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 80d5110481ec..c265494234e6 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -160,6 +160,11 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+   init_intel_cacheinfo(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
+#ifdef CONFIG_X86_32
+   detect_ht(c);
+#endif
 
if (c->cpuid_level > 9) {
unsigned int eax = cpuid_eax(10);

Re: [PATCH v2 0/7] Introduce the for_each_set_port_word macro

[Andy Shevchenko]

On Tue, May 8, 2018 at 4:26 PM, William Breathitt Gray
 wrote:

> While adding GPIO get_multiple/set_multiple callback support for various
> drivers, I noticed a pattern of looping manifesting that would be useful
> standardized as a macro.
>
> This patchset introduces the for_each_set_port_word macro and utilizes
> it in several GPIO drivers. The for_each_set_port_word macro facilitates
> a for-loop syntax that iterates over entire groups of set bits at a
> time.
>
> For example, suppose you would like to iterate over a 16-bit integer 4
> bits at a time, skipping over 4-bit groups with no set bit, where 
> represents the current 4-bit group:
>
> Example:1011 1110  
> First loop: 1011 1110  

> Second loop:1011   

8-bit itteration. Is it correct?

> Third loop:  1110  

Looking at the example above I highly recommend to introduce some test
cases for your helper function.

Consider extending lib/test_bitmap.c for this purpose.

>
> Each iteration of the loop returns the next 4-bit group that has at
> least one set bit.
>
> The for_each_set_port_word macro has six parameters:
>
> * port_word: set to current port word index for the iteration
> * word_index: set to current bitmap word index for the iteration
> * word_offset: bits offset of the found port word in the bitmap word
> * bits: bitmap to search within
> * size: bitmap size in number of port words
> * port_size: port word size in number of bits
>
> The port_size argument can be an arbitrary number of bits and is not
> required to be a multiple of 2.
>
> I've called the group of bits a "port word" which may be a confusing
> naming convention; I was afraid calling that them a "group" may be too
> vague. Should a different name be chosen; what would you suggest?
>
> This patchset was rebased on top of the following three commits:
>
> * commit aaf96e51de11 ("gpio: pci-idio-16: Fix port memory offset for 
> get_multiple callback")
> * commit 304440aa96c6 ("gpio: pcie-idio-24: Fix port memory offset for 
> get_multiple/set_multiple callbacks")
> * commit e026646c178d ("gpio: pcie-idio-24: Fix off-by-one error in 
> get_multiple loop")
>
> William Breathitt Gray
>
> William Breathitt Gray (7):
>   bitops: Introduce the for_each_set_port_word macro
>   gpio: 104-dio-48e: Utilize for_each_set_port_word macro
>   gpio: 104-idi-48: Utilize for_each_set_port_word macro
>   gpio: gpio-mm: Utilize for_each_set_port_word macro
>   gpio: ws16c48: Utilize for_each_set_port_word macro
>   gpio: pci-idio-16: Utilize for_each_set_port_word macro
>   gpio: pcie-idio-24: Utilize for_each_set_port_word macro
>
>  drivers/gpio/gpio-104-dio-48e.c   |  67 +---
>  drivers/gpio/gpio-104-idi-48.c|  32 ++
>  drivers/gpio/gpio-gpio-mm.c   |  67 +---
>  drivers/gpio/gpio-pci-idio-16.c   |  67 ++--
>  drivers/gpio/gpio-pcie-idio-24.c  | 102 +++---
>  drivers/gpio/gpio-ws16c48.c   |  66 +--
>  include/asm-generic/bitops/find.h |  26 
>  include/linux/bitops.h|   9 +++
>  lib/find_bit.c|  28 
>  9 files changed, 172 insertions(+), 292 deletions(-)
>
> --
> 2.17.0
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 11/13] dt-bindings: power: add PX30 SoCs header for power-domain

[Tao Huang]

Hi Heiko:
On 2018年05月12日 06:11, Heiko Stuebner wrote:
> Here I have a naming question. When looking at the vendor kernel
> it looks like the px30 is largely related to the rk3326.
> (rk3326.dtsi includeing the px30.dtsi)
>
> What is the reason for basing the naming on the px30 this time? And could
> we possibly keep to rk names for the basic things in the kernel, thus
> keeping the pxXX as second name, like with the other px-variants before?
>
PX30 and RK3326 are different chips. PX30 has more features. You can simply 
think that RK3326 is a subset of PX30. The RK3326 is more like a PX30 
derivative chip. This is not the same as the previous chips.
So we use PX30 instead of RK3326 for name, and the opening document is only for 
PX30, we think this is more convenient for developers.

Best Regards,
Tao Huang

Re: [PATCH REPOST 1/5] thread_info: Port core code to use update_thread_flag() helpers

[Oleg Nesterov]

On 05/11, Dave Martin wrote:
>
> This patch ports a couple of relevant bits of the core kernel to
> use the new update_thread_flag() helpers.
>
> No functional change.
>
> Signed-off-by: Dave Martin 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Steven Rostedt 
> Cc: Oleg Nesterov 
> ---
>  include/trace/syscall.h |  6 ++
>  kernel/ptrace.c | 13 +
>  2 files changed, 7 insertions(+), 12 deletions(-)

Acked-by: Oleg Nesterov 

KMSAN: uninit-value in tipc_conn_rcv_sub

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:74ee2200b89f kmsan: bump .config.example to v4.17-rc3
git tree:   https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=12ab863780
kernel config:  https://syzkaller.appspot.com/x/.config?x=4ca1e57bafa8ab1f
dashboard link: https://syzkaller.appspot.com/bug?extid=8951a3065ee7fd6d6e23
compiler:   clang version 7.0.0 (trunk 329391)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=15a497f780
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=177c190780

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+8951a3065ee7fd6d6...@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
==
BUG: KMSAN: uninit-value in tipc_conn_rcv_sub+0x184/0x950  
net/tipc/topsrv.c:373

CPU: 0 PID: 66 Comm: kworker/u4:4 Not tainted 4.17.0-rc3+ #88
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Workqueue: tipc_rcv tipc_conn_recv_work
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x185/0x1d0 lib/dump_stack.c:113
 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
 tipc_conn_rcv_sub+0x184/0x950 net/tipc/topsrv.c:373
 tipc_conn_rcv_from_sock net/tipc/topsrv.c:409 [inline]
 tipc_conn_recv_work+0x3cd/0x560 net/tipc/topsrv.c:424
 process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2145
 worker_thread+0x113c/0x24f0 kernel/workqueue.c:2279
 kthread+0x539/0x720 kernel/kthread.c:239
 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:412

Local variable description: s.i@tipc_conn_recv_work
Variable was created at:
 tipc_conn_recv_work+0x65/0x560 net/tipc/topsrv.c:419
 process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2145
==
Kernel panic - not syncing: panic_on_warn set ...

CPU: 0 PID: 66 Comm: kworker/u4:4 Tainted: GB 4.17.0-rc3+  
#88
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Workqueue: tipc_rcv tipc_conn_recv_work
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x185/0x1d0 lib/dump_stack.c:113
 panic+0x39d/0x940 kernel/panic.c:184
 kmsan_report+0x238/0x240 mm/kmsan/kmsan.c:1083
 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
 tipc_conn_rcv_sub+0x184/0x950 net/tipc/topsrv.c:373
 tipc_conn_rcv_from_sock net/tipc/topsrv.c:409 [inline]
 tipc_conn_recv_work+0x3cd/0x560 net/tipc/topsrv.c:424
 process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2145
 worker_thread+0x113c/0x24f0 kernel/workqueue.c:2279
 kthread+0x539/0x720 kernel/kthread.c:239
 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:412
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
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.

syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

[tip:x86/urgent] kprobes/x86: Prohibit probing on exception masking instructions

[tip-bot for Masami Hiramatsu]

Commit-ID:  ee6a7354a3629f9b65bc18dbe393503e9440d6f5
Gitweb: https://git.kernel.org/tip/ee6a7354a3629f9b65bc18dbe393503e9440d6f5
Author: Masami Hiramatsu 
AuthorDate: Wed, 9 May 2018 21:58:15 +0900
Committer:  Thomas Gleixner 
CommitDate: Sun, 13 May 2018 19:52:55 +0200

kprobes/x86: Prohibit probing on exception masking instructions

Since MOV SS and POP SS instructions will delay the exceptions until the
next instruction is executed, single-stepping on it by kprobes must be
prohibited.

However, kprobes usually executes those instructions directly on trampoline
buffer (a.k.a. kprobe-booster), except for the kprobes which has
post_handler. Thus if kprobe user probes MOV SS with post_handler, it will
do single-stepping on the MOV SS.

This means it is safe that if it is used via ftrace or perf/bpf since those
don't use the post_handler.

Anyway, since the stack switching is a rare case, it is safer just
rejecting kprobes on such instructions.

Signed-off-by: Masami Hiramatsu 
Signed-off-by: Thomas Gleixner 
Cc: Ricardo Neri 
Cc: Francis Deslauriers 
Cc: Oleg Nesterov 
Cc: Alexei Starovoitov 
Cc: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: "H . Peter Anvin" 
Cc: Yonghong Song 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: "David S . Miller" 
Link: 
https://lkml.kernel.org/r/152587069574.17316.3311695234863248641.stgit@devbox

---
 arch/x86/include/asm/insn.h| 18 ++
 arch/x86/kernel/kprobes/core.c |  4 
 2 files changed, 22 insertions(+)

diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
index b3e32b010ab1..c2c01f84df75 100644
--- a/arch/x86/include/asm/insn.h
+++ b/arch/x86/include/asm/insn.h
@@ -208,4 +208,22 @@ static inline int insn_offset_immediate(struct insn *insn)
return insn_offset_displacement(insn) + insn->displacement.nbytes;
 }
 
+#define POP_SS_OPCODE 0x1f
+#define MOV_SREG_OPCODE 0x8e
+
+/*
+ * Intel SDM Vol.3A 6.8.3 states;
+ * "Any single-step trap that would be delivered following the MOV to SS
+ * instruction or POP to SS instruction (because EFLAGS.TF is 1) is
+ * suppressed."
+ * This function returns true if @insn is MOV SS or POP SS. On these
+ * instructions, single stepping is suppressed.
+ */
+static inline int insn_masking_exception(struct insn *insn)
+{
+   return insn->opcode.bytes[0] == POP_SS_OPCODE ||
+   (insn->opcode.bytes[0] == MOV_SREG_OPCODE &&
+X86_MODRM_REG(insn->modrm.bytes[0]) == 2);
+}
+
 #endif /* _ASM_X86_INSN_H */
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 0715f827607c..6f4d42377fe5 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -370,6 +370,10 @@ int __copy_instruction(u8 *dest, u8 *src, u8 *real, struct 
insn *insn)
if (insn->opcode.bytes[0] == BREAKPOINT_INSTRUCTION)
return 0;
 
+   /* We should not singlestep on the exception masking instructions */
+   if (insn_masking_exception(insn))
+   return 0;
+
 #ifdef CONFIG_X86_64
/* Only x86_64 has RIP relative instructions */
if (insn_rip_relative(insn)) {

Re: [PATCH 6/8] serial: Add Tegra Combined UART driver

[Andy Shevchenko]

On Tue, May 8, 2018 at 2:44 PM, Mikko Perttunen  wrote:
> The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows
> multiplexing multiple "virtual UARTs" into a single hardware serial
> port. The TCU is the primary serial port on Tegra194 devices.
>
> Add a TCU driver utilizing the mailbox framework, as the used mailboxes
> are part of Tegra HSP blocks that are already controlled by the Tegra
> HSP mailbox driver.

First question, can it be done utilizing SERDEV framework?

> +static void tegra_tcu_uart_set_mctrl(struct uart_port *port, unsigned int 
> mctrl)
> +{

> +   (void)port;
> +   (void)mctrl;

Huh?

> +}

> +static void tegra_tcu_uart_stop_tx(struct uart_port *port)
> +{
> +   (void)port;
> +}

Ditto.

> +   if (written == 3) {
> +   value |= 3 << 24;
> +   value |= BIT(26);
> +   mbox_send_message(tcu->tx, );

> +   }

(1)

> +   }
> +
> +   if (written) {
> +   value |= written << 24;
> +   value |= BIT(26);
> +   mbox_send_message(tcu->tx, );
> +   }

(2)

These are code duplications.

> +static void tegra_tcu_uart_stop_rx(struct uart_port *port)
> +{
> +   (void)port;
> +}
> +
> +static void tegra_tcu_uart_break_ctl(struct uart_port *port, int ctl)
> +{
> +   (void)port;
> +   (void)ctl;
> +}
> +
> +static int tegra_tcu_uart_startup(struct uart_port *port)
> +{
> +   (void)port;
> +
> +   return 0;
> +}
> +
> +static void tegra_tcu_uart_shutdown(struct uart_port *port)
> +{
> +   (void)port;
> +}
> +
> +static void tegra_tcu_uart_set_termios(struct uart_port *port,
> +  struct ktermios *new,
> +  struct ktermios *old)
> +{
> +   (void)port;
> +   (void)new;
> +   (void)old;
> +}

Remove those unused stub contents.

> +   return uart_set_options(_tcu_uart_port, cons,
> +   115200, 'n', 8, 'n');

Can't it be one line?

> +static void tegra_tcu_receive(struct mbox_client *client, void *msg_p)
> +{
> +   struct tty_port *port = _tcu_uart_port.state->port;

> +   uint32_t msg = *(uint32_t *)msg_p;

Redundant casting.

> +   unsigned int num_bytes;
> +   int i;
> +

> +   num_bytes = (msg >> 24) & 0x3;

Two magic numbers.

> +   for (i = 0; i < num_bytes; i++)
> +   tty_insert_flip_char(port, (msg >> (i*8)) & 0xff, TTY_NORMAL);
> +
> +   tty_flip_buffer_push(port);
> +}

> +MODULE_AUTHOR("Mikko Perttunen ");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("NVIDIA Tegra Combined UART driver");
> diff --git a/include/uapi/linux/serial_core.h 
> b/include/uapi/linux/serial_core.h
> index dce5f9dae121..eaf3c303cba6 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -281,4 +281,7 @@
>  /* MediaTek BTIF */
>  #define PORT_MTK_BTIF  117
>
> +/* NVIDIA Tegra Combined UART */
> +#define PORT_TEGRA_TCU 118

Check if there is an unused gap. IIRC we still have one near to 40ish.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 3/3] tty: implement led triggers

[Andy Shevchenko]

On Tue, May 8, 2018 at 1:05 PM, Uwe Kleine-König
 wrote:
> The rx trigger fires when data is pushed to the ldisc by the driver. This
> is a bit later than the actual receiving of data but has the nice benefit
> that it doesn't need adaption for each driver and isn't in the hot path.
>
> Similarly the tx trigger fires when data was copied from userspace and is
> given to the ldisc.

>  #include 
>  #include 
>  #include 
> +#include 

Even for unordered lists of inclusions I would still try to put new
lines in "somehow" ordered positions.
For example here, I would rather put it before llist.h.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 1/2] x86/amd_nb: Add support for Raven Ridge CPUs

[Guenter Roeck]

On 05/13/2018 07:21 AM, Thomas Gleixner wrote:

On Fri, 4 May 2018, Guenter Roeck wrote:


Add Raven Ridge root bridge and data fabric PCI IDs.
This is required for amd_pci_dev_to_node_id() and amd_smn_read().

Tested-by: Gabriel Craciunescu 
Signed-off-by: Guenter Roeck 


Guenter, if you want to take that through hwmon:



Yes, that was the idea.


 Acked-by: Thomas Gleixner 


Thanks!

Guenter


If not, let me know.


---
v3: No change.
v2: Use naming scheme suggested by Borislav Petkov.

  arch/x86/kernel/amd_nb.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c
index c88e0b127810..b481b95bd8f6 100644
--- a/arch/x86/kernel/amd_nb.c
+++ b/arch/x86/kernel/amd_nb.c
@@ -14,8 +14,11 @@
  #include 
  
  #define PCI_DEVICE_ID_AMD_17H_ROOT	0x1450

+#define PCI_DEVICE_ID_AMD_17H_M10H_ROOT0x15d0
  #define PCI_DEVICE_ID_AMD_17H_DF_F3   0x1463
  #define PCI_DEVICE_ID_AMD_17H_DF_F4   0x1464
+#define PCI_DEVICE_ID_AMD_17H_M10H_DF_F3 0x15eb
+#define PCI_DEVICE_ID_AMD_17H_M10H_DF_F4 0x15ec
  
  /* Protect the PCI config register pairs used for SMN and DF indirect access. */

  static DEFINE_MUTEX(smn_mutex);
@@ -24,6 +27,7 @@ static u32 *flush_words;
  
  static const struct pci_device_id amd_root_ids[] = {

{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_ROOT) },
+   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M10H_ROOT) },
{}
  };
  
@@ -39,6 +43,7 @@ const struct pci_device_id amd_nb_misc_ids[] = {

{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) },
+   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M10H_DF_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F3) },
{}
  };
@@ -51,6 +56,7 @@ static const struct pci_device_id amd_nb_link_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_DF_F4) },
+   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M10H_DF_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F4) },
{}
  };
--
2.7.4



--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/8] serial: Add Tegra Combined UART driver

[Jassi Brar]

On Tue, May 8, 2018 at 5:14 PM, Mikko Perttunen  wrote:


>
> +config SERIAL_TEGRA_TCU
> +   tristate "NVIDIA Tegra Combined UART"
> +   depends on ARCH_TEGRA && MAILBOX
> +   select SERIAL_CORE
> +   help
> + Support for the mailbox-based TCU (Tegra Combined UART) serial port.
> + TCU is a virtual serial port that allows multiplexing multiple data
> + streams into a single hardware serial port.
> +
Maybe make it depend upon TEGRA_HSP_MBOX ?

..

> +
> +static void tegra_tcu_write(const char *s, unsigned int count)
> +{
> +   struct tegra_tcu *tcu = tegra_tcu_uart_port.private_data;
> +   unsigned int written = 0, i = 0;
> +   bool insert_nl = false;
> +   uint32_t value = 0;
> +
> +   while (i < count) {
> +   if (insert_nl) {
> +   value |= '\n' << (written++ * 8);
> +   insert_nl = false;
> +   i++;
> +   } else if (s[i] == '\n') {
> +   value |= '\r' << (written++ * 8);
> +   insert_nl = true;
> +   } else {
> +   value |= s[i++] << (written++ * 8);
> +   }
> +
> +   if (written == 3) {
> +   value |= 3 << 24;
> +   value |= BIT(26);
> +   mbox_send_message(tcu->tx, );
>
How is this supposed to work? tegra_hsp_doorbell_send_data() ignores
the second argument.

Re: [GIT PULL 5/5] ARM: exynos: mach/soc for v4.18

[Krzysztof Kozlowski]

On Sun, May 13, 2018 at 5:42 PM, Krzysztof Kozlowski  wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
>   Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-soc-4.18
>
> for you to fetch changes up to 9ad9a2183bf51da7f8840f2e7087816c0fc8c91d:
>
>   ARM: exynos: Remove unused soc_is_exynos{4,5} (2018-05-13 14:07:03 +0200)
>
> 
> Samsung mach/soc changes for v4.18
>
> 1. Remove at24_platform_data in S3C2440.
> 2. Fix invalid SPDX identifier.
> 3. Remove Exynos5440 entirely.
> 4. Cleanups.
> 5. Remove static mapping of SCU SFR and rely on DTS.
>
> 
> Bartlomiej Zolnierkiewicz (1):
>   ARM: exynos: no need to select ARCH_HAS_BANDGAP any longer
>
> Bartosz Golaszewski (1):
>   ARM: s3c24xx: mini2440: Use device properties for at24 eeprom
>
> Krzysztof Kozlowski (1):
>   ARM: exynos: Remove support for Exynos5440

I forgot to mention here possible conflict with dma-mapping tree and
its commit 4965a68780c5 ("arch: define the ARCH_DMA_ADDR_T_64BIT
config symbol in lib/Kconfig"). Since Exynos5440 is going away,
conflict is easy to solve - just remove.

Best regards,
Krzysztof

[PATCH v2] platform/x86: ideapad-laptop: Add fn-lock setting

[Oleg Keri]

Some of latest Lenovo ideapad laptops do not have UEFI/BIOS setting for
switching fn-lock mode. This commit adds related acpi calls to ideapad
platform driver. However setting is available via sysfs.

Signed-off-by: Oleg Keri 
---
 .../ABI/testing/sysfs-platform-ideapad-laptop | 13 +
 drivers/platform/x86/ideapad-laptop.c | 52 +--
 2 files changed, 62 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-platform-ideapad-laptop 
b/Documentation/ABI/testing/sysfs-platform-ideapad-laptop
index 597a2f3d..bc1e712d 100644
--- a/Documentation/ABI/testing/sysfs-platform-ideapad-laptop
+++ b/Documentation/ABI/testing/sysfs-platform-ideapad-laptop
@@ -25,3 +25,16 @@ Description:
Control touchpad mode.
* 1 -> Switched On
* 0 -> Switched Off
+
+What:  /sys/bus/pci/devices///VPC2004:00/fn_lock
+Date:  May 2018
+KernelVersion: 4.17
+Contact:   "Oleg Keri "
+Description:
+   Control fn-lock mode.
+   * 1 -> Switched On
+   * 0 -> Switched Off
+
+   For example:
+   # echo "0" >\
+   /sys/bus/pci/devices/:00:1f.0/PNP0C09:00/VPC2004:00/fn_lock
diff --git a/drivers/platform/x86/ideapad-laptop.c 
b/drivers/platform/x86/ideapad-laptop.c
index 535199c9..2f4991fb 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -43,6 +43,7 @@
 #define IDEAPAD_RFKILL_DEV_NUM (3)
 
 #define BM_CONSERVATION_BIT (5)
+#define HA_FNLOCK_BIT   (10)
 
 #define CFG_BT_BIT (16)
 #define CFG_3G_BIT (17)
@@ -59,6 +60,8 @@ static const char *const ideapad_wmi_fnesc_events[] = {
 enum {
BMCMD_CONSERVATION_ON = 3,
BMCMD_CONSERVATION_OFF = 5,
+   HACMD_FNLOCK_ON = 0xe,
+   HACMD_FNLOCK_OFF = 0xf,
 };
 
 enum {
@@ -139,11 +142,11 @@ static int method_gbmd(acpi_handle handle, unsigned long 
*ret)
return result;
 }
 
-static int method_sbmc(acpi_handle handle, int cmd)
+static int method_int1(acpi_handle handle, char *method, int cmd)
 {
acpi_status status;
 
-   status = acpi_execute_simple_method(handle, "SBMC", cmd);
+   status = acpi_execute_simple_method(handle, method, cmd);
return ACPI_FAILURE(status) ? -1 : 0;
 }
 
@@ -487,7 +490,7 @@ static ssize_t conservation_mode_store(struct device *dev,
if (ret)
return ret;
 
-   ret = method_sbmc(priv->adev->handle, state ?
+   ret = method_int1(priv->adev->handle, "SBMC", state ?
  BMCMD_CONSERVATION_ON :
  BMCMD_CONSERVATION_OFF);
if (ret < 0)
@@ -497,11 +500,51 @@ static ssize_t conservation_mode_store(struct device *dev,
 
 static DEVICE_ATTR_RW(conservation_mode);
 
+static ssize_t fn_lock_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct ideapad_private *priv = dev_get_drvdata(dev);
+   unsigned long result;
+   int hals;
+   int fail = read_method_int(priv->adev->handle, "HALS", );
+
+   if (fail)
+   return sprintf(buf, "-1\n");
+
+   result = hals;
+   return sprintf(buf, "%u\n", test_bit(HA_FNLOCK_BIT, ));
+}
+
+static ssize_t fn_lock_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct ideapad_private *priv = dev_get_drvdata(dev);
+   bool state;
+   int ret;
+
+   ret = kstrtobool(buf, );
+   if (ret)
+   return ret;
+
+   ret = method_int1(priv->adev->handle, "SALS", state ?
+ HACMD_FNLOCK_ON :
+ HACMD_FNLOCK_OFF);
+   if (ret < 0)
+   return -EIO;
+   return count;
+}
+
+static DEVICE_ATTR_RW(fn_lock);
+
+
 static struct attribute *ideapad_attributes[] = {
_attr_camera_power.attr,
_attr_fan_mode.attr,
_attr_touchpad.attr,
_attr_conservation_mode.attr,
+   _attr_fn_lock.attr,
NULL
 };
 
@@ -522,6 +565,9 @@ static umode_t ideapad_is_visible(struct kobject *kobj,
} else if (attr == _attr_conservation_mode.attr) {
supported = acpi_has_method(priv->adev->handle, "GBMD") &&
acpi_has_method(priv->adev->handle, "SBMC");
+   } else if (attr == _attr_fn_lock.attr) {
+   supported = acpi_has_method(priv->adev->handle, "HALS") &&
+   acpi_has_method(priv->adev->handle, "SALS");
} else
supported = true;
 
-- 
2.17.0

Re: [PATCH v2] {net, IB}/mlx5: Use 'kvfree()' for memory allocated by 'kvzalloc()'

[Eric Dumazet]

On 05/13/2018 12:00 AM, Christophe JAILLET wrote:
> When 'kvzalloc()' is used to allocate memory, 'kvfree()' must be used to
> free it.
> 
> Signed-off-by: Christophe JAILLET 
> ---
> v1 -> v2: More places to update have been added to the patch


Please add relevant Fixes: tag(s)

Re: [PATCH v5 03/13] mm: Assign memcg-aware shrinkers bitmap to memcg

[Vladimir Davydov]

On Thu, May 10, 2018 at 12:52:36PM +0300, Kirill Tkhai wrote:
> Imagine a big node with many cpus, memory cgroups and containers.
> Let we have 200 containers, every container has 10 mounts,
> and 10 cgroups. All container tasks don't touch foreign
> containers mounts. If there is intensive pages write,
> and global reclaim happens, a writing task has to iterate
> over all memcgs to shrink slab, before it's able to go
> to shrink_page_list().
> 
> Iteration over all the memcg slabs is very expensive:
> the task has to visit 200 * 10 = 2000 shrinkers
> for every memcg, and since there are 2000 memcgs,
> the total calls are 2000 * 2000 = 400.
> 
> So, the shrinker makes 4 million do_shrink_slab() calls
> just to try to isolate SWAP_CLUSTER_MAX pages in one
> of the actively writing memcg via shrink_page_list().
> I've observed a node spending almost 100% in kernel,
> making useless iteration over already shrinked slab.
> 
> This patch adds bitmap of memcg-aware shrinkers to memcg.
> The size of the bitmap depends on bitmap_nr_ids, and during
> memcg life it's maintained to be enough to fit bitmap_nr_ids
> shrinkers. Every bit in the map is related to corresponding
> shrinker id.
> 
> Next patches will maintain set bit only for really charged
> memcg. This will allow shrink_slab() to increase its
> performance in significant way. See the last patch for
> the numbers.
> 
> Signed-off-by: Kirill Tkhai 
> ---
>  include/linux/memcontrol.h |   21 
>  mm/memcontrol.c|  116 
> 
>  mm/vmscan.c|   16 ++
>  3 files changed, 152 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 6cbea2f25a87..e5e7e0fc7158 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -105,6 +105,17 @@ struct lruvec_stat {
>   long count[NR_VM_NODE_STAT_ITEMS];
>  };
>  
> +#ifdef CONFIG_MEMCG_SHRINKER
> +/*
> + * Bitmap of shrinker::id corresponding to memcg-aware shrinkers,
> + * which have elements charged to this memcg.
> + */
> +struct memcg_shrinker_map {
> + struct rcu_head rcu;
> + unsigned long map[0];
> +};
> +#endif /* CONFIG_MEMCG_SHRINKER */
> +

AFAIR we don't normally ifdef structure definitions.

>  /*
>   * per-zone information in memory controller.
>   */
> @@ -118,6 +129,9 @@ struct mem_cgroup_per_node {
>  
>   struct mem_cgroup_reclaim_iter  iter[DEF_PRIORITY + 1];
>  
> +#ifdef CONFIG_MEMCG_SHRINKER
> + struct memcg_shrinker_map __rcu *shrinker_map;
> +#endif
>   struct rb_node  tree_node;  /* RB tree node */
>   unsigned long   usage_in_excess;/* Set to the value by which */
>   /* the soft limit is exceeded*/
> @@ -1255,4 +1269,11 @@ static inline void memcg_put_cache_ids(void)
>  
>  #endif /* CONFIG_MEMCG && !CONFIG_SLOB */
>  
> +#ifdef CONFIG_MEMCG_SHRINKER

> +#define MEMCG_SHRINKER_MAP(memcg, nid) (memcg->nodeinfo[nid]->shrinker_map)

I don't really like this helper macro. Accessing shrinker_map directly
looks cleaner IMO.

> +
> +extern int memcg_shrinker_nr_max;

As I've mentioned before, the capacity of shrinker map should be a
private business of memcontrol.c IMHO. We shouldn't use it in vmscan.c
as max shrinker id, instead we should introduce another variable for
this, private to vmscan.c.

> +extern int memcg_expand_shrinker_maps(int old_id, int id);

... Then this function would take just one argument, max id, and would
update shrinker_map capacity if necessary in memcontrol.c under the
corresponding mutex, which would look much more readable IMHO as all
shrinker_map related manipulations would be isolated in memcontrol.c.

> +#endif /* CONFIG_MEMCG_SHRINKER */
> +
>  #endif /* _LINUX_MEMCONTROL_H */
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 3df3efa7ff40..18e0fdf302a9 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -322,6 +322,116 @@ struct workqueue_struct *memcg_kmem_cache_wq;
>  
>  #endif /* !CONFIG_SLOB */
>  
> +#ifdef CONFIG_MEMCG_SHRINKER
> +int memcg_shrinker_nr_max;

memcg_shrinker_map_capacity, may be?

> +static DEFINE_MUTEX(shrinkers_nr_max_mutex);

memcg_shrinker_map_mutex?

> +
> +static void memcg_free_shrinker_map_rcu(struct rcu_head *head)
> +{
> + kvfree(container_of(head, struct memcg_shrinker_map, rcu));
> +}
> +
> +static int memcg_expand_one_shrinker_map(struct mem_cgroup *memcg,
> +  int size, int old_size)

If you followed my advice and made the shrinker_map_capacity private to
memcontrol.c, you wouldn't need to pass old_size here either, just max
shrinker id.

> +{
> + struct memcg_shrinker_map *new, *old;
> + int nid;
> +
> + lockdep_assert_held(_nr_max_mutex);
> +
> + for_each_node(nid) {
> + old = rcu_dereference_protected(MEMCG_SHRINKER_MAP(memcg, nid), 
> true);
> + /* Not yet online 

Re: [PATCH 1/1] Drivers: hv: vmbus: enable VMBus protocol version 5.0

[Stephen Hemminger]

On Sat, 12 May 2018 02:30:33 -0700
k...@linuxonhyperv.com wrote:

>  int vmbus_post_msg(void *buffer, size_t buflen, bool can_sleep)
>  {
> + struct vmbus_channel_message_header *hdr;
>   union hv_connection_id conn_id;
>   int ret = 0;
>   int retries = 0;
>   u32 usec = 1;
>  
>   conn_id.asu32 = 0;
> - conn_id.u.id = VMBUS_MESSAGE_CONNECTION_ID;
> + conn_id.u.id = vmbus_connection.msg_conn_id;
>  
>   /*
>* hv_post_message() can have transient failures because of
> @@ -372,6 +400,18 @@ int vmbus_post_msg(void *buffer, size_t buflen, bool 
> can_sleep)
>  
>   switch (ret) {
>   case HV_STATUS_INVALID_CONNECTION_ID:
> + /*
> +  * See vmbus_negotiate_version(): VMBus protocol 5.0
> +  * requires that we must use
> +  * VMBUS_MESSAGE_CONNECTION_ID_4 for the Initiate
> +  * Contact message, but on old hosts that only
> +  * support VMBus protocol 4.0 or lower, here we get
> +  * HV_STATUS_INVALID_CONNECTION_ID and we should
> +  * return an error immediately without retrying.
> +  */
> + hdr = (struct vmbus_channel_message_header *)buffer;

Hate to pick o the details, but buffer is void * so cast is not necessary here.

[PATCH] [RFC] bpf: tracing: new helper bpf_get_current_cgroup_ino

[Alban Crequy]

From: Alban Crequy 

bpf_get_current_cgroup_ino() allows BPF trace programs to get the inode
of the cgroup where the current process resides.

My use case is to get statistics about syscalls done by a specific
Kubernetes container. I have a tracepoint on raw_syscalls/sys_enter and
a BPF map containing the cgroup inode that I want to trace. I use
bpf_get_current_cgroup_ino() and I quickly return from the tracepoint if
the inode is not in the BPF hash map.

Without this BPF helper, I would need to keep track of all pids in the
container. The Netlink proc connector can be used to follow process
creation and destruction but it is racy.

This patch only looks at the memory cgroup, which was enough for me
since each Kubernetes container is placed in a different mem cgroup.
For a generic implementation, I'm not sure how to proceed: it seems I
would need to use 'for_each_root(root)' (see example in
proc_cgroup_show() from kernel/cgroup/cgroup.c) but I don't know if
taking the cgroup mutex is possible in the BPF helper function. It might
be ok in the tracepoint raw_syscalls/sys_enter but could the mutex
already be taken in some other tracepoints?

Signed-off-by: Alban Crequy 
---
 include/uapi/linux/bpf.h | 11 ++-
 kernel/trace/bpf_trace.c | 25 +
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index c5ec89732a8d..38ac3959cdf3 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -755,6 +755,14 @@ union bpf_attr {
  * @addr: pointer to struct sockaddr to bind socket to
  * @addr_len: length of sockaddr structure
  * Return: 0 on success or negative error code
+ *
+ * u64 bpf_get_current_cgroup_ino(hierarchy, flags)
+ * Get the cgroup{1,2} inode of current task under the specified hierarchy.
+ * @hierarchy: cgroup hierarchy
+ * @flags: reserved for future use
+ * Return:
+ *   == 0 error
+ *> 0 inode of the cgroup
  */
 #define __BPF_FUNC_MAPPER(FN)  \
FN(unspec), \
@@ -821,7 +829,8 @@ union bpf_attr {
FN(msg_apply_bytes),\
FN(msg_cork_bytes), \
FN(msg_pull_data),  \
-   FN(bind),
+   FN(bind),   \
+   FN(get_current_cgroup_ino),
 
 /* integer value in 'imm' field of BPF_CALL instruction selects which helper
  * function eBPF program intends to call
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 56ba0f2a01db..9bf92a786639 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -524,6 +524,29 @@ static const struct bpf_func_proto 
bpf_probe_read_str_proto = {
.arg3_type  = ARG_ANYTHING,
 };
 
+BPF_CALL_2(bpf_get_current_cgroup_ino, u32, hierarchy, u64, flags)
+{
+   // TODO: pick the correct hierarchy instead of the mem controller
+   struct cgroup *cgrp = task_cgroup(current, memory_cgrp_id);
+
+   if (unlikely(!cgrp))
+   return -EINVAL;
+   if (unlikely(hierarchy))
+   return -EINVAL;
+   if (unlikely(flags))
+   return -EINVAL;
+
+   return cgrp->kn->id.ino;
+}
+
+static const struct bpf_func_proto bpf_get_current_cgroup_ino_proto = {
+   .func   = bpf_get_current_cgroup_ino,
+   .gpl_only   = false,
+   .ret_type   = RET_INTEGER,
+   .arg1_type  = ARG_DONTCARE,
+   .arg2_type  = ARG_DONTCARE,
+};
+
 static const struct bpf_func_proto *
 tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
 {
@@ -564,6 +587,8 @@ tracing_func_proto(enum bpf_func_id func_id, const struct 
bpf_prog *prog)
return _get_prandom_u32_proto;
case BPF_FUNC_probe_read_str:
return _probe_read_str_proto;
+   case BPF_FUNC_get_current_cgroup_ino:
+   return _get_current_cgroup_ino_proto;
default:
return NULL;
}
-- 
2.14.3

[PATCH v2] edac: fix skx_edac build error when ACPI_NFIT=m

[Randy Dunlap]

From: Randy Dunlap 

Prevent build error when CONFIG_ACPI_NFIT=m and CONFIG_EDAC_SKX=y
by limiting EDAC_SKX based on how ACPI_NFIT is set.

Fixes this build error:
drivers/edac/skx_edac.o: In function `get_nvdimm_info':
../drivers/edac/skx_edac.c:399: undefined reference to `nfit_get_smbios_id'

Fixes: 58ca9ac1463d ("EDAC, skx_edac: Detect non-volatile DIMMs")

Reported-by: kbuild test robot 
Signed-off-by: Randy Dunlap 
Cc: Tony Luck 
Cc: Borislav Petkov 
Cc: Mauro Carvalho Chehab 
Cc: sta...@vger.kernel.org
---
 drivers/edac/Kconfig |1 +
 1 file changed, 1 insertion(+)

v2: add comment in Kconfig file

--- lnx-417-rc4.orig/drivers/edac/Kconfig
+++ lnx-417-rc4/drivers/edac/Kconfig
@@ -232,6 +232,7 @@ config EDAC_SBRIDGE
 config EDAC_SKX
tristate "Intel Skylake server Integrated MC"
depends on PCI && X86_64 && X86_MCE_INTEL && PCI_MMCONFIG
+   depends on ACPI_NFIT || !ACPI_NFIT # if ACPI_NFIT=m, EDAC_SKX can't be y
select DMI
help
  Support for error detection and correction the Intel

[tip:x86/urgent] uprobes/x86: Prohibit probing on MOV SS instruction

[tip-bot for Masami Hiramatsu]

Commit-ID:  13ebe18c94f5b0665c01ae7fad2717ae959f4212
Gitweb: https://git.kernel.org/tip/13ebe18c94f5b0665c01ae7fad2717ae959f4212
Author: Masami Hiramatsu 
AuthorDate: Wed, 9 May 2018 21:58:45 +0900
Committer:  Thomas Gleixner 
CommitDate: Sun, 13 May 2018 19:52:56 +0200

uprobes/x86: Prohibit probing on MOV SS instruction

Since MOV SS and POP SS instructions will delay the exceptions until the
next instruction is executed, single-stepping on it by uprobes must be
prohibited.

uprobe already rejects probing on POP SS (0x1f), but allows probing on MOV
SS (0x8e and reg == 2).  This checks the target instruction and if it is
MOV SS or POP SS, returns -ENOTSUPP to reject probing.

Signed-off-by: Masami Hiramatsu 
Signed-off-by: Thomas Gleixner 
Acked-by: Oleg Nesterov 
Cc: Ricardo Neri 
Cc: Francis Deslauriers 
Cc: Alexei Starovoitov 
Cc: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: "H . Peter Anvin" 
Cc: Yonghong Song 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: "David S . Miller" 
Link: 
https://lkml.kernel.org/r/152587072544.17316.5950935243917346341.stgit@devbox

---
 arch/x86/kernel/uprobes.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 85c7ef23d99f..c84bb5396958 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -299,6 +299,10 @@ static int uprobe_init_insn(struct arch_uprobe *auprobe, 
struct insn *insn, bool
if (is_prefix_bad(insn))
return -ENOTSUPP;
 
+   /* We should not singlestep on the exception masking instructions */
+   if (insn_masking_exception(insn))
+   return -ENOTSUPP;
+
if (x86_64)
good_insns = good_insns_64;
else

PROBLEM: "ACPI Error: Method parse/execution failed" and "ACPI BIOS Error (bug): Failure looking up" related

[Jeffrin Thalakkottoor]

hello ,

the error from "dmesg -l err"  related ...

->

[1.709950] ACPI BIOS Error (bug): Failure looking up
[\_SB.PCI0.LPCB.HEC.ECWT], AE_NOT_FOUND (20180313/psargs-330)
[1.710045] ACPI Error: Method parse/execution failed
\_TZ.FN00._ON, AE_NOT_FOUND (20180313/psparse-516)
[1.710208] ACPI BIOS Error (bug): Failure looking up
[\_SB.PCI0.LPCB.HEC.ECWT], AE_NOT_FOUND (20180313/psargs-330)
[1.710267] ACPI Error: Method parse/execution failed
\_TZ.FN00._ON, AE_NOT_FOUND (20180313/psparse-516)
[1.710338] acpi PNP0C0B:00: Failed to set initial power state
[1.710846] ACPI BIOS Error (bug): Failure looking up
[\_SB.PCI0.LPCB.HEC.ECRD], AE_NOT_FOUND (20180313/psargs-330)
[1.710938] ACPI Error: Method parse/execution failed
\_TZ.TZ00._TMP, AE_NOT_FOUND (20180313/psparse-516)
[1.711588] ACPI BIOS Error (bug): Failure looking up
[\_SB.PCI0.LPCB.HEC.ECRD], AE_NOT_FOUND (20180313/psargs-330)
[1.711681] ACPI Error: Method parse/execution failed
\_TZ.TZ00._TMP, AE_NOT_FOUND (20180313/psparse-516)
[1.711960] ACPI BIOS Error (bug): Failure looking up
[\_SB.PCI0.LPCB.HEC.ECRD], AE_NOT_FOUND (20180313/psargs-330)
[1.712054] ACPI Error: Method parse/execution failed
\_TZ.TZ01._TMP, AE_NOT_FOUND (20180313/psparse-516)
[1.712471] ACPI BIOS Error (bug): Failure looking up
[\_SB.PCI0.LPCB.HEC.ECRD], AE_NOT_FOUND (20180313/psargs-330)
[1.712552] ACPI Error: Method parse/execution failed
\_TZ.TZ01._TMP, AE_NOT_FOUND (20180313/psparse-516)

->



$awk -f scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux debian 4.17.0-rc4+ #24 SMP Sat May 12 19:26:27 IST 2018 x86_64 GNU/Linux

GNU Make4.2.1
Binutils2.30
Util-linux  2.31.1
Mount2.31.1
Linux C Library  2.27
Dynamic linker (ldd) 2.27
readlink: missing operand
Try 'readlink --help' for more information.
Procps  3.3.14
Kbd  2.0.4
Console-tools2.0.4
Sh-utils8.28
Udev238
Modules Loaded  ac acpi_pad acpi_thermal_rel ahci autofs4 battery
binfmt_misc bluetooth bnep btbcm btintel btrfs btrtl btusb button
cdrom cfg80211 cmac coretemp cpuid crc32c_intel crc32_pclmul
crct10dif_pclmul cryptd drm drm_kms_helper ecdh_generic efi_pstore
efivarfs efivars ehci_hcd ehci_pci evdev fan fat fuse
ghash_clmulni_intel hid hp_wireless hp_wmi i2c_algo_bit i2c_hid
i2c_i801 i915 int3400_thermal int340x_thermal_zone intel_cstate
intel_pch_thermal intel_powerclamp intel_rapl intel_rapl_perf
intel_soc_dts_iosf intel_uncore ip_tables irqbypass
iTCO_vendor_support iTCO_wdt joydev kvm kvm_intel libahci libata
libcrc32c loop lp lpc_ich media mei mei_me mfd_core mii nls_ascii
nls_cp437 parport parport_pc pcspkr ppdev processor_thermal_device
psmouse r8169 raid6_pq rfcomm rfkill scsi_mod sd_mod serio_raw sg
shpchp snd snd_hda_codec snd_hda_codec_generic snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_core snd_hda_intel snd_hwdep snd_pcm
snd_timer soundcore sparse_keymap sr_mod sunrpc thermal usbcore
uvcvideo vfat video videobuf2_common videobuf2_memops videobuf2_v4l2
videobuf2_vmalloc videodev wl wmi wmi_bmof x86_pkg_temp_thermal xfs
xhci_hcd xhci_pci xor x_tables xxhash zstd_compress zstd_decompress


$uname -a
Linux debian 4.17.0-rc4+ #24 SMP Sat May 12 19:26:27 IST 2018 x86_64 GNU/Linux
$

Reported-by: Jeffrin Jose T  

-- 
software engineer
rajagiri school of engineering and technology

Re: [PATCH v3 1/2] x86/amd_nb: Add support for Raven Ridge CPUs

[Thomas Gleixner]

On Fri, 4 May 2018, Guenter Roeck wrote:

> Add Raven Ridge root bridge and data fabric PCI IDs.
> This is required for amd_pci_dev_to_node_id() and amd_smn_read().
> 
> Tested-by: Gabriel Craciunescu 
> Signed-off-by: Guenter Roeck 

Guenter, if you want to take that through hwmon:

 Acked-by: Thomas Gleixner 

If not, let me know.

> ---
> v3: No change.
> v2: Use naming scheme suggested by Borislav Petkov.
> 
>  arch/x86/kernel/amd_nb.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c
> index c88e0b127810..b481b95bd8f6 100644
> --- a/arch/x86/kernel/amd_nb.c
> +++ b/arch/x86/kernel/amd_nb.c
> @@ -14,8 +14,11 @@
>  #include 
>  
>  #define PCI_DEVICE_ID_AMD_17H_ROOT   0x1450
> +#define PCI_DEVICE_ID_AMD_17H_M10H_ROOT  0x15d0
>  #define PCI_DEVICE_ID_AMD_17H_DF_F3  0x1463
>  #define PCI_DEVICE_ID_AMD_17H_DF_F4  0x1464
> +#define PCI_DEVICE_ID_AMD_17H_M10H_DF_F3 0x15eb
> +#define PCI_DEVICE_ID_AMD_17H_M10H_DF_F4 0x15ec
>  
>  /* Protect the PCI config register pairs used for SMN and DF indirect 
> access. */
>  static DEFINE_MUTEX(smn_mutex);
> @@ -24,6 +27,7 @@ static u32 *flush_words;
>  
>  static const struct pci_device_id amd_root_ids[] = {
>   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_ROOT) },
> + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M10H_ROOT) },
>   {}
>  };
>  
> @@ -39,6 +43,7 @@ const struct pci_device_id amd_nb_misc_ids[] = {
>   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
>   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
>   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) },
> + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M10H_DF_F3) },
>   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F3) },
>   {}
>  };
> @@ -51,6 +56,7 @@ static const struct pci_device_id amd_nb_link_ids[] = {
>   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F4) },
>   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F4) },
>   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_DF_F4) },
> + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M10H_DF_F4) },
>   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F4) },
>   {}
>  };
> -- 
> 2.7.4
> 
> 

KASAN: slab-out-of-bounds Read in vmx_vcpu_run

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:036db8bd9637 Merge branch 'for-4.17-fixes' of git://git.ke..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11228e0780
kernel config:  https://syzkaller.appspot.com/x/.config?x=31f4b3733894ef79
dashboard link: https://syzkaller.appspot.com/bug?extid=d8f8a4d784b336549b5b
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+d8f8a4d784b336549...@syzkaller.appspotmail.com

==
BUG: KASAN: slab-out-of-bounds in msr_write_intercepted  
arch/x86/kvm/vmx.c:2126 [inline]
BUG: KASAN: slab-out-of-bounds in vmx_vcpu_run+0x2379/0x25f0  
arch/x86/kvm/vmx.c:9869

Read of size 8 at addr 8801d3efc840 by task syz-executor1/11848

CPU: 1 PID: 11848 Comm: syz-executor1 Not tainted 4.17.0-rc4+ #39
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 print_address_description+0x6c/0x20b mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
 msr_write_intercepted arch/x86/kvm/vmx.c:2126 [inline]
 vmx_vcpu_run+0x2379/0x25f0 arch/x86/kvm/vmx.c:9869

Allocated by task 11848:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
 kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
 kmalloc include/linux/slab.h:512 [inline]
 kzalloc include/linux/slab.h:701 [inline]
 tcp_sendmsg_fastopen net/ipv4/tcp.c:1145 [inline]
 tcp_sendmsg_locked+0x2ff7/0x3ee0 net/ipv4/tcp.c:1209
 tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1447
 inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg+0xd5/0x120 net/socket.c:639
 __sys_sendto+0x3d7/0x670 net/socket.c:1789
 __do_sys_sendto net/socket.c:1801 [inline]
 __se_sys_sendto net/socket.c:1797 [inline]
 __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1797
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 2388:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
 __cache_free mm/slab.c:3498 [inline]
 kfree+0xd9/0x260 mm/slab.c:3813
 inotify_free_event+0x15/0x20 fs/notify/inotify/inotify_fsnotify.c:182
 fsnotify_destroy_event.part.1+0x1a8/0x270 fs/notify/notification.c:87
 fsnotify_destroy_event+0x69/0x80 fs/notify/notification.c:74
 inotify_read+0x5a8/0x9b0 fs/notify/inotify/inotify_user.c:246
 __vfs_read+0x10f/0xa50 fs/read_write.c:416
 vfs_read+0x17f/0x3d0 fs/read_write.c:452
 ksys_read+0xf9/0x250 fs/read_write.c:578
 __do_sys_read fs/read_write.c:588 [inline]
 __se_sys_read fs/read_write.c:586 [inline]
 __x64_sys_read+0x73/0xb0 fs/read_write.c:586
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at 8801d3efc800
 which belongs to the cache kmalloc-64 of size 64
The buggy address is located 0 bytes to the right of
 64-byte region [8801d3efc800, 8801d3efc840)
The buggy address belongs to the page:
page:ea00074fbf00 count:1 mapcount:0 mapping:8801d3efc000 index:0x0
flags: 0x2fffc000100(slab)
raw: 02fffc000100 8801d3efc000  00010020
raw: ea00076687a0 ea000766e660 8801da800340 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 8801d3efc700: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
 8801d3efc780: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc

8801d3efc800: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc

   ^
 8801d3efc880: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
 8801d3efc900: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
==


---
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: BUG: workqueue lockup (2)

[Tetsuo Handa]

Eric Biggers wrote:
> Generally it's best to close syzbot bug reports once the original cause is
> fixed, so that syzbot can continue to report other bugs with the same 
> signature.

That's difficult to judge. Closing as soon as the original cause is fixed allows
syzbot to try to report different reproducer for different bugs. But at the 
same time,
different/similar bugs which were reported in that report (or comments in the 
discussion
for that report) will become almost invisible from users (because users 
unlikely check
other reports in already fixed bugs).

An example is

  general protection fault in kernfs_kill_sb (2)
  https://syzkaller.appspot.com/bug?id=903af3e08fc7ec60e57d9c9b93b035f4fb038d9a

where the cause of above report was already pointed out in the discussion for
the below report.

  general protection fault in kernfs_kill_sb
  https://syzkaller.appspot.com/bug?id=d7db6ecf34f099248e4ff404cd381a19a4075653

Since the latter is marked as "fixed on May 08 18:30", I worry that quite few
users would check the relationship.

> Note also that a "workqueue lockup" can be caused by almost anything in the
> kernel, I think.  This one for example is probably in the sound subsystem:
> https://syzkaller.appspot.com/text?tag=CrashReport=1767232b80
> 

Right. Maybe we should not stop the test upon "workqueue lockup" message, for
it is likely that the cause of lockup is that somebody is busy looping which
should have been reported shortly as "rcu detected stall".

Of course, there is possibility that "workqueue lockup" is reported because
cond_resched() was used when explicit schedule_timeout_*() is required, which
was the reason commit 82607adcf9cdf40f ("workqueue: implement lockup detector")
was added.

If we stop the test upon "workqueue lockup" message, maybe longer timeout (e.g.
300 seconds) is better so that rcu stall or hung task messages are reported
if rcu stall or hung task is occurring.

Re: BUG: workqueue lockup (2)

[Dmitry Vyukov]

On Sun, May 13, 2018 at 4:29 PM, Tetsuo Handa
 wrote:
> Eric Biggers wrote:
>> Generally it's best to close syzbot bug reports once the original cause is
>> fixed, so that syzbot can continue to report other bugs with the same 
>> signature.
>
> That's difficult to judge. Closing as soon as the original cause is fixed 
> allows
> syzbot to try to report different reproducer for different bugs. But at the 
> same time,
> different/similar bugs which were reported in that report (or comments in the 
> discussion
> for that report) will become almost invisible from users (because users 
> unlikely check
> other reports in already fixed bugs).
>
> An example is
>
>   general protection fault in kernfs_kill_sb (2)
>   
> https://syzkaller.appspot.com/bug?id=903af3e08fc7ec60e57d9c9b93b035f4fb038d9a
>
> where the cause of above report was already pointed out in the discussion for
> the below report.
>
>   general protection fault in kernfs_kill_sb
>   
> https://syzkaller.appspot.com/bug?id=d7db6ecf34f099248e4ff404cd381a19a4075653
>
> Since the latter is marked as "fixed on May 08 18:30", I worry that quite few
> users would check the relationship.
>
>> Note also that a "workqueue lockup" can be caused by almost anything in the
>> kernel, I think.  This one for example is probably in the sound subsystem:
>> https://syzkaller.appspot.com/text?tag=CrashReport=1767232b80
>>
>
> Right. Maybe we should not stop the test upon "workqueue lockup" message, for
> it is likely that the cause of lockup is that somebody is busy looping which
> should have been reported shortly as "rcu detected stall".
>
> Of course, there is possibility that "workqueue lockup" is reported because
> cond_resched() was used when explicit schedule_timeout_*() is required, which
> was the reason commit 82607adcf9cdf40f ("workqueue: implement lockup 
> detector")
> was added.
>
> If we stop the test upon "workqueue lockup" message, maybe longer timeout 
> (e.g.
> 300 seconds) is better so that rcu stall or hung task messages are reported
> if rcu stall or hung task is occurring.

Yes, we need order different stalls/lockups/hangs/etc according to
what can trigger what. E.g. rcu stall can trigger task hung and
workqueue lockup, but not the other way around.
There is https://github.com/google/syzkaller/issues/516 to track this.
But I did not yet have time to figure out all required changes.
If you have additional details, please add them there.

Re: [PATCH v2 1/7] bitops: Introduce the for_each_set_port_word macro

[Andy Shevchenko]

On Tue, May 8, 2018 at 4:26 PM, William Breathitt Gray
 wrote:
> This macro iterates for each group of bits (port word) with set bits,
> within a bitmap memory region. For each iteration, "port_word" is set to
> the found port word index, "word_index" is set to the word index of the
> bitmap containing the found port word, and "word_offset" is set to the
> bit offset of the found port word within the respective bitmap word.

Isn't that idea we discussed some time ago?

In any case, part "port" is too specific for a generic function like
this. Please, get rid of it completely. No-one knows what port means
here. Just makes a lot of confusion.

> --- a/lib/find_bit.c
> +++ b/lib/find_bit.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 

> +#include 

No need. It's included by bitmap.h IIRC.


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2] KVM: X86: Fix CR3 reserve bits

[Junaid Shahid]

On 05/13/2018 02:24 AM, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> MSB of CR3 is a reserved bit if the PCIDE bit is not set in CR4. 
> It should be checked when PCIDE bit is not set, however commit 
> 'd1cd3ce900441 ("KVM: MMU: check guest CR3 reserved bits based on 
> its physical address width")' removes the bit 63 checking 
> unconditionally. This patch fixes it by checking bit 63 of CR3 
> when PCIDE bit is not set in CR4.
> 
> Fixes: d1cd3ce900441 (KVM: MMU: check guest CR3 reserved bits based on its 
> physical address width)
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Junaid Shahid 
> Cc: Liran Alon 
> Signed-off-by: Wanpeng Li 
> ---
> v1 -> v2:
>  * remove CR3_PCID_INVD in rsvd when PCIDE is 1 instead of 
>removing CR3_PCID_INVD in new_value
> 
>  arch/x86/kvm/emulate.c | 4 +++-
>  arch/x86/kvm/x86.c | 2 +-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index b3705ae..143b7ae 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -4189,7 +4189,9 @@ static int check_cr_write(struct x86_emulate_ctxt *ctxt)
>   maxphyaddr = eax & 0xff;
>   else
>   maxphyaddr = 36;
> - rsvd = rsvd_bits(maxphyaddr, 62);
> + rsvd = rsvd_bits(maxphyaddr, 63);
> + if (ctxt->ops->get_cr(ctxt, 4) & X86_CR4_PCIDE)
> + rsvd &= ~CR3_PCID_INVD;
>   }
>  
>   if (new_val & rsvd)
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 87e4805..9a90668 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -863,7 +863,7 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
>   }
>  
>   if (is_long_mode(vcpu) &&
> - (cr3 & rsvd_bits(cpuid_maxphyaddr(vcpu), 62)))
> + (cr3 & rsvd_bits(cpuid_maxphyaddr(vcpu), 63)))
>   return 1;
>   else if (is_pae(vcpu) && is_paging(vcpu) &&
>  !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
> 

Reviewed-by: Junaid Shahid 

Re: [tip/core/rcu,16/21] rcu: Add funnel locking to rcu_start_this_gp()

[Paul E. McKenney]

On Sat, May 12, 2018 at 04:53:01PM -0700, Joel Fernandes wrote:
> On Sat, May 12, 2018 at 07:44:38AM -0700, Paul E. McKenney wrote:
> > On Sat, May 12, 2018 at 07:40:02AM -0700, Paul E. McKenney wrote:
> > > On Fri, May 11, 2018 at 11:03:25PM -0700, Joel Fernandes wrote:
> > > > On Sun, Apr 22, 2018 at 08:03:39PM -0700, Paul E. McKenney wrote:
> > > > > The rcu_start_this_gp() function had a simple form of funnel locking 
> > > > > that
> > > > > used only the leaves and root of the rcu_node tree, which is fine for
> > > > > systems with only a few hundred CPUs, but sub-optimal for systems 
> > > > > having
> > > > > thousands of CPUs.  This commit therefore adds full-tree funnel 
> > > > > locking.
> > > > > 
> > > > > This variant of funnel locking is unusual in the following ways:
> > > > > 
> > > > > 1.The leaf-level rcu_node structure's ->lock is held throughout.
> > > > >   Other funnel-locking implementations drop the leaf-level lock
> > > > >   before progressing to the next level of the tree.
> > > > > 
> > > > > 2.Funnel locking can be started at the root, which is convenient
> > > > >   for code that already holds the root rcu_node structure's 
> > > > > ->lock.
> > > > >   Other funnel-locking implementations start at the leaves.
> > > > > 
> > > > > 3.If an rcu_node structure other than the initial one believes
> > > > >   that a grace period is in progress, it is not necessary to
> > > > >   go further up the tree.  This is because grace-period cleanup
> > > > >   scans the full tree, so that marking the need for a subsequent
> > > > >   grace period anywhere in the tree suffices -- but only if
> > > > >   a grace period is currently in progress.
> > > > > 
> > > > > 4.It is possible that the RCU grace-period kthread has not yet
> > > > >   started, and this case must be handled appropriately.
> > > > > 
> > > > > However, the general approach of using a tree to control lock 
> > > > > contention
> > > > > is still in place.
> > > > > 
> > > > > Signed-off-by: Paul E. McKenney 
> > > > > ---
> > > > >  kernel/rcu/tree.c | 92 
> > > > > +--
> > > > >  1 file changed, 35 insertions(+), 57 deletions(-)
> > > > > 
> > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > > > index 94519c7d552f..d3c769502929 100644
> > > > > --- a/kernel/rcu/tree.c
> > > > > +++ b/kernel/rcu/tree.c
> > > > > @@ -1682,74 +1682,52 @@ static bool rcu_start_this_gp(struct rcu_node 
> > > > > *rnp, struct rcu_data *rdp,
> > > > >  {
> > > > >   bool ret = false;
> > > > >   struct rcu_state *rsp = rdp->rsp;
> > > > > - struct rcu_node *rnp_root = rcu_get_root(rsp);
> > > > > -
> > > > > - raw_lockdep_assert_held_rcu_node(rnp);
> > > > > -
> > > > > - /* If the specified GP is already known needed, return to 
> > > > > caller. */
> > > > > - trace_rcu_this_gp(rnp, rdp, c, TPS("Startleaf"));
> > > > > - if (need_future_gp_element(rnp, c)) {
> > > > > - trace_rcu_this_gp(rnp, rdp, c, TPS("Prestartleaf"));
> > > > > - goto out;
> > > > > - }
> > > > > + struct rcu_node *rnp_root;
> > > > >  
> > > > >   /*
> > > > > -  * If this rcu_node structure believes that a grace period is in
> > > > > -  * progress, then we must wait for the one following, which is 
> > > > > in
> > > > > -  * "c".  Because our request will be noticed at the end of the
> > > > > -  * current grace period, we don't need to explicitly start one.
> > > > > +  * Use funnel locking to either acquire the root rcu_node
> > > > > +  * structure's lock or bail out if the need for this grace 
> > > > > period
> > > > > +  * has already been recorded -- or has already started.  If 
> > > > > there
> > > > > +  * is already a grace period in progress in a non-leaf node, no
> > > > > +  * recording is needed because the end of the grace period will
> > > > > +  * scan the leaf rcu_node structures.  Note that rnp->lock must
> > > > > +  * not be released.
> > > > >*/
> > > > > - if (rnp->gpnum != rnp->completed) {
> > > > > - need_future_gp_element(rnp, c) = true;
> > > > > - trace_rcu_this_gp(rnp, rdp, c, TPS("Startedleaf"));
> > > > > - goto out;
> > > > 
> > > > Referring to the above negative diff as [1] (which I wanted to refer to 
> > > > later
> > > > in this message..)
> > > > 
> > > > > + raw_lockdep_assert_held_rcu_node(rnp);
> > > > > + trace_rcu_this_gp(rnp, rdp, c, TPS("Startleaf"));
> > > > > + for (rnp_root = rnp; 1; rnp_root = rnp_root->parent) {
> > > > > + if (rnp_root != rnp)
> > > > > + raw_spin_lock_rcu_node(rnp_root);
> > > > > + if (need_future_gp_element(rnp_root, c) ||
> > > > > + ULONG_CMP_GE(rnp_root->gpnum, c) ||
> > > > > + (rnp != rnp_root &&
> > > > 

[GIT PULL 3/5] ARM: dts: exynos: Stuff for v4.18

[Krzysztof Kozlowski]

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-dt-4.18

for you to fetch changes up to 83cb529b2ef4f3446e60e75522d76fdaaea4724c:

  ARM: dts: exynos: Update x and y properties for mms114 touchscreen 
(2018-05-13 15:15:49 +0200)


Samsung DTS ARM changes for v4.18

1. Add support for USB OTG port on Origen board.
2. Allow earlycon on Rinato board.
3. Cleanup from obsolete properties.
4. Fix DTC warnings.
5. Remove Exynos5440 entirely.
6. Add mem-2-mem Scaler devices.


Andi Shyti (1):
  ARM: dts: exynos: Update x and y properties for mms114 touchscreen

Andrzej Pietrasiewicz (1):
  ARM: dts: exynos: Add mem-2-mem Scaler devices

Krzysztof Kozlowski (11):
  ARM: dts: exynos: Move syscon poweroff and restart nodes under the PMU
  ARM: dts: exynos: Fix invalid node referenced by i2c20 alias in Peach Pit 
and Pi
  ARM: dts: exynos: Remove unnecessary address/size properties in Midas 
boards
  ARM: dts: exynos: Remove unnecessary address/size properties in Origen
  ARM: dts: exynos: Remove regulators node container in Origen and N710x
  ARM: dts: exynos: Bring order in fixed-regulators naming in Midas boards
  ARM: dts: exynos: Remove unnecessary address/size properties in 
dp-controller of Exynos5
  ARM: dts: exynos: Remove Exynos5440
  ARM: dts: s3c24xx: Remove skeleton.dtsi and fix DTC warning for /memory
  ARM: dts: s3c24xx: Fix unnecessary address/size cells DTC warnings
  ARM: dts: s3c64xx: Remove skeleton.dtsi and fix DTC warnings for /memory

Marek Szyprowski (3):
  ARM: dts: exynos: Add support for USB OTG port on Origen board
  ARM: dts: exynos: Add serial path for Rinato board to get earlycon support
  ARM: dts: exynos: Remove obsolete clock properties from power domains

Mathieu Malaterre (1):
  ARM: dts: exynos/s3c: Remove leading 0x and 0s from bindings notation

 .../bindings/arm/samsung/samsung-boards.txt|   2 -
 arch/arm/boot/dts/Makefile |   2 -
 arch/arm/boot/dts/exynos-syscon-restart.dtsi   |  28 +-
 arch/arm/boot/dts/exynos3250-rinato.dts|   4 +
 arch/arm/boot/dts/exynos3250.dtsi  |   2 +-
 arch/arm/boot/dts/exynos4.dtsi |   3 +-
 arch/arm/boot/dts/exynos4210-origen.dts|  34 +-
 arch/arm/boot/dts/exynos4210-trats.dts |   4 +-
 arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi|  36 +--
 arch/arm/boot/dts/exynos4412-midas.dtsi|  86 +++--
 arch/arm/boot/dts/exynos4412-n710x.dts |  16 +-
 arch/arm/boot/dts/exynos4412-origen.dts|   2 +-
 arch/arm/boot/dts/exynos4412.dtsi  |   2 +-
 arch/arm/boot/dts/exynos5.dtsi |   3 -
 arch/arm/boot/dts/exynos5250.dtsi  |   7 +-
 arch/arm/boot/dts/exynos5410.dtsi  |   1 +
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   4 +-
 arch/arm/boot/dts/exynos5420.dtsi  |  87 +++--
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi  |   2 +-
 arch/arm/boot/dts/exynos5440-sd5v1.dts |  42 ---
 arch/arm/boot/dts/exynos5440-ssdk5440.dts  |  81 -
 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi  |  20 --
 arch/arm/boot/dts/exynos5440-trip-points.dtsi  |  21 --
 arch/arm/boot/dts/exynos5440.dtsi  | 355 -
 arch/arm/boot/dts/exynos5800-peach-pi.dts  |   4 +-
 arch/arm/boot/dts/s3c2416-smdk2416.dts |   5 +-
 arch/arm/boot/dts/s3c2416.dtsi |  11 +-
 arch/arm/boot/dts/s3c24xx.dtsi |   4 +-
 arch/arm/boot/dts/s3c6410-mini6410.dts |   3 +-
 arch/arm/boot/dts/s3c6410-smdk6410.dts |   3 +-
 arch/arm/boot/dts/s3c64xx.dtsi |   4 +-
 31 files changed, 183 insertions(+), 695 deletions(-)
 delete mode 100644 arch/arm/boot/dts/exynos5440-sd5v1.dts
 delete mode 100644 arch/arm/boot/dts/exynos5440-ssdk5440.dts
 delete mode 100644 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
 delete mode 100644 arch/arm/boot/dts/exynos5440-trip-points.dtsi
 delete mode 100644 arch/arm/boot/dts/exynos5440.dtsi

[GIT PULL 1/5] ARM: defconfig: Exynos for v4.18

[Krzysztof Kozlowski]

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-defconfig-4.18

for you to fetch changes up to b0121046cacdbc99475871aceb2e9e57995c2ba1:

  ARM: multi_v7_config: enable S6E63J0X03 panel driver (2018-04-16 20:22:28 
+0200)


Samsung defconfig changes for v4.18

1. Enable Samsung S6E63J0X03 DSI panel.


Marek Szyprowski (2):
  ARM: exynos_defconfig: enable S6E63J0X03 panel driver
  ARM: multi_v7_config: enable S6E63J0X03 panel driver

 arch/arm/configs/exynos_defconfig   | 1 +
 arch/arm/configs/multi_v7_defconfig | 1 +
 2 files changed, 2 insertions(+)

[GIT PULL 5/5] ARM: exynos: mach/soc for v4.18

[Krzysztof Kozlowski]

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-soc-4.18

for you to fetch changes up to 9ad9a2183bf51da7f8840f2e7087816c0fc8c91d:

  ARM: exynos: Remove unused soc_is_exynos{4,5} (2018-05-13 14:07:03 +0200)


Samsung mach/soc changes for v4.18

1. Remove at24_platform_data in S3C2440.
2. Fix invalid SPDX identifier.
3. Remove Exynos5440 entirely.
4. Cleanups.
5. Remove static mapping of SCU SFR and rely on DTS.


Bartlomiej Zolnierkiewicz (1):
  ARM: exynos: no need to select ARCH_HAS_BANDGAP any longer

Bartosz Golaszewski (1):
  ARM: s3c24xx: mini2440: Use device properties for at24 eeprom

Krzysztof Kozlowski (1):
  ARM: exynos: Remove support for Exynos5440

Pankaj Dubey (2):
  ARM: exynos: Remove static mapping of SCU SFR
  ARM: exynos: Remove unused soc_is_exynos{4,5}

Thomas Gleixner (1):
  ARM: s3c24xx: Fix invalid SPDX identifier

Wolfram Sang (1):
  ARM: samsung: simplify getting .drvdata

 arch/arm/mach-exynos/Kconfig | 13 --
 arch/arm/mach-exynos/common.h| 17 -
 arch/arm/mach-exynos/exynos.c| 37 ++--
 arch/arm/mach-exynos/include/mach/map.h  |  2 --
 arch/arm/mach-exynos/platsmp.c   | 27 +++-
 arch/arm/mach-exynos/pm.c|  4 +--
 arch/arm/mach-exynos/suspend.c   |  4 +--
 arch/arm/mach-s3c24xx/h1940-bluetooth.c  |  2 +-
 arch/arm/mach-s3c24xx/mach-mini2440.c| 10 
 arch/arm/plat-samsung/adc.c  |  3 +--
 arch/arm/plat-samsung/include/plat/map-s5p.h |  4 ---
 11 files changed, 37 insertions(+), 86 deletions(-)

[GIT PULL 4/5] arm64: dts: exynos: Stuff for v4.18

[Krzysztof Kozlowski]

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-dt64-4.18

for you to fetch changes up to 8dd6203f32f20cb83469eb859efded9e403b3e9f:

  arm64: dts: exynos: Add mem-2-mem Scaler devices (2018-05-13 11:26:13 +0200)


Samsung DTS ARM64 changes for v4.18

1. Fix DTC warnings.
2. Add mem-2-mem Scaler devices.


Andrzej Pietrasiewicz (1):
  arm64: dts: exynos: Add mem-2-mem Scaler devices

Krzysztof Kozlowski (2):
  arm64: dts: exynos: Move syscon poweroff and restart nodes under the PMU
  arm64: dts: exynos: Remove unneeded address space mapping for soc node

 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 66 +-
 arch/arm64/boot/dts/exynos/exynos7.dtsi| 18 
 2 files changed, 65 insertions(+), 19 deletions(-)

[GIT PULL 2/5] soc: samsung: Stuff for v4.18

[Krzysztof Kozlowski]

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-drivers-4.18

for you to fetch changes up to b2b568c591ddbb20d597e256212579d70dbf3000:

  soc: samsung: pm_domains: Deprecate support for clocks (2018-04-17 17:25:42 
+0200)


Samsung soc drivers changes for v4.18

1. Clock operations during power domain on/off were moved to respective
   clock driver so clean up obsolete code from power domain driver.


Marek Szyprowski (1):
  soc: samsung: pm_domains: Deprecate support for clocks

 .../devicetree/bindings/power/pd-samsung.txt   | 20 +
 drivers/soc/samsung/pm_domains.c   | 90 +-
 2 files changed, 5 insertions(+), 105 deletions(-)

[GIT PULL 0/5] ARM: samsung/exynos: Stuff for v4.18

[Krzysztof Kozlowski]

Hi,

Changes for v4.18. No dependencies, no specific order of pulls.

Support for Exynos5440 is removed step by step through different trees.

Best regards,
Krzysztof

WARNING in iov_iter_revert

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:427fbe89261d Merge branch 'next' of git://git.kernel.org/p..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16b3347780
kernel config:  https://syzkaller.appspot.com/x/.config?x=fcce42b221691ff9
dashboard link: https://syzkaller.appspot.com/bug?extid=c226690f7b3126c5ee04
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=144f199780
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=141d541780

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c226690f7b3126c5e...@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
WARNING: CPU: 1 PID: 4542 at lib/iov_iter.c:857 iov_iter_revert+0x2ee/0xaa0  
lib/iov_iter.c:857

Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 4542 Comm: syz-executor650 Not tainted 4.17.0-rc4+ #44
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 panic+0x22f/0x4de kernel/panic.c:184
 __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
 report_bug+0x252/0x2d0 lib/bug.c:186
 fixup_bug arch/x86/kernel/traps.c:178 [inline]
 do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:iov_iter_revert+0x2ee/0xaa0 lib/iov_iter.c:857
RSP: 0018:8801ad1bf700 EFLAGS: 00010293
RAX: 8801ac55e6c0 RBX:  RCX: 835104a1
RDX:  RSI: 8351074e RDI: 0007
RBP: 8801ad1bf760 R08: 8801ac55e6c0 R09: ed003b5e46c2
R10: 0003 R11: 0001 R12: 0001
R13: 8801ad1bfd60 R14: 0011 R15: 8801ae9ac040
 tls_sw_sendmsg+0xf1c/0x12d0 net/tls/tls_sw.c:448
 inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg+0xd5/0x120 net/socket.c:639
 ___sys_sendmsg+0x805/0x940 net/socket.c:2117
 __sys_sendmsg+0x115/0x270 net/socket.c:2155
 __do_sys_sendmsg net/socket.c:2164 [inline]
 __se_sys_sendmsg net/socket.c:2162 [inline]
 __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4403a9
RSP: 002b:7ffdcdfbd6c8 EFLAGS: 0207 ORIG_RAX: 002e
RAX: ffda RBX: 004002c8 RCX: 004403a9
RDX:  RSI: 20001340 RDI: 0003
RBP: 006ca018 R08: 001c R09: 001c
R10: 2180 R11: 0207 R12: 00401cd0
R13: 00401d60 R14:  R15: 
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
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.

syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [PATCH 1/6] x86/early-quirks: Rename duplicate define of dev_err

[Joe Perches]

On Sun, 2018-05-13 at 15:03 +0200, Thomas Gleixner wrote:
> On Wed, 9 May 2018, Joe Perches wrote:
> 
> > dev_err is becoming a macro calling _dev_err to allow prefixing of
> > dev_fmt to any dev_ use that has a #define dev_fmt(fmt) similar
> > to the existing #define pr_fmt(fmt) uses.
> > 
> > Remove this dev_err macro and convert the existing two uses to pr_err.
> > This allows clean compilation in the patch that introduces dev_fmt which
> > can prefix dev_ logging macros with arbitrary content similar to
> > the #define pr_fmt macro.
> > 
> > Signed-off-by: Joe Perches 
> 
> I assume you want to take them as block, so:
> 
> Reviewed-by: Thomas Gleixner 

I do not have a tree that Linus pulls.

I think it'd be fine if you apply this one as it's a
simple rename deduplication.

Corey Minyard has already taken the ipmi changes
separately.

Patch 2/6 could go separately, probably via Greg KH's
tree, after this 1/6 change is in the tree.

Re: [PATCH bpf v3] x86/cpufeature: bpf hack for clang not supporting asm goto

[Thomas Gleixner]

On Sun, 13 May 2018, Alexei Starovoitov wrote:
> On Sat, May 12, 2018 at 10:30:02PM +0200, Thomas Gleixner wrote:
> > But yes, the situation is slightly different here because tools which
> > create trace event magic _HAVE_ to pull in kernel headers. At the same time
> > these tools depend on a compiler which failed to implement asm_goto for
> > fricking 8 years.
> 
> As a maintainer of a piece of llvm codebase I have to say that
> this bullying tactic has the opposite effect.

I'm not bullying at all. Its a fact that the discussion about asm goto is
dragging out 8 years now. We've stayed away from mandating it for quite
some time, but at some point it just doesn't make sense anymore.

> The inline asm is processed by gcc and llvm very differently.  gcc is
> leaking internal backend implementation details into inline asm
> syntax. It makes little sense for llvm to do the same, since compiler
> codegen is completely different. gcc doesn't have integrated assembler
> whereas llvm not only can parse asm, but can potentially optimize it as
> well.  Instead of demanding asm-goto that matches gcc one to one it's
> better to work with the community to define the syntax that works for
> both kernel and llvm.

Come on, we surely are open for discussions, but what I've seen so far is
just 'oh we can't do this because' instead of a sane proposal how it can be
done w/o rewriting the whole ASM GOTO stuff in the kernel or even
duplicating it.

> > + * Workaround for the sake of BPF compilation which utilizes kernel
> > + * headers, but clang does not support ASM GOTO and fails the build.
> > + */
> > +#ifndef __BPF__
> > +#warning "Compiler lacks ASM_GOTO support. Add -D __BPF__ to your compiler 
> > arguments"
> > +#endif
> 
> Agree.
> The warning makes sense to me, but it has to be different macro name.
> How about -D__BPF_TRACING__ or -D__BPF_KPROBES__ or something similar ?

Fair enough.

> Such name will also make it clear that only tracing bpf programs
> need this. Networking programs shouldn't be including kernel headers.
> There was never a need, but since the tracing progs are often used
> as an example people copy paste makefiles too.
> We tried to document it as much as possible, but people still use
> 'clang -target native -I/kernel/includes bpf_prog.c -emit-llvm | llc 
> -march=bpf'
> in their builds.
> (sometimes as a workaround for setups where clang is older version,
> but llc/llvm is new)
> Now they will see this warning and it will force them to think whether
> they actually need the kernel headers.

Makes sense.

> > +
> > +#define static_cpu_has(bit)boot_cpu_has(bit)
> > +
> > +#else
> > +
> >  /*
> >   * Static testing of CPU features.  Used the same as boot_cpu_has().
> >   * These will statically patch the target code for additional
> > @@ -195,6 +209,7 @@ static __always_inline __pure bool _stat
> > boot_cpu_has(bit) : \
> > _static_cpu_has(bit)\
> >  )
> > +#endif
> >  
> >  #define cpu_has_bug(c, bit)cpu_has(c, (bit))
> >  #define set_cpu_bug(c, bit)set_cpu_cap(c, (bit))
> > --- a/samples/bpf/Makefile
> > +++ b/samples/bpf/Makefile
> > @@ -255,7 +255,7 @@ verify_target_bpf: verify_cmds
> >  $(obj)/%.o: $(src)/%.c
> > $(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) -I$(obj) \
> > -I$(srctree)/tools/testing/selftests/bpf/ \
> > -   -D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \
> > +   -D__KERNEL__ -D__BPF__ -Wno-unused-value -Wno-pointer-sign \
> 
> Yep. In samples/bpf and libbcc we can selectively add -D__BPF_TRACING__
> I think sysdig and other folks can live with that as well.
> Agree?

Sure. Care to send an updated patch?

Thanks,

tglx

Re: [PATCH v3 1/3] leds: triggers: provide led_trigger_register_format()

[Andy Shevchenko]

On Thu, May 10, 2018 at 2:22 PM, Pavel Machek  wrote:
> On Thu 2018-05-10 13:21:01, Pavel Machek wrote:

>> I know this is not your fault, but if you have a space or "[]" in
>> netdev names, confusing things will happen.
>
> Hmm. If we are doing this we really should check trigger names for
> forbidden characters. At least "[] " should be forbidden.

So, string_escape_mem() is your helper here.

-- 
With Best Regards,
Andy Shevchenko