1. 17 Apr, 2019 12 commits
    • Artemy Kovalyov's avatar
      net/mlx5: Decrease default mr cache size · 53a19068
      Artemy Kovalyov authored
      [ Upstream commit e8b26b21 ]
      
      Delete initialization of high order entries in mr cache to decrease initial
      memory footprint. When required, the administrator can populate the
      entries with memory keys via the /sys interface.
      
      This approach is very helpful to significantly reduce the per HW function
      memory footprint in virtualization environments such as SRIOV.
      
      Fixes: 9603b61d ("mlx5: Move pci device handling from mlx5_ib to mlx5_core")
      Signed-off-by: default avatarArtemy Kovalyov <artemyko@mellanox.com>
      Signed-off-by: default avatarMoni Shoua <monis@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Reported-by: default avatarShalom Toledo <shalomt@mellanox.com>
      Acked-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      53a19068
    • Steffen Klassert's avatar
      net-gro: Fix GRO flush when receiving a GSO packet. · b87ec813
      Steffen Klassert authored
      [ Upstream commit 0ab03f35 ]
      
      Currently we may merge incorrectly a received GSO packet
      or a packet with frag_list into a packet sitting in the
      gro_hash list. skb_segment() may crash case because
      the assumptions on the skb layout are not met.
      The correct behaviour would be to flush the packet in the
      gro_hash list and send the received GSO packet directly
      afterwards. Commit d61d072e ("net-gro: avoid reorders")
      sets NAPI_GRO_CB(skb)->flush in this case, but this is not
      checked before merging. This patch makes sure to check this
      flag and to not merge in that case.
      
      Fixes: d61d072e ("net-gro: avoid reorders")
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b87ec813
    • Li RongQing's avatar
      net: ethtool: not call vzalloc for zero sized memory request · 80c20581
      Li RongQing authored
      [ Upstream commit 3d883026 ]
      
      NULL or ZERO_SIZE_PTR will be returned for zero sized memory
      request, and derefencing them will lead to a segfault
      
      so it is unnecessory to call vzalloc for zero sized memory
      request and not call functions which maybe derefence the
      NULL allocated memory
      
      this also fixes a possible memory leak if phy_ethtool_get_stats
      returns error, memory should be freed before exit
      Signed-off-by: default avatarLi RongQing <lirongqing@baidu.com>
      Reviewed-by: default avatarWang Li <wangli39@baidu.com>
      Reviewed-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      80c20581
    • Jiri Slaby's avatar
      kcm: switch order of device registration to fix a crash · b7b05831
      Jiri Slaby authored
      [ Upstream commit 3c446e6f ]
      
      When kcm is loaded while many processes try to create a KCM socket, a
      crash occurs:
       BUG: unable to handle kernel NULL pointer dereference at 000000000000000e
       IP: mutex_lock+0x27/0x40 kernel/locking/mutex.c:240
       PGD 8000000016ef2067 P4D 8000000016ef2067 PUD 3d6e9067 PMD 0
       Oops: 0002 [#1] SMP KASAN PTI
       CPU: 0 PID: 7005 Comm: syz-executor.5 Not tainted 4.12.14-396-default #1 SLE15-SP1 (unreleased)
       RIP: 0010:mutex_lock+0x27/0x40 kernel/locking/mutex.c:240
       RSP: 0018:ffff88000d487a00 EFLAGS: 00010246
       RAX: 0000000000000000 RBX: 000000000000000e RCX: 1ffff100082b0719
       ...
       CR2: 000000000000000e CR3: 000000004b1bc003 CR4: 0000000000060ef0
       Call Trace:
        kcm_create+0x600/0xbf0 [kcm]
        __sock_create+0x324/0x750 net/socket.c:1272
       ...
      
      This is due to race between sock_create and unfinished
      register_pernet_device. kcm_create tries to do "net_generic(net,
      kcm_net_id)". but kcm_net_id is not initialized yet.
      
      So switch the order of the two to close the race.
      
      This can be reproduced with mutiple processes doing socket(PF_KCM, ...)
      and one process doing module removal.
      
      Fixes: ab7ac4eb ("kcm: Kernel Connection Multiplexor module")
      Reviewed-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b7b05831
    • Lorenzo Bianconi's avatar
      ipv6: sit: reset ip header pointer in ipip6_rcv · 42f1fa0f
      Lorenzo Bianconi authored
      [ Upstream commit bb9bd814 ]
      
      ipip6 tunnels run iptunnel_pull_header on received skbs. This can
      determine the following use-after-free accessing iph pointer since
      the packet will be 'uncloned' running pskb_expand_head if it is a
      cloned gso skb (e.g if the packet has been sent though a veth device)
      
      [  706.369655] BUG: KASAN: use-after-free in ipip6_rcv+0x1678/0x16e0 [sit]
      [  706.449056] Read of size 1 at addr ffffe01b6bd855f5 by task ksoftirqd/1/=
      [  706.669494] Hardware name: HPE ProLiant m400 Server/ProLiant m400 Server, BIOS U02 08/19/2016
      [  706.771839] Call trace:
      [  706.801159]  dump_backtrace+0x0/0x2f8
      [  706.845079]  show_stack+0x24/0x30
      [  706.884833]  dump_stack+0xe0/0x11c
      [  706.925629]  print_address_description+0x68/0x260
      [  706.982070]  kasan_report+0x178/0x340
      [  707.025995]  __asan_report_load1_noabort+0x30/0x40
      [  707.083481]  ipip6_rcv+0x1678/0x16e0 [sit]
      [  707.132623]  tunnel64_rcv+0xd4/0x200 [tunnel4]
      [  707.185940]  ip_local_deliver_finish+0x3b8/0x988
      [  707.241338]  ip_local_deliver+0x144/0x470
      [  707.289436]  ip_rcv_finish+0x43c/0x14b0
      [  707.335447]  ip_rcv+0x628/0x1138
      [  707.374151]  __netif_receive_skb_core+0x1670/0x2600
      [  707.432680]  __netif_receive_skb+0x28/0x190
      [  707.482859]  process_backlog+0x1d0/0x610
      [  707.529913]  net_rx_action+0x37c/0xf68
      [  707.574882]  __do_softirq+0x288/0x1018
      [  707.619852]  run_ksoftirqd+0x70/0xa8
      [  707.662734]  smpboot_thread_fn+0x3a4/0x9e8
      [  707.711875]  kthread+0x2c8/0x350
      [  707.750583]  ret_from_fork+0x10/0x18
      
      [  707.811302] Allocated by task 16982:
      [  707.854182]  kasan_kmalloc.part.1+0x40/0x108
      [  707.905405]  kasan_kmalloc+0xb4/0xc8
      [  707.948291]  kasan_slab_alloc+0x14/0x20
      [  707.994309]  __kmalloc_node_track_caller+0x158/0x5e0
      [  708.053902]  __kmalloc_reserve.isra.8+0x54/0xe0
      [  708.108280]  __alloc_skb+0xd8/0x400
      [  708.150139]  sk_stream_alloc_skb+0xa4/0x638
      [  708.200346]  tcp_sendmsg_locked+0x818/0x2b90
      [  708.251581]  tcp_sendmsg+0x40/0x60
      [  708.292376]  inet_sendmsg+0xf0/0x520
      [  708.335259]  sock_sendmsg+0xac/0xf8
      [  708.377096]  sock_write_iter+0x1c0/0x2c0
      [  708.424154]  new_sync_write+0x358/0x4a8
      [  708.470162]  __vfs_write+0xc4/0xf8
      [  708.510950]  vfs_write+0x12c/0x3d0
      [  708.551739]  ksys_write+0xcc/0x178
      [  708.592533]  __arm64_sys_write+0x70/0xa0
      [  708.639593]  el0_svc_handler+0x13c/0x298
      [  708.686646]  el0_svc+0x8/0xc
      
      [  708.739019] Freed by task 17:
      [  708.774597]  __kasan_slab_free+0x114/0x228
      [  708.823736]  kasan_slab_free+0x10/0x18
      [  708.868703]  kfree+0x100/0x3d8
      [  708.905320]  skb_free_head+0x7c/0x98
      [  708.948204]  skb_release_data+0x320/0x490
      [  708.996301]  pskb_expand_head+0x60c/0x970
      [  709.044399]  __iptunnel_pull_header+0x3b8/0x5d0
      [  709.098770]  ipip6_rcv+0x41c/0x16e0 [sit]
      [  709.146873]  tunnel64_rcv+0xd4/0x200 [tunnel4]
      [  709.200195]  ip_local_deliver_finish+0x3b8/0x988
      [  709.255596]  ip_local_deliver+0x144/0x470
      [  709.303692]  ip_rcv_finish+0x43c/0x14b0
      [  709.349705]  ip_rcv+0x628/0x1138
      [  709.388413]  __netif_receive_skb_core+0x1670/0x2600
      [  709.446943]  __netif_receive_skb+0x28/0x190
      [  709.497120]  process_backlog+0x1d0/0x610
      [  709.544169]  net_rx_action+0x37c/0xf68
      [  709.589131]  __do_softirq+0x288/0x1018
      
      [  709.651938] The buggy address belongs to the object at ffffe01b6bd85580
                      which belongs to the cache kmalloc-1024 of size 1024
      [  709.804356] The buggy address is located 117 bytes inside of
                      1024-byte region [ffffe01b6bd85580, ffffe01b6bd85980)
      [  709.946340] The buggy address belongs to the page:
      [  710.003824] page:ffff7ff806daf600 count:1 mapcount:0 mapping:ffffe01c4001f600 index:0x0
      [  710.099914] flags: 0xfffff8000000100(slab)
      [  710.149059] raw: 0fffff8000000100 dead000000000100 dead000000000200 ffffe01c4001f600
      [  710.242011] raw: 0000000000000000 0000000000380038 00000001ffffffff 0000000000000000
      [  710.334966] page dumped because: kasan: bad access detected
      
      Fix it resetting iph pointer after iptunnel_pull_header
      
      Fixes: a09a4c8d ("tunnels: Remove encapsulation offloads on decap")
      Tested-by: default avatarJianlin Shi <jishi@redhat.com>
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      42f1fa0f
    • Junwei Hu's avatar
      ipv6: Fix dangling pointer when ipv6 fragment · ea06796f
      Junwei Hu authored
      [ Upstream commit ef0efcd3 ]
      
      At the beginning of ip6_fragment func, the prevhdr pointer is
      obtained in the ip6_find_1stfragopt func.
      However, all the pointers pointing into skb header may change
      when calling skb_checksum_help func with
      skb->ip_summed = CHECKSUM_PARTIAL condition.
      The prevhdr pointe will be dangling if it is not reloaded after
      calling __skb_linearize func in skb_checksum_help func.
      
      Here, I add a variable, nexthdr_offset, to evaluate the offset,
      which does not changes even after calling __skb_linearize func.
      
      Fixes: 405c92f7 ("ipv6: add defensive check for CHECKSUM_PARTIAL skbs in ip_fragment")
      Signed-off-by: default avatarJunwei Hu <hujunwei4@huawei.com>
      Reported-by: default avatarWenhao Zhang <zhangwenhao8@huawei.com>
      Reported-by: syzbot+e8ce541d095e486074fc@syzkaller.appspotmail.com
      Reviewed-by: default avatarZhiqiang Liu <liuzhiqiang26@huawei.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ea06796f
    • Sheena Mira-ato's avatar
      ip6_tunnel: Match to ARPHRD_TUNNEL6 for dev type · 8e4b4da3
      Sheena Mira-ato authored
      [ Upstream commit b2e54b09 ]
      
      The device type for ip6 tunnels is set to
      ARPHRD_TUNNEL6. However, the ip4ip6_err function
      is expecting the device type of the tunnel to be
      ARPHRD_TUNNEL.  Since the device types do not
      match, the function exits and the ICMP error
      packet is not sent to the originating host. Note
      that the device type for IPv4 tunnels is set to
      ARPHRD_TUNNEL.
      
      Fix is to expect a tunnel device type of
      ARPHRD_TUNNEL6 instead.  Now the tunnel device
      type matches and the ICMP error packet is sent
      to the originating host.
      Signed-off-by: default avatarSheena Mira-ato <sheena.mira-ato@alliedtelesis.co.nz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8e4b4da3
    • Thomas Falcon's avatar
      ibmvnic: Fix completion structure initialization · 16701957
      Thomas Falcon authored
      [ Upstream commit bbd669a8 ]
      
      Fix device initialization completion handling for vNIC adapters.
      Initialize the completion structure on probe and reinitialize when needed.
      This also fixes a race condition during kdump where the driver can attempt
      to access the completion struct before it is initialized:
      
      Unable to handle kernel paging request for data at address 0x00000000
      Faulting instruction address: 0xc0000000081acbe0
      Oops: Kernel access of bad area, sig: 11 [#1]
      LE SMP NR_CPUS=2048 NUMA pSeries
      Modules linked in: ibmvnic(+) ibmveth sunrpc overlay squashfs loop
      CPU: 19 PID: 301 Comm: systemd-udevd Not tainted 4.18.0-64.el8.ppc64le #1
      NIP:  c0000000081acbe0 LR: c0000000081ad964 CTR: c0000000081ad900
      REGS: c000000027f3f990 TRAP: 0300   Not tainted  (4.18.0-64.el8.ppc64le)
      MSR:  800000010280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 28228288  XER: 00000006
      CFAR: c000000008008934 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1
      GPR00: c0000000081ad964 c000000027f3fc10 c0000000095b5800 c0000000221b4e58
      GPR04: 0000000000000003 0000000000000001 000049a086918581 00000000000000d4
      GPR08: 0000000000000007 0000000000000000 ffffffffffffffe8 d0000000014dde28
      GPR12: c0000000081ad900 c000000009a00c00 0000000000000001 0000000000000100
      GPR16: 0000000000000038 0000000000000007 c0000000095e2230 0000000000000006
      GPR20: 0000000000400140 0000000000000001 c00000000910c880 0000000000000000
      GPR24: 0000000000000000 0000000000000006 0000000000000000 0000000000000003
      GPR28: 0000000000000001 0000000000000001 c0000000221b4e60 c0000000221b4e58
      NIP [c0000000081acbe0] __wake_up_locked+0x50/0x100
      LR [c0000000081ad964] complete+0x64/0xa0
      Call Trace:
      [c000000027f3fc10] [c000000027f3fc60] 0xc000000027f3fc60 (unreliable)
      [c000000027f3fc60] [c0000000081ad964] complete+0x64/0xa0
      [c000000027f3fca0] [d0000000014dad58] ibmvnic_handle_crq+0xce0/0x1160 [ibmvnic]
      [c000000027f3fd50] [d0000000014db270] ibmvnic_tasklet+0x98/0x130 [ibmvnic]
      [c000000027f3fda0] [c00000000813f334] tasklet_action_common.isra.3+0xc4/0x1a0
      [c000000027f3fe00] [c000000008cd13f4] __do_softirq+0x164/0x400
      [c000000027f3fef0] [c00000000813ed64] irq_exit+0x184/0x1c0
      [c000000027f3ff20] [c0000000080188e8] __do_irq+0xb8/0x210
      [c000000027f3ff90] [c00000000802d0a4] call_do_irq+0x14/0x24
      [c000000026a5b010] [c000000008018adc] do_IRQ+0x9c/0x130
      [c000000026a5b060] [c000000008008ce4] hardware_interrupt_common+0x114/0x120
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      16701957
    • Haiyang Zhang's avatar
      hv_netvsc: Fix unwanted wakeup after tx_disable · 9a7c4f5a
      Haiyang Zhang authored
      [ Upstream commit 1b704c4a ]
      
      After queue stopped, the wakeup mechanism may wake it up again
      when ring buffer usage is lower than a threshold. This may cause
      send path panic on NULL pointer when we stopped all tx queues in
      netvsc_detach and start removing the netvsc device.
      
      This patch fix it by adding a tx_disable flag to prevent unwanted
      queue wakeup.
      
      Fixes: 7b2ee50c ("hv_netvsc: common detach logic")
      Reported-by: default avatarMohammed Gamal <mgamal@redhat.com>
      Signed-off-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9a7c4f5a
    • Breno Leitao's avatar
      powerpc/tm: Limit TM code inside PPC_TRANSACTIONAL_MEM · 902eca1a
      Breno Leitao authored
      commit 897bc3df upstream.
      
      Commit e1c3743e ("powerpc/tm: Set MSR[TS] just prior to recheckpoint")
      moved a code block around and this block uses a 'msr' variable outside of
      the CONFIG_PPC_TRANSACTIONAL_MEM, however the 'msr' variable is declared
      inside a CONFIG_PPC_TRANSACTIONAL_MEM block, causing a possible error when
      CONFIG_PPC_TRANSACTION_MEM is not defined.
      
      	error: 'msr' undeclared (first use in this function)
      
      This is not causing a compilation error in the mainline kernel, because
      'msr' is being used as an argument of MSR_TM_ACTIVE(), which is defined as
      the following when CONFIG_PPC_TRANSACTIONAL_MEM is *not* set:
      
      	#define MSR_TM_ACTIVE(x) 0
      
      This patch just fixes this issue avoiding the 'msr' variable usage outside
      the CONFIG_PPC_TRANSACTIONAL_MEM block, avoiding trusting in the
      MSR_TM_ACTIVE() definition.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarChristoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
      Fixes: e1c3743e ("powerpc/tm: Set MSR[TS] just prior to recheckpoint")
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      902eca1a
    • Yan Zhao's avatar
      drm/i915/gvt: do not let pin count of shadow mm go negative · 8ad895bf
      Yan Zhao authored
      [ Upstream commit 663a50ce ]
      
      shadow mm's pin count got increased in workload preparation phase, which
      is after workload scanning.
      it will get decreased in complete_current_workload() anyway after
      workload completion.
      Sometimes, if a workload meets a scanning error, its shadow mm pin count
      will not get increased but will get decreased in the end.
      This patch lets shadow mm's pin count not go below 0.
      
      Fixes: 2707e444 ("drm/i915/gvt: vGPU graphics memory virtualization")
      Cc: zhenyuw@linux.intel.com
      Cc: stable@vger.kernel.org #4.14+
      Signed-off-by: default avatarYan Zhao <yan.y.zhao@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8ad895bf
    • Jim Mattson's avatar
      kvm: nVMX: NMI-window and interrupt-window exiting should wake L2 from HLT · 646f8e01
      Jim Mattson authored
      [ Upstream commit 9ebdfe52 ]
      
      According to the SDM, "NMI-window exiting" VM-exits wake a logical
      processor from the same inactive states as would an NMI and
      "interrupt-window exiting" VM-exits wake a logical processor from the
      same inactive states as would an external interrupt. Specifically, they
      wake a logical processor from the shutdown state and from the states
      entered using the HLT and MWAIT instructions.
      
      Fixes: 6dfacadd ("KVM: nVMX: Add support for activity state HLT")
      Signed-off-by: default avatarJim Mattson <jmattson@google.com>
      Reviewed-by: default avatarPeter Shier <pshier@google.com>
      Suggested-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      [Squashed comments of two Jim's patches and used the simplified code
       hunk provided by Sean. - Radim]
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      646f8e01
  2. 05 Apr, 2019 28 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.19.34 · 4d552acf
      Greg Kroah-Hartman authored
      4d552acf
    • Andrea Righi's avatar
      kprobes/x86: Blacklist non-attachable interrupt functions · d5813e77
      Andrea Righi authored
      [ Upstream commit a50480cb ]
      
      These interrupt functions are already non-attachable by kprobes.
      Blacklist them explicitly so that they can show up in
      /sys/kernel/debug/kprobes/blacklist and tools like BCC can use this
      additional information.
      Signed-off-by: default avatarAndrea Righi <righi.andrea@gmail.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yonghong Song <yhs@fb.com>
      Link: http://lkml.kernel.org/r/20181206095648.GA8249@DellSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d5813e77
    • Coly Li's avatar
      bcache: fix potential div-zero error of writeback_rate_p_term_inverse · e7d26616
      Coly Li authored
      [ Upstream commit 5b5fd3c9 ]
      
      Current code already uses d_strtoul_nonzero() to convert input string
      to an unsigned integer, to make sure writeback_rate_p_term_inverse
      won't be zero value. But overflow may happen when converting input
      string to an unsigned integer value by d_strtoul_nonzero(), then
      dc->writeback_rate_p_term_inverse can still be set to 0 even if the
      sysfs file input value is not zero, e.g. 4294967296 (a.k.a UINT_MAX+1).
      
      If dc->writeback_rate_p_term_inverse is set to 0, it might cause a
      dev-zero error in following code from __update_writeback_rate(),
      	int64_t proportional_scaled =
      		div_s64(error, dc->writeback_rate_p_term_inverse);
      
      This patch replaces d_strtoul_nonzero() by sysfs_strtoul_clamp() and
      limit the value range in [1, UINT_MAX]. Then the unsigned integer
      overflow and dev-zero error can be avoided.
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e7d26616
    • Hans de Goede's avatar
      ACPI / video: Extend chassis-type detection with a "Lunch Box" check · 09abe130
      Hans de Goede authored
      [ Upstream commit d693c008 ]
      
      Commit 53fa1f6e ("ACPI / video: Only default only_lcd to true on
      Win8-ready _desktops_") introduced chassis type detection, limiting the
      lcd_only check for the backlight to devices where the chassis-type
      indicates their is no builtin LCD panel.
      
      The purpose of the lcd_only check is to avoid advertising a backlight
      interface on desktops, since skylake and newer machines seem to always
      have a backlight interface even if there is no LCD panel. The limiting
      of this check to desktops only was done to avoid breaking backlight
      support on some laptops which do not have the lcd flag set.
      
      The Fujitsu ESPRIMO Q910 which is a compact (NUC like) desktop machine
      has a chassis type of 0x10 aka "Lunch Box". Without the lcd_only check
      we end up falsely advertising backlight/brightness control on this
      device. This commit extend the dmi_is_desktop check to return true
      for type 0x10 to fix this.
      
      Fixes: 53fa1f6e ("ACPI / video: Only default only_lcd to true ...")
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      09abe130
    • Nathan Chancellor's avatar
      net: stmmac: Avoid one more sometimes uninitialized Clang warning · d1d2ca98
      Nathan Chancellor authored
      [ Upstream commit 1f5d861f ]
      
      When building with -Wsometimes-uninitialized, Clang warns:
      
      drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c:111:2: error: variable
      'ns' is used uninitialized whenever 'if' condition is false
      [-Werror,-Wsometimes-uninitialized]
      drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c:111:2: error: variable
      'ns' is used uninitialized whenever '&&' condition is false
      [-Werror,-Wsometimes-uninitialized]
      
      Clang is concerned with the use of stmmac_do_void_callback (which
      stmmac_get_systime wraps), as it may fail to initialize these values if
      the if condition was ever false (meaning the callback doesn't exist).
      It's not wrong because the callback is what initializes ns. While it's
      unlikely that the callback is going to disappear at some point and make
      that condition false, we can easily avoid this warning by zero
      initializing the variable.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/384
      Fixes: df103170 ("net: stmmac: Avoid sometimes uninitialized Clang warnings")
      Suggested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d1d2ca98
    • Ville Syrjälä's avatar
      drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers · 972e31ba
      Ville Syrjälä authored
      [ Upstream commit c978ae9b ]
      
      We aren't supposed to force a stop+start between every i2c msg
      when performing multi message transfers. This should eg. cause
      the DDC segment address to be reset back to 0 between writing
      the segment address and reading the actual EDID extension block.
      
      To quote the E-DDC spec:
      "... this standard requires that the segment pointer be
       reset to 00h when a NO ACK or a STOP condition is received."
      
      Since we're going to touch this might as well consult the
      I2C_M_STOP flag to determine whether we want to force the stop
      or not.
      
      Cc: Brian Vincent <brainn@gmail.com>
      References: https://bugs.freedesktop.org/show_bug.cgi?id=108081Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180928180403.22499-1-ville.syrjala@linux.intel.comReviewed-by: default avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      972e31ba
    • Hans de Goede's avatar
      Input: soc_button_array - fix mapping of the 5th GPIO in a PNP0C40 device · 986a2bb5
      Hans de Goede authored
      [ Upstream commit e9eb788f ]
      
      The Microsoft documenation for the PNP0C40 device aka the
      "Windows-compatible button array" describes the 5th GpioInt listed in
      the resources as: '5. Interrupt corresponding to the "Rotation Lock"
      button, if supported'.
      
      Notice this describes the 5th entry as a button while we sofar have been
      mapping it to EV_SW, SW_ROTATE_LOCK. On my Point of View TAB P1006W-232
      which actually comes with a rotation-lock button, the button indeed is a
      button and not a slider/switch. An image search for other Windows tablets
      has found 2 more models with a rotation-lock button and on both of those
      it too is a push-button and not a slider/switch.
      
      Further evidence can be found in the HUT extension HUTRR52 from Microsoft
      which adds rotation lock support to the HUT, which describes 2 different
      usages: "0xC9 System Display Rotation Lock Button" and
      "0xCA System Display Rotation Lock Slider Switch" note that switch is seen
      as a separate thing here and the non switch wording is an exact match for
      the "Windows-compatible button array" spec wording.
      
      TL;DR: our current mapping of the 5th GPIO to SW_ROTATE_LOCK is wrong
      because the 5th GPIO is for a push-button not a switch.
      
      This commit fixes this by maping the 5th GPIO to KEY_ROTATE_LOCK_TOGGLE.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      986a2bb5
    • Ben Dooks's avatar
      dmaengine: tegra: avoid overflow of byte tracking · 6d2817e2
      Ben Dooks authored
      [ Upstream commit e486df39 ]
      
      The dma_desc->bytes_transferred counter tracks the number of bytes
      moved by the DMA channel. This is then used to calculate the information
      passed back in the in the tegra_dma_tx_status callback, which is usually
      fine.
      
      When the DMA channel is configured as continous, then the bytes_transferred
      counter will increase over time and eventually overflow to become negative
      so the residue count will become invalid and the ALSA sound-dma code will
      report invalid hardware pointer values to the application. This results in
      some users becoming confused about the playout position and putting audio
      data in the wrong place.
      
      To fix this issue, always ensure the bytes_transferred field is modulo the
      size of the request. We only do this for the case of the cyclic transfer
      done ISR as anyone attempting to move 2GiB of DMA data in one transfer
      is unlikely.
      
      Note, we don't fix the issue that we should /never/ transfer a negative
      number of bytes so we could make those fields unsigned.
      Reviewed-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: default avatarBen Dooks <ben.dooks@codethink.co.uk>
      Acked-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6d2817e2
    • Katsuhiro Suzuki's avatar
      clk: rockchip: fix frac settings of GPLL clock for rk3328 · 7386f095
      Katsuhiro Suzuki authored
      [ Upstream commit a0e447b0 ]
      
      This patch fixes settings of GPLL frequency in fractional mode for
      rk3328. In this mode, FOUTVCO is calcurated by following formula:
        FOUTVCO = FREF * FBDIV / REFDIV + ((FREF * FRAC / REFDIV) >> 24)
      
      The problem is in FREF * FRAC >> 24 term. This result always lacks
      one from target value is specified by rate member. For example first
      itme of rk3328_pll_frac_rate originally has
        - rate  : 1016064000
        - refdiv: 3
        - fbdiv : 127
        - frac  : 134217
        - FREF * FBDIV / REFDIV        = 1016000000
        - (FREF * FRAC / REFDIV) >> 24 = 63999
      Thus calculated rate is 1016063999. It seems wrong.
      
      If frac has 134218 (it is increased 1 from original value), second
      term is 64000. All other items have same situation. So this patch
      adds 1 to frac member in all items of rk3328_pll_frac_rate.
      Signed-off-by: default avatarKatsuhiro Suzuki <katsuhiro@katsuster.net>
      Acked-by: default avatarElaine Zhang <zhangqing@rock-chips.com>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7386f095
    • Jerome Brunet's avatar
      clk: meson: clean-up clock registration · c8e4f840
      Jerome Brunet authored
      [ Upstream commit 8d9981ef ]
      
      Order, ids and size  between the table of regmap clocks and the onecell
      data table could be different.
      
      Set regmap pointer in all the regmap clocks before starting the
      registration using the onecell data, to make sure we don't
      get into an incoherent situation.
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Acked-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Link: https://lkml.kernel.org/r/20181221160239.26265-3-jbrunet@baylibre.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      c8e4f840
    • Peter Wu's avatar
      drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup · 6251c1db
      Peter Wu authored
      [ Upstream commit 00eb5b0d ]
      
      After drm_fb_helper_fbdev_setup calls drm_fb_helper_init,
      "dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will
      have some effect). After that, drm_fb_helper_initial_config is called
      which may call the "fb_probe" driver callback.
      
      This driver callback may call drm_fb_helper_defio_init (as is done by
      drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs)
      as documented. These are normally cleaned up on exit by
      drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini.
      
      If an error occurs after "fb_probe", but before setup is complete, then
      calling just drm_fb_helper_fini will leak resources. This was triggered
      by df2052cc ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"):
      
          [   50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support this framebuffer
          [   50.009436] bochs-drm 0000:00:02.0: [drm:drm_fb_helper_fbdev_setup] *ERROR* fbdev: Failed to set configuration (ret=-38)
          [   50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:02.0 on minor 2
          [   50.013604] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0
          [   50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G                T 4.20.0-rc7 #1
          [   50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0
          ...
          [   50.023155] Call Trace:
          [   50.023155]  ? bochs_kms_fini+0x1e/0x30
          [   50.023155]  ? bochs_unload+0x18/0x40
      
      This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n.
      
      Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian
      Link: https://lkml.kernel.org/r/20181223004315.GA11455@al
      Fixes: 87412163 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()")
      Reported-by: default avatarkernel test robot <rong.a.chen@intel.com>
      Cc: Noralf Trønnes <noralf@tronnes.org>
      Signed-off-by: default avatarPeter Wu <peter@lekensteyn.nl>
      Reviewed-by: default avatarNoralf Trønnes <noralf@tronnes.org>
      Signed-off-by: default avatarNoralf Trønnes <noralf@tronnes.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181223005507.28328-1-peter@lekensteyn.nlSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      6251c1db
    • Rafael Ávila de Espíndola's avatar
      x86/build: Mark per-CPU symbols as absolute explicitly for LLD · 648b949b
      Rafael Ávila de Espíndola authored
      [ Upstream commit d071ae09 ]
      
      Accessing per-CPU variables is done by finding the offset of the
      variable in the per-CPU block and adding it to the address of the
      respective CPU's block.
      
      Section 3.10.8 of ld.bfd's documentation states:
      
        For expressions involving numbers, relative addresses and absolute
        addresses, ld follows these rules to evaluate terms:
      
        Other binary operations, that is, between two relative addresses
        not in the same section, or between a relative address and an
        absolute address, first convert any non-absolute term to an
        absolute address before applying the operator."
      
      Note that LLVM's linker does not adhere to the GNU ld's implementation
      and as such requires implicitly-absolute terms to be explicitly marked
      as absolute in the linker script. If not, it fails currently with:
      
        ld.lld: error: ./arch/x86/kernel/vmlinux.lds:153: at least one side of the expression must be absolute
        ld.lld: error: ./arch/x86/kernel/vmlinux.lds:154: at least one side of the expression must be absolute
        Makefile:1040: recipe for target 'vmlinux' failed
      
      This is not a functional change for ld.bfd which converts the term to an
      absolute symbol anyways as specified above.
      
      Based on a previous submission by Tri Vo <trong@android.com>.
      Reported-by: default avatarDmitry Golovin <dima@golovin.in>
      Signed-off-by: default avatarRafael Ávila de Espíndola <rafael@espindo.la>
      [ Update commit message per Boris' and Michael's suggestions. ]
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      [ Massage commit message more, fix typos. ]
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Tested-by: default avatarDmitry Golovin <dima@golovin.in>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Brijesh Singh <brijesh.singh@amd.com>
      Cc: Cao Jin <caoj.fnst@cn.fujitsu.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tri Vo <trong@android.com>
      Cc: dima@golovin.in
      Cc: morbo@google.com
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20181219190145.252035-1-ndesaulniers@google.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      648b949b
    • Zumeng Chen's avatar
      wlcore: Fix memory leak in case wl12xx_fetch_firmware failure · 52cd9e0e
      Zumeng Chen authored
      [ Upstream commit ba2ffc96 ]
      
      Release fw_status, raw_fw_status, and tx_res_if when wl12xx_fetch_firmware
      failed instead of meaningless goto out to avoid the following memory leak
      reports(Only the last one listed):
      
      unreferenced object 0xc28a9a00 (size 512):
        comm "kworker/0:4", pid 31298, jiffies 2783204 (age 203.290s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
        backtrace:
          [<6624adab>] kmemleak_alloc+0x40/0x74
          [<500ddb31>] kmem_cache_alloc_trace+0x1ac/0x270
          [<db4d731d>] wl12xx_chip_wakeup+0xc4/0x1fc [wlcore]
          [<76c5db53>] wl1271_op_add_interface+0x4a4/0x8f4 [wlcore]
          [<cbf30777>] drv_add_interface+0xa4/0x1a0 [mac80211]
          [<65bac325>] ieee80211_reconfig+0x9c0/0x1644 [mac80211]
          [<2817c80e>] ieee80211_restart_work+0x90/0xc8 [mac80211]
          [<7e1d425a>] process_one_work+0x284/0x42c
          [<55f9432e>] worker_thread+0x2fc/0x48c
          [<abb582c6>] kthread+0x148/0x160
          [<63144b13>] ret_from_fork+0x14/0x2c
          [< (null)>] (null)
          [<1f6e7715>] 0xffffffff
      Signed-off-by: default avatarZumeng Chen <zumeng.chen@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      52cd9e0e
    • Hans de Goede's avatar
      brcmfmac: Use firmware_request_nowarn for the clm_blob · 05b23c66
      Hans de Goede authored
      [ Upstream commit 4ad0be16 ]
      
      The linux-firmware brcmfmac firmware files contain an embedded table with
      per country allowed channels and strength info.
      
      For recent hardware these versions of the firmware are specially build for
      linux-firmware, the firmware files directly available from Cypress rely on
      a separate clm_blob file for this info.
      
      For some unknown reason Cypress refuses to provide the standard firmware
      files + clm_blob files it uses elsewhere for inclusion into linux-firmware,
      instead relying on these special builds with the clm_blob info embedded.
      This means that the linux-firmware firmware versions often lag behind,
      but I digress.
      
      The brcmfmac driver does support the separate clm_blob file and always
      tries to load this. Currently we use request_firmware for this. This means
      that on any standard install, using the standard combo of linux-kernel +
      linux-firmware, we will get a warning:
      "Direct firmware load for ... failed with error -2"
      
      On top of this, brcmfmac itself prints: "no clm_blob available (err=-2),
      device may have limited channels available".
      
      This commit switches to firmware_request_nowarn, fixing almost any brcmfmac
      device logging the warning (it leaves the brcmfmac info message in place).
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      05b23c66
    • Ondrej Mosnacek's avatar
      selinux: do not override context on context mounts · e30e0b09
      Ondrej Mosnacek authored
      [ Upstream commit 53e0c2aa ]
      
      Ignore all selinux_inode_notifysecctx() calls on mounts with SBLABEL_MNT
      flag unset. This is achived by returning -EOPNOTSUPP for this case in
      selinux_inode_setsecurtity() (because that function should not be called
      in such case anyway) and translating this error to 0 in
      selinux_inode_notifysecctx().
      
      This fixes behavior of kernfs-based filesystems when mounted with the
      'context=' option. Before this patch, if a node's context had been
      explicitly set to a non-default value and later the filesystem has been
      remounted with the 'context=' option, then this node would show up as
      having the manually-set context and not the mount-specified one.
      
      Steps to reproduce:
          # mount -t cgroup2 cgroup2 /sys/fs/cgroup/unified
          # chcon unconfined_u:object_r:user_home_t:s0 /sys/fs/cgroup/unified/cgroup.stat
          # ls -lZ /sys/fs/cgroup/unified
          total 0
          -r--r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.controllers
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.max.depth
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.max.descendants
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.procs
          -r--r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Dec 13 10:41 cgroup.stat
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.subtree_control
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.threads
          # umount /sys/fs/cgroup/unified
          # mount -o context=system_u:object_r:tmpfs_t:s0 -t cgroup2 cgroup2 /sys/fs/cgroup/unified
      
      Result before:
          # ls -lZ /sys/fs/cgroup/unified
          total 0
          -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.controllers
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.max.depth
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.max.descendants
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.procs
          -r--r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Dec 13 10:41 cgroup.stat
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.subtree_control
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.threads
      
      Result after:
          # ls -lZ /sys/fs/cgroup/unified
          total 0
          -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.controllers
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.depth
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.descendants
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.procs
          -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.stat
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.subtree_control
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.threads
      Signed-off-by: default avatarOndrej Mosnacek <omosnace@redhat.com>
      Reviewed-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e30e0b09
    • George Rimar's avatar
      x86/build: Specify elf_i386 linker emulation explicitly for i386 objects · d2053718
      George Rimar authored
      [ Upstream commit 927185c1 ]
      
      The kernel uses the OUTPUT_FORMAT linker script command in it's linker
      scripts. Most of the time, the -m option is passed to the linker with
      correct architecture, but sometimes (at least for x86_64) the -m option
      contradicts the OUTPUT_FORMAT directive.
      
      Specifically, arch/x86/boot and arch/x86/realmode/rm produce i386 object
      files, but are linked with the -m elf_x86_64 linker flag when building
      for x86_64.
      
      The GNU linker manpage doesn't explicitly state any tie-breakers between
      -m and OUTPUT_FORMAT. But with BFD and Gold linkers, OUTPUT_FORMAT
      overrides the emulation value specified with the -m option.
      
      LLVM lld has a different behavior, however. When supplied with
      contradicting -m and OUTPUT_FORMAT values it fails with the following
      error message:
      
        ld.lld: error: arch/x86/realmode/rm/header.o is incompatible with elf_x86_64
      
      Therefore, just add the correct -m after the incorrect one (it overrides
      it), so the linker invocation looks like this:
      
        ld -m elf_x86_64 -z max-page-size=0x200000 -m elf_i386 --emit-relocs -T \
          realmode.lds header.o trampoline_64.o stack.o reboot.o -o realmode.elf
      
      This is not a functional change for GNU ld, because (although not
      explicitly documented) OUTPUT_FORMAT overrides -m EMULATION.
      
      Tested by building x86_64 kernel with GNU gcc/ld toolchain and booting
      it in QEMU.
      
       [ bp: massage and clarify text. ]
      Suggested-by: default avatarDmitry Golovin <dima@golovin.in>
      Signed-off-by: default avatarGeorge Rimar <grimar@accesssoftek.com>
      Signed-off-by: default avatarTri Vo <trong@android.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Tested-by: default avatarTri Vo <trong@android.com>
      Tested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Michael Matz <matz@suse.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: morbo@google.com
      Cc: ndesaulniers@google.com
      Cc: ruiu@google.com
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190111201012.71210-1-trong@android.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      d2053718
    • Daniel Vetter's avatar
      drm/nouveau: Stop using drm_crtc_force_disable · e0662d00
      Daniel Vetter authored
      [ Upstream commit 934c5b32 ]
      
      The correct way for legacy drivers to update properties that need to
      do a full modeset, is to do a full modeset.
      
      Note that we don't need to call the drm_mode_config_internal helper
      because we're not changing any of the refcounted paramters.
      
      v2: Fixup error handling (Ville). Since the old code didn't bother
      I decided to just delete it instead of adding even more code for just
      error handling.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
      Cc: Sean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181217194303.14397-2-daniel.vetter@ffwll.chSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      e0662d00
    • Paul Kocialkowski's avatar
      drm: Auto-set allow_fb_modifiers when given modifiers at plane init · 1d377200
      Paul Kocialkowski authored
      [ Upstream commit 890880dd ]
      
      When drivers pass non-empty lists of modifiers for initializing their
      planes, we can infer that they allow framebuffer modifiers and set the
      driver's allow_fb_modifiers mode config element.
      
      In case the allow_fb_modifiers element was not set (some drivers tend
      to set them after registering planes), the modifiers will still be
      registered but won't be available to userspace unless the flag is set
      later. However in that case, the IN_FORMATS blob won't be created.
      
      In order to avoid this case and generally reduce the trouble associated
      with the flag, always set allow_fb_modifiers when a non-empty list of
      format modifiers is passed at plane init.
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarPaul Kocialkowski <paul.kocialkowski@bootlin.com>
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190104085610.5829-1-paul.kocialkowski@bootlin.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      1d377200
    • Martin Blumenstingl's avatar
      pinctrl: meson: meson8b: add the eth_rxd2 and eth_rxd3 pins · 27d6de37
      Martin Blumenstingl authored
      [ Upstream commit 6daae002 ]
      
      Gigabit Ethernet requires the Ethernet TXD0..3 and RXD0..3 data lines.
      Add the missing eth_rxd2 and eth_rxd3 definitions so we don't have to
      rely on the bootloader to set them up correctly.
      
      The vendor u-boot sources for Odroid-C1 use the following Ethernet
      pinmux configuration:
        SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_6, 0x3f4f);
        SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_7, 0xf00000);
      This translates to the following pin groups in the mainline kernel:
      - register 6 bit  0: eth_rxd1 (DIF_0_P)
      - register 6 bit  1: eth_rxd0 (DIF_0_N)
      - register 6 bit  2: eth_rx_dv (DIF_1_P)
      - register 6 bit  3: eth_rx_clk (DIF_1_N)
      - register 6 bit  6: eth_tx_en (DIF_3_P)
      - register 6 bit  8: eth_ref_clk (DIF_3_N)
      - register 6 bit  9: eth_mdc (DIF_4_P)
      - register 6 bit 10: eth_mdio_en (DIF_4_N)
      - register 6 bit 11: eth_tx_clk (GPIOH_9)
      - register 6 bit 12: eth_txd2 (GPIOH_8)
      - register 6 bit 13: eth_txd3 (GPIOH_7)
      - register 7 bit 20: eth_txd0_0 (GPIOH_6)
      - register 7 bit 21: eth_txd1_0 (GPIOH_5)
      - register 7 bit 22: eth_rxd3 (DIF_2_P)
      - register 7 bit 23: eth_rxd2 (DIF_2_N)
      
      All functions except eth_rxd2 and eth_rxd3 are already supported by the
      pinctrl-meson8b driver.
      Suggested-by: default avatarJianxin Pan <jianxin.pan@amlogic.com>
      Signed-off-by: default avatarMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Reviewed-by: default avatarKevin Hilman <khilman@baylibre.com>
      Tested-by: default avatarEmiliano Ingrassia <ingrassia@epigenesys.com>
      Reviewed-by: default avatarEmiliano Ingrassia <ingrassia@epigenesys.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      27d6de37
    • Axel Lin's avatar
      regulator: act8865: Fix act8600_sudcdc_voltage_ranges setting · 61174e34
      Axel Lin authored
      [ Upstream commit f01a7beb ]
      
      The act8600_sudcdc_voltage_ranges setting does not match the datasheet.
      
      The problems in below entry:
        REGULATOR_LINEAR_RANGE(19000000, 191, 255, 400000),
      
      1. The off-by-one min_sel causes wrong volatage calculation.
         The min_sel should be 192.
      2. According to the datasheet[1] Table 7. (on page 43):
         The selector 248 (0b11111000) ~ 255 (0b11111111) are 41.400V.
      
      Also fix off-by-one for ACT8600_SUDCDC_VOLTAGE_NUM.
      
      [1] https://active-semi.com/wp-content/uploads/ACT8600_Datasheet.pdf
      
      Fixes: df3a950e ("regulator: act8865: Add act8600 support")
      Signed-off-by: default avatarAxel Lin <axel.lin@ingics.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      61174e34
    • Pawe? Chmiel's avatar
      media: s5p-jpeg: Check for fmt_ver_flag when doing fmt enumeration · bcdd4a5e
      Pawe? Chmiel authored
      [ Upstream commit 49710c32 ]
      
      Previously when doing format enumeration, it was returning all
       formats supported by driver, even if they're not supported by hw.
      Add missing check for fmt_ver_flag, so it'll be fixed and only those
       supported by hw will be returned. Similar thing is already done
       in s5p_jpeg_find_format.
      
      It was found by using v4l2-compliance tool and checking result
       of VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS test
      and using v4l2-ctl to get list of all supported formats.
      
      Tested on s5pv210-galaxys (Samsung i9000 phone).
      
      Fixes: bb677f3a ("[media] Exynos4 JPEG codec v4l2 driver")
      Signed-off-by: default avatarPawe? Chmiel <pawel.mikolaj.chmiel@gmail.com>
      Reviewed-by: default avatarJacek Anaszewski <jacek.anaszewski@gmail.com>
      [hverkuil-cisco@xs4all.nl: fix a few alignment issues]
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bcdd4a5e
    • Steve Longerbeam's avatar
      media: rcar-vin: Allow independent VIN link enablement · 9bfd4ab5
      Steve Longerbeam authored
      [ Upstream commit c5ff0edb ]
      
      There is a block of code in rvin_group_link_notify() that prevents
      enabling a link to a VIN node if any entity in the media graph is
      in use. This prevents enabling a VIN link even if there is an in-use
      entity somewhere in the graph that is independent of the link's
      pipeline.
      
      For example, the code block will prevent enabling a link from
      the first rcar-csi2 receiver to a VIN node even if there is an
      enabled link somewhere far upstream on the second independent
      rcar-csi2 receiver pipeline.
      
      If this code block is meant to prevent modifying a link if any entity
      in the graph is actively involved in streaming (because modifying
      the CHSEL register fields can disrupt any/all running streams), then
      the entities stream counts should be checked rather than the use counts.
      
      (There is already such a check in __media_entity_setup_link() that verifies
      the stream_count of the link's source and sink entities are both zero,
      but that is insufficient, since there should be no running streams in
      the entire graph).
      
      Modify the code block to check the entity stream_count instead of the
      use_count (and elaborate on the comment). VIN node links can now be
      enabled even if there are other independent in-use entities that are
      not streaming.
      
      Fixes: c0cc5aef ("media: rcar-vin: add link notify for Gen3")
      Signed-off-by: default avatarSteve Longerbeam <slongerbeam@gmail.com>
      Reviewed-by: default avatarNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9bfd4ab5
    • Florian Westphal's avatar
      netfilter: physdev: relax br_netfilter dependency · 2e6bcc32
      Florian Westphal authored
      [ Upstream commit 8e2f311a ]
      
      Following command:
        iptables -D FORWARD -m physdev ...
      causes connectivity loss in some setups.
      
      Reason is that iptables userspace will probe kernel for the module revision
      of the physdev patch, and physdev has an artificial dependency on
      br_netfilter (xt_physdev use makes no sense unless a br_netfilter module
      is loaded).
      
      This causes the "phydev" module to be loaded, which in turn enables the
      "call-iptables" infrastructure.
      
      bridged packets might then get dropped by the iptables ruleset.
      
      The better fix would be to change the "call-iptables" defaults to 0 and
      enforce explicit setting to 1, but that breaks backwards compatibility.
      
      This does the next best thing: add a request_module call to checkentry.
      This was a stray '-D ... -m physdev' won't activate br_netfilter
      anymore.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2e6bcc32
    • Shunyong Yang's avatar
      dmaengine: qcom_hidma: initialize tx flags in hidma_prep_dma_* · 24296fbc
      Shunyong Yang authored
      [ Upstream commit 875aac8a ]
      
      In async_tx_test_ack(), it uses flags in struct dma_async_tx_descriptor
      to check the ACK status. As hidma reuses the descriptor in a free list
      when hidma_prep_dma_*(memcpy/memset) is called, the flag will keep ACKed
      if the descriptor has been used before. This will cause a BUG_ON in
      async_tx_quiesce().
      
        kernel BUG at crypto/async_tx/async_tx.c:282!
        Internal error: Oops - BUG: 0 1 SMP
        ...
        task: ffff8017dd3ec000 task.stack: ffff8017dd3e8000
        PC is at async_tx_quiesce+0x54/0x78 [async_tx]
        LR is at async_trigger_callback+0x98/0x110 [async_tx]
      
      This patch initializes flags in dma_async_tx_descriptor by the flags
      passed from the caller when hidma_prep_dma_*(memcpy/memset) is called.
      
      Cc: Joey Zheng <yu.zheng@hxt-semitech.com>
      Reviewed-by: default avatarSinan Kaya <okaya@kernel.org>
      Signed-off-by: default avatarShunyong Yang <shunyong.yang@hxt-semitech.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      24296fbc
    • Shunyong Yang's avatar
      dmaengine: qcom_hidma: assign channel cookie correctly · c55f4a6e
      Shunyong Yang authored
      [ Upstream commit 546c0547 ]
      
      When dma_cookie_complete() is called in hidma_process_completed(),
      dma_cookie_status() will return DMA_COMPLETE in hidma_tx_status(). Then,
      hidma_txn_is_success() will be called to use channel cookie
      mchan->last_success to do additional DMA status check. Current code
      assigns mchan->last_success after dma_cookie_complete(). This causes
      a race condition of dma_cookie_status() returns DMA_COMPLETE before
      mchan->last_success is assigned correctly. The race will cause
      hidma_tx_status() return DMA_ERROR but the transaction is actually a
      success. Moreover, in async_tx case, it will cause a timeout panic
      in async_tx_quiesce().
      
       Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for
       transaction
       ...
       Call trace:
       [<ffff000008089994>] dump_backtrace+0x0/0x1f4
       [<ffff000008089bac>] show_stack+0x24/0x2c
       [<ffff00000891e198>] dump_stack+0x84/0xa8
       [<ffff0000080da544>] panic+0x12c/0x29c
       [<ffff0000045d0334>] async_tx_quiesce+0xa4/0xc8 [async_tx]
       [<ffff0000045d03c8>] async_trigger_callback+0x70/0x1c0 [async_tx]
       [<ffff0000048b7d74>] raid_run_ops+0x86c/0x1540 [raid456]
       [<ffff0000048bd084>] handle_stripe+0x5e8/0x1c7c [raid456]
       [<ffff0000048be9ec>] handle_active_stripes.isra.45+0x2d4/0x550 [raid456]
       [<ffff0000048beff4>] raid5d+0x38c/0x5d0 [raid456]
       [<ffff000008736538>] md_thread+0x108/0x168
       [<ffff0000080fb1cc>] kthread+0x10c/0x138
       [<ffff000008084d34>] ret_from_fork+0x10/0x18
      
      Cc: Joey Zheng <yu.zheng@hxt-semitech.com>
      Reviewed-by: default avatarSinan Kaya <okaya@kernel.org>
      Signed-off-by: default avatarShunyong Yang <shunyong.yang@hxt-semitech.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c55f4a6e
    • Anders Roxell's avatar
      dmaengine: imx-dma: fix warning comparison of distinct pointer types · afacaf85
      Anders Roxell authored
      [ Upstream commit 9227ab56 ]
      
      The warning got introduced by commit 930507c1 ("arm64: add basic
      Kconfig symbols for i.MX8"). Since it got enabled for arm64. The warning
      haven't been seen before since size_t was 'unsigned int' when built on
      arm32.
      
      ../drivers/dma/imx-dma.c: In function ‘imxdma_sg_next’:
      ../include/linux/kernel.h:846:29: warning: comparison of distinct pointer types lacks a cast
         (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
                                   ^~
      ../include/linux/kernel.h:860:4: note: in expansion of macro ‘__typecheck’
         (__typecheck(x, y) && __no_side_effects(x, y))
          ^~~~~~~~~~~
      ../include/linux/kernel.h:870:24: note: in expansion of macro ‘__safe_cmp’
        __builtin_choose_expr(__safe_cmp(x, y), \
                              ^~~~~~~~~~
      ../include/linux/kernel.h:879:19: note: in expansion of macro ‘__careful_cmp’
       #define min(x, y) __careful_cmp(x, y, <)
                         ^~~~~~~~~~~~~
      ../drivers/dma/imx-dma.c:288:8: note: in expansion of macro ‘min’
        now = min(d->len, sg_dma_len(sg));
              ^~~
      
      Rework so that we use min_t and pass in the size_t that returns the
      minimum of two values, using the specified type.
      Signed-off-by: default avatarAnders Roxell <anders.roxell@linaro.org>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Reviewed-by: default avatarFabio Estevam <festevam@gmail.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      afacaf85
    • Valentin Schneider's avatar
      cpu/hotplug: Mute hotplug lockdep during init · fba4c61e
      Valentin Schneider authored
      [ Upstream commit ce48c457 ]
      
      Since we've had:
      
        commit cb538267 ("jump_label/lockdep: Assert we hold the hotplug lock for _cpuslocked() operations")
      
      we've been getting some lockdep warnings during init, such as on HiKey960:
      
      [    0.820495] WARNING: CPU: 4 PID: 0 at kernel/cpu.c:316 lockdep_assert_cpus_held+0x3c/0x48
      [    0.820498] Modules linked in:
      [    0.820509] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G S                4.20.0-rc5-00051-g4cae42a #34
      [    0.820511] Hardware name: HiKey960 (DT)
      [    0.820516] pstate: 600001c5 (nZCv dAIF -PAN -UAO)
      [    0.820520] pc : lockdep_assert_cpus_held+0x3c/0x48
      [    0.820523] lr : lockdep_assert_cpus_held+0x38/0x48
      [    0.820526] sp : ffff00000a9cbe50
      [    0.820528] x29: ffff00000a9cbe50 x28: 0000000000000000
      [    0.820533] x27: 00008000b69e5000 x26: ffff8000bff4cfe0
      [    0.820537] x25: ffff000008ba69e0 x24: 0000000000000001
      [    0.820541] x23: ffff000008fce000 x22: ffff000008ba70c8
      [    0.820545] x21: 0000000000000001 x20: 0000000000000003
      [    0.820548] x19: ffff00000a35d628 x18: ffffffffffffffff
      [    0.820552] x17: 0000000000000000 x16: 0000000000000000
      [    0.820556] x15: ffff00000958f848 x14: 455f3052464d4d34
      [    0.820559] x13: 00000000769dde98 x12: ffff8000bf3f65a8
      [    0.820564] x11: 0000000000000000 x10: ffff00000958f848
      [    0.820567] x9 : ffff000009592000 x8 : ffff00000958f848
      [    0.820571] x7 : ffff00000818ffa0 x6 : 0000000000000000
      [    0.820574] x5 : 0000000000000000 x4 : 0000000000000001
      [    0.820578] x3 : 0000000000000000 x2 : 0000000000000001
      [    0.820582] x1 : 00000000ffffffff x0 : 0000000000000000
      [    0.820587] Call trace:
      [    0.820591]  lockdep_assert_cpus_held+0x3c/0x48
      [    0.820598]  static_key_enable_cpuslocked+0x28/0xd0
      [    0.820606]  arch_timer_check_ool_workaround+0xe8/0x228
      [    0.820610]  arch_timer_starting_cpu+0xe4/0x2d8
      [    0.820615]  cpuhp_invoke_callback+0xe8/0xd08
      [    0.820619]  notify_cpu_starting+0x80/0xb8
      [    0.820625]  secondary_start_kernel+0x118/0x1d0
      
      We've also had a similar warning in sched_init_smp() for every
      asymmetric system that would enable the sched_asym_cpucapacity static
      key, although that was singled out in:
      
        commit 40fa3780 ("sched/core: Take the hotplug lock in sched_init_smp()")
      
      Those warnings are actually harmless, since we cannot have hotplug
      operations at the time they appear. Instead of starting to sprinkle
      useless hotplug lock operations in the init codepaths, mute the
      warnings until they start warning about real problems.
      Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarValentin Schneider <valentin.schneider@arm.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: cai@gmx.us
      Cc: daniel.lezcano@linaro.org
      Cc: dietmar.eggemann@arm.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: longman@redhat.com
      Cc: marc.zyngier@arm.com
      Cc: mark.rutland@arm.com
      Link: https://lkml.kernel.org/r/1545243796-23224-2-git-send-email-valentin.schneider@arm.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fba4c61e
    • Buland Singh's avatar
      hpet: Fix missing '=' character in the __setup() code of hpet_mmap_enable · a6c671e2
      Buland Singh authored
      [ Upstream commit 24d48a61 ]
      
      Commit '3d035f58 ("drivers/char/hpet.c: allow user controlled mmap for
      user processes")' introduced a new kernel command line parameter hpet_mmap,
      that is required to expose the memory map of the HPET registers to
      user-space. Unfortunately the kernel command line parameter 'hpet_mmap' is
      broken and never takes effect due to missing '=' character in the __setup()
      code of hpet_mmap_enable.
      
      Before this patch:
      
      dmesg output with the kernel command line parameter hpet_mmap=1
      
      [    0.204152] HPET mmap disabled
      
      dmesg output with the kernel command line parameter hpet_mmap=0
      
      [    0.204192] HPET mmap disabled
      
      After this patch:
      
      dmesg output with the kernel command line parameter hpet_mmap=1
      
      [    0.203945] HPET mmap enabled
      
      dmesg output with the kernel command line parameter hpet_mmap=0
      
      [    0.204652] HPET mmap disabled
      
      Fixes: 3d035f58 ("drivers/char/hpet.c: allow user controlled mmap for user processes")
      Signed-off-by: default avatarBuland Singh <bsingh@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a6c671e2