kernel: upgrade the kernel to the version 6.6.52
We upgrade the kernel to the version 6.6.52 to fix the following CVEs: CVE-2024-46786: https://nvd.nist.gov/vuln/detail/CVE-2024-46786 CVE-2024-46746: https://nvd.nist.gov/vuln/detail/CVE-2024-46746 CVE-2024-46731: https://nvd.nist.gov/vuln/detail/CVE-2024-46731 CVE-2024-46782: https://nvd.nist.gov/vuln/detail/CVE-2024-46782 CVE-2024-46759: https://nvd.nist.gov/vuln/detail/CVE-2024-46759 CVE-2024-46758: https://nvd.nist.gov/vuln/detail/CVE-2024-46758 CVE-2024-46757: https://nvd.nist.gov/vuln/detail/CVE-2024-46757 CVE-2024-46756: https://nvd.nist.gov/vuln/detail/CVE-2024-46756 CVE-2024-46800: https://nvd.nist.gov/vuln/detail/CVE-2024-46800 CVE-2024-46796: https://nvd.nist.gov/vuln/detail/CVE-2024-46796 CVE-2024-46798: https://nvd.nist.gov/vuln/detail/CVE-2024-46798 CVE-2024-46747: https://nvd.nist.gov/vuln/detail/CVE-2024-46747 CVE-2024-46738: https://nvd.nist.gov/vuln/detail/CVE-2024-46738 CVE-2024-46740: https://nvd.nist.gov/vuln/detail/CVE-2024-46740 CVE-2024-46741: https://nvd.nist.gov/vuln/detail/CVE-2024-46741 CVE-2024-46743: https://nvd.nist.gov/vuln/detail/CVE-2024-46743 It also contains kernel 6.6.50 which fix following CVEs: CVE-2024-46725: https://nvd.nist.gov/vuln/detail/CVE-2024-46725 CVE-2024-46724: https://nvd.nist.gov/vuln/detail/CVE-2024-46724 CVE-2024-46723: https://nvd.nist.gov/vuln/detail/CVE-2024-46723 CVE-2024-46722: https://nvd.nist.gov/vuln/detail/CVE-2024-46722 CVE-2024-45026: https://nvd.nist.gov/vuln/detail/CVE-2024-45026 CVE-2024-46687: https://nvd.nist.gov/vuln/detail/CVE-2024-46687 CVE-2024-46674: https://nvd.nist.gov/vuln/detail/CVE-2024-46674 CVE-2024-46673: https://nvd.nist.gov/vuln/detail/CVE-2024-46673 CVE-2024-44941: https://nvd.nist.gov/vuln/detail/CVE-2024-44941 CVE-2024-44940: https://nvd.nist.gov/vuln/detail/CVE-2024-44940 CVE-2024-41040: https://nvd.nist.gov/vuln/detail/CVE-2024-41040 CVE-2024-41039: https://nvd.nist.gov/vuln/detail/CVE-2024-41039 CVE-2024-42280: https://nvd.nist.gov/vuln/detail/CVE-2024-42280 CVE-2024-41059: https://nvd.nist.gov/vuln/detail/CVE-2024-41059 CVE-2024-44983: https://nvd.nist.gov/vuln/detail/CVE-2024-44983 CVE-2024-44985: https://nvd.nist.gov/vuln/detail/CVE-2024-44985 CVE-2024-44974: https://nvd.nist.gov/vuln/detail/CVE-2024-44974 CVE-2024-44987: https://nvd.nist.gov/vuln/detail/CVE-2024-44987 CVE-2024-44986: https://nvd.nist.gov/vuln/detail/CVE-2024-44986 CVE-2024-44999: https://nvd.nist.gov/vuln/detail/CVE-2024-44999 CVE-2024-44997: https://nvd.nist.gov/vuln/detail/CVE-2024-44997 CVE-2024-44998: https://nvd.nist.gov/vuln/detail/CVE-2024-44998 CVE-2024-43882: https://nvd.nist.gov/vuln/detail/CVE-2024-43882 CVE-2024-43873: https://nvd.nist.gov/vuln/detail/CVE-2024-43873 It also contains kernel 6.6.47 which fix following CVEs: CVE-2024-43858: https://nvd.nist.gov/vuln/detail/CVE-2024-43858 CVE-2024-42314: https://nvd.nist.gov/vuln/detail/CVE-2024-42314 CVE-2024-42313: https://nvd.nist.gov/vuln/detail/CVE-2024-42313 CVE-2024-42302: https://nvd.nist.gov/vuln/detail/CVE-2024-42302 CVE-2024-42301: https://nvd.nist.gov/vuln/detail/CVE-2024-42301 CVE-2024-41046: https://nvd.nist.gov/vuln/detail/CVE-2024-41046 CVE-2024-41049: https://nvd.nist.gov/vuln/detail/CVE-2024-41049 CVE-2024-41057: https://nvd.nist.gov/vuln/detail/CVE-2024-41057 CVE-2024-41058: https://nvd.nist.gov/vuln/detail/CVE-2024-41058 CVE-2024-41070: https://nvd.nist.gov/vuln/detail/CVE-2024-41070 CVE-2024-41073: https://nvd.nist.gov/vuln/detail/CVE-2024-41073 CVE-2024-42284: https://nvd.nist.gov/vuln/detail/CVE-2024-42284 CVE-2024-42271: https://nvd.nist.gov/vuln/detail/CVE-2024-42271 CVE-2024-42285: https://nvd.nist.gov/vuln/detail/CVE-2024-42285 CVE-2024-44942: https://nvd.nist.gov/vuln/detail/CVE-2024-44942 CVE-2024-44934: https://nvd.nist.gov/vuln/detail/CVE-2024-44934 CVE-2024-43900: https://nvd.nist.gov/vuln/detail/CVE-2024-43900 For updated kernel v6.6.52 has contained following patch under ice-ptp-vsi directory: ice-fix-VSI-lists-confusion-when-adding-VLANs.patch it will be deleted to adapt source code. Verification: - Build kernel and out of tree modules success for rt and std. - Build iso success for rt and std. - Install success onto a All-in-One lab with rt kernel. - Boot up successfully in the lab. - The sanity testing was run and the test results PASS. - The cyclictest benchmark was also run on the starlingx lab, the result is "samples: 86400000 avg: 1674.128 std_dev: 49.673 max: 3711 99.9999th percentile: 2625". - The values are relatively similar kernel v6.6.40 (1674 vs 1658, 49 vs 44 and 2625 vs 2590). Closes-Bug: 2077387 Closes-Bug: 2079952 Closes-Bug: 2081784 Change-Id: I140260d0a9c5617ee8f9650cc8a89db5b284a8db Signed-off-by: Peng Zhang <Peng.Zhang2@windriver.com>
This commit is contained in:
Peng Zhang
parent
6c5f0dd9e3
commit
7f53ef73e9
@ -24,7 +24,7 @@
|
||||
# building.
|
||||
# Tools needed: tar/sed
|
||||
|
||||
KERNEL_HEAD_COMMIT=a1cc143cd640beb4c378a16345e25853224b5522
|
||||
KERNEL_HEAD_COMMIT=a2252fce7715d414dc5877902ff4fe07630aa92c
|
||||
DEBIAN_FILE=linux_6.1.27-1~bpo11%2B1.debian.tar.xz
|
||||
|
||||
tar xvf linux-yocto-${KERNEL_HEAD_COMMIT}.tar.gz
|
||||
|
||||
@ -1,14 +1,14 @@
|
||||
---
|
||||
debver: 6.6.40
|
||||
debver: 6.6.52
|
||||
debname: linux-rt
|
||||
dl_hook: dl_hook
|
||||
dl_files:
|
||||
linux-yocto-a1cc143cd640beb4c378a16345e25853224b5522.tar.gz:
|
||||
linux-yocto-a2252fce7715d414dc5877902ff4fe07630aa92c.tar.gz:
|
||||
topdir: null
|
||||
url:
|
||||
"https://git.yoctoproject.org/linux-yocto/snapshot/\
|
||||
linux-yocto-a1cc143cd640beb4c378a16345e25853224b5522.tar.gz"
|
||||
sha256sum: cc316c6742a2848b9d8e2b198fe2ec5ad68d4e881fcbebf1612b6148afa2d557
|
||||
linux-yocto-a2252fce7715d414dc5877902ff4fe07630aa92c.tar.gz"
|
||||
sha256sum: 0dc003f200aba9965ec7609c67eaffd88900ad608597007ce55d3a3f9d2d318a
|
||||
linux_6.1.27-1~bpo11%2B1.debian.tar.xz:
|
||||
topdir: null
|
||||
url:
|
||||
|
||||
@ -1,88 +0,0 @@
|
||||
From cb5660d20f96228a3cd29c0b035f16402b1ce3b5 Mon Sep 17 00:00:00 2001
|
||||
From: Michal Schmidt <mschmidt@redhat.com>
|
||||
Date: Wed, 4 Sep 2024 11:39:22 +0200
|
||||
Subject: [PATCH] ice: fix VSI lists confusion when adding VLANs
|
||||
|
||||
The description of function ice_find_vsi_list_entry says:
|
||||
Search VSI list map with VSI count 1
|
||||
|
||||
However, since the blamed commit (see Fixes below), the function no
|
||||
longer checks vsi_count. This causes a problem in ice_add_vlan_internal,
|
||||
where the decision to share VSI lists between filter rules relies on the
|
||||
vsi_count of the found existing VSI list being 1.
|
||||
|
||||
The reproducing steps:
|
||||
1. Have a PF and two VFs.
|
||||
There will be a filter rule for VLAN 0, referring to a VSI list
|
||||
containing VSIs: 0 (PF), 2 (VF#0), 3 (VF#1).
|
||||
2. Add VLAN 1234 to VF#0.
|
||||
ice will make the wrong decision to share the VSI list with the new
|
||||
rule. The wrong behavior may not be immediately apparent, but it can
|
||||
be observed with debug prints.
|
||||
3. Add VLAN 1234 to VF#1.
|
||||
ice will unshare the VSI list for the VLAN 1234 rule. Due to the
|
||||
earlier bad decision, the newly created VSI list will contain
|
||||
VSIs 0 (PF) and 3 (VF#1), instead of expected 2 (VF#0) and 3 (VF#1).
|
||||
4. Try pinging a network peer over the VLAN interface on VF#0.
|
||||
This fails.
|
||||
|
||||
Reproducer script at:
|
||||
https://gitlab.com/mschmidt2/repro/-/blob/master/RHEL-46814/test-vlan-vsi-list-confusion.sh
|
||||
Commented debug trace:
|
||||
https://gitlab.com/mschmidt2/repro/-/blob/master/RHEL-46814/ice-vlan-vsi-lists-debug.txt
|
||||
Patch adding the debug prints:
|
||||
https://gitlab.com/mschmidt2/linux/-/commit/f8a8814623944a45091a77c6094c40bfe726bfdb
|
||||
(Unsafe, by the way. Lacks rule_lock when dumping in ice_remove_vlan.)
|
||||
|
||||
Michal Swiatkowski added to the explanation that the bug is caused by
|
||||
reusing a VSI list created for VLAN 0. All created VFs' VSIs are added
|
||||
to VLAN 0 filter. When a non-zero VLAN is created on a VF which is already
|
||||
in VLAN 0 (normal case), the VSI list from VLAN 0 is reused.
|
||||
It leads to a problem because all VFs (VSIs to be specific) that are
|
||||
subscribed to VLAN 0 will now receive a new VLAN tag traffic. This is
|
||||
one bug, another is the bug described above. Removing filters from
|
||||
one VF will remove VLAN filter from the previous VF. It happens a VF is
|
||||
reset. Example:
|
||||
- creation of 3 VFs
|
||||
- we have VSI list (used for VLAN 0) [0 (pf), 2 (vf1), 3 (vf2), 4 (vf3)]
|
||||
- we are adding VLAN 100 on VF1, we are reusing the previous list
|
||||
because 2 is there
|
||||
- VLAN traffic works fine, but VLAN 100 tagged traffic can be received
|
||||
on all VSIs from the list (for example broadcast or unicast)
|
||||
- trust is turning on VF2, VF2 is resetting, all filters from VF2 are
|
||||
removed; the VLAN 100 filter is also removed because 3 is on the list
|
||||
- VLAN traffic to VF1 isn't working anymore, there is a need to recreate
|
||||
VLAN interface to readd VLAN filter
|
||||
|
||||
One thing I'm not certain about is the implications for the LAG feature,
|
||||
which is another caller of ice_find_vsi_list_entry. I don't have a
|
||||
LAG-capable card at hand to test.
|
||||
|
||||
Fixes: 23ccae5ce15f ("ice: changes to the interface with the HW and FW for SRIOV_VF+LAG")
|
||||
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
|
||||
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
|
||||
Reviewed-by: Dave Ertman <David.m.ertman@intel.com>
|
||||
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
|
||||
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
||||
(cherry picked from commit d2940002b0aa42898de815a1453b29d440292386)
|
||||
Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
|
||||
---
|
||||
drivers/net/ethernet/intel/ice/ice_switch.c | 2 +-
|
||||
1 file changed, 1 insertion(+), 1 deletion(-)
|
||||
|
||||
diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c
|
||||
index d2a2388d4fa0..24b68193cd08 100644
|
||||
--- a/drivers/net/ethernet/intel/ice/ice_switch.c
|
||||
+++ b/drivers/net/ethernet/intel/ice/ice_switch.c
|
||||
@@ -3142,7 +3142,7 @@ ice_find_vsi_list_entry(struct ice_hw *hw, u8 recp_id, u16 vsi_handle,
|
||||
|
||||
list_head = &sw->recp_list[recp_id].filt_rules;
|
||||
list_for_each_entry(list_itr, list_head, list_entry) {
|
||||
- if (list_itr->vsi_list_info) {
|
||||
+ if (list_itr->vsi_count == 1 && list_itr->vsi_list_info) {
|
||||
map_info = list_itr->vsi_list_info;
|
||||
if (test_bit(vsi_handle, map_info->vsi_map)) {
|
||||
*vsi_list_id = map_info->vsi_list_id;
|
||||
--
|
||||
2.43.0
|
||||
|
||||
@ -102,7 +102,6 @@ ice-VDF/0035-ice-Don-t-process-extts-if-PTP-is-disabled.patch
|
||||
ice-VDF/0036-ice-Introduce-ice_ptp_hw-struct.patch
|
||||
ice-VDF/0037-ice-Introduce-ice_get_base_incval-helper.patch
|
||||
ice-VDF/0038-ice-modify-the-ice-driver-version-to-stx.4.patch
|
||||
ice-ptp-vsi/0001-ice-fix-VSI-lists-confusion-when-adding-VLANs.patch
|
||||
ice-ptp-vsi/0002-ice-modify-the-ice-driver-version-to-stx.5.patch
|
||||
ice-ptp-vsi/0003-ice-add-ice_adapter-for-shared-data-across-PFs-on-th.patch
|
||||
ice-ptp-vsi/0004-ice-avoid-the-PTP-hardware-semaphore-in-gettimex64-p.patch
|
||||
|
||||
@ -1,3 +1,9 @@
|
||||
linux-rt (6.6.52-1) unstable; urgency=medium
|
||||
|
||||
* New upstream update:
|
||||
https://git.yoctoproject.org/linux-yocto/log/?h=v6.6%2Fstandard%2Fpreempt-rt%2Fbase&qt=range&q=a2252fce7715d414dc5877902ff4fe07630aa92c
|
||||
-- Peng Zhang <Peng.Zhang2@windriver.com> Thu, 17 Oct 2024 22:44:35 +0800
|
||||
|
||||
linux-rt (6.6.40-1) unstable; urgency=medium
|
||||
|
||||
* New upstream update:
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
# be put at the same path where this script is located.
|
||||
# Tools needed: tar
|
||||
|
||||
KERNEL_HEAD_COMMIT=12524ba963715d599cd28515eb8814476b6bf1d9
|
||||
KERNEL_HEAD_COMMIT=01b1f32be4b0eb108c00b16ec4eef29ce7fa9546
|
||||
DEBIAN_FILE=linux_6.1.27-1~bpo11%2B1.debian.tar.xz
|
||||
|
||||
tar xvf linux-yocto-${KERNEL_HEAD_COMMIT}.tar.gz
|
||||
|
||||
@ -1,14 +1,14 @@
|
||||
---
|
||||
debver: 6.6.40
|
||||
debver: 6.6.52
|
||||
debname: linux
|
||||
dl_hook: dl_hook
|
||||
dl_files:
|
||||
linux-yocto-12524ba963715d599cd28515eb8814476b6bf1d9.tar.gz:
|
||||
linux-yocto-01b1f32be4b0eb108c00b16ec4eef29ce7fa9546.tar.gz:
|
||||
topdir: null
|
||||
url:
|
||||
"https://git.yoctoproject.org/linux-yocto/snapshot/\
|
||||
linux-yocto-12524ba963715d599cd28515eb8814476b6bf1d9.tar.gz"
|
||||
sha256sum: efe728c9ba5153a03b205d98566067402b96447e4ae6804d6fac677fe29a5faf
|
||||
linux-yocto-01b1f32be4b0eb108c00b16ec4eef29ce7fa9546.tar.gz"
|
||||
sha256sum: eab4cf25bcb0e66d2610e6fb55da6916250374aa0f97a94bfec8b19895c189b1
|
||||
linux_6.1.27-1~bpo11%2B1.debian.tar.xz:
|
||||
topdir: null
|
||||
url:
|
||||
|
||||
@ -1,88 +0,0 @@
|
||||
From cb5660d20f96228a3cd29c0b035f16402b1ce3b5 Mon Sep 17 00:00:00 2001
|
||||
From: Michal Schmidt <mschmidt@redhat.com>
|
||||
Date: Wed, 4 Sep 2024 11:39:22 +0200
|
||||
Subject: [PATCH] ice: fix VSI lists confusion when adding VLANs
|
||||
|
||||
The description of function ice_find_vsi_list_entry says:
|
||||
Search VSI list map with VSI count 1
|
||||
|
||||
However, since the blamed commit (see Fixes below), the function no
|
||||
longer checks vsi_count. This causes a problem in ice_add_vlan_internal,
|
||||
where the decision to share VSI lists between filter rules relies on the
|
||||
vsi_count of the found existing VSI list being 1.
|
||||
|
||||
The reproducing steps:
|
||||
1. Have a PF and two VFs.
|
||||
There will be a filter rule for VLAN 0, referring to a VSI list
|
||||
containing VSIs: 0 (PF), 2 (VF#0), 3 (VF#1).
|
||||
2. Add VLAN 1234 to VF#0.
|
||||
ice will make the wrong decision to share the VSI list with the new
|
||||
rule. The wrong behavior may not be immediately apparent, but it can
|
||||
be observed with debug prints.
|
||||
3. Add VLAN 1234 to VF#1.
|
||||
ice will unshare the VSI list for the VLAN 1234 rule. Due to the
|
||||
earlier bad decision, the newly created VSI list will contain
|
||||
VSIs 0 (PF) and 3 (VF#1), instead of expected 2 (VF#0) and 3 (VF#1).
|
||||
4. Try pinging a network peer over the VLAN interface on VF#0.
|
||||
This fails.
|
||||
|
||||
Reproducer script at:
|
||||
https://gitlab.com/mschmidt2/repro/-/blob/master/RHEL-46814/test-vlan-vsi-list-confusion.sh
|
||||
Commented debug trace:
|
||||
https://gitlab.com/mschmidt2/repro/-/blob/master/RHEL-46814/ice-vlan-vsi-lists-debug.txt
|
||||
Patch adding the debug prints:
|
||||
https://gitlab.com/mschmidt2/linux/-/commit/f8a8814623944a45091a77c6094c40bfe726bfdb
|
||||
(Unsafe, by the way. Lacks rule_lock when dumping in ice_remove_vlan.)
|
||||
|
||||
Michal Swiatkowski added to the explanation that the bug is caused by
|
||||
reusing a VSI list created for VLAN 0. All created VFs' VSIs are added
|
||||
to VLAN 0 filter. When a non-zero VLAN is created on a VF which is already
|
||||
in VLAN 0 (normal case), the VSI list from VLAN 0 is reused.
|
||||
It leads to a problem because all VFs (VSIs to be specific) that are
|
||||
subscribed to VLAN 0 will now receive a new VLAN tag traffic. This is
|
||||
one bug, another is the bug described above. Removing filters from
|
||||
one VF will remove VLAN filter from the previous VF. It happens a VF is
|
||||
reset. Example:
|
||||
- creation of 3 VFs
|
||||
- we have VSI list (used for VLAN 0) [0 (pf), 2 (vf1), 3 (vf2), 4 (vf3)]
|
||||
- we are adding VLAN 100 on VF1, we are reusing the previous list
|
||||
because 2 is there
|
||||
- VLAN traffic works fine, but VLAN 100 tagged traffic can be received
|
||||
on all VSIs from the list (for example broadcast or unicast)
|
||||
- trust is turning on VF2, VF2 is resetting, all filters from VF2 are
|
||||
removed; the VLAN 100 filter is also removed because 3 is on the list
|
||||
- VLAN traffic to VF1 isn't working anymore, there is a need to recreate
|
||||
VLAN interface to readd VLAN filter
|
||||
|
||||
One thing I'm not certain about is the implications for the LAG feature,
|
||||
which is another caller of ice_find_vsi_list_entry. I don't have a
|
||||
LAG-capable card at hand to test.
|
||||
|
||||
Fixes: 23ccae5ce15f ("ice: changes to the interface with the HW and FW for SRIOV_VF+LAG")
|
||||
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
|
||||
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
|
||||
Reviewed-by: Dave Ertman <David.m.ertman@intel.com>
|
||||
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
|
||||
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
||||
(cherry picked from commit d2940002b0aa42898de815a1453b29d440292386)
|
||||
Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
|
||||
---
|
||||
drivers/net/ethernet/intel/ice/ice_switch.c | 2 +-
|
||||
1 file changed, 1 insertion(+), 1 deletion(-)
|
||||
|
||||
diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c
|
||||
index d2a2388d4fa0..24b68193cd08 100644
|
||||
--- a/drivers/net/ethernet/intel/ice/ice_switch.c
|
||||
+++ b/drivers/net/ethernet/intel/ice/ice_switch.c
|
||||
@@ -3142,7 +3142,7 @@ ice_find_vsi_list_entry(struct ice_hw *hw, u8 recp_id, u16 vsi_handle,
|
||||
|
||||
list_head = &sw->recp_list[recp_id].filt_rules;
|
||||
list_for_each_entry(list_itr, list_head, list_entry) {
|
||||
- if (list_itr->vsi_list_info) {
|
||||
+ if (list_itr->vsi_count == 1 && list_itr->vsi_list_info) {
|
||||
map_info = list_itr->vsi_list_info;
|
||||
if (test_bit(vsi_handle, map_info->vsi_map)) {
|
||||
*vsi_list_id = map_info->vsi_list_id;
|
||||
--
|
||||
2.43.0
|
||||
|
||||
@ -102,7 +102,6 @@ ice-VDF/0035-ice-Don-t-process-extts-if-PTP-is-disabled.patch
|
||||
ice-VDF/0036-ice-Introduce-ice_ptp_hw-struct.patch
|
||||
ice-VDF/0037-ice-Introduce-ice_get_base_incval-helper.patch
|
||||
ice-VDF/0038-ice-modify-the-ice-driver-version-to-stx.4.patch
|
||||
ice-ptp-vsi/0001-ice-fix-VSI-lists-confusion-when-adding-VLANs.patch
|
||||
ice-ptp-vsi/0002-ice-modify-the-ice-driver-version-to-stx.5.patch
|
||||
ice-ptp-vsi/0003-ice-add-ice_adapter-for-shared-data-across-PFs-on-th.patch
|
||||
ice-ptp-vsi/0004-ice-avoid-the-PTP-hardware-semaphore-in-gettimex64-p.patch
|
||||
|
||||
@ -1,3 +1,9 @@
|
||||
linux (6.6.52-1) unstable; urgency=medium
|
||||
|
||||
* New upstream update:
|
||||
https://git.yoctoproject.org/linux-yocto/log/?h=v6.6%2Fstandard%2Fbase&qt=range&q=01b1f32be4b0eb108c00b16ec4eef29ce7fa9546
|
||||
-- Peng Zhang <Peng.Zhang2@windriver.com> Thu, 17 Oct 2024 12:23:49 +0800
|
||||
|
||||
linux (6.6.40-1) unstable; urgency=medium
|
||||
|
||||
* New upstream update:
|
||||
|
||||
Loading…
Reference in New Issue
Block a user