Add a new parameter to complement the existing 'netmask' option. The
main difference between netmask and bitmask is that bitmask takes any
arbitrary ip address as input, it does not have to be a valid netmask.
The name of the new parameter is 'bitmask'. This lets us mask out
arbitrary bits in the ip address, for example:
ipset create set1 hash:ip bitmask 255.128.255.0
ipset create set2 hash:ip,port family inet6 bitmask ffff::ff80
Signed-off-by: Vishwanath Pai <vpai@akamai.com>
Signed-off-by: Joshua Hunt <johunt@akamai.com>
Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
No need to have distinct functions. After merge, ipv6 can avoid
protooff computation if the connection neither needs sequence adjustment
nor helper invocation -- this is the normal case.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
These are the interconnect changes for the 6.2-rc1 merge window consisting
of new drivers to enable both L3 and DDR scaling on sc8280xp platforms.
There are also a few miscellaneous fixes.
New osm-l3 driver:
- interconnect: qcom: osm-l3: Use platform-independent node ids
- interconnect: qcom: osm-l3: Squash common descriptors
- interconnect: qcom: osm-l3: Add per-core EPSS L3 support
- interconnect: qcom: osm-l3: Simplify osm_l3_set()
- dt-bindings: interconnect: Add sm8350, sc8280xp and generic OSM L3 compatibles
- dt-bindings: interconnect: qcom,msm8998-bwmon: Add sc8280xp bwmon instances
Fixes:
- interconnect: qcom: icc-rpm: Remove redundant dev_err call
- interconnect: qcom: sc7180: fix dropped const of qcom_icc_bcm
- interconnect: qcom: sc7180: drop double space
- interconnect: qcom: sc8180x: constify pointer to qcom_icc_node
Signed-off-by: Georgi Djakov <djakov@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJjh0p9AAoJEIDQzArG2BZjQwsP+QGuJ9iJhNHR6zHR+5fu6wdJ
m9lMsCP93gjZarR1+5elTtORNKeLe25UqGAAtOT0zE9yQX5c94ufKi8BI1+50RyO
AD56/9rGRbUwu6AyP7MfqoalPyFpjVG3V7A3qV2Jodue1k7z/Xp003iC/XDzjB7U
H1bPM9VMNdyOYA8HL6FMH5/rE2ELdOcbgSq20xbqEUOPeJ2p75+otAE1AVGnf0qa
1+lJADKtcL+mg/krqKKEpPtuosuhuOe1uTzUDCEy4Sk7XN7J0WWOqRQwJM9HZWqn
yvWlj2eykimkpKMu7txa+YOXwNLu6aYQJMHjSD3z+5ADRjl0UqiEJ3jAJC4Sb0xK
oxkSNu3wh27xOzsYO3mcgvxVy6Bv3BN569kP2uzatbJtGXClg5hNoGlj0w6BBx/t
wJl4VKTqQCq0SqclyNfDPv3sJwN9e8mr0l4rH8Cn0H5qQ1kpIu0ReYNXPkWnOUTo
+e4btmnfQeustw9MJk4EyHuUMrKGdifVA3ydNn6fQ8I0GBRkOXz+5YVR5k2v+GIg
nHZQBiia6Zn+n/vwZg3EG2jqxigo/ohQbmBJ/468evvEzK/bJM8dpFBa8ig+1pqo
as6TBe3+m0Dc9fQ8qRUtwHvvJL9u+gviT/eGv5oETQbb32t4w925zkw/AhFQ6nsP
buD9niNQyonOAVpV7kHg
=2sB2
-----END PGP SIGNATURE-----
Merge tag 'icc-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-misc-next
Georgi writes:
interconnect changes for 6.2
These are the interconnect changes for the 6.2-rc1 merge window consisting
of new drivers to enable both L3 and DDR scaling on sc8280xp platforms.
There are also a few miscellaneous fixes.
New osm-l3 driver:
- interconnect: qcom: osm-l3: Use platform-independent node ids
- interconnect: qcom: osm-l3: Squash common descriptors
- interconnect: qcom: osm-l3: Add per-core EPSS L3 support
- interconnect: qcom: osm-l3: Simplify osm_l3_set()
- dt-bindings: interconnect: Add sm8350, sc8280xp and generic OSM L3 compatibles
- dt-bindings: interconnect: qcom,msm8998-bwmon: Add sc8280xp bwmon instances
Fixes:
- interconnect: qcom: icc-rpm: Remove redundant dev_err call
- interconnect: qcom: sc7180: fix dropped const of qcom_icc_bcm
- interconnect: qcom: sc7180: drop double space
- interconnect: qcom: sc8180x: constify pointer to qcom_icc_node
Signed-off-by: Georgi Djakov <djakov@kernel.org>
* tag 'icc-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc:
interconnect: qcom: sc8180x: constify pointer to qcom_icc_node
interconnect: qcom: sc7180: drop double space
interconnect: qcom: sc7180: fix dropped const of qcom_icc_bcm
interconnect: qcom: icc-rpm: Remove redundant dev_err call
dt-bindings: interconnect: qcom,msm8998-bwmon: Add sc8280xp bwmon instances
dt-bindings: interconnect: Add sm8350, sc8280xp and generic OSM L3 compatibles
interconnect: qcom: osm-l3: Simplify osm_l3_set()
interconnect: qcom: osm-l3: Add per-core EPSS L3 support
interconnect: qcom: osm-l3: Squash common descriptors
interconnect: qcom: osm-l3: Use platform-independent node ids
dt-bindings: interconnect: qcom,msm8998-bwmon: Correct SC7280 CPU compatible
Replace integrated with discrete for dgfx platforms.
v2: commit title reword (Jani)
v3: use variable name i915 (Jani)
v4: commit message reword (MattR)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Taylor, Clinton A <clinton.a.taylor@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221129203343.720860-1-clinton.a.taylor@intel.com
There is one newly added place when we lock ring with io_cq_lock() but
unlocking is hand coded calling spin_unlock directly. It's ugly and
troublesome in the long run. Make it consistent with the other completion
locking.
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://lore.kernel.org/r/4ca4f0564492b90214a190cd5b2a6c76522de138.1669821213.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
SCTP conntrack currently assumes that the SCTP endpoints will
probe secondary paths using HEARTBEAT before sending traffic.
But, according to RFC 9260, SCTP endpoints can send any traffic
on any of the confirmed paths after SCTP association is up.
SCTP endpoints that sends INIT will confirm all peer addresses
that upper layer configures, and the SCTP endpoint that receives
COOKIE_ECHO will only confirm the address it sent the INIT_ACK to.
So, we can have a situation where the INIT sender can start to
use secondary paths without the need to send HEARTBEAT. This patch
allows DATA/SACK packets to create new connection tracking entry.
A new state has been added to indicate that a DATA/SACK chunk has
been seen in the original direction - SCTP_CONNTRACK_DATA_SENT.
State transitions mostly follows the HEARTBEAT_SENT, except on
receiving HEARTBEAT/HEARTBEAT_ACK/DATA/SACK in the reply direction.
State transitions in original direction:
- DATA_SENT behaves similar to HEARTBEAT_SENT for all chunks,
except that it remains in DATA_SENT on receving HEARTBEAT,
HEARTBEAT_ACK/DATA/SACK chunks
State transitions in reply direction:
- DATA_SENT behaves similar to HEARTBEAT_SENT for all chunks,
except that it moves to HEARTBEAT_ACKED on receiving
HEARTBEAT/HEARTBEAT_ACK/DATA/SACK chunks
Note: This patch still doesn't solve the problem when the SCTP
endpoint decides to use primary paths for association establishment
but uses a secondary path for association shutdown. We still have
to depend on timeout for connections to expire in such a case.
Signed-off-by: Sriram Yagnaraman <sriram.yagnaraman@est.tech>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
xfs log io error will trigger xlog shut down, and end_io worker call
xlog_state_shutdown_callbacks to unpin and release the buf log item.
The race condition is that when there are some thread doing transaction
commit and happened not to be intercepted by xlog_is_shutdown, then,
these log item will be insert into CIL, when unpin and release these
buf log item, UAF will occur. BTW, add delay before `xlog_cil_commit`
can increase recurrence probability.
The following call graph actually encountered this bad situation.
fsstress io end worker kworker/0:1H-216
xlog_ioend_work
->xlog_force_shutdown
->xlog_state_shutdown_callbacks
->xlog_cil_process_committed
->xlog_cil_committed
->xfs_trans_committed_bulk
->xfs_trans_apply_sb_deltas ->li_ops->iop_unpin(lip, 1);
->xfs_trans_getsb
->_xfs_trans_bjoin
->xfs_buf_item_init
->if (bip) { return 0;} //relog
->xlog_cil_commit
->xlog_cil_insert_items //insert into CIL
->xfs_buf_ioend_fail(bp);
->xfs_buf_ioend
->xfs_buf_item_done
->xfs_buf_item_relse
->xfs_buf_item_free
when cil push worker gather percpu cil and insert super block buf log item
into ctx->log_items then uaf occurs.
==================================================================
BUG: KASAN: use-after-free in xlog_cil_push_work+0x1c8f/0x22f0
Write of size 8 at addr ffff88801800f3f0 by task kworker/u4:4/105
CPU: 0 PID: 105 Comm: kworker/u4:4 Tainted: G W
6.1.0-rc1-00001-g274115149b42 #136
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: xfs-cil/sda xlog_cil_push_work
Call Trace:
<TASK>
dump_stack_lvl+0x4d/0x66
print_report+0x171/0x4a6
kasan_report+0xb3/0x130
xlog_cil_push_work+0x1c8f/0x22f0
process_one_work+0x6f9/0xf70
worker_thread+0x578/0xf30
kthread+0x28c/0x330
ret_from_fork+0x1f/0x30
</TASK>
Allocated by task 2145:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
__kasan_slab_alloc+0x54/0x60
kmem_cache_alloc+0x14a/0x510
xfs_buf_item_init+0x160/0x6d0
_xfs_trans_bjoin+0x7f/0x2e0
xfs_trans_getsb+0xb6/0x3f0
xfs_trans_apply_sb_deltas+0x1f/0x8c0
__xfs_trans_commit+0xa25/0xe10
xfs_symlink+0xe23/0x1660
xfs_vn_symlink+0x157/0x280
vfs_symlink+0x491/0x790
do_symlinkat+0x128/0x220
__x64_sys_symlink+0x7a/0x90
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Freed by task 216:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_save_free_info+0x2a/0x40
__kasan_slab_free+0x105/0x1a0
kmem_cache_free+0xb6/0x460
xfs_buf_ioend+0x1e9/0x11f0
xfs_buf_item_unpin+0x3d6/0x840
xfs_trans_committed_bulk+0x4c2/0x7c0
xlog_cil_committed+0xab6/0xfb0
xlog_cil_process_committed+0x117/0x1e0
xlog_state_shutdown_callbacks+0x208/0x440
xlog_force_shutdown+0x1b3/0x3a0
xlog_ioend_work+0xef/0x1d0
process_one_work+0x6f9/0xf70
worker_thread+0x578/0xf30
kthread+0x28c/0x330
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff88801800f388
which belongs to the cache xfs_buf_item of size 272
The buggy address is located 104 bytes inside of
272-byte region [ffff88801800f388, ffff88801800f498)
The buggy address belongs to the physical page:
page:ffffea0000600380 refcount:1 mapcount:0 mapping:0000000000000000
index:0xffff88801800f208 pfn:0x1800e
head:ffffea0000600380 order:1 compound_mapcount:0 compound_pincount:0
flags: 0x1fffff80010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
raw: 001fffff80010200 ffffea0000699788 ffff88801319db50 ffff88800fb50640
raw: ffff88801800f208 000000000015000a 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88801800f280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88801800f300: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88801800f380: fc fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88801800f400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88801800f480: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Disabling lock debugging due to kernel taint
Signed-off-by: Guo Xuenan <guoxuenan@huawei.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Fix uaf in xfs_trans_ail_delete during xlog force shutdown.
In commit cd6f79d1fb ("xfs: run callbacks before waking waiters in
xlog_state_shutdown_callbacks") changed the order of running callbacks
and wait for iclog completion to avoid unmount path untimely destroy AIL.
But which seems not enough to ensue this, adding mdelay in
`xfs_buf_item_unpin` can prove that.
The reproduction is as follows. To ensure destroy AIL safely,
we should wait all xlog ioend workers done and sync the AIL.
==================================================================
BUG: KASAN: use-after-free in xfs_trans_ail_delete+0x240/0x2a0
Read of size 8 at addr ffff888023169400 by task kworker/1:1H/43
CPU: 1 PID: 43 Comm: kworker/1:1H Tainted: G W
6.1.0-rc1-00002-gc28266863c4a #137
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: xfs-log/sda xlog_ioend_work
Call Trace:
<TASK>
dump_stack_lvl+0x4d/0x66
print_report+0x171/0x4a6
kasan_report+0xb3/0x130
xfs_trans_ail_delete+0x240/0x2a0
xfs_buf_item_done+0x7b/0xa0
xfs_buf_ioend+0x1e9/0x11f0
xfs_buf_item_unpin+0x4c8/0x860
xfs_trans_committed_bulk+0x4c2/0x7c0
xlog_cil_committed+0xab6/0xfb0
xlog_cil_process_committed+0x117/0x1e0
xlog_state_shutdown_callbacks+0x208/0x440
xlog_force_shutdown+0x1b3/0x3a0
xlog_ioend_work+0xef/0x1d0
process_one_work+0x6f9/0xf70
worker_thread+0x578/0xf30
kthread+0x28c/0x330
ret_from_fork+0x1f/0x30
</TASK>
Allocated by task 9606:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
__kasan_kmalloc+0x7a/0x90
__kmalloc+0x59/0x140
kmem_alloc+0xb2/0x2f0
xfs_trans_ail_init+0x20/0x320
xfs_log_mount+0x37e/0x690
xfs_mountfs+0xe36/0x1b40
xfs_fs_fill_super+0xc5c/0x1a70
get_tree_bdev+0x3c5/0x6c0
vfs_get_tree+0x85/0x250
path_mount+0xec3/0x1830
do_mount+0xef/0x110
__x64_sys_mount+0x150/0x1f0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Freed by task 9662:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_save_free_info+0x2a/0x40
__kasan_slab_free+0x105/0x1a0
__kmem_cache_free+0x99/0x2d0
kvfree+0x3a/0x40
xfs_log_unmount+0x60/0xf0
xfs_unmountfs+0xf3/0x1d0
xfs_fs_put_super+0x78/0x300
generic_shutdown_super+0x151/0x400
kill_block_super+0x9a/0xe0
deactivate_locked_super+0x82/0xe0
deactivate_super+0x91/0xb0
cleanup_mnt+0x32a/0x4a0
task_work_run+0x15f/0x240
exit_to_user_mode_prepare+0x188/0x190
syscall_exit_to_user_mode+0x12/0x30
do_syscall_64+0x42/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The buggy address belongs to the object at ffff888023169400
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 0 bytes inside of
128-byte region [ffff888023169400, ffff888023169480)
The buggy address belongs to the physical page:
page:ffffea00008c5a00 refcount:1 mapcount:0 mapping:0000000000000000
index:0xffff888023168f80 pfn:0x23168
head:ffffea00008c5a00 order:1 compound_mapcount:0 compound_pincount:0
flags: 0x1fffff80010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
raw: 001fffff80010200 ffffea00006b3988 ffffea0000577a88 ffff88800f842ac0
raw: ffff888023168f80 0000000000150007 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888023169300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888023169380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888023169400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888023169480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888023169500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Disabling lock debugging due to kernel taint
Fixes: cd6f79d1fb ("xfs: run callbacks before waking waiters in xlog_state_shutdown_callbacks")
Signed-off-by: Guo Xuenan <guoxuenan@huawei.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
This is an assorted collection of bug fixes that have been bundled
together. The first patch fixes a metadump corruption vector resulting
from a three-way race between a slow-running blkid process, the kernel
mounting, changing, and unmounting the fs, and xfs_db reading stale
block device pagecache contents.
The middle two patches address gcc warnings.
The final patch fixes a subtle corruption bug wherein making a delalloc
reservation on a filesystem with quotas enabled would sample the data
mapping, try to attach dquots, unlock the inode to attach the dquots,
relock the inode, and fail to reverify the sampled data. If another
process updated the data mapping while the inode was unlocked, the
reservation would proceed with stale data and corrupt the data fork.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmOHjswACgkQ+H93GTRK
tOuSKQ//dBLc5nx9HRFXdFMPi+uytPXzu8twkLfogkHh2F0oL7En5MnRdTY6jhTN
zf/f+pQhLIqctYhV7xtMvUT6bC6HD95jJGjcOS8gA8/lSNoeVPJBEhCjo5+6uqyk
/Nb3RaDAVvP4fG6eb03pbt/dQn8swgxyt7XDzxIfhGfAkKXm/ksSIcisv0EsSQdc
PFZfbklCw1PzMcAUhysHyrNlhf3bAYk1o/IYY855P/OHRxBZxyf3CAFwlhyP5Cl+
jCV1JcgkCR5VCV4iuCsmxMIwx0FVJwuk2YTLZNipEOrehR7Kzubgdg159eFzNBZS
a0lXCLWSRCvNIvl/yUbWk+tBEKgk9WPdP/ihHRw9qxR+3wN2TmcEMkSTBqbPqxDz
C42iaInjVXw+Tg7hm6XdHaHcLp3xR24l3uZvp9LCEXZ8SdltQoglbsyO0KcMqgfl
qjgyoub9KOR4N/CaNPgV1nObDbGAy+j12hmqX4BaPlTz7SjFios3rEZi+i9K1clj
Z/O7aIBVgFKDkE691f9S2VsHNnIFxWSgCQWKAsfr9ES96AA7UdnE/wgXeeKbu74Q
GNDIJ5hicFjn2HqO/xyxp+b9plvAzLdBAxAHXm3l00QKrNmHDbHzVqHSXSeFk0u7
+JvOaFH8vgZsjetT4tNIyBXYEsGc+/NRV+AT4HJriuoSIstoSS4=
=tQJn
-----END PGP SIGNATURE-----
Merge tag 'random-fixes-6.2_2022-11-30' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.2-mergeC
xfs: various fixes for 6.2
This is an assorted collection of bug fixes that have been bundled
together. The first patch fixes a metadump corruption vector resulting
from a three-way race between a slow-running blkid process, the kernel
mounting, changing, and unmounting the fs, and xfs_db reading stale
block device pagecache contents.
The middle two patches address gcc warnings.
The final patch fixes a subtle corruption bug wherein making a delalloc
reservation on a filesystem with quotas enabled would sample the data
mapping, try to attach dquots, unlock the inode to attach the dquots,
relock the inode, and fail to reverify the sampled data. If another
process updated the data mapping while the inode was unlocked, the
reservation would proceed with stale data and corrupt the data fork.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
* tag 'random-fixes-6.2_2022-11-30' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux:
xfs: attach dquots to inode before reading data/cow fork mappings
xfs: shut up -Wuninitialized in xfsaild_push
xfs: use memcpy, not strncpy, to format the attr prefix during listxattr
xfs: invalidate block device page cache during unmount
This series is a followup to Dave Chinner's series entitled
"xfs, iomap: fix data corruption due to stale cached iomaps".
The two patches here add debugging knobs to introduce artificial delays
into the pagecache write and writeback code to facilitate testing of the
iomap invalidation code. New tracepoints are also introduced so that
fstests can look for the invalidations.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmOHjsQACgkQ+H93GTRK
tOtD8A//UCxbSWRbuDPtiWz9pRmh3pA/UzCB1aFqkzunFlDzH/0fjiDFjRuSj0O5
3jaBgKvi+/25dVMlBWz1U6PTuK0kjjBLbAcfo7kA42YPLL1OvGE7aNcERY6TZz+i
LYsZznl4viDr69P9f5voSd5lZyJ1Im8u++ztwoRlzRY+mhFe7vVVJATQ+kHQxCEK
CQVA3S1nHKDmXBg7ZCEVaSkI5MTg1DpJ1mQ6Ni2JjemBEo+huVcO1SyGd1phFazG
bP2xkS+fN2nz3tF+25U9MDLYTzG2Mg/GDyuFsXU+uecFElH7iQis5TM6scj9EpT6
WOQTaMu8D9GebTwjRN52qoSkb5/1yQaLObpfLPMY9TduK3rjdNE6tu9sRZ8Swn+T
eUxSgbTDQNEqthoQ6IJXR2VkfJG7zsRogJKvc3SE0rGlsx8+KuD1mwMIwdesf+Om
w5ToWooGdYkP3jEMTL+S65OPzojs4WGX7etOV+WFHh48sIlCOBvbsTeKZzTnkjFT
wA6A9ZqjDuV66wugilTRRPhA1nTjGmvmCMAZzQOtl3VOP9tVaH66SHvWw5TBN+Yk
a/n07M07xruZ61zgCv9n3mtb8e46JoOnhK59X16ZcNDx3L78ZYjIkNFIFAnBnxvj
s1kCrHGywUA1B/PoEaEBVgvJ5vD8O5CAUu1tlkVWJK6pCFVhXqU=
=jpef
-----END PGP SIGNATURE-----
Merge tag 'iomap-write-race-testing-6.2_2022-11-30' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.2-mergeC
xfs: add knobs for testing iomap write race fixes
This series is a followup to Dave Chinner's series entitled
"xfs, iomap: fix data corruption due to stale cached iomaps".
The two patches here add debugging knobs to introduce artificial delays
into the pagecache write and writeback code to facilitate testing of the
iomap invalidation code. New tracepoints are also introduced so that
fstests can look for the invalidations.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
* tag 'iomap-write-race-testing-6.2_2022-11-30' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux:
xfs: add debug knob to slow down write for fun
xfs: add debug knob to slow down writeback for fun
We've been overloading uncore->lock to protect access to the MCR
steering register. That's not really what uncore->lock is intended for,
and it would be better if we didn't need to hold such a high-traffic
spinlock for the whole sequence of (apply steering, access MCR register,
restore steering). Let's create a dedicated MCR lock to protect the
steering control register over this critical section and stop relying on
the high-traffic uncore->lock.
For now the new lock is a software lock. However some platforms (MTL
and beyond) have a hardware-provided locking mechanism that can be used
to serialize not only software accesses, but also hardware/firmware
accesses as well; support for that hardware level lock will be added in
a future patch.
v2:
- Use irqsave/irqrestore spinlock calls; platforms using execlist
submission rather than GuC submission can perform MCR accesses in
interrupt context because reset -> errordump happens in a tasklet.
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221128233014.4000136-4-matthew.d.roper@intel.com
Passing the GT rather than uncore to the lowest level MCR read and write
functions will make it easier to introduce dedicated MCR locking in a
following patch.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221128233014.4000136-3-matthew.d.roper@intel.com
The kerneldoc function name was not updated when this function was
converted to a non-fw form.
Fixes: 192bb40f03 ("drm/i915/gt: Manage uncore->lock while waiting on MCR register")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221128233014.4000136-2-matthew.d.roper@intel.com
I've been running near-continuous integration testing of online fsck,
and I've noticed that once a day, one of the ARM VMs will fail the test
with out of order records in the data fork.
xfs/804 races fsstress with online scrub (aka scan but do not change
anything), so I think this might be a bug in the core xfs code. This
also only seems to trigger if one runs the test for more than ~6 minutes
via TIME_FACTOR=13 or something.
https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/tree/tests/xfs/804?h=djwong-wtf
I added a debugging patch to the kernel to check the data fork extents
after taking the ILOCK, before dropping ILOCK, and before and after each
bmapping operation. So far I've narrowed it down to the delalloc code
inserting a record in the wrong place in the iext tree:
xfs_bmap_add_extent_hole_delay, near line 2691:
case 0:
/*
* New allocation is not contiguous with another
* delayed allocation.
* Insert a new entry.
*/
oldlen = newlen = 0;
xfs_iunlock_check_datafork(ip); <-- ok here
xfs_iext_insert(ip, icur, new, state);
xfs_iunlock_check_datafork(ip); <-- bad here
break;
}
I recorded the state of the data fork mappings and iext cursor state
when a corrupt data fork is detected immediately after the
xfs_bmap_add_extent_hole_delay call in xfs_bmapi_reserve_delalloc:
ino 0x140bb3 func xfs_bmapi_reserve_delalloc line 4164 data fork:
ino 0x140bb3 nr 0x0 nr_real 0x0 offset 0xb9 blockcount 0x1f startblock 0x935de2 state 1
ino 0x140bb3 nr 0x1 nr_real 0x1 offset 0xe6 blockcount 0xa startblock 0xffffffffe0007 state 0
ino 0x140bb3 nr 0x2 nr_real 0x1 offset 0xd8 blockcount 0xe startblock 0x935e01 state 0
Here we see that a delalloc extent was inserted into the wrong position
in the iext leaf, same as all the other times. The extra trace data I
collected are as follows:
ino 0x140bb3 fork 0 oldoff 0xe6 oldlen 0x4 oldprealloc 0x6 isize 0xe6000
ino 0x140bb3 oldgotoff 0xea oldgotstart 0xfffffffffffffffe oldgotcount 0x0 oldgotstate 0
ino 0x140bb3 crapgotoff 0x0 crapgotstart 0x0 crapgotcount 0x0 crapgotstate 0
ino 0x140bb3 freshgotoff 0xd8 freshgotstart 0x935e01 freshgotcount 0xe freshgotstate 0
ino 0x140bb3 nowgotoff 0xe6 nowgotstart 0xffffffffe0007 nowgotcount 0xa nowgotstate 0
ino 0x140bb3 oldicurpos 1 oldleafnr 2 oldleaf 0xfffffc00f0609a00
ino 0x140bb3 crapicurpos 2 crapleafnr 2 crapleaf 0xfffffc00f0609a00
ino 0x140bb3 freshicurpos 1 freshleafnr 2 freshleaf 0xfffffc00f0609a00
ino 0x140bb3 newicurpos 1 newleafnr 3 newleaf 0xfffffc00f0609a00
The first line shows that xfs_bmapi_reserve_delalloc was called with
whichfork=XFS_DATA_FORK, off=0xe6, len=0x4, prealloc=6.
The second line ("oldgot") shows the contents of @got at the beginning
of the call, which are the results of the first iext lookup in
xfs_buffered_write_iomap_begin.
Line 3 ("crapgot") is the result of duplicating the cursor at the start
of the body of xfs_bmapi_reserve_delalloc and performing a fresh lookup
at @off.
Line 4 ("freshgot") is the result of a new xfs_iext_get_extent right
before the call to xfs_bmap_add_extent_hole_delay. Totally garbage.
Line 5 ("nowgot") is contents of @got after the
xfs_bmap_add_extent_hole_delay call.
Line 6 is the contents of @icur at the beginning fo the call. Lines 7-9
are the contents of the iext cursors at the point where the block
mappings were sampled.
I think @oldgot is a HOLESTARTBLOCK extent because the first lookup
didn't find anything, so we filled in imap with "fake hole until the
end". At the time of the first lookup, I suspect that there's only one
32-block unwritten extent in the mapping (hence oldicurpos==1) but by
the time we get to recording crapgot, crapicurpos==2.
Dave then added:
Ok, that's much simpler to reason about, and implies the smoke is
coming from xfs_buffered_write_iomap_begin() or
xfs_bmapi_reserve_delalloc(). I suspect the former - it does a lot
of stuff with the ILOCK_EXCL held.....
.... including calling xfs_qm_dqattach_locked().
xfs_buffered_write_iomap_begin
ILOCK_EXCL
look up icur
xfs_qm_dqattach_locked
xfs_qm_dqattach_one
xfs_qm_dqget_inode
dquot cache miss
xfs_iunlock(ip, XFS_ILOCK_EXCL);
error = xfs_qm_dqread(mp, id, type, can_alloc, &dqp);
xfs_ilock(ip, XFS_ILOCK_EXCL);
....
xfs_bmapi_reserve_delalloc(icur)
Yup, that's what is letting the magic smoke out -
xfs_qm_dqattach_locked() can cycle the ILOCK. If that happens, we
can pass a stale icur to xfs_bmapi_reserve_delalloc() and it all
goes downhill from there.
Back to Darrick now:
So. Fix this by moving the dqattach_locked call up before we take the
ILOCK, like all the other callers in that file.
Fixes: a526c85c22 ("xfs: move xfs_file_iomap_begin_delay around") # goes further back than this
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
-Wuninitialized complains about @target in xfsaild_push being
uninitialized in the case where the waitqueue is active but there is no
last item in the AIL to wait for. I /think/ it should never be the case
that the subsequent xfs_trans_ail_cursor_first returns a log item and
hence we'll never end up at XFS_LSN_CMP, but let's make this explicit.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
When -Wstringop-truncation is enabled, the compiler complains about
truncation of the null byte at the end of the xattr name prefix. This
is intentional, since we're concatenating the two strings together and
do _not_ want a null byte in the middle of the name.
We've already ensured that the name buffer is long enough to handle
prefix and name, and the prefix_len is supposed to be the length of the
prefix string without the null byte, so use memcpy here instead.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Every now and then I see fstests failures on aarch64 (64k pages) that
trigger on the following sequence:
mkfs.xfs $dev
mount $dev $mnt
touch $mnt/a
umount $mnt
xfs_db -c 'path /a' -c 'print' $dev
99% of the time this succeeds, but every now and then xfs_db cannot find
/a and fails. This turns out to be a race involving udev/blkid, the
page cache for the block device, and the xfs_db process.
udev is triggered whenever anyone closes a block device or unmounts it.
The default udev rules invoke blkid to read the fs super and create
symlinks to the bdev under /dev/disk. For this, it uses buffered reads
through the page cache.
xfs_db also uses buffered reads to examine metadata. There is no
coordination between xfs_db and udev, which means that they can run
concurrently. Note there is no coordination between the kernel and
blkid either.
On a system with 64k pages, the page cache can cache the superblock and
the root inode (and hence the root dir) with the same 64k page. If
udev spawns blkid after the mkfs and the system is busy enough that it
is still running when xfs_db starts up, they'll both read from the same
page in the pagecache.
The unmount writes updated inode metadata to disk directly. The XFS
buffer cache does not use the bdev pagecache, nor does it invalidate the
pagecache on umount. If the above scenario occurs, the pagecache no
longer reflects what's on disk, xfs_db reads the stale metadata, and
fails to find /a. Most of the time this succeeds because closing a bdev
invalidates the page cache, but when processes race, everyone loses.
Fix the problem by invalidating the bdev pagecache after flushing the
bdev, so that xfs_db will see up to date metadata.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
pull the following:
- Yuan uses dev_err_probe() in the Raspberry Pi firmware provider to
simplify the error handling code
- Rafal adds support for initialiazing the BCM47xx NVMEM/NVRAM firmware
provider out of memory-mapped flash devices.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmOGWqQACgkQh9CWnEQH
BwRXVRAA5ieip57Dr+TFlOKgVVsLR0lildCIEf8xBLS2248JpLOdcZiEH8A52l09
zqWLjWkWmgHnVHJ8hxLGZojsuWZvTI1bg/Y6IOY6ZQRSpFGR9DMTmedAdmmOe6Wi
tXApkgfsR5s/vkTye/Sd8x9vJRI+V6BEO2maH891Tqz533FpqPM67GXpW5dClu5D
0hL/I9bnDoRtugfycLiH1y9I7wrQdAvkSYjgo7ncQLSb5Zw3b3993hRvQ2Afcq+F
mnmsCoCeBsWFh8VO+qy3cmxQi7P031kxxH01+XHo+3glCx9TMzUSL71dT0kybXEU
5yf2Ej7yuqUpsHQIj1ET6+wb8K2QXOv2onn3wIy1WncgWbZjOgFGUEb69U+vXBLa
Y/0U81Ib421LspIM4/brIdX/UKeFy04gz9/r+i+pme5+WMBcamm8/TS79lxJdxKt
gjOw2jEXM26cCCXkHRrLPFebi1c2Y2I/r6/YYLvwzt7uSBqaj2afw2ZCbRR3Om2j
JJsA+wqql1iAx1vrPb6nSeBf/Dbl+HuFlynxn7rTnUcgeNmjLamdywE5TBpiKUws
P1rXV3gKeMEk2IQksE/jukBmSW1efkbMA2u63BUmrwMmh17CBJddY2ttK0w7AFPU
WmrncPB4WpvPBzeUOC4IvmbzYJHbhRZ6tkcOMP5UWRhcI1HKrg0=
=7dAD
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmOHirEACgkQmmx57+YA
GNkMNRAAtJfwKAc2/v/4R6bnqaSiN9Fc+i6LosszuXBVaac2D72js6oV2R26WfYN
COlOXs6rV4HvHPtWban40NkrmNFxJixW1vrWfkWjjstX28VqzKJnv6oUOCUaigB4
alHqOIB6jGo6BH5+Kro0/8G1F9pbZ0PWaTpY90ison+LKzVPn8ZGU03YHLYIpq2q
zeACwCeNIqjP376QjLCf3dwsEuswaSRoCkOCjMzlOJhamy5XRivIpvPP+0Qkrvcu
YN1wqrwXBJ7/YrlmKBwQBEtN0pEIIzvL+vvZKp99VOCB7ofx9SAUcwSDF7LA5+q3
5JW38H8nFQGsDaWrw1E++fsd8o4wFbLn0K2altNwjTIMjoBbaFopnXdRW3Jp3lhS
R+iQ8sobDkHIDvw2a7Ski8PursVo9hC8ZRdF6FPazLPQJrHe6SoWLzbRw5dovdsK
tSFQ/DqjfmDlkrUfa8iXSQnTzdTObi3N5OHGTp+KHlJad34MhPuNW4JVGhXm2OGE
mGKL/2HIN5w5GxE1D8YoKexaeBjvc0zi2zHvb/dIUbN3aeK2p3wQsMyvf424SAMe
1zsg+AnwbASLmkEPjBTqxnec82FG0a6cvYJ5UtcdJ6J0YlSUVm07zimzYKJY2M1d
ryjSN6dKpanyIcJInWfCecmvICS2KTerpcVyte6VST5TDKc5ZNo=
=wHNl
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-6.2/drivers' of https://github.com/Broadcom/stblinux into soc/drivers
This pull request contains Broadcom SoCs driver changes for 6.2, please
pull the following:
- Yuan uses dev_err_probe() in the Raspberry Pi firmware provider to
simplify the error handling code
- Rafal adds support for initialiazing the BCM47xx NVMEM/NVRAM firmware
provider out of memory-mapped flash devices.
* tag 'arm-soc/for-6.2/drivers' of https://github.com/Broadcom/stblinux:
firmware/nvram: bcm47xx: support init from IO memory
firmware: raspberrypi: Use dev_err_probe() to simplify code
Link: https://lore.kernel.org/r/20221129191755.542584-3-f.fainelli@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Just two minor correctness nits reported by the kernel test robot.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQSByI3Ki0mXziclZJcd+FPLCI8zYgUCY4SdmgAKCRAd+FPLCI8z
YqLEAP4qakDqDcQyXjBh8uekFqqGCuAH+T3FPcPKUJCWKuVHYQEA4aK64fibS6Fr
Pnz/Kw0RyFG51mMD8KRBd++hbTH/9g4=
=Inh7
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmOHijUACgkQmmx57+YA
GNnZHhAAhd9/uLeP7g9B+IbEYMVSK8WXxWERGZ3mT2QqbJpWuky+U7+7ndNQEn23
ky49kJzkPAbYWNJ/PjNLcoCeHjWQ+joBLyB/f8llXyaAqqW4r/WC4IL2ZRtj0zOn
nmD2VBN3DAtlza1AbqklsdEOjYJvxtIu/9u1QBYUwwp8mxWuEkUQ+9DGQLhKz/pd
XYklIW3f8l99lIwUlAiuto2dQfszZjUbmwYKIUk7klNSRasIBPPizp3OxmyDbgRk
dCL4kbydaN1kx3lP1xx4gsu5eaVCEsUdKkNDJrZoHyF3k5SUI2XrvRdVgJs75Pyc
/f6oVft5Bqqwx4ES8a9xI8JbqLY1q8U3nxDLwnp3ERDs3QeR6ZOSf2e2kAqeuDyw
2nRPsj6XiQPZY6bScx7j89FLbF4TVxVsuhyZoNWTypMNe+8nMAywuQDr7MxntwMc
Eie7SU5MHlpvdmy2p54x9cA3eDBjyHolsRgLkiRTi8jwnJl159SlBQiwT+iPYYQ/
SYGC9iN+g/OksRtL1gw25BLjZo17oaO9UJY35EN1iHDs9BPMBReAxhErJ7WzEU3I
+SX/2dOy/Szpdra4nvply1mIsKeDNpVJgCvfA+gt9B9kOMBNAetskP1aZPcmGZ9/
uJEZWSsqZYupXMPo/GZWW4IiNY9HyXTwt8ldSnqX53RpGe3DiRQ=
=qFo6
-----END PGP SIGNATURE-----
Merge tag 'asahi-soc-rtkit-sart-6.2' of https://github.com/AsahiLinux/linux into soc/drivers
Apple SoC RTKit/SART updates for 6.2.
Just two minor correctness nits reported by the kernel test robot.
* tag 'asahi-soc-rtkit-sart-6.2' of https://github.com/AsahiLinux/linux:
soc: apple: rtkit: Stop casting function pointer signatures
soc: apple: sart: Stop casting function pointer signatures
Link: https://lore.kernel.org/r/57f84134-8645-35f6-2427-ee683800c413@marcan.st
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
It contains:
- updates for defconfigs to use the new CONFIG_VIDEO_MICROCHIP_ISC,
CONFIG_VIDEO_MICROCHIP_XISC config flags that replaced the
CONFIG_VIDEO_ATMEL_ISC, CONFIG_VIDEO_ATMEL_XISC. Drivers under
CONFIG_VIDEO_ATMEL_* were moved to staging and considered deprecated.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTsZ8eserC1pmhwqDmejrg/N2X7/QUCY4DMugAKCRCejrg/N2X7
/R2cAP4mNhim4mqS0gnz7WA41Ahl5KMxGQerQurW9zFV2V6hjAEAtRiVIIhPEWLv
bHgZNDkdb1TpRqmPQ7JJoZ9CSwItRg8=
=uu4P
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmOHifkACgkQmmx57+YA
GNnDuRAAret+I2cvPkN76HpUuSQL2uJJF2yDlDSCG228IrbqSM5UikJvFB7WYQwh
nmu9AcDrQxudSHFZCa0Q0r2sff1DW6ncQ6XD1XxYAyDaSV2uor4YdBChqbtzf2uE
7Zk+Yqu4zthNtTezNBKb0RgJwwG+rUcqMe9pw+n+eQ5Iz/sjOBHMsK19pM5mCrsE
INQ/dnSJ/iFjNvHJUNy+PkdfH8x5zFgtr6JUIiZhtCj0maZaT4LOFykFD5bBm4w2
6dbH/bP+cDWivoYe48K6Wx/MCLegFTHiDC68sQLOLRtPP9VNhXdDd3LHHlZpZcZR
JV5YFeOjOdd0BKg7tQ7/Qke280eXI7eTHzGGV1jos9lKIUln+/VfZVmH8kLvnxov
+wsSuTbBZqjz8fd8HGJSqpYYAnfvxw8B/A+mK6PLWe7Lqx6NGV6aNFZz5TEN1241
slabTalkMyFAK4E6b1eXYNt5ftJaQ0NZht9jHOAqP89oB45TEhEnGI7W4CB+H5ay
jclklHcdijZJNO8dWtVHCCASmT2eM0Hs5RTkwpCXI8zMnQ2oWSDws07awIsaBWu8
uoDlNddTtAt+gQuXcJ81PNGcB1z2a2NDicL6zgPpCkepTMJOJ3Vb+KEcBj4Wgr0D
cZFefR0/b6r7KMxXuqgFckYS/8hVYUzi5Odr1lCJQ5cW7WDLbgk=
=zvQn
-----END PGP SIGNATURE-----
Merge tag 'at91-defconfig-6.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/defconfig
AT91 defconfig for 6.2 #2
It contains:
- updates for defconfigs to use the new CONFIG_VIDEO_MICROCHIP_ISC,
CONFIG_VIDEO_MICROCHIP_XISC config flags that replaced the
CONFIG_VIDEO_ATMEL_ISC, CONFIG_VIDEO_ATMEL_XISC. Drivers under
CONFIG_VIDEO_ATMEL_* were moved to staging and considered deprecated.
* tag 'at91-defconfig-6.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
ARM: configs: multi_v7: switch to new MICROCHIP_ISC driver
ARM: configs: sama5/7: switch to new MICROCHIP_ISC driver
Link: https://lore.kernel.org/r/20221125142736.385654-1-claudiu.beznea@microchip.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
If a triple fault was fixed by kvm_x86_ops.nested_ops->triple_fault (by
turning it into a vmexit), there is no need to leave vcpu_enter_guest().
Any vcpu->requests will be caught later before the actual vmentry,
and in fact vcpu_enter_guest() was not initializing the "r" variable.
Depending on the compiler's whims, this could cause the
x86_64/triple_fault_event_test test to fail.
Cc: Maxim Levitsky <mlevitsk@redhat.com>
Fixes: 92e7d5c83a ("KVM: x86: allow L1 to not intercept triple fault")
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Enable the Qualcomm SM6115 / SM4250 TLMM pinctrl and GCC clock drivers.
They need to be builtin to ensure that the UART is allowed to probe
before user space needs a console.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221128200834.1776868-1-bhupesh.sharma@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
In case of Gen12 video and compute engines, TLB_INV registers are masked -
to modify one bit, corresponding bit in upper half of the register must
be enabled, otherwise nothing happens.
CVE: CVE-2022-4139
Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: 7938d61591 ("drm/i915: Flush TLBs before releasing backing store")
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
for 6.2, please pull the following:
- Rafal describes the timer/watchdog block for the BCM4908 and BCM6858
SoCs
- Krzysztof corrects invalid "reg" properties for the memory nodes that
were off by one digit
- Pierre updates a number of cache Device Tree node properties to be
schema compliant
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmOGWkoACgkQh9CWnEQH
BwTM3hAAz6n7Ncc6ZU+v+sUkfGw5mHYr8tO0SM+nFADGxqd1Rjs+rdyoAxVWnKOY
tC/9Y+l66JmPrwlXJN9dFnRoUjAv8zp09R34ptTpvkBXs5VSC1tppknw14fRQsXk
xZl0oz+TNzoWkb2fWXx8uQdM3WX/R/cfs52kbxVobx2Z27BXSZs8em9PjFRqNKed
1fHHTFuD7JAQX8g575W4vkcP8k0vA4yAGpZdqekAo2A8FaZhQ/DnOszUEQuQNjn2
Wr8Arl8vrBJS8LXBPjPPIzKQlE5+8khR1ESLS+11MKSaP4zTRAB+elpPsiWkqqDv
BfwQVFQs7KCNoPV6WqsltiIoh4/uP70dwUapF9Tye0MqhZ4ZH4C8PBCh8b80H5Wb
h1T78x+6SnzH0rlPjssdfHKNWVSubUvnU7deNA84OrNpxJCrdi5eNf3gZytaU480
550wkDBBuiffYdXplw5LCjxyKIcJ3KoLVyHqQkQ4sCinC8hDWzcA/oOeiAZyedwf
P/cDs+JlOyDwSdeQMkMmaDtKoW8oVaQ6+v9BBKNBl+vvr4l1HlFeEtt30bDvQ6CT
/cOdHhL/ki5FljPsRgF9Uf/Jp9jGF41Ph20Zo636ArQVG4pwGWM3hNTE/J3XSSzj
jBHSdsm346iT55ajqci+5/TWlxUUBvhaIVuj203Q5Z5EAvfqJvY=
=l7Fu
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmOHh+8ACgkQmmx57+YA
GNm88xAAmR3TUNIQiN9ovK7Ibjp9OA+DLXJPDBdplPVB2Y4DigcYNshbJUdJI1He
RLi8npUB3XccLS72tyZA76AYHFD5/zugf0y7erZQTw9eNesd4aXVWfVNWn5tJoVy
4GfewjUg6EmP3kpBsXfKMZak5M8dggZONH0Lkpe7QkquKSut29ku9LxT3Y3Gtzs4
ERNku3T4m7ozgp3LWYg5KHBuEpK2lPvC4hhZnP6+8sChfWJiJwONOWUeXz+P2z5p
vkHQIoqbye42rnwc02gQk79EXmjS/ggEmaCJhU1sS9YnO7QSIC/5hGuQ+spc5Lob
RDGRGDeFG71DbFOVYFWF9Aj1+hxqaY/lJrIRfgjwuxxzuItFMrYytXjZdYGHIoJu
M+ZMt2/cHfQ/0tDA9bkDiK8OmN5D/61OqkAU/CeWwPYY4Ci+t3jkSZP3LI3P5wHV
WB7UUxanM6g7uzaTINFkUAgx6Ljr8edW0pB6nrigei50BZwnRD7B5FbYEaPmbC9B
um+BpnM06oE9+X+V4uh6iYnLBtRcpdLgWk7lzcgoLKyAxxVpyT6+qRBJ7vN/NVaR
nOY7IGMXyTohCvitg4RTssP1vf1VoYEguw4NRdqpgRbeAFy6s8xxSDq7EXxfcRfF
CJlMy7P+XXOKY7ZRi+1yNj/Un30ymRDE2yXrFbKjX9yIZj/0q6Q=
=8S30
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-6.2/devicetree-arm64' of https://github.com/Broadcom/stblinux into soc/dt
This pull request contains Broadcom ARM64-based SoCs Device Tree updates
for 6.2, please pull the following:
- Rafal describes the timer/watchdog block for the BCM4908 and BCM6858
SoCs
- Krzysztof corrects invalid "reg" properties for the memory nodes that
were off by one digit
- Pierre updates a number of cache Device Tree node properties to be
schema compliant
* tag 'arm-soc/for-6.2/devicetree-arm64' of https://github.com/Broadcom/stblinux:
arm64: dts: Update cache properties for broadcom
arm64: dts: broadcom: trim addresses to 8 digits
arm64: dts: broadcom: bcmbca: bcm6858: add TWD block
arm64: dts: broadcom: bcmbca: bcm4908: add TWD block timer
Link: https://lore.kernel.org/r/20221129191755.542584-2-f.fainelli@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
generic_remap_checks() can reduce the effective request length (i.e.,
after the reflink extend to EOF case is handled) down to zero. If this
occurs, __generic_remap_file_range_prep() proceeds through dio
serialization, file mapping flush calls, and may invoke file_modified()
before returning back to the filesystem caller, all of which immediately
check for len == 0 and return.
While this is mostly harmless, it is spurious and not completely
without side effect. A filemap write call can submit I/O (but not
wait on it) when the specified end byte precedes the start but
happens to land on the same aligned page boundary, which can occur
from __generic_remap_file_range_prep() when len is 0.
The dedupe path already has a len == 0 check to break out before
doing range comparisons. Lift this check a bit earlier in the
function to cover the general case of len == 0 and avoid the
unnecessary work. While here, account for the case where
generic_remap_check_len() may also reduce length to zero.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
for 6.2, please pull the following:
- Linus adds support for the D-Link DWL-8610AP which is based upon the
BCM53016 SoC and the D-Link DIR-890L routers
- Maxime resolves a long standing issue affecting Raspberry Pi devices
by switching entirely over to the VPU firmware clock provider rather
than mixing the "bare metal" clock driver and VPU
- Rafal corrects the description of the TP-Link router partitions to
use the "safeloader" partition parser
- Stefan fixes a number of invalid underscores in the bcm283x DTS files
and also moves the ACT LED into a separate DTS include file for better
re-use
- Krzysztof aligns the LEDs DT nodes to the proper schema format
- Pierre adds missing cache properties to various SoCs
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmOFR/0ACgkQh9CWnEQH
BwTjQQ/8Dlt/3xTRb5m2Llq2fnsb+D6NkMDlQB2R0NS+CQ3796iMUpHb2uXmboIn
9k4N7Vldk2mng/MEaCj5M14/5uwscsg8pDCAQq13ATfhBTTJKJJ4XfVfgyCJvdI8
+zWe9VFOZkIEO14ZkD4uQoLQTFJAETe7sSPJHwPNm/9IAX2xu0ktGaLteF6k8jfE
ykx+KuW7e5D+hJdT7LbyDjWPMJBB7U374h1P0Z/WGfdoFFbkwN7UfPvdCxT8LBHD
ErMchplqH1iW1zP28QplokO492PLmlXfc3JjaZ15kx3xr1YXZ6Z1lZ1Z93nZ9h+k
l1qBuKmaelRYp0vofcBdvEzT97DChhslPTpxhK+biiF4Jrazcxi4GZnhFbpShI+o
R1BpFNoP2/bX+ZOUC+In15GlWF77zxOe/rrNbwGIJY7Ht4riLaa7U08c4zi61sKM
p61N8n7hh7Nml1k7IW7E0hjPWguJQkkKDilfctKp+iWq13IzcNJhkoWkH8pD9y83
MJh6EsHT5ZNlzILy6Ny0SdckTV+TKNPwl5CGXayVrGK7bxQ1XcUHg85Ag2oWOG0b
nybNNSwqj7TQIROb9jrJ/6QxaxW2PXQjBnK+KJb8iCBCAdxd48AfhUL+I0mrEuvx
gpswLInl0CyfuxypwO8wuT4XgjtMQi79rrDb3itCyfR54Rtq7e4=
=6fCc
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmOHh1sACgkQmmx57+YA
GNmQLxAAilkBtZ8tT4Dn2FWerOWUIxrBO5heq1YrOQ3o0r4bOCCtV0Rza0g2N8NI
IMdzLqfBluOVNohEv8UpZA6VmRfvHIFLbHeJExaSiNuxWjo9LDXhnjIPSnK5Tkst
QGF0aqdPiS7RJRe8is3eR+w40qlf9Mj7UBqLPmMsjHK1qN9HxOkiZH4h6pXSbDWe
pDHdomnwVbP6V/z/eWdoeglWFxbST9gHMj5Iwrmwl0Ftuu6DHPaUV5Wv3bBcz6l1
otGF8eWNVKi+dfmN1DxqqgjcOx1wvNqnx0TNT09MqKKkbCZmiygOrTXzZMw/I7dX
5bZ/ycMARjkUcS+eLw2H+TC/YSgyF82FRV5Z/h+OKHwVtDhLOWBlOvAfD01LyXPv
8iO3CYOOMt7+AVhuPb/e7noHXUN7yAiNGyI3IU9n/enlgWqxxGGBguPZGiFLpETH
auwj+/qq/lZG68//LmfvCSbikhTtmnflMIR50yKTtMAKAFNZvw544dVM9doVGpbw
aNhkntoB1R99KiCJoaV9D8h8qKMwIQxZbMdTNENUbpDXUNsEtm4+/rOCS0X+CFy+
sxXTJ7G/DdnejluhKAI6e2KJ0is4x4fXy+vmT+AqGPaabjz9utKVKnXaOYHZTY1X
DRVntuqQZtZjx5COvZPO2qxlecJ26+K6maJmS5UqbNGCwQxgGG0=
=vkEv
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-6.2/devicetree' of https://github.com/Broadcom/stblinux into soc/dt
This pull request contains Broadcom ARM-based SoCs Device Tree changes
for 6.2, please pull the following:
- Linus adds support for the D-Link DWL-8610AP which is based upon the
BCM53016 SoC and the D-Link DIR-890L routers
- Maxime resolves a long standing issue affecting Raspberry Pi devices
by switching entirely over to the VPU firmware clock provider rather
than mixing the "bare metal" clock driver and VPU
- Rafal corrects the description of the TP-Link router partitions to
use the "safeloader" partition parser
- Stefan fixes a number of invalid underscores in the bcm283x DTS files
and also moves the ACT LED into a separate DTS include file for better
re-use
- Krzysztof aligns the LEDs DT nodes to the proper schema format
- Pierre adds missing cache properties to various SoCs
* tag 'arm-soc/for-6.2/devicetree' of https://github.com/Broadcom/stblinux:
arm: dts: Update cache properties for broadcom
ARM: dts: broadcom: align LED node names with dtschema
ARM: dts: bcm283x: Move ACT LED into separate dtsi
ARM: dts: bcm283x: Fix underscores in node names
ARM: dts: BCM5301X: Correct description of TP-Link partitions
ARM: dts: bcm47094: Add devicetree for D-Link DIR-890L
dt-bindings: ARM: add bindings for the D-Link DIR-890L
ARM: dts: bcm2835-rpi: Use firmware clocks for display
ARM: dts: bcm283x: Remove bcm2835-rpi-common.dtsi from SoC DTSI
ARM: dts: bcm53016: Add devicetree for D-Link DWL-8610AP
dt-bindings: ARM: add bindings for the D-Link DWL-8610AP
Link: https://lore.kernel.org/r/20221129191755.542584-1-f.fainelli@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Just few addtions including updates to cache information on various
platforms to align well with the bindings, addition of cache information
on FVP Rev C model, addition of SPE to Foundation model and updates to
LED node names.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmOF8SgACgkQAEG6vDF+
4ph7uhAAs+XsDmozvzn6q7XtgEDAsSmuXSSmdLawW9dOWBm4h9yP+b0ShfHasSlN
Z/tg/Erc2IGLW6bYwam0JGLyzast2ifOVJfCe1M7Whfep3j2o/SV2eN43qnjSwwp
enryQNw7hF9ShEHtvvBqruHg8BWNQqCBvJRAKHtemcXeXhaad0b32y53ahdbzB0o
FAGD/i2KRJeghlw2s0lw4+jiV+W5UodoEZ4WbxQJSjTcUyqeDLiqfhs0KoHTJjaM
s8rHKHRxRr+Wctibf25JW5iiBhe7ON9rb+KRVubI0jp9LVauO+dzujnR2dP+SbUC
wc61U2G0QEZof+QCSYfVVQbuJ1bLVUzl6hJMl+c5VHSBq6x75jCCHdCq9PlTlXGl
nmBPVP5haDgO17WsJuO5absawsBJehihwC0JLkk6bWnm15+XE7NnMDDLZRHSNuU9
zterk4LVN7d94o+/WwK8XeZtzFfFS4l0OlIDBYWoP0hljvHc/p4jXOh2vvFucPmN
L/YORmb8Vrj2Ql0NY+NPiHt1MDFIOftcYSufBuzzMQJw3pYQAQMFHKc3rUxB6Xee
6CAikSuBWWO7qdY9yP8Fk+GceLrACSk5C/1pJOA2cBQiLw1whYI+4RRzn0g+Su9Z
VN5KU6tP44tE0625ip5wLwcV1TiBa7ghKCezav+4b+TUFxLM0Yw=
=Of6J
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmOHhtEACgkQmmx57+YA
GNkW1g//dZ1xCZ7m0Zduhqp6dfLkC9IUyhkguIba3HsKLL5A1t4E5/AfZM7befQr
rWZZTeeGQtpBlWo0/X2BjtNkcyDH02fU3Mk7mM3raOO/MF+C0IEAmaLWOkiekgYf
dHg5ig2GKVI71wPRtYa0JfwFztgnkhGdMS+PSvELxDlisziVwSaGYOW+1DEZibU6
hMTOZzePFvaI7Q6iP9N6uyLLiLnddrg2ar37z2ummsMgxVd51Eoe6IPzEa2B3bWB
KswrPcVZ2XTINiOleMN9kE8awsZJOacIiNXP8oluffcu/03tLlwv3UYr5RDddtp8
9K2GtXJ1wzvqXbpHo4a1AMwPkgUbcFgLZSl9ypZZP+afwIxxfunr7Ca0gdwBI4GR
5cCrEih9SXGeegrzMz4wa5f5PuxDyeyRHzFzpnDX5z+6+8Q85tGUdDa6cazoBQyS
U11Ty+zu+6NGWVPGz3e6udaJUkkQfF1TO0Kb9EtmNhOh6avj0J4kQT9Vx7PeoXpW
LRPlBt8TLktS7/9jpAvdk0cLkULRqjLlONDRhdrIzGwW3+fMGVyMyWCWnNSu6ia/
M57KTbfZsuq1p223arIC4z6YHPe0JKl5fgEaYRl9fVf3YcMPhrwllsLom5/xf25S
2K7scuKw/AGE+2GSvVgyqyeqeeu+OaYpYkhtXZHVEMBuvBir7Oo=
=GlOv
-----END PGP SIGNATURE-----
Merge tag 'juno-updates-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/dt
Armv8 Juno/FVP updates for v6.2
Just few addtions including updates to cache information on various
platforms to align well with the bindings, addition of cache information
on FVP Rev C model, addition of SPE to Foundation model and updates to
LED node names.
* tag 'juno-updates-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
ARM: dts: vexpress: align LED node names with dtschema
arm64: dts: fvp: Add information about L1 and L2 caches
arm64: dts: fvp: Add SPE to Foundation FVP
arm64: dts: Update cache properties for Arm Ltd platforms
arm64: dts: juno: Add thermal critical trip points
Link: https://lore.kernel.org/r/20221129115111.2464233-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Some more fixes for v6.1, some of these are very old and were originally
intended to get sent for v5.18 but got lost in the shuffle when there
was an issue with Linus not liking my branching strategy and I rebuilt
bits of my workflow. The ops changes have been validated by people
looking at real hardware and are how things getting dropped got noticed.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmOHg3AACgkQJNaLcl1U
h9AO+gf8C1E6GHk6UI3mU/xYCap0KgJavCVEJKExal2/pgCtCheC8OutFRAepsEM
mnbhfNImFEEkD/3YfdhH22XqavDE+fN0DSfFhkdiEbsfPTrHhc+PeWU8aQzEyOxT
tND7X01tmkWojmmoWJcVAv/z7hW1vF3FE/RUOiXHi3M7LhlJiSMy2ZkxHC9AEIz/
3jyahc2LbzZ5SuIo+c8kSoErg/mZ8zI2KlAGx3afpFAHUiGkSVWmhl4XOQ+1lozQ
dv4JtPMDx7SsM06GXUcvVTf6RI8QZQq6ohfz02BK7+NqD+odRrg3WlbabcTLvi1k
LpNg5saPWYx8JVwHu9ggLtNfE5TAVQ==
=T8ew
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v6.1-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v6.1
Some more fixes for v6.1, some of these are very old and were originally
intended to get sent for v5.18 but got lost in the shuffle when there
was an issue with Linus not liking my branching strategy and I rebuilt
bits of my workflow. The ops changes have been validated by people
looking at real hardware and are how things getting dropped got noticed.
for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.
If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL
input parameter, there is no problem for the 'Device not found' branch.
For the normal path, add pci_dev_put() in amd_gpio_exit().
Fixes: f942a7de04 ("gpio: add a driver for GPIO pins found on AMD-8111 south bridge chips")
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
If a triple fault was fixed by kvm_x86_ops.nested_ops->triple_fault (by
turning it into a vmexit), there is no need to leave vcpu_enter_guest().
Any vcpu->requests will be caught later before the actual vmentry,
and in fact vcpu_enter_guest() was not initializing the "r" variable.
Depending on the compiler's whims, this could cause the
x86_64/triple_fault_event_test test to fail.
Cc: Maxim Levitsky <mlevitsk@redhat.com>
Fixes: 92e7d5c83a ("KVM: x86: allow L1 to not intercept triple fault")
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Remove the unused @kvm argument from gpc_unmap_khva().
Signed-off-by: Michal Luczaj <mhal@rbox.co>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Formalize "gpc" as the acronym and use it in function names.
No functional change intended.
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Michal Luczaj <mhal@rbox.co>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Torture test the cases where the runstate crosses a page boundary, and
and especially the case where it's configured in 32-bit mode and doesn't,
but then switching to 64-bit mode makes it go onto the second page.
To simplify this, make the KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST ioctl
also update the guest runstate area. It already did so if the actual
runstate changed, as a side-effect of kvm_xen_update_runstate(). So
doing it in the plain adjustment case is making it more consistent, as
well as giving us a nice way to trigger the update without actually
running the vCPU again and changing the values.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Closer inspection of the Xen code shows that we aren't supposed to be
using the XEN_RUNSTATE_UPDATE flag unconditionally. It should be
explicitly enabled by guests through the HYPERVISOR_vm_assist hypercall.
If we randomly set the top bit of ->state_entry_time for a guest that
hasn't asked for it and doesn't expect it, that could make the runtimes
fail to add up and confuse the guest. Without the flag it's perfectly
safe for a vCPU to read its own vcpu_runstate_info; just not for one
vCPU to read *another's*.
I briefly pondered adding a word for the whole set of VMASST_TYPE_*
flags but the only one we care about for HVM guests is this, so it
seemed a bit pointless.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <20221127122210.248427-3-dwmw2@infradead.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The guest runstate area can be arbitrarily byte-aligned. In fact, even
when a sane 32-bit guest aligns the overall structure nicely, the 64-bit
fields in the structure end up being unaligned due to the fact that the
32-bit ABI only aligns them to 32 bits.
So setting the ->state_entry_time field to something|XEN_RUNSTATE_UPDATE
is buggy, because if it's unaligned then we can't update the whole field
atomically; the low bytes might be observable before the _UPDATE bit is.
Xen actually updates the *byte* containing that top bit, on its own. KVM
should do the same.
In addition, we cannot assume that the runstate area fits within a single
page. One option might be to make the gfn_to_pfn cache cope with regions
that cross a page — but getting a contiguous virtual kernel mapping of a
discontiguous set of IOMEM pages is a distinctly non-trivial exercise,
and it seems this is the *only* current use case for the GPC which would
benefit from it.
An earlier version of the runstate code did use a gfn_to_hva cache for
this purpose, but it still had the single-page restriction because it
used the uhva directly — because it needs to be able to do so atomically
when the vCPU is being scheduled out, so it used pagefault_disable()
around the accesses and didn't just use kvm_write_guest_cached() which
has a fallback path.
So... use a pair of GPCs for the first and potential second page covering
the runstate area. We can get away with locking both at once because
nothing else takes more than one GPC lock at a time so we can invent
a trivial ordering rule.
The common case where it's all in the same page is kept as a fast path,
but in both cases, the actual guest structure (compat or not) is built
up from the fields in @vx, following preset pointers to the state and
times fields. The only difference is whether those pointers point to
the kernel stack (in the split case) or to guest memory directly via
the GPC. The fast path is also fixed to use a byte access for the
XEN_RUNSTATE_UPDATE bit, then the only real difference is the dual
memcpy.
Finally, Xen also does write the runstate area immediately when it's
configured. Flip the kvm_xen_update_runstate() and …_guest() functions
and call the latter directly when the runstate area is set. This means
that other ioctls which modify the runstate also write it immediately
to the guest when they do so, which is also intended.
Update the xen_shinfo_test to exercise the pathological case where the
XEN_RUNSTATE_UPDATE flag in the top byte of the state_entry_time is
actually in a different page to the rest of the 64-bit word.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fix assigned-addresses for every PCIe Root Port
Align LED node names with dtschema
Add a new kirkwood based board: Zyxel NSA310S
Fix compatible string for gpios for Armada 38x and 39x
Add interrupts for watchdog on Armada XP
Turris Omnia (Armada 385 based):
- Add switch port 6 node
- Add ethernet aliases
Switch to using gpiod API in pm-board code
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQQYqXDMF3cvSLY+g9cLBhiOFHI71QUCY4QDYQAKCRALBhiOFHI7
1WAEAJ9oLKs8LbLgO7CqgfY9j4g/bMWlMACfSxssqM2DqLd3EADd1y/JRRhwFaU=
=iXv9
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmOHeb0ACgkQmmx57+YA
GNlkixAAjvYjGVuQgStoWcrnT/fL8qatMCtXxvgNDT8Tq0zil5l7I7sLS7CIvc/j
nkRdgtP62xBafYVd0BdP9vUWmW9lzTHgxitsxU5lE/J5+65xtnnBpfpd1cPg4r4k
kv4D2UmIbiAQL7JrvVB3nL36K8tNN1PSN+pOTrJ9zccyjrMRGXgYsCF9zZRJSVyB
Rn39xJM3gFawlFkSRJDAwcByck/8sGd7bhGCgZq5SeSQ1dDuy7w0PP06QoXa8oqe
74EfcsDpP/2EbWKHjOSick4JDC6fiMM+i3G3h9MuZbpRemY2SxABHtaVdYh3G2yJ
v8VRR5lZLK6A4iOYd2IDw27kHNh30kX6kHLhAYaXqBRc4ZTElSyo5V7xCWJIJ28T
I6HunSsbBls1HXqkkMeow73VHoFe4ec1PNA5ToSrSzxqxUMvbAPza9Wflm+PktE7
eKajK+IIsBXwI5JtXAnF+uAMVuhBcqDnQrrOzbedts2cA14Hm/LG0dmb8BE9bDJR
npv1NpZBP/xg5l98FFgaq06He6gcY7vlT3VyGUj3N+VYDQq0LFA0WK+pV1Z+ORYS
vyfHANvhJ03FgFX2396rfkzXT7j8fhmbaGi+WvdPa2e39c5BQ6a2aP/G6iCmWWpe
7wg7iXE2npepBtj7PGOC9DX/xZ2nKjaR/fJMHc5wu46RnJO7JII=
=Vk4K
-----END PGP SIGNATURE-----
Merge tag 'mvebu-dt-6.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into soc/dt
mvebu dt for 6.2 (part 1)
Fix assigned-addresses for every PCIe Root Port
Align LED node names with dtschema
Add a new kirkwood based board: Zyxel NSA310S
Fix compatible string for gpios for Armada 38x and 39x
Add interrupts for watchdog on Armada XP
Turris Omnia (Armada 385 based):
- Add switch port 6 node
- Add ethernet aliases
Switch to using gpiod API in pm-board code
* tag 'mvebu-dt-6.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu:
ARM: dts: armada-xp: add interrupts for watchdog
ARM: dts: armada: align LED node names with dtschema
ARM: mvebu: switch to using gpiod API in pm-board code
ARM: dts: armada-39x: Fix compatible string for gpios
ARM: dts: armada-38x: Fix compatible string for gpios
ARM: dts: turris-omnia: Add switch port 6 node
ARM: dts: turris-omnia: Add ethernet aliases
ARM: dts: armada-39x: Fix assigned-addresses for every PCIe Root Port
ARM: dts: armada-38x: Fix assigned-addresses for every PCIe Root Port
ARM: dts: armada-375: Fix assigned-addresses for every PCIe Root Port
ARM: dts: armada-xp: Fix assigned-addresses for every PCIe Root Port
ARM: dts: armada-370: Fix assigned-addresses for every PCIe Root Port
ARM: dts: dove: Fix assigned-addresses for every PCIe Root Port
ARM: dts: kirkwood: Add Zyxel NSA310S board
Link: https://lore.kernel.org/r/87cz979adf.fsf@BL-laptop
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
TC Applied Technologies (TCAT) produces TCD3070 as final DICE ASIC for
communication in IEEE 1394 bus for IEC 61883-1/6 protocol. As long as I
know, latter model of Focusrite Saffire Pro 40 is an application of the
ASIC and only in the market for consumers.
This patchset adds support for the device. The device has several
remarkable points.
1. No support for extended synchronization information section in TCAT
general protocol. The value of GLOBAL_EXTENDED_STATUS register is always
zero. Additionally, NOTIFY_EXT_STATUS message is never emitted.
2. No support for TCAT protocol extension. Hard coding is required for
format of CIP payload.
3. During several seconds after changing sampling rate, the block to
process PCM frames is under disfunction. When starting packet streaming
during the state, the block is never function till configuring different
sampling rate and several seconds.
This commit adds support for the device. The item 1 and 2 can be
adaptable, while item 3 is not. It's not preferable that user process
is forced to sleep during the disfunction in the call of ioctl(2) with
SNDRV_PCM_IOCTL_HW_PARAMS or SNDRV_PCM_IOCTL_PREPARE request. It's
inconvenient but let user configure preferable sampling rate in advance
of starting PCM substream.
The content of configuration ROM in the device I used is available at:
* https://github.com/takaswie/am-config-roms/
I note that any mixer control operation is implemented by unique
transaction. The frame of request consists of 16 bytes header followed
by payload.
header (4 quadlets):
1st: the type of request, prefixed with 0x8000
2nd: counter at 2 bytes in MSB side, the length of data at 2 bytes in LSB
side
3rd: parameter 0
4th: parameter 1
payload (variable length if need):
5th-: data according to parameters
The request frame is sent by block write request to 0x'ffff'e040'01c0.
The frame of response is similar to the frame of request, but it is
header only, thus fixed to 16 bytes. The response frame is sent to the
address which is registered by lock transaction to 0x'ffff'e040'0008.
If the operation results in batch of data, the 2nd quadlet of header
includes the length of data like request. The data is itself readable
by read block request to 0x'ffff'e040'0030, which includes both
header and payload for data, thus the length to read should be the
length of data plus 16 bytes for header
The actual value of request, parameter 0, parameter 1, and data is
unclear yet.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20221130143313.43880-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For Lexicon I-ONIX FW810S, the call of ioctl(2) with
SNDRV_PCM_IOCTL_HW_PARAMS can returns -ETIMEDOUT. This is a regression due
to the commit 41319eb56e ("ALSA: dice: wait just for
NOTIFY_CLOCK_ACCEPTED after GLOBAL_CLOCK_SELECT operation"). The device
does not emit NOTIFY_CLOCK_ACCEPTED notification when accepting
GLOBAL_CLOCK_SELECT operation with the same parameters as current ones.
This commit fixes the regression. When receiving no notification, return
-ETIMEDOUT as long as operating for any change.
Fixes: 41319eb56e ("ALSA: dice: wait just for NOTIFY_CLOCK_ACCEPTED after GLOBAL_CLOCK_SELECT operation")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20221130130604.29774-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
According to the description in ti-sn65dsi86's datasheet:
CHA_HSYNC_POLARITY:
0 = Active High Pulse. Synchronization signal is high for the sync
pulse width. (default)
1 = Active Low Pulse. Synchronization signal is low for the sync
pulse width.
CHA_VSYNC_POLARITY:
0 = Active High Pulse. Synchronization signal is high for the sync
pulse width. (Default)
1 = Active Low Pulse. Synchronization signal is low for the sync
pulse width.
We should only set these bits when the polarity is negative.
Fixes: a095f15c00 ("drm/bridge: add support for sn65dsi86 bridge driver")
Signed-off-by: Qiqi Zhang <eddy.zhang@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125104558.84616-1-eddy.zhang@rock-chips.com
