Tom Rix [Wed, 10 Jun 2020 21:57:13 +0000 (14:57 -0700)]
selinux: fix double free
commit
65de50969a77509452ae590e9449b70a22b923bb upstream.
Clang's static analysis tool reports these double free memory errors.
security/selinux/ss/services.c:2987:4: warning: Attempt to free released memory [unix.Malloc]
kfree(bnames[i]);
^~~~~~~~~~~~~~~~
security/selinux/ss/services.c:2990:2: warning: Attempt to free released memory [unix.Malloc]
kfree(bvalues);
^~~~~~~~~~~~~~
So improve the security_get_bools error handling by freeing these variables
and setting their return pointers to NULL and the return len to 0
Cc: stable@vger.kernel.org
Signed-off-by: Tom Rix <trix@redhat.com>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Huacai Chen [Tue, 31 Mar 2020 06:18:08 +0000 (14:18 +0800)]
drm/qxl: Use correct notify port address when creating cursor ring
commit
80e5f89da3ab949fbbf1cae01dfaea29f5483a75 upstream.
The command ring and cursor ring use different notify port addresses
definition: QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR. However, in
qxl_device_init() we use QXL_IO_NOTIFY_CMD to create both command ring
and cursor ring. This doesn't cause any problems now, because QEMU's
behaviors on QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR are the same.
However, QEMU's behavior may be change in future, so let's fix it.
P.S.: In the X.org QXL driver, the notify port address of cursor ring
is correct.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: <stable@vger.kernel.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1585635488-17507-1-git-send-email-chenhc@lemote.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lyude Paul [Fri, 3 Apr 2020 18:08:32 +0000 (14:08 -0400)]
drm/dp_mst: Reformat drm_dp_check_act_status() a bit
commit
a5cb5fa6c3a5c2cf492db667b8670ee7b044b79f upstream.
Just add a bit more line wrapping, get rid of some extraneous
whitespace, remove an unneeded goto label, and move around some variable
declarations. No functional changes here.
Signed-off-by: Lyude Paul <lyude@redhat.com>
[this isn't a fix, but it's needed for the fix that comes after this]
Fixes:
ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
Cc: Sean Paul <sean@poorly.run>
Cc: <stable@vger.kernel.org> # v3.17+
Reviewed-by: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-3-lyude@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wolfram Sang [Mon, 15 Jun 2020 07:58:10 +0000 (09:58 +0200)]
drm: encoder_slave: fix refcouting error for modules
[ Upstream commit
f78d4032de60f50fd4afaa0fb68ea03b985f820a ]
module_put() balances try_module_get(), not request_module(). Fix the
error path to match that.
Fixes:
2066facca4c7 ("drm/kms: slave encoder interface.")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kai-Heng Feng [Wed, 3 Jun 2020 07:48:19 +0000 (15:48 +0800)]
libata: Use per port sync for detach
[ Upstream commit
b5292111de9bb70cba3489075970889765302136 ]
Commit
130f4caf145c ("libata: Ensure ata_port probe has completed before
detach") may cause system freeze during suspend.
Using async_synchronize_full() in PM callbacks is wrong, since async
callbacks that are already scheduled may wait for not-yet-scheduled
callbacks, causes a circular dependency.
Instead of using big hammer like async_synchronize_full(), use async
cookie to make sure port probe are synced, without affecting other
scheduled PM callbacks.
Fixes:
130f4caf145c ("libata: Ensure ata_port probe has completed before detach")
Suggested-by: John Garry <john.garry@huawei.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: John Garry <john.garry@huawei.com>
BugLink: https://bugs.launchpad.net/bugs/1867983
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jason Yan [Tue, 16 Jun 2020 12:16:55 +0000 (20:16 +0800)]
block: Fix use-after-free in blkdev_get()
[ Upstream commit
2d3a8e2deddea6c89961c422ec0c5b851e648c14 ]
In blkdev_get() we call __blkdev_get() to do some internal jobs and if
there is some errors in __blkdev_get(), the bdput() is called which
means we have released the refcount of the bdev (actually the refcount of
the bdev inode). This means we cannot access bdev after that point. But
acctually bdev is still accessed in blkdev_get() after calling
__blkdev_get(). This results in use-after-free if the refcount is the
last one we released in __blkdev_get(). Let's take a look at the
following scenerio:
CPU0 CPU1 CPU2
blkdev_open blkdev_open Remove disk
bd_acquire
blkdev_get
__blkdev_get del_gendisk
bdev_unhash_inode
bd_acquire bdev_get_gendisk
bd_forget failed because of unhashed
bdput
bdput (the last one)
bdev_evict_inode
access bdev => use after free
[ 459.350216] BUG: KASAN: use-after-free in __lock_acquire+0x24c1/0x31b0
[ 459.351190] Read of size 8 at addr
ffff88806c815a80 by task syz-executor.0/20132
[ 459.352347]
[ 459.352594] CPU: 0 PID: 20132 Comm: syz-executor.0 Not tainted 4.19.90 #2
[ 459.353628] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 459.354947] Call Trace:
[ 459.355337] dump_stack+0x111/0x19e
[ 459.355879] ? __lock_acquire+0x24c1/0x31b0
[ 459.356523] print_address_description+0x60/0x223
[ 459.357248] ? __lock_acquire+0x24c1/0x31b0
[ 459.357887] kasan_report.cold+0xae/0x2d8
[ 459.358503] __lock_acquire+0x24c1/0x31b0
[ 459.359120] ? _raw_spin_unlock_irq+0x24/0x40
[ 459.359784] ? lockdep_hardirqs_on+0x37b/0x580
[ 459.360465] ? _raw_spin_unlock_irq+0x24/0x40
[ 459.361123] ? finish_task_switch+0x125/0x600
[ 459.361812] ? finish_task_switch+0xee/0x600
[ 459.362471] ? mark_held_locks+0xf0/0xf0
[ 459.363108] ? __schedule+0x96f/0x21d0
[ 459.363716] lock_acquire+0x111/0x320
[ 459.364285] ? blkdev_get+0xce/0xbe0
[ 459.364846] ? blkdev_get+0xce/0xbe0
[ 459.365390] __mutex_lock+0xf9/0x12a0
[ 459.365948] ? blkdev_get+0xce/0xbe0
[ 459.366493] ? bdev_evict_inode+0x1f0/0x1f0
[ 459.367130] ? blkdev_get+0xce/0xbe0
[ 459.367678] ? destroy_inode+0xbc/0x110
[ 459.368261] ? mutex_trylock+0x1a0/0x1a0
[ 459.368867] ? __blkdev_get+0x3e6/0x1280
[ 459.369463] ? bdev_disk_changed+0x1d0/0x1d0
[ 459.370114] ? blkdev_get+0xce/0xbe0
[ 459.370656] blkdev_get+0xce/0xbe0
[ 459.371178] ? find_held_lock+0x2c/0x110
[ 459.371774] ? __blkdev_get+0x1280/0x1280
[ 459.372383] ? lock_downgrade+0x680/0x680
[ 459.373002] ? lock_acquire+0x111/0x320
[ 459.373587] ? bd_acquire+0x21/0x2c0
[ 459.374134] ? do_raw_spin_unlock+0x4f/0x250
[ 459.374780] blkdev_open+0x202/0x290
[ 459.375325] do_dentry_open+0x49e/0x1050
[ 459.375924] ? blkdev_get_by_dev+0x70/0x70
[ 459.376543] ? __x64_sys_fchdir+0x1f0/0x1f0
[ 459.377192] ? inode_permission+0xbe/0x3a0
[ 459.377818] path_openat+0x148c/0x3f50
[ 459.378392] ? kmem_cache_alloc+0xd5/0x280
[ 459.379016] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 459.379802] ? path_lookupat.isra.0+0x900/0x900
[ 459.380489] ? __lock_is_held+0xad/0x140
[ 459.381093] do_filp_open+0x1a1/0x280
[ 459.381654] ? may_open_dev+0xf0/0xf0
[ 459.382214] ? find_held_lock+0x2c/0x110
[ 459.382816] ? lock_downgrade+0x680/0x680
[ 459.383425] ? __lock_is_held+0xad/0x140
[ 459.384024] ? do_raw_spin_unlock+0x4f/0x250
[ 459.384668] ? _raw_spin_unlock+0x1f/0x30
[ 459.385280] ? __alloc_fd+0x448/0x560
[ 459.385841] do_sys_open+0x3c3/0x500
[ 459.386386] ? filp_open+0x70/0x70
[ 459.386911] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 459.387610] ? trace_hardirqs_off_caller+0x55/0x1c0
[ 459.388342] ? do_syscall_64+0x1a/0x520
[ 459.388930] do_syscall_64+0xc3/0x520
[ 459.389490] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 459.390248] RIP: 0033:0x416211
[ 459.390720] Code: 75 14 b8 02 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83
04 19 00 00 c3 48 83 ec 08 e8 0a fa ff ff 48 89 04 24 b8 02 00 00 00 0f
05 <48> 8b 3c 24 48 89 c2 e8 53 fa ff ff 48 89 d0 48 83 c4 08 48 3d
01
[ 459.393483] RSP: 002b:
00007fe45dfe9a60 EFLAGS:
00000293 ORIG_RAX:
0000000000000002
[ 459.394610] RAX:
ffffffffffffffda RBX:
00007fe45dfea6d4 RCX:
0000000000416211
[ 459.395678] RDX:
00007fe45dfe9b0a RSI:
0000000000000002 RDI:
00007fe45dfe9b00
[ 459.396758] RBP:
000000000076bf20 R08:
0000000000000000 R09:
000000000000000a
[ 459.397930] R10:
0000000000000075 R11:
0000000000000293 R12:
00000000ffffffff
[ 459.399022] R13:
0000000000000bd9 R14:
00000000004cdb80 R15:
000000000076bf2c
[ 459.400168]
[ 459.400430] Allocated by task 20132:
[ 459.401038] kasan_kmalloc+0xbf/0xe0
[ 459.401652] kmem_cache_alloc+0xd5/0x280
[ 459.402330] bdev_alloc_inode+0x18/0x40
[ 459.402970] alloc_inode+0x5f/0x180
[ 459.403510] iget5_locked+0x57/0xd0
[ 459.404095] bdget+0x94/0x4e0
[ 459.404607] bd_acquire+0xfa/0x2c0
[ 459.405113] blkdev_open+0x110/0x290
[ 459.405702] do_dentry_open+0x49e/0x1050
[ 459.406340] path_openat+0x148c/0x3f50
[ 459.406926] do_filp_open+0x1a1/0x280
[ 459.407471] do_sys_open+0x3c3/0x500
[ 459.408010] do_syscall_64+0xc3/0x520
[ 459.408572] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 459.409415]
[ 459.409679] Freed by task 1262:
[ 459.410212] __kasan_slab_free+0x129/0x170
[ 459.410919] kmem_cache_free+0xb2/0x2a0
[ 459.411564] rcu_process_callbacks+0xbb2/0x2320
[ 459.412318] __do_softirq+0x225/0x8ac
Fix this by delaying bdput() to the end of blkdev_get() which means we
have finished accessing bdev.
Fixes:
77ea887e433a ("implement in-kernel gendisk events handling")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhiqiang Liu [Sun, 14 Jun 2020 16:53:30 +0000 (00:53 +0800)]
bcache: fix potential deadlock problem in btree_gc_coalesce
[ Upstream commit
be23e837333a914df3f24bf0b32e87b0331ab8d1 ]
coccicheck reports:
drivers/md//bcache/btree.c:1538:1-7: preceding lock on line 1417
In btree_gc_coalesce func, if the coalescing process fails, we will goto
to out_nocoalesce tag directly without releasing new_nodes[i]->write_lock.
Then, it will cause a deadlock when trying to acquire new_nodes[i]->
write_lock for freeing new_nodes[i] before return.
btree_gc_coalesce func details as follows:
if alloc new_nodes[i] fails:
goto out_nocoalesce;
// obtain new_nodes[i]->write_lock
mutex_lock(&new_nodes[i]->write_lock)
// main coalescing process
for (i = nodes - 1; i > 0; --i)
[snipped]
if coalescing process fails:
// Here, directly goto out_nocoalesce
// tag will cause a deadlock
goto out_nocoalesce;
[snipped]
// release new_nodes[i]->write_lock
mutex_unlock(&new_nodes[i]->write_lock)
// coalesing succ, return
return;
out_nocoalesce:
btree_node_free(new_nodes[i]) // free new_nodes[i]
// obtain new_nodes[i]->write_lock
mutex_lock(&new_nodes[i]->write_lock);
// set flag for reuse
clear_bit(BTREE_NODE_dirty, &ew_nodes[i]->flags);
// release new_nodes[i]->write_lock
mutex_unlock(&new_nodes[i]->write_lock);
To fix the problem, we add a new tag 'out_unlock_nocoalesce' for
releasing new_nodes[i]->write_lock before out_nocoalesce tag. If
coalescing process fails, we will go to out_unlock_nocoalesce tag
for releasing new_nodes[i]->write_lock before free new_nodes[i] in
out_nocoalesce tag.
(Coly Li helps to clean up commit log format.)
Fixes:
2a285686c109816 ("bcache: btree locking rework")
Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Signed-off-by: Coly Li <colyli@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gaurav Singh [Mon, 8 Jun 2020 16:18:17 +0000 (13:18 -0300)]
perf report: Fix NULL pointer dereference in hists__fprintf_nr_sample_events()
[ Upstream commit
11b6e5482e178055ec1f2444b55f2518713809d1 ]
The 'evname' variable can be NULL, as it is checked a few lines back,
check it before using.
Fixes:
9e207ddfa207 ("perf report: Show call graph from reference events")
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/
Signed-off-by: Gaurav Singh <gaurav1086@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qais Yousef [Mon, 18 May 2020 15:49:31 +0000 (16:49 +0100)]
usb/ehci-platform: Set PM runtime as active on resume
[ Upstream commit
16bdc04cc98ab0c74392ceef2475ecc5e73fcf49 ]
Follow suit of ohci-platform.c and perform pm_runtime_set_active() on
resume.
ohci-platform.c had a warning reported due to the missing
pm_runtime_set_active() [1].
[1] https://lore.kernel.org/lkml/
20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
CC: Tony Prisk <linux@prisktech.co.nz>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Mathias Nyman <mathias.nyman@intel.com>
CC: Oliver Neukum <oneukum@suse.de>
CC: linux-arm-kernel@lists.infradead.org
CC: linux-usb@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20200518154931.6144-3-qais.yousef@arm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qais Yousef [Mon, 18 May 2020 15:49:30 +0000 (16:49 +0100)]
usb/xhci-plat: Set PM runtime as active on resume
[ Upstream commit
79112cc3c29f4a8c73a21428fbcbcb0afb005e3e ]
Follow suit of ohci-platform.c and perform pm_runtime_set_active() on
resume.
ohci-platform.c had a warning reported due to the missing
pm_runtime_set_active() [1].
[1] https://lore.kernel.org/lkml/
20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
CC: Tony Prisk <linux@prisktech.co.nz>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Mathias Nyman <mathias.nyman@intel.com>
CC: Oliver Neukum <oneukum@suse.de>
CC: linux-arm-kernel@lists.infradead.org
CC: linux-usb@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20200518154931.6144-2-qais.yousef@arm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Sat, 30 May 2020 08:16:22 +0000 (10:16 +0200)]
scsi: acornscsi: Fix an error handling path in acornscsi_probe()
[ Upstream commit
42c76c9848e13dbe0538d7ae0147a269dfa859cb ]
'ret' is known to be 0 at this point. Explicitly return -ENOMEM if one of
the 'ecardm_iomap()' calls fail.
Link: https://lore.kernel.org/r/20200530081622.577888-1-christophe.jaillet@wanadoo.fr
Fixes:
e95a1b656a98 ("[ARM] rpc: acornscsi: update to new style ecard driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
tannerlove [Mon, 8 Jun 2020 19:37:15 +0000 (15:37 -0400)]
selftests/net: in timestamping, strncpy needs to preserve null byte
[ Upstream commit
8027bc0307ce59759b90679fa5d8b22949586d20 ]
If user passed an interface option longer than 15 characters, then
device.ifr_name and hwtstamp.ifr_name became non-null-terminated
strings. The compiler warned about this:
timestamping.c:353:2: warning: ‘strncpy’ specified bound 16 equals \
destination size [-Wstringop-truncation]
353 | strncpy(device.ifr_name, interface, sizeof(device.ifr_name));
Fixes:
cb9eff097831 ("net: new user space API for time stamping of incoming and outgoing packets")
Signed-off-by: Tanner Love <tannerlove@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ram Pai [Thu, 4 Jun 2020 23:52:05 +0000 (16:52 -0700)]
selftests/vm/pkeys: fix alloc_random_pkey() to make it really random
[ Upstream commit
6e373263ce07eeaa6410843179535fbdf561fc31 ]
alloc_random_pkey() was allocating the same pkey every time. Not all
pkeys were geting tested. This fixes it.
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: "Desnes A. Nunes do Rosario" <desnesn@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Michal Suchanek <msuchanek@suse.de>
Cc: Shuah Khan <shuah@kernel.org>
Link: http://lkml.kernel.org/r/0162f55816d4e783a0d6e49e554d0ab9a3c9a23b.1585646528.git.sandipan@linux.ibm.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nick Desaulniers [Thu, 4 Jun 2020 23:50:49 +0000 (16:50 -0700)]
elfnote: mark all .note sections SHF_ALLOC
[ Upstream commit
51da9dfb7f20911ae4e79e9b412a9c2d4c373d4b ]
ELFNOTE_START allows callers to specify flags for .pushsection assembler
directives. All callsites but ELF_NOTE use "a" for SHF_ALLOC. For vdso's
that explicitly use ELF_NOTE_START and BUILD_SALT, the same section is
specified twice after preprocessing, once with "a" flag, once without.
Example:
.pushsection .note.Linux, "a", @note ;
.pushsection .note.Linux, "", @note ;
While GNU as allows this ordering, it warns for the opposite ordering,
making these directives position dependent. We'd prefer not to precisely
match this behavior in Clang's integrated assembler. Instead, the non
__ASSEMBLY__ definition of ELF_NOTE uses
__attribute__((section(".note.Linux"))) which is created with SHF_ALLOC,
so let's make the __ASSEMBLY__ definition of ELF_NOTE consistent with C
and just always use "a" flag.
This allows Clang to assemble a working mainline (5.6) kernel via:
$ make CC=clang AS=clang
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Fangrui Song <maskray@google.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/913
Link: http://lkml.kernel.org/r/20200325231250.99205-1-ndesaulniers@google.com
Debugged-by: Ilie Halip <ilie.halip@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Thu, 4 Jun 2020 23:50:30 +0000 (16:50 -0700)]
include/linux/bitops.h: avoid clang shift-count-overflow warnings
[ Upstream commit
bd93f003b7462ae39a43c531abca37fe7073b866 ]
Clang normally does not warn about certain issues in inline functions when
it only happens in an eliminated code path. However if something else
goes wrong, it does tend to complain about the definition of hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
^~~~~~~~~~~~
include/asm-generic/bitops/const_hweight.h:29:49: note: expanded from macro 'hweight64'
define hweight64(w) (__builtin_constant_p(w) ? __const_hweight64(w) : __arch_hweight64(w))
^~~~~~~~~~~~~~~~~~~~
include/asm-generic/bitops/const_hweight.h:21:76: note: expanded from macro '__const_hweight64'
define __const_hweight64(w) (__const_hweight32(w) + __const_hweight32((w) >> 32))
^ ~~
include/asm-generic/bitops/const_hweight.h:20:49: note: expanded from macro '__const_hweight32'
define __const_hweight32(w) (__const_hweight16(w) + __const_hweight16((w) >> 16))
^
include/asm-generic/bitops/const_hweight.h:19:72: note: expanded from macro '__const_hweight16'
define __const_hweight16(w) (__const_hweight8(w) + __const_hweight8((w) >> 8 ))
^
include/asm-generic/bitops/const_hweight.h:12:9: note: expanded from macro '__const_hweight8'
(!!((w) & (1ULL << 2))) + \
Adding an explicit cast to __u64 avoids that warning and makes it easier
to read other output.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Link: http://lkml.kernel.org/r/20200505135513.65265-1-arnd@arndb.de
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jann Horn [Thu, 4 Jun 2020 23:50:17 +0000 (16:50 -0700)]
lib/zlib: remove outdated and incorrect pre-increment optimization
[ Upstream commit
acaab7335bd6f0c0b54ce3a00bd7f18222ce0f5f ]
The zlib inflate code has an old micro-optimization based on the
assumption that for pre-increment memory accesses, the compiler will
generate code that fits better into the processor's pipeline than what
would be generated for post-increment memory accesses.
This optimization was already removed in upstream zlib in 2016:
https://github.com/madler/zlib/commit/
9aaec95e8211
This optimization causes UB according to C99, which says in section 6.5.6
"Additive operators": "If both the pointer operand and the result point to
elements of the same array object, or one past the last element of the
array object, the evaluation shall not produce an overflow; otherwise, the
behavior is undefined".
This UB is not only a theoretical concern, but can also cause trouble for
future work on compiler-based sanitizers.
According to the zlib commit, this optimization also is not optimal
anymore with modern compilers.
Replace uses of OFF, PUP and UP_UNALIGNED with their definitions in the
POSTINC case, and remove the macro definitions, just like in the upstream
patch.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Link: http://lkml.kernel.org/r/20200507123112.252723-1-jannh@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tero Kristo [Wed, 27 May 2020 12:24:29 +0000 (15:24 +0300)]
crypto: omap-sham - add proper load balancing support for multicore
[ Upstream commit
281c377872ff5d15d80df25fc4df02d2676c7cde ]
The current implementation of the multiple accelerator core support for
OMAP SHA does not work properly. It always picks up the first probed
accelerator core if this is available, and rest of the book keeping also
gets confused if there are two cores available. Add proper load
balancing support for SHA, and also fix any bugs related to the
multicore support while doing it.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Sat, 30 May 2020 20:19:52 +0000 (22:19 +0200)]
pinctrl: imxl: Fix an error handling path in 'imx1_pinctrl_core_probe()'
[ Upstream commit
9eb728321286c4b31e964d2377fca2368526d408 ]
When 'pinctrl_register()' has been turned into 'devm_pinctrl_register()',
an error handling path has not been updated.
Axe a now unneeded 'pinctrl_unregister()'.
Fixes:
e55e025d1687 ("pinctrl: imxl: Use devm_pinctrl_register() for pinctrl registration")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20200530201952.585798-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qiushi Wu [Thu, 28 May 2020 20:13:53 +0000 (15:13 -0500)]
scsi: iscsi: Fix reference count leak in iscsi_boot_create_kobj
[ Upstream commit
0267ffce562c8bbf9b57ebe0e38445ad04972890 ]
kobject_init_and_add() takes reference even when it fails. If this
function returns an error, kobject_put() must be called to properly
clean up the memory associated with the object.
Link: https://lore.kernel.org/r/20200528201353.14849-1-wu000273@umn.edu
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Qiushi Wu <wu000273@umn.edu>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bob Peterson [Wed, 29 Apr 2020 13:45:54 +0000 (08:45 -0500)]
gfs2: Allow lock_nolock mount to specify jid=X
[ Upstream commit
ea22eee4e6027d8927099de344f7fff43c507ef9 ]
Before this patch, a simple typo accidentally added \n to the jid=
string for lock_nolock mounts. This made it impossible to mount a
gfs2 file system with a journal other than journal0. Thus:
mount -tgfs2 -o hostdata="jid=1" <device> <mount pt>
Resulted in:
mount: wrong fs type, bad option, bad superblock on <device>
In most cases this is not a problem. However, for debugging and
testing purposes we sometimes want to test the integrity of other
journals. This patch removes the unnecessary \n and thus allows
lock_nolock users to specify an alternate journal.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stafford Horne [Wed, 22 Apr 2020 11:24:11 +0000 (20:24 +0900)]
openrisc: Fix issue with argument clobbering for clone/fork
[ Upstream commit
6bd140e14d9aaa734ec37985b8b20a96c0ece948 ]
Working on the OpenRISC glibc port I found that sometimes clone was
working strange. That the tls data argument sent in r7 was always
wrong. Further investigation revealed that the arguments were getting
clobbered in the entry code. This patch removes the code that writes to
the argument registers. This was likely due to some old code hanging
around.
This patch fixes this up for clone and fork. This fork clobber is
harmless but also useless so remove.
Signed-off-by: Stafford Horne <shorne@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiyu Yang [Mon, 25 May 2020 14:12:46 +0000 (22:12 +0800)]
ASoC: fsl_asrc_dma: Fix dma_chan leak when config DMA channel failed
[ Upstream commit
36124fb19f1ae68a500cd76a76d40c6e81bee346 ]
fsl_asrc_dma_hw_params() invokes dma_request_channel() or
fsl_asrc_get_dma_channel(), which returns a reference of the specified
dma_chan object to "pair->dma_chan[dir]" with increased refcnt.
The reference counting issue happens in one exception handling path of
fsl_asrc_dma_hw_params(). When config DMA channel failed for Back-End,
the function forgets to decrease the refcnt increased by
dma_request_channel() or fsl_asrc_get_dma_channel(), causing a refcnt
leak.
Fix this issue by calling dma_release_channel() when config DMA channel
failed.
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Link: https://lore.kernel.org/r/1590415966-52416-1-git-send-email-xiyuyang19@fudan.edu.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Sun, 10 May 2020 09:53:03 +0000 (11:53 +0200)]
extcon: adc-jack: Fix an error handling path in 'adc_jack_probe()'
[ Upstream commit
bc84cff2c92ae5ccb2c37da73756e7174b1b430f ]
In some error handling paths, a call to 'iio_channel_get()' is not balanced
by a corresponding call to 'iio_channel_release()'.
This can be achieved easily by using the devm_ variant of
'iio_channel_get()'.
This has the extra benefit to simplify the remove function.
Fixes:
19939860dcae ("extcon: adc_jack: adc-jack driver to support 3.5 pi or simliar devices")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Olga Kornievskaia [Sun, 26 Apr 2020 15:30:00 +0000 (11:30 -0400)]
NFSv4.1 fix rpc_call_done assignment for BIND_CONN_TO_SESSION
[ Upstream commit
1c709b766e73e54d64b1dde1b7cfbcf25bcb15b9 ]
Fixes:
02a95dee8cf0 ("NFS add callback_ops to nfs4_proc_bind_conn_to_session_callback")
Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fedor Tokarev [Sat, 28 Mar 2020 11:56:55 +0000 (14:56 +0300)]
net: sunrpc: Fix off-by-one issues in 'rpc_ntop6'
[ Upstream commit
118917d696dc59fd3e1741012c2f9db2294bed6f ]
Fix off-by-one issues in 'rpc_ntop6':
- 'snprintf' returns the number of characters which would have been
written if enough space had been available, excluding the terminating
null byte. Thus, a return value of 'sizeof(scopebuf)' means that the
last character was dropped.
- 'strcat' adds a terminating null byte to the string, thus if len ==
buflen, the null byte is written past the end of the buffer.
Signed-off-by: Fedor Tokarev <ftokarev@gmail.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Sat, 16 May 2020 08:08:06 +0000 (01:08 -0700)]
clk: bcm2835: Fix return type of bcm2835_register_gate
[ Upstream commit
f376c43bec4f8ee8d1ba5c5c4cfbd6e84fb279cb ]
bcm2835_register_gate is used as a callback for the clk_register member
of bcm2835_clk_desc, which expects a struct clk_hw * return type but
bcm2835_register_gate returns a struct clk *.
This discrepancy is hidden by the fact that bcm2835_register_gate is
cast to the typedef bcm2835_clk_register by the _REGISTER macro. This
turns out to be a control flow integrity violation, which is how this
was noticed.
Change the return type of bcm2835_register_gate to be struct clk_hw *
and use clk_hw_register_gate to do so. This should be a non-functional
change as clk_register_gate calls clk_hw_register_gate anyways but this
is needed to avoid issues with further changes.
Fixes:
b19f009d4510 ("clk: bcm2835: Migrate to clk_hw based registration and OF APIs")
Link: https://github.com/ClangBuiltLinux/linux/issues/1028
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Link: https://lkml.kernel.org/r/20200516080806.1459784-1-natechancellor@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pawel Laszczak [Mon, 18 May 2020 10:08:45 +0000 (12:08 +0200)]
usb: gadget: Fix issue with config_ep_by_speed function
[ Upstream commit
5d363120aa548ba52d58907a295eee25f8207ed2 ]
This patch adds new config_ep_by_speed_and_alt function which
extends the config_ep_by_speed about alt parameter.
This additional parameter allows to find proper usb_ss_ep_comp_descriptor.
Problem has appeared during testing f_tcm (BOT/UAS) driver function.
f_tcm function for SS use array of headers for both BOT/UAS alternate
setting:
static struct usb_descriptor_header *uasp_ss_function_desc[] = {
(struct usb_descriptor_header *) &bot_intf_desc,
(struct usb_descriptor_header *) &uasp_ss_bi_desc,
(struct usb_descriptor_header *) &bot_bi_ep_comp_desc,
(struct usb_descriptor_header *) &uasp_ss_bo_desc,
(struct usb_descriptor_header *) &bot_bo_ep_comp_desc,
(struct usb_descriptor_header *) &uasp_intf_desc,
(struct usb_descriptor_header *) &uasp_ss_bi_desc,
(struct usb_descriptor_header *) &uasp_bi_ep_comp_desc,
(struct usb_descriptor_header *) &uasp_bi_pipe_desc,
(struct usb_descriptor_header *) &uasp_ss_bo_desc,
(struct usb_descriptor_header *) &uasp_bo_ep_comp_desc,
(struct usb_descriptor_header *) &uasp_bo_pipe_desc,
(struct usb_descriptor_header *) &uasp_ss_status_desc,
(struct usb_descriptor_header *) &uasp_status_in_ep_comp_desc,
(struct usb_descriptor_header *) &uasp_status_pipe_desc,
(struct usb_descriptor_header *) &uasp_ss_cmd_desc,
(struct usb_descriptor_header *) &uasp_cmd_comp_desc,
(struct usb_descriptor_header *) &uasp_cmd_pipe_desc,
NULL,
};
The first 5 descriptors are associated with BOT alternate setting,
and others are associated with UAS.
During handling UAS alternate setting f_tcm driver invokes
config_ep_by_speed and this function sets incorrect companion endpoint
descriptor in usb_ep object.
Instead setting ep->comp_desc to uasp_bi_ep_comp_desc function in this
case set ep->comp_desc to uasp_ss_bi_desc.
This is due to the fact that it searches endpoint based on endpoint
address:
for_each_ep_desc(speed_desc, d_spd) {
chosen_desc = (struct usb_endpoint_descriptor *)*d_spd;
if (chosen_desc->bEndpoitAddress == _ep->address)
goto ep_found;
}
And in result it uses the descriptor from BOT alternate setting
instead UAS.
Finally, it causes that controller driver during enabling endpoints
detect that just enabled endpoint for bot.
Signed-off-by: Jayshri Pawar <jpawar@cadence.com>
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qiushi Wu [Sat, 23 May 2020 04:06:25 +0000 (23:06 -0500)]
usb: gadget: fix potential double-free in m66592_probe.
[ Upstream commit
44734a594196bf1d474212f38fe3a0d37a73278b ]
m66592_free_request() is called under label "err_add_udc"
and "clean_up", and m66592->ep0_req is not set to NULL after
first free, leading to a double-free. Fix this issue by
setting m66592->ep0_req to NULL after the first free.
Fixes:
0f91349b89f3 ("usb: gadget: convert all users to the new udc infrastructure")
Signed-off-by: Qiushi Wu <wu000273@umn.edu>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Thu, 21 May 2020 15:13:00 +0000 (16:13 +0100)]
usb: gadget: lpc32xx_udc: don't dereference ep pointer before null check
[ Upstream commit
eafa80041645cd7604c4357b1a0cd4a3c81f2227 ]
Currently pointer ep is being dereferenced before it is null checked
leading to a null pointer dereference issue. Fix this by only assigning
pointer udc once ep is known to be not null. Also remove a debug
message that requires a valid udc which may not be possible at that
point.
Addresses-Coverity: ("Dereference before null check")
Fixes:
24a28e428351 ("USB: gadget driver for LPC32xx")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Thu, 23 Apr 2020 16:29:24 +0000 (09:29 -0700)]
USB: gadget: udc: s3c2410_udc: Remove pointless NULL check in s3c2410_udc_nuke
[ Upstream commit
7a0fbcf7c308920bc6116b3a5fb21c8cc5fec128 ]
Clang warns:
drivers/usb/gadget/udc/s3c2410_udc.c:255:11: warning: comparison of
address of 'ep->queue' equal to a null pointer is always false
[-Wtautological-pointer-compare]
if (&ep->queue == NULL)
~~~~^~~~~ ~~~~
1 warning generated.
It is not wrong, queue is not a pointer so if ep is not NULL, the
address of queue cannot be NULL. No other driver does a check like this
and this check has been around since the driver was first introduced,
presumably with no issues so it does not seem like this check should be
something else. Just remove it.
Commit
afe956c577b2d ("kbuild: Enable -Wtautological-compare") exposed
this but it is not the root cause of the warning.
Fixes:
3fc154b6b8134 ("USB Gadget driver for Samsung s3c2410 ARM SoC")
Link: https://github.com/ClangBuiltLinux/linux/issues/1004
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fabrice Gasnier [Thu, 23 Apr 2020 11:55:53 +0000 (13:55 +0200)]
usb: dwc2: gadget: move gadget resume after the core is in L0 state
[ Upstream commit
8c935deacebb8fac8f41378701eb79d12f3c2e2d ]
When the remote wakeup interrupt is triggered, lx_state is resumed from L2
to L0 state. But when the gadget resume is called, lx_state is still L2.
This prevents the resume callback to queue any request. Any attempt
to queue a request from resume callback will result in:
- "submit request only in active state" debug message to be issued
- dwc2_hsotg_ep_queue() returns -EAGAIN
Call the gadget resume routine after the core is in L0 state.
Fixes:
f81f46e1f530 ("usb: dwc2: implement hibernation during bus suspend/resume")
Acked-by: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stefan Riedmueller [Fri, 3 Apr 2020 13:07:28 +0000 (15:07 +0200)]
watchdog: da9062: No need to ping manually before setting timeout
[ Upstream commit
a0948ddba65f4f6d3cfb5e2b84685485d0452966 ]
There is actually no need to ping the watchdog before disabling it
during timeout change. Disabling the watchdog already takes care of
resetting the counter.
This fixes an issue during boot when the userspace watchdog handler takes
over and the watchdog is already running. Opening the watchdog in this case
leads to the first ping and directly after that without the required
heartbeat delay a second ping issued by the set_timeout call. Due to the
missing delay this resulted in a reset.
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20200403130728.39260-3-s.riedmueller@phytec.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maor Gottlieb [Thu, 21 May 2020 07:26:50 +0000 (10:26 +0300)]
IB/cma: Fix ports memory leak in cma_configfs
[ Upstream commit
63a3345c2d42a9b29e1ce2d3a4043689b3995cea ]
The allocated ports structure in never freed. The free function should be
called by release_cma_ports_group, but the group is never released since
we don't remove its default group.
Remove default groups when device group is deleted.
Fixes:
045959db65c6 ("IB/cma: Add configfs for rdma_cm")
Link: https://lore.kernel.org/r/20200521072650.567908-1-leon@kernel.org
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bjorn Helgaas [Thu, 21 May 2020 20:40:07 +0000 (15:40 -0500)]
PCI/PTM: Inherit Switch Downstream Port PTM settings from Upstream Port
[ Upstream commit
7b38fd9760f51cc83d80eed2cfbde8b5ead9e93a ]
Except for Endpoints, we enable PTM at enumeration-time. Previously we did
not account for the fact that Switch Downstream Ports are not permitted to
have a PTM capability; their PTM behavior is controlled by the Upstream
Port (PCIe r5.0, sec 7.9.16). Since Downstream Ports don't have a PTM
capability, we did not mark them as "ptm_enabled", which meant that
pci_enable_ptm() on an Endpoint failed because there was no PTM path to it.
Mark Downstream Ports as "ptm_enabled" if their Upstream Port has PTM
enabled.
Fixes:
eec097d43100 ("PCI: Add pci_enable_ptm() for drivers to enable PTM on endpoints")
Reported-by: Aditya Paluri <Venkata.AdityaPaluri@synopsys.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qian Cai [Fri, 6 Mar 2020 04:48:52 +0000 (23:48 -0500)]
powerpc/64s/pgtable: fix an undefined behaviour
[ Upstream commit
c2e929b18cea6cbf71364f22d742d9aad7f4677a ]
Booting a power9 server with hash MMU could trigger an undefined
behaviour because pud_offset(p4d, 0) will do,
0 >> (PAGE_SHIFT:16 + PTE_INDEX_SIZE:8 + H_PMD_INDEX_SIZE:10)
Fix it by converting pud_index() and friends to static inline
functions.
UBSAN: shift-out-of-bounds in arch/powerpc/mm/ptdump/ptdump.c:282:15
shift exponent 34 is too large for 32-bit type 'int'
CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc4-next-
20200303+ #13
Call Trace:
dump_stack+0xf4/0x164 (unreliable)
ubsan_epilogue+0x18/0x78
__ubsan_handle_shift_out_of_bounds+0x160/0x21c
walk_pagetables+0x2cc/0x700
walk_pud at arch/powerpc/mm/ptdump/ptdump.c:282
(inlined by) walk_pagetables at arch/powerpc/mm/ptdump/ptdump.c:311
ptdump_check_wx+0x8c/0xf0
mark_rodata_ro+0x48/0x80
kernel_init+0x74/0x194
ret_from_kernel_thread+0x5c/0x74
Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Link: https://lore.kernel.org/r/20200306044852.3236-1-cai@lca.pw
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marek Szyprowski [Tue, 19 May 2020 10:26:52 +0000 (12:26 +0200)]
clk: samsung: exynos5433: Add IGNORE_UNUSED flag to sclk_i2s1
[ Upstream commit
25bdae0f1c6609ceaf55fe6700654f0be2253d8e ]
Mark the SCLK clock for Exynos5433 I2S1 device with IGNORE_UNUSED flag to
match its behaviour with SCLK clock for AUD_I2S (I2S0) device until
a proper fix for Exynos I2S driver is ready.
This fixes the following synchronous abort issue revealed by the probe
order change caused by the commit
93d2e4322aa7 ("of: platform: Batch
fwnode parsing when adding all top level devices")
Internal error: synchronous external abort:
96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 50 Comm: kworker/0:1 Not tainted 5.7.0-rc5+ #701
Hardware name: Samsung TM2E board (DT)
Workqueue: events deferred_probe_work_func
pstate:
60000005 (nZCv daif -PAN -UAO)
pc : samsung_i2s_probe+0x768/0x8f0
lr : samsung_i2s_probe+0x688/0x8f0
...
Call trace:
samsung_i2s_probe+0x768/0x8f0
platform_drv_probe+0x50/0xa8
really_probe+0x108/0x370
driver_probe_device+0x54/0xb8
__device_attach_driver+0x90/0xc0
bus_for_each_drv+0x70/0xc8
__device_attach+0xdc/0x140
device_initial_probe+0x10/0x18
bus_probe_device+0x94/0xa0
deferred_probe_work_func+0x70/0xa8
process_one_work+0x2a8/0x718
worker_thread+0x48/0x470
kthread+0x134/0x160
ret_from_fork+0x10/0x1c
Code:
17ffffaf d503201f f94086c0 91003000 (
88dffc00)
---[ end trace
ccf721c9400ddbd6 ]---
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gregory CLEMENT [Mon, 18 May 2020 08:45:13 +0000 (10:45 +0200)]
tty: n_gsm: Fix bogus i++ in gsm_data_kick
[ Upstream commit
4dd31f1ffec6c370c3c2e0c605628bf5e16d5c46 ]
When submitting the previous fix "tty: n_gsm: Fix waking up upper tty
layer when room available". It was suggested to switch from a while to
a for loop, but when doing it, there was a remaining bogus i++.
This patch removes this i++ and also reorganizes the code making it more
compact.
Fixes:
e1eaea46bb40 ("tty: n_gsm line discipline")
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20200518084517.2173242-3-gregory.clement@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tang Bin [Wed, 13 May 2020 13:26:47 +0000 (21:26 +0800)]
USB: host: ehci-mxc: Add error handling in ehci_mxc_drv_probe()
[ Upstream commit
d49292025f79693d3348f8e2029a8b4703be0f0a ]
The function ehci_mxc_drv_probe() does not perform sufficient error
checking after executing platform_get_irq(), thus fix it.
Fixes:
7e8d5cd93fac ("USB: Add EHCI support for MX27 and MX31 based boards")
Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
Reviewed-by: Peter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20200513132647.5456-1-tangbin@cmss.chinamobile.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Roy Spliet [Tue, 7 Apr 2020 17:07:37 +0000 (18:07 +0100)]
drm/msm/mdp5: Fix mdp5_init error path for failed mdp5_kms allocation
[ Upstream commit
e4337877c5d578722c0716f131fb774522013cf5 ]
When allocation for mdp5_kms fails, calling mdp5_destroy() leads to undefined
behaviour, likely a nullptr exception or use-after-free troubles.
Signed-off-by: Roy Spliet <nouveau@spliet.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qais Yousef [Mon, 18 May 2020 15:49:29 +0000 (16:49 +0100)]
usb/ohci-platform: Fix a warning when hibernating
[ Upstream commit
1cb3b0095c3d0bb96912bfbbce4fc006d41f367c ]
The following warning was observed when attempting to suspend to disk
using a USB flash as a swap device.
[ 111.779649] ------------[ cut here ]------------
[ 111.788382] URB (____ptrval____) submitted while active
[ 111.796646] WARNING: CPU: 3 PID: 365 at drivers/usb/core/urb.c:363 usb_submit_urb+0x3d8/0x590
[ 111.805417] Modules linked in:
[ 111.808584] CPU: 3 PID: 365 Comm: kworker/3:2 Not tainted 5.6.0-rc6-00002-gdfd1731f9a3e-dirty #545
[ 111.817796] Hardware name: ARM Juno development board (r2) (DT)
[ 111.823896] Workqueue: usb_hub_wq hub_event
[ 111.828217] pstate:
60000005 (nZCv daif -PAN -UAO)
[ 111.833156] pc : usb_submit_urb+0x3d8/0x590
[ 111.837471] lr : usb_submit_urb+0x3d8/0x590
[ 111.841783] sp :
ffff800018de38b0
[ 111.845205] x29:
ffff800018de38b0 x28:
0000000000000003
[ 111.850682] x27:
ffff000970530b20 x26:
ffff8000133fd000
[ 111.856159] x25:
ffff8000133fd000 x24:
ffff800018de3b38
[ 111.861635] x23:
0000000000000004 x22:
0000000000000c00
[ 111.867112] x21:
0000000000000000 x20:
00000000fffffff0
[ 111.872589] x19:
ffff0009704e7a00 x18:
ffffffffffffffff
[ 111.878065] x17:
00000000a7c8f4bc x16:
000000002af33de8
[ 111.883542] x15:
ffff8000133fda88 x14:
0720072007200720
[ 111.889019] x13:
0720072007200720 x12:
0720072007200720
[ 111.894496] x11:
0000000000000000 x10:
00000000a5286134
[ 111.899973] x9 :
0000000000000002 x8 :
ffff000970c837a0
[ 111.905449] x7 :
0000000000000000 x6 :
ffff800018de3570
[ 111.910926] x5 :
0000000000000001 x4 :
0000000000000003
[ 111.916401] x3 :
0000000000000000 x2 :
ffff800013427118
[ 111.921879] x1 :
9d4e965b4b7d7c00 x0 :
0000000000000000
[ 111.927356] Call trace:
[ 111.929892] usb_submit_urb+0x3d8/0x590
[ 111.933852] hub_activate+0x108/0x7f0
[ 111.937633] hub_resume+0xac/0x148
[ 111.941149] usb_resume_interface.isra.10+0x60/0x138
[ 111.946265] usb_resume_both+0xe4/0x140
[ 111.950225] usb_runtime_resume+0x24/0x30
[ 111.954365] __rpm_callback+0xdc/0x138
[ 111.958236] rpm_callback+0x34/0x98
[ 111.961841] rpm_resume+0x4a8/0x720
[ 111.965445] rpm_resume+0x50c/0x720
[ 111.969049] __pm_runtime_resume+0x4c/0xb8
[ 111.973276] usb_autopm_get_interface+0x28/0x60
[ 111.977948] hub_event+0x80/0x16d8
[ 111.981466] process_one_work+0x2a4/0x748
[ 111.985604] worker_thread+0x48/0x498
[ 111.989387] kthread+0x13c/0x140
[ 111.992725] ret_from_fork+0x10/0x18
[ 111.996415] irq event stamp: 354
[ 111.999756] hardirqs last enabled at (353): [<
ffff80001019ea1c>] console_unlock+0x504/0x5b8
[ 112.008441] hardirqs last disabled at (354): [<
ffff8000100a95d0>] do_debug_exception+0x1a8/0x258
[ 112.017479] softirqs last enabled at (350): [<
ffff8000100818a4>] __do_softirq+0x4bc/0x568
[ 112.025984] softirqs last disabled at (343): [<
ffff8000101145a4>] irq_exit+0x144/0x150
[ 112.034129] ---[ end trace
dc96030b9cf6c8a3 ]---
The problem was tracked down to a missing call to
pm_runtime_set_active() on resume in ohci-platform.
Link: https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
CC: Tony Prisk <linux@prisktech.co.nz>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Mathias Nyman <mathias.nyman@intel.com>
CC: Oliver Neukum <oneukum@suse.de>
CC: linux-arm-kernel@lists.infradead.org
CC: linux-usb@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20200518154931.6144-1-qais.yousef@arm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alex Williamson [Wed, 8 Apr 2020 17:45:28 +0000 (11:45 -0600)]
vfio-pci: Mask cap zero
[ Upstream commit
bc138db1b96264b9c1779cf18d5a3b186aa90066 ]
The PCI Code and ID Assignment Specification changed capability ID 0
from reserved to a NULL capability in the v1.1 revision. The NULL
capability is defined to include only the 16-bit capability header,
ie. only the ID and next pointer. Unfortunately vfio-pci creates a
map of config space, where ID 0 is used to reserve the standard type
0 header. Finding an actual capability with this ID therefore results
in a bogus range marked in that map and conflicts with subsequent
capabilities. As this seems to be a dummy capability anyway and we
already support dropping capabilities, let's hide this one rather than
delving into the potentially subtle dependencies within our map.
Seen on an NVIDIA Tesla T4.
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Geoff Levand [Sat, 9 May 2020 18:58:32 +0000 (18:58 +0000)]
powerpc/ps3: Fix kexec shutdown hang
[ Upstream commit
126554465d93b10662742128918a5fc338cda4aa ]
The ps3_mm_region_destroy() and ps3_mm_vas_destroy() routines
are called very late in the shutdown via kexec's mmu_cleanup_all
routine. By the time mmu_cleanup_all runs it is too late to use
udbg_printf, and calling it will cause PS3 systems to hang.
Remove all debugging statements from ps3_mm_region_destroy() and
ps3_mm_vas_destroy() and replace any error reporting with calls
to lv1_panic.
With this change builds with 'DEBUG' defined will not cause kexec
reboots to hang, and builds with 'DEBUG' defined or not will end
in lv1_panic if an error is encountered.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/7325c4af2b4c989c19d6a26b90b1fec9c0615ddf.1589049250.git.geoff@infradead.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nicholas Piggin [Fri, 8 May 2020 04:33:58 +0000 (14:33 +1000)]
powerpc/pseries/ras: Fix FWNMI_VALID off by one
[ Upstream commit
deb70f7a35a22dffa55b2c3aac71bc6fb0f486ce ]
This was discovered developing qemu fwnmi sreset support. This
off-by-one bug means the last 16 bytes of the rtas area can not
be used for a 16 byte save area.
It's not a serious bug, and QEMU implementation has to retain a
workaround for old kernels, but it's good to tighten it.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Link: https://lore.kernel.org/r/20200508043408.886394-7-npiggin@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gregory CLEMENT [Tue, 12 May 2020 11:53:23 +0000 (13:53 +0200)]
tty: n_gsm: Fix waking up upper tty layer when room available
[ Upstream commit
01dbb362f0a114fbce19c8abe4cd6f4710e934d5 ]
Warn the upper layer when n_gms is ready to receive data
again. Without this the associated virtual tty remains blocked
indefinitely.
Fixes:
e1eaea46bb40 ("tty: n_gsm line discipline")
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20200512115323.1447922-4-gregory.clement@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gregory CLEMENT [Tue, 12 May 2020 11:53:22 +0000 (13:53 +0200)]
tty: n_gsm: Fix SOF skipping
[ Upstream commit
84d6f81c1fb58b56eba81ff0a36cf31946064b40 ]
For at least some modems like the TELIT LE910, skipping SOF makes
transfers blocking indefinitely after a short amount of data
transferred.
Given the small improvement provided by skipping the SOF (just one
byte on about 100 bytes), it seems better to completely remove this
"feature" than make it optional.
Fixes:
e1eaea46bb40 ("tty: n_gsm line discipline")
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20200512115323.1447922-3-gregory.clement@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tero Kristo [Wed, 29 Apr 2020 13:13:39 +0000 (16:13 +0300)]
clk: ti: composite: fix memory leak
[ Upstream commit
c7c1cbbc9217ebb5601b88d138d4a5358548de9d ]
The parent_names is never released for a component clock definition,
causing some memory leak. Fix by releasing it once it is no longer
needed.
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Link: https://lkml.kernel.org/r/20200429131341.4697-2-t-kristo@ti.com
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Thu, 7 May 2020 21:34:28 +0000 (23:34 +0200)]
dlm: remove BUG() before panic()
[ Upstream commit
fe204591cc9480347af7d2d6029b24a62e449486 ]
Building a kernel with clang sometimes fails with an objtool error in dlm:
fs/dlm/lock.o: warning: objtool: revert_lock_pc()+0xbd: can't find jump dest instruction at .text+0xd7fc
The problem is that BUG() never returns and the compiler knows
that anything after it is unreachable, however the panic still
emits some code that does not get fully eliminated.
Having both BUG() and panic() is really pointless as the BUG()
kills the current process and the subsequent panic() never hits.
In most cases, we probably don't really want either and should
replace the DLM_ASSERT() statements with WARN_ON(), as has
been done for some of them.
Remove the BUG() here so the user at least sees the panic message
and we can reliably build randconfig kernels.
Fixes:
e7fd41792fc0 ("[DLM] The core of the DLM for GFS2/CLVM")
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: clang-built-linux@googlegroups.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Suganath Prabu S [Fri, 8 May 2020 11:07:38 +0000 (07:07 -0400)]
scsi: mpt3sas: Fix double free warnings
[ Upstream commit
cbbfdb2a2416c9f0cde913cf09670097ac281282 ]
Fix following warning from Smatch static analyser:
drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools()
warn: 'ioc->hpr_lookup' double freed
drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools()
warn: 'ioc->internal_lookup' double freed
Link: https://lore.kernel.org/r/20200508110738.30732-1-suganath-prabu.subramani@broadcom.com
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dmitry Osipenko [Sun, 29 Mar 2020 16:15:44 +0000 (18:15 +0200)]
power: supply: smb347-charger: IRQSTAT_D is volatile
[ Upstream commit
c32ea07a30630ace950e07ffe7a18bdcc25898e1 ]
Fix failure when USB cable is connected:
smb347 2-006a: reading IRQSTAT_D failed
Fixes:
1502cfe19bac ("smb347-charger: Fix battery status reporting logic for charger faults")
Tested-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Sat, 9 May 2020 08:23:23 +0000 (10:23 +0200)]
power: supply: lp8788: Fix an error handling path in 'lp8788_charger_probe()'
[ Upstream commit
934ed3847a4ebc75b655659c4d2349ba4337941c ]
In the probe function, in case of error, resources allocated in
'lp8788_setup_adc_channel()' must be released.
This can be achieved easily by using the devm_ variant of
'iio_channel_get()'.
This has the extra benefit to simplify the remove function and to axe the
'lp8788_release_adc_channel()' function which is now useless.
Fixes:
98a276649358 ("power_supply: Add new lp8788 charger driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kai-Heng Feng [Tue, 5 May 2020 17:34:21 +0000 (01:34 +0800)]
PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X Bridges
[ Upstream commit
66ff14e59e8a30690755b08bc3042359703fb07a ]
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for
Linux to enable ASPM, but for some undocumented reason, it didn't enable
ASPM on links where the downstream component is a PCIe-to-PCI/PCI-X Bridge.
Remove this exclusion so we can enable ASPM on these links.
The Dell OptiPlex 7080 mentioned in the bugzilla has a TI XIO2001
PCIe-to-PCI Bridge. Enabling ASPM on the link leading to it allows the
Intel SoC to enter deeper Package C-states, which is a significant power
savings.
[bhelgaas: commit log]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207571
Link: https://lore.kernel.org/r/20200505173423.26968-1-kai.heng.feng@canonical.com
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrew Murray [Fri, 4 Oct 2019 13:29:41 +0000 (14:29 +0100)]
PCI: rcar: Fix incorrect programming of OB windows
[ Upstream commit
2b9f217433e31d125fb697ca7974d3de3ecc3e92 ]
The outbound windows (PCIEPAUR(x), PCIEPALR(x)) describe a mapping between
a CPU address (which is determined by the window number 'x') and a
programmed PCI address - Thus allowing the controller to translate CPU
accesses into PCI accesses.
However the existing code incorrectly writes the CPU address - lets fix
this by writing the PCI address instead.
For memory transactions, existing DT users describe a 1:1 identity mapping
and thus this change should have no effect. However the same isn't true for
I/O.
Link: https://lore.kernel.org/r/20191004132941.6660-1-andrew.murray@arm.com
Fixes:
c25da4778803 ("PCI: rcar: Add Renesas R-Car PCIe driver")
Tested-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kuppuswamy Sathyanarayanan [Wed, 8 Apr 2020 21:40:03 +0000 (14:40 -0700)]
drivers: base: Fix NULL pointer exception in __platform_driver_probe() if a driver developer is foolish
[ Upstream commit
388bcc6ecc609fca1b4920de7dc3806c98ec535e ]
If platform bus driver registration is failed then, accessing
platform bus spin lock (&drv->driver.bus->p->klist_drivers.k_lock)
in __platform_driver_probe() without verifying the return value
__platform_driver_register() can lead to NULL pointer exception.
So check the return value before attempting the spin lock.
One such example is below:
For a custom usecase, I have intentionally failed the platform bus
registration and I expected all the platform device/driver
registrations to fail gracefully. But I came across this panic
issue.
[ 1.331067] BUG: kernel NULL pointer dereference, address:
00000000000000c8
[ 1.331118] #PF: supervisor write access in kernel mode
[ 1.331163] #PF: error_code(0x0002) - not-present page
[ 1.331208] PGD 0 P4D 0
[ 1.331233] Oops: 0002 [#1] PREEMPT SMP
[ 1.331268] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 5.6.0-00049-g670d35fb0144 #165
[ 1.331341] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
[ 1.331406] RIP: 0010:_raw_spin_lock+0x15/0x30
[ 1.331588] RSP: 0000:
ffffc9000001be70 EFLAGS:
00010246
[ 1.331632] RAX:
0000000000000000 RBX:
00000000000000c8 RCX:
0000000000000001
[ 1.331696] RDX:
0000000000000001 RSI:
0000000000000092 RDI:
0000000000000000
[ 1.331754] RBP:
00000000ffffffed R08:
0000000000000501 R09:
0000000000000001
[ 1.331817] R10:
ffff88817abcc520 R11:
0000000000000670 R12:
00000000ffffffed
[ 1.331881] R13:
ffffffff82dbc268 R14:
ffffffff832f070a R15:
0000000000000000
[ 1.331945] FS:
0000000000000000(0000) GS:
ffff88817bd80000(0000) knlGS:
0000000000000000
[ 1.332008] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 1.332062] CR2:
00000000000000c8 CR3:
000000000681e001 CR4:
00000000003606e0
[ 1.332126] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 1.332189] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 1.332252] Call Trace:
[ 1.332281] __platform_driver_probe+0x92/0xee
[ 1.332323] ? rtc_dev_init+0x2b/0x2b
[ 1.332358] cmos_init+0x37/0x67
[ 1.332396] do_one_initcall+0x7d/0x168
[ 1.332428] kernel_init_freeable+0x16c/0x1c9
[ 1.332473] ? rest_init+0xc0/0xc0
[ 1.332508] kernel_init+0x5/0x100
[ 1.332543] ret_from_fork+0x1f/0x30
[ 1.332579] CR2:
00000000000000c8
[ 1.332616] ---[ end trace
3bd87f12e9010b87 ]---
[ 1.333549] note: swapper/0[1] exited with preempt_count 1
[ 1.333592] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[ 1.333736] Kernel Offset: disabled
Note, this can only be triggered if a driver errors out from this call,
which should never happen. If it does, the driver needs to be fixed.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Link: https://lore.kernel.org/r/20200408214003.3356-1-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
John Stultz [Tue, 28 Apr 2020 18:40:50 +0000 (18:40 +0000)]
serial: amba-pl011: Make sure we initialize the port.lock spinlock
[ Upstream commit
8508f4cba308f785b2fd4b8c38849c117b407297 ]
Valentine reported seeing:
[ 3.626638] INFO: trying to register non-static key.
[ 3.626639] the code is fine but needs lockdep annotation.
[ 3.626640] turning off the locking correctness validator.
[ 3.626644] CPU: 7 PID: 51 Comm: kworker/7:1 Not tainted 5.7.0-rc2-00115-g8c2e9790f196 #116
[ 3.626646] Hardware name: HiKey960 (DT)
[ 3.626656] Workqueue: events deferred_probe_work_func
[ 3.632476] sd 0:0:0:0: [sda] Optimal transfer size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.640220] Call trace:
[ 3.640225] dump_backtrace+0x0/0x1b8
[ 3.640227] show_stack+0x20/0x30
[ 3.640230] dump_stack+0xec/0x158
[ 3.640234] register_lock_class+0x598/0x5c0
[ 3.640235] __lock_acquire+0x80/0x16c0
[ 3.640236] lock_acquire+0xf4/0x4a0
[ 3.640241] _raw_spin_lock_irqsave+0x70/0xa8
[ 3.640245] uart_add_one_port+0x388/0x4b8
[ 3.640248] pl011_register_port+0x70/0xf0
[ 3.640250] pl011_probe+0x184/0x1b8
[ 3.640254] amba_probe+0xdc/0x180
[ 3.640256] really_probe+0xe0/0x338
[ 3.640257] driver_probe_device+0x60/0xf8
[ 3.640259] __device_attach_driver+0x8c/0xd0
[ 3.640260] bus_for_each_drv+0x84/0xd8
[ 3.640261] __device_attach+0xe4/0x140
[ 3.640263] device_initial_probe+0x1c/0x28
[ 3.640265] bus_probe_device+0xa4/0xb0
[ 3.640266] deferred_probe_work_func+0x7c/0xb8
[ 3.640269] process_one_work+0x2c0/0x768
[ 3.640271] worker_thread+0x4c/0x498
[ 3.640272] kthread+0x14c/0x158
[ 3.640275] ret_from_fork+0x10/0x1c
Which seems to be due to the fact that after allocating the uap
structure, nothing initializes the spinlock.
Its a little confusing, as uart_port_spin_lock_init() is one
place where the lock is supposed to be initialized, but it has
an exception for the case where the port is a console.
This makes it seem like a deeper fix is needed to properly
register the console, but I'm not sure what that entails, and
Andy suggested that this approach is less invasive.
Thus, this patch resolves the issue by initializing the spinlock
in the driver, and resolves the resulting warning.
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-serial@vger.kernel.org
Reported-by: Valentin Schneider <valentin.schneider@arm.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Reviewed-and-tested-by: Valentin Schneider <valentin.schneider@arm.com>
Link: https://lore.kernel.org/r/20200428184050.6501-1-john.stultz@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Russell King [Mon, 27 Apr 2020 18:49:22 +0000 (19:49 +0100)]
i2c: pxa: fix i2c_pxa_scream_blue_murder() debug output
[ Upstream commit
88b73ee7ca4c90baf136ed5a8377fc5a9b73ac08 ]
The IRQ log output is supposed to appear on a single line. However,
commit
3a2dc1677b60 ("i2c: pxa: Update debug function to dump more info
on error") resulted in it being printed one-entry-per-line, which is
excessively long.
Fixing this is not a trivial matter; using pr_cont() doesn't work as
the previous dev_dbg() may not have been compiled in, or may be
dynamic.
Since the rest of this function output is at error level, and is also
debug output, promote this to error level as well to avoid this
problem.
Reduce the number of always zero prefix digits to save screen real-
estate.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Matej Dujava [Thu, 30 Apr 2020 20:09:24 +0000 (22:09 +0200)]
staging: sm750fb: add missing case while setting FB_VISUAL
[ Upstream commit
fa90133377f4a7f15a937df6ad55133bb57c5665 ]
Switch statement does not contain all cases: 8, 16, 24, 32.
This patch will add missing one (24)
Fixes:
81dee67e215b ("staging: sm750fb: add sm750 to staging")
Signed-off-by: Matej Dujava <mdujava@kocurkovo.cz>
Link: https://lore.kernel.org/r/1588277366-19354-2-git-send-email-mdujava@kocurkovo.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Raghavendra Rao Ananta [Tue, 28 Apr 2020 03:26:01 +0000 (20:26 -0700)]
tty: hvc: Fix data abort due to race in hvc_open
[ Upstream commit
e2bd1dcbe1aa34ff5570b3427c530e4332ecf0fe ]
Potentially, hvc_open() can be called in parallel when two tasks calls
open() on /dev/hvcX. In such a scenario, if the hp->ops->notifier_add()
callback in the function fails, where it sets the tty->driver_data to
NULL, the parallel hvc_open() can see this NULL and cause a memory abort.
Hence, serialize hvc_open and check if tty->private_data is NULL before
proceeding ahead.
The issue can be easily reproduced by launching two tasks simultaneously
that does nothing but open() and close() on /dev/hvcX.
For example:
$ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 &
Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
Link: https://lore.kernel.org/r/20200428032601.22127-1-rananta@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Julian Wiedmann [Thu, 9 Apr 2020 07:59:39 +0000 (09:59 +0200)]
s390/qdio: put thinint indicator after early error
[ Upstream commit
75e82bec6b2622c6f455b7a543fb5476a5d0eed7 ]
qdio_establish() calls qdio_setup_thinint() via qdio_setup_irq().
If the subsequent qdio_establish_thinint() fails, we miss to put the
DSCI again. Thus the DSCI isn't available for re-use. Given enough of
such errors, we could end up with having only the shared DSCI available.
Merge qdio_setup_thinint() into qdio_establish_thinint(), and deal with
such an error internally.
Fixes:
779e6e1c724d ("[S390] qdio: new qdio driver.")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alexander Tsoy [Fri, 24 Apr 2020 02:24:48 +0000 (05:24 +0300)]
ALSA: usb-audio: Improve frames size computation
[ Upstream commit
f0bd62b64016508938df9babe47f65c2c727d25c ]
For computation of the the next frame size current value of fs/fps and
accumulated fractional parts of fs/fps are used, where values are stored
in Q16.16 format. This is quite natural for computing frame size for
asynchronous endpoints driven by explicit feedback, since in this case
fs/fps is a value provided by the feedback endpoint and it's already in
the Q format. If an error is accumulated over time, the device can
adjust fs/fps value to prevent buffer overruns/underruns.
But for synchronous endpoints the accuracy provided by these computations
is not enough. Due to accumulated error the driver periodically produces
frames with incorrect size (+/- 1 audio sample).
This patch fixes this issue by implementing a different algorithm for
frame size computation. It is based on accumulating of the remainders
from division fs/fps and it doesn't accumulate errors over time. This
new method is enabled for synchronous and adaptive playback endpoints.
Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Link: https://lore.kernel.org/r/20200424022449.14972-1-alexander@tsoy.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tyrel Datwyler [Wed, 3 Jun 2020 20:36:32 +0000 (15:36 -0500)]
scsi: ibmvscsi: Don't send host info in adapter info MAD after LPM
[ Upstream commit
4919b33b63c8b69d8dcf2b867431d0e3b6dc6d28 ]
The adapter info MAD is used to send the client info and receive the host
info as a response. A persistent buffer is used and as such the client info
is overwritten after the response. During the course of a normal adapter
reset the client info is refreshed in the buffer in preparation for sending
the adapter info MAD.
However, in the special case of LPM where we reenable the CRQ instead of a
full CRQ teardown and reset we fail to refresh the client info in the
adapter info buffer. As a result, after Live Partition Migration (LPM) we
erroneously report the host's info as our own.
[mkp: typos]
Link: https://lore.kernel.org/r/20200603203632.18426-1-tyreld@linux.ibm.com
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Simon Arlott [Sat, 30 May 2020 17:59:44 +0000 (18:59 +0100)]
scsi: sr: Fix sr_probe() missing deallocate of device minor
[ Upstream commit
6555781b3fdec5e94e6914511496144241df7dee ]
If the cdrom fails to be registered then the device minor should be
deallocated.
Link: https://lore.kernel.org/r/072dac4b-8402-4de8-36bd-47e7588969cd@0882a8b5-c6c3-11e9-b005-00805fc181fe
Signed-off-by: Simon Arlott <simon@octiron.net>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ashimida [Tue, 2 Jun 2020 07:45:17 +0000 (15:45 +0800)]
mksysmap: Fix the mismatch of '.L' symbols in System.map
[ Upstream commit
72d24accf02add25e08733f0ecc93cf10fcbd88c ]
When System.map was generated, the kernel used mksysmap to
filter the kernel symbols, but all the symbols with the
second letter 'L' in the kernel were filtered out, not just
the symbols starting with 'dot + L'.
For example:
ashimida@ubuntu:~/linux$ cat System.map |grep ' .L'
ashimida@ubuntu:~/linux$ nm -n vmlinux |grep ' .L'
ffff0000088028e0 t bLength_show
......
ffff0000092e0408 b PLLP_OUTC_lock
ffff0000092e0410 b PLLP_OUTA_lock
The original intent should be to filter out all local symbols
starting with '.L', so the dot should be escaped.
Fixes:
00902e984732 ("mksysmap: Add h8300 local symbol pattern")
Signed-off-by: ashimida <ashimida@linux.alibaba.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang Hai [Thu, 4 Jun 2020 12:18:51 +0000 (20:18 +0800)]
yam: fix possible memory leak in yam_init_driver
[ Upstream commit
98749b7188affbf2900c2aab704a8853901d1139 ]
If register_netdev(dev) fails, free_netdev(dev) needs
to be called, otherwise a memory leak will occur.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pingfan Liu [Wed, 1 Apr 2020 14:00:44 +0000 (22:00 +0800)]
powerpc/crashkernel: Take "mem=" option into account
[ Upstream commit
be5470e0c285a68dc3afdea965032f5ddc8269d7 ]
'mem=" option is an easy way to put high pressure on memory during
some test. Hence after applying the memory limit, instead of total
mem, the actual usable memory should be considered when reserving mem
for crashkernel. Otherwise the boot up may experience OOM issue.
E.g. it would reserve 4G prior to the change and 512M afterward, if
passing
crashkernel="2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G",
and mem=5G on a 256G machine.
This issue is powerpc specific because it puts higher priority on
fadump and kdump reservation than on "mem=". Referring the following
code:
if (fadump_reserve_mem() == 0)
reserve_crashkernel();
...
/* Ensure that total memory size is page-aligned. */
limit = ALIGN(memory_limit ?: memblock_phys_mem_size(), PAGE_SIZE);
memblock_enforce_memory_limit(limit);
While on other arches, the effect of "mem=" takes a higher priority
and pass through memblock_phys_mem_size() before calling
reserve_crashkernel().
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Reviewed-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1585749644-4148-1-git-send-email-kernelfans@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiyu Yang [Mon, 25 May 2020 14:15:41 +0000 (22:15 +0800)]
nfsd: Fix svc_xprt refcnt leak when setup callback client failed
[ Upstream commit
a4abc6b12eb1f7a533c2e7484cfa555454ff0977 ]
nfsd4_process_cb_update() invokes svc_xprt_get(), which increases the
refcount of the "c->cn_xprt".
The reference counting issue happens in one exception handling path of
nfsd4_process_cb_update(). When setup callback client failed, the
function forgets to decrease the refcnt increased by svc_xprt_get(),
causing a refcnt leak.
Fix this issue by calling svc_xprt_put() when setup callback client
failed.
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kajol Jain [Mon, 25 May 2020 10:43:03 +0000 (16:13 +0530)]
powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run
[ Upstream commit
b4ac18eead28611ff470d0f47a35c4e0ac080d9c ]
Commit
2b206ee6b0df ("powerpc/perf/hv-24x7: Display change in counter
values")' added to print _change_ in the counter value rather then raw
value for 24x7 counters. Incase of transactions, the event count
is set to 0 at the beginning of the transaction. It also sets
the event's prev_count to the raw value at the time of initialization.
Because of setting event count to 0, we are seeing some weird behaviour,
whenever we run multiple 24x7 events at a time.
For example:
command#: ./perf stat -e "{hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/,
hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/}"
-C 0 -I 1000 sleep 100
1.
000121704 120 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
1.
000121704 5 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
2.
000357733 8 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
2.
000357733 10 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
3.
000495215 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
3.
000495215 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
4.
000641884 56 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
4.
000641884 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
5.
000791887 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
Getting these large values in case we do -I.
As we are setting event_count to 0, for interval case, overall event_count is not
coming in incremental order. As we may can get new delta lesser then previous count.
Because of which when we print intervals, we are getting negative value which create
these large values.
This patch removes part where we set event_count to 0 in function
'h_24x7_event_read'. There won't be much impact as we do set event->hw.prev_count
to the raw value at the time of initialization to print change value.
With this patch
In power9 platform
command#: ./perf stat -e "{hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/,
hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/}"
-C 0 -I 1000 sleep 100
1.
000117685 93 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
1.
000117685 1 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
2.
000349331 98 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
2.
000349331 2 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
3.
000495900 131 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
3.
000495900 4 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
4.
000645920 204 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
4.
000645920 61 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
4.
284169997 22 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
Suggested-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
Tested-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200525104308.9814-2-kjain@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alain Volmat [Sun, 22 Mar 2020 14:07:40 +0000 (15:07 +0100)]
clk: clk-flexgen: fix clock-critical handling
[ Upstream commit
a403bbab1a73d798728d76931cab3ff0399b9560 ]
Fixes an issue leading to having all clocks following a critical
clocks marked as well as criticals.
Fixes:
fa6415affe20 ("clk: st: clk-flexgen: Detect critical clocks")
Signed-off-by: Alain Volmat <avolmat@me.com>
Link: https://lkml.kernel.org/r/20200322140740.3970-1-avolmat@me.com
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiyu Yang [Mon, 25 May 2020 14:16:24 +0000 (22:16 +0800)]
scsi: lpfc: Fix lpfc_nodelist leak when processing unsolicited event
[ Upstream commit
7217e6e694da3aae6d17db8a7f7460c8d4817ebf ]
In order to create or activate a new node, lpfc_els_unsol_buffer() invokes
lpfc_nlp_init() or lpfc_enable_node() or lpfc_nlp_get(), all of them will
return a reference of the specified lpfc_nodelist object to "ndlp" with
increased refcnt.
When lpfc_els_unsol_buffer() returns, local variable "ndlp" becomes
invalid, so the refcount should be decreased to keep refcount balanced.
The reference counting issue happens in one exception handling path of
lpfc_els_unsol_buffer(). When "ndlp" in DEV_LOSS, the function forgets to
decrease the refcnt increased by lpfc_nlp_init() or lpfc_enable_node() or
lpfc_nlp_get(), causing a refcnt leak.
Fix this issue by calling lpfc_nlp_put() when "ndlp" in DEV_LOSS.
Link: https://lore.kernel.org/r/1590416184-52592-1-git-send-email-xiyuyang19@fudan.edu.cn
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: James Smart <james.smart@broadcom.com>
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marek Szyprowski [Mon, 27 Apr 2020 07:48:29 +0000 (09:48 +0200)]
mfd: wm8994: Fix driver operation if loaded as modules
[ Upstream commit
d4f9b5428b53dd67f49ee8deed8d4366ed6b1933 ]
WM8994 chip has built-in regulators, which might be used for chip
operation. They are controlled by a separate wm8994-regulator driver,
which should be loaded before this driver calls regulator_get(), because
that driver also provides consumer-supply mapping for the them. If that
driver is not yet loaded, regulator core substitute them with dummy
regulator, what breaks chip operation, because the built-in regulators are
never enabled. Fix this by annotating this driver with MODULE_SOFTDEP()
"pre" dependency to "wm8994_regulator" module.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qian Cai [Sun, 10 May 2020 16:16:56 +0000 (12:16 -0400)]
vfio/pci: fix memory leaks in alloc_perm_bits()
[ Upstream commit
3e63b94b6274324ff2e7d8615df31586de827c4e ]
vfio_pci_disable() calls vfio_config_free() but forgets to call
free_perm_bits() resulting in memory leaks,
unreferenced object 0xc000000c4db2dee0 (size 16):
comm "qemu-kvm", pid 4305, jiffies
4295020272 (age 3463.780s)
hex dump (first 16 bytes):
00 00 ff 00 ff ff ff ff ff ff ff ff ff ff 00 00 ................
backtrace:
[<
00000000a6a4552d>] alloc_perm_bits+0x58/0xe0 [vfio_pci]
[<
00000000ac990549>] vfio_config_init+0xdf0/0x11b0 [vfio_pci]
init_pci_cap_msi_perm at drivers/vfio/pci/vfio_pci_config.c:1125
(inlined by) vfio_msi_cap_len at drivers/vfio/pci/vfio_pci_config.c:1180
(inlined by) vfio_cap_len at drivers/vfio/pci/vfio_pci_config.c:1241
(inlined by) vfio_cap_init at drivers/vfio/pci/vfio_pci_config.c:1468
(inlined by) vfio_config_init at drivers/vfio/pci/vfio_pci_config.c:1707
[<
000000006db873a1>] vfio_pci_open+0x234/0x700 [vfio_pci]
[<
00000000630e1906>] vfio_group_fops_unl_ioctl+0x8e0/0xb84 [vfio]
[<
000000009e34c54f>] ksys_ioctl+0xd8/0x130
[<
000000006577923d>] sys_ioctl+0x28/0x40
[<
000000006d7b1cf2>] system_call_exception+0x114/0x1e0
[<
0000000008ea7dd5>] system_call_common+0xf0/0x278
unreferenced object 0xc000000c4db2e330 (size 16):
comm "qemu-kvm", pid 4305, jiffies
4295020272 (age 3463.780s)
hex dump (first 16 bytes):
00 ff ff 00 ff ff ff ff ff ff ff ff ff ff 00 00 ................
backtrace:
[<
000000004c71914f>] alloc_perm_bits+0x44/0xe0 [vfio_pci]
[<
00000000ac990549>] vfio_config_init+0xdf0/0x11b0 [vfio_pci]
[<
000000006db873a1>] vfio_pci_open+0x234/0x700 [vfio_pci]
[<
00000000630e1906>] vfio_group_fops_unl_ioctl+0x8e0/0xb84 [vfio]
[<
000000009e34c54f>] ksys_ioctl+0xd8/0x130
[<
000000006577923d>] sys_ioctl+0x28/0x40
[<
000000006d7b1cf2>] system_call_exception+0x114/0x1e0
[<
0000000008ea7dd5>] system_call_common+0xf0/0x278
Fixes:
89e1f7d4c66d ("vfio: Add PCI device driver")
Signed-off-by: Qian Cai <cai@lca.pw>
[aw: rolled in follow-up patch]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Emmanuel Nicolet [Sat, 9 May 2020 18:58:32 +0000 (18:58 +0000)]
ps3disk: use the default segment boundary
[ Upstream commit
720bc316690bd27dea9d71510b50f0cd698ffc32 ]
Since commit
dcebd755926b ("block: use bio_for_each_bvec() to compute
multi-page bvec count"), the kernel will bug_on on the PS3 because
bio_split() is called with sectors == 0:
kernel BUG at block/bio.c:1853!
Oops: Exception in kernel mode, sig: 5 [#1]
BE PAGE_SIZE=4K MMU=Hash PREEMPT SMP NR_CPUS=8 NUMA PS3
Modules linked in: firewire_sbp2 rtc_ps3(+) soundcore ps3_gelic(+) \
ps3rom(+) firewire_core ps3vram(+) usb_common crc_itu_t
CPU: 0 PID: 97 Comm: blkid Not tainted 5.3.0-rc4 #1
NIP:
c00000000027d0d0 LR:
c00000000027d0b0 CTR:
0000000000000000
REGS:
c00000000135ae90 TRAP: 0700 Not tainted (5.3.0-rc4)
MSR:
8000000000028032 <SF,EE,IR,DR,RI> CR:
44008240 XER:
20000000
IRQMASK: 0
GPR00:
c000000000289368 c00000000135b120 c00000000084a500 c000000004ff8300
GPR04:
0000000000000c00 c000000004c905e0 c000000004c905e0 000000000000ffff
GPR08:
0000000000000000 0000000000000001 0000000000000000 000000000000ffff
GPR12:
0000000000000000 c0000000008ef000 000000000000003e 0000000000080001
GPR16:
0000000000000100 000000000000ffff 0000000000000000 0000000000000004
GPR20:
c00000000062fd7e 0000000000000001 000000000000ffff 0000000000000080
GPR24:
c000000000781788 c00000000135b350 0000000000000080 c000000004c905e0
GPR28:
c00000000135b348 c000000004ff8300 0000000000000000 c000000004c90000
NIP [
c00000000027d0d0] .bio_split+0x28/0xac
LR [
c00000000027d0b0] .bio_split+0x8/0xac
Call Trace:
[
c00000000135b120] [
c00000000027d130] .bio_split+0x88/0xac (unreliable)
[
c00000000135b1b0] [
c000000000289368] .__blk_queue_split+0x11c/0x53c
[
c00000000135b2d0] [
c00000000028f614] .blk_mq_make_request+0x80/0x7d4
[
c00000000135b3d0] [
c000000000283a8c] .generic_make_request+0x118/0x294
[
c00000000135b4b0] [
c000000000283d34] .submit_bio+0x12c/0x174
[
c00000000135b580] [
c000000000205a44] .mpage_bio_submit+0x3c/0x4c
[
c00000000135b600] [
c000000000206184] .mpage_readpages+0xa4/0x184
[
c00000000135b750] [
c0000000001ff8fc] .blkdev_readpages+0x24/0x38
[
c00000000135b7c0] [
c0000000001589f0] .read_pages+0x6c/0x1a8
[
c00000000135b8b0] [
c000000000158c74] .__do_page_cache_readahead+0x118/0x184
[
c00000000135b9b0] [
c0000000001591a8] .force_page_cache_readahead+0xe4/0xe8
[
c00000000135ba50] [
c00000000014fc24] .generic_file_read_iter+0x1d8/0x830
[
c00000000135bb50] [
c0000000001ffadc] .blkdev_read_iter+0x40/0x5c
[
c00000000135bbc0] [
c0000000001b9e00] .new_sync_read+0x144/0x1a0
[
c00000000135bcd0] [
c0000000001bc454] .vfs_read+0xa0/0x124
[
c00000000135bd70] [
c0000000001bc7a4] .ksys_read+0x70/0xd8
[
c00000000135be20] [
c00000000000a524] system_call+0x5c/0x70
Instruction dump:
7fe3fb78 482e30dc 7c0802a6 482e3085 7c9e2378 f821ff71 7ca42b78 7d3e00d0
7c7d1b78 79290fe0 7cc53378 69290001 <
0b090000>
81230028 7bca0020 7929ba62
[ end trace
313fec760f30aa1f ]---
The problem originates from setting the segment boundary of the
request queue to -1UL. This makes get_max_segment_size() return zero
when offset is zero, whatever the max segment size. The test with
BLK_SEG_BOUNDARY_MASK fails and 'mask - (mask & offset) + 1' overflows
to zero in the return statement.
Not setting the segment boundary and using the default
value (BLK_SEG_BOUNDARY_MASK) fixes the problem.
Signed-off-by: Emmanuel Nicolet <emmanuel.nicolet@gmail.com>
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/060a416c43138f45105c0540eff1a45539f7e2fc.1589049250.git.geoff@infradead.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pali Rohár [Thu, 30 Apr 2020 08:06:15 +0000 (10:06 +0200)]
PCI: aardvark: Don't blindly enable ASPM L0s and don't write to read-only register
[ Upstream commit
90c6cb4a355e7befcb557d217d1d8b8bd5875a05 ]
Trying to change Link Status register does not have any effect as this
is a read-only register. Trying to overwrite bits for Negotiated Link
Width does not make sense.
In future proper change of link width can be done via Lane Count Select
bits in PCIe Control 0 register.
Trying to unconditionally enable ASPM L0s via ASPM Control bits in Link
Control register is wrong. There should be at least some detection if
endpoint supports L0s as isn't mandatory.
Moreover ASPM Control bits in Link Control register are controlled by
pcie/aspm.c code which sets it according to system ASPM settings,
immediately after aardvark driver probes. So setting these bits by
aardvark driver has no long running effect.
Remove code which touches ASPM L0s bits from this driver and let
kernel's ASPM implementation to set ASPM state properly.
Some users are reporting issues that this code is problematic for some
Intel wifi cards and removing it fixes them, see e.g.:
https://bugzilla.kernel.org/show_bug.cgi?id=196339
If problems with Intel wifi cards occur even after this commit, then
pcie/aspm.c code could be modified / hooked to not enable ASPM L0s state
for affected problematic cards.
Link: https://lore.kernel.org/r/20200430080625.26070-3-pali@kernel.org
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Oliver Neukum [Thu, 7 May 2020 08:58:06 +0000 (10:58 +0200)]
usblp: poison URBs upon disconnect
[ Upstream commit
296a193b06120aa6ae7cf5c0d7b5e5b55968026e ]
syzkaller reported an URB that should have been killed to be active.
We do not understand it, but this should fix the issue if it is real.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Reported-by: syzbot+be5b5f86a162a6c281e6@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20200507085806.5793-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Russell King [Wed, 6 May 2020 09:36:38 +0000 (10:36 +0100)]
i2c: pxa: clear all master action bits in i2c_pxa_stop_message()
[ Upstream commit
e81c979f4e071d516aa27cf5a0c3939da00dc1ca ]
If we timeout during a message transfer, the control register may
contain bits that cause an action to be set. Read-modify-writing the
register leaving these bits set may trigger the hardware to attempt
one of these actions unintentionally.
Always clear these bits when cleaning up after a message or after
a timeout.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andreas Klinger [Mon, 4 May 2020 18:10:34 +0000 (20:10 +0200)]
iio: bmp280: fix compensation of humidity
[ Upstream commit
dee2dabc0e4115b80945fe2c91603e634f4b4686 ]
Limit the output of humidity compensation to the range between 0 and 100
percent.
Depending on the calibration parameters of the individual sensor it
happens, that a humidity above 100 percent or below 0 percent is
calculated, which don't make sense in terms of relative humidity.
Add a clamp to the compensation formula as described in the datasheet of
the sensor in chapter 4.2.3.
Although this clamp is documented, it was never in the driver of the
kernel.
It depends on the circumstances (calibration parameters, temperature,
humidity) if one can see a value above 100 percent without the clamp.
The writer of this patch was working with this type of sensor without
noting this error. So it seems to be a rare event when this bug occures.
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Viacheslav Dubeyko [Wed, 22 Apr 2020 10:55:52 +0000 (13:55 +0300)]
scsi: qla2xxx: Fix issue with adapter's stopping state
[ Upstream commit
803e45550b11c8e43d89812356fe6f105adebdf9 ]
The goal of the following command sequence is to restart the adapter.
However, the tgt_stop flag remains set, indicating that the adapter is
still in stopping state even after re-enabling it.
echo 0x7fffffff > /sys/module/qla2xxx/parameters/logging
modprobe target_core_mod
modprobe tcm_qla2xxx
mkdir /sys/kernel/config/target/qla2xxx
mkdir /sys/kernel/config/target/qla2xxx/<port-name>
mkdir /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1
echo 1 > /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1/enable
echo 0 > /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1/enable
echo 1 > /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1/enable
kernel: PID 1396:qla_target.c:1555 qlt_stop_phase1(): tgt_stop 0x0, tgt_stopped 0x0
kernel: qla2xxx [0001:00:02.0]-e803:1: PID 1396:qla_target.c:1567: Stopping target for host 1(
c0000000033557e8)
kernel: PID 1396:qla_target.c:1579 qlt_stop_phase1(): tgt_stop 0x1, tgt_stopped 0x0
kernel: PID 1396:qla_target.c:1266 qlt_schedule_sess_for_deletion(): tgt_stop 0x1, tgt_stopped 0x0
kernel: qla2xxx [0001:00:02.0]-e801:1: PID 1396:qla_target.c:1316: Scheduling sess
c00000002d5cd800 for deletion 21:00:00:24:ff:7f:35:c7
<skipped>
kernel: qla2xxx [0001:00:02.0]-290a:1: PID 340:qla_target.c:1187: qlt_unreg_sess sess
c00000002d5cd800 for deletion 21:00:00:24:ff:7f:35:c7
<skipped>
kernel: qla2xxx [0001:00:02.0]-f801:1: PID 340:qla_target.c:1145: Unregistration of sess
c00000002d5cd800 21:00:00:24:ff:7f:35:c7 finished fcp_cnt 0
kernel: PID 340:qla_target.c:1155 qlt_free_session_done(): tgt_stop 0x1, tgt_stopped 0x0
kernel: qla2xxx [0001:00:02.0]-4807:1: PID 346:qla_os.c:6329: ISP abort scheduled.
<skipped>
kernel: qla2xxx [0001:00:02.0]-28f1:1: PID 346:qla_os.c:3956: Mark all dev lost
kernel: PID 346:qla_target.c:1266 qlt_schedule_sess_for_deletion(): tgt_stop 0x1, tgt_stopped 0x0
kernel: qla2xxx [0001:00:02.0]-4808:1: PID 346:qla_os.c:6338: ISP abort end.
<skipped>
kernel: PID 1396:qla_target.c:6812 qlt_enable_vha(): tgt_stop 0x1, tgt_stopped 0x0
<skipped>
kernel: qla2xxx [0001:00:02.0]-4807:1: PID 346:qla_os.c:6329: ISP abort scheduled.
<skipped>
kernel: qla2xxx [0001:00:02.0]-4808:1: PID 346:qla_os.c:6338: ISP abort end.
qlt_handle_cmd_for_atio() rejects the request to send commands because the
adapter is in the stopping state:
kernel: PID 0:qla_target.c:4442 qlt_handle_cmd_for_atio(): tgt_stop 0x1, tgt_stopped 0x0
kernel: qla2xxx [0001:00:02.0]-3861:1: PID 0:qla_target.c:4447: New command while device
c000000005314600 is shutting down
kernel: qla2xxx [0001:00:02.0]-e85f:1: PID 0:qla_target.c:5728: qla_target: Unable to send command to target
This patch calls qla_stop_phase2() in addition to qlt_stop_phase1() in
tcm_qla2xxx_tpg_enable_store() and tcm_qla2xxx_npiv_tpg_enable_store(). The
qlt_stop_phase1() marks adapter as stopping (tgt_stop == 0x1, tgt_stopped
== 0x0) but qlt_stop_phase2() marks adapter as stopped (tgt_stop == 0x0,
tgt_stopped == 0x1).
Link: https://lore.kernel.org/r/52be1e8a3537f6c5407eae3edd4c8e08a9545ea5.camel@yadro.com
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Viacheslav Dubeyko <v.dubeiko@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Fri, 1 May 2020 09:40:11 +0000 (12:40 +0300)]
ALSA: isa/wavefront: prevent out of bounds write in ioctl
[ Upstream commit
7f0d5053c5a9d23fe5c2d337495a9d79038d267b ]
The "header->number" comes from the ioctl and it needs to be clamped to
prevent out of bounds writes.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20200501094011.GA960082@mwanda
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Linus Walleij [Thu, 13 Feb 2020 14:27:54 +0000 (15:27 +0100)]
ARM: integrator: Add some Kconfig selections
[ Upstream commit
d2854bbe5f5c4b4bec8061caf4f2e603d8819446 ]
The CMA and DMA_CMA Kconfig options need to be selected
by the Integrator in order to produce boot console on some
Integrator systems.
The REGULATOR and REGULATOR_FIXED_VOLTAGE need to be
selected in order to boot the system from an external
MMC card when using MMCI/PL181 from the device tree
probe path.
Select these things directly from the Kconfig so we are
sure to be able to bring the systems up with console
from any device tree.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jon Hunter [Mon, 24 Feb 2020 14:07:48 +0000 (14:07 +0000)]
backlight: lp855x: Ensure regulators are disabled on probe failure
[ Upstream commit
d8207c155a7c6015eb7f43739baa7dfb1fa638af ]
If probing the LP885x backlight fails after the regulators have been
enabled, then the following warning is seen when releasing the
regulators ...
WARNING: CPU: 1 PID: 289 at drivers/regulator/core.c:2051 _regulator_put.part.28+0x158/0x160
Modules linked in: tegra_xudc lp855x_bl(+) host1x pwm_tegra ip_tables x_tables ipv6 nf_defrag_ipv6
CPU: 1 PID: 289 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-
20200224 #1
Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
...
Call trace:
_regulator_put.part.28+0x158/0x160
regulator_put+0x34/0x50
devm_regulator_release+0x10/0x18
release_nodes+0x12c/0x230
devres_release_all+0x34/0x50
really_probe+0x1c0/0x370
driver_probe_device+0x58/0x100
device_driver_attach+0x6c/0x78
__driver_attach+0xb0/0xf0
bus_for_each_dev+0x68/0xc8
driver_attach+0x20/0x28
bus_add_driver+0x160/0x1f0
driver_register+0x60/0x110
i2c_register_driver+0x40/0x80
lp855x_driver_init+0x20/0x1000 [lp855x_bl]
do_one_initcall+0x58/0x1a0
do_init_module+0x54/0x1d0
load_module+0x1d80/0x21c8
__do_sys_finit_module+0xe8/0x100
__arm64_sys_finit_module+0x18/0x20
el0_svc_common.constprop.3+0xb0/0x168
do_el0_svc+0x20/0x98
el0_sync_handler+0xf4/0x1b0
el0_sync+0x140/0x180
Fix this by ensuring that the regulators are disabled, if enabled, on
probe failure.
Finally, ensure that the vddio regulator is disabled in the driver
remove handler.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bryan O'Donoghue [Sun, 29 Mar 2020 12:41:16 +0000 (13:41 +0100)]
clk: qcom: msm8916: Fix the address location of pll->config_reg
[ Upstream commit
f47ab3c2f5338828a67e89d5f688d2cef9605245 ]
During the process of debugging a processor derived from the msm8916 which
we found the new processor was not starting one of its PLLs.
After tracing the addresses and writes that downstream was doing and
comparing to upstream it became obvious that we were writing to a different
register location than downstream when trying to configure the PLL.
This error is also present in upstream msm8916.
As an example clk-pll.c::clk_pll_recalc_rate wants to write to
pll->config_reg updating the bit-field POST_DIV_RATIO. That bit-field is
defined in PLL_USER_CTL not in PLL_CONFIG_CTL. Taking the BIMC PLL as an
example
lm80-p0436-13_c_qc_snapdragon_410_processor_hrd.pdf
0x01823010 GCC_BIMC_PLL_USER_CTL
0x01823014 GCC_BIMC_PLL_CONFIG_CTL
This pattern is repeated for gpll0, gpll1, gpll2 and bimc_pll.
This error is likely not apparent since the bootloader will already have
initialized these PLLs.
This patch corrects the location of config_reg from PLL_CONFIG_CTL to
PLL_USER_CTL for all relevant PLLs on msm8916.
Fixes commit
3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support")
Cc: Georgi Djakov <georgi.djakov@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lkml.kernel.org/r/20200329124116.4185447-1-bryan.odonoghue@linaro.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Mon, 23 Mar 2020 10:41:25 +0000 (12:41 +0200)]
iio: pressure: bmp280: Tolerate IRQ before registering
[ Upstream commit
97b31a6f5fb95b1ec6575b78a7240baddba34384 ]
With DEBUG_SHIRQ enabled we have a kernel crash
[ 116.482696] BUG: kernel NULL pointer dereference, address:
0000000000000000
...
[ 116.606571] Call Trace:
[ 116.609023] <IRQ>
[ 116.611047] complete+0x34/0x50
[ 116.614206] bmp085_eoc_irq+0x9/0x10 [bmp280]
because DEBUG_SHIRQ mechanism fires an IRQ before registration and drivers
ought to be able to handle an interrupt happening before request_irq() returns.
Fixes:
aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC interrupt")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Adam Honse [Fri, 10 Apr 2020 20:48:44 +0000 (15:48 -0500)]
i2c: piix4: Detect secondary SMBus controller on AMD AM4 chipsets
[ Upstream commit
f27237c174fd9653033330e4e532cd9d153ce824 ]
The AMD X370 and other AM4 chipsets (A/B/X 3/4/5 parts) and Threadripper
equivalents have a secondary SMBus controller at I/O port address
0x0B20. This bus is used by several manufacturers to control
motherboard RGB lighting via embedded controllers. I have been using
this bus in my OpenRGB project to control the Aura RGB on many
motherboards and ASRock also uses this bus for their Polychrome RGB
controller.
I am not aware of any CZ-compatible platforms which do not have the
second SMBus channel. All of AMD's AM4- and Threadripper- series
chipsets that OpenRGB users have tested appear to have this secondary
bus. I also noticed this secondary bus is present on older AMD
platforms including my FM1 home server.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202587
Signed-off-by: Adam Honse <calcprogrammer1@gmail.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rikard Falkeborn [Tue, 17 Mar 2020 21:13:32 +0000 (22:13 +0100)]
clk: sunxi: Fix incorrect usage of round_down()
[ Upstream commit
ee25d9742dabed3fd18158b518f846abeb70f319 ]
round_down() can only round to powers of 2. If round_down() is asked
to round to something that is not a power of 2, incorrect results are
produced. The incorrect results can be both too large and too small.
Instead, use rounddown() which can round to any number.
Fixes:
6a721db180a2 ("clk: sunxi: Add A31 clocks support")
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Enric Balletbo i Serra [Mon, 13 Apr 2020 14:10:51 +0000 (16:10 +0200)]
power: supply: bq24257_charger: Replace depends on REGMAP_I2C with select
[ Upstream commit
87c3d579c8ed0eaea6b1567d529a8daa85a2bc6c ]
regmap is a library function that gets selected by drivers that need
it. No driver modules should depend on it. Depending on REGMAP_I2C makes
this driver only build if another driver already selected REGMAP_I2C,
as the symbol can't be selected through the menu kernel configuration.
Fixes:
2219a935963e ("power_supply: Add TI BQ24257 charger driver")
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Greg Kroah-Hartman [Sat, 20 Jun 2020 08:24:22 +0000 (10:24 +0200)]
Linux 4.9.228
Adrian Hunter [Tue, 26 May 2020 15:52:07 +0000 (18:52 +0300)]
perf symbols: Fix debuginfo search for Ubuntu
commit
85afd35575a3c1a3a905722dde5ee70b49282e70 upstream.
Reportedly, from 19.10 Ubuntu has begun mixing up the location of some
debug symbol files, putting files expected to be in
/usr/lib/debug/usr/lib into /usr/lib/debug/lib instead. Fix by adding
another dso_binary_type.
Example on Ubuntu 20.04
Before:
$ perf record -e intel_pt//u uname
Linux
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.030 MB perf.data ]
$ perf script --call-trace | head -5
uname 14003 [005] 15321.
764958566: cbr: 42 freq: 4219 MHz (156%)
uname 14003 [005] 15321.
764958566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so )
7f1e71cc4100
uname 14003 [005] 15321.
764961566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so )
7f1e71cc4df0
uname 14003 [005] 15321.
764961900: (/usr/lib/x86_64-linux-gnu/ld-2.31.so )
7f1e71cc4e18
uname 14003 [005] 15321.
764963233: (/usr/lib/x86_64-linux-gnu/ld-2.31.so )
7f1e71cc5128
After:
$ perf script --call-trace | head -5
uname 14003 [005] 15321.
764958566: cbr: 42 freq: 4219 MHz (156%)
uname 14003 [005] 15321.
764958566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _start
uname 14003 [005] 15321.
764961566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _dl_start
uname 14003 [005] 15321.
764961900: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _dl_start
uname 14003 [005] 15321.
764963233: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _dl_start
Reported-by: Travis Downs <travis.downs@gmail.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lore.kernel.org/lkml/20200526155207.9172-1-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masami Hiramatsu [Thu, 23 Apr 2020 11:01:22 +0000 (20:01 +0900)]
perf probe: Do not show the skipped events
commit
f41ebe9defacddeae96a872a33f0f22ced0bfcef upstream.
When a probe point is expanded to several places (like inlined) and if
some of them are skipped because of blacklisted or __init function,
those trace_events has no event name. It must be skipped while showing
results.
Without this fix, you can see "(null):(null)" on the list,
# ./perf probe request_resource
reserve_setup is out of .text, skip it.
Added new events:
(null):(null) (on request_resource)
probe:request_resource (on request_resource)
You can now use it in all perf tools, such as:
perf record -e probe:request_resource -aR sleep 1
#
With this fix, it is ignored:
# ./perf probe request_resource
reserve_setup is out of .text, skip it.
Added new events:
probe:request_resource (on request_resource)
You can now use it in all perf tools, such as:
perf record -e probe:request_resource -aR sleep 1
#
Fixes:
5a51fcd1f30c ("perf probe: Skip kernel symbols which is out of .text")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: stable@vger.kernel.org
Link: http://lore.kernel.org/lkml/158763968263.30755.12800484151476026340.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
H. Nikolaus Schaller [Sat, 23 May 2020 17:32:54 +0000 (19:32 +0200)]
w1: omap-hdq: cleanup to add missing newline for some dev_dbg
commit
5e02f3b31704e24537697bce54f8156bdb72b7a6 upstream.
Otherwise it will corrupt the console log during debugging.
Fixes:
7b5362a603a1 ("w1: omap_hdq: Fix some error/debug handling.")
Cc: stable@vger.kernel.org
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/cd0d55749a091214106575f6e1d363c6db56622f.1590255176.git.hns@goldelico.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miquel Raynal [Tue, 19 May 2020 13:00:13 +0000 (15:00 +0200)]
mtd: rawnand: pasemi: Fix the probe error path
commit
f51466901c07e6930435d30b02a21f0841174f61 upstream.
nand_cleanup() is supposed to be called on error after a successful
call to nand_scan() to free all NAND resources.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit
d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible, hence pointing it as the commit to
fix for backporting purposes, even if this commit is not introducing
any bug.
Fixes:
d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-41-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Álvaro Fernández Rojas [Tue, 12 May 2020 07:57:32 +0000 (09:57 +0200)]
mtd: rawnand: brcmnand: fix hamming oob layout
commit
130bbde4809b011faf64f99dddc14b4b01f440c3 upstream.
First 2 bytes are used in large-page nand.
Fixes:
ef5eeea6e911 ("mtd: nand: brcm: switch to mtd_ooblayout_ops")
Cc: stable@vger.kernel.org
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200512075733.745374-2-noltari@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Fri, 22 May 2020 02:01:33 +0000 (12:01 +1000)]
sunrpc: clean up properly in gss_mech_unregister()
commit
24c5efe41c29ee3e55bcf5a1c9f61ca8709622e8 upstream.
gss_mech_register() calls svcauth_gss_register_pseudoflavor() for each
flavour, but gss_mech_unregister() does not call auth_domain_put().
This is unbalanced and makes it impossible to reload the module.
Change svcauth_gss_register_pseudoflavor() to return the registered
auth_domain, and save it for later release.
Cc: stable@vger.kernel.org (v2.6.12+)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206651
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Fri, 22 May 2020 02:01:33 +0000 (12:01 +1000)]
sunrpc: svcauth_gss_register_pseudoflavor must reject duplicate registrations.
commit
d47a5dc2888fd1b94adf1553068b8dad76cec96c upstream.
There is no valid case for supporting duplicate pseudoflavor
registrations.
Currently the silent acceptance of such registrations is hiding a bug.
The rpcsec_gss_krb5 module registers 2 flavours but does not unregister
them, so if you load, unload, reload the module, it will happily
continue to use the old registration which now has pointers to the
memory were the module was originally loaded. This could lead to
unexpected results.
So disallow duplicate registrations.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206651
Cc: stable@vger.kernel.org (v2.6.12+)
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masahiro Yamada [Sun, 31 May 2020 08:47:06 +0000 (17:47 +0900)]
kbuild: force to build vmlinux if CONFIG_MODVERSION=y
commit
4b50c8c4eaf06a825d1c005c0b1b4a8307087b83 upstream.
This code does not work as stated in the comment.
$(CONFIG_MODVERSIONS) is always empty because it is expanded before
include/config/auto.conf is included. Hence, 'make modules' with
CONFIG_MODVERSION=y cannot record the version CRCs.
This has been broken since 2003, commit ("kbuild: Enable modules to be
build using the "make dir/" syntax"). [1]
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=
15c6240cdc44bbeef3c4797ec860f9765ef4f1a7
Cc: linux-stable <stable@vger.kernel.org> # v2.5.71+
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Thu, 23 Apr 2020 06:00:38 +0000 (16:00 +1000)]
drivers/macintosh: Fix memleak in windfarm_pm112 driver
commit
93900337b9ac2f4eca427eff6d187be2dc3b5551 upstream.
create_cpu_loop() calls smu_sat_get_sdb_partition() which does
kmalloc() and returns the allocated buffer. In fact it's called twice,
and neither buffer is freed.
This results in a memory leak as reported by Erhard:
unreferenced object 0xc00000047081f840 (size 32):
comm "kwindfarm", pid 203, jiffies
4294880630 (age 5552.877s)
hex dump (first 32 bytes):
c8 06 02 7f ff 02 ff 01 fb bf 00 41 00 20 00 00 ...........A. ..
00 07 89 37 00 a0 00 00 00 00 00 00 00 00 00 00 ...7............
backtrace:
[<
0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat]
[<
000000003010fcb7>] .pm112_wf_notify+0x104c/0x13bc [windfarm_pm112]
[<
00000000b958b2dd>] .notifier_call_chain+0xa8/0x180
[<
0000000070490868>] .blocking_notifier_call_chain+0x64/0x90
[<
00000000131d8149>] .wf_thread_func+0x114/0x1a0
[<
000000000d54838d>] .kthread+0x13c/0x190
[<
00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64
unreferenced object 0xc0000004737089f0 (size 16):
comm "kwindfarm", pid 203, jiffies
4294880879 (age 5552.050s)
hex dump (first 16 bytes):
c4 04 01 7f 22 11 e0 e6 ff 55 7b 12 ec 11 00 00 ...."....U{.....
backtrace:
[<
0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat]
[<
00000000b94ef7e1>] .pm112_wf_notify+0x1294/0x13bc [windfarm_pm112]
[<
00000000b958b2dd>] .notifier_call_chain+0xa8/0x180
[<
0000000070490868>] .blocking_notifier_call_chain+0x64/0x90
[<
00000000131d8149>] .wf_thread_func+0x114/0x1a0
[<
000000000d54838d>] .kthread+0x13c/0x190
[<
00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64
Fix it by rearranging the logic so we deal with each buffer
separately, which then makes it easy to free the buffer once we're
done with it.
Fixes:
ac171c46667c ("[PATCH] powerpc: Thermal control for dual core G5s")
Cc: stable@vger.kernel.org # v2.6.16+
Reported-by: Erhard F. <erhard_f@mailbox.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Erhard F. <erhard_f@mailbox.org>
Link: https://lore.kernel.org/r/20200423060038.3308530-1-mpe@ellerman.id.au
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Osipenko [Fri, 13 Mar 2020 09:01:04 +0000 (12:01 +0300)]
ARM: tegra: Correct PL310 Auxiliary Control Register initialization
commit
35509737c8f958944e059d501255a0bf18361ba0 upstream.
The PL310 Auxiliary Control Register shouldn't have the "Full line of
zero" optimization bit being set before L2 cache is enabled. The L2X0
driver takes care of enabling the optimization by itself.
This patch fixes a noisy error message on Tegra20 and Tegra30 telling
that cache optimization is erroneously enabled without enabling it for
the CPU:
L2C-310: enabling full line of zeros but not enabled in Cortex-A9
Cc: <stable@vger.kernel.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Tested-by: Nicolas Chauvet <kwizart@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Douglas Anderson [Mon, 4 May 2020 17:50:17 +0000 (10:50 -0700)]
kernel/cpu_pm: Fix uninitted local in cpu_pm
commit
b5945214b76a1f22929481724ffd448000ede914 upstream.
cpu_pm_notify() is basically a wrapper of notifier_call_chain().
notifier_call_chain() doesn't initialize *nr_calls to 0 before it
starts incrementing it--presumably it's up to the callers to do this.
Unfortunately the callers of cpu_pm_notify() don't init *nr_calls.
This potentially means you could get too many or two few calls to
CPU_PM_ENTER_FAILED or CPU_CLUSTER_PM_ENTER_FAILED depending on the
luck of the stack.
Let's fix this.
Fixes:
ab10023e0088 ("cpu_pm: Add cpu power management notifiers")
Cc: stable@vger.kernel.org
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200504104917.v6.3.I2d44fc0053d019f239527a4e5829416714b7e299@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Sun, 17 May 2020 19:37:50 +0000 (15:37 -0400)]
sparc64: fix misuses of access_process_vm() in genregs32_[sg]et()
commit
142cd25293f6a7ecbdff4fb0af17de6438d46433 upstream.
We do need access_process_vm() to access the target's reg_window.
However, access to caller's memory (storing the result in
genregs32_get(), fetching the new values in case of genregs32_set())
should be done by normal uaccess primitives.
Fixes:
ad4f95764040 ([SPARC64]: Fix user accesses in regset code.)
Cc: stable@kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Sun, 17 May 2020 16:20:40 +0000 (12:20 -0400)]
sparc32: fix register window handling in genregs32_[gs]et()
commit
cf51e129b96847f969bfb8af1ee1516a01a70b39 upstream.
It needs access_process_vm() if the traced process does not share
mm with the caller. Solution is similar to what sparc64 does.
Note that genregs32_set() is only ever called with pos being 0
or 32 * sizeof(u32) (the latter - as part of PTRACE_SETREGS
handling).
Cc: stable@kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Bakker [Sat, 25 Apr 2020 23:10:46 +0000 (16:10 -0700)]
pinctrl: samsung: Save/restore eint_mask over suspend for EINT_TYPE GPIOs
commit
f354157a7d184db430c1a564c506434e33b1bec5 upstream.
Currently, for EINT_TYPE GPIOs, the CON and FLTCON registers
are saved and restored over a suspend/resume cycle. However, the
EINT_MASK registers are not.
On S5PV210 at the very least, these registers are not retained over
suspend, leading to the interrupts remaining masked upon resume and
therefore no interrupts being triggered for the device. There should
be no effect on any SoCs that do retain these registers as theoretically
we would just be re-writing what was already there.
Fixes:
7ccbc60cd9c2 ("pinctrl: exynos: Handle suspend/resume of GPIO EINT registers")
Cc: <stable@vger.kernel.org>
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anders Roxell [Wed, 27 May 2020 11:26:04 +0000 (13:26 +0200)]
power: vexpress: add suppress_bind_attrs to true
commit
73174acc9c75960af2daa7dcbdb9781fc0d135cb upstream.
Make sure that the POWER_RESET_VEXPRESS driver won't have bind/unbind
attributes available via the sysfs, so lets be explicit here and use
".suppress_bind_attrs = true" to prevent userspace from doing something
silly.
Link: https://lore.kernel.org/r/20200527112608.3886105-2-anders.roxell@linaro.org
Cc: stable@vger.kernel.org
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / platform / kernel / linux-amlogic.git / log