Skip to content

Khadas edge 4.4.y - #31

Merged
numbqq merged 4 commits into
khadas:khadas-edge-4.4.yfrom
yan-wyb:khadas-edge-4.4.y
Oct 26, 2020
Merged

Khadas edge 4.4.y#31
numbqq merged 4 commits into
khadas:khadas-edge-4.4.yfrom
yan-wyb:khadas-edge-4.4.y

Conversation

@yan-wyb

@yan-wyb yan-wyb commented Oct 24, 2020

Copy link
Copy Markdown

No description provided.

yan-wyb and others added 4 commits October 20, 2020 15:46
@yan-wyb
Merge pull request #6 from khadas/khadas-edge-4.4.y
1cc73d3 
Khadas edge 4.4.y
@yan-wyb
Add overlays supports
5cd2932 
Signed-off-by: yan <yan-wyb@foxmail.com>
@yan-wyb
arm64 / dts / overlays : move spi3 and i2s0 to overlays
4740313 
Signed-off-by: yan <yan-wyb@foxmail.com>
@yan-wyb
arm64 / boot / dts / overlays : move onewire to overlays
16763cf 
Signed-off-by: yan <yan-wyb@foxmail.com>
@numbqq
numbqq merged commit 23a5445 into khadas:khadas-edge-4.4.y Oct 26, 2020
numbqq pushed a commit that referenced this pull request Nov 7, 2020
@HowardChung1209 @gregkh
Bluetooth: L2CAP: handle l2cap config request during open state
b7d0ca7 
[ Upstream commit 96298f6 ]

According to Core Spec Version 5.2 | Vol 3, Part A 6.1.5,
the incoming L2CAP_ConfigReq should be handled during
OPEN state.

The section below shows the btmon trace when running
L2CAP/COS/CFD/BV-12-C before and after this change.

=== Before ===
...
> ACL Data RX: Handle 256 flags 0x02 dlen 12                #22
      L2CAP: Connection Request (0x02) ident 2 len 4
        PSM: 1 (0x0001)
        Source CID: 65
< ACL Data TX: Handle 256 flags 0x00 dlen 16                #23
      L2CAP: Connection Response (0x03) ident 2 len 8
        Destination CID: 64
        Source CID: 65
        Result: Connection successful (0x0000)
        Status: No further information available (0x0000)
< ACL Data TX: Handle 256 flags 0x00 dlen 12                #24
      L2CAP: Configure Request (0x04) ident 2 len 4
        Destination CID: 65
        Flags: 0x0000
> HCI Event: Number of Completed Packets (0x13) plen 5      #25
        Num handles: 1
        Handle: 256
        Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5      #26
        Num handles: 1
        Handle: 256
        Count: 1
> ACL Data RX: Handle 256 flags 0x02 dlen 16                #27
      L2CAP: Configure Request (0x04) ident 3 len 8
        Destination CID: 64
        Flags: 0x0000
        Option: Unknown (0x10) [hint]
        01 00                                            ..
< ACL Data TX: Handle 256 flags 0x00 dlen 18                #28
      L2CAP: Configure Response (0x05) ident 3 len 10
        Source CID: 65
        Flags: 0x0000
        Result: Success (0x0000)
        Option: Maximum Transmission Unit (0x01) [mandatory]
          MTU: 672
> HCI Event: Number of Completed Packets (0x13) plen 5      #29
        Num handles: 1
        Handle: 256
        Count: 1
> ACL Data RX: Handle 256 flags 0x02 dlen 14                #30
      L2CAP: Configure Response (0x05) ident 2 len 6
        Source CID: 64
        Flags: 0x0000
        Result: Success (0x0000)
> ACL Data RX: Handle 256 flags 0x02 dlen 20                #31
      L2CAP: Configure Request (0x04) ident 3 len 12
        Destination CID: 64
        Flags: 0x0000
        Option: Unknown (0x10) [hint]
        01 00 91 02 11 11                                ......
< ACL Data TX: Handle 256 flags 0x00 dlen 14                #32
      L2CAP: Command Reject (0x01) ident 3 len 6
        Reason: Invalid CID in request (0x0002)
        Destination CID: 64
        Source CID: 65
> HCI Event: Number of Completed Packets (0x13) plen 5      #33
        Num handles: 1
        Handle: 256
        Count: 1
...
=== After ===
...
> ACL Data RX: Handle 256 flags 0x02 dlen 12               #22
      L2CAP: Connection Request (0x02) ident 2 len 4
        PSM: 1 (0x0001)
        Source CID: 65
< ACL Data TX: Handle 256 flags 0x00 dlen 16               #23
      L2CAP: Connection Response (0x03) ident 2 len 8
        Destination CID: 64
        Source CID: 65
        Result: Connection successful (0x0000)
        Status: No further information available (0x0000)
< ACL Data TX: Handle 256 flags 0x00 dlen 12               #24
      L2CAP: Configure Request (0x04) ident 2 len 4
        Destination CID: 65
        Flags: 0x0000
> HCI Event: Number of Completed Packets (0x13) plen 5     #25
        Num handles: 1
        Handle: 256
        Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5     #26
        Num handles: 1
        Handle: 256
        Count: 1
> ACL Data RX: Handle 256 flags 0x02 dlen 16               #27
      L2CAP: Configure Request (0x04) ident 3 len 8
        Destination CID: 64
        Flags: 0x0000
        Option: Unknown (0x10) [hint]
        01 00                                            ..
< ACL Data TX: Handle 256 flags 0x00 dlen 18               #28
      L2CAP: Configure Response (0x05) ident 3 len 10
        Source CID: 65
        Flags: 0x0000
        Result: Success (0x0000)
        Option: Maximum Transmission Unit (0x01) [mandatory]
          MTU: 672
> HCI Event: Number of Completed Packets (0x13) plen 5     #29
        Num handles: 1
        Handle: 256
        Count: 1
> ACL Data RX: Handle 256 flags 0x02 dlen 14               #30
      L2CAP: Configure Response (0x05) ident 2 len 6
        Source CID: 64
        Flags: 0x0000
        Result: Success (0x0000)
> ACL Data RX: Handle 256 flags 0x02 dlen 20               #31
      L2CAP: Configure Request (0x04) ident 3 len 12
        Destination CID: 64
        Flags: 0x0000
        Option: Unknown (0x10) [hint]
        01 00 91 02 11 11                                .....
< ACL Data TX: Handle 256 flags 0x00 dlen 18               #32
      L2CAP: Configure Response (0x05) ident 3 len 10
        Source CID: 65
        Flags: 0x0000
        Result: Success (0x0000)
        Option: Maximum Transmission Unit (0x01) [mandatory]
          MTU: 672
< ACL Data TX: Handle 256 flags 0x00 dlen 12               #33
      L2CAP: Configure Request (0x04) ident 3 len 4
        Destination CID: 65
        Flags: 0x0000
> HCI Event: Number of Completed Packets (0x13) plen 5     #34
        Num handles: 1
        Handle: 256
        Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5     #35
        Num handles: 1
        Handle: 256
        Count: 1
...

Signed-off-by: Howard Chung <howardchung@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
HighwayStar pushed a commit to Amlogic-Lineage/linux that referenced this pull request May 19, 2022
Brian Zhu @HighwayStar
vpp: support 3D with afbc format [1/1]
0e60e3e 
PD#TV-3042

Problem:
3D function did not support afbc format before

Solution:
Add the support case which format is afbc.

Verify:
x301

Change-Id: I38189bfa78eec6ac811fb81631514d7d7b8b3d62
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>

b8d9145 vpp: add interface to force non-afbc path [1/1]
c807fc4 vpp: tm2: add vd2 function for tm2 [2/2]
eea348a vpp: tm2: add vpp and sr support [1/2]
f08c28c video: Some interlace stream will stuck when pts rebound [1/1]
53b2624 amlvideo: reset video_inuse when amlvideo stop [1/1]
17cdaf3 amvideo: set black_threshold_height default 48 [1/1]
1cd025d vpp: set default aspect when the ratecontrol is zero [1/1]
58a2e8f vpp: Modify vframe epoll event [1/1]
94b0dc8 vpp: Modify vframe epoll event [1/1]
e98d6d3 video: enable pts calculation when hold video state changes [1/1]
43d30c4 vpp: add histgram test interface for vpp slt test [1/1]
2677784 amvecm: optimize amvecm update in vsync [1/1]
af78b0f vpp: increase the afbc burst len as 4 for txlx [1/1]
1ace6fc vpp: hold the vpp setting when meet the non-dw afbc frame [1/1]
e8a3758 vpp: 3d: disable crop when 3d playback or hdmi in [1/1]
4e6774d vpp: add black_threshold to disable video when window is too small[1/1]
3ae164f vpp: including crop info when AFBC switch to normal frame [1/1]
c67657f vpp: add the pic_mode backup to check difference [1/1]
33b1aee video: timming gets error when switching channels [1/1]
233779e vpp: add log switch in vpp_set_filters [1/1]
b00582b vpp: config the vd1 canvas1 correctly when 3D enabled [1/1]
607bc19 vpp: support 3D with afbc format [1/1]

vpp: config the vd1 canvas1 correctly when 3D enabled [1/1]

PD#TV-3086

Problem:
3D display abnormal. The vd1 canvas1 was incorrect.

Solution:
When enabled 3D function, config vd1 canvas1 correctly

Verify:
x301

Change-Id: I201cda2f33badf1af54ab4f177a17f761c7cea8d
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>

vpp: add log switch in vpp_set_filters [1/1]

PD#SWPL-5942

Problem:
Too many log when DI process called the vpp_set_filters with AFBC.

Solution:
Add log switch to disable it.

Verify:
verified on X301

Change-Id: I34c8573bed78e49d27ec386279e929e617bf76d5
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>

video: timming gets error when switching channels [1/1]

PD#TV-3062

Problem:
When switching channels, Hisense platform needs hold video,
and the timming obtained at this time is wrong

Solution:
because we have add hold video function, so get width and
height interface give the last video frame width and height,
and so on change the video

Verify:
X301

Change-Id: I331a4589dcb5f5785dce7eea6d8cd03c92d733d2
Signed-off-by: Xiaoming Sui <xiaoming.sui@amlogic.com>

vpp: add the pic_mode backup to check difference [1/1]

PD#TV-2929

Problem:
The pic_mode in cur_dispbuf was changed but not be detected.

Solution:
Add global pic_mode variable to check if the pic_mode in cur_dispbuf
is changed. If so, force vpp_set_filters.

Verify:
verified on x301

Change-Id: I5b95f512ad0823b031989f05526f114694887f2b
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>

vpp: including crop info when AFBC switch to normal frame [1/1]

PD#SWPL-6347

Problem:
When AFBC switch to normal frame, excluding the crop information, the pps
parameters are calculated with wrong input size.

Solution:
1.Add the crop information, when afbc swicth to normal frame.
2.check ratio of compress_width/width, sync to crop value

Verify:
verified on x301

Change-Id: Ib943f8a11263ce577952e589bc172d8b7bafd954
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>
Signed-off-by: Luan Yuan <luan.yuan@amlogic.com>

vpp: add black_threshold to disable video when window is too small [1/1]

PD#TV-3641

Problem:
Add new interface to disable video when window is too small

Solution:
Add the black_threshold interface to control the threshold size.
And set the default value is width=20, height=30.

Verify:
verified by x301

Change-Id: Ifeb376c2e2edbb5706b2cdc2d08421bd0086b01e
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>

vpp: 3d: disable crop when 3d playback or hdmi in [1/1]

PD#TV-3962

Problem:
3D mode does not support crop function

Solution:
Remove crop when 3D display.

Verify:
Verified on x301

Change-Id: Id35dd662886be24e3ec78d070e3a70f513f89b16
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>

vpp: hold the vpp setting when meet the non-dw afbc frame [1/1]

PD#SWPL-7513

Problem:
When meet the non-dw afbc frame, vpp can not display with
scaling down as expected.

Solution:
Hold the current vpp setting and wait provider to switch
non-afbc.

Verify:
x301

Change-Id: I3c0e678d2da42376f3a77e334b8c5ce48460273b
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>

vpp: increase the afbc burst len as 4 for txlx [1/1]

PD#TV-3132

Problem:
When playing 4K afbc and scaling down to small window,
the vskip is 1 and DDR freq is also lower, the display will
flicker caused by DDR bandwidth issue.

Solution:
Increase the afbc mif burst len from 2 to 4. And enable
the dmc adjustment in that case.

Verify:
r311, verify pass

Change-Id: Ia431a93f6083fd584b7e2eb14f777c5a5e7c20e7
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>

amvecm: optimize amvecm update in vsync [1/1]

PD#SWPL-6475

Problem:
hdmi input signal, video flicker

Solution:
optimize amvecm update in vsync

Verify:
verify on TL1

Change-Id: I3379333053fc52b8a33747ca83b1d6d68ea874ab
Signed-off-by: MingLiang Dong <mingliang.dong@amlogic.com>

vpp: add histgram test interface for vpp slt test [1/1]

PD#khadasGH-31

Problem:
Need pattern to filter the error vpp modules in SLT test

Solution:
Using clipping and histgram function to create the test pattern
and get the histgram data.

Verify:
verified on w400

Change-Id: I52680c96f568980f71ac8c27c4b66352fea96651
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>

video: enable pts calculation when hold video state changes [1/1]

PD#TV-3999

Problem:
dtmb individual channel switching speed is slow,
it takes about 16s

Solution:
enable pts calculation when hold video
state changes.

Verify:
X301

Change-Id: I4c8eda3af3df894d8116461abf63c3dda45c8ce3
Signed-off-by: Rui Wang <rui.wang@amlogic.com>

vpp: Modify vframe epoll event [1/1]

PD#SWPL-8850

Problem:
too many print when channel change.

Solution:
Modify vframe epoll event flow to avoid same event.

Verify:
verify on marconi.

Change-Id: Id709439f24d3cad82df6082c477cacce1a9b9cc7
Signed-off-by: qiyao.zhou <qiyao.zhou@amlogic.com>

vpp: Modify vframe epoll event [1/1]

PD#SWPL-8850

Problem:
too many print when channel change.

Solution:
Modify vframe epoll event flow to avoid same event.

Verify:
verify on marconi.

Change-Id: Iefbd190c0280276bf941c48bf99706a0f2573df1
Signed-off-by: qiyao.zhou <qiyao.zhou@amlogic.com>

vpp: set default aspect when the ratecontrol is zero [1/1]

PD#TV-5266

Problem:
Vpp used the wrong aspect ratio in 3D, screen mode = normal
and aspect ratio is 0 in ratecontrol variable.

Solution:
When the aspect ratio is 0, set the default value as
(height << 8) / width

Verify:
Verified by x301

Change-Id: I34f7cd3ce5ed1818d3090ebb4be934225038625e
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>

amvideo: set black_threshold_height default 48 [1/1]

PD#OTT-1836

Problem:
disable video when window is too small

Solution:
set black_threshold_height default 48

Verify:
U212

Change-Id: I9ed7deb54baef1c44bb9cc0c1a4d699140663864
Signed-off-by: jintao xu <jintao.xu@amlogic.com>

amlvideo: reset video_inuse when amlvideo stop [1/1]

PD#TV-6189

Problem:
video_inuse always is 1 when codec server crash

Solution:
reset video_inuse when amlvideo stop

Verify:
TL1

Change-Id: I5b1b808668e3b2fb78781a4ea1ccbaefc3507d2b
Signed-off-by: Lifeng Cao <lifeng.cao@amlogic.com>

video: Some interlace stream will stuck when pts rebound [1/1]

PD#TV-6236

Problem:
Some interlace stream di has buffer count more than 16
If video pts rebound in this stream. The condition that
(abs(omx_pts_set_index - next_vf->omx_index) <= 16) is
not true. So this frame can not toggle always.

Solution:
Delete this condition that
(abs(omx_pts_set_index - next_vf->omx_index) <= 16)

Verify:
verify TL1

Change-Id: I7e8c12ec72d086b0516f7c7490b492e16e36e8fe
Signed-off-by: Lifeng Cao <lifeng.cao@amlogic.com>

vpp: tm2: add vpp and sr support [1/2]

PD#SWPL-6615

Problem:
Need vpp and sr supprt for sm2

Solution:
add support for tm2

Verify:
test pass on tm2 skt

Change-Id: I0ae2cb178fcbe047cdfec6b4e200424178993e6e
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>

vpp: tm2: add vd2 function for tm2 [2/2]

PD#SWPL-6615

Problem:
Need vd2 function

Solution:
add vd2 function for tm2:
1.vd2 pps scaler
2.disable vd2 afbc

Verify:
test pass on tm2 skt

Change-Id: I7af5de741b90e443ee065218aecb823ef06d66a7
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>
Signed-off-by: Luan Yuan <luan.yuan@amlogic.com>

vpp: add interface to force non-afbc path [1/1]

PD#SWPL-7035

Problem:
When DI switched to use VD AFBC, need vpp force to non-afbc first.
Otherwise, display willl flash.

Solution:
Provide new interface to request the vpp release afbc hardware first.
Then return the current afbc status.

Verify:
verified on x301

Change-Id: Ibb2b897db7d2f2c40006433d63709988992c84f1
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>
numbqq pushed a commit to numbqq/linux that referenced this pull request Mar 6, 2026
Alexei Starovoitov
Merge branch 'bpf-cpumap-devmap-fix-per-cpu-bulk-queue-races-on-preem…
8c0d9e1 
…pt_rt'

Jiayuan Chen says:

====================
bpf: Fix per-CPU bulk queue races on PREEMPT_RT

On PREEMPT_RT kernels, local_bh_disable() only calls migrate_disable()
(when PREEMPT_RT_NEEDS_BH_LOCK is not set) and does not disable
preemption. This means CFS scheduling can preempt a task inside the
per-CPU bulk queue (bq) operations in cpumap and devmap, allowing
another task on the same CPU to concurrently access the same bq,
leading to use-after-free, list corruption, and kernel panics.

Patch 1 fixes the cpumap race in bq_flush_to_queue(), originally
reported by syzbot [1].

Patch 2 fixes the same class of race in devmap's bq_xmit_all(),
identified by code inspection after Sebastian Andrzej Siewior pointed
out that devmap has the same per-CPU bulk queue pattern [2].

Both patches use local_lock_nested_bh() to serialize access to the
per-CPU bq. On non-RT this is a pure lockdep annotation with no
overhead; on PREEMPT_RT it provides a per-CPU sleeping lock.

To reproduce the devmap race, insert an mdelay(100) in bq_xmit_all()
after "cnt = bq->count" and before the actual transmit loop. Then pin
two threads to the same CPU, each running BPF_PROG_TEST_RUN with an XDP
program that redirects to a DEVMAP entry (e.g. a veth pair). CFS
timeslicing during the mdelay window causes interleaving. Without the
fix, KASAN reports null-ptr-deref due to operating on freed frames:

  BUG: KASAN: null-ptr-deref in __build_skb_around+0x22d/0x340
  Write of size 32 at addr 0000000000000d50 by task devmap_race_rep/449

  CPU: 0 UID: 0 PID: 449 Comm: devmap_race_rep Not tainted 6.19.0+ khadas#31 PREEMPT_RT
  Call Trace:
   <TASK>
   __build_skb_around+0x22d/0x340
   build_skb_around+0x25/0x260
   __xdp_build_skb_from_frame+0x103/0x860
   veth_xdp_rcv_bulk_skb.isra.0+0x162/0x320
   veth_xdp_rcv.constprop.0+0x61e/0xbb0
   veth_poll+0x280/0xb50
   __napi_poll.constprop.0+0xa5/0x590
   net_rx_action+0x4b0/0xea0
   handle_softirqs.isra.0+0x1b3/0x780
   __local_bh_enable_ip+0x12a/0x240
   xdp_test_run_batch.constprop.0+0xedd/0x1f60
   bpf_test_run_xdp_live+0x304/0x640
   bpf_prog_test_run_xdp+0xd24/0x1b70
   __sys_bpf+0x61c/0x3e00
   </TASK>

  Kernel panic - not syncing: Fatal exception in interrupt

[1] https://lore.kernel.org/all/69369331.a70a0220.38f243.009d.GAE@google.com/T/
[2] https://lore.kernel.org/bpf/20260212023634.366343-1-jiayuan.chen@linux.dev/

v3 -> v4: https://lore.kernel.org/all/20260213034018.284146-1-jiayuan.chen@linux.dev/
- Move panic trace to cover letter. (Sebastian Andrzej Siewior)
- Add Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> to both patches
  from cover letter.

v2 -> v3: https://lore.kernel.org/bpf/20260212023634.366343-1-jiayuan.chen@linux.dev/
- Fix commit message: remove incorrect "spin_lock() becomes rt_mutex"
claim, the per-CPU bq has no spin_lock at all. (Sebastian Andrzej Siewior)
- Fix commit message: accurately describe local_lock_nested_bh()
behavior instead of referencing local_lock(). (Sebastian Andrzej Siewior)
- Remove incomplete discussion of snapshot alternative.
(Sebastian Andrzej Siewior)
- Remove panic trace from commit message. (Sebastian Andrzej Siewior)
- Add patch 2/2 for devmap, same race pattern. (Sebastian Andrzej Siewior)

v1 -> v2: https://lore.kernel.org/bpf/20260211064417.196401-1-jiayuan.chen@linux.dev/
- Use local_lock_nested_bh()/local_unlock_nested_bh() instead of
local_lock()/local_unlock(), since these paths already run under
local_bh_disable(). (Sebastian Andrzej Siewior)
- Replace "Caller must hold bq->bq_lock" comment with
lockdep_assert_held() in bq_flush_to_queue(). (Sebastian Andrzej Siewior)
- Fix Fixes tag to 3253cb4 ("softirq: Allow to drop the
softirq-BKL lock on PREEMPT_RT") which is the actual commit that
makes the race possible. (Sebastian Andrzej Siewior)
====================

Link: https://patch.msgid.link/20260225121459.183121-1-jiayuan.chen@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
HighwayStar pushed a commit to Lineage-Rockchip/android_kernel_rockchip_kernel-6.1 that referenced this pull request Oct 12, 2026
@cloehle @gregkh
cpufreq: Initialize cpufreq-based invariance before subsys
75d9fb6 
[ Upstream commit 8ffe28b ]

commit 2a6c727 ("cpufreq: Initialize cpufreq-based
frequency-invariance later") postponed the frequency invariance
initialization to avoid disabling it in the error case.
This isn't locking safe, instead move the initialization up before
the subsys interface is registered (which will rebuild the
sched_domains) and add the corresponding disable on the error path.

Observed lockdep without this patch:
[    0.989686] ======================================================
[    0.989688] WARNING: possible circular locking dependency detected
[    0.989690] 6.17.0-rc4-cix-build+ khadas#31 Tainted: G S
[    0.989691] ------------------------------------------------------
[    0.989692] swapper/0/1 is trying to acquire lock:
[    0.989693] ffff800082ada7f8 (sched_energy_mutex){+.+.}-{4:4}, at: rebuild_sched_domains_energy+0x30/0x58
[    0.989705]
               but task is already holding lock:
[    0.989706] ffff000088c89bc8 (&policy->rwsem){+.+.}-{4:4}, at: cpufreq_online+0x7f8/0xbe0
[    0.989713]
               which lock already depends on the new lock.

Fixes: 2a6c727 ("cpufreq: Initialize cpufreq-based frequency-invariance later")
Signed-off-by: Christian Loehle <christian.loehle@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
HighwayStar pushed a commit to Lineage-Rockchip/android_kernel_rockchip_kernel-6.1 that referenced this pull request Oct 12, 2026
@sean-jc @gregkh
KVM: Don't clobber irqfd routing type when deassigning irqfd
6d14ba1 
commit b4d37cd upstream.

When deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's
routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86
and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI.  Instead, to
handle a concurrent routing update, verify that the irqfd is still active
before consuming the routing information.  As evidenced by the x86 and
arm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),
clobbering the entry type without notifying arch code is surprising and
error prone.

As a bonus, checking that the irqfd is active provides a convenient
location for documenting _why_ KVM must not consume the routing entry for
an irqfd that is in the process of being deassigned: once the irqfd is
deleted from the list (which happens *before* the eventfd is detached), it
will no longer receive updates via kvm_irq_routing_update(), and so KVM
could deliver an event using stale routing information (relative to
KVM_SET_GSI_ROUTING returning to userspace).

As an even better bonus, explicitly checking for the irqfd being active
fixes a similar bug to the one the clobbering is trying to prevent: if an
irqfd is deactivated, and then its routing is changed,
kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing()
(because the irqfd isn't in the list).  And so if the irqfd is in bypass
mode, IRQs will continue to be posted using the old routing information.

As for kvm_arch_irq_bypass_del_producer(), clobbering the routing type
results in KVM incorrectly keeping the IRQ in bypass mode, which is
especially problematic on AMD as KVM tracks IRQs that are being posted to
a vCPU in a list whose lifetime is tied to the irqfd.

Without the help of KASAN to detect use-after-free, the most common
sympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to
the memory for irqfd structure being re-allocated and zeroed, resulting
in irqfd->irq_bypass_data being NULL when read by
avic_update_iommu_vcpu_affinity():

  BUG: kernel NULL pointer dereference, address: 0000000000000018
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0
  Oops: Oops: 0000 [khadas#1] SMP
  CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test
  Tainted: G     U  W  O        6.19.0-smp--5dddc257e6b2-irqfd khadas#31 NONE
  Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE
  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025
  RIP: 0010:amd_iommu_update_ga+0x19/0xe0
  Call Trace:
   <TASK>
   avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd]
   __avic_vcpu_load+0xf4/0x130 [kvm_amd]
   kvm_arch_vcpu_load+0x89/0x210 [kvm]
   vcpu_load+0x30/0x40 [kvm]
   kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm]
   kvm_vcpu_ioctl+0x571/0x6a0 [kvm]
   __se_sys_ioctl+0x6d/0xb0
   do_syscall_64+0x6f/0x9d0
   entry_SYSCALL_64_after_hwframe+0x4b/0x53
  RIP: 0033:0x46893b
    </TASK>
  ---[ end trace 0000000000000000 ]---

If AVIC is inhibited when the irfd is deassigned, the bug will manifest as
list corruption, e.g. on the next irqfd assignment.

  list_add corruption. next->prev should be prev (ffff8d474d5cd588),
                       but was 0000000000000000. (next=ffff8d8658f86530).
  ------------[ cut here ]------------
  kernel BUG at lib/list_debug.c:31!
  Oops: invalid opcode: 0000 [khadas#1] SMP
  CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test
  Tainted: G     U  W  O        6.19.0-smp--f19dc4d680ba-irqfd khadas#28 NONE
  Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE
  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025
  RIP: 0010:__list_add_valid_or_report+0x97/0xc0
  Call Trace:
   <TASK>
   avic_pi_update_irte+0x28e/0x2b0 [kvm_amd]
   kvm_pi_update_irte+0xbf/0x190 [kvm]
   kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm]
   irq_bypass_register_consumer+0xcd/0x170 [irqbypass]
   kvm_irqfd+0x4c6/0x540 [kvm]
   kvm_vm_ioctl+0x118/0x5d0 [kvm]
   __se_sys_ioctl+0x6d/0xb0
   do_syscall_64+0x6f/0x9d0
   entry_SYSCALL_64_after_hwframe+0x4b/0x53
   </TASK>
  ---[ end trace 0000000000000000 ]---

On Intel and arm64, the bug is less noisy, as the end result is that the
device keeps posting IRQs to the vCPU even after it's been deassigned.

Note, the worst of the breakage can be traced back to commit cb21073
("KVM: Pass new routing entries and irqfd when updating IRTEs"), as before
that commit KVM would pull the routing information from the per-VM routing
table.  But as above, similar bugs have existed since support for IRQ
bypass was added.  E.g. if a routing change finished before irq_shutdown()
invoked kvm_arch_irq_bypass_del_producer(), VMX and SVM would see stale
routing information and potentially leave the irqfd in bypass mode.

Alternatively, x86 could be fixed by explicitly checking irq_bypass_vcpu
instead of irq_entry.type in kvm_arch_irq_bypass_del_producer(), and arm64
could be modified to utilize irq_bypass_vcpu in a similar manner.  But (a)
that wouldn't fix the routing updates bug, and (b) fixing core code doesn't
preclude x86 (or arm64) from adding such code as a sanity check (spoiler
alert).

Fixes: f70c20a ("KVM: Add an arch specific hooks in 'struct kvm_kernel_irqfd'")
Fixes: cb21073 ("KVM: Pass new routing entries and irqfd when updating IRTEs")
Fixes: a0d7e2f ("KVM: arm64: vgic-v4: Only attempt vLPI mapping for actual MSIs")
Cc: stable@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>
Link: https://patch.msgid.link/20260113174606.104978-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@yan-wyb @numbqq