14 Nov, 2018
40 commits
-
commit aab8d0520e6e7c2a61f71195e6ce7007a4843afb upstream.
Private ZONE_DEVICE pages use a special pte entry and thus are not
present. Properly handle this case in map_pte(), it is already handled in
check_pte(), the map_pte() part was lost in some rebase most probably.Without this patch the slow migration path can not migrate back to any
private ZONE_DEVICE memory to regular memory. This was found after stress
testing migration back to system memory. This ultimatly can lead to the
CPU constantly page fault looping on the special swap entry.Link: http://lkml.kernel.org/r/20181019160442.18723-3-jglisse@redhat.com
Signed-off-by: Ralph Campbell
Signed-off-by: Jérôme Glisse
Reviewed-by: Balbir Singh
Cc: Andrew Morton
Cc: Kirill A. Shutemov
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 22146c3ce98962436e401f7b7016a6f664c9ffb5 upstream.
Some test systems were experiencing negative huge page reserve counts and
incorrect file block counts. This was traced to /proc/sys/vm/drop_caches
removing clean pages from hugetlbfs file pagecaches. When non-hugetlbfs
explicit code removes the pages, the appropriate accounting is not
performed.This can be recreated as follows:
fallocate -l 2M /dev/hugepages/foo
echo 1 > /proc/sys/vm/drop_caches
fallocate -l 2M /dev/hugepages/foo
grep -i huge /proc/meminfo
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
HugePages_Total: 2048
HugePages_Free: 2047
HugePages_Rsvd: 18446744073709551615
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 4194304 kB
ls -lsh /dev/hugepages/foo
4.0M -rw-r--r--. 1 root root 2.0M Oct 17 20:05 /dev/hugepages/fooTo address this issue, dirty pages as they are added to pagecache. This
can easily be reproduced with fallocate as shown above. Read faulted
pages will eventually end up being marked dirty. But there is a window
where they are clean and could be impacted by code such as drop_caches.
So, just dirty them all as they are added to the pagecache.Link: http://lkml.kernel.org/r/b5be45b8-5afe-56cd-9482-28384699a049@oracle.com
Fixes: 6bda666a03f0 ("hugepages: fold find_or_alloc_pages into huge_no_page()")
Signed-off-by: Mike Kravetz
Acked-by: Mihcla Hocko
Reviewed-by: Khalid Aziz
Cc: Hugh Dickins
Cc: Naoya Horiguchi
Cc: "Aneesh Kumar K . V"
Cc: Andrea Arcangeli
Cc: "Kirill A . Shutemov"
Cc: Davidlohr Bueso
Cc: Alexander Viro
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 1e4c8dafbb6bf72fb5eca035b861e39c5896c2b7 upstream.
The 12 character temporary buffer is not necessarily long enough to hold
a 'long' value. Increase it.Signed-off-by: Eric Biggers
Cc: stable@vger.kernel.org
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman -
commit fa76da461bb0be13c8339d984dcf179151167c8f upstream.
Leonardo reports an apparent regression in 4.19-rc7:
BUG: unable to handle kernel NULL pointer dereference at 00000000000000f0
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 3 PID: 6032 Comm: python Not tainted 4.19.0-041900rc7-lowlatency #201810071631
Hardware name: LENOVO 80UG/Toronto 4A2, BIOS 0XCN45WW 08/09/2018
RIP: 0010:smaps_pte_range+0x32d/0x540
Code: 80 00 00 00 00 74 a9 48 89 de 41 f6 40 52 40 0f 85 04 02 00 00 49 2b 30 48 c1 ee 0c 49 03 b0 98 00 00 00 49 8b 80 a0 00 00 00 8b b8 f0 00 00 00 e8 b7 ef ec ff 48 85 c0 0f 84 71 ff ff ff a8
RSP: 0018:ffffb0cbc484fb88 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 0000560ddb9e9000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000560ddb9e9 RDI: 0000000000000001
RBP: ffffb0cbc484fbc0 R08: ffff94a5a227a578 R09: ffff94a5a227a578
R10: 0000000000000000 R11: 0000560ddbbe7000 R12: ffffe903098ba728
R13: ffffb0cbc484fc78 R14: ffffb0cbc484fcf8 R15: ffff94a5a2e9cf48
FS: 00007f6dfb683740(0000) GS:ffff94a5aaf80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000f0 CR3: 000000011c118001 CR4: 00000000003606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__walk_page_range+0x3c2/0x6f0
walk_page_vma+0x42/0x60
smap_gather_stats+0x79/0xe0
? gather_pte_stats+0x320/0x320
? gather_hugetlb_stats+0x70/0x70
show_smaps_rollup+0xcd/0x1c0
seq_read+0x157/0x400
__vfs_read+0x3a/0x180
? security_file_permission+0x93/0xc0
? security_file_permission+0x93/0xc0
vfs_read+0x8f/0x140
ksys_read+0x55/0xc0
__x64_sys_read+0x1a/0x20
do_syscall_64+0x5a/0x110
entry_SYSCALL_64_after_hwframe+0x44/0xa9Decoded code matched to local compilation+disassembly points to
smaps_pte_entry():} else if (unlikely(IS_ENABLED(CONFIG_SHMEM) && mss->check_shmem_swap
&& pte_none(*pte))) {
page = find_get_entry(vma->vm_file->f_mapping,
linear_page_index(vma, addr));Here, vma->vm_file is NULL. mss->check_shmem_swap should be false in that
case, however for smaps_rollup, smap_gather_stats() can set the flag true
for one vma and leave it true for subsequent vma's where it should be
false.To fix, reset the check_shmem_swap flag to false. There's also related
bug which sets mss->swap to shmem_swapped, which in the context of
smaps_rollup overwrites any value accumulated from previous vma's. Fix
that as well.Note that the report suggests a regression between 4.17.19 and 4.19-rc7,
which makes the 4.19 series ending with commit 258f669e7e88 ("mm:
/proc/pid/smaps_rollup: convert to single value seq_file") suspicious.
But the mss was reused for rollup since 493b0e9d945f ("mm: add
/proc/pid/smaps_rollup") so let's play it safe with the stable backport.Link: http://lkml.kernel.org/r/555fbd1f-4ac9-0b58-dcd4-5dc4380ff7ca@suse.cz
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201377
Fixes: 493b0e9d945f ("mm: add /proc/pid/smaps_rollup")
Signed-off-by: Vlastimil Babka
Reported-by: Leonardo Soares Müller
Tested-by: Leonardo Soares Müller
Cc: Greg Kroah-Hartman
Cc: Daniel Colascione
Cc: Alexey Dobriyan
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 331351f89c36bf7d03561a28b6f64fa10a9f6f3a upstream.
ghash is a keyed hash algorithm, thus setkey needs to be called.
Otherwise the following error occurs:
$ modprobe tcrypt mode=318 sec=1
testing speed of async ghash-generic (ghash-generic)
tcrypt: test 0 ( 16 byte blocks, 16 bytes per update, 1 updates):
tcrypt: hashing failed ret=-126Cc: # 4.6+
Fixes: 0660511c0bee ("crypto: tcrypt - Use ahash")
Tested-by: Franck Lenormand
Signed-off-by: Horia Geantă
Acked-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit fbe1a850b3b1522e9fc22319ccbbcd2ab05328d2 upstream.
When the LRW block counter overflows, the current implementation returns
128 as the index to the precomputed multiplication table, which has 128
entries. This patch fixes it to return the correct value (127).Fixes: 64470f1b8510 ("[CRYPTO] lrw: Liskov Rivest Wagner, a tweakable narrow block cipher mode")
Cc: # 2.6.20+
Reported-by: Eric Biggers
Signed-off-by: Ondrej Mosnacek
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit a36700589b85443e28170be59fa11c8a104130a5 upstream.
While fixing an out of bounds array access in known_siginfo_layout
reported by the kernel test robot it became apparent that the same bug
exists in siginfo_layout and affects copy_siginfo_from_user32.The straight forward fix that makes guards against making this mistake
in the future and should keep the code size small is to just take an
unsigned signal number instead of a signed signal number, as I did to
fix known_siginfo_layout.Cc: stable@vger.kernel.org
Fixes: cc731525f26a ("signal: Remove kernel interal si_code magic")
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman -
commit 0ab93e9c99f8208c0a1a7b7170c827936268c996 upstream.
The genweq_add_file and genwqe_del_file by caching current without
using reference counting embed the assumption that a file descriptor
will never be passed from one process to another. It even embeds the
assumption that the the thread that opened the file will be in
existence when the process terminates. Neither of which are
guaranteed to be true.Therefore replace caching the task_struct of the opener with
pid of the openers thread group id. All the knowledge of the
opener is used for is as the target of SIGKILL and a SIGKILL
will kill the entire process group.Rename genwqe_force_sig to genwqe_terminate, remove it's unncessary
signal argument, update it's ownly caller, and use kill_pid
instead of force_sig.The work force_sig does in changing signal handling state is not
relevant to SIGKILL sent as SEND_SIG_PRIV. The exact same processess
will be killed just with less work, and less confusion. The work done
by force_sig is really only needed for handling syncrhonous
exceptions.It will still be possible to cause genwqe_device_remove to wait
8 seconds by passing a file descriptor to another process but
the possible user after free is fixed.Fixes: eaf4722d4645 ("GenWQE Character device and DDCB queue")
Cc: stable@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: Frank Haverkamp
Cc: Joerg-Stephan Vogt
Cc: Michael Jung
Cc: Michael Ruettger
Cc: Kleber Sacilotto de Souza
Cc: Sebastian Ott
Cc: Eberhard S. Amann
Cc: Gabriel Krisman Bertazi
Cc: Guilherme G. Piccoli
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman -
commit a7f58b9ecfd3c0f63703ec10f4a592cc38dbd1b8 upstream.
Devices with slow interrupt handlers are significantly harming
performance when their interrupt vector is shared with a fast device.Create a class code white list for devices with known fast interrupt
handlers and let all other devices share a single vector so that they
don't interfere with performance.At the moment, only the NVM Express class code is on the list, but more
may be added if VMD users desire to use other low-latency devices in
these domains.Signed-off-by: Keith Busch
[lorenzo.pieralisi@arm.com: changelog]
Signed-off-by: Lorenzo Pieralisi
Acked-by: Jon Derrick:
Cc: "Heitke, Kenneth"
Signed-off-by: Greg Kroah-Hartman -
commit d0c9606b31a21028fb5b753c8ad79626292accfd upstream.
Add Device IDs to the Intel GPU "spurious interrupt" quirk table.
For these devices, unplugging the VGA cable and plugging it in again causes
spurious interrupts from the IGD. Linux eventually disables the interrupt,
but of course that disables any other devices sharing the interrupt.The theory is that this is a VGA BIOS defect: it should have disabled the
IGD interrupt but failed to do so.See f67fd55fa96f ("PCI: Add quirk for still enabled interrupts on Intel
Sandy Bridge GPUs") and 7c82126a94e6 ("PCI: Add new ID for Intel GPU
"spurious interrupt" quirk") for some history.[bhelgaas: See link below for discussion about how to fix this more
generically instead of adding device IDs for every new Intel GPU. I hope
this is the last patch to add device IDs.]Link: https://lore.kernel.org/linux-pci/1537974841-29928-1-git-send-email-bmeng.cn@gmail.com
Signed-off-by: Bin Meng
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Greg Kroah-Hartman -
commit aeae4f3e5c38d47bdaef50446dc0ec857307df68 upstream.
Upon removal of the last device on a bus, the link_state of the bridge
leading to that bus is sought to be torn down by having pci_stop_dev()
call pcie_aspm_exit_link_state().When ASPM was originally introduced by commit 7d715a6c1ae5 ("PCI: add
PCI Express ASPM support"), it determined whether the device being
removed is the last one by calling list_empty() on the bridge's
subordinate devices list. That didn't work because the device is only
removed from the list slightly later in pci_destroy_dev().Commit 3419c75e15f8 ("PCI: properly clean up ASPM link state on device
remove") attempted to fix it by calling list_is_last(), but that's not
correct either because it checks whether the device is at the *end* of
the list, not whether it's the last one *left* in the list. If the user
removes the device which happens to be at the end of the list via sysfs
but other devices are preceding the device in the list, the link_state
is torn down prematurely.The real fix is to move the invocation of pcie_aspm_exit_link_state() to
pci_destroy_dev() and reinstate the call to list_empty(). Remove a
duplicate check for dev->bus->self because pcie_aspm_exit_link_state()
already contains an identical check.Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support")
Signed-off-by: Lukas Wunner
Signed-off-by: Bjorn Helgaas
Cc: Shaohua Li
Cc: stable@vger.kernel.org # v2.6.26
Signed-off-by: Greg Kroah-Hartman -
commit 6d0af44a82be87c13f2320821e9fbb8b8cf5a56f upstream.
Bit positions of PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE and
PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE in CTRL_CORE_SMA_SW_7 are
incorrectly documented in the TRM. In fact, the bit positions are
swapped. Update the DT bindings for PCIe EP to reflect the same.Fixes: d23f3839fe97 ("ARM: dts: DRA7: Add pcie1 dt node for EP mode")
Cc: stable@vger.kernel.org
Signed-off-by: Vignesh R
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 8f18973877204dc8ca4ce1004a5d28683b9a7086 upstream.
The code "lchan = (lchan << 1) | ~lchan" for logical channel
intermediate decoding is wrong. The wrong intermediate decoding
result is {0xffffffff, 0xfffffffe}.Fix it by replacing '~' with '!'. The correct intermediate
decoding result is {0x1, 0x2}.Signed-off-by: Qiuxu Zhuo
Signed-off-by: Tony Luck
Signed-off-by: Borislav Petkov
CC: Aristeu Rozanski
CC: Mauro Carvalho Chehab
CC: linux-edac
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20181009172025.18594-1-tony.luck@intel.com
Signed-off-by: Greg Kroah-Hartman -
commit 432de7fd7630c84ad24f1c2acd1e3bb4ce3741ca upstream.
The count of errors is picked up from bits 52:38 of the machine check
bank status register. But this is the count of *corrected* errors. If an
uncorrected error is being logged, the h/w sets this field to 0. Which
means that when edac_mc_handle_error() is called, the EDAC core will
carefully add zero to the appropriate uncorrected error counts.Signed-off-by: Tony Luck
[ Massage commit message. ]
Signed-off-by: Borislav Petkov
Cc: stable@vger.kernel.org
Cc: Aristeu Rozanski
Cc: Mauro Carvalho Chehab
Cc: Qiuxu Zhuo
Cc: linux-edac
Link: http://lkml.kernel.org/r/20180928213934.19890-1-tony.luck@intel.com
Signed-off-by: Greg Kroah-Hartman -
commit 8960de4a5ca7980ed1e19e7ca5a774d3b7a55c38 upstream.
Add new device IDs for family 17h, models 10h-2fh.
This is required by amd64_edac_mod in order to properly detect PCI
device functions 0 and 6.Signed-off-by: Michael Jin
Reviewed-by: Yazen Ghannam
Cc:
Link: http://lkml.kernel.org/r/20180816192840.31166-1-mikhail.jin@gmail.com
Signed-off-by: Borislav Petkov
Signed-off-by: Greg Kroah-Hartman -
commit f11274396a538b31bc010f782e05c2ce3f804c13 upstream.
uref->usage_index can be indirectly controlled by userspace, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.This field is used as an array index by the hiddev_ioctl_usage() function,
when 'cmd' is either HIDIOCGCOLLECTIONINDEX, HIDIOCGUSAGES or
HIDIOCSUSAGES.For cmd == HIDIOCGCOLLECTIONINDEX case, uref->usage_index is compared to
field->maxusage and then used as an index to dereference field->usage
array. The same thing happens to the cmd == HIDIOC{G,S}USAGES cases, where
uref->usage_index is checked against an array maximum value and then it is
used as an index in an array.This is a summary of the HIDIOCGCOLLECTIONINDEX case, which matches the
traditional Spectre V1 first load:copy_from_user(uref, user_arg, sizeof(*uref))
if (uref->usage_index >= field->maxusage)
goto inval;
i = field->usage[uref->usage_index].collection_index;
return i;This patch fixes this by sanitizing field uref->usage_index before using it
to index field->usage (HIDIOCGCOLLECTIONINDEX) or field->value in
HIDIOC{G,S}USAGES arrays, thus, avoiding speculation in the first load.Cc:
Signed-off-by: Breno Leitao
v2: Contemplate cmd == HIDIOC{G,S}USAGES case
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit 33458eaba4dfe778a426df6a19b7aad2ff9f7eec upstream.
It's possible for ext4_show_quota_options() to try reading
s_qf_names[i] while it is being modified by ext4_remount() --- most
notably, in ext4_remount's error path when the original values of the
quota file name gets restored.Reported-by: syzbot+a2872d6feea6918008a9@syzkaller.appspotmail.com
Signed-off-by: Theodore Ts'o
Cc: stable@kernel.org # 3.2+
Signed-off-by: Greg Kroah-Hartman -
commit 182a79e0c17147d2c2d3990a9a7b6b58a1561c7a upstream.
We return most failure of dquota_initialize() except
inode evict, this could make a bit sense, for example
we allow file removal even quota files are broken?But it dosen't make sense to allow setting project
if quota files etc are broken.Signed-off-by: Wang Shilong
Signed-off-by: Theodore Ts'o
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit dc7ac6c4cae3b58724c2f1e21a7c05ce19ecd5a8 upstream.
Currently, project quota could be changed by fssetxattr
ioctl, and existed permission check inode_owner_or_capable()
is obviously not enough, just think that common users could
change project id of file, that could make users to
break project quota easily.This patch try to follow same regular of xfs project
quota:"Project Quota ID state is only allowed to change from
within the init namespace. Enforce that restriction only
if we are trying to change the quota ID state.
Everything else is allowed in user namespaces."Besides that, check and set project id'state should
be an atomic operation, protect whole operation with
inode lock, ext4_ioctl_setproject() is only used for
ioctl EXT4_IOC_FSSETXATTR, we have held mnt_want_write_file()
before ext4_ioctl_setflags(), and ext4_ioctl_setproject()
is called after ext4_ioctl_setflags(), we could share
codes, so remove it inside ext4_ioctl_setproject().Signed-off-by: Wang Shilong
Signed-off-by: Theodore Ts'o
Reviewed-by: Andreas Dilger
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 625ef8a3acd111d5f496d190baf99d1a815bd03e upstream.
Variable retries is not initialized in ext4_da_write_inline_data_begin()
which can lead to nondeterministic number of retries in case we hit
ENOSPC. Initialize retries to zero as we do everywhere else.Signed-off-by: Lukas Czerner
Signed-off-by: Theodore Ts'o
Fixes: bc0ca9df3b2a ("ext4: retry allocation when inline->extent conversion failed")
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 3df629d873f8683af6f0d34dfc743f637966d483 upstream.
get in sync with mount_bdev() handling of the same
Reported-by: syzbot+c54f8e94e6bba03b04e9@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro
Signed-off-by: Greg Kroah-Hartman -
commit ccd3c4373eacb044eb3832966299d13d2631f66f upstream.
The code cleaning transaction's lists of checkpoint buffers has a bug
where it increases bh refcount only after releasing
journal->j_list_lock. Thus the following race is possible:CPU0 CPU1
jbd2_log_do_checkpoint()
jbd2_journal_try_to_free_buffers()
__journal_try_to_free_buffer(bh)
...
while (transaction->t_checkpoint_io_list)
...
if (buffer_locked(bh)) {spin_unlock(&journal->j_list_lock);
spin_lock(&journal->j_list_lock);
__jbd2_journal_remove_checkpoint(jh);
spin_unlock(&journal->j_list_lock);
try_to_free_buffers(page);
get_bh(bh) j_list_lock.Fixes: dc6e8d669cf5 ("jbd2: don't call get_bh() before calling __jbd2_journal_remove_checkpoint()")
Fixes: be1158cc615f ("jbd2: fold __process_buffer() into jbd2_log_do_checkpoint()")
Reported-by: syzbot+7f4a27091759e2fe7453@syzkaller.appspotmail.com
CC: stable@vger.kernel.org
Reviewed-by: Lukas Czerner
Signed-off-by: Jan Kara
Signed-off-by: Theodore Ts'o
Signed-off-by: Greg Kroah-Hartman -
commit 013c2403bf32e48119aeb13126929f81352cc7ac upstream.
Schedule MR cache work only after bucket was initialized.
Cc: # 4.10
Fixes: 49780d42dfc9 ("IB/mlx5: Expose MR cache for mlx5_ib")
Signed-off-by: Artemy Kovalyov
Reviewed-by: Majd Dibbiny
Signed-off-by: Leon Romanovsky
Signed-off-by: Jason Gunthorpe
Signed-off-by: Greg Kroah-Hartman -
commit 9c80c5a8831471e0a3e139aad1b0d4c0fdc50b2f upstream.
skl_tplg_get_token() misses a break in the big switch() block for
SKL_TKN_U8_CORE_ID entry.
Spotted nicely by -Wimplicit-fallthrough compiler option.Fixes: 6277e83292a2 ("ASoC: Intel: Skylake: Parse vendor tokens to build module data")
Cc:
Signed-off-by: Takashi Iwai
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 5d394eee2c102453278d81d9a7cf94c80253486a upstream.
While experimenting with region driver loading the following backtrace
was triggered:INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
[..]
Call Trace:
dump_stack+0x85/0xcb
register_lock_class+0x571/0x580
? __lock_acquire+0x2ba/0x1310
? kernfs_seq_start+0x2a/0x80
__lock_acquire+0xd4/0x1310
? dev_attr_show+0x1c/0x50
? __lock_acquire+0x2ba/0x1310
? kernfs_seq_start+0x2a/0x80
? lock_acquire+0x9e/0x1a0
lock_acquire+0x9e/0x1a0
? dev_attr_show+0x1c/0x50
badblocks_show+0x70/0x190
? dev_attr_show+0x1c/0x50
dev_attr_show+0x1c/0x50This results from a missing successful call to devm_init_badblocks()
from nd_region_probe(). Block attempts to show badblocks while the
region is not enabled.Fixes: 6a6bef90425e ("libnvdimm: add mechanism to publish badblocks...")
Cc:
Reviewed-by: Johannes Thumshirn
Reviewed-by: Dave Jiang
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman -
commit b6eae0f61db27748606cc00dafcfd1e2c032f0a5 upstream.
Unlike asynchronous initialization in the core we have not yet associated
the device with the parent, and as such the device doesn't hold a reference
to the parent.In order to resolve that we should be holding a reference on the parent
until the asynchronous initialization has completed.Cc:
Fixes: 4d88a97aa9e8 ("libnvdimm: ...base ... infrastructure")
Signed-off-by: Alexander Duyck
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman -
commit e57cb3b3f10d005410f09d4598cc6d62b833f2b0 upstream.
When in cyclic mode, the configuration is updated after having started the
DMA hardware (STM32_DMA_SCR_EN) leading to incomplete configuration of
SMxAR registers.Signed-off-by: Pierre-Yves MORDRET
Signed-off-by: Hugues Fruchet
Signed-off-by: Vinod Koul
Cc: "Joel Fernandes (Google)"
Signed-off-by: Greg Kroah-Hartman -
commit 27d8d2d7a9b7eb05c4484b74b749eaee7b50b845 upstream.
There are two poly_store, but one should have been poly_show.
|adma.c:4382:16: error: conflicting types for 'poly_store'
| static ssize_t poly_store(struct device_driver *dev, const char *buf,
| ^~~~~~~~~~
|adma.c:4363:16: note: previous definition of 'poly_store' was here
| static ssize_t poly_store(struct device_driver *dev, char *buf)
| ^~~~~~~~~~CC: stable@vger.kernel.org
Fixes: 13efe1a05384 ("dmaengine: ppc4xx: remove DRIVER_ATTR() usage")
Signed-off-by: Christian Lamparter
Signed-off-by: Vinod Koul
Signed-off-by: Greg Kroah-Hartman -
commit 076ed3da0c9b2f88d9157dbe7044a45641ae369e upstream.
commit 40413955ee26 ("Cipso: cipso_v4_optptr enter infinite loop") fixed
a possible infinite loop in the IP option parsing of CIPSO. The fix
assumes that ip_options_compile filtered out all zero length options and
that no other one-byte options beside IPOPT_END and IPOPT_NOOP exist.
While this assumption currently holds true, add explicit checks for zero
length and invalid length options to be safe for the future. Even though
ip_options_compile should have validated the options, the introduction of
new one-byte options can still confuse this code without the additional
checks.Signed-off-by: Stefan Nuernberger
Cc: David Woodhouse
Cc: Simon Veith
Cc: stable@vger.kernel.org
Acked-by: Paul Moore
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 3d71c3f1f50cf309bd20659422af549bc784bfff upstream.
The rs_rate_from_ucode_rate() function may return -EINVAL if the rate
is invalid, but none of the callsites check for the error, potentially
making us access arrays with index IWL_RATE_INVALID, which is larger
than the arrays, causing an out-of-bounds access. This will trigger
KASAN warnings, such as the one reported in the bugzilla issue
mentioned below.This fixes https://bugzilla.kernel.org/show_bug.cgi?id=200659
Cc: stable@vger.kernel.org
Signed-off-by: Luca Coelho
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman -
commit afc92514a34c7414b28047b1205a6b709103c699 upstream.
If the "workaround_for_vbus" is true, the driver will not call
usb_disconnect(). So, since the controller keeps some registers'
value, the driver doesn't re-enumarate suitable speed after
the b-device mode is disabled. To fix the issue, this patch
adds usb_disconnect() calling in renesas_usb3_b_device_write()
if workaround_for_vbus is true.Fixes: 43ba968b00ea ("usb: gadget: udc: renesas_usb3: add debugfs to set the b-device mode")
Cc: # v4.14+
Signed-off-by: Yoshihiro Shimoda
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit e28fd56ad5273be67d0fae5bedc7e1680e729952 upstream.
In rmmod path, usbip_vudc does platform_device_put() twice once from
platform_device_unregister() and then from put_vudc_device().The second put results in:
BUG kmalloc-2048 (Not tainted): Poison overwritten error or
BUG: KASAN: use-after-free in kobject_put+0x1e/0x230 if KASAN is
enabled.[ 169.042156] calling init+0x0/0x1000 [usbip_vudc] @ 1697
[ 169.042396] =============================================================================
[ 169.043678] probe of usbip-vudc.0 returned 1 after 350 usecs
[ 169.044508] BUG kmalloc-2048 (Not tainted): Poison overwritten
[ 169.044509] -----------------------------------------------------------------------------
...
[ 169.057849] INFO: Freed in device_release+0x2b/0x80 age=4223 cpu=3 pid=1693
[ 169.057852] kobject_put+0x86/0x1b0
[ 169.057853] 0xffffffffc0c30a96
[ 169.057855] __x64_sys_delete_module+0x157/0x240Fix it to call platform_device_del() instead and let put_vudc_device() do
the platform_device_put().Reported-by: Randy Dunlap
Signed-off-by: Shuah Khan (Samsung OSG)
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit 6528d88047801b80d2a5370ad46fb6eff2f509e0 upstream.
The USB core gets rightfully upset:
usb 1-1: BOGUS urb flags, 240 --> 200
WARNING: CPU: 0 PID: 60 at drivers/usb/core/urb.c:503 usb_submit_urb+0x2f8/0x3ed
Modules linked in:
CPU: 0 PID: 60 Comm: kworker/0:3 Not tainted 4.19.0-rc6-00319-g5206d00a45c7 #39
Hardware name: OLPC XO/XO, BIOS OLPC Ver 1.00.01 06/11/2014
Workqueue: events request_firmware_work_func
EIP: usb_submit_urb+0x2f8/0x3ed
Code: 75 06 8b 8f 80 00 00 00 8d 47 78 89 4d e4 89 55 e8 e8 35 1c f6 ff 8b 55 e8 56 52 8b 4d e4 51 50 68 e3 ce c7 c0 e8 ed 18 c6 ff 0b 83 c4 14 80 7d ef 01 74 0a 80 7d ef 03 0f 85 b8 00 00 00 8b
EAX: 00000025 EBX: ce7d4980 ECX: 00000000 EDX: 00000001
ESI: 00000200 EDI: ce7d8800 EBP: ce7f5ea8 ESP: ce7f5e70
DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 EFLAGS: 00210292
CR0: 80050033 CR2: 00000000 CR3: 00e80000 CR4: 00000090
Call Trace:
? if_usb_fw_timeo+0x64/0x64
__if_usb_submit_rx_urb+0x85/0xe6
? if_usb_fw_timeo+0x64/0x64
if_usb_submit_rx_urb_fwload+0xd/0xf
if_usb_prog_firmware+0xc0/0x3db
? _request_firmware+0x54/0x47b
? _request_firmware+0x89/0x47b
? if_usb_probe+0x412/0x412
lbs_fw_loaded+0x55/0xa6
? debug_smp_processor_id+0x12/0x14
helper_firmware_cb+0x3c/0x3f
request_firmware_work_func+0x37/0x6f
process_one_work+0x164/0x25a
worker_thread+0x1c4/0x284
kthread+0xec/0xf1
? cancel_delayed_work_sync+0xf/0xf
? kthread_create_on_node+0x1a/0x1a
ret_from_fork+0x2e/0x38
---[ end trace 3ef1e3b2dd53852f ]---Cc: stable@vger.kernel.org
Signed-off-by: Lubomir Rintel
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman -
commit e6111161c0a02d58919d776eec94b313bb57911f upstream.
A Xen PVH guest has no associated qemu device model, so trying to
unplug any emulated devices is making no sense at all.Bail out early from xen_unplug_emulated_devices() when running as PVH
guest. This will avoid issuing the boot message:[ 0.000000] Xen Platform PCI: unrecognised magic value
Cc: # 4.11
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman -
commit 7deecbda3026f5e2a8cc095d7ef7261a920efcf2 upstream.
While booting on an AMD EPYC box the stack canary would detect stack
overflows when using the current PVH early stack size (256). Switch to
using the value defined by BOOT_STACK_SIZE, which prevents the stack
overflow.Cc: # 4.11
Signed-off-by: Roger Pau Monné
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman -
commit a856531951dc8094359dfdac21d59cee5969c18e upstream.
xen_qlock_wait() isn't safe for nested calls due to interrupts. A call
of xen_qlock_kick() might be ignored in case a deeper nesting level
was active right before the call of xen_poll_irq():CPU 1: CPU 2:
spin_lock(lock1)
spin_lock(lock1)
-> xen_qlock_wait()
-> xen_clear_irq_pending()
Interrupt happens
spin_unlock(lock1)
-> xen_qlock_kick(CPU 2)
spin_lock_irqsave(lock2)
spin_lock_irqsave(lock2)
-> xen_qlock_wait()
-> xen_clear_irq_pending()
clears kick for lock1
-> xen_poll_irq()
spin_unlock_irq_restore(lock2)
-> xen_qlock_kick(CPU 2)
wakes up
spin_unlock_irq_restore(lock2)
IRET
resumes in xen_qlock_wait()
-> xen_poll_irq()
never wakes upThe solution is to disable interrupts in xen_qlock_wait() and not to
poll for the irq in case xen_qlock_wait() is called in nmi context.Cc: stable@vger.kernel.org
Cc: Waiman.Long@hp.com
Cc: peterz@infradead.org
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman -
commit 2ac2a7d4d9ff4e01e36f9c3d116582f6f655ab47 upstream.
In the following situation a vcpu waiting for a lock might not be
woken up from xen_poll_irq():CPU 1: CPU 2: CPU 3:
takes a spinlock
tries to get lock
-> xen_qlock_wait()
frees the lock
-> xen_qlock_kick(cpu2)
-> xen_clear_irq_pending()takes lock again
tries to get lock
-> *lock = _Q_SLOW_VAL
-> *lock == _Q_SLOW_VAL ?
-> xen_poll_irq()
frees the lock
-> xen_qlock_kick(cpu3)And cpu 2 will sleep forever.
This can be avoided easily by modifying xen_qlock_wait() to call
xen_poll_irq() only if the related irq was not pending and to call
xen_clear_irq_pending() only if it was pending.Cc: stable@vger.kernel.org
Cc: Waiman.Long@hp.com
Cc: peterz@infradead.org
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman -
commit 3aa6c19d2f38be9c6e9a8ad5fa8e3c9d29ee3c35 upstream.
Xend-based toolstacks don't have static-max entry in xenstore. The
equivalent node for those toolstacks is memory_static_max.Fixes: 5266b8e4445c (xen: fix booting ballooned down hvm guest)
Signed-off-by: Boris Ostrovsky
Cc: # 4.13
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman -
commit f92898e7f32e3533bfd95be174044bc349d416ca upstream.
If a block device is hot-added when we are out of grants,
gnttab_grant_foreign_access fails with -ENOSPC (log message "28
granting access to ring page") in this code path:talk_to_blkback ->
setup_blkring ->
xenbus_grant_ring ->
gnttab_grant_foreign_accessand the failing path in talk_to_blkback sets the driver_data to NULL:
destroy_blkring:
blkif_free(info, 0);mutex_lock(&blkfront_mutex);
free_info(info);
mutex_unlock(&blkfront_mutex);dev_set_drvdata(&dev->dev, NULL);
This results in a NULL pointer BUG when blkfront_remove and blkif_free
try to access the failing device's NULL struct blkfront_info.Cc: stable@vger.kernel.org # 4.5 and later
Signed-off-by: Vasilis Liaskovitis
Reviewed-by: Roger Pau Monné
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit e487a0f52301293152a6f8c4e217f2a11dd808e3 upstream.
Functionality of the xen-tpmfront driver was lost secondary to
the introduction of xenbus multi-page support in commit ccc9d90a9a8b
("xenbus_client: Extend interface to support multi-page ring").In this commit pointer to location of where the shared page address
is stored was being passed to the xenbus_grant_ring() function rather
then the address of the shared page itself. This resulted in a situation
where the driver would attach to the vtpm-stubdom but any attempt
to send a command to the stub domain would timeout.A diagnostic finding for this regression is the following error
message being generated when the xen-tpmfront driver probes for a
device:vtpm vtpm-0: tpm_transmit: tpm_send: error -62
vtpm vtpm-0: A TPM error (-62) occurred attempting to determine
the timeoutsThis fix is relevant to all kernels from 4.1 forward which is the
release in which multi-page xenbus support was introduced.Daniel De Graaf formulated the fix by code inspection after the
regression point was located.Fixes: ccc9d90a9a8b ("xenbus_client: Extend interface to support multi-page ring")
Signed-off-by: Dr. Greg Wettstein
Signed-off-by: Greg Kroah-Hartman[boris: Updated commit message, added Fixes tag]
Signed-off-by: Boris Ostrovsky
Cc: stable@vger.kernel.org # v4.1+
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
