IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The big top of the file comment talk about grand plans that never
happened, so remove them to not confuse the readers. Also mark the
devname and volname fields as ignored as they were never used by the
kernel.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The macro that creates both the structure and the format displayed
to user space for the stack trace event was changed a while ago
to fix the parsing by user space tooling. But this change also modified
the structure used to store the stack trace event. It changed the
caller array field from [0] to [8]. Even though the size in the ring
buffer is dynamic and can be something other than 8 (user space knows
how to handle this), the 8 extra words was not accounted for when
reserving the event on the ring buffer, and added 8 more entries, due
to the calculation of "sizeof(*entry) + nr_entries * sizeof(long)",
as the sizeof(*entry) now contains 8 entries. The size of the caller
field needs to be subtracted from the size of the entry to create
the correct allocation size.
-----BEGIN PGP SIGNATURE-----
iIoEABYIADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCYGccURQccm9zdGVkdEBn
b29kbWlzLm9yZwAKCRAp5XQQmuv6qiboAPwNM1q8A7EFLDGfj+3tXksvp4H3hXd3
ErMd2OMlsNQtRAD9GGmYyt2OtFdxZWzKOSEC07vdxq2TYTz50mqJM81YbgE=
=7hwx
-----END PGP SIGNATURE-----
Merge tag 'trace-v5.12-rc5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fix from Steven Rostedt:
"Fix stack trace entry size to stop showing garbage
The macro that creates both the structure and the format displayed to
user space for the stack trace event was changed a while ago to fix
the parsing by user space tooling. But this change also modified the
structure used to store the stack trace event. It changed the caller
array field from [0] to [8].
Even though the size in the ring buffer is dynamic and can be
something other than 8 (user space knows how to handle this), the 8
extra words was not accounted for when reserving the event on the ring
buffer, and added 8 more entries, due to the calculation of
"sizeof(*entry) + nr_entries * sizeof(long)", as the sizeof(*entry)
now contains 8 entries.
The size of the caller field needs to be subtracted from the size of
the entry to create the correct allocation size"
* tag 'trace-v5.12-rc5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Fix stack trace event size
It's non-obvious how retry is done for block backed files, when it happens
off the kiocb done path. It also makes it tricky to deal with the iov_iter
handling.
Just mark the req as needing a reissue, and handling it from the
submission path instead. This makes it directly obvious that we're not
re-importing the iovec from userspace past the submit point, and it means
that we can just reuse our usual -EAGAIN retry path from the read/write
handling.
At some point in the future, we'll gain the ability to always reliably
return -EAGAIN through the stack. A previous attempt on the block side
didn't pan out and got reverted, hence the need to check for this
information out-of-band right now.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
If IOCB_NOWAIT is set on submission, then that needs to get propagated to
REQ_NOWAIT on the block side. Otherwise we completely lose this
information, and any issuer of IOCB_NOWAIT IO will potentially end up
blocking on eg request allocation on the storage side.
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
NUMA is useless when NOMMU, and it leads some build error,
make it depend on MMU.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Eliminate the following coccicheck warning:
./arch/riscv/mm/kasan_init.c:219:2-3: Unneeded semicolon
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
In RV64, the size of each entry in excp_vect_table is 8 bytes. If the
base of the table is not 8-byte aligned, loading an entry in the table
will raise a misaligned exception. Although such exception will be
handled by opensbi/bbl, this still causes performance degradation.
Signed-off-by: Zihao Yu <yuzihao@ict.ac.cn>
Reviewed-by: Anup Patel <anup@brainfault.org>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
The <asm/uaccess.h> header has a problem with put_user(a, ptr) if
the 'a' is not a simple variable, such as a function. This can lead
to the compiler producing code as so:
1: enable_user_access()
2: evaluate 'a' into register 'r'
3: put 'r' to 'ptr'
4: disable_user_acess()
The issue is that 'a' is now being evaluated with the user memory
protections disabled. So we try and force the evaulation by assigning
'x' to __val at the start, and hoping the compiler barriers in
enable_user_access() do the job of ordering step 2 before step 1.
This has shown up in a bug where 'a' sleeps and thus schedules out
and loses the SR_SUM flag. This isn't sufficient to fully fix, but
should reduce the window of opportunity. The first instance of this
we found is in scheudle_tail() where the code does:
$ less -N kernel/sched/core.c
4263 if (current->set_child_tid)
4264 put_user(task_pid_vnr(current), current->set_child_tid);
Here, the task_pid_vnr(current) is called within the block that has
enabled the user memory access. This can be made worse with KASAN
which makes task_pid_vnr() a rather large call with plenty of
opportunity to sleep.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Reported-by: syzbot+e74b94fe601ab9552d69@syzkaller.appspotmail.com
Suggested-by: Arnd Bergman <arnd@arndb.de>
--
Changes since v1:
- fixed formatting and updated the patch description with more info
Changes since v2:
- fixed commenting on __put_user() (schwab@linux-m68k.org)
Change since v3:
- fixed RFC in patch title. Should be ready to merge.
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
The const annotation should not be used for 'sp', or it will
become read only and lead to bad stack output.
Fixes: dec822771b ("riscv: stacktrace: Move register keyword to beginning of declaration")
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
- Only perform explicit module section merges under LTO (Sean Christopherson)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEpcP2jyKd1g9yPm4TiXL039xtwCYFAmBmPJYACgkQiXL039xt
wCbUKBAAnLSVlo9+FQ8FJ+jDfMp/0oVVopNy/35/X9S1lbfsCfB1XYkPB0Y24yT6
MuPJSfmSSDXcQShQI53bahe3sHBpckwkUycKN5sUCkgIip6SW/AZzYFRO012/91N
QPAlhndT33b43JGZ+sk22ZujC4IEWvg4c4IwLmMGAUvY/lhWq/iW+oZf3HFRxU/M
dajdtgMF/6HvlPt3QNX4JmK/FQa5mR9n+JV7hE467mLM4PKxJOwMB2slmFDm5H/G
RU93gdbYnTjP9X+Be1onGvsPWpUfgfZ2D8l38O391WLMcCbLz35csQmjUlyYy5fA
2NQSgtI1oehEnnINsIheU1o9oBLglv6hq7RtCHG/QX38XQX0ULCiwi51R7jk2Dr4
52RKF7tTo4Lt4YSNfaoV+SsKGn4lFUQwoiw2OKz8OtFJdIBDX9vnButK/fBYjC93
LOhZsPnkz4Ab7iiTuMP6w4DwshyKNH9IFtYffdqRcloaKZm7StXDuXXla5G9IL/H
0KW5pz+N4ThdN8FJ9AsttrVZNMjIFWGaDo4f+4nPU8gYeh+41qnbLLQBvXx6ASXe
FAMYYAUunBtHMH3gw8Fyp5p4JtMSILFpnBoyIEKthlTNQislbMWuQOxZNwWh0SGQ
ktEUK3d77MfzFolNZ/GPYHAXk/vOWrJC2qA4KC9zJ3zzH5feHRw=
=w7Gw
-----END PGP SIGNATURE-----
Merge tag 'lto-v5.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
Pull LTO fix from Kees Cook:
"It seems that there is a bug in ld.bfd when doing module section
merging.
As explicit merging is only needed for LTO, the work-around is to only
do it under LTO, leaving the original section layout choices alone
under normal builds:
- Only perform explicit module section merges under LTO (Sean
Christopherson)"
* tag 'lto-v5.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
kbuild: lto: Merge module sections if and only if CONFIG_LTO_CLANG is enabled
Merge module sections only when using Clang LTO. With ld.bfd, merging
sections does not appear to update the symbol tables for the module,
e.g. 'readelf -s' shows the value that a symbol would have had, if
sections were not merged. ld.lld does not show this problem.
The stale symbol table breaks gdb's function disassembler, and presumably
other things, e.g.
gdb -batch -ex "file arch/x86/kvm/kvm.ko" -ex "disassemble kvm_init"
reads the wrong bytes and dumps garbage.
Fixes: dd2776222a ("kbuild: lto: merge module sections")
Cc: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210322234438.502582-1-seanjc@google.com
* Fixes for missing TLB flushes with TDP MMU
* Fixes for race conditions in nested SVM
* Fixes for lockdep splat with Xen emulation
* Fix for kvmclock underflow
* Fix srcdir != builddir builds
* Other small cleanups
ARM:
* Fix GICv3 MMIO compatibility probing
* Prevent guests from using the ARMv8.4 self-hosted tracing extension
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmBlum4UHHBib256aW5p
QHJlZGhhdC5jb20ACgkQv/vSX3jHroM5sgf9HmO3FOAhMZg6byK8lVBd5M+voNnx
0oC2EWhcT4uuEJ6MZN8CYGorHBtiMFGya5+USCINM9Te2u92jgBhqVaOsc3SRVfE
GPDbwcaSM2LP8T1Ao2ilaMSbcBEbphBrLbiBw2bToIuqDnFXUwL6psdBHyKKYRv+
LbtjfrapdB8lyll9BOhF4Iq0l74jcJEAkD/y7FlMCEgDLFCVpfbkA1HcdV/1oXsJ
+d6WKlAH9643V8HrMoX7jiXamnJVafkX2Q75Lay6xkkHtdB5wnbRFzfJGXELv9qi
6eJ7Oh5oNmrSUIrtdFkeGMdZZoJJgE9GwCXpeXM49VeqTUKkUEx9v9GAsg==
=5B67
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"It's a bit larger than I (and probably you) would like by the time we
get to -rc6, but perhaps not entirely unexpected since the changes in
the last merge window were larger than usual.
x86:
- Fixes for missing TLB flushes with TDP MMU
- Fixes for race conditions in nested SVM
- Fixes for lockdep splat with Xen emulation
- Fix for kvmclock underflow
- Fix srcdir != builddir builds
- Other small cleanups
ARM:
- Fix GICv3 MMIO compatibility probing
- Prevent guests from using the ARMv8.4 self-hosted tracing
extension"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
selftests: kvm: Check that TSC page value is small after KVM_SET_CLOCK(0)
KVM: x86: Prevent 'hv_clock->system_time' from going negative in kvm_guest_time_update()
KVM: x86: disable interrupts while pvclock_gtod_sync_lock is taken
KVM: x86: reduce pvclock_gtod_sync_lock critical sections
KVM: SVM: ensure that EFER.SVME is set when running nested guest or on nested vmexit
KVM: SVM: load control fields from VMCB12 before checking them
KVM: x86/mmu: Don't allow TDP MMU to yield when recovering NX pages
KVM: x86/mmu: Ensure TLBs are flushed for TDP MMU during NX zapping
KVM: x86/mmu: Ensure TLBs are flushed when yielding during GFN range zap
KVM: make: Fix out-of-source module builds
selftests: kvm: make hardware_disable_test less verbose
KVM: x86/vPMU: Forbid writing to MSR_F15H_PERF MSRs when guest doesn't have X86_FEATURE_PERFCTR_CORE
KVM: x86: remove unused declaration of kvm_write_tsc()
KVM: clean up the unused argument
tools/kvm_stat: Add restart delay
KVM: arm64: Fix CPU interface MMIO compatibility detection
KVM: arm64: Disable guest access to trace filter controls
KVM: arm64: Hide system instruction access to Trace registers
amdgpu:
- Polaris idle power fix
- VM fix
- Vangogh S3 fix
- Fixes for non-4K page sizes
amdkfd:
- dqm fence memory corruption fix
tegra:
- lockdep warning fix
- runtine PM reference fix
- display controller fix
- PLL Fix
imx:
- memory leak in error path fix
- LDB driver channel registration fix
- oob array warning in LDB driver
exynos
- unused header file removal
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJgZhtHAAoJEAx081l5xIa+k20P/RMY0RatSqKuQ+gqn2h2TUnp
CRwiVha5jHMB00tvJ+QLX2gD38pPrSZEXx+bqmrN0lzjxb5JIRmoGbv7+73L0jk1
Yjf42zWpdCHAP4j/M7uFCybR1hklqwUzfspZ85n/u4TQk7OOHvo7mGZPn1J1r2oW
Da+01Xu2UdxfEZVxNf34RR1TflTQ+qh+UYgRU1+Ss0Zh2im8F0EKO5b7VelOoVWK
GHNzj6NA/gSozHdh5hXdyrIibJrP4J8fQGRWEc6gTg27wa4t5hFnKfKNlRPbisb8
4apSU5PPsL6RBcqIEME42FrKkFkMqfzKz15i/iQUVHd08jMRPvYub4scqbhUWvBI
Y4vXteTbPAgKnblkdjS8xCLREi7SN2YHXYZnQmXqV4UTps37IzbZ5d/kQCKiXtKL
tYUPSAiZ9jFwq7x7ySmSvihsXWn65Jsd7K4QsxVWW0EVvsl16fl5jYRV1lyUczVU
TNj1mtCH6IPqtz4E7B5ckF1voKKOhX0zCdbMtis6+d5/l/50VRG6nt15MgOt0xm+
We9F7h9Rkty8mBxxldT2ji1lP+yQVbgIdBFEsVpU8D5Lz5GmCVtdi1aCFBUIOZGE
5W1sIYwNbpaAZ1Wg8zQdpA6LFnHhStZ95ehKevb1IxxpXOm6sovPqzBTI6UgWLyx
YDx3Z3xnTURYbpx0JD9A
=ud48
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2021-04-02' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Things have settled down in time for Easter, a random smattering of
small fixes across a few drivers.
I'm guessing though there might be some i915 and misc fixes out there
I haven't gotten yet, but since today is a public holiday here, I'm
sending this early so I can have the day off, I'll see if more
requests come in and decide what to do with them later.
amdgpu:
- Polaris idle power fix
- VM fix
- Vangogh S3 fix
- Fixes for non-4K page sizes
amdkfd:
- dqm fence memory corruption fix
tegra:
- lockdep warning fix
- runtine PM reference fix
- display controller fix
- PLL Fix
imx:
- memory leak in error path fix
- LDB driver channel registration fix
- oob array warning in LDB driver
exynos
- unused header file removal"
* tag 'drm-fixes-2021-04-02' of git://anongit.freedesktop.org/drm/drm:
drm/amdgpu: check alignment on CPU page for bo map
drm/amdgpu: Set a suitable dev_info.gart_page_size
drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in suspend
drm/amdkfd: dqm fence memory corruption
drm/tegra: sor: Grab runtime PM reference across reset
drm/tegra: dc: Restore coupling of display controllers
gpu: host1x: Use different lock classes for each client
drm/tegra: dc: Don't set PLL clock to 0Hz
drm/amdgpu: fix offset calculation in amdgpu_vm_bo_clear_mappings()
drm/amd/pm: no need to force MCLK to highest when no display connected
drm/exynos/decon5433: Remove the unused include statements
drm/imx: imx-ldb: fix out of bounds array access warning
drm/imx: imx-ldb: Register LDB channel1 when it is the only channel to be used
drm/imx: fix memory leak when fails to init
Fix a memory leak in an error path during DRM device initialization,
fix the LDB driver to register channel 1 even if channel 0 is unused,
and fix an out of bounds array access warning in the LDB driver.
-----BEGIN PGP SIGNATURE-----
iI4EABYIADYWIQRRO6F6WdpH1R0vGibVhaclGDdiwAUCYGWEMBgccGhpbGlwcC56
YWJlbEBnbWFpbC5jb20ACgkQ1YWnJRg3YsANIgD+Kb7yLjv17TC1lfEVYK8k5nDf
QKDXJJPnQm2O3KvbXDIBAPDQwEGAG3fcT1AjzahbzpntIJsqlyD0aMVSDgK4Dq4H
=jeDO
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-fixes-2021-04-01' of git://git.pengutronix.de/git/pza/linux into drm-fixes
drm/imx: imx-drm-core and imx-ldb fixes
Fix a memory leak in an error path during DRM device initialization,
fix the LDB driver to register channel 1 even if channel 0 is unused,
and fix an out of bounds array access warning in the LDB driver.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210401092235.GA13586@pengutronix.de
This contains a couple of fixes for various issues such as lockdep
warnings, runtime PM references, coupled display controllers and
misconfigured PLLs.
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmBl9PoTHHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zoYsUD/YjsgwhLKF6BWMZDOR7BFigO0guqmSL
3VHpWKjGtanp/tR8fpScfdYCyhhAWHZ/EcHqtZofUefNMjL1c7UXzZaxdcxHazWA
ygy3CP00ch+ldm0jiajTdj60hVoZ6RJEPh7R2E9gdXkpwjksJhsjhNNYR9qSej4c
HJsjOIB7cPP1Xnc6HQZm+3+jWwS4ZhMxJbZ6sS5xBxG+Pep03ZOeualM129QW91U
tbca/QZtmWwtmXaTOnm+FlzhEqVLawOuhx/oWMMckVjLBzQy0UGhulTkDIUQ64gH
gCVTfFY6t08CZIoRvLnx8dsOtJx9b4Gg454C7pBzGl0IlsNwPQnZ2NWhn2tvkJeb
S6A7V8TZtshuJ2tqZOJJqaq0fAdKFh9PI2HupdXX1RA/gS23CXXbzPTjsHxQcknm
E1WHo1cdqc/mMhPq8mZfg8OsVHt2dca7H8fBHmzsWsSo5fdwrKDEAl6HogE/XGn0
myC1IxCi/qQ3CkzezML3oh76XDY7JA09SSDYbOCwHzIv8MhJkBY+XRySVOh1zf6g
W2sWVk8QsIDG7pnlojfTrh3jRvWz99l4x1aTntX64mONte91nHxLW2Sgyk5C3emT
iIiUNV2nfuvjtL7lCI0tPqi2Wx7/YwPmVV2C4QSBMnRXF3GNCIxn10XWORZmqmBo
Ldqdstr2pceo
=fDaE
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-5.12-rc6' of ssh://git.freedesktop.org/git/tegra/linux into drm-fixes
drm/tegra: Fixes for v5.12-rc6
This contains a couple of fixes for various issues such as lockdep
warnings, runtime PM references, coupled display controllers and
misconfigured PLLs.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thierry Reding <thierry.reding@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210401163352.3348296-1-thierry.reding@gmail.com
Commit cbc3b92ce0 fixed an issue to modify the macros of the stack trace
event so that user space could parse it properly. Originally the stack
trace format to user space showed that the called stack was a dynamic
array. But it is not actually a dynamic array, in the way that other
dynamic event arrays worked, and this broke user space parsing for it. The
update was to make the array look to have 8 entries in it. Helper
functions were added to make it parse it correctly, as the stack was
dynamic, but was determined by the size of the event stored.
Although this fixed user space on how it read the event, it changed the
internal structure used for the stack trace event. It changed the array
size from [0] to [8] (added 8 entries). This increased the size of the
stack trace event by 8 words. The size reserved on the ring buffer was the
size of the stack trace event plus the number of stack entries found in
the stack trace. That commit caused the amount to be 8 more than what was
needed because it did not expect the caller field to have any size. This
produced 8 entries of garbage (and reading random data) from the stack
trace event:
<idle>-0 [002] d... 1976396.837549: <stack trace>
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify
=> 0xc8c5e150ffff93de
=> 0xffff93de
=> 0
=> 0
=> 0xc8c5e17800000000
=> 0x1f30affff93de
=> 0x00000004
=> 0x200000000
Instead, subtract the size of the caller field from the size of the event
to make sure that only the amount needed to store the stack trace is
reserved.
Link: https://lore.kernel.org/lkml/your-ad-here.call-01617191565-ext-9692@work.hours/
Cc: stable@vger.kernel.org
Fixes: cbc3b92ce0 ("tracing: Set kernel_stack's caller size properly")
Reported-by: Vasily Gorbik <gor@linux.ibm.com>
Tested-by: Vasily Gorbik <gor@linux.ibm.com>
Acked-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Things seem calming down, only usual device-specific fixes for
HD-audio and USB-audio at this time.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmBly7oOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE/XghAAueq7x3BoDukrwGjsJxUlo+Y7mZnbwDY4hiA0
58G5o/k0q4uIpZ3FcimUa66qf7zNgIgppLqMAeoCDe8ZmycPPUPWOVn9Xg7+nHLx
H9Vr1Vvy/sou4MDk8hjav+SBG06HnFFtxgjHg4CeSLNYB0zXF+U2BUyEGoXMWsP/
Dh14BoOUvFGmfZO6SCzNxtkwl/6KnKzxTYkQ3ghKfTdFBXhfVohGoH/mmS2b/0Nr
rucQJm6w7GyHxnfNaexSG4zcdAaQO0iRRHHHCeQP8/4vq4yBqgRErHT0ZDX2TT9e
yAbEfRdT+UIHZBjzWfZHy483yI3tIF7psolqqM0lMzdrFwIjvz4qdoWd7QCymEcR
Vm2th+z6vbwSntQw+yeGtpnYxpOzk/vTnExmqI1wEqqQbQiFpJqUHgp94JYmIk9r
bEDJ4PWwpsL8BgNVtWBswO0Xwc/yZrJWDBgOTdGXNFPzuHqOigwQVwGLd510i/Kf
BuUo9x8uI1hi/P9OdlWtuVH5FyAbH7rzeXi2larhcQo59X07S3FzdCx3qXvc+F0q
+NWaRDe6pE94ZuI2l8xEV5HKQZAlblNBK/2PwFN5vDAvb+MPsPSp6ViTenpOjS8p
+8V3rfx3R7yLgDiNMjKCoNaxfSaPcBUtd2K5tYk4orF9aDZ7fe4//9NTl6RPEB72
IhQ9Mt0=
=TYaf
-----END PGP SIGNATURE-----
Merge tag 'sound-5.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Things seem calming down, only usual device-specific fixes for
HD-audio and USB-audio at this time"
* tag 'sound-5.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda/realtek: fix mute/micmute LEDs for HP 640 G8
ALSA: hda: Add missing sanity checks in PM prepare/complete callbacks
ALSA: hda: Re-add dropped snd_poewr_change_state() calls
ALSA: usb-audio: Apply sample rate quirk to Logitech Connect
ALSA: hda/realtek: call alc_update_headset_mode() in hp_automute_hook
ALSA: hda/realtek: fix a determine_headset_type issue for a Dell AIO
tomoyo: don't special case PF_IO_WORKER for PF_KTHREAD
security/tomoyo/network.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJgZdFiAAoJEEJfEo0MZPUqWLwP+gOJ3o561s0SiCKQ0AHU5eTO
d5AgzneRvn0NCiQDNyz+zlii0h8rfJAkwtFB6mwOyJnX/G5SmSG10yiS2Ze347ZZ
9oTFwmAVODfRNq4a9IHWCadXGVR+8zY1h8eLpszid7sIpYiByjigX2sAzhrxsH2A
xdV8u2kQfHAjzcUeX1BjJK/8MNWyFBZD6pNThve8gLIDdo+XY7CZ2G0vOOJ3JVK2
00rciV4+4BprcF/I9lRyWQ5uvpWp0nMcSslLRb0wMgqFmrea73Fro3H/k2VDNJtn
/rU6XPvNCxYNtrndxDFPCRc5Sx6Sgtw8rZChrYlZbSO8kT3uSTJr3DJ8lBgifbcX
skqvby3XlDcJ3qHmExI1PatDJeYDyB+j+X7TpBAkgXE+6i4PLERq/nAb35vYTkK7
q2EobOatNu4Maz3zgRwdgmht3Wz2xSO4tXfD8/CoevBfwaH9wvYGEFMdkacxgJ8T
ebobXgj5dD8Nywsyf6vFlHtKzkTx1E+glJsAEkWCnj6fzQMt38YNwQGwCAM2Pzpc
F1GhZT81YKxpzsLpHfH37yzNcjAsl4wcQena9K5b9AduRsXBV2RnTzDK/jcr8wTW
fh6fZ5hw7tG36hgt4p0T0HN4SqTIJbu7QcXUuohOZuJVXymUbS9RDtX8lC5F+TXt
NCe0CR48IziYGdxkzbM4
=7qgt
-----END PGP SIGNATURE-----
Merge tag 'tomoyo-pr-20210401' of git://git.osdn.net/gitroot/tomoyo/tomoyo-test1
Pull tomory fix from Tetsuo Handa:
"An update on 'tomoyo: recognize kernel threads correctly' from Jens
Axboe to not special case PF_IO_WORKER for PF_KTHREAD"
* tag 'tomoyo-pr-20210401' of git://git.osdn.net/gitroot/tomoyo/tomoyo-test1:
tomoyo: don't special case PF_IO_WORKER for PF_KTHREAD
- Fix a bug when splitting to a non-zero order
- Documentation fix
- Add a predefined 16-bit allocation limit
- Various test suite fixes
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEejHryeLBw/spnjHrDpNsjXcpgj4FAmBlv+kACgkQDpNsjXcp
gj7lYAf/R0dG7V5LdZaHVLTIE9lgWDn1U5ISTw9HuRgpFf9RUDEY6LnnPNa5TkWS
OqVKGyhHOUYmJr4ImsuXssTXq2vaUBvR1ojf+/gst/rsaAoCFEsKMl8ZIZz95tz8
hzDUXV/rd5s7ZUXkKTuuZRBxqj4r5VW8KDdheboM6wGtrd6iXFC1JFG/DL/EbHDd
XZVZ0i3+nqB0CO2SG1uyE9m38En69jB5498Q4SPUDqYAw2+7XZWRT7qPPUnCPXJD
bgHZUf4XEG6xOjTV8AfPYhWTZ99d6gD1vYhxxSAmLKCHla+2Wd8lYLvSHFh+QXhs
WYyhsHsculb9BGdmXCTwYrJn6qZKMw==
=p+yt
-----END PGP SIGNATURE-----
Merge tag 'xarray-5.12' of git://git.infradead.org/users/willy/xarray
Pull XArray fixes from Matthew Wilcox:
"My apologies for the lateness of this. I had a bug reported in the
test suite, and when I started working on it, I realised I had two
fixes sitting in the xarray tree since last November. Anyway,
everything here is fixes, apart from adding xa_limit_16b. The test
suite passes.
Summary:
- Fix a bug when splitting to a non-zero order
- Documentation fix
- Add a predefined 16-bit allocation limit
- Various test suite fixes"
* tag 'xarray-5.12' of git://git.infradead.org/users/willy/xarray:
idr test suite: Improve reporting from idr_find_test_1
idr test suite: Create anchor before launching throbber
idr test suite: Take RCU read lock in idr_find_test_1
radix tree test suite: Register the main thread with the RCU library
radix tree test suite: Fix compilation
XArray: Add xa_limit_16b
XArray: Fix splitting to non-zero orders
XArray: Fix split documentation
iov_iter_revert() is done in completion handlers that happensf before
read/write returns -EIOCBQUEUED, no need to repeat reverting afterwards.
Moreover, even though it may appear being just a no-op, it's actually
races with 1) user forging a new iovec of a different size 2) reissue,
that is done via io-wq continues completely asynchronously.
Fixes: 3e6a0d3c75 ("io_uring: fix -EAGAIN retry with IOPOLL")
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
task_pid may be large enough to not fit into the left space of
TASK_COMM_LEN-sized buffers and overflow in sprintf. We not so care
about uniqueness, so replace it with safer snprintf().
Reported-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://lore.kernel.org/r/1702c6145d7e1c46fbc382f28334c02e1a3d3994.1617267273.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
S_ISBLK is marked as unbounded work for async preparation, because it
doesn't match S_ISREG. That is incorrect, as any read/write to a block
device is also a bounded operation. Fix it up and ensure that S_ISBLK
isn't marked unbounded.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Memory backed or zoned null block devices may generate actual request
timeout errors due to the submission path being blocked on memory
allocation or zone locking. Unlike fake timeouts or injected timeouts,
the request submission path will call blk_mq_complete_request() or
blk_mq_end_request() for these real timeout errors, causing a double
completion and use after free situation as the block layer timeout
handler executes blk_mq_rq_timed_out() and __blk_mq_free_request() in
blk_mq_check_expired(). This problem often triggers a NULL pointer
dereference such as:
BUG: kernel NULL pointer dereference, address: 0000000000000050
RIP: 0010:blk_mq_sched_mark_restart_hctx+0x5/0x20
...
Call Trace:
dd_finish_request+0x56/0x80
blk_mq_free_request+0x37/0x130
null_handle_cmd+0xbf/0x250 [null_blk]
? null_queue_rq+0x67/0xd0 [null_blk]
blk_mq_dispatch_rq_list+0x122/0x850
__blk_mq_do_dispatch_sched+0xbb/0x2c0
__blk_mq_sched_dispatch_requests+0x13d/0x190
blk_mq_sched_dispatch_requests+0x30/0x60
__blk_mq_run_hw_queue+0x49/0x90
process_one_work+0x26c/0x580
worker_thread+0x55/0x3c0
? process_one_work+0x580/0x580
kthread+0x134/0x150
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x1f/0x30
This problem very often triggers when running the full btrfs xfstests
on a memory-backed zoned null block device in a VM with limited amount
of memory.
Avoid this by executing blk_mq_complete_request() in null_timeout_rq()
only for commands that are marked for a fake timeout completion using
the fake_timeout boolean in struct null_cmd. For timeout errors injected
through debugfs, the timeout handler will execute
blk_mq_complete_request()i as before. This is safe as the submission
path does not execute complete requests in this case.
In null_timeout_rq(), also make sure to set the command error field to
BLK_STS_TIMEOUT and to propagate this error through to the request
completion.
Reported-by: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Tested-by: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
Reviewed-by: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
Link: https://lore.kernel.org/r/20210331225244.126426-1-damien.lemoal@wdc.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Instead of just reporting an assertion failure, report enough information
that we can start diagnosing exactly went wrong.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
The throbber could race with creation of the anchor entry and cause the
IDR to have zero entries in it, which would cause the test to fail.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
When run on a single CPU, this test would frequently access already-freed
memory. Due to timing, this bug never showed up on multi-CPU tests.
Reported-by: Chris von Recklinghausen <crecklin@redhat.com>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Several test runners register individual worker threads with the
RCU library, but neglect to register the main thread, which can lead
to objects being freed while the main thread is in what appears to be
an RCU critical section.
Reported-by: Chris von Recklinghausen <crecklin@redhat.com>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Commit 496121c021 ("ACPI: processor: idle: Allow probing on platforms
with one ACPI C-state") broke CPU0 hotplug on certain systems, e.g.
I'm observing the following on AWS Nitro (e.g r5b.xlarge but other
instance types are affected as well):
# echo 0 > /sys/devices/system/cpu/cpu0/online
# echo 1 > /sys/devices/system/cpu/cpu0/online
<10 seconds delay>
-bash: echo: write error: Input/output error
In fact, the above mentioned commit only revealed the problem and did
not introduce it. On x86, to wakeup CPU an NMI is being used and
hlt_play_dead()/mwait_play_dead() loops are prepared to handle it:
/*
* If NMI wants to wake up CPU0, start CPU0.
*/
if (wakeup_cpu0())
start_cpu0();
cpuidle_play_dead() -> acpi_idle_play_dead() (which is now being called on
systems where it wasn't called before the above mentioned commit) serves
the same purpose but it doesn't have a path for CPU0. What happens now on
wakeup is:
- NMI is sent to CPU0
- wakeup_cpu0_nmi() works as expected
- we get back to while (1) loop in acpi_idle_play_dead()
- safe_halt() puts CPU0 to sleep again.
The straightforward/minimal fix is add the special handling for CPU0 on x86
and that's what the patch is doing.
Fixes: 496121c021 ("ACPI: processor: idle: Allow probing on platforms with one ACPI C-state")
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: 5.10+ <stable@vger.kernel.org> # 5.10+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add a test for the issue when KVM_SET_CLOCK(0) call could cause
TSC page value to go very big because of a signedness issue around
hv_clock->system_time.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210326155551.17446-3-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When guest time is reset with KVM_SET_CLOCK(0), it is possible for
'hv_clock->system_time' to become a small negative number. This happens
because in KVM_SET_CLOCK handling we set 'kvm->arch.kvmclock_offset' based
on get_kvmclock_ns(kvm) but when KVM_REQ_CLOCK_UPDATE is handled,
kvm_guest_time_update() does (masterclock in use case):
hv_clock.system_time = ka->master_kernel_ns + v->kvm->arch.kvmclock_offset;
And 'master_kernel_ns' represents the last time when masterclock
got updated, it can precede KVM_SET_CLOCK() call. Normally, this is not a
problem, the difference is very small, e.g. I'm observing
hv_clock.system_time = -70 ns. The issue comes from the fact that
'hv_clock.system_time' is stored as unsigned and 'system_time / 100' in
compute_tsc_page_parameters() becomes a very big number.
Use 'master_kernel_ns' instead of get_kvmclock_ns() when masterclock is in
use and get_kvmclock_base_ns() when it's not to prevent 'system_time' from
going negative.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210331124130.337992-2-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
pvclock_gtod_sync_lock can be taken with interrupts disabled if the
preempt notifier calls get_kvmclock_ns to update the Xen
runstate information:
spin_lock include/linux/spinlock.h:354 [inline]
get_kvmclock_ns+0x25/0x390 arch/x86/kvm/x86.c:2587
kvm_xen_update_runstate+0x3d/0x2c0 arch/x86/kvm/xen.c:69
kvm_xen_update_runstate_guest+0x74/0x320 arch/x86/kvm/xen.c:100
kvm_xen_runstate_set_preempted arch/x86/kvm/xen.h:96 [inline]
kvm_arch_vcpu_put+0x2d8/0x5a0 arch/x86/kvm/x86.c:4062
So change the users of the spinlock to spin_lock_irqsave and
spin_unlock_irqrestore.
Reported-by: syzbot+b282b65c2c68492df769@syzkaller.appspotmail.com
Fixes: 30b5c851af ("KVM: x86/xen: Add support for vCPU runstate information")
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
There is no need to include changes to vcpu->requests into
the pvclock_gtod_sync_lock critical section. The changes to
the shared data structures (in pvclock_update_vm_gtod_copy)
already occur under the lock.
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fixing nested_vmcb_check_save to avoid all TOC/TOU races
is a bit harder in released kernels, so do the bare minimum
by avoiding that EFER.SVME is cleared. This is problematic
because svm_set_efer frees the data structures for nested
virtualization if EFER.SVME is cleared.
Also check that EFER.SVME remains set after a nested vmexit;
clearing it could happen if the bit is zero in the save area
that is passed to KVM_SET_NESTED_STATE (the save area of the
nested state corresponds to the nested hypervisor's state
and is restored on the next nested vmexit).
Cc: stable@vger.kernel.org
Fixes: 2fcf4876ad ("KVM: nSVM: implement on demand allocation of the nested state")
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Avoid races between check and use of the nested VMCB controls. This
for example ensures that the VMRUN intercept is always reflected to the
nested hypervisor, instead of being processed by the host. Without this
patch, it is possible to end up with svm->nested.hsave pointing to
the MSR permission bitmap for nested guests.
This bug is CVE-2021-29657.
Reported-by: Felix Wilhelm <fwilhelm@google.com>
Cc: stable@vger.kernel.org
Fixes: 2fcf4876ad ("KVM: nSVM: implement on demand allocation of the nested state")
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- This header file isn't used anymore so drop it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJgYbbvAAoJEFc4NIkMQxK4KMYQALXOVKqGu8fgQXct3lyIn9cK
lvFkrWv03v5DYdyHio7XR8egFzRMKw0XENYzAM0CAaUsVApOgi63puZrtyO5+taW
++Ai3oclCrGvwEWXhxx6jGEPUPaPPrD8sQF60+3bOxbAGDxHk99RhEHvYwIQbQzD
5ZJa3V2K7xiBmnnXP2mlm5qNSVC0c8rRWtf5rXjRHcAfaWHy9gqScaXqwn/9KKZy
Nrf5dsV3vxG9F+HdoWyKIdvhGfVrjdIldkLBtCn2P3n0aHJXAeqpoK1K6JpVIFtO
mJPHwB9XwZZ/I2jxXBpATU70C50SAKgFd0bS5f6caZOZJHw1S+VkocgcOqLZA4Kz
7QnaMJfef2MkSK/1I3XsLgissd+4GsnghNt8t5lF6+vNuTTEcqY+k/eL+2xpXzaF
lKtXqTgL3+JKlCibYUK0ZCGa7M3cGGWjmSSUsXTo2jWY7GqlT5T6lB0YOp8fmr8P
7IQEm3l1gNCgFpF8S2mbIHbWKRlv/Bm0oTbUixAPMojLYjIPC48YZ7qZZ5WwPcSz
CB+y2F+QkIDR1Du8Ys8cacNgedVfSZz3SGdJ8pnpTI5UkzGWvgzqTwnqRumNmPUb
uzAtmA9Fi43f/DWgNqsA5FPODtDin3ubU8/JwGKlNEYgJfrXYga4trINOAqCjKoJ
sHgi5Ekd8ZzVsf9CPWRe
=Rp8S
-----END PGP SIGNATURE-----
Merge tag 'exynos-drm-fixes-for-v5.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
Just one cleanup which drops of_gpio.h inclusion.
- This header file isn't used anymore so drop it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Inki Dae <inki.dae@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1617016858-14081-1-git-send-email-inki.dae@samsung.com
The page table of AMDGPU requires an alignment to CPU page so we should
check ioctl parameters for it. Return -EINVAL if some parameter is
unaligned to CPU page, instead of corrupt the page table sliently.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Xi Ruoyao <xry111@mengyan1223.wang>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
In Mesa, dev_info.gart_page_size is used for alignment and it was
set to AMDGPU_GPU_PAGE_SIZE(4KB). However, the page table of AMDGPU
driver requires an alignment on CPU pages. So, for non-4KB page system,
gart_page_size should be max_t(u32, PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE).
Signed-off-by: Rui Wang <wangr@lemote.com>
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Link: https://github.com/loongson-community/linux-stable/commit/caa9c0a1
[Xi: rebased for drm-next, use max_t for checkpatch,
and reworded commit message.]
Signed-off-by: Xi Ruoyao <xry111@mengyan1223.wang>
BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1549
Tested-by: Dan Horák <dan@danny.cz>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Do the same thing we do for Renoir. We can check, but since
the sbios has started DPM, it will always return true which
causes the driver to skip some of the SMU init when it shouldn't.
Reviewed-by: Zhan Liu <zhan.liu@amd.com>
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Amdgpu driver uses 4-byte data type as DQM fence memory,
and transmits GPU address of fence memory to microcode
through query status PM4 message. However, query status
PM4 message definition and microcode processing are all
processed according to 8 bytes. Fence memory only allocates
4 bytes of memory, but microcode does write 8 bytes of memory,
so there is a memory corruption.
Changes since v1:
* Change dqm->fence_addr as a u64 pointer to fix this issue,
also fix up query_status and amdkfd_fence_wait_timeout function
uses 64 bit fence value to make them consistent.
Signed-off-by: Qu Huang <jinsdb@126.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
For multiple split bios, if one of the bio is fail, the whole
should return error to application. But we found there is a race
between bio_integrity_verify_fn and bio complete, which return
io success to application after one of the bio fail. The race as
following:
split bio(READ) kworker
nvme_complete_rq
blk_update_request //split error=0
bio_endio
bio_integrity_endio
queue_work(kintegrityd_wq, &bip->bip_work);
bio_integrity_verify_fn
bio_endio //split bio
__bio_chain_endio
if (!parent->bi_status)
<interrupt entry>
nvme_irq
blk_update_request //parent error=7
req_bio_endio
bio->bi_status = 7 //parent bio
<interrupt exit>
parent->bi_status = 0
parent->bi_end_io() // return bi_status=0
The bio has been split as two: split and parent. When split
bio completed, it depends on kworker to do endio, while
bio_integrity_verify_fn have been interrupted by parent bio
complete irq handler. Then, parent bio->bi_status which have
been set in irq handler will overwrite by kworker.
In fact, even without the above race, we also need to conside
the concurrency beteen mulitple split bio complete and update
the same parent bi_status. Normally, multiple split bios will
be issued to the same hctx and complete from the same irq
vector. But if we have updated queue map between multiple split
bios, these bios may complete on different hw queue and different
irq vector. Then the concurrency update parent bi_status may
cause the final status error.
Suggested-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20210331115359.1125679-1-yuyufen@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The function addresses that are traced by ftrace are stored in pages,
and the size is held in a variable. If there's some error in creating
them, the allocate ones will be freed. In this case, it is possible that
the order of pages to be freed may end up being negative due to a size of
zero passed to get_count_order(), and then that negative number will cause
free_pages() to free a very large section. Make sure that does not happen.
-----BEGIN PGP SIGNATURE-----
iIoEABYIADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCYGR30BQccm9zdGVkdEBn
b29kbWlzLm9yZwAKCRAp5XQQmuv6qnbDAP9yEhTLcDRUi3VLWnEq19Dt4Lsg86Bf
QRpbWG6Ze9EbZQEAgYAOe1fsNCNEIMXXh/4nlKVpKKH+vviS0ux9Z6uhpQQ=
=Veyq
-----END PGP SIGNATURE-----
Merge tag 'trace-v5.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull ftrace fix from Steven Rostedt:
"Add check of order < 0 before calling free_pages()
The function addresses that are traced by ftrace are stored in pages,
and the size is held in a variable. If there's some error in creating
them, the allocate ones will be freed. In this case, it is possible
that the order of pages to be freed may end up being negative due to a
size of zero passed to get_count_order(), and then that negative
number will cause free_pages() to free a very large section.
Make sure that does not happen"
* tag 'trace-v5.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
ftrace: Check if pages were allocated before calling free_pages()
- Fix up some Intel GPIO base calculations.
- Fix a register offset in the Microchip driver.
- Fix suspend/resume bug in the Rockchip driver.
- Default pull up strength in the Qualcomm LPASS
driver.
- Fix two pingroup offsets in the Qualcomm SC7280
driver.
- Fix SDC1 register offset in the Qualcomm SC7280
driver.
- Fix a nasty string concatenation in the
Qualcomm SDX55 driver.
- Check the REVID register to see if the device is
real or virtualized during virtualization in the
Intel driver.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAmBkalgACgkQQRCzN7AZ
XXMY/g/+OUZm+mT0DR0AFDW7UkMytns0Zgt7Zk9V6W5rytW7731LNCC5CRF1F3kI
iZiutqNfe7uDWop5yo1ub8UqCxBtgrJADzXT4uTGid11jQrsfwUjZEqjlW1J4oHz
Y4cfmLCPtuB4rA1GrISqYQ2s2YO2+kdFVdL8ZrhFQug5GEOJrtmjAYvTU1GshaLH
9oxd7bg5QV2ZmzAQoH7tScqUi+60u7CqWLBJzuW6/qIBCBpYxc6NFLlfPbuqJbyb
NuJeRl+e7OA2tQE5CR4ymQyuoz7iGCrgsDIOi7maADDTJQEW/RPG9565qzqQxCgv
UFt1sqodgegEgXLRNJG6Y9zO1qktCzDHJGNFyH9EZ2FHVKox+Gicf8TxYM3ulHca
az/qs+MXH32YdLr//lg6XvogAMjnl3nXeq9j1U7nunki4N93oxBhq89d5qBcyZSP
/3D53HViq6EEcBnChAZ64SY21Ro7HNzE6x5bOSL2HPsWy9B8U5jRgAkHxPjd8/Vr
LF5EPblI+bZc8fOxAi9ifMu9OROB+I5ZUm00zYzucJUKoMtrkAkObW9/GS88vpwN
j6uAAr/WFlWaXpKynIxyME3zPuhoyZHFlSnI8LI3UTBiZtFsxoMWbVP1OVkbK6bc
kUtQUPsE0T4OowYa+ulYet+US/LucmVn7KgTFGOodSKtpxHU7Mk=
=+Gsn
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v5.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Some overly ripe fixes for the v5.12 kernel. I should have sent
earlier but had my head stuck in GDB.
All are driver fixes:
- Fix up some Intel GPIO base calculations.
- Fix a register offset in the Microchip driver.
- Fix suspend/resume bug in the Rockchip driver.
- Default pull up strength in the Qualcomm LPASS driver.
- Fix two pingroup offsets in the Qualcomm SC7280 driver.
- Fix SDC1 register offset in the Qualcomm SC7280 driver.
- Fix a nasty string concatenation in the Qualcomm SDX55 driver.
- Check the REVID register to see if the device is real or
virtualized during virtualization in the Intel driver"
* tag 'pinctrl-v5.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: intel: check REVID register value for device presence
pinctrl: qcom: fix unintentional string concatenation
pinctrl: qcom: sc7280: Fix SDC1_RCLK configurations
pinctrl: qcom: sc7280: Fix SDC_QDSD_PINGROUP and UFS_RESET offsets
pinctrl: qcom: lpass lpi: use default pullup/strength values
pinctrl: rockchip: fix restore error in resume
pinctrl: microchip-sgpio: Fix wrong register offset for IRQ trigger
pinctrl: intel: Show the GPIO base calculation explicitly
syzbot is reporting NULL pointer dereference at reiserfs_security_init()
[1], for commit ab17c4f021 ("reiserfs: fixup xattr_root caching")
is assuming that REISERFS_SB(s)->xattr_root != NULL in
reiserfs_xattr_jcreate_nblocks() despite that commit made
REISERFS_SB(sb)->priv_root != NULL && REISERFS_SB(s)->xattr_root == NULL
case possible.
I guess that commit 6cb4aff0a7 ("reiserfs: fix oops while creating
privroot with selinux enabled") wanted to check xattr_root != NULL
before reiserfs_xattr_jcreate_nblocks(), for the changelog is talking
about the xattr root.
The issue is that while creating the privroot during mount
reiserfs_security_init calls reiserfs_xattr_jcreate_nblocks which
dereferences the xattr root. The xattr root doesn't exist, so we get
an oops.
Therefore, update reiserfs_xattrs_initialized() to check both the
privroot and the xattr root.
Link: https://syzkaller.appspot.com/bug?id=8abaedbdeb32c861dc5340544284167dd0e46cde # [1]
Reported-and-tested-by: syzbot <syzbot+690cb1e51970435f9775@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fixes: 6cb4aff0a7 ("reiserfs: fix oops while creating privroot with selinux enabled")
Acked-by: Jeff Mahoney <jeffm@suse.com>
Acked-by: Jan Kara <jack@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Don't call into get_signal() with the sqd mutex held, it'll fail if we're
freezing the task and we'll get complaints on locks still being held:
====================================
WARNING: iou-sqp-8386/8387 still has locks held!
5.12.0-rc4-syzkaller #0 Not tainted
------------------------------------
1 lock held by iou-sqp-8386/8387:
#0: ffff88801e1d2470 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread+0x24c/0x13a0 fs/io_uring.c:6731
stack backtrace:
CPU: 1 PID: 8387 Comm: iou-sqp-8386 Not tainted 5.12.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
try_to_freeze include/linux/freezer.h:66 [inline]
get_signal+0x171a/0x2150 kernel/signal.c:2576
io_sq_thread+0x8d2/0x13a0 fs/io_uring.c:6748
Fold the get_signal() case in with the parking checks, as we need to drop
the lock in both cases, and since we need to be checking for parking when
juggling the lock anyway.
Reported-by: syzbot+796d767eb376810256f5@syzkaller.appspotmail.com
Fixes: dbe1bdbb39 ("io_uring: handle signals for IO threads like a normal thread")
Signed-off-by: Jens Axboe <axboe@kernel.dk>