Seven fixes to four drivers with no core changes. The mpt3sas one is
theoretical until we get a CPU that goes up to 64 bits physical, the
qla2xxx one fixes an oops in a driver initialization error leg and the
others are mostly cosmetic.
Signed-off-by: James E.J. Bottomley <jejb@linux.ibm.com>
-----BEGIN PGP SIGNATURE-----
iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCXURSriYcamFtZXMuYm90
dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishWpKAQCbTaKz
AWOXWaMUoL26nZ036slYx9KjxcXS/MFuDXCAnQEA5ww+AfKurovX62i3B7YqVDxm
j0TBq+LvzUUNcrA+JU8=
=NfZ0
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Seven fixes to four drivers with no core changes.
The mpt3sas one is theoretical until we get a CPU that goes up to 64
bits physical, the qla2xxx one fixes an oops in a driver
initialization error leg and the others are mostly cosmetic"
[ The fcoe patches may be worth highlighting - they may be "just"
cleanups, but they simplify and fix the odd fc_rport_priv structure
handling rules so that the new gcc-9 warnings about memset crossing
structure boundaries are gone.
The old code was hard for humans to understand too, and really
confused the compiler sanity checks - Linus ]
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: qla2xxx: Fix possible fcport null-pointer dereferences
scsi: mpt3sas: Use 63-bit DMA addressing on SAS35 HBA
scsi: hpsa: remove printing internal cdb on tag collision
scsi: hpsa: correct scsi command status issue after reset
scsi: fcoe: pass in fcoe_rport structure instead of fc_rport_priv
scsi: fcoe: Embed fc_rport_priv in fcoe_rport structure
scsi: libfc: Whitespace cleanup in libfc.h
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAl1ERCMQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpjr7D/0U8SMu1T9JOge91zXQQUc7XtCX9RvHYhhj
vbwwN9RwpIfrTwuLZUCvt2vEz8WPOVfZbwYGkfFcdI+N5I/dOfT8Swiwy7Zabpi2
KTedn2EdELTizEuWQ3QhaBHWuTGvE04aAzZTBRCQ0tCOYTPpXGRavxhG6UHcQi+z
lohB5Pr/cyX8/jWJj4kq7381QYUUH2bm9uY7qutBsQOt2CsN5prjWxX3JM6EO1wb
VyyI25fWLaS+bZW+crVutcARxccuav4e+LEJbb9Z7+19vjmkc2qE+22F3MBxYCzo
tOjU0RP0IvvVR9t0Hahw/3MnDTDfuSqlqrT12zNtn7FrzOKpkygMyRa+u8YygI6k
2iAp92HkNWpjBxUFNGoRCRfJpApG3vT6/VkI8tixFSw/Re3F1H9Bc9IRZxc3uU4H
5DMRmjZXGg+8Nw+93XzwWnD1paCJcDsHRHUpWFNJvRfJYQzDaziPUBV9a9TZ+HMF
BnCJBCW641tcA5yCRwBF6OpoowtmxOtWce7Lr9wAjU+cYHMEzOQoG+J6gPH3q8Jh
aD9U2FcnE6kReL+MsGj42q1U1n60xngcdzo8Ca4bWfWNpqb4lJatjumkDAiI6U4q
DFDs9bRbB4LLgwkRQ+n1biwAK626KJOp5lGXrEu7XHXSTlO/BiJytISwASjlzKsZ
4uGHc/uUdA==
=P5E/
-----END PGP SIGNATURE-----
Merge tag 'for-linus-20190802' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
"Here's a small collection of fixes that should go into this series.
This contains:
- io_uring potential use-after-free fix (Jackie)
- loop regression fix (Jan)
- O_DIRECT fragmented bio regression fix (Damien)
- Mark Denis as the new floppy maintainer (Denis)
- ataflop switch fall-through annotation (Gustavo)
- libata zpodd overflow fix (Kees)
- libata ahci deferred probe fix (Miquel)
- nbd invalidation BUG_ON() fix (Munehisa)
- dasd endless loop fix (Stefan)"
* tag 'for-linus-20190802' of git://git.kernel.dk/linux-block:
s390/dasd: fix endless loop after read unit address configuration
block: Fix __blkdev_direct_IO() for bio fragments
MAINTAINERS: floppy: take over maintainership
nbd: replace kill_bdev() with __invalidate_device() again
ata: libahci: do not complain in case of deferred probe
io_uring: fix KASAN use after free in io_sq_wq_submit_work
loop: Fix mount(2) failure due to race with LOOP_SET_FD
libata: zpodd: Fix small read overflow in zpodd_get_mech_type()
ataflop: Mark expected switch fall-through
changes from commit in 5.3 merge.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCAAxFiEEJfWUX4UqZ4x1O2wixSPxCi2dA1oFAl1EUvUTHHNuaXR6ZXJA
cmVkaGF0LmNvbQAKCRDFI/EKLZ0DWgj9B/0QQL8kB5DybBkADKAkmTw4pTtEqGSy
LebPIGl45RHHgLcXB1J1cSGs6uA6AuNnn9XoFY7juEJthGp0IR+NgxKiq5r4UW2Q
/k72a82D8T/FlBGet+5w44mKMARXiq5opdMS8iFezcd0c15IeNbbSmKZHluRppQX
KsCKJ1FsZobXlUUMSeJFIS5eJNMaSg1isotcT8P6kWXsaNYziGul2Akjhxw8a2qZ
kN6ATBKcvT4EOy/tDMFQhbFU6t5ydEH3buOZ1h8slCOSuzSzXuz56ff42dFYV8QK
WzldzZ7PSSHqKn7SAKwRs4g/iEMotPk1ChsMSvDBVGs3VG3yACV0OCdB
=KJ3q
-----END PGP SIGNATURE-----
Merge tag 'for-5.3/dm-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mike Snitzer:
"Fix NULL pointer and various whitespace issues with DM's recent DAX
code changes from commit in 5.3 merge"
* tag 'for-5.3/dm-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm table: fix various whitespace issues with recent DAX code
dm table: fix dax_dev NULL dereference in device_synchronous()
- A couple Spectre V1 fixes (umad, hfi1)
- Fix a tricky deadlock in the rdma core code with refcounting instead
of locks (client removal patches)
- Build errors (hns)
- Fix a scheduling while atomic issue (mlx5)
- Use after free fix (mad)
- Fix error path return code (hns)
- Null deref fix (siw_crypto_hash)
- A few other misc. minor fixes
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEErmsb2hIrI7QmWxJ0uCajMw5XL90FAl1ESa0ACgkQuCajMw5X
L91Beg//RqM0d05EmAqR0G3taQfzXZezE81CHk+92WxsZPN9SYdLeeJH0RXJNVsC
BrWrzR/g4s8e+cCdXeEU0fr0oxd4pzsxya3WjQmZ+ZgUoYyesbz4wvnzX8JVBuV6
fZ1AvXTviAYQvMA6RAddyuH+g951LAvNNvrZpfFUoD6AGEm8s/F9xHBUl2hR5hE/
W6LQvO65rzXKEkHC6r91qUNS1CIEUyhrlFe3Qs3jI8cqLzfUEUb5hAyUd/Oe+kRa
UiocfazisQzJX2NJWUFSWy0C+H7m38q6WNKrfoBLfyBpBj+Q2MOqoA8ghq095qj3
8DoWgD2tgdq3+ttYBEvNn21ZkOKBk0MLJDKVt34YLR8p+M4k1yP3f1V5TVIfnhdz
Y6Iv++JhpB9tMJXIucCXdmVyLOjwid8b8UMcyZE91y8u8nucTt/JWlPjob+D9aA9
gHQMZmaQvBSCGgorpWRfyTH04Sey2WOkQKWZQWSeEMvRX6wS5wab/RB5c13EHKF2
0B2+V2WsR8Mrj4fG7XSsBOGvIcBssSppnFSW1OaR98rspZcU4ykjRgBO0T9PXzce
kzCTCa9Zl48fEMYR1P50YJyVFu3X8RTOKv/cs5s/XoDLsvSU76+NhHQSlMV5XU12
lfXd2vDeUJX2cVlT+YAAwg+a0+tVskySww7vZmOpuYVvj/8z3mw=
=CfX3
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Pull rdma fixes from Doug Ledford:
"Here's our second -rc pull request. Nothing particularly special in
this one. The client removal deadlock fix is kindy tricky, but we had
multiple eyes on it and no one could find a fault in it. A couple
Spectre V1 fixes too. Otherwise, all just normal -rc fodder:
- A couple Spectre V1 fixes (umad, hfi1)
- Fix a tricky deadlock in the rdma core code with refcounting
instead of locks (client removal patches)
- Build errors (hns)
- Fix a scheduling while atomic issue (mlx5)
- Use after free fix (mad)
- Fix error path return code (hns)
- Null deref fix (siw_crypto_hash)
- A few other misc. minor fixes"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
RDMA/hns: Fix error return code in hns_roce_v1_rsv_lp_qp()
RDMA/mlx5: Release locks during notifier unregister
IB/hfi1: Fix Spectre v1 vulnerability
IB/mad: Fix use-after-free in ib mad completion handling
RDMA/restrack: Track driver QP types in resource tracker
IB/mlx5: Fix MR registration flow to use UMR properly
RDMA/devices: Remove the lock around remove_client_context
RDMA/devices: Do not deadlock during client removal
IB/core: Add mitigation for Spectre V1
Do not dereference 'siw_crypto_shash' before checking
RDMA/qedr: Fix the hca_type and hca_rev returned in device attributes
RDMA/hns: Fix build error
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE8rQSAMVO+zA4DBdWxWXV+ddtWDsFAl1ETYkACgkQxWXV+ddt
WDupLA/+LXPJvxRG/Ob655sxOAqpG4+XUW7aaI5jSnlr958TtDlNFkpzrQ28NFzk
XlEe/HjgI6CH7DhNwe1IlHLqFt874fiCeIZ2jvuSVVbPAO+9T8a5BIbeUY6V4h5v
QUmbaUpVshsh2IDArU8Vc/UjycCuwrccfGkS5ydTVI6Eni4BWsOY2PMiB5ojdOTE
bpclws3ca/CMbNpGKnn3cH5aXJpENTXedXxBbp99DproZVY3YL1ZyDxc37R6+5Ua
kbZznSMZFoLjHt3vktHmiozF7W1Zdi6ExOp9NHApshlw/n08ICkY1oNfd9KSYgQs
8gTl9mZ8jbJnSfZTuHNL6LwfSZjDyT5LCTbXSj0UnaVOYwJVwopsDrrdO6AESd8S
1eFeEFQ62lEV+31xa0nsYBz5j6ejEfcvxiq14W8LawWpkxtAIsEyXockWtmXPods
29BYkstQADlCOu2WYdQ8ugseBtfEpEAvD+Rf+qqyZ6XlHMIjL1J1S+BIXQ868z1f
KZCVsepJ0dVm0siVNMFBUaM2z1PcHusxNgYd37YcJRX2t4Gql9Ku/00PJ+tRhsBa
80a5ue9p6nuZfR6XoM6Cpe3uG8qyFyPccC3ohwKEOAnHnmk2LEJYASudV4pk/P8G
Vy3o9Uv/NMMznop24r7UB3mklBQCIchKpaij3RT0Jx+3RGdR4Yo=
=jr4T
-----END PGP SIGNATURE-----
Merge tag 'for-5.3-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
- tiny race window during 2 transactions aborting at the same time can
accidentally lead to a commit
- regression fix, possible deadlock during fiemap
- fix for an old bug when incremental send can fail on a file that has
been deduplicated in a special way
* tag 'for-5.3-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
Btrfs: fix deadlock between fiemap and transaction commits
Btrfs: fix race leading to fs corruption after transaction abort
Btrfs: fix incremental send failure after deduplication
- A further fix for syzcaller issues with USB-audio, addressing
NULL dereference that was introduced by the recent fix
- Avoid a long delay at boot with HD-audio when i915 module was
built but not installed, found on some Debian systems
- A fix of small race window at PCM draining
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl1EAPUOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE/UKw/+J7YWMbLMDUNlmCFBi2MStSc898LB3UsB+W+O
VGsluaiv9ZkyVmu/v6D4HqLDNCzNsqpg1NSNIDOAM/RBdsOjR1PYO0LZWED1hQet
frYiaIEx9xOKV8b1Q4X0soQY7OztXTOWvB5qzhl+HhAijhPaoMcjP0g6kqQiIRwQ
CxMljNAmE9pikFCqrmzi1XdaMr73tllfaAfUfNqvSoBTh++t3y3xt0OTEshsvidS
Df/3/rF+apRavyFoyGdXGNZsP16T1crWN1g2Ln/i2kCyCLU/YsVj290fnS3WJAzH
gMwridTLUaGF8gTbvwIdyKXejnK2gUqz6Kp/2m6v1DGQZxhdFzTbc1TMurqqc54K
1vAul0lFFrc9AIsTnBucTpUbI4enMcwXlrUBCU57NezjK60cMd6NWLv1wJIkD1el
WxDliDrHPuhgf6w6FiT3Ul+YirvcNm/zJKQSs/yDoj6GfjETgIoXQgoAP4HQK/XG
DrfQRvujFzv4tMiP7aaSCGe0zoGR09SwJdQyYTtxkD58GKtBFkX1/jiM682eAfSB
cIw44yKXto+P/g8BQYi+TgdTMBV/JKX2Oa0B2nhhOl1rHe6T2fKkKAqSN/J7EcYg
/Hx6NQglSos2+r9pk3nofvdBC9nT9KQgqDOGzKuBvPeY7cCbv5BsZlBkKJ46bplt
7IwtXho=
=IaLJ
-----END PGP SIGNATURE-----
Merge tag 'sound-5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
- A further fix for syzcaller issues with USB-audio, addressing NULL
dereference that was introduced by the recent fix
- Avoid a long delay at boot with HD-audio when i915 module was built
but not installed, found on some Debian systems
- A fix of small race window at PCM draining
* tag 'sound-5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: usb-audio: Fix gpf in snd_usb_pipe_sanity_check
ALSA: pcm: fix lost wakeup event scenarios in snd_pcm_drain
ALSA: hda: Fix 1-minute detection delay when i915 module is not available
amdgpu:
navi10 temperature and pstate fixes
vcn dynamic power management fix
CS ioctl error handling fix
debugfs info leak fix
amdkfd VegaM fix.
msm:
dma sync call fix
mdp5 dsi command mode fix
fall-through fixes
disabled GPU fix
nouveau:
regression fix for displayport MST support.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJdQ5SQAAoJEAx081l5xIa+m4gP/jaCuo50oIAoTcKGWi6JM4FB
6dg3peqNSLx+pGnNHOXx3hYUyf2KfUZ2CtTYvab4xFjES//rJOy+HwrtbjVvW0AG
RfFDVHB2Vsz5e23TxVJBkodJwudsuVCUsINHGDg3o9GYOnZDe8bO7aiEiZ7xbFYA
29DOCXuLx8JvN3Gm/HKVrasIY7T3mm84/L1Yo72OhExSipyfGImBsxZ5gW1K7GzO
XL+I8W2h9ViBEsy7DfRGAqn5SwSl81JePf1X73Fl3ZEzMB9drtt/+BsJc2eAfacP
aG3vQL8i1EdzGGMqLZTy0csfr76Bp8hnZIhKdmyYVq2zTGd+J5SCQWlaJ/ov0vTj
dzPMfbLysVzQzxOdQNAkokyM1N+r2QicjR1W8jki/BCGoZhrhoMH3JA9qgxnLVw9
ggem6rMSb5yXnp4JxCOBWZzROON06hdaiGBHAeXqq+mU9DFj/xTqlloUE3Ln/ncs
2HVFxsN6+tNN5vEFzKPPJYk+OpW8+r5UfWJmcpaDfMiuzBWyuqOkw2+DFrfdrQDp
ubDC7O0ZBlhfEcUjHVYbFJc5lv7ip21DxHGEUnDdPdePi+/UKOq6ySDM2yE+rshL
Sg05Ifu17uUGwd2gtDKaIcX9RMxwc8TdSt3CRhAVl2JrCLFsbQwhntWthIHlndmn
OkzCKmsylr2lX19GEh5J
=jOZ/
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2019-08-02' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Thanks to Daniel for handling the email the last couple of weeks, flus
and break-ins combined to derail me. Surprised nothing materialised
today to take me out again.
Just more amdgpu navi fixes, msm fixes and a single nouveau regression
fix:
amdgpu:
- navi10 temperature and pstate fixes
- vcn dynamic power management fix
- CS ioctl error handling fix
- debugfs info leak fix
- amdkfd VegaM fix
msm:
- dma sync call fix
- mdp5 dsi command mode fix
- fall-through fixes
- disabled GPU fix
nouveau:
- regression fix for displayport MST support"
* tag 'drm-fixes-2019-08-02' of git://anongit.freedesktop.org/drm/drm:
drm/nouveau: Only release VCPI slots on mode changes
drm: msm: Fix add_gpu_components
drm/msm: Annotate intentional switch statement fall throughs
drm/msm: add support for per-CRTC max_vblank_count on mdp5
drm/msm: Use the correct dma_sync calls in msm_gem
drm/amd/powerplay: correct UVD/VCE/VCN power status retrieval
drm/amd/powerplay: correct Navi10 VCN powergate control (v2)
drm/amd/powerplay: support VCN powergate status retrieval for SW SMU
drm/amd/powerplay: support VCN powergate status retrieval on Raven
drm/amd/powerplay: add new sensor type for VCN powergate status
drm/amdgpu: fix a potential information leaking bug
drm/amdgpu: fix error handling in amdgpu_cs_process_fence_dep
drm/amd/powerplay: enable SW SMU reset functionality
drm/amd/powerplay: fix null pointer dereference around dpm state relates
drm/amdgpu/powerplay: use proper revision id for navi
drm/amd/powerplay: fix temperature granularity error in smu11
drm/amd/powerplay: add callback function of get_thermal_temperature_range
drm/amdkfd: Fix byte align on VegaM
that started getting exercised differently this time around:
- Select regmap MMIO kconfig in spreadtrum driver to avoid compile
errors
- Complete kerneldoc on devm_clk_bulk_get_optional()
- Register an essential clk earlier on mediatek mt8183 SoCs so
the clocksource driver can use it
- Fix divisor math in the at91 driver
- Plug a race in Renesas reset control logic
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEE9L57QeeUxqYDyoaDrQKIl8bklSUFAl1DH5oRHHNib3lkQGtl
cm5lbC5vcmcACgkQrQKIl8bklSXEiRAAlKgH3gBvg9gtwRuK11qeW/yJYA9/rdF6
nRxMQDq3AA/BktyHpnfDBOHbHs7zmwaeg/bk0x/Ex4+mgdCRe8+X9PJxlgSovenY
8Ky0CAijGxY2Mud/R0YPR2+QVCLYON8cp9SryrWpfokZP4bMqZOKUE6vs2NbeYCa
0iDneX9UUQhvGejEnhgKiuGtiRWPux3htxNlGaHkk/I/z1CvvsfGnxfbAPWN6ppl
txiZDLvtYjGx4tHVWg+olXhyQAMg3JADS1MOx3AcDv7OO5UnfLzdLMp/NLVwqdor
ZmbE2yTdzplGtuoh7waE7Mel6bm/gd94XHsX5S0gJU+ock2wWYoCMMkRGskSJFg3
/Dn7ajNS0Z4xMmdyz+O3kBMB4zu8kiedT07nkwXm+bsFzGK4UEzY6Gn09JP9+m2P
qSzxVLoO5Kg1M4yDIauOX6IyOC0VNgpftdZ4SGoCVqUrH3BYI804I6unbLOF5nad
u4mL0v8Bfz/OuJxuvaFpWCYoowHMi7NOz9ipQRB2bS/QYCB9H6rjv8tT4xAw81w6
P6DI0eG+QCjfHCEbe8W/KikLWSL52fnycwAAospkV+1AFFZ2735oJgb9KY4xY6Qd
tMRLsVjOTnq3mu/PlHuilnyaNtH7OHxp47HoBdgg8kc8VEIsfY+Z7SsPMms228/u
KBzPg709SIk=
=tNyv
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk fixes from Stephen Boyd:
"A few fixes for code that came in during the merge window or that
started getting exercised differently this time around:
- Select regmap MMIO kconfig in spreadtrum driver to avoid compile
errors
- Complete kerneldoc on devm_clk_bulk_get_optional()
- Register an essential clk earlier on mediatek mt8183 SoCs so the
clocksource driver can use it
- Fix divisor math in the at91 driver
- Plug a race in Renesas reset control logic"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: renesas: cpg-mssr: Fix reset control race condition
clk: sprd: Select REGMAP_MMIO to avoid compile errors
clk: mediatek: mt8183: Register 13MHz clock earlier for clocksource
clk: Add missing documentation of devm_clk_bulk_get_optional() argument
clk: at91: generated: Truncate divisor to GENERATED_MAX_DIV + 1
This fixes a cascade of regressions that originally started with
the addition of the ia64 port, but only got fatal once we removed
most uses of block layer bounce buffering in Linux 4.18.
The reason is that while the original i386/PAE code that was the first
architecture that supported > 4GB of memory without an iommu decided to
leave bounce buffering to the subsystems, which in those days just mean
block and networking as no one else consumer arbitrary userspace memory.
Later with ia64, x86_64 and other ports we assumed that either an iommu
or something that fakes it up ("software IOTLB" in beautiful Intel
speak) is present and that subsystems can rely on that for dealing with
addressing limitations in devices. Except that the ARM LPAE scheme
that added larger physical address to 32-bit ARM did not follow that
scheme and thus only worked by chance and only for block and networking
I/O directly to highmem.
Long story, short fix - add swiotlb support to arm when build for LPAE
platforms, which actuallys turns out to be pretty trivial with the
modern dma-direct / swiotlb code to fix the Linux 4.18-ish regression.
-----BEGIN PGP SIGNATURE-----
iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAl1DFj8LHGhjaEBsc3Qu
ZGUACgkQD55TZVIEUYPFqg/+Oh62VCFCkIK07NAeTq6EmrfHI8I1Wm/SFWPOOB+a
vm7nMcSG3C8K8PRHzGc6Zk3SC1+RrHghcyKw54yLT1Mhroakv6Um7p2y8S3M4tmZ
uEg8yYbtzxvuaY9T42s2msZURbBCEELzA2bYbQzgQ1zczRI1zuMI07ssMr91IQ91
HC1OjAUoxUkp/+2uU/X2k6DvPQLSJSyWvKgbi1bjNpE+FRCKJP+2a2K3psBQuDBe
aJXiz/kD2L/JNvF/e4c414d5GnGXwtIYs1kbskmnj3LeToS+JjX+6ZcENorpScIP
c20s/3H6nsb14TFy548rJUlAHdcd9kOdeTw+0oPUliNLCogGs6FKNU4N5gVAo+bC
AWDP0wMHMWkrVz6lQL9PR78IHrHOxFYS5/uHsqqdKo5YTsgaHnwKEiPxX1aiKQ67
ovUrOnGRo4R9Y4YwD+BbHY9qw9jFMqazBdLWMivK5NxqltsahOug8w2emTFfXzQn
m4APJYa0RVJA4mkh3ejcci5qHyyzPOjslyIJn7eaJPV2rknkxRn9UngkgJLnzHfc
+lKiD1zaRy82nV4auPjYRiOdAoQN40YFB/RT16OVkjkT+jJEE2UAMjqh2SRlRusp
Ce8vK7pw6VpDNGJRQveQA+1n9OR/jl0Jf8R7GFRrf9c/bM1J8GErJ6xS/EwNPrgI
5dE=
=D6Uy
-----END PGP SIGNATURE-----
Merge tag 'arm-swiotlb-5.3' of git://git.infradead.org/users/hch/dma-mapping
Pull arm swiotlb support from Christoph Hellwig:
"This fixes a cascade of regressions that originally started with the
addition of the ia64 port, but only got fatal once we removed most
uses of block layer bounce buffering in Linux 4.18.
The reason is that while the original i386/PAE code that was the first
architecture that supported > 4GB of memory without an iommu decided
to leave bounce buffering to the subsystems, which in those days just
mean block and networking as no one else consumed arbitrary userspace
memory.
Later with ia64, x86_64 and other ports we assumed that either an
iommu or something that fakes it up ("software IOTLB" in beautiful
Intel speak) is present and that subsystems can rely on that for
dealing with addressing limitations in devices. Except that the ARM
LPAE scheme that added larger physical address to 32-bit ARM did not
follow that scheme and thus only worked by chance and only for block
and networking I/O directly to highmem.
Long story, short fix - add swiotlb support to arm when build for LPAE
platforms, which actuallys turns out to be pretty trivial with the
modern dma-direct / swiotlb code to fix the Linux 4.18-ish regression"
* tag 'arm-swiotlb-5.3' of git://git.infradead.org/users/hch/dma-mapping:
arm: use swiotlb for bounce buffering on LPAE configs
dma-mapping: check pfn validity in dma_common_{mmap,get_sgtable}
- fix alignment issues introduced in the CMA allocation rework
(Nicolin Chen)
-----BEGIN PGP SIGNATURE-----
iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAl1DE+YLHGhjaEBsc3Qu
ZGUACgkQD55TZVIEUYOrkA//Y7YxsJ9MaI0DNu9gYbYHg9u4ORBWXJ4fN67g2AUe
rdrHdEHyd4uYduy4Ggi65oknfMZms6xYHGaFr1iDforBmOk0CXfvovocHzJkcV/R
gtHSkp0L+SVmsLrWFXjd7pbkVhBziLEVrFlw07FbtBlNIeS2VvcAnU+CUcTKpxNi
7MHhCqxTjVuUZ/qRKyyAnKHGoLCdLqTvpaf1uJq9ca838I/9E5UqitaxL/72G7ab
q/fe93d94Xj3QNk+ekim6xBSD82VPU+OnFUf+f5dELDwyhgI0LAtz6iL8gH+NnK1
P9cIIs2sFyBLXRQEaRXF5KhA97sjlWLioXYWs/AxvCphDeb1Zk4u3uGn0bGt90fQ
g8DryY++nVo6sKpFsaNN7RQ9w/LfxejIcf0hVbNfH6tP8KDO19ds/05kE4O2LUC2
gLOmPMt+dIOJlBQY0fUNrZN/IH6u60LnULmCWDiy7iY7VBJOf+H3zXM0UAJ+XEbs
l2OG5vxkQ4hnFZVD1csNRd9gKYyjhrqOA0VssopgdBS53/seYMNopSbQsMTdp8J7
V3c7Rozz3f62pwxJ7Jd7AwCgpvw8zHOESb5WOzi5DEmxAqRaJQ80H2DdAvQc3orL
x0SummHKX2mY0cJdrFFbXkGoYt3sjJ+J6P+0CP11UIEIqtw4Zfa2hyWmbs8Q9SFt
KYg=
=rM5q
-----END PGP SIGNATURE-----
Merge tag 'dma-mapping-5.3-3' of git://git.infradead.org/users/hch/dma-mapping
Pull dma-mapping regression fixes from Christoph Hellwig:
"Two related regression fixes for changes from this merge window to fix
alignment issues introduced in the CMA allocation rework (Nicolin
Chen)"
* tag 'dma-mapping-5.3-3' of git://git.infradead.org/users/hch/dma-mapping:
dma-contiguous: page-align the size in dma_free_contiguous()
dma-contiguous: do not overwrite align in dma_alloc_contiguous()
. use dev_get_drvdata for readability instead of platform_get_drvdata
. remove redundant assignment to node.
- Two fixup patches
. fix undefined reference to 'vmf_insert_mixed' with NOMMU configuration.
. fix potential infinite spin issue by decrementing 'retry' variable in
scaler_reset function of exynos_drm_scaler.c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJdQ/OtAAoJEFc4NIkMQxK48yQQAIrLBIN88jL0A+gfWjqjGOfO
W66zBigAmKsxz6lT0NTYHyarqrXe3WsdEuAhggUKkilbsRsj6w6DZVnmwlmI7Kly
yfz+WJKZK4X/02hz2smqXiQeYW+a17TsCtnpIOZLJKMIJ/Q3zFNNpVNKl1wQQhmK
KsL7QL9GOQXW3UdqjfGNPdT4e4BHIK0yO4xcaYEzBYg6H7dN9bIeYEiD97FlSiez
DnQGIE6mH0Frii2n+DEPo+LknTUfqOZBAig1SL5JZs8dxhJ7Bl7T2TN3BiMS5MiK
X/A+zn6bKJjhKCiUrzWoNHJMXtvtfOJxCpQKo042Ed4bHOvRV4hRBYIuZBLqsUI1
uYrgSgZoytKY3uyJWXckxmtwOJQDxJJmEbXtifpbwanyHTaExfINTB6IVFgxTQwc
oJ6obP2FeYIn7ehV+0P64eg7RxJYqVUTLirbEwdIs/o6/2yqo+/KcpCx3W294aP4
oyvDVvYPA5vf+4QyNznvK+gRdg79ojXPe4gogFOrFVYSCmhTIOUxT/d/X7PD9OJD
4VwgD2J3vOjG134J7XylyfQLyuYcmYXL5DPf08dY3+tefazOTpDh7tdF2PdHBMny
imBACcjcOWoQnyw77mjFOhoyuhlthzfgnwpEl+sAyDBuypF+6RGHz7/282gvO8iN
XwN/MnasUbowy6RhPpwe
=Qqyg
-----END PGP SIGNATURE-----
Merge tag 'exynos-drm-fixes-for-v5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
- Two cleanup patches
. use dev_get_drvdata for readability instead of platform_get_drvdata
. remove redundant assignment to node.
- Two fixup patches
. fix undefined reference to 'vmf_insert_mixed' with NOMMU configuration.
. fix potential infinite spin issue by decrementing 'retry' variable in
scaler_reset function of exynos_drm_scaler.c
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Inki Dae <inki.dae@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1564734791-745-1-git-send-email-inki.dae@samsung.com
commit 7e9e5ead55 ("drm/vgem: fix cache synchronization on arm/arm64")
broke all of the !llc i915-vgem coherency tests in CI, and left the HW
very, very unhappy (which is even more scary).
Fixes: 7e9e5ead55 ("drm/vgem: fix cache synchronization on arm/arm64")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rob Clark <robdclark@chromium.org>
Cc: Sean Paul <seanpaul@chromium.org>
Acked-by: Sean Paul <sean@poorly.run>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190801124458.24949-1-chris@chris-wilson.co.uk
- Fix some build errors in drm/bridge.
- Do not build i810 on CONFIG_PREEMPTION.
- Fix cache sync on arm in vgem.
- Allow mapping fb in drm_client only when required, and use it to fix bochs fbdev.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAl1EPe0ACgkQ/lWMcqZw
E8NwlBAAg3698yPzGFKuXQ+LDpcgUA0zL+j2uvpQjmOYsyZCIAkT8gzKP9Z+vySx
ga7mm15uCDE4J3WFYBMIsI3m+r0d3Fdyt2l/r7TTjnNMBE0/X8rtpCb5EWWLuCbf
t6hX4gfwMXz5li7EcQKVq+oeOSuqQV8fPJYgJgdub8ePft3yx3QNDRLBz+BRDap9
NQEwaY0XwYq2PWGx5sNP6Ku8E1tIOzit+UGonkBnYy6RmZ9CPSiR2QIFN3llJ00+
UhGWcr+CXljIj1CkaDJA/f6FDVBo5dbGkhSJUHirB0csDnvq4ena5xKg8FGFAQ3e
RLKMwRbTXKHlTY/wxl9iibUR2wNA0DnQYIeWBBaEGpUtnjmMgzugPWGXWm6+qIZ2
zl2k2cTSJmgubzABY+FSI27MwYpgqT9Bh5pceJitx4/ijojgdN+KzkN5Nlw7XcAt
ejRbIdfMrtN6XRgoNtliBNyfzLccb4ONNQNbvKYTo6pIxbgSnlnHGF+VIxPUvBnN
oEbd7OcjaBEU0eL0gZWAFlFeZlMvqaYk1dlC4wMqPECIDMTJV6F5CyXILq2PVjMj
+i2+5Twqa2L7naOFedn0B6wfaVAiXtR5VZ9lzXc8l5L8KpF46Yajx/ndAn+iGAWC
ERiqwMvhCy6eK9JUbEyhrL+NPiIxTsbgV+VD4cLsFtkh2cR484I=
=oX0Q
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2019-08-02' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
drm-misc-fixes for v5.3-rc3:
- Fix some build errors in drm/bridge.
- Do not build i810 on CONFIG_PREEMPTION.
- Fix cache sync on arm in vgem.
- Allow mapping fb in drm_client only when required, and use it to fix bochs fbdev.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/af0dc371-16e0-cee8-0d71-4824d44aa973@linux.intel.com
Silence the following warnings when built with -Wimplicit-fallthrough=3
enabled by default since 5.3-rc2:
In file included from ./include/linux/preempt.h:11,
from ./include/linux/spinlock.h:51,
from ./include/linux/mmzone.h:8,
from ./include/linux/gfp.h:6,
from ./include/linux/slab.h:15,
from drivers/s390/crypto/ap_queue.c:13:
drivers/s390/crypto/ap_queue.c: In function 'ap_sm_recv':
./include/linux/list.h:577:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
577 | for (pos = list_first_entry(head, typeof(*pos), member); \
| ^~~
drivers/s390/crypto/ap_queue.c:147:3: note: in expansion of macro 'list_for_each_entry'
147 | list_for_each_entry(ap_msg, &aq->pendingq, list) {
| ^~~~~~~~~~~~~~~~~~~
drivers/s390/crypto/ap_queue.c:155:2: note: here
155 | case AP_RESPONSE_NO_PENDING_REPLY:
| ^~~~
drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_ep11_xcrb':
drivers/s390/crypto/zcrypt_msgtype6.c:871:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
871 | if (msg->cprbx.cprb_ver_id == 0x04)
| ^
drivers/s390/crypto/zcrypt_msgtype6.c:874:2: note: here
874 | default: /* Unknown response type, this should NEVER EVER happen */
| ^~~~~~~
drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_rng':
drivers/s390/crypto/zcrypt_msgtype6.c:901:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
901 | if (msg->cprbx.cprb_ver_id == 0x02)
| ^
drivers/s390/crypto/zcrypt_msgtype6.c:907:2: note: here
907 | default: /* Unknown response type, this should NEVER EVER happen */
| ^~~~~~~
drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_xcrb':
drivers/s390/crypto/zcrypt_msgtype6.c:838:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
838 | if (msg->cprbx.cprb_ver_id == 0x02)
| ^
drivers/s390/crypto/zcrypt_msgtype6.c:844:2: note: here
844 | default: /* Unknown response type, this should NEVER EVER happen */
| ^~~~~~~
drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_ica':
drivers/s390/crypto/zcrypt_msgtype6.c:801:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
801 | if (msg->cprbx.cprb_ver_id == 0x02)
| ^
drivers/s390/crypto/zcrypt_msgtype6.c:808:2: note: here
808 | default: /* Unknown response type, this should NEVER EVER happen */
| ^~~~~~~
Acked-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Make debug exceptions visible from RCU so that synchronize_rcu()
correctly track the debug exception handler.
This also introduces sanity checks for user-mode exceptions as same
as x86's ist_enter()/ist_exit().
The debug exception can interrupt in idle task. For example, it warns
if we put a kprobe on a function called from idle task as below.
The warning message showed that the rcu_read_lock() caused this
problem. But actually, this means the RCU is lost the context which
is already in NMI/IRQ.
/sys/kernel/debug/tracing # echo p default_idle_call >> kprobe_events
/sys/kernel/debug/tracing # echo 1 > events/kprobes/enable
/sys/kernel/debug/tracing # [ 135.122237]
[ 135.125035] =============================
[ 135.125310] WARNING: suspicious RCU usage
[ 135.125581] 5.2.0-08445-g9187c508bdc7 #20 Not tainted
[ 135.125904] -----------------------------
[ 135.126205] include/linux/rcupdate.h:594 rcu_read_lock() used illegally while idle!
[ 135.126839]
[ 135.126839] other info that might help us debug this:
[ 135.126839]
[ 135.127410]
[ 135.127410] RCU used illegally from idle CPU!
[ 135.127410] rcu_scheduler_active = 2, debug_locks = 1
[ 135.128114] RCU used illegally from extended quiescent state!
[ 135.128555] 1 lock held by swapper/0/0:
[ 135.128944] #0: (____ptrval____) (rcu_read_lock){....}, at: call_break_hook+0x0/0x178
[ 135.130499]
[ 135.130499] stack backtrace:
[ 135.131192] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.2.0-08445-g9187c508bdc7 #20
[ 135.131841] Hardware name: linux,dummy-virt (DT)
[ 135.132224] Call trace:
[ 135.132491] dump_backtrace+0x0/0x140
[ 135.132806] show_stack+0x24/0x30
[ 135.133133] dump_stack+0xc4/0x10c
[ 135.133726] lockdep_rcu_suspicious+0xf8/0x108
[ 135.134171] call_break_hook+0x170/0x178
[ 135.134486] brk_handler+0x28/0x68
[ 135.134792] do_debug_exception+0x90/0x150
[ 135.135051] el1_dbg+0x18/0x8c
[ 135.135260] default_idle_call+0x0/0x44
[ 135.135516] cpu_startup_entry+0x2c/0x30
[ 135.135815] rest_init+0x1b0/0x280
[ 135.136044] arch_call_rest_init+0x14/0x1c
[ 135.136305] start_kernel+0x4d4/0x500
[ 135.136597]
So make debug exception visible to RCU can fix this warning.
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
kprobes manipulates the interrupted PSTATE for single step, and
doesn't restore it. Thus, if we put a kprobe where the pstate.D
(debug) masked, the mask will be cleared after the kprobe hits.
Moreover, in the most complicated case, this can lead a kernel
crash with below message when a nested kprobe hits.
[ 152.118921] Unexpected kernel single-step exception at EL1
When the 1st kprobe hits, do_debug_exception() will be called.
At this point, debug exception (= pstate.D) must be masked (=1).
But if another kprobes hits before single-step of the first kprobe
(e.g. inside user pre_handler), it unmask the debug exception
(pstate.D = 0) and return.
Then, when the 1st kprobe setting up single-step, it saves current
DAIF, mask DAIF, enable single-step, and restore DAIF.
However, since "D" flag in DAIF is cleared by the 2nd kprobe, the
single-step exception happens soon after restoring DAIF.
This has been introduced by commit 7419333fa1 ("arm64: kprobe:
Always clear pstate.D in breakpoint exception handler")
To solve this issue, this stores all DAIF bits and restore it
after single stepping.
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Fixes: 7419333fa1 ("arm64: kprobe: Always clear pstate.D in breakpoint exception handler")
Reviewed-by: James Morse <james.morse@arm.com>
Tested-by: James Morse <james.morse@arm.com>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Currently the retry counter is not being decremented, leading to a
potential infinite spin if the scalar_reads don't change state.
Addresses-Coverity: ("Infinite loop")
Fixes: 280e54c9f6 ("drm/exynos: scaler: Reset hardware before starting the operation")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Compile-testing this driver on a NOMMU configuration shows a link failure:
drivers/gpu/drm/exynos/exynos_drm_gem.o: In function `exynos_drm_gem_fault':
exynos_drm_gem.c:(.text+0x484): undefined reference to `vmf_insert_mixed'
Add a CONFIG_MMU dependency to ensure we only enable this in configurations
that build correctly.
Many other drm drivers have the same dependency. It would be nice to
make this work in MMU-less configurations, but evidently nobody has
ever needed this so far.
Fixes: 156bdac990 ("drm/exynos: trigger build of all modules")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Inki Dae <daeinki@gmail.com>
The pointer 'node' is being assigned with a value that is never
read and is re-assigned later. The assignment is redundant and
can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Inki Dae <daeinki@gmail.com>
Several drivers cast a struct device pointer to a struct
platform_device pointer only to then call platform_get_drvdata().
To improve readability, these constructs can be simplified
by using dev_get_drvdata() directly.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
After getting a storage server event that causes the DASD device driver
to update its unit address configuration during a device shutdown there is
the possibility of an endless loop in the device driver.
In the system log there will be ongoing DASD error messages with RC: -19.
The reason is that the loop starting the ruac request only terminates when
the retry counter is decreased to 0. But in the sleep_on function there are
early exit paths that do not decrease the retry counter.
Prevent an endless loop by handling those cases separately.
Remove the unnecessary do..while loop since the sleep_on function takes
care of retries by itself.
Fixes: 8e09f21574 ("[S390] dasd: add hyper PAV support to DASD device driver, part 1")
Cc: stable@vger.kernel.org # 2.6.25+
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
- Fix mdp5 dsi command mode (Brian)
- Squash fall through warnings (Jordan)
- Don't add disabled gpu nodes to the of device list (Jeffrey)
Cc: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Cc: Jordan Crouse <jcrouse@codeaurora.org>
Cc: Brian Masney <masneyb@onstation.org>
Cc: Rob Clark <robdclark@chromium.org>
-----BEGIN PGP SIGNATURE-----
iQFKBAABCgA0FiEEfxcpfMSgdnQMs+QqlvcN/ahKBwoFAl1DQ3MWHHNlYW5wYXVs
QGNocm9taXVtLm9yZwAKCRCW9w39qEoHCtmoB/9Qesjz6sh2CZ8PhehHi2hLniiY
33ojx73lPkAPY2INbSTMiPFyCRvB9emvIYG68nkHNX+Ey7ZjQIzXenuzFLLFfO5P
jS3phHs2UtFfMAfOaxApF11vtnwzGQu3GqpLnoC80DzcLzpDAXJgaV608LcTwzug
48NHVvG7pzOKyPOyVQG5q/YJ1H8hqr7rxSdAfOlradCwoo3PoNxIU2ieqF0YrrmV
nn18E4XpTS9PRS+zxl4KPVIivHg1HS+Ii23V6C+y5fPEW/lVO2WOahm1wW/WD5Mt
07o0WOZkU4qLjAmLyWgmzpLlZ/Scl2WIhje2Z5EkpD+o7wVlOaqA2tge3OTZ
=aA5E
-----END PGP SIGNATURE-----
Merge tag 'msm-fixes-2019_08_01' of https://gitlab.freedesktop.org/drm/msm into drm-fixes
- Fix the dma_sync calls applied last week (Rob)
- Fix mdp5 dsi command mode (Brian)
- Squash fall through warnings (Jordan)
- Don't add disabled gpu nodes to the of device list (Jeffrey)
Cc: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Cc: Jordan Crouse <jcrouse@codeaurora.org>
Cc: Brian Masney <masneyb@onstation.org>
Cc: Rob Clark <robdclark@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
# gpg: Signature made Fri 02 Aug 2019 05:54:27 AM AEST
# gpg: using RSA key 96F70DFDA84A070A
# gpg: Can't check signature: public key not found
From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20190801200439.GV104440@art_vandelay
Looks like a regression got introduced into nv50_mstc_atomic_check()
that somehow didn't get found until now. If userspace changes
crtc_state->active to false but leaves the CRTC enabled, we end up
calling drm_dp_atomic_find_vcpi_slots() using the PBN calculated in
asyh->dp.pbn. However, if the display is inactive we end up calculating
a PBN of 0, which inadvertently causes us to have an allocation of 0.
>From there, if userspace then disables the CRTC afterwards we end up
accidentally attempting to free the VCPI twice:
WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336
drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper]
RIP: 0010:drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper]
Call Trace:
drm_atomic_helper_check_modeset+0x3f3/0xa60 [drm_kms_helper]
? drm_atomic_check_only+0x43/0x780 [drm]
drm_atomic_helper_check+0x15/0x90 [drm_kms_helper]
nv50_disp_atomic_check+0x83/0x1d0 [nouveau]
drm_atomic_check_only+0x54d/0x780 [drm]
? drm_atomic_set_crtc_for_connector+0xec/0x100 [drm]
drm_atomic_commit+0x13/0x50 [drm]
drm_atomic_helper_set_config+0x81/0x90 [drm_kms_helper]
drm_mode_setcrtc+0x194/0x6a0 [drm]
? vprintk_emit+0x16a/0x230
? drm_ioctl+0x163/0x390 [drm]
? drm_mode_getcrtc+0x180/0x180 [drm]
drm_ioctl_kernel+0xaa/0xf0 [drm]
drm_ioctl+0x208/0x390 [drm]
? drm_mode_getcrtc+0x180/0x180 [drm]
nouveau_drm_ioctl+0x63/0xb0 [nouveau]
do_vfs_ioctl+0x405/0x660
? recalc_sigpending+0x17/0x50
? _copy_from_user+0x37/0x60
ksys_ioctl+0x5e/0x90
? exit_to_usermode_loop+0x92/0xe0
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x59/0x190
entry_SYSCALL_64_after_hwframe+0x44/0xa9
WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336
drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper]
---[ end trace 4c395c0c51b1f88d ]---
[drm:drm_dp_atomic_release_vcpi_slots [drm_kms_helper]] *ERROR* no VCPI for
[MST PORT:00000000e288eb7d] found in mst state 000000008e642070
So, fix this by doing what we probably should have done from the start: only
call drm_dp_atomic_find_vcpi_slots() when crtc_state->mode_changed is set, so
that VCPI allocations remain for as long as the CRTC is enabled.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 232c9eec41 ("drm/nouveau: Use atomic VCPI helpers for MST")
Cc: Lyude Paul <lyude@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@redhat.com>
Cc: Jerry Zuo <Jerry.Zuo@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Juston Li <juston.li@intel.com>
Cc: Karol Herbst <karolherbst@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: <stable@vger.kernel.org> # v5.1+
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190801220216.15323-1-lyude@redhat.com
drm-fixes-5.3-2019-07-31:
amdgpu:
- Fix temperature granularity for navi
- Fix stable pstate setting for navi
- Fix VCN DPM enablement on navi
- Fix error handling on CS ioctl when processing dependencies
- Fix possible information leak in debugfs
amdkfd:
- fix memory alignment for VegaM
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190731191648.25729-1-alexander.deucher@amd.com
Commit f850a48a07 ("ACPI: PM: Allow transitions to D0 to occur in
special cases") overlooked the fact that acpi_power_transition() may
change the power.state value for the target device and if that
happens, it may confuse acpi_device_set_power() and cause it to
omit the _PS0 evaluation which on some systems is necessary to
change power states of devices from low-power to D0.
Fix that by saving the current value of power.state for the
target device before passing it to acpi_power_transition() and
using the saved value in a subsequent check.
Fixes: f850a48a07 ("ACPI: PM: Allow transitions to D0 to occur in special cases")
Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Reported-by: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Mario Limonciello <mario.limonciello@dell.com>
Mark switch cases where we are expecting to fall through.
This patch fixes the following warning:
drivers/i2c/busses/i2c-s3c2410.c: In function 'i2c_s3c_irq_nextbyte':
drivers/i2c/busses/i2c-s3c2410.c:431:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (i2c->state == STATE_READ)
^
drivers/i2c/busses/i2c-s3c2410.c:439:2: note: here
case STATE_WRITE:
^~~~
Notice that, in this particular case, the code comment is
modified in accordance with what GCC is expecting to find.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
In SAMA5D2 datasheet, TWIHS_CWGR register rescription mentions clock
offset of 3 cycles (compared to 4 in eg. SAMA5D3).
Cc: stable@vger.kernel.org # 5.2.x
[needs applying to i2c-at91.c instead for earlier kernels]
Fixes: 0ef6f3213d ("i2c: at91: add support for new alternative command mode")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Driver was not disabling TXRDY interrupt after last TX byte.
This caused interrupt storm until transfer timeouts for slow
or broken device on the bus. The patch fixes the interrupt storm
on my SAMA5D2-based board.
Cc: stable@vger.kernel.org # 5.2.x
[v5.2 introduced file split; the patch should apply to i2c-at91.c before the split]
Fixes: fac368a040 ("i2c: at91: add new driver")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Tested-by: Raag Jadav <raagjadav@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The recent fix to properly handle IOCB_NOWAIT for async O_DIRECT IO
(patch 6a43074e2f) introduced two problems with BIO fragment handling
for direct IOs:
1) The dio size processed is calculated by incrementing the ret variable
by the size of the bio fragment issued for the dio. However, this size
is obtained directly from bio->bi_iter.bi_size AFTER the bio submission
which may result in referencing the bi_size value after the bio
completed, resulting in an incorrect value use.
2) The ret variable is not incremented by the size of the last bio
fragment issued for the bio, leading to an invalid IO size being
returned to the user.
Fix both problem by using dio->size (which is incremented before the bio
submission) to update the value of ret after bio submissions, including
for the last bio fragment issued.
Fixes: 6a43074e2f ("block: properly handle IOCB_NOWAIT for async O_DIRECT IO")
Reported-by: Masato Suzuki <masato.suzuki@wdc.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
- Fix a couple of UAF on error paths (RZA1, GICv3 ITS)
- Fix iMX GPCv2 trigger setting
- Add missing of_node_put on error path in MBIGEN
- Add another bunch of /* fall-through */ to silence warnings
-----BEGIN PGP SIGNATURE-----
iQJDBAABCgAtFiEEn9UcU+C1Yxj9lZw9I9DQutE9ekMFAl1B0ysPHG1hekBrZXJu
ZWwub3JnAAoJECPQ0LrRPXpDEq0P/19TlvVhBzRBQ7xrZsh7RYGYddgHZeYxEwcJ
iZaZnEwYPqrQXS7UIOyMmpdhDOE89sntgCfQWWhPqZdVMAPPAanucbcIA9vNxy+U
OI9ue90Eeo5MAm7T2qp3MgEROQ21npYeTNGPHM6Rhh3twbsLX5S7rQCOZBeuY1zT
l9FGOUsUgYfUgdEGAv4wZLdIakfTbwAlk+9QaryEn7leu4s/vzHIdyMmJ/RDlt/i
YPWFD4XfDV8WSE0CE88oy1T4ppD8e71C6LjS+NfJsY5brUGPDvcbllCm3tFudy/9
D/4kM6yjpNIGZK23p5ux8dBTZB/9+z/PadFJc6J78cFH+IMf2Clv40GrZ50cG8MK
GIDBgwGmooUU+vsmTTPeqtEn30CIyVGb1AkoZnTR/vRltsg0zaLhuqIHnhLTo5av
dEeTv1sBOcPR3b4NkX4WAHd5UJrF/a3/fSdW9h95rF/xlP3fto5lhRmtI9UOqlra
1X+GJXRWoEbMvLP75PlSOQkDiG8zKko9/5JX/da5Q0Qztl/gZPFaGexL/c36DLoJ
kKuHut/1TXu3xfoGPotYm8mainSHkEF1OThCOWX6sjS4m9JMYZMejjg9l1pNXfKw
lZVKKygYOwOeBubsYqmVOEliFai2EggSWmq77csu5FP84M/8JNRX+69yQLO0Cwea
ukYEvrvA
=oXHS
-----END PGP SIGNATURE-----
Merge tag 'irqchip-fixes-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent
Pull irqchip fixes from Marc Zyngier:
A small bunch of fixes from the irqchip department:
- Fix a couple of UAF on error paths (RZA1, GICv3 ITS)
- Fix iMX GPCv2 trigger setting
- Add missing of_node_put on error path in MBIGEN
- Add another bunch of /* fall-through */ to silence warnings
This LSM was added in v5.1 and needs an entry in the MAINTAINERS file.
Signed-off-by: Micah Morton <mortonm@chromium.org>
Acked-by: James Morris <jamorris@linux.microsoft.com>
Fix to return error code -ENOMEM from the rdma_zalloc_drv_obj() error
handling case instead of 0, as done elsewhere in this function.
Fixes: e8ac9389f0 ("RDMA: Fix allocation failure on pointer pd")
Fixes: 21a428a019 ("RDMA: Handle PD allocations by IB/core")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Link: https://lore.kernel.org/r/20190801012725.150493-1-weiyongjun1@huawei.com
Signed-off-by: Doug Ledford <dledford@redhat.com>
add_gpu_components() adds found GPU nodes from the DT to the match list,
regardless of the status of the nodes. This is a problem, because if the
nodes are disabled, they should not be on the match list because they will
not be matched. This prevents display from initing if a GPU node is
defined, but it's status is disabled.
Fix this by checking the node's status before adding it to the match list.
Fixes: dc3ea265b8 (drm/msm: Drop the gpu binding)
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626180015.45242-1-jeffrey.l.hugo@gmail.com
sl is controlled by user-space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.
Fix this by sanitizing sl before using it to index ibp->sl_to_sc.
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20190731175428.GA16736@embeddedor
Signed-off-by: Doug Ledford <dledford@redhat.com>
We encountered a use-after-free bug when unloading the driver:
[ 3562.116059] BUG: KASAN: use-after-free in ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
[ 3562.117233] Read of size 4 at addr ffff8882ca5aa868 by task kworker/u13:2/23862
[ 3562.118385]
[ 3562.119519] CPU: 2 PID: 23862 Comm: kworker/u13:2 Tainted: G OE 5.1.0-for-upstream-dbg-2019-05-19_16-44-30-13 #1
[ 3562.121806] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014
[ 3562.123075] Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
[ 3562.124383] Call Trace:
[ 3562.125640] dump_stack+0x9a/0xeb
[ 3562.126911] print_address_description+0xe3/0x2e0
[ 3562.128223] ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
[ 3562.129545] __kasan_report+0x15c/0x1df
[ 3562.130866] ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
[ 3562.132174] kasan_report+0xe/0x20
[ 3562.133514] ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
[ 3562.134835] ? find_mad_agent+0xa00/0xa00 [ib_core]
[ 3562.136158] ? qlist_free_all+0x51/0xb0
[ 3562.137498] ? mlx4_ib_sqp_comp_worker+0x1970/0x1970 [mlx4_ib]
[ 3562.138833] ? quarantine_reduce+0x1fa/0x270
[ 3562.140171] ? kasan_unpoison_shadow+0x30/0x40
[ 3562.141522] ib_mad_recv_done+0xdf6/0x3000 [ib_core]
[ 3562.142880] ? _raw_spin_unlock_irqrestore+0x46/0x70
[ 3562.144277] ? ib_mad_send_done+0x1810/0x1810 [ib_core]
[ 3562.145649] ? mlx4_ib_destroy_cq+0x2a0/0x2a0 [mlx4_ib]
[ 3562.147008] ? _raw_spin_unlock_irqrestore+0x46/0x70
[ 3562.148380] ? debug_object_deactivate+0x2b9/0x4a0
[ 3562.149814] __ib_process_cq+0xe2/0x1d0 [ib_core]
[ 3562.151195] ib_cq_poll_work+0x45/0xf0 [ib_core]
[ 3562.152577] process_one_work+0x90c/0x1860
[ 3562.153959] ? pwq_dec_nr_in_flight+0x320/0x320
[ 3562.155320] worker_thread+0x87/0xbb0
[ 3562.156687] ? __kthread_parkme+0xb6/0x180
[ 3562.158058] ? process_one_work+0x1860/0x1860
[ 3562.159429] kthread+0x320/0x3e0
[ 3562.161391] ? kthread_park+0x120/0x120
[ 3562.162744] ret_from_fork+0x24/0x30
...
[ 3562.187615] Freed by task 31682:
[ 3562.188602] save_stack+0x19/0x80
[ 3562.189586] __kasan_slab_free+0x11d/0x160
[ 3562.190571] kfree+0xf5/0x2f0
[ 3562.191552] ib_mad_port_close+0x200/0x380 [ib_core]
[ 3562.192538] ib_mad_remove_device+0xf0/0x230 [ib_core]
[ 3562.193538] remove_client_context+0xa6/0xe0 [ib_core]
[ 3562.194514] disable_device+0x14e/0x260 [ib_core]
[ 3562.195488] __ib_unregister_device+0x79/0x150 [ib_core]
[ 3562.196462] ib_unregister_device+0x21/0x30 [ib_core]
[ 3562.197439] mlx4_ib_remove+0x162/0x690 [mlx4_ib]
[ 3562.198408] mlx4_remove_device+0x204/0x2c0 [mlx4_core]
[ 3562.199381] mlx4_unregister_interface+0x49/0x1d0 [mlx4_core]
[ 3562.200356] mlx4_ib_cleanup+0xc/0x1d [mlx4_ib]
[ 3562.201329] __x64_sys_delete_module+0x2d2/0x400
[ 3562.202288] do_syscall_64+0x95/0x470
[ 3562.203277] entry_SYSCALL_64_after_hwframe+0x49/0xbe
The problem was that the MAD PD was deallocated before the MAD CQ.
There was completion work pending for the CQ when the PD got deallocated.
When the mad completion handling reached procedure
ib_mad_post_receive_mads(), we got a use-after-free bug in the following
line of code in that procedure:
sg_list.lkey = qp_info->port_priv->pd->local_dma_lkey;
(the pd pointer in the above line is no longer valid, because the
pd has been deallocated).
We fix this by allocating the PD before the CQ in procedure
ib_mad_port_open(), and deallocating the PD after freeing the CQ
in procedure ib_mad_port_close().
Since the CQ completion work queue is flushed during ib_free_cq(),
no completions will be pending for that CQ when the PD is later
deallocated.
Note that freeing the CQ before deallocating the PD is the practice
in the ULPs.
Fixes: 4be90bc60d ("IB/mad: Remove ib_get_dma_mr calls")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Link: https://lore.kernel.org/r/20190801121449.24973-1-leon@kernel.org
Signed-off-by: Doug Ledford <dledford@redhat.com>
The check for QP type different than XRC has excluded driver QP
types from the resource tracker.
As a result, "rdma resource show" user command would not show opened
driver QPs which does not reflect the real state of the system.
Check QP type explicitly instead of assuming enum values/ordering.
Fixes: 40909f664d ("RDMA/efa: Add EFA verbs implementation")
Signed-off-by: Gal Pressman <galpress@amazon.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Link: https://lore.kernel.org/r/20190801104354.11417-1-galpress@amazon.com
Signed-off-by: Doug Ledford <dledford@redhat.com>
Driver shouldn't allow to use UMR to register a MR when
umr_modify_atomic_disabled is set. Otherwise it will always end up with a
failure in the post send flow which sets the UMR WQE to modify atomic access
right.
Fixes: c8d75a980f ("IB/mlx5: Respect new UMR capabilities")
Signed-off-by: Guy Levi <guyle@mellanox.com>
Reviewed-by: Moni Shoua <monis@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Link: https://lore.kernel.org/r/20190731081929.32559-1-leon@kernel.org
Signed-off-by: Doug Ledford <dledford@redhat.com>
Due to the complexity of client->remove() callbacks it is desirable to not
hold any locks while calling them. Remove the last one by tracking only
the highest client ID and running backwards from there over the xarray.
Since the only purpose of that lock was to protect the linked list, we can
drop the lock.
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Link: https://lore.kernel.org/r/20190731081841.32345-3-leon@kernel.org
Signed-off-by: Doug Ledford <dledford@redhat.com>
lockdep reports:
WARNING: possible circular locking dependency detected
modprobe/302 is trying to acquire lock:
0000000007c8919c ((wq_completion)ib_cm){+.+.}, at: flush_workqueue+0xdf/0x990
but task is already holding lock:
000000002d3d2ca9 (&device->client_data_rwsem){++++}, at: remove_client_context+0x79/0xd0 [ib_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&device->client_data_rwsem){++++}:
down_read+0x3f/0x160
ib_get_net_dev_by_params+0xd5/0x200 [ib_core]
cma_ib_req_handler+0x5f6/0x2090 [rdma_cm]
cm_process_work+0x29/0x110 [ib_cm]
cm_req_handler+0x10f5/0x1c00 [ib_cm]
cm_work_handler+0x54c/0x311d [ib_cm]
process_one_work+0x4aa/0xa30
worker_thread+0x62/0x5b0
kthread+0x1ca/0x1f0
ret_from_fork+0x24/0x30
-> #1 ((work_completion)(&(&work->work)->work)){+.+.}:
process_one_work+0x45f/0xa30
worker_thread+0x62/0x5b0
kthread+0x1ca/0x1f0
ret_from_fork+0x24/0x30
-> #0 ((wq_completion)ib_cm){+.+.}:
lock_acquire+0xc8/0x1d0
flush_workqueue+0x102/0x990
cm_remove_one+0x30e/0x3c0 [ib_cm]
remove_client_context+0x94/0xd0 [ib_core]
disable_device+0x10a/0x1f0 [ib_core]
__ib_unregister_device+0x5a/0xe0 [ib_core]
ib_unregister_device+0x21/0x30 [ib_core]
mlx5_ib_stage_ib_reg_cleanup+0x9/0x10 [mlx5_ib]
__mlx5_ib_remove+0x3d/0x70 [mlx5_ib]
mlx5_ib_remove+0x12e/0x140 [mlx5_ib]
mlx5_remove_device+0x144/0x150 [mlx5_core]
mlx5_unregister_interface+0x3f/0xf0 [mlx5_core]
mlx5_ib_cleanup+0x10/0x3a [mlx5_ib]
__x64_sys_delete_module+0x227/0x350
do_syscall_64+0xc3/0x6a4
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Which is due to the read side of the client_data_rwsem being obtained
recursively through a work queue flush during cm client removal.
The lock is being held across the remove in remove_client_context() so
that the function is a fence, once it returns the client is removed. This
is required so that the two callers do not proceed with destruction until
the client completes removal.
Instead of using client_data_rwsem use the existing device unregistration
refcount and add a similar client unregistration (client->uses) refcount.
This will fence the two unregistration paths without holding any locks.
Cc: <stable@vger.kernel.org>
Fixes: 921eab1143 ("RDMA/devices: Re-organize device.c locking")
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Link: https://lore.kernel.org/r/20190731081841.32345-2-leon@kernel.org
Signed-off-by: Doug Ledford <dledford@redhat.com>
Some processors may mispredict an array bounds check and
speculatively access memory that they should not. With
a user supplied array index we like to play things safe
by masking the value with the array size before it is
used as an index.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Link: https://lore.kernel.org/r/20190731043957.GA1600@agluck-desk2.amr.corp.intel.com
Signed-off-by: Doug Ledford <dledford@redhat.com>
When CONFIG_KASAN_SW_TAGS=n, set_tag() is compiled away. GCC throws a
warning,
mm/kasan/common.c: In function '__kasan_kmalloc':
mm/kasan/common.c:464:5: warning: variable 'tag' set but not used
[-Wunused-but-set-variable]
u8 tag = 0xff;
^~~
Fix it by making __tag_set() a static inline function the same as
arch_kasan_set_tag() in mm/kasan/kasan.h for consistency because there
is a macro in arch/arm64/include/asm/kasan.h,
#define arch_kasan_set_tag(addr, tag) __tag_set(addr, tag)
However, when CONFIG_DEBUG_VIRTUAL=n and CONFIG_SPARSEMEM_VMEMMAP=y,
page_to_virt() will call __tag_set() with incorrect type of a
parameter, so fix that as well. Also, still let page_to_virt() return
"void *" instead of "const void *", so will not need to add a similar
cast in lowmem_page_address().
Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: Will Deacon <will@kernel.org>
The mdp5 drm/kms driver currently does not work on command-mode DSI
panels due to 'vblank wait timed out' errors. This causes a latency
of seconds, or tens of seconds in some cases, before content is shown
on the panel. This hardware does not have the something that we can use
as a frame counter available when running in command mode, so we need to
fall back to using timestamps by setting the max_vblank_count to zero.
This can be done on a per-CRTC basis, so the convert mdp5 to use
drm_crtc_set_max_vblank_count().
This change was tested on a LG Nexus 5 (hammerhead) phone.
Suggested-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Reviewed-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Signed-off-by: Brian Masney <masneyb@onstation.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190531094619.31704-3-masneyb@onstation.org
GCC throws a warning,
arch/arm64/mm/mmu.c: In function 'pud_free_pmd_page':
arch/arm64/mm/mmu.c:1033:8: warning: variable 'pud' set but not used
[-Wunused-but-set-variable]
pud_t pud;
^~~
because pud_table() is a macro and compiled away. Fix it by making it a
static inline function and for pud_sect() as well.
Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: Will Deacon <will@kernel.org>
Remove rcu_read_lock()/rcu_read_unlock() from debug exception
handlers since we are sure those are not preemptible and
interrupts are off.
Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Prohibit probing on return_address() and subroutines which
is called from return_address(), since the it is invoked from
trace_hardirqs_off() which is also kprobe blacklisted.
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
