10 Oct, 2018
10 commits
-
[ Upstream commit 67d1ba8a6dc83d90cd58b89fa6cbf9ae35a0cf7f ]
The mod mask for VHT capabilities intends to say that you can override
the number of STBC receive streams, and it does, but only by accident.
The IEEE80211_VHT_CAP_RXSTBC_X aren't bits to be set, but values (albeit
left-shifted). ORing the bits together gets the right answer, but we
should use the _MASK macro here instead.Signed-off-by: Danek Duvall
Signed-off-by: Johannes Berg
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 89809b028b6f54187b7d81a0c69b35d394c52e62 ]
Reported-by: Colin Ian King
Signed-off-by: Varun Prakash
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 801660b040d132f67fac6a95910ad307c5929b49 ]
Test case btrfs/164 reports use-after-free:
[ 6712.084324] general protection fault: 0000 [#1] PREEMPT SMP
..
[ 6712.195423] btrfs_update_commit_device_size+0x75/0xf0 [btrfs]
[ 6712.201424] btrfs_commit_transaction+0x57d/0xa90 [btrfs]
[ 6712.206999] btrfs_rm_device+0x627/0x850 [btrfs]
[ 6712.211800] btrfs_ioctl+0x2b03/0x3120 [btrfs]Reason for this is that btrfs_shrink_device adds the resized device to
the fs_devices::resized_devices after it has called the last commit
transaction.So the list fs_devices::resized_devices is not empty when
btrfs_shrink_device returns. Now the parent function
btrfs_rm_device calls:btrfs_close_bdev(device);
call_rcu(&device->rcu, free_device_rcu);and then does the transactio ncommit. It goes through the
fs_devices::resized_devices in btrfs_update_commit_device_size and
leads to use-after-free.Fix this by making sure btrfs_shrink_device calls the last needed
btrfs_commit_transaction before the return. This is consistent with what
the grow counterpart does and this makes sure the on-disk state is
persistent when the function returns.Reported-by: Lu Fengqi
Tested-by: Lu Fengqi
Signed-off-by: Anand Jain
Reviewed-by: David Sterba
[ update changelog ]
Signed-off-by: David Sterba
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 46dec40fb741f00f1864580130779aeeaf24fb3d ]
This fixes a bug which causes guest virtual addresses to get translated
to guest real addresses incorrectly when the guest is using the HPT MMU
and has more than 256GB of RAM, or more specifically has a HPT larger
than 2GB. This has showed up in testing as a failure of the host to
emulate doorbell instructions correctly on POWER9 for HPT guests with
more than 256GB of RAM.The bug is that the HPTE index in kvmppc_mmu_book3s_64_hv_xlate()
is stored as an int, and in forming the HPTE address, the index gets
shifted left 4 bits as an int before being signed-extended to 64 bits.
The simple fix is to make the variable a long int, matching the
return type of kvmppc_hv_find_lock_hpte(), which is what calculates
the index.Fixes: 697d3899dcb4 ("KVM: PPC: Implement MMIO emulation support for Book3S HV guests")
Signed-off-by: Paul Mackerras
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 484004339d4514fde425f6e8a9f6a6cc979bb0c3 ]
Syzbot continues to try to create mac80211_hwsim radios, and
manages to pass parameters that are later checked with WARN_ON
in cfg80211 - catch another one in hwsim directly.Reported-by: syzbot+2a12f11c306afe871c1f@syzkaller.appspotmail.com
Signed-off-by: Johannes Berg
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 77cfaf52eca5cac30ed029507e0cab065f888995 ]
The TXQ teardown code can reference the vif data structures that are
stored in the netdev private memory area if there are still packets on
the queue when it is being freed. Since the TXQ teardown code is run
after the netdevs are freed, this can lead to a use-after-free. Fix this
by moving the TXQ teardown code to earlier in ieee80211_unregister_hw().Reported-by: Ben Greear
Tested-by: Ben Greear
Signed-off-by: Toke Høiland-Jørgensen
Signed-off-by: Johannes Berg
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
commit 46c2797826cc6d1ae36fcbd966e76f9fa1907eef upstream.
Signed-off-by: Len Brown
Cc: Alakesh Haloi
Signed-off-by: Greg Kroah-Hartman -
commit e0bf2d4982fe7d9ddaf550dd023803ea286f47fc upstream.
Apparently, this driver (or the hardware) does not support character
length settings. It's apparently running in 8-bit mode, but it makes
userspace believe it's in 5-bit mode. That makes tcsetattr with CS8
incorrectly fail, breaking e.g. getty from busybox, thus the login shell
on ttyMVx.Fix by hard-wiring CS8 into c_cflag.
Signed-off-by: Jan Kiszka
Fixes: 30530791a7a0 ("serial: mvebu-uart: initial support for Armada-3700 serial port")
Cc: stable # 4.6+
Signed-off-by: Greg Kroah-Hartman -
commit b3fc2ab37e27f8d6588a4755382346ba2335a7c7 upstream.
Needs ATPX rather than _PR3.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=200517
Reviewed-by: Junwei Zhang
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman -
commit c4ff91dd40e2253ab6dd028011469c2c694e1e19 upstream.
The current use of result is or'ing in values and checking for
a non-zero result, however, result is not initialized to zero
so it potentially contains garbage to start with. Fix this by
initializing it to the first return from the call to
vega10_program_didt_config_registers.Detected by cppcheck:
"(error) Uninitialized variable: result"Fixes: 9b7b8154cdb8 ("drm/amd/powerplay: added didt support for vega10")
Signed-off-by: Colin Ian King
Acked-by: Huang Rui
[Fix the subject as Colin's comment]
Signed-off-by: Huang Rui
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman
04 Oct, 2018
30 commits
-
commit ad608fbcf166fec809e402d548761768f602702c upstream.
The event subscriptions are added to the subscribed event list while
holding a spinlock, but that lock is subsequently released while still
accessing the subscription object. This makes it possible to unsubscribe
the event --- and freeing the subscription object's memory --- while
the subscription object is simultaneously accessed.Prevent this by adding a mutex to serialise the event subscription and
unsubscription. This also gives a guarantee to the callback ops that the
add op has returned before the del op is called.This change also results in making the elems field less special:
subscriptions are only added to the event list once they are fully
initialised.Signed-off-by: Sakari Ailus
Reviewed-by: Hans Verkuil
Reviewed-by: Laurent Pinchart
Cc: stable@vger.kernel.org # for 4.14 and up
Fixes: c3b5b0241f62 ("V4L/DVB: V4L: Events: Add backend")
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 2a3f93459d689d990b3ecfbe782fec89b97d3279 upstream.
Not all execution modes are valid for a guest, and some of them
depend on what the HW actually supports. Let's verify that what
userspace provides is compatible with both the VM settings and
the HW capabilities.Cc:
Fixes: 0d854a60b1d7 ("arm64: KVM: enable initialization of a 32bit vcpu")
Reviewed-by: Christoffer Dall
Reviewed-by: Mark Rutland
Reviewed-by: Dave Martin
Signed-off-by: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit ff924c5a1ec7548825cc2d07980b03be4224ffac ]
Fix the section mismatch warning in arch/x86/mm/pti.c:
WARNING: vmlinux.o(.text+0x6972a): Section mismatch in reference from the function pti_clone_pgtable() to the function .init.text:pti_user_pagetable_walk_pte()
The function pti_clone_pgtable() references
the function __init pti_user_pagetable_walk_pte().
This is often because pti_clone_pgtable lacks a __init
annotation or the annotation of pti_user_pagetable_walk_pte is wrong.
FATAL: modpost: Section mismatches detected.Fixes: 85900ea51577 ("x86/pti: Map the vsyscall page if needed")
Reported-by: kbuild test robot
Signed-off-by: Randy Dunlap
Signed-off-by: Thomas Gleixner
Cc: Andy Lutomirski
Link: https://lkml.kernel.org/r/43a6d6a3-d69d-5eda-da09-0b1c88215a2a@infradead.org
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 7fd6d98b89f382d414e1db528e29a67bbd749457 ]
Commit 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict
with PCI BAR") made it possible for AML code to access SMBus I/O ports
by installing custom SystemIO OpRegion handler and blocking i80i driver
access upon first AML read/write to this OpRegion.However, while ThinkPad T560 does have SystemIO OpRegion declared under
the SMBus device, it does not access any of the SMBus registers:Device (SMBU)
{
...OperationRegion (SMBP, PCI_Config, 0x50, 0x04)
Field (SMBP, DWordAcc, NoLock, Preserve)
{
, 5,
TCOB, 11,
Offset (0x04)
}Name (TCBV, 0x00)
Method (TCBS, 0, NotSerialized)
{
If ((TCBV == 0x00))
{
TCBV = (\_SB.PCI0.SMBU.TCOB << 0x05)
}Return (TCBV) /* \_SB_.PCI0.SMBU.TCBV */
}OperationRegion (TCBA, SystemIO, TCBS (), 0x10)
Field (TCBA, ByteAcc, NoLock, Preserve)
{
Offset (0x04),
, 9,
CPSC, 1
}
}Problem with the current approach is that it blocks all I/O port access
and because this system has touchpad connected to the SMBus controller
after first AML access (happens during suspend/resume cycle) the
touchpad fails to work anymore.Fix this so that we allow ACPI AML I/O port access if it does not touch
the region reserved for the SMBus.Fixes: 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200737
Reported-by: Yussuf Khalil
Signed-off-by: Mika Westerberg
Reviewed-by: Jean Delvare
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 755a8bf5579d22eb5636685c516d8dede799e27b ]
If someone has the silly idea to write something along those lines:
extern u64 foo(void);
void bar(struct arm_smccc_res *res)
{
arm_smccc_1_1_smc(0xbad, foo(), res);
}they are in for a surprise, as this gets compiled as:
0000000000000588 :
588: a9be7bfd stp x29, x30, [sp, #-32]!
58c: 910003fd mov x29, sp
590: f9000bf3 str x19, [sp, #16]
594: aa0003f3 mov x19, x0
598: aa1e03e0 mov x0, x30
59c: 94000000 bl 0
5a0: 94000000 bl 0
5a4: aa0003e1 mov x1, x0
5a8: d4000003 smc #0x0
5ac: b4000073 cbz x19, 5b8
5b0: a9000660 stp x0, x1, [x19]
5b4: a9010e62 stp x2, x3, [x19, #16]
5b8: f9400bf3 ldr x19, [sp, #16]
5bc: a8c27bfd ldp x29, x30, [sp], #32
5c0: d65f03c0 ret
5c4: d503201f nopThe call to foo "overwrites" the x0 register for the return value,
and we end up calling the wrong secure service.A solution is to evaluate all the parameters before assigning
anything to specific registers, leading to the expected result:0000000000000588 :
588: a9be7bfd stp x29, x30, [sp, #-32]!
58c: 910003fd mov x29, sp
590: f9000bf3 str x19, [sp, #16]
594: aa0003f3 mov x19, x0
598: aa1e03e0 mov x0, x30
59c: 94000000 bl 0
5a0: 94000000 bl 0
5a4: aa0003e1 mov x1, x0
5a8: d28175a0 mov x0, #0xbad
5ac: d4000003 smc #0x0
5b0: b4000073 cbz x19, 5bc
5b4: a9000660 stp x0, x1, [x19]
5b8: a9010e62 stp x2, x3, [x19, #16]
5bc: f9400bf3 ldr x19, [sp, #16]
5c0: a8c27bfd ldp x29, x30, [sp], #32
5c4: d65f03c0 retReported-by: Julien Grall
Signed-off-by: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 1d8f574708a3fb6f18c85486d0c5217df893c0cf ]
An unfortunate consequence of having a strong typing for the input
values to the SMC call is that it also affects the type of the
return values, limiting r0 to 32 bits and r{1,2,3} to whatever
was passed as an input.Let's turn everything into "unsigned long", which satisfies the
requirements of both architectures, and allows for the full
range of return values.Reported-by: Julien Grall
Signed-off-by: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 2d59bb602314a4b2593fde267734266b5e872dd0 ]
Otherwise we can get the following errors occasionally on some devices:
mmc1: tried to HW reset card, got error -110
mmcblk1: error -110 requesting status
mmcblk1: recovery failed!
print_req_error: I/O error, dev mmcblk1, sector 14329
...I have one device that hits this error almost on every boot, and another
one that hits it only rarely with the other ones I've used behave without
problems. I'm not sure if the issue is related to a particular eMMC card
model, but in case it is, both of the machines with issues have:# cat /sys/class/mmc_host/mmc1/mmc1:0001/manfid \
/sys/class/mmc_host/mmc1/mmc1:0001/oemid \
/sys/class/mmc_host/mmc1/mmc1:0001/name
0x000045
0x0100
SEM16Gand the working ones have:
0x000011
0x0100
016G92Note that "ti,non-removable" is different as omap_hsmmc_reg_get() does not
call omap_hsmmc_disable_boot_regulators() if no_regulator_off_init is set.
And currently we set no_regulator_off_init only for "ti,non-removable" and
not for "non-removable". It seems that we should have "non-removable" with
some other mmc generic property behave in the same way instead of having to
use a non-generic property. But let's fix the issue first.Fixes: 7e2f8c0ae670 ("ARM: dts: Add minimal support for motorola droid 4
xt894")
Cc: Marcel Partap
Cc: Merlijn Wajer
Cc: Michael Scott
Cc: NeKit
Cc: Pavel Machek
Cc: Sebastian Reichel
Signed-off-by: Tony Lindgren
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit afd299ca996929f4f98ac20da0044c0cdc124879 ]
When a targetport is removed from the config, fcloop will avoid calling
the LS done() routine thinking the targetport is gone. This leaves the
initiator reset/reconnect hanging as it waits for a status on the
Create_Association LS for the reconnect.Change the filter in the LS callback path. If tport null (set when
failed validation before "sending to remote port"), be sure to call
done. This was the main bug. But, continue the logic that only calls
done if tport was set but there is no remoteport (e.g. case where
remoteport has been removed, thus host doesn't expect a completion).Signed-off-by: James Smart
Signed-off-by: Christoph Hellwig
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 46cb52ad414ac829680d0bb8cc7090ac2b577ca7 ]
The DMA is broken on this specific device for some unknown
reason (probably badly designed or plain broken interface
electronics) and will only work with PIO. Other users of
the same hardware does not have this problem.Add a specific quirk so that this Gemini device gets
DMA turned off. Also fix up some code around passing the
port information around in probe while we're at it.Signed-off-by: Linus Walleij
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 2ab4d0e74256fc49b7b270f63c1d1e47c2455abc ]
For SI/Kv, the power state is managed by function
amdgpu_pm_compute_clocks.when dpm enabled, we should call amdgpu_pm_compute_clocks
to update current power state instand of set boot state.this change can fix the oops when kfd driver was enabled on Kv.
Reviewed-by: Alex Deucher
Tested-by: Michel Dänzer
Signed-off-by: Rex Zhu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 8ef23364b654d44244400d79988e677e504b21ba ]
This is required by gfx hw and can fix the rlc hang when
do s3 stree test on Cz/St.Reviewed-by: Alex Deucher
Signed-off-by: Hang Zhou
Signed-off-by: Rex Zhu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 538d6e9d597584e80514698e24321645debde78f ]
This reverts commit 1c86c9dd82f859b474474a7fee0d5195da2c9c1d.
That commit followed the reference manual but unfortunately the imx7d
manual is incorrect.Tested with ath9k pcie card and confirmed internally.
Signed-off-by: Leonard Crestez
Acked-by: Lucas Stach
Fixes: 1c86c9dd82f8 ("ARM: dts: imx7d: Invert legacy PCI irq mapping")
Signed-off-by: Shawn Guo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit f196dec6d50abb2e65fb54a0621b2f1b4d922995 ]
The adt7475_read_word() function was meant to return negative error
codes on failure.Signed-off-by: Dan Carpenter
Reviewed-by: Tokunori Ikegami
Signed-off-by: Guenter Roeck
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 3ad867001c91657c46dcf6656d52eb6080286fd5 ]
fix the sysfs shunt resistor read access: return the shunt resistor
value, not the calibration register contents.update email address
Signed-off-by: Lothar Felten
Signed-off-by: Guenter Roeck
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 3d7c82060d1fe65bde4023aac41a0b1bd7718e07 ]
Earlier used to post the current command without checking queue full
after backlog submissions. So, post the current command only after
confirming the space in queue after backlog submissions.Maintain host write index instead of reading device registers
to get the next free slot to post the command.Return -ENOSPC in queue full case.
Signed-off-by: Srikanth Jampala
Reviewed-by: Gadam Sreerama
Tested-by: Jha, Chandan
Signed-off-by: Herbert Xu
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit ee400a3f1bfe7004a3e14b81c38ccc5583c26295 ]
In 'e1000_set_ringparam()', the tx_ring and rx_ring are updated with new value
and the old tx/rx rings are freed only when the device is up. There are resource
leaks on old tx/rx rings when the device is not up. This bug is reported by COD,
a tool for testing kernel module binaries I am building.This patch fixes the bug by always calling 'kfree()' on old tx/rx rings in
'e1000_set_ringparam()'.Signed-off-by: Bo Chen
Reviewed-by: Alexander Duyck
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit cf1acec008f8d7761aa3fd7c4bca7e17b2d2512d ]
When the device is not up, the call to 'e1000_up()' from the error handling path
of 'e1000_set_ringparam()' causes a kernel oops with a null-pointer
dereference. The null-pointer dereference is triggered in function
'e1000_alloc_rx_buffers()' at line 'buffer_info = &rx_ring->buffer_info[i]'.This bug was reported by COD, a tool for testing kernel module binaries I am
building. This bug was also detected by KFI from Dr. Kai Cong.This patch fixes the bug by checking on 'netif_running()' before calling
'e1000_up()' in 'e1000_set_ringparam()'.Signed-off-by: Bo Chen
Acked-by: Alexander Duyck
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit b1ccd4c0ab6ef499f47dd84ed4920502a7147bba ]
skb->truesize is not meant to be tracking amount of used bytes in a skb,
but amount of reserved/consumed bytes in memory.For instance, if we use a single byte in last page fragment, we have to
account the full size of the fragment.So skb_add_rx_frag needs to calculate the length of the entire buffer into
turesize.Fixes: 9cbe9fd5214e ("net: hns: optimize XGE capability by reducing cpu usage")
Signed-off-by: Huazhong tan
Signed-off-by: Salil Mehta
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 3ed614dce3ca9912d22be215ff0f11104b69fe62 ]
When enable the config item "CONFIG_ARM64_64K_PAGES", the size of PAGE_SIZE
is 65536(64K). But the type of length and page_offset are u16, they will
overflow. So change them to u32.Fixes: 6fe6611ff275 ("net: add Hisilicon Network Subsystem hnae framework support")
Signed-off-by: Huazhong Tan
Signed-off-by: Salil Mehta
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 9b2e0388bec8ec5427403e23faff3b58dd1c3200 ]
When sockmap code is using the stream parser it also handles the write
space events in order to handle the case where (a) verdict redirects
skb to another socket and (b) the sockmap then sends the skb but due
to memory constraints (or other EAGAIN errors) needs to do a retry.But the initial code missed a third case where the
skb_send_sock_locked() triggers an sk_wait_event(). A typically case
would be when sndbuf size is exceeded. If this happens because we
do not pass the write_space event to the lower layers we never wake
up the event and it will wait for sndtimeo. Which as noted in ktls
fix may be rather large and look like a hang to the user.To reproduce the best test is to reduce the sndbuf size and send
1B data chunks to stress the memory handling. To fix this pass the
event from the upper layer to the lower layer.Signed-off-by: John Fastabend
Signed-off-by: Daniel Borkmann
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 67db7cd249e71f64346f481b629724376d063e08 ]
Currently, the lower protocols sk_write_space handler is not called if
TLS is sending a scatterlist via tls_push_sg. However, normally
tls_push_sg calls do_tcp_sendpage, which may be under memory pressure,
that in turn may trigger a wait via sk_wait_event. Typically, this
happens when the in-flight bytes exceed the sdnbuf size. In the normal
case when enough ACKs are received sk_write_space() will be called and
the sk_wait_event will be woken up allowing it to send more data
and/or return to the user.But, in the TLS case because the sk_write_space() handler does not
wake up the events the above send will wait until the sndtimeo is
exceeded. By default this is MAX_SCHEDULE_TIMEOUT so it look like a
hang to the user (especially this impatient user). To fix this pass
the sk_write_space event to the lower layers sk_write_space event
which in the TCP case will wake any pending events.I observed the above while integrating sockmap and ktls. It
initially appeared as test_sockmap (modified to use ktls) occasionally
hanging. To reliably reproduce this reduce the sndbuf size and stress
the tls layer by sending many 1B sends. This results in every byte
needing a header and each byte individually being sent to the crypto
layer.Signed-off-by: John Fastabend
Acked-by: Dave Watson
Signed-off-by: Daniel Borkmann
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 09a4e0be5826aa66c4ce9954841f110ffe63ef4f ]
The largest block size supported by isofs is ISOFS_BLOCK_SIZE (2048), but
isofs_fill_super calls sb_min_blocksize and sets the blocksize to the
device's logical block size if it's larger than what we ended up with after
option parsing.If for some reason we try to mount a hard 4k device as an isofs filesystem,
we'll set opt.blocksize to 4096, and when we try to read the superblock
we found via:block = iso_blknum << (ISOFS_BLOCK_BITS - s->s_blocksize_bits)
with s_blocksize_bits greater than ISOFS_BLOCK_BITS, we'll have a negative
shift and the bread will fail somewhat cryptically:isofs_fill_super: bread failed, dev=sda, iso_blknum=17, block=-2147483648
It seems best to just catch and clearly reject mounts of such a device.
Reported-by: Bryan Gurney
Signed-off-by: Eric Sandeen
Signed-off-by: Jan Kara
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 152395fd03d4ce1e535a75cdbf58105e50587611 ]
When thermal zone is in passive mode, disabling its mode from
sysfs is NOT taking effect at all, it is still polling the
temperature of the disabled thermal zone and handling all thermal
trips, it makes user confused. The disabling operation should
disable the thermal zone behavior completely, for both active and
passive mode, this patch clears the passive_delay when thermal
zone is disabled and restores it when it is enabled.Signed-off-by: Anson Huang
Signed-off-by: Eduardo Valentin
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit b310974e041913231b6e3d5d475d4df55c312301 ]
Keep sending mailbox commands to the MFW when it is not responsive ends up
with a redundant amount of timeout expiries.
This patch prints the MCP status on the first command which is not
responded, and blocks the following commands.
Since the (un)load request commands might be not responded due to other
PFs, the patch also adds the option to skip the blocking upon a failure.Signed-off-by: Tomer Tayar
Signed-off-by: Ariel Elior
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit eaa50fc59e5841910987e90b0438b2643041f508 ]
The MFW manages an internal lock to prevent concurrent hardware
(de)initialization of different PFs.
This, together with the busy-waiting for the MFW's responses for commands,
might lead to a deadlock during concurrent load or unload of PFs.
This patch adds the option to sleep within the busy-waiting, and uses it
for the (un)load requests (which are not sent from an interrupt context) to
prevent the possible deadlock.Signed-off-by: Tomer Tayar
Signed-off-by: Ariel Elior
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 76271809f49056f079e202bf6513d17b0d6dd34d ]
Successive iterations of halting and resuming the management chip (MCP)
might fail, since currently the driver doesn't wait for these operations to
actually take place.
This patch prevents the driver from moving forward before the operations
are reflected in the state register.Signed-off-by: Tomer Tayar
Signed-off-by: Ariel Elior
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit f00d25f3154b676fcea4502a25b94bd7f142ca74 ]
The MFW might be reset and re-update its shared memory.
Upon the detection of such a reset the driver rereads this memory, but it
has to wait till the data is valid.
This patch adds the missing wait for a data ready indication.Signed-off-by: Tomer Tayar
Signed-off-by: Ariel Elior
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
commit d26c25a9d19b5976b319af528886f89cf455692d upstream.
We currently allow userspace to access the core register file
in about any possible way, including straddling multiple
registers and doing unaligned accesses.This is not the expected use of the ABI, and nobody is actually
using it that way. Let's tighten it by explicitly checking
the size and alignment for each field of the register file.Cc:
Fixes: 2f4a07c5f9fe ("arm64: KVM: guest one-reg interface")
Reviewed-by: Christoffer Dall
Reviewed-by: Mark Rutland
Signed-off-by: Dave Martin
[maz: rewrote Dave's initial patch to be more easily backported]
Signed-off-by: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit 7e620984b62532783912312e334f3c48cdacbd5d upstream.
Back in 2015 when irda was dropped from the driver imx1 was broken. This
change reintroduces the support for the third interrupt of the UART.Fixes: afe9cbb1a6ad ("serial: imx: drop support for IRDA")
Cc: stable
Signed-off-by: Uwe Kleine-König
Reviewed-by: Leonard Crestez
Signed-off-by: Greg Kroah-Hartman
