30 Dec, 2020
40 commits
-
commit 34cdf405aa5de827b8bef79a6c82c39120b3729b upstream.
Acer TravelMate laptops P648/P658 series with codec ALC282 only have
one physical jack for headset but there's a confusing lineout pin on
NID 0x1b reported. Audio applications hence misunderstand that there
are a speaker and a lineout, and take the lineout as the default audio
output.Add a new quirk to remove the useless lineout and enable the pin 0x18
for jack sensing and headset microphone.Signed-off-by: Chris Chiu
Signed-off-by: Jian-Hong Pan
Cc:
Link: https://lore.kernel.org/r/20201216125200.27053-1-chiu@endlessos.org
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 6ca653e3f73a1af0f30dbf9c2c79d2897074989f upstream.
The Quanta NL3 laptop has both a headphone output jack and a headset
jack, on the right edge of the chassis.The pin information suggests that both of these are at the Front.
The PulseAudio is confused to differentiate them so one of the jack
can neither get the jack sense working nor the audio output.The ALC269_FIXUP_LIFEBOOK chained with ALC269_FIXUP_QUANTA_MUTE can
help to differentiate 2 jacks and get the 'Auto-Mute Mode' working
correctly.Signed-off-by: Chris Chiu
Cc:
Link: https://lore.kernel.org/r/20201222150459.9545-1-chiu@endlessos.org
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 09926202e939fd699650ac0fc0baa5757e069390 upstream.
MSI-GP73 (with SSID 1462:1229) requires yet again
ALC1220_FIXUP_CLEVO_P950 quirk like other MSI models.BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210793
Cc:
Link: https://lore.kernel.org/r/20201220080943.24839-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 13be30f156fda725b168ac89fc91f78651575307 upstream.
This Acer Veriton N4640G/N6640G/N2510G desktops have 2 headphone
jacks(front and rear), and a separate Mic In jack.The rear headphone jack is actually a line out jack but always silent
while playing audio. The front 'Mic In' also fails the jack sensing.
Apply the ALC269_FIXUP_LIFEBOOK to have all audio jacks to work as
expected.Signed-off-by: Chris Chiu
Signed-off-by: Jian-Hong Pan
Cc:
Link: https://lore.kernel.org/r/20201222150459.9545-2-chiu@endlessos.org
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 11cb881bf075cea41092a20236ba708b18e1dbb2 upstream.
There are a few places that call round{up|down}_pow_of_two() with the
value zero, and this causes undefined behavior warnings. Avoid
calling those macros if such a nonsense value is passed; it's a minor
optimization as well, as we handle it as either an error or a value to
be skipped, instead.Reported-by: syzbot+33ef0b6639a8d2d42b4c@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20201218161730.26596-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 607184cb1635eaee239fe3fb9648a8b82a5232d7 upstream.
Add supported for more Lenovo ALC285 Headset Button.
Signed-off-by: Kailang Yang
Cc:
Link: https://lore.kernel.org/r/bb1f1da1526d460885aa4257be81eb94@realtek.com
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 7e413528474d5895e3e315c019fb0c43522eb6d9 upstream.
The ASUS laptop Q524UQK with ALC255 codec can't detect the headset
microphone until ALC255_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.Signed-off-by: Chris Chiu
Signed-off-by: Jian-Hong Pan
Cc:
Link: https://lore.kernel.org/r/20201209045730.9972-1-chiu@endlessos.org
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 5cfca59604e423f720297e30a9dc493eea623493 upstream.
The ASUS laptop X430UN with ALC256 can't detect the headset microphone
until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.Signed-off-by: Chris Chiu
Signed-off-by: Jian-Hong Pan
Cc:
Link: https://lore.kernel.org/r/20201207072755.16210-1-chiu@endlessos.org
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit c72b9bfe0f914639cc475585f45722a3eb57a56d upstream.
This change could fix 2 issues on this machine:
- the bass speaker's output volume can't be adjusted, that is because
the bass speaker is routed to the DAC (Nid 0x6) which has no volume
control.
- after plugging a headset with vol+, vol- and pause buttons on it,
press those buttons, nothing happens, this means those buttons
don't work at all. This machine has alc287 codec, need to add the
codec id to the disable/enable_headset_jack_key(), then the headset
button could work.The quirk of ALC285_FIXUP_THINKPAD_HEADSET_JACK could fix both of these
2 issues.Cc:
Signed-off-by: Hui Wang
Link: https://lore.kernel.org/r/20201205051130.8122-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit c697ba85a94b8f65bf90dec5ef9af5c39c3e73b2 upstream.
The Windows driver sets the pincfg for the AE-5's rear-headphone to
report as a microphone. This causes issues with Pulseaudio mistakenly
believing there is no headphone plugged in. In Linux, we should instead
set it to be a headphone.Fixes: a6b0961b39896 ("ALSA: hda/ca0132 - fix AE-5 pincfg")
Cc:
Signed-off-by: Connor McAdams
Link: https://lore.kernel.org/r/20201208195223.424753-1-conmanx360@gmail.com
Link: https://lore.kernel.org/r/20201210173550.2968-1-conmanx360@gmail.com
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 2506318e382c4c7daa77bdc48f80a0ee82804588 upstream.
It seems that the HD-audio clear and reconfig sysfs don't work any
longer after the recent driver core change. There are multiple issues
around that: the linked list corruption and the dead device handling.
The former issue is fixed by another patch for the driver core itself,
while the latter patch needs to be addressed in HD-audio side.This patch corresponds to the latter, it recovers those broken
functions by replacing the device detach and attach actions with the
standard core API functions, which are almost equivalent with unbind
and bind actions.Fixes: 654888327e9f ("driver core: Avoid binding drivers to dead devices")
Cc:
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209207
Link: https://lore.kernel.org/r/20201209150119.7705-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit b08221c40febcbda9309dd70c61cf1b0ebb0e351 upstream.
Recently we met a touchscreen problem on some Thinkpad machines, the
touchscreen driver (i2c-hid) is not loaded and the touchscreen can't
work.An i2c ACPI device with the name WACF2200 is defined in the BIOS, with
the current rule in matching_id(), this device will be regarded as
a PNP device since there is WACFXXX in the acpi_pnp_device_ids[] and
this PNP device is attached to the acpi device as the 1st
physical_node, this will make the i2c bus match fail when i2c bus
calls acpi_companion_match() to match the acpi_id_table in the i2c-hid
driver.WACF2200 is an i2c device instead of a PNP device, after adding the
string length comparing, the matching_id() will return false when
matching WACF2200 and WACFXXX, and it is reasonable to compare the
string length when matching two IDs.Suggested-by: Rafael J. Wysocki
Signed-off-by: Hui Wang
Cc: All applicable
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 12fc4dad94dfac25599f31257aac181c691ca96f upstream.
This reverts commit 8a66790b7850a6669129af078768a1d42076a0ef.
Switching this function to AE_CTRL_TERMINATE broke the documented
behaviour of acpi_dev_get_resources() - AE_CTRL_TERMINATE does not, in
fact, terminate the resource walk because acpi_walk_resource_buffer()
ignores it (specifically converting it to AE_OK), referring to that
value as "an OK termination by the user function". This means that
acpi_dev_get_resources() does not abort processing when the preproc
function returns a negative value.Signed-off-by: Daniel Scally
Cc: 3.10+ # 3.10+
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 7482c5cb90e5a7f9e9e12dd154d405e0219656e3 upstream.
The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to
be reference counted for wakeup enabling, because they may be enabled
to signal wakeup on behalf of their subordinate devices and that
may happen for multiple times in a row, whereas for the other devices
it only makes sense to enable wakeup signaling once.However, this becomes problematic if the bridge itself is suspended,
because it is treated as a "regular" device in that case and the
reference counting doesn't work.For instance, suppose that there are two devices below a bridge and
they both can signal wakeup. Every time one of them is suspended,
wakeup signaling is enabled for the bridge, so when they both have
been suspended, the bridge's wakeup reference counter value is 2.Say that the bridge is suspended subsequently and acpi_pci_wakeup()
is called for it. Because the bridge can signal wakeup, that
function will invoke acpi_pm_set_device_wakeup() to configure it
and __acpi_pm_set_device_wakeup() will be called with the last
argument equal to 1. This causes __acpi_device_wakeup_enable()
invoked by it to omit the reference counting, because the reference
counter of the target device (the bridge) is 2 at that time.Now say that the bridge resumes and one of the device below it
resumes too, so the bridge's reference counter becomes 0 and
wakeup signaling is disabled for it, but there is still the other
suspended device which may need the bridge to signal wakeup on its
behalf and that is not going to work.To address this scenario, use wakeup enable reference counting for
all devices, not just for bridges, so drop the last argument from
__acpi_device_wakeup_enable() and __acpi_pm_set_device_wakeup(),
which causes acpi_pm_set_device_wakeup() and
acpi_pm_set_bridge_wakeup() to become identical, so drop the latter
and use the former instead of it everywhere.Fixes: 1ba51a7c1496 ("ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()")
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Mika Westerberg
Acked-by: Bjorn Helgaas
Cc: 4.14+ # 4.14+
Signed-off-by: Greg Kroah-Hartman -
commit 9a7e3d7f056831a6193d6d737fb7a26dfdceb04b upstream.
Dan reports that smatch thinks userspace can craft an out-of-bound bus
family number. However, nd_cmd_clear_to_send() blocks all non-zero
values of bus-family since only the kernel can initiate these commands.
However, in the speculation path, family is a user controlled array
index value so mask it for speculation safety. Also, since the
nd_cmd_clear_to_send() safety is non-obvious and possibly may change in
the future include input validation as if userspace could get past the
nd_cmd_clear_to_send() gatekeeper.Link: http://lore.kernel.org/r/20201111113000.GA1237157@mwanda
Reported-by: Dan Carpenter
Fixes: 6450ddbd5d8e ("ACPI: NFIT: Define runtime firmware activation commands")
Cc:
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman -
commit 7079f785b50055a32b72eddcb7d9ba5688db24d0 upstream.
Change the Input Source enumerated control's strings to make it play
nice with pulseaudio.Fixes: 7cb9d94c05de9 ("ALSA: hda/ca0132: add alt_select_in/out for R3Di + SBZ")
Cc:
Signed-off-by: Connor McAdams
Link: https://lore.kernel.org/r/20201208195223.424753-2-conmanx360@gmail.com
Link: https://lore.kernel.org/r/20201210173550.2968-2-conmanx360@gmail.com
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit f051ae4f6c732c231046945b36234e977f8467c6 upstream.
gcc -Warray-bounds warns about a serious bug in
cyapa_pip_retrieve_data_structure:drivers/input/mouse/cyapa_gen6.c: In function 'cyapa_pip_retrieve_data_structure.constprop':
include/linux/unaligned/access_ok.h:40:17: warning: array subscript -1 is outside array bounds of 'struct retrieve_data_struct_cmd[1]' [-Warray-bounds]
40 | *((__le16 *)p) = cpu_to_le16(val);
drivers/input/mouse/cyapa_gen6.c:569:13: note: while referencing 'cmd'
569 | } __packed cmd;
| ^~~Apparently the '-2' was added to the pointer instead of the value,
writing garbage into the stack next to this variable.Fixes: c2c06c41f700 ("Input: cyapa - add gen6 device module support")
Signed-off-by: Arnd Bergmann
Link: https://lore.kernel.org/r/20201026161332.3708389-1-arnd@kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 219a8b9c04e54872f9a4d566633fb42f08bcbe2a upstream.
The ipu3-cio2 doesn't make use of the field and this is reflected in V4L2
buffers as well as the try format. Do this in active format, too.Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
Signed-off-by: Sakari Ailus
Reviewed-by: Bingbu Cao
Reviewed-by: Andy Shevchenko
Reviewed-by: Laurent Pinchart
Cc: stable@vger.kernel.org # v4.16 and up
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit a86cf9b29e8b12811cf53c4970eefe0c1d290476 upstream.
Validate media bus code, width and height when setting the subdev format.
This effectively reworks how setting subdev format is implemented in the
driver.Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
Signed-off-by: Sakari Ailus
Reviewed-by: Andy Shevchenko
Reviewed-by: Laurent Pinchart
Cc: stable@vger.kernel.org # v4.16 and up
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 55a6c6b2be3d6670bf5772364d8208bd8dc17da4 upstream.
Pad format can be accessed from user space. Serialise access to it.
Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
Signed-off-by: Sakari Ailus
Reviewed-by: Laurent Pinchart
Reviewed-by: Bingbu Cao
Reviewed-by: Andy Shevchenko
Cc: stable@vger.kernel.org # v4.16 and up
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 8160e86702e0807bd36d40f82648f9f9820b9d5a upstream.
Return actual subdev format on ipu3-cio2 subdev pads. The earlier
implementation was based on an infinite recursion that exhausted the
stack.Reported-by: Tsuchiya Yuto
Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
Signed-off-by: Sakari Ailus
Reviewed-by: Laurent Pinchart
Reviewed-by: Bingbu Cao
Reviewed-by: Andy Shevchenko
Cc: stable@vger.kernel.org # v4.16 and up
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 61e7f892b5ee1dd10ea8bff805f3c3fe6e535959 upstream.
If starting a video buffer queue fails, the buffers are returned to
videobuf2. Remove the reference to the buffer from the driver's queue as
well.Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
Signed-off-by: Sakari Ailus
Cc: stable@vger.kernel.org # v4.16 and up
Reviewed-by: Andy Shevchenko
Reviewed-by: Laurent Pinchart
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit e297ddf296de35037fa97f4302782def196d350a upstream.
If the call to spi_register_master() fails on probe of the NetUP
Universal DVB driver, the spi_master struct is erroneously not freed.Likewise, if spi_new_device() fails, the spi_controller struct is
not unregistered. Plug the leaks.While at it, fix an ordering issue in netup_spi_release() wherein
spi_unregister_master() is called after fiddling with the IRQ control
register. The correct order is to call spi_unregister_master() *before*
this teardown step because bus accesses may still be ongoing until that
function returns.Fixes: 52b1eaf4c59a ("[media] netup_unidvb: NetUP Universal DVB-S/S2/T/T2/C PCI-E card driver")
Signed-off-by: Lukas Wunner
Reviewed-by: Mauro Carvalho Chehab
Cc: # v4.3+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
Cc: # v4.3+
Cc: Kozlov Sergey
Link: https://lore.kernel.org/r/c4c24f333fc7840f4a3db24789e6e10dd660bede.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 3f56df4c8ffeb120ed41906d3aae71799b7e726a upstream.
If a user holds a button down on a remote, then no ir idle interrupt will
be generated until the user releases the button, depending on how quickly
the remote repeats. No IR is processed until that point, which means that
holding down a button may not do anything.This also resolves an issue on a Cubieboard 1 where the IR receiver is
picking up ambient infrared as IR and spews out endless
"rc rc0: IR event FIFO is full!" messages unless you choose to live in
the dark.Cc: stable@vger.kernel.org
Tested-by: Hans Verkuil
Acked-by: Maxime Ripard
Reported-by: Hans Verkuil
Signed-off-by: Sean Young
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 00c18640c2430c4bafaaeede1f9dd6f7ec0e4b25 upstream.
Before IORING_SETUP_ATTACH_WQ, we could just cancel everything on the
io-wq when exiting. But that's not the case if they are shared, so
cancel for the specific ctx instead.Cc: stable@vger.kernel.org
Fixes: 24369c2e3bb0 ("io_uring: add io-wq workqueue sharing")
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 9faadcc8abe4b83d0263216dc3a6321d5bbd616b upstream.
Once we created a file for current context during setup, we should not
call io_ring_ctx_wait_and_kill() directly as it'll be done by fput(file)Cc: stable@vger.kernel.org # 5.10
Reported-by: syzbot+c9937dfb2303a5f18640@syzkaller.appspotmail.com
Signed-off-by: Pavel Begunkov
[axboe: fix unused 'ret' for !CONFIG_UNIX]
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit a528b04ea40690ff40501f50d618a62a02b19620 upstream.
xa_store() may fail, check the result.
Cc: stable@vger.kernel.org # 5.10
Fixes: 0f2122045b946 ("io_uring: don't rely on weak ->files references")
Signed-off-by: Pavel Begunkov
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit c07e6719511e77c4b289f62bfe96423eb6ea061d upstream.
io_iopoll_complete() does not hold completion_lock to complete polled io,
so in io_wq_submit_work(), we can not call io_req_complete() directly, to
complete polled io, otherwise there maybe concurrent access to cqring,
defer_list, etc, which is not safe. Commit dad1b1242fd5 ("io_uring: always
let io_iopoll_complete() complete polled io") has fixed this issue, but
Pavel reported that IOPOLL apart from rw can do buf reg/unreg requests(
IORING_OP_PROVIDE_BUFFERS or IORING_OP_REMOVE_BUFFERS), so the fix is not
good.Given that io_iopoll_complete() is always called under uring_lock, so here
for polled io, we can also get uring_lock to fix this issue.Fixes: dad1b1242fd5 ("io_uring: always let io_iopoll_complete() complete polled io")
Cc: # 5.5+
Signed-off-by: Xiaoguang Wang
Reviewed-by: Pavel Begunkov
[axboe: don't deref 'req' after completing it']
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit dd20166236953c8cd14f4c668bf972af32f0c6be upstream.
Doing vectored buf-select read with 0 iovec passed is meaningless and
utterly broken, forbid it.Cc: # 5.7+
Signed-off-by: Pavel Begunkov
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 0020ef04e48571a88d4f482ad08f71052c5c5a08 upstream.
For the first time a req punted to io-wq, we'll initialize io_wq_work's
list to be NULL, then insert req to io_wqe->work_list. If this req is not
inserted into tail of io_wqe->work_list, this req's io_wq_work list will
point to another req's io_wq_work. For splitted bio case, this req maybe
inserted to io_wqe->work_list repeatedly, once we insert it to tail of
io_wqe->work_list for the second time, now io_wq_work->list->next will be
invalid pointer, which then result in many strang error, panic, kernel
soft-lockup, rcu stall, etc.In my vm, kernel doest not have commit cc29e1bf0d63f7 ("block: disable
iopoll for split bio"), below fio job can reproduce this bug steadily:
[global]
name=iouring-sqpoll-iopoll-1
ioengine=io_uring
iodepth=128
numjobs=1
thread
rw=randread
direct=1
registerfiles=1
hipri=1
bs=4m
size=100M
runtime=120
time_based
group_reporting
randrepeat=0[device]
directory=/home/feiman.wxg/mntpoint/ # an ext4 mount pointIf we have commit cc29e1bf0d63f7 ("block: disable iopoll for split bio"),
there will no splitted bio case for polled io, but I think we still to need
to fix this list corruption, it also should maybe go to stable branchs.To fix this corruption, if a req is inserted into tail of io_wqe->work_list,
initialize req->io_wq_work->list->next to bu NULL.Cc: stable@vger.kernel.org
Signed-off-by: Xiaoguang Wang
Reviewed-by: Pavel Begunkov
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit e469d0b09a19496e1972a20974bbf55b728151eb upstream.
The gspca driver leaks memory when a probe fails. gspca_dev_probe2()
calls v4l2_device_register(), which takes a reference to the
underlying device node (in this case, a USB interface). But the
failure pathway neglects to call v4l2_device_unregister(), the routine
responsible for dropping this reference. Consequently the memory for
the USB interface and its device never gets released.This patch adds the missing function call.
Reported-and-tested-by: syzbot+44e64397bd81d5e84cba@syzkaller.appspotmail.com
Signed-off-by: Alan Stern
CC:
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit d22f9a6c92de96304c81792942ae7c306f08ac77 upstream.
We execute certain NPU2 setup code (such as mapping an LPID to a device
in NPU2) unconditionally if an Nvlink bridge is detected. However this
cannot succeed on POWER8NVL machines as the init helpers return an error
other than ENODEV which means the device is there is and setup failed so
vfio_pci_enable() fails and pass through is not possible.This changes the two NPU2 related init helpers to return -ENODEV if
there is no "memory-region" device tree property as this is
the distinction between NPU and NPU2.Tested on
- POWER9 pvr=004e1201, Ubuntu 19.04 host, Ubuntu 18.04 vm,
NVIDIA GV100 10de:1db1 driver 418.39
- POWER8 pvr=004c0100, RHEL 7.6 host, Ubuntu 16.10 vm,
NVIDIA P100 10de:15f9 driver 396.47Fixes: 7f92891778df ("vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriver")
Cc: stable@vger.kernel.org # 5.0
Signed-off-by: Alexey Kardashevskiy
Signed-off-by: Alex Williamson
Signed-off-by: Greg Kroah-Hartman -
commit 16b8fe4caf499ae8e12d2ab1b1324497e36a7b83 upstream.
In case an error occurs in vfio_pci_enable() before the call to
vfio_pci_probe_mmaps(), vfio_pci_disable() will try to iterate
on an uninitialized list and cause a kernel panic.Lets move to the initialization to vfio_pci_probe() to fix the
issue.Signed-off-by: Eric Auger
Fixes: 05f0c03fbac1 ("vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive")
CC: Stable # v4.7+
Signed-off-by: Alex Williamson
Signed-off-by: Greg Kroah-Hartman -
commit dad1b1242fd5717af18ae4ac9d12b9f65849e13a upstream.
Abaci Fuzz reported a double-free or invalid-free BUG in io_commit_cqring():
[ 95.504842] BUG: KASAN: double-free or invalid-free in io_commit_cqring+0x3ec/0x8e0
[ 95.505921]
[ 95.506225] CPU: 0 PID: 4037 Comm: io_wqe_worker-0 Tainted: G B
W 5.10.0-rc5+ #1
[ 95.507434] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[ 95.508248] Call Trace:
[ 95.508683] dump_stack+0x107/0x163
[ 95.509323] ? io_commit_cqring+0x3ec/0x8e0
[ 95.509982] print_address_description.constprop.0+0x3e/0x60
[ 95.510814] ? vprintk_func+0x98/0x140
[ 95.511399] ? io_commit_cqring+0x3ec/0x8e0
[ 95.512036] ? io_commit_cqring+0x3ec/0x8e0
[ 95.512733] kasan_report_invalid_free+0x51/0x80
[ 95.513431] ? io_commit_cqring+0x3ec/0x8e0
[ 95.514047] __kasan_slab_free+0x141/0x160
[ 95.514699] kfree+0xd1/0x390
[ 95.515182] io_commit_cqring+0x3ec/0x8e0
[ 95.515799] __io_req_complete.part.0+0x64/0x90
[ 95.516483] io_wq_submit_work+0x1fa/0x260
[ 95.517117] io_worker_handle_work+0xeac/0x1c00
[ 95.517828] io_wqe_worker+0xc94/0x11a0
[ 95.518438] ? io_worker_handle_work+0x1c00/0x1c00
[ 95.519151] ? __kthread_parkme+0x11d/0x1d0
[ 95.519806] ? io_worker_handle_work+0x1c00/0x1c00
[ 95.520512] ? io_worker_handle_work+0x1c00/0x1c00
[ 95.521211] kthread+0x396/0x470
[ 95.521727] ? _raw_spin_unlock_irq+0x24/0x30
[ 95.522380] ? kthread_mod_delayed_work+0x180/0x180
[ 95.523108] ret_from_fork+0x22/0x30
[ 95.523684]
[ 95.523985] Allocated by task 4035:
[ 95.524543] kasan_save_stack+0x1b/0x40
[ 95.525136] __kasan_kmalloc.constprop.0+0xc2/0xd0
[ 95.525882] kmem_cache_alloc_trace+0x17b/0x310
[ 95.533930] io_queue_sqe+0x225/0xcb0
[ 95.534505] io_submit_sqes+0x1768/0x25f0
[ 95.535164] __x64_sys_io_uring_enter+0x89e/0xd10
[ 95.535900] do_syscall_64+0x33/0x40
[ 95.536465] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 95.537199]
[ 95.537505] Freed by task 4035:
[ 95.538003] kasan_save_stack+0x1b/0x40
[ 95.538599] kasan_set_track+0x1c/0x30
[ 95.539177] kasan_set_free_info+0x1b/0x30
[ 95.539798] __kasan_slab_free+0x112/0x160
[ 95.540427] kfree+0xd1/0x390
[ 95.540910] io_commit_cqring+0x3ec/0x8e0
[ 95.541516] io_iopoll_complete+0x914/0x1390
[ 95.542150] io_do_iopoll+0x580/0x700
[ 95.542724] io_iopoll_try_reap_events.part.0+0x108/0x200
[ 95.543512] io_ring_ctx_wait_and_kill+0x118/0x340
[ 95.544206] io_uring_release+0x43/0x50
[ 95.544791] __fput+0x28d/0x940
[ 95.545291] task_work_run+0xea/0x1b0
[ 95.545873] do_exit+0xb6a/0x2c60
[ 95.546400] do_group_exit+0x12a/0x320
[ 95.546967] __x64_sys_exit_group+0x3f/0x50
[ 95.547605] do_syscall_64+0x33/0x40
[ 95.548155] entry_SYSCALL_64_after_hwframe+0x44/0xa9The reason is that once we got a non EAGAIN error in io_wq_submit_work(),
we'll complete req by calling io_req_complete(), which will hold completion_lock
to call io_commit_cqring(), but for polled io, io_iopoll_complete() won't
hold completion_lock to call io_commit_cqring(), then there maybe concurrent
access to ctx->defer_list, double free may happen.To fix this bug, we always let io_iopoll_complete() complete polled io.
Cc: # 5.5+
Reported-by: Abaci Fuzz
Signed-off-by: Xiaoguang Wang
Reviewed-by: Pavel Begunkov
Reviewed-by: Joseph Qi
Signed-off-by: Pavel Begunkov
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 31bff9a51b264df6d144931a6a5f1d6cc815ed4b upstream.
IOPOLL allows buffer remove/provide requests, but they doesn't
synchronise by rules of IOPOLL, namely it have to hold uring_lock.Cc: # 5.7+
Signed-off-by: Pavel Begunkov
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 59850d226e4907a6f37c1d2fe5ba97546a8691a4 upstream.
Checking !list_empty(&ctx->cq_overflow_list) around noflush in
io_cqring_events() is racy, because if it fails but a request overflowed
just after that, io_cqring_overflow_flush() still will be called.Remove the second check, it shouldn't be a problem for performance,
because there is cq_check_overflow bit check just above.Cc: # 5.5+
Signed-off-by: Pavel Begunkov
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 14e3e989f6a5d9646b6cf60690499cc8bdc11f7d ]
Since commit 36e2c7421f02 ("fs: don't allow splice read/write without
explicit ops") we've required that file operation structures explicitly
enable splice support, rather than falling back to the default handlers.Most /proc files use the indirect 'struct proc_ops' to describe their
file operations, and were fixed up to support splice earlier in commits
40be821d627c..b24c30c67863, but the mountinfo files interact with the
VFS directly using their own 'struct file_operations' and got missed as
a result.This adds the necessary support for splice to work for /proc/*/mountinfo
and friends.Reported-by: Joan Bruguera Micó
Reported-by: Jussi Kivilinna
Link: https://bugzilla.kernel.org/show_bug.cgi?id=209971
Cc: Greg Kroah-Hartman
Cc: Christoph Hellwig
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 942cb357ae7d9249088e3687ee6a00ed2745a0c7 ]
Smack assumes that kernel threads are privileged for smackfs
operations. This was necessary because the credential of the
kernel thread was not related to a user operation. With io_uring
the credential does reflect a user's rights and can be used.Suggested-by: Jens Axboe
Acked-by: Jens Axboe
Acked-by: Eric W. Biederman
Signed-off-by: Casey Schaufler
Signed-off-by: Sasha Levin -
[ Upstream commit cda286f0715c82f8117e166afd42cca068876dde ]
io_uring_cancel_task_requests() doesn't imply that the ring is going
away, it may continue to work well after that. The problem is that it
sets ->cq_overflow_flushed effectively disabling the CQ overflow featureSplit setting cq_overflow_flushed from flush, and do the first one only
on exit. It's ok in terms of cancellations because there is a
io_uring->in_idle check in __io_cqring_fill_event().It also fixes a race with setting ->cq_overflow_flushed in
io_uring_cancel_task_requests, whuch's is not atomic and a part of a
bitmask with other flags. Though, the only other flag that's not set
during init is drain_next, so it's not as bad for sane architectures.Signed-off-by: Pavel Begunkov
Fixes: 0f2122045b946 ("io_uring: don't rely on weak ->files references")
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin -
[ Upstream commit 634578f800652035debba3098d8ab0d21af7c7a5 ]
It's not safe to call io_cqring_overflow_flush() for IOPOLL mode without
hodling uring_lock, because it does synchronisation differently. Make
sure we have it.As for io_ring_exit_work(), we don't even need it there because
io_ring_ctx_wait_and_kill() already set force flag making all overflowed
requests to be dropped.Cc: # 5.5+
Signed-off-by: Pavel Begunkov
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
