Currently we remove EA inode from mbcache as soon as its xattr refcount
drops to zero. However there can be pending attempts to reuse the inode
and thus refcount handling code has to handle the situation when
refcount increases from zero anyway. So save some work and just keep EA
inode in mbcache until it is getting evicted. At that moment we are sure
following iget() of EA inode will fail anyway (or wait for eviction to
finish and load things from the disk again) and so removing mbcache
entry at that moment is fine and simplifies the code a bit.
CC: stable(a)vger.kernel.org
Fixes: 82939d7999df ("ext4: convert to mbcache2")
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
fs/ext4/inode.c | 2 ++
fs/ext4/xattr.c | 24 ++++++++----------------
fs/ext4/xattr.h | 1 +
3 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 3dce7d058985..7450ee734262 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -177,6 +177,8 @@ void ext4_evict_inode(struct inode *inode)
trace_ext4_evict_inode(inode);
+ if (EXT4_I(inode)->i_flags & EXT4_EA_INODE_FL)
+ ext4_evict_ea_inode(inode);
if (inode->i_nlink) {
/*
* When journalling data dirty buffers are tracked only in the
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 042325349098..7fc40fb1e6b3 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -436,6 +436,14 @@ static int ext4_xattr_inode_iget(struct inode *parent, unsigned long ea_ino,
return err;
}
+/* Remove entry from mbcache when EA inode is getting evicted */
+void ext4_evict_ea_inode(struct inode *inode)
+{
+ if (EA_INODE_CACHE(inode))
+ mb_cache_entry_delete(EA_INODE_CACHE(inode),
+ ext4_xattr_inode_get_hash(inode), inode->i_ino);
+}
+
static int
ext4_xattr_inode_verify_hashes(struct inode *ea_inode,
struct ext4_xattr_entry *entry, void *buffer,
@@ -976,10 +984,8 @@ int __ext4_xattr_set_credits(struct super_block *sb, struct inode *inode,
static int ext4_xattr_inode_update_ref(handle_t *handle, struct inode *ea_inode,
int ref_change)
{
- struct mb_cache *ea_inode_cache = EA_INODE_CACHE(ea_inode);
struct ext4_iloc iloc;
s64 ref_count;
- u32 hash;
int ret;
inode_lock(ea_inode);
@@ -1002,14 +1008,6 @@ static int ext4_xattr_inode_update_ref(handle_t *handle, struct inode *ea_inode,
set_nlink(ea_inode, 1);
ext4_orphan_del(handle, ea_inode);
-
- if (ea_inode_cache) {
- hash = ext4_xattr_inode_get_hash(ea_inode);
- mb_cache_entry_create(ea_inode_cache,
- GFP_NOFS, hash,
- ea_inode->i_ino,
- true /* reusable */);
- }
}
} else {
WARN_ONCE(ref_count < 0, "EA inode %lu ref_count=%lld",
@@ -1022,12 +1020,6 @@ static int ext4_xattr_inode_update_ref(handle_t *handle, struct inode *ea_inode,
clear_nlink(ea_inode);
ext4_orphan_add(handle, ea_inode);
-
- if (ea_inode_cache) {
- hash = ext4_xattr_inode_get_hash(ea_inode);
- mb_cache_entry_delete(ea_inode_cache, hash,
- ea_inode->i_ino);
- }
}
}
diff --git a/fs/ext4/xattr.h b/fs/ext4/xattr.h
index 77efb9a627ad..060b7a2f485c 100644
--- a/fs/ext4/xattr.h
+++ b/fs/ext4/xattr.h
@@ -178,6 +178,7 @@ extern void ext4_xattr_inode_array_free(struct ext4_xattr_inode_array *array);
extern int ext4_expand_extra_isize_ea(struct inode *inode, int new_extra_isize,
struct ext4_inode *raw_inode, handle_t *handle);
+extern void ext4_evict_ea_inode(struct inode *inode);
extern const struct xattr_handler *ext4_xattr_handlers[];
--
2.35.3
Do not reclaim entries that are currently used by somebody from a
shrinker. Firstly, these entries are likely useful. Secondly, we will
need to keep such entries to protect pending increment of xattr block
refcount.
CC: stable(a)vger.kernel.org
Fixes: 82939d7999df ("ext4: convert to mbcache2")
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
fs/mbcache.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/fs/mbcache.c b/fs/mbcache.c
index 97c54d3a2227..cfc28129fb6f 100644
--- a/fs/mbcache.c
+++ b/fs/mbcache.c
@@ -288,7 +288,7 @@ static unsigned long mb_cache_shrink(struct mb_cache *cache,
while (nr_to_scan-- && !list_empty(&cache->c_list)) {
entry = list_first_entry(&cache->c_list,
struct mb_cache_entry, e_list);
- if (entry->e_referenced) {
+ if (entry->e_referenced || atomic_read(&entry->e_refcnt) > 2) {
entry->e_referenced = 0;
list_move_tail(&entry->e_list, &cache->c_list);
continue;
@@ -302,6 +302,14 @@ static unsigned long mb_cache_shrink(struct mb_cache *cache,
spin_unlock(&cache->c_list_lock);
head = mb_cache_entry_head(cache, entry->e_key);
hlist_bl_lock(head);
+ /* Now a reliable check if the entry didn't get used... */
+ if (atomic_read(&entry->e_refcnt) > 2) {
+ hlist_bl_unlock(head);
+ spin_lock(&cache->c_list_lock);
+ list_add_tail(&entry->e_list, &cache->c_list);
+ cache->c_entry_count++;
+ continue;
+ }
if (!hlist_bl_unhashed(&entry->e_hash_list)) {
hlist_bl_del_init(&entry->e_hash_list);
atomic_dec(&entry->e_refcnt);
--
2.35.3
commit f2e19b36593caed4c977c2f55aeba7408aeb2132 upstream.
The transaction buffer is allocated by using the size of the packet buf,
and subtracting two which seem intended to remove the two tags which are
not present in the target structure. This calculation leads to under
counting memory because of differences between the packet contents and the
target structure. The aid_len field is a u8 in the packet, but a u32 in
the structure, resulting in at least 3 bytes always being under counted.
Further, the aid data is a variable length field in the packet, but fixed
in the structure, so if this field is less than the max, the difference is
added to the under counting.
The last validation check for transaction->params_len is also incorrect
since it employs the same accounting error.
To fix, perform validation checks progressively to safely reach the
next field, to determine the size of both buffers and verify both tags.
Once all validation checks pass, allocate the buffer and copy the data.
This eliminates freeing memory on the error path, as those checks are
moved ahead of memory allocation.
Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
Fixes: 4fbcc1a4cb20 ("nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION")
Cc: stable(a)vger.kernel.org
Signed-off-by: Martin Faltesek <mfaltesek(a)google.com>
Reviewed-by: Guenter Roeck <groeck(a)chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
Change-Id: I22f9d58293b64566c43a7ba254d9e0e8c4dc35fe
---
drivers/nfc/st21nfca/se.c | 61 +++++++++++++++++++--------------------
1 file changed, 30 insertions(+), 31 deletions(-)
This patch cleanly applies in stable kernels 4.9 through 5.4.
The following difference between upstream and 4.9 though 5.4
caused the upstream patch to fail applying:
< - transaction = devm_kzalloc(dev, skb->len - 2, GFP_KERNEL);
---
> - transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
> - skb->len - 2, GFP_KERNEL);
This is the only change made in this patch from the original.
diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index ccaace2a5b0e..d41636504246 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -304,6 +304,8 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
int r = 0;
struct device *dev = &hdev->ndev->dev;
struct nfc_evt_transaction *transaction;
+ u32 aid_len;
+ u8 params_len;
pr_debug("connectivity gate event: %x\n", event);
@@ -312,51 +314,48 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
r = nfc_se_connectivity(hdev->ndev, host);
break;
case ST21NFCA_EVT_TRANSACTION:
- /*
- * According to specification etsi 102 622
+ /* According to specification etsi 102 622
* 11.2.2.4 EVT_TRANSACTION Table 52
* Description Tag Length
* AID 81 5 to 16
* PARAMETERS 82 0 to 255
+ *
+ * The key differences are aid storage length is variably sized
+ * in the packet, but fixed in nfc_evt_transaction, and that the aid_len
+ * is u8 in the packet, but u32 in the structure, and the tags in
+ * the packet are not included in nfc_evt_transaction.
+ *
+ * size in bytes: 1 1 5-16 1 1 0-255
+ * offset: 0 1 2 aid_len + 2 aid_len + 3 aid_len + 4
+ * member name: aid_tag(M) aid_len aid params_tag(M) params_len params
+ * example: 0x81 5-16 X 0x82 0-255 X
*/
- if (skb->len < NFC_MIN_AID_LENGTH + 2 ||
- skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
+ if (skb->len < 2 || skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
return -EPROTO;
- transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
- skb->len - 2, GFP_KERNEL);
- if (!transaction)
- return -ENOMEM;
-
- transaction->aid_len = skb->data[1];
+ aid_len = skb->data[1];
- /* Checking if the length of the AID is valid */
- if (transaction->aid_len > sizeof(transaction->aid)) {
- devm_kfree(dev, transaction);
- return -EINVAL;
- }
+ if (skb->len < aid_len + 4 || aid_len > sizeof(transaction->aid))
+ return -EPROTO;
- memcpy(transaction->aid, &skb->data[2],
- transaction->aid_len);
+ params_len = skb->data[aid_len + 3];
- /* Check next byte is PARAMETERS tag (82) */
- if (skb->data[transaction->aid_len + 2] !=
- NFC_EVT_TRANSACTION_PARAMS_TAG) {
- devm_kfree(dev, transaction);
+ /* Verify PARAMETERS tag is (82), and final check that there is enough
+ * space in the packet to read everything.
+ */
+ if ((skb->data[aid_len + 2] != NFC_EVT_TRANSACTION_PARAMS_TAG) ||
+ (skb->len < aid_len + 4 + params_len))
return -EPROTO;
- }
- transaction->params_len = skb->data[transaction->aid_len + 3];
+ transaction = devm_kzalloc(dev, sizeof(*transaction) + params_len, GFP_KERNEL);
+ if (!transaction)
+ return -ENOMEM;
- /* Total size is allocated (skb->len - 2) minus fixed array members */
- if (transaction->params_len > ((skb->len - 2) -
- sizeof(struct nfc_evt_transaction))) {
- devm_kfree(dev, transaction);
- return -EINVAL;
- }
+ transaction->aid_len = aid_len;
+ transaction->params_len = params_len;
- memcpy(transaction->params, skb->data +
- transaction->aid_len + 4, transaction->params_len);
+ memcpy(transaction->aid, &skb->data[2], aid_len);
+ memcpy(transaction->params, &skb->data[aid_len + 4], params_len);
r = nfc_se_transaction(hdev->ndev, host, transaction);
break;
base-commit: 9d6e67bf50908cc661972969e8f073ec1d1bc97d
--
2.36.1.476.g0c4daa206d-goog
Please backport 5446ff1a6716 ("arm64: dts: imx8mn-beacon: Enable
RTS-CTS on UART3") to 5.15+
This fixes an issue where attempting to use hardware handshaking on
the DB9 port fails.
Thank you,
adam
Please port 4ce01ce36d77 ("arm64: dts: imx8mm-beacon: Enable RTS-CTS on UART3")
to 5.10+
This fixes an issue where attempting to use hardware handshaking on
the DB9 port fails.
[Public]
Hi,
The following revert commit went into 5.19:
commit 1039188806d4 ("Revert "drm/amd/display: Fix DCN3 B0 DP Alt Mapping")
The original commit was mistaken and causes USB-C monitors and monitors behind docks to not light up properly.
Can you please bring this into 5.15.y and later?
Thanks,
Hi,
Please apply upstream commit b577d0cd2104 ("9p: missing chunk of
"fs/9p: Don't update file type when updating file attributes"") to
stable versions v4.9, v4.14, v4.19, v5.4, and v5.10.
It fixes an issue found by syzbot:
https://syzkaller.appspot.com/bug?id=7830d7214570b38391194d814a625dbbfd569e…
The commit applies cleanly to all the versions listed above.
Please also add:
Reported-by: syzbot+16342c5db3ef64c0f60a(a)syzkaller.appspotmail.com
Tested-by: Tadeusz Struk <tadeusz.struk(a)linaro.org>
Thanks,
Tadeusz
This is the start of the stable review cycle for the 5.18.5 release.
There are 11 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 16 Jun 2022 18:37:02 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.5-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.18.5-rc1
Josh Poimboeuf <jpoimboe(a)kernel.org>
x86/speculation/mmio: Print SMT warning
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
KVM: x86/speculation: Disable Fill buffer clear within guests
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/srbds: Update SRBDS mitigation selection
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation: Add a common function for MD_CLEAR mitigation update
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
Documentation: Add documentation for Processor MMIO Stale Data
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +++
Makefile | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 25 +++
arch/x86/include/asm/nospec-branch.h | 2 +
arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 ++++-
arch/x86/kvm/vmx/vmx.c | 72 ++++++
arch/x86/kvm/vmx/vmx.h | 2 +
arch/x86/kvm/x86.c | 3 +
drivers/base/cpu.c | 8 +
include/linux/cpu.h | 3 +
tools/arch/x86/include/asm/cpufeatures.h | 1 +
tools/arch/x86/include/asm/msr-index.h | 25 +++
17 files changed, 676 insertions(+), 41 deletions(-)
Greetings beloved.
Good morning my beloved how are you doing today? My name is Mrs. Rabi
Affason Marcus; Please I want to confirm if you get my previous mail
concerning the Humanitarian Gesture Project that I need your
assistance to execute? Please I wait for your candid response.
I'm announcing the release of the 5.18.5 kernel.
All users of the 5.18 kernel series must upgrade.
The updated 5.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.18.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/admin-guide/hw-vuln/index.rst | 1
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/msr-index.h | 25 +
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++-
arch/x86/kernel/cpu/common.c | 52 +-
arch/x86/kvm/vmx/vmx.c | 72 ++
arch/x86/kvm/vmx/vmx.h | 2
arch/x86/kvm/x86.c | 3
drivers/base/cpu.c | 8
include/linux/cpu.h | 3
tools/arch/x86/include/asm/cpufeatures.h | 1
tools/arch/x86/include/asm/msr-index.h | 25 +
17 files changed, 675 insertions(+), 40 deletions(-)
Greg Kroah-Hartman (1):
Linux 5.18.5
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
I'm announcing the release of the 5.15.48 kernel.
All users of the 5.15 kernel series must upgrade.
The updated 5.15.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.15.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/admin-guide/hw-vuln/index.rst | 1
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/msr-index.h | 25 +
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++-
arch/x86/kernel/cpu/common.c | 52 +-
arch/x86/kvm/vmx/vmx.c | 72 ++
arch/x86/kvm/vmx/vmx.h | 2
arch/x86/kvm/x86.c | 3
drivers/base/cpu.c | 8
include/linux/cpu.h | 3
tools/arch/x86/include/asm/cpufeatures.h | 1
tools/arch/x86/include/asm/msr-index.h | 25 +
17 files changed, 675 insertions(+), 40 deletions(-)
Greg Kroah-Hartman (1):
Linux 5.15.48
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
I'm announcing the release of the 5.10.123 kernel.
All users of the 5.10 kernel series must upgrade.
The updated 5.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.10.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/admin-guide/hw-vuln/index.rst | 1
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/msr-index.h | 25 +
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++-
arch/x86/kernel/cpu/common.c | 52 +-
arch/x86/kvm/vmx/vmx.c | 72 ++
arch/x86/kvm/vmx/vmx.h | 2
arch/x86/kvm/x86.c | 3
drivers/base/cpu.c | 8
include/linux/cpu.h | 3
tools/arch/x86/include/asm/cpufeatures.h | 1
tools/arch/x86/include/asm/msr-index.h | 25 +
17 files changed, 675 insertions(+), 40 deletions(-)
Greg Kroah-Hartman (1):
Linux 5.10.123
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
I'm announcing the release of the 5.4.199 kernel.
All users of the 5.4 kernel series must upgrade.
The updated 5.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.4.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/admin-guide/hw-vuln/index.rst | 1
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/intel-family.h | 9
arch/x86/include/asm/msr-index.h | 25 +
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++-
arch/x86/kernel/cpu/common.c | 52 +-
arch/x86/kvm/vmx/vmx.c | 75 +++
arch/x86/kvm/vmx/vmx.h | 3
arch/x86/kvm/x86.c | 4
drivers/base/cpu.c | 8
include/linux/cpu.h | 4
16 files changed, 663 insertions(+), 41 deletions(-)
Gayatri Kammela (1):
x86/cpu: Add another Alder Lake CPU to the Intel family
Greg Kroah-Hartman (1):
Linux 5.4.199
Guenter Roeck (1):
cpu/speculation: Add prototype for cpu_show_srbds()
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
Tony Luck (1):
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Zhang Rui (1):
x86/cpu: Add Jasper Lake to Intel family
I'm announcing the release of the 4.19.248 kernel.
All users of the 4.19 kernel series must upgrade.
The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/admin-guide/hw-vuln/index.rst | 1
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/intel-family.h | 11
arch/x86/include/asm/msr-index.h | 25 +
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++-
arch/x86/kernel/cpu/common.c | 52 +-
arch/x86/kvm/vmx.c | 77 +++
arch/x86/kvm/x86.c | 4
drivers/base/cpu.c | 8
include/linux/cpu.h | 4
15 files changed, 664 insertions(+), 41 deletions(-)
Gayatri Kammela (2):
x86/cpu: Add Elkhart Lake to Intel family
x86/cpu: Add another Alder Lake CPU to the Intel family
Greg Kroah-Hartman (1):
Linux 4.19.248
Guenter Roeck (1):
cpu/speculation: Add prototype for cpu_show_srbds()
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
Tony Luck (1):
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Zhang Rui (1):
x86/cpu: Add Jasper Lake to Intel family
I'm announcing the release of the 4.14.284 kernel.
All users of the 4.14 kernel series must upgrade.
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/admin-guide/hw-vuln/index.rst | 1
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/intel-family.h | 25 +
arch/x86/include/asm/msr-index.h | 25 +
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++-
arch/x86/kernel/cpu/common.c | 52 +-
arch/x86/kvm/vmx.c | 77 +++
arch/x86/kvm/x86.c | 4
drivers/base/cpu.c | 8
include/linux/cpu.h | 4
15 files changed, 678 insertions(+), 41 deletions(-)
Gayatri Kammela (2):
x86/cpu: Add Elkhart Lake to Intel family
x86/cpu: Add another Alder Lake CPU to the Intel family
Greg Kroah-Hartman (1):
Linux 4.14.284
Guenter Roeck (1):
cpu/speculation: Add prototype for cpu_show_srbds()
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Kan Liang (2):
x86/CPU: Add more Icelake model numbers
x86/cpu: Add Comet Lake to the Intel CPU models header
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
Rajneesh Bhardwaj (2):
x86/cpu: Add Cannonlake to Intel family
x86/CPU: Add Icelake model number
Tony Luck (1):
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Zhang Rui (1):
x86/cpu: Add Jasper Lake to Intel family
I'm announcing the release of the 4.9.319 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/hw-vuln/index.rst | 1
Documentation/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++++++++++++
Documentation/kernel-parameters.txt | 36 ++
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/intel-family.h | 25 ++
arch/x86/include/asm/msr-index.h | 25 ++
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 +++-
arch/x86/kvm/vmx.c | 77 ++++++
arch/x86/kvm/x86.c | 4
drivers/base/cpu.c | 8
include/linux/cpu.h | 4
15 files changed, 678 insertions(+), 41 deletions(-)
Gayatri Kammela (2):
x86/cpu: Add Elkhart Lake to Intel family
x86/cpu: Add another Alder Lake CPU to the Intel family
Greg Kroah-Hartman (1):
Linux 4.9.319
Guenter Roeck (1):
cpu/speculation: Add prototype for cpu_show_srbds()
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Kan Liang (2):
x86/CPU: Add more Icelake model numbers
x86/cpu: Add Comet Lake to the Intel CPU models header
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
Rajneesh Bhardwaj (2):
x86/cpu: Add Cannonlake to Intel family
x86/CPU: Add Icelake model number
Tony Luck (1):
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Zhang Rui (1):
x86/cpu: Add Jasper Lake to Intel family
This is the start of the stable review cycle for the 4.19.248 release.
There are 16 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 16 Jun 2022 18:37:02 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.248-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.19.248-rc1
Josh Poimboeuf <jpoimboe(a)kernel.org>
x86/speculation/mmio: Print SMT warning
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
KVM: x86/speculation: Disable Fill buffer clear within guests
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/srbds: Update SRBDS mitigation selection
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation: Add a common function for MD_CLEAR mitigation update
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
Documentation: Add documentation for Processor MMIO Stale Data
Gayatri Kammela <gayatri.kammela(a)intel.com>
x86/cpu: Add another Alder Lake CPU to the Intel family
Tony Luck <tony.luck(a)intel.com>
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Zhang Rui <rui.zhang(a)intel.com>
x86/cpu: Add Jasper Lake to Intel family
Guenter Roeck <linux(a)roeck-us.net>
cpu/speculation: Add prototype for cpu_show_srbds()
Gayatri Kammela <gayatri.kammela(a)intel.com>
x86/cpu: Add Elkhart Lake to Intel family
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +++
Makefile | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/intel-family.h | 11 +
arch/x86/include/asm/msr-index.h | 25 +++
arch/x86/include/asm/nospec-branch.h | 2 +
arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 ++++-
arch/x86/kvm/vmx.c | 77 ++++++-
arch/x86/kvm/x86.c | 4 +
drivers/base/cpu.c | 8 +
include/linux/cpu.h | 4 +
15 files changed, 665 insertions(+), 42 deletions(-)
--
Benötigen Sie ein Geschäftsdarlehen oder ein Darlehen jeglicher Art?
Wenn ja, kontaktieren Sie uns
*Vollständiger Name:
* Benötigte Menge:
*Leihdauer:
*Mobiltelefon:
*Land:
This is the start of the stable review cycle for the 5.15.48 release.
There are 11 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 16 Jun 2022 18:37:02 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.48-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.15.48-rc1
Josh Poimboeuf <jpoimboe(a)kernel.org>
x86/speculation/mmio: Print SMT warning
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
KVM: x86/speculation: Disable Fill buffer clear within guests
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/srbds: Update SRBDS mitigation selection
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation: Add a common function for MD_CLEAR mitigation update
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
Documentation: Add documentation for Processor MMIO Stale Data
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +++
Makefile | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 25 +++
arch/x86/include/asm/nospec-branch.h | 2 +
arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 ++++-
arch/x86/kvm/vmx/vmx.c | 72 ++++++
arch/x86/kvm/vmx/vmx.h | 2 +
arch/x86/kvm/x86.c | 3 +
drivers/base/cpu.c | 8 +
include/linux/cpu.h | 3 +
tools/arch/x86/include/asm/cpufeatures.h | 1 +
tools/arch/x86/include/asm/msr-index.h | 25 +++
17 files changed, 676 insertions(+), 41 deletions(-)
Hi, All
With the 4.14.281 version[1], there were three mmc related changes merged,
but that causes one boot failure with the X15 Android builds, a problem
similar to one reported before here[2].
After being confirmed with Ulf Hansson, and verified with the X15 Android build,
it needs to have the following four commits cherry-picked to the 4.14
branch as well.
4f32b45c9a2c mmc: core: Allow host controllers to require R1B for CMD6
5fc615c1e3eb mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for erase/trim/discard
d091259b8d7a mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for eMMC sleep command
23161bed631a mmc: sdhci-omap: Fix busy detection by enabling
MMC_CAP_NEED_RSP_BUSY
The above four commits are from the 4.19 branch, as they are a little
easier to be cherry-picked
into the 4.14 branch, compared to the commits from the mainline branch.
(I have confirmed that the four commits are all in 4.19, 5.4, 5.10 and
mainline branches already).
Saying that, there will be still one merge conflict reported when
cherry picking the commit of
4f32b45c9a2c, it's easy to resolve though.
To avoid the merge conflict, it could be done like this as well:
1. revert the 327b6689898b commit from 4.14 first, so that the commits in step#2
could be cherry-picked without any problem
327b6689898b mmc: core: Default to generic_cmd6_time as
timeout in __mmc_switch()
2. git cherry-pick the following commits from 4.19 into the 4.14 branch
4f32b45c9a2c mmc: core: Allow host controllers to require R1B for CMD6
5fc615c1e3eb mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for
erase/trim/discard
d091259b8d7a mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for eMMC
sleep command
23161bed631a mmc: sdhci-omap: Fix busy detection by enabling
MMC_CAP_NEED_RSP_BUSY
26c6f614cf02 mmc: mmc: core: Default to generic_cmd6_time as
timeout in __mmc_switch()
The last commit of 26c6f614cf02 is for the revert in step#1.
I am not sure which way is more convenient for the maintenance work
here, so just list both of them here
for your information.
And please let me know if there is anything else I could help on this
cherry pick work here.
[1]: https://lore.kernel.org/lkml/16534624745741@kroah.com/T/
[2]: https://lore.kernel.org/lkml/CA+G9fYuqAQfhzF2BzHr7vMHx68bo8-jT+ob_F3eHQ3=oF…
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-android(a)lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-android
This is the start of the stable review cycle for the 5.4.199 release.
There are 15 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 16 Jun 2022 18:37:02 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.199-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.4.199-rc1
Josh Poimboeuf <jpoimboe(a)kernel.org>
x86/speculation/mmio: Print SMT warning
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
KVM: x86/speculation: Disable Fill buffer clear within guests
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/srbds: Update SRBDS mitigation selection
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation: Add a common function for MD_CLEAR mitigation update
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
Documentation: Add documentation for Processor MMIO Stale Data
Gayatri Kammela <gayatri.kammela(a)intel.com>
x86/cpu: Add another Alder Lake CPU to the Intel family
Tony Luck <tony.luck(a)intel.com>
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Zhang Rui <rui.zhang(a)intel.com>
x86/cpu: Add Jasper Lake to Intel family
Guenter Roeck <linux(a)roeck-us.net>
cpu/speculation: Add prototype for cpu_show_srbds()
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +++
Makefile | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/intel-family.h | 9 +
arch/x86/include/asm/msr-index.h | 25 +++
arch/x86/include/asm/nospec-branch.h | 2 +
arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 ++++-
arch/x86/kvm/vmx/vmx.c | 75 ++++++-
arch/x86/kvm/vmx/vmx.h | 3 +
arch/x86/kvm/x86.c | 4 +
drivers/base/cpu.c | 8 +
include/linux/cpu.h | 4 +
16 files changed, 664 insertions(+), 42 deletions(-)
This is the start of the stable review cycle for the 4.14.284 release.
There are 20 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 16 Jun 2022 18:37:02 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.284-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.14.284-rc1
Josh Poimboeuf <jpoimboe(a)kernel.org>
x86/speculation/mmio: Print SMT warning
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
KVM: x86/speculation: Disable Fill buffer clear within guests
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/srbds: Update SRBDS mitigation selection
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation: Add a common function for MD_CLEAR mitigation update
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
Documentation: Add documentation for Processor MMIO Stale Data
Gayatri Kammela <gayatri.kammela(a)intel.com>
x86/cpu: Add another Alder Lake CPU to the Intel family
Tony Luck <tony.luck(a)intel.com>
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Kan Liang <kan.liang(a)linux.intel.com>
x86/cpu: Add Comet Lake to the Intel CPU models header
Kan Liang <kan.liang(a)linux.intel.com>
x86/CPU: Add more Icelake model numbers
Rajneesh Bhardwaj <rajneesh.bhardwaj(a)linux.intel.com>
x86/CPU: Add Icelake model number
Rajneesh Bhardwaj <rajneesh.bhardwaj(a)intel.com>
x86/cpu: Add Cannonlake to Intel family
Zhang Rui <rui.zhang(a)intel.com>
x86/cpu: Add Jasper Lake to Intel family
Guenter Roeck <linux(a)roeck-us.net>
cpu/speculation: Add prototype for cpu_show_srbds()
Gayatri Kammela <gayatri.kammela(a)intel.com>
x86/cpu: Add Elkhart Lake to Intel family
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +++
Makefile | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/intel-family.h | 25 +++
arch/x86/include/asm/msr-index.h | 25 +++
arch/x86/include/asm/nospec-branch.h | 2 +
arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 ++++-
arch/x86/kvm/vmx.c | 77 ++++++-
arch/x86/kvm/x86.c | 4 +
drivers/base/cpu.c | 8 +
include/linux/cpu.h | 4 +
15 files changed, 679 insertions(+), 42 deletions(-)
Den 2022-06-14 kl. 20:12, skrev Greg Kroah-Hartman:
> On Tue, Jun 14, 2022 at 10:08:27AM -0700, Guenter Roeck wrote:
>> On Tue, Jun 14, 2022 at 08:36:08AM -0700, Guenter Roeck wrote:
>>> On Mon, Jun 13, 2022 at 08:19:49PM +0200, Greg Kroah-Hartman wrote:
>>>> This is the start of the stable review cycle for the 5.15.47 release.
>>>> There are 251 patches in this series, all will be posted as a response
>>>> to this one. If anyone has any issues with these being applied, please
>>>> let me know.
>>>>
>>>> Responses should be made by Wed, 15 Jun 2022 18:18:03 +0000.
>>>> Anything received after that time might be too late.
>>>>
>>>
>>> Build results:
>>> total: 159 pass: 159 fail: 0
>>> Qemu test results:
>>> total: 488 pass: 488 fail: 0
>>>
>>
>> I spoke a bit too early. I see the following backtrace in some qemu arm
>> boot tests.
>>
>> BUG: spinlock bad magic on CPU#0, kdevtmpfs/15
>> lock: noop_backing_dev_info+0x6c/0x3b0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
>> CPU: 0 PID: 15 Comm: kdevtmpfs Not tainted 5.15.47-rc2-00252-g677f0128d0ed #1
>> Hardware name: ARM RealView Machine (Device Tree Support)
>> [<c01101d0>] (unwind_backtrace) from [<c010bc0c>] (show_stack+0x10/0x14)
>> [<c010bc0c>] (show_stack) from [<c0a10ae4>] (dump_stack_lvl+0x68/0x90)
>> [<c0a10ae4>] (dump_stack_lvl) from [<c0191250>] (do_raw_spin_lock+0xbc/0x124)
>> [<c0191250>] (do_raw_spin_lock) from [<c02eb578>] (__mark_inode_dirty+0x1cc/0x704)
>> [<c02eb578>] (__mark_inode_dirty) from [<c02e6a74>] (simple_setattr+0x44/0x5c)
>> [<c02e6a74>] (simple_setattr) from [<c02d7a18>] (notify_change+0x400/0x45c)
>> [<c02d7a18>] (notify_change) from [<c0a19ef8>] (devtmpfsd+0x1f8/0x2b8)
>> [<c0a19ef8>] (devtmpfsd) from [<c014cf3c>] (kthread+0x150/0x17c)
>> [<c014cf3c>] (kthread) from [<c0100120>] (ret_from_fork+0x14/0x34)
>> Exception stack(0xd00dbfb0 to 0xd00dbff8)
>> bfa0: 00000000 00000000 00000000 00000000
>> bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
>>
>> This bisects to commit bc5d960d4e58 ("writeback: Fix inode->i_io_list not
>> be protected by inode->i_lock error"). The problem is also seen in the
>> mainline kernel. v5.15.y.queue and later are affected. Reverting the patch
>> here and in mainline fixes the problem.
>
> Thanks for letting me know. Hopefully it gets fixed in upstream...
>
I "think" this is the suggested fix:
https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git/commit/?h…
--
Thomas
The patch titled
Subject: mm/memory-failure: disable unpoison once hw error happens
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-memory-failure-disable-unpoison-once-hw-error-happens.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: zhenwei pi <pizhenwei(a)bytedance.com>
Subject: mm/memory-failure: disable unpoison once hw error happens
Date: Wed, 15 Jun 2022 17:32:09 +0800
Currently unpoison_memory(unsigned long pfn) is designed for soft
poison(hwpoison-inject) only. Since 17fae1294ad9d, the KPTE gets cleared
on a x86 platform once hardware memory corrupts.
Unpoisoning a hardware corrupted page puts page back buddy only, the
kernel has a chance to access the page with *NOT PRESENT* KPTE. This
leads BUG during accessing on the corrupted KPTE.
Suggested by David&Naoya, disable unpoison mechanism when a real HW error
happens to avoid BUG like this:
Unpoison: Software-unpoisoned page 0x61234
BUG: unable to handle page fault for address: ffff888061234000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 2c01067 P4D 2c01067 PUD 107267063 PMD 10382b063 PTE 800fffff9edcb062
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 4 PID: 26551 Comm: stress Kdump: loaded Tainted: G M OE 5.18.0.bm.1-amd64 #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...
RIP: 0010:clear_page_erms+0x7/0x10
Code: ...
RSP: 0000:ffffc90001107bc8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000901 RCX: 0000000000001000
RDX: ffffea0001848d00 RSI: ffffea0001848d40 RDI: ffff888061234000
RBP: ffffea0001848d00 R08: 0000000000000901 R09: 0000000000001276
R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000001
R13: 0000000000000000 R14: 0000000000140dca R15: 0000000000000001
FS: 00007fd8b2333740(0000) GS:ffff88813fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff888061234000 CR3: 00000001023d2005 CR4: 0000000000770ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
prep_new_page+0x151/0x170
get_page_from_freelist+0xca0/0xe20
? sysvec_apic_timer_interrupt+0xab/0xc0
? asm_sysvec_apic_timer_interrupt+0x1b/0x20
__alloc_pages+0x17e/0x340
__folio_alloc+0x17/0x40
vma_alloc_folio+0x84/0x280
__handle_mm_fault+0x8d4/0xeb0
handle_mm_fault+0xd5/0x2a0
do_user_addr_fault+0x1d0/0x680
? kvm_read_and_reset_apf_flags+0x3b/0x50
exc_page_fault+0x78/0x170
asm_exc_page_fault+0x27/0x30
Link: https://lkml.kernel.org/r/20220615093209.259374-2-pizhenwei@bytedance.com
Fixes: 847ce401df392 ("HWPOISON: Add unpoisoning support")
Fixes: 17fae1294ad9d ("x86/{mce,mm}: Unmap the entire page if the whole page is affected and poisoned")
Signed-off-by: zhenwei pi <pizhenwei(a)bytedance.com>
Acked-by: David Hildenbrand <david(a)redhat.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi(a)nec.com>
Cc: Oscar Salvador <osalvador(a)suse.de>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
Documentation/vm/hwpoison.rst | 3 ++-
drivers/base/memory.c | 2 +-
include/linux/mm.h | 1 +
mm/hwpoison-inject.c | 2 +-
mm/madvise.c | 2 +-
mm/memory-failure.c | 12 ++++++++++++
6 files changed, 18 insertions(+), 4 deletions(-)
--- a/Documentation/vm/hwpoison.rst~mm-memory-failure-disable-unpoison-once-hw-error-happens
+++ a/Documentation/vm/hwpoison.rst
@@ -120,7 +120,8 @@ Testing
unpoison-pfn
Software-unpoison page at PFN echoed into this file. This way
a page can be reused again. This only works for Linux
- injected failures, not for real memory failures.
+ injected failures, not for real memory failures. Once any hardware
+ memory failure happens, this feature is disabled.
Note these injection interfaces are not stable and might change between
kernel versions
--- a/drivers/base/memory.c~mm-memory-failure-disable-unpoison-once-hw-error-happens
+++ a/drivers/base/memory.c
@@ -558,7 +558,7 @@ static ssize_t hard_offline_page_store(s
if (kstrtoull(buf, 0, &pfn) < 0)
return -EINVAL;
pfn >>= PAGE_SHIFT;
- ret = memory_failure(pfn, 0);
+ ret = memory_failure(pfn, MF_SW_SIMULATED);
if (ret == -EOPNOTSUPP)
ret = 0;
return ret ? ret : count;
--- a/include/linux/mm.h~mm-memory-failure-disable-unpoison-once-hw-error-happens
+++ a/include/linux/mm.h
@@ -3232,6 +3232,7 @@ enum mf_flags {
MF_MUST_KILL = 1 << 2,
MF_SOFT_OFFLINE = 1 << 3,
MF_UNPOISON = 1 << 4,
+ MF_SW_SIMULATED = 1 << 5,
};
extern int memory_failure(unsigned long pfn, int flags);
extern void memory_failure_queue(unsigned long pfn, int flags);
--- a/mm/hwpoison-inject.c~mm-memory-failure-disable-unpoison-once-hw-error-happens
+++ a/mm/hwpoison-inject.c
@@ -48,7 +48,7 @@ static int hwpoison_inject(void *data, u
inject:
pr_info("Injecting memory failure at pfn %#lx\n", pfn);
- err = memory_failure(pfn, 0);
+ err = memory_failure(pfn, MF_SW_SIMULATED);
return (err == -EOPNOTSUPP) ? 0 : err;
}
--- a/mm/madvise.c~mm-memory-failure-disable-unpoison-once-hw-error-happens
+++ a/mm/madvise.c
@@ -1112,7 +1112,7 @@ static int madvise_inject_error(int beha
} else {
pr_info("Injecting memory failure for pfn %#lx at process virtual address %#lx\n",
pfn, start);
- ret = memory_failure(pfn, MF_COUNT_INCREASED);
+ ret = memory_failure(pfn, MF_COUNT_INCREASED | MF_SW_SIMULATED);
if (ret == -EOPNOTSUPP)
ret = 0;
}
--- a/mm/memory-failure.c~mm-memory-failure-disable-unpoison-once-hw-error-happens
+++ a/mm/memory-failure.c
@@ -69,6 +69,8 @@ int sysctl_memory_failure_recovery __rea
atomic_long_t num_poisoned_pages __read_mostly = ATOMIC_LONG_INIT(0);
+static bool hw_memory_failure __read_mostly = false;
+
static bool __page_handle_poison(struct page *page)
{
int ret;
@@ -1768,6 +1770,9 @@ int memory_failure(unsigned long pfn, in
mutex_lock(&mf_mutex);
+ if (!(flags & MF_SW_SIMULATED))
+ hw_memory_failure = true;
+
p = pfn_to_online_page(pfn);
if (!p) {
res = arch_memory_failure(pfn, flags);
@@ -2103,6 +2108,13 @@ int unpoison_memory(unsigned long pfn)
mutex_lock(&mf_mutex);
+ if (hw_memory_failure) {
+ unpoison_pr_info("Unpoison: Disabled after HW memory failure %#lx\n",
+ pfn, &unpoison_rs);
+ ret = -EOPNOTSUPP;
+ goto unlock_mutex;
+ }
+
if (!PageHWPoison(p)) {
unpoison_pr_info("Unpoison: Page was already unpoisoned %#lx\n",
pfn, &unpoison_rs);
_
Patches currently in -mm which might be from pizhenwei(a)bytedance.com are
mm-memory-failure-disable-unpoison-once-hw-error-happens.patch
From: Paolo Bonzini <pbonzini(a)redhat.com>
[ Upstream commit 6cd88243c7e03845a450795e134b488fc2afb736 ]
If a vCPU is outside guest mode and is scheduled out, it might be in the
process of making a memory access. A problem occurs if another vCPU uses
the PV TLB flush feature during the period when the vCPU is scheduled
out, and a virtual address has already been translated but has not yet
been accessed, because this is equivalent to using a stale TLB entry.
To avoid this, only report a vCPU as preempted if sure that the guest
is at an instruction boundary. A rescheduling request will be delivered
to the host physical CPU as an external interrupt, so for simplicity
consider any vmexit *not* instruction boundary except for external
interrupts.
It would in principle be okay to report the vCPU as preempted also
if it is sleeping in kvm_vcpu_block(): a TLB flush IPI will incur the
vmentry/vmexit overhead unnecessarily, and optimistic spinning is
also unlikely to succeed. However, leave it for later because right
now kvm_vcpu_check_block() is doing memory accesses. Even
though the TLB flush issue only applies to virtual memory address,
it's very much preferrable to be conservative.
Reported-by: Jann Horn <jannh(a)google.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/x86/include/asm/kvm_host.h | 3 +++
arch/x86/kvm/svm/svm.c | 2 ++
arch/x86/kvm/vmx/vmx.c | 1 +
arch/x86/kvm/x86.c | 22 ++++++++++++++++++++++
4 files changed, 28 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 49d814b2a341..a35f5e23fc2a 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -642,6 +642,7 @@ struct kvm_vcpu_arch {
u64 ia32_misc_enable_msr;
u64 smbase;
u64 smi_count;
+ bool at_instruction_boundary;
bool tpr_access_reporting;
bool xsaves_enabled;
u64 ia32_xss;
@@ -1271,6 +1272,8 @@ struct kvm_vcpu_stat {
u64 nested_run;
u64 directed_yield_attempted;
u64 directed_yield_successful;
+ u64 preemption_reported;
+ u64 preemption_other;
u64 guest_mode;
};
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 26f2da1590ed..5b51156712f7 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -4263,6 +4263,8 @@ static int svm_check_intercept(struct kvm_vcpu *vcpu,
static void svm_handle_exit_irqoff(struct kvm_vcpu *vcpu)
{
+ if (to_svm(vcpu)->vmcb->control.exit_code == SVM_EXIT_INTR)
+ vcpu->arch.at_instruction_boundary = true;
}
static void svm_sched_in(struct kvm_vcpu *vcpu, int cpu)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 16a660a0ed5f..08f9f05a6cb2 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6390,6 +6390,7 @@ static void handle_external_interrupt_irqoff(struct kvm_vcpu *vcpu)
return;
handle_interrupt_nmi_irqoff(vcpu, gate_offset(desc));
+ vcpu->arch.at_instruction_boundary = true;
}
static void vmx_handle_exit_irqoff(struct kvm_vcpu *vcpu)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 23905ba3058a..fbf10fa99507 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -277,6 +277,8 @@ const struct _kvm_stats_desc kvm_vcpu_stats_desc[] = {
STATS_DESC_COUNTER(VCPU, nested_run),
STATS_DESC_COUNTER(VCPU, directed_yield_attempted),
STATS_DESC_COUNTER(VCPU, directed_yield_successful),
+ STATS_DESC_COUNTER(VCPU, preemption_reported),
+ STATS_DESC_COUNTER(VCPU, preemption_other),
STATS_DESC_ICOUNTER(VCPU, guest_mode)
};
@@ -4368,6 +4370,19 @@ static void kvm_steal_time_set_preempted(struct kvm_vcpu *vcpu)
struct kvm_memslots *slots;
static const u8 preempted = KVM_VCPU_PREEMPTED;
+ /*
+ * The vCPU can be marked preempted if and only if the VM-Exit was on
+ * an instruction boundary and will not trigger guest emulation of any
+ * kind (see vcpu_run). Vendor specific code controls (conservatively)
+ * when this is true, for example allowing the vCPU to be marked
+ * preempted if and only if the VM-Exit was due to a host interrupt.
+ */
+ if (!vcpu->arch.at_instruction_boundary) {
+ vcpu->stat.preemption_other++;
+ return;
+ }
+
+ vcpu->stat.preemption_reported++;
if (!(vcpu->arch.st.msr_val & KVM_MSR_ENABLED))
return;
@@ -9936,6 +9951,13 @@ static int vcpu_run(struct kvm_vcpu *vcpu)
vcpu->arch.l1tf_flush_l1d = true;
for (;;) {
+ /*
+ * If another guest vCPU requests a PV TLB flush in the middle
+ * of instruction emulation, the rest of the emulation could
+ * use a stale page translation. Assume that any code after
+ * this point can start executing an instruction.
+ */
+ vcpu->arch.at_instruction_boundary = false;
if (kvm_vcpu_running(vcpu)) {
r = vcpu_enter_guest(vcpu);
} else {
--
2.35.1
test_bit(), as any other bitmap op, takes `unsigned long *` as a
second argument (pointer to the actual bitmap), as any bitmap
itself is an array of unsigned longs. However, the ia64_get_irr()
code passes a ref to `u64` as a second argument.
This works with the ia64 bitops implementation due to that they
have `void *` as the second argument and then cast it later on.
This works with the bitmap API itself due to that `unsigned long`
has the same size on ia64 as `u64` (`unsigned long long`), but
from the compiler PoV those two are different.
Define @irr as `unsigned long` to fix that. That implies no
functional changes. Has been hidden for 16 years!
Fixes: a58786917ce2 ("[IA64] avoid broken SAL_CACHE_FLUSH implementations")
Cc: stable(a)vger.kernel.org # 2.6.16+
Reported-by: kernel test robot <lkp(a)intel.com>
Signed-off-by: Alexander Lobakin <alexandr.lobakin(a)intel.com>
---
arch/ia64/include/asm/processor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/ia64/include/asm/processor.h b/arch/ia64/include/asm/processor.h
index 7cbce290f4e5..757c2f6d8d4b 100644
--- a/arch/ia64/include/asm/processor.h
+++ b/arch/ia64/include/asm/processor.h
@@ -538,7 +538,7 @@ ia64_get_irr(unsigned int vector)
{
unsigned int reg = vector / 64;
unsigned int bit = vector % 64;
- u64 irr;
+ unsigned long irr;
switch (reg) {
case 0: irr = ia64_getreg(_IA64_REG_CR_IRR0); break;
--
2.36.1
Dear Mr/Mrs,
Let me start by introducing myself. I am Lei Wang, Executive Director and
Chief Financial Officer of Bank of China (Hong Kong).
I will need you to assist me in executing this Business Project from Hong
Kong to your country. Please endeavor to observe utmost discretion in all
matters concerning this issue and If you are interested please get back to
me so I can provide you with more details of this operation.
Kind Regards,
Lei Wang
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From f2e19b36593caed4c977c2f55aeba7408aeb2132 Mon Sep 17 00:00:00 2001
From: Martin Faltesek <mfaltesek(a)google.com>
Date: Mon, 6 Jun 2022 21:57:29 -0500
Subject: [PATCH] nfc: st21nfca: fix incorrect sizing calculations in
EVT_TRANSACTION
The transaction buffer is allocated by using the size of the packet buf,
and subtracting two which seem intended to remove the two tags which are
not present in the target structure. This calculation leads to under
counting memory because of differences between the packet contents and the
target structure. The aid_len field is a u8 in the packet, but a u32 in
the structure, resulting in at least 3 bytes always being under counted.
Further, the aid data is a variable length field in the packet, but fixed
in the structure, so if this field is less than the max, the difference is
added to the under counting.
The last validation check for transaction->params_len is also incorrect
since it employs the same accounting error.
To fix, perform validation checks progressively to safely reach the
next field, to determine the size of both buffers and verify both tags.
Once all validation checks pass, allocate the buffer and copy the data.
This eliminates freeing memory on the error path, as those checks are
moved ahead of memory allocation.
Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
Fixes: 4fbcc1a4cb20 ("nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION")
Cc: stable(a)vger.kernel.org
Signed-off-by: Martin Faltesek <mfaltesek(a)google.com>
Reviewed-by: Guenter Roeck <groeck(a)chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index 8e1113ce139b..df8d27cf2956 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -300,6 +300,8 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
int r = 0;
struct device *dev = &hdev->ndev->dev;
struct nfc_evt_transaction *transaction;
+ u32 aid_len;
+ u8 params_len;
pr_debug("connectivity gate event: %x\n", event);
@@ -308,50 +310,48 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
r = nfc_se_connectivity(hdev->ndev, host);
break;
case ST21NFCA_EVT_TRANSACTION:
- /*
- * According to specification etsi 102 622
+ /* According to specification etsi 102 622
* 11.2.2.4 EVT_TRANSACTION Table 52
* Description Tag Length
* AID 81 5 to 16
* PARAMETERS 82 0 to 255
+ *
+ * The key differences are aid storage length is variably sized
+ * in the packet, but fixed in nfc_evt_transaction, and that the aid_len
+ * is u8 in the packet, but u32 in the structure, and the tags in
+ * the packet are not included in nfc_evt_transaction.
+ *
+ * size in bytes: 1 1 5-16 1 1 0-255
+ * offset: 0 1 2 aid_len + 2 aid_len + 3 aid_len + 4
+ * member name: aid_tag(M) aid_len aid params_tag(M) params_len params
+ * example: 0x81 5-16 X 0x82 0-255 X
*/
- if (skb->len < NFC_MIN_AID_LENGTH + 2 ||
- skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
+ if (skb->len < 2 || skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
return -EPROTO;
- transaction = devm_kzalloc(dev, skb->len - 2, GFP_KERNEL);
- if (!transaction)
- return -ENOMEM;
-
- transaction->aid_len = skb->data[1];
+ aid_len = skb->data[1];
- /* Checking if the length of the AID is valid */
- if (transaction->aid_len > sizeof(transaction->aid)) {
- devm_kfree(dev, transaction);
- return -EINVAL;
- }
+ if (skb->len < aid_len + 4 || aid_len > sizeof(transaction->aid))
+ return -EPROTO;
- memcpy(transaction->aid, &skb->data[2],
- transaction->aid_len);
+ params_len = skb->data[aid_len + 3];
- /* Check next byte is PARAMETERS tag (82) */
- if (skb->data[transaction->aid_len + 2] !=
- NFC_EVT_TRANSACTION_PARAMS_TAG) {
- devm_kfree(dev, transaction);
+ /* Verify PARAMETERS tag is (82), and final check that there is enough
+ * space in the packet to read everything.
+ */
+ if ((skb->data[aid_len + 2] != NFC_EVT_TRANSACTION_PARAMS_TAG) ||
+ (skb->len < aid_len + 4 + params_len))
return -EPROTO;
- }
- transaction->params_len = skb->data[transaction->aid_len + 3];
+ transaction = devm_kzalloc(dev, sizeof(*transaction) + params_len, GFP_KERNEL);
+ if (!transaction)
+ return -ENOMEM;
- /* Total size is allocated (skb->len - 2) minus fixed array members */
- if (transaction->params_len > ((skb->len - 2) -
- sizeof(struct nfc_evt_transaction))) {
- devm_kfree(dev, transaction);
- return -EINVAL;
- }
+ transaction->aid_len = aid_len;
+ transaction->params_len = params_len;
- memcpy(transaction->params, skb->data +
- transaction->aid_len + 4, transaction->params_len);
+ memcpy(transaction->aid, &skb->data[2], aid_len);
+ memcpy(transaction->params, &skb->data[aid_len + 4], params_len);
r = nfc_se_transaction(hdev->ndev, host, transaction);
break;
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From f2e19b36593caed4c977c2f55aeba7408aeb2132 Mon Sep 17 00:00:00 2001
From: Martin Faltesek <mfaltesek(a)google.com>
Date: Mon, 6 Jun 2022 21:57:29 -0500
Subject: [PATCH] nfc: st21nfca: fix incorrect sizing calculations in
EVT_TRANSACTION
The transaction buffer is allocated by using the size of the packet buf,
and subtracting two which seem intended to remove the two tags which are
not present in the target structure. This calculation leads to under
counting memory because of differences between the packet contents and the
target structure. The aid_len field is a u8 in the packet, but a u32 in
the structure, resulting in at least 3 bytes always being under counted.
Further, the aid data is a variable length field in the packet, but fixed
in the structure, so if this field is less than the max, the difference is
added to the under counting.
The last validation check for transaction->params_len is also incorrect
since it employs the same accounting error.
To fix, perform validation checks progressively to safely reach the
next field, to determine the size of both buffers and verify both tags.
Once all validation checks pass, allocate the buffer and copy the data.
This eliminates freeing memory on the error path, as those checks are
moved ahead of memory allocation.
Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
Fixes: 4fbcc1a4cb20 ("nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION")
Cc: stable(a)vger.kernel.org
Signed-off-by: Martin Faltesek <mfaltesek(a)google.com>
Reviewed-by: Guenter Roeck <groeck(a)chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index 8e1113ce139b..df8d27cf2956 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -300,6 +300,8 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
int r = 0;
struct device *dev = &hdev->ndev->dev;
struct nfc_evt_transaction *transaction;
+ u32 aid_len;
+ u8 params_len;
pr_debug("connectivity gate event: %x\n", event);
@@ -308,50 +310,48 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
r = nfc_se_connectivity(hdev->ndev, host);
break;
case ST21NFCA_EVT_TRANSACTION:
- /*
- * According to specification etsi 102 622
+ /* According to specification etsi 102 622
* 11.2.2.4 EVT_TRANSACTION Table 52
* Description Tag Length
* AID 81 5 to 16
* PARAMETERS 82 0 to 255
+ *
+ * The key differences are aid storage length is variably sized
+ * in the packet, but fixed in nfc_evt_transaction, and that the aid_len
+ * is u8 in the packet, but u32 in the structure, and the tags in
+ * the packet are not included in nfc_evt_transaction.
+ *
+ * size in bytes: 1 1 5-16 1 1 0-255
+ * offset: 0 1 2 aid_len + 2 aid_len + 3 aid_len + 4
+ * member name: aid_tag(M) aid_len aid params_tag(M) params_len params
+ * example: 0x81 5-16 X 0x82 0-255 X
*/
- if (skb->len < NFC_MIN_AID_LENGTH + 2 ||
- skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
+ if (skb->len < 2 || skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
return -EPROTO;
- transaction = devm_kzalloc(dev, skb->len - 2, GFP_KERNEL);
- if (!transaction)
- return -ENOMEM;
-
- transaction->aid_len = skb->data[1];
+ aid_len = skb->data[1];
- /* Checking if the length of the AID is valid */
- if (transaction->aid_len > sizeof(transaction->aid)) {
- devm_kfree(dev, transaction);
- return -EINVAL;
- }
+ if (skb->len < aid_len + 4 || aid_len > sizeof(transaction->aid))
+ return -EPROTO;
- memcpy(transaction->aid, &skb->data[2],
- transaction->aid_len);
+ params_len = skb->data[aid_len + 3];
- /* Check next byte is PARAMETERS tag (82) */
- if (skb->data[transaction->aid_len + 2] !=
- NFC_EVT_TRANSACTION_PARAMS_TAG) {
- devm_kfree(dev, transaction);
+ /* Verify PARAMETERS tag is (82), and final check that there is enough
+ * space in the packet to read everything.
+ */
+ if ((skb->data[aid_len + 2] != NFC_EVT_TRANSACTION_PARAMS_TAG) ||
+ (skb->len < aid_len + 4 + params_len))
return -EPROTO;
- }
- transaction->params_len = skb->data[transaction->aid_len + 3];
+ transaction = devm_kzalloc(dev, sizeof(*transaction) + params_len, GFP_KERNEL);
+ if (!transaction)
+ return -ENOMEM;
- /* Total size is allocated (skb->len - 2) minus fixed array members */
- if (transaction->params_len > ((skb->len - 2) -
- sizeof(struct nfc_evt_transaction))) {
- devm_kfree(dev, transaction);
- return -EINVAL;
- }
+ transaction->aid_len = aid_len;
+ transaction->params_len = params_len;
- memcpy(transaction->params, skb->data +
- transaction->aid_len + 4, transaction->params_len);
+ memcpy(transaction->aid, &skb->data[2], aid_len);
+ memcpy(transaction->params, &skb->data[aid_len + 4], params_len);
r = nfc_se_transaction(hdev->ndev, host, transaction);
break;
How are you doing today? I'm the Chief Executive Officer of the First International Bank of Israel. I have a very lucrative deal to discuss with you.
I will await your response to proceed with the details.
Regards.
Smadar Barber-Tsadik
When ext4_xattr_block_set() decides to remove xattr block the following
race can happen:
CPU1 CPU2
ext4_xattr_block_set() ext4_xattr_release_block()
new_bh = ext4_xattr_block_cache_find()
lock_buffer(bh);
ref = le32_to_cpu(BHDR(bh)->h_refcount);
if (ref == 1) {
...
mb_cache_entry_delete();
unlock_buffer(bh);
ext4_free_blocks();
...
ext4_forget(..., bh, ...);
jbd2_journal_revoke(..., bh);
ext4_journal_get_write_access(..., new_bh, ...)
do_get_write_access()
jbd2_journal_cancel_revoke(..., new_bh);
Later the code in ext4_xattr_block_set() finds out the block got freed
and cancels reusal of the block but the revoke stays canceled and so in
case of block reuse and journal replay the filesystem can get corrupted.
If the race works out slightly differently, we can also hit assertions
in the jbd2 code.
Fix the problem by making sure that once matching mbcache entry is
found, code dropping the last xattr block reference (or trying to modify
xattr block in place) waits until the mbcache entry reference is
dropped. This way code trying to reuse xattr block is protected from
someone trying to drop the last reference to xattr block.
Reported-by: Ritesh Harjani <ritesh.list(a)gmail.com>
CC: stable(a)vger.kernel.org
Fixes: 82939d7999df ("ext4: convert to mbcache2")
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
fs/ext4/xattr.c | 67 +++++++++++++++++++++++++++++++++----------------
1 file changed, 45 insertions(+), 22 deletions(-)
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index aadfae53d055..0c42c0e22cd2 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -439,9 +439,16 @@ static int ext4_xattr_inode_iget(struct inode *parent, unsigned long ea_ino,
/* Remove entry from mbcache when EA inode is getting evicted */
void ext4_evict_ea_inode(struct inode *inode)
{
- if (EA_INODE_CACHE(inode))
- mb_cache_entry_delete(EA_INODE_CACHE(inode),
- ext4_xattr_inode_get_hash(inode), inode->i_ino);
+ struct mb_cache_entry *oe;
+
+ if (!EA_INODE_CACHE(inode))
+ return;
+ /* Wait for entry to get unused so that we can remove it */
+ while ((oe = mb_cache_entry_try_delete(EA_INODE_CACHE(inode),
+ ext4_xattr_inode_get_hash(inode), inode->i_ino))) {
+ mb_cache_entry_wait_unused(oe);
+ mb_cache_entry_put(EA_INODE_CACHE(inode), oe);
+ }
}
static int
@@ -1229,6 +1236,7 @@ ext4_xattr_release_block(handle_t *handle, struct inode *inode,
if (error)
goto out;
+retry_ref:
lock_buffer(bh);
hash = le32_to_cpu(BHDR(bh)->h_hash);
ref = le32_to_cpu(BHDR(bh)->h_refcount);
@@ -1238,9 +1246,18 @@ ext4_xattr_release_block(handle_t *handle, struct inode *inode,
* This must happen under buffer lock for
* ext4_xattr_block_set() to reliably detect freed block
*/
- if (ea_block_cache)
- mb_cache_entry_delete(ea_block_cache, hash,
- bh->b_blocknr);
+ if (ea_block_cache) {
+ struct mb_cache_entry *oe;
+
+ oe = mb_cache_entry_try_delete(ea_block_cache, hash,
+ bh->b_blocknr);
+ if (oe) {
+ unlock_buffer(bh);
+ mb_cache_entry_wait_unused(oe);
+ mb_cache_entry_put(ea_block_cache, oe);
+ goto retry_ref;
+ }
+ }
get_bh(bh);
unlock_buffer(bh);
@@ -1867,9 +1884,20 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
* ext4_xattr_block_set() to reliably detect modified
* block
*/
- if (ea_block_cache)
- mb_cache_entry_delete(ea_block_cache, hash,
- bs->bh->b_blocknr);
+ if (ea_block_cache) {
+ struct mb_cache_entry *oe;
+
+ oe = mb_cache_entry_try_delete(ea_block_cache,
+ hash, bs->bh->b_blocknr);
+ if (oe) {
+ /*
+ * Xattr block is getting reused. Leave
+ * it alone.
+ */
+ mb_cache_entry_put(ea_block_cache, oe);
+ goto clone_block;
+ }
+ }
ea_bdebug(bs->bh, "modifying in-place");
error = ext4_xattr_set_entry(i, s, handle, inode,
true /* is_block */);
@@ -1885,6 +1913,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
goto cleanup;
goto inserted;
}
+clone_block:
unlock_buffer(bs->bh);
ea_bdebug(bs->bh, "cloning");
s->base = kmalloc(bs->bh->b_size, GFP_NOFS);
@@ -1991,18 +2020,13 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
lock_buffer(new_bh);
/*
* We have to be careful about races with
- * freeing, rehashing or adding references to
- * xattr block. Once we hold buffer lock xattr
- * block's state is stable so we can check
- * whether the block got freed / rehashed or
- * not. Since we unhash mbcache entry under
- * buffer lock when freeing / rehashing xattr
- * block, checking whether entry is still
- * hashed is reliable. Same rules hold for
- * e_reusable handling.
+ * adding references to xattr block. Once we
+ * hold buffer lock xattr block's state is
+ * stable so we can check the additional
+ * reference fits.
*/
- if (hlist_bl_unhashed(&ce->e_hash_list) ||
- !ce->e_reusable) {
+ ref = le32_to_cpu(BHDR(new_bh)->h_refcount) + 1;
+ if (ref > EXT4_XATTR_REFCOUNT_MAX) {
/*
* Undo everything and check mbcache
* again.
@@ -2017,9 +2041,8 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
new_bh = NULL;
goto inserted;
}
- ref = le32_to_cpu(BHDR(new_bh)->h_refcount) + 1;
BHDR(new_bh)->h_refcount = cpu_to_le32(ref);
- if (ref >= EXT4_XATTR_REFCOUNT_MAX)
+ if (ref == EXT4_XATTR_REFCOUNT_MAX)
ce->e_reusable = 0;
ea_bdebug(new_bh, "reusing; refcount now=%d",
ref);
--
2.35.3
commit <88467db6e2f46a2e79b1b67ce6873c284e4cf417> upstream
Backport from upstream to match function amdgpu_vm_bo_update_mapping
change.
Migration range from system memory to VRAM, if system page can not be
locked or unmapped, we do partial migration and leave some pages in
system memory. Several bugs found to copy pages and update GPU mapping
for this situation:
1. copy to vram should use migrate->npage which is total pages of range
as npages, not migrate->cpages which is number of pages can be migrated.
2. After partial copy, set VRAM res cursor as j + 1, j is number of
system pages copied plus 1 page to skip copy.
3. copy to ram, should collect all continuous VRAM pages and copy
together.
4. Call amdgpu_vm_update_range, should pass in offset as bytes, not
as number of pages.
Signed-off-by: Philip Yang <Philip.Yang(a)amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling(a)amd.com>
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 6 +++---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index ed5385137f48..9d5324b6298c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -299,7 +299,7 @@ svm_migrate_copy_to_vram(struct amdgpu_device *adev, struct svm_range *prange,
struct migrate_vma *migrate, struct dma_fence **mfence,
dma_addr_t *scratch)
{
- uint64_t npages = migrate->cpages;
+ uint64_t npages = migrate->npages;
struct device *dev = adev->dev;
struct amdgpu_res_cursor cursor;
dma_addr_t *src;
@@ -346,7 +346,7 @@ svm_migrate_copy_to_vram(struct amdgpu_device *adev, struct svm_range *prange,
mfence);
if (r)
goto out_free_vram_pages;
- amdgpu_res_next(&cursor, j << PAGE_SHIFT);
+ amdgpu_res_next(&cursor, (j + 1) << PAGE_SHIFT);
j = 0;
} else {
amdgpu_res_next(&cursor, PAGE_SIZE);
@@ -593,7 +593,7 @@ svm_migrate_copy_to_ram(struct amdgpu_device *adev, struct svm_range *prange,
continue;
}
src[i] = svm_migrate_addr(adev, spage);
- if (i > 0 && src[i] != src[i - 1] + PAGE_SIZE) {
+ if (j > 0 && src[i] != src[i - 1] + PAGE_SIZE) {
r = svm_migrate_copy_memory_gart(adev, dst + i - j,
src + i - j, j,
FROM_VRAM_TO_RAM,
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index f2805ba74c80..6d108dbbabdc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -1275,7 +1275,7 @@ svm_range_map_to_gpu(struct amdgpu_device *adev, struct amdgpu_vm *vm,
r = amdgpu_vm_bo_update_mapping(adev, bo_adev, vm, false, false,
NULL, last_start,
prange->start + i, pte_flags,
- last_start - prange->start,
+ (last_start - prange->start) << PAGE_SHIFT,
NULL, dma_addr,
&vm->last_update,
&table_freed);
--
2.35.1
From: He Ying <heying24(a)huawei.com>
[ Upstream commit a1b29ba2f2c171b9bea73be993bfdf0a62d37d15 ]
The following KASAN warning was reported in our kernel.
BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
Read of size 4 at addr d216f958 by task ps/14437
CPU: 3 PID: 14437 Comm: ps Tainted: G O 5.10.0 #1
Call Trace:
[daa63858] [c0654348] dump_stack+0x9c/0xe4 (unreliable)
[daa63888] [c035cf0c] print_address_description.constprop.3+0x8c/0x570
[daa63908] [c035d6bc] kasan_report+0x1ac/0x218
[daa63948] [c00496e8] get_wchan+0x188/0x250
[daa63978] [c0461ec8] do_task_stat+0xce8/0xe60
[daa63b98] [c0455ac8] proc_single_show+0x98/0x170
[daa63bc8] [c03cab8c] seq_read_iter+0x1ec/0x900
[daa63c38] [c03cb47c] seq_read+0x1dc/0x290
[daa63d68] [c037fc94] vfs_read+0x164/0x510
[daa63ea8] [c03808e4] ksys_read+0x144/0x1d0
[daa63f38] [c005b1dc] ret_from_syscall+0x0/0x38
--- interrupt: c00 at 0x8fa8f4
LR = 0x8fa8cc
The buggy address belongs to the page:
page:98ebcdd2 refcount:0 mapcount:0 mapping:00000000 index:0x2 pfn:0x1216f
flags: 0x0()
raw: 00000000 00000000 01010122 00000000 00000002 00000000 ffffffff 00000000
raw: 00000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
d216f800: 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
d216f880: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>d216f900: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
^
d216f980: f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
d216fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
After looking into this issue, I find the buggy address belongs
to the task stack region. It seems KASAN has something wrong.
I look into the code of __get_wchan in x86 architecture and
find the same issue has been resolved by the commit
f7d27c35ddff ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to powerpc architecture too.
As Andrey Ryabinin said, get_wchan() is racy by design, it may
access volatile stack of running task, thus it may access
redzone in a stack frame and cause KASAN to warn about this.
Use READ_ONCE_NOCHECK() to silence these warnings.
Reported-by: Wanming Hu <huwanming(a)huaweil.com>
Signed-off-by: He Ying <heying24(a)huawei.com>
Signed-off-by: Chen Jingwen <chenjingwen6(a)huawei.com>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Link: https://lore.kernel.org/r/20220121014418.155675-1-heying24@huawei.com
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/powerpc/kernel/process.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 984813a4d5dc..a75d20f23dac 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2160,12 +2160,12 @@ static unsigned long ___get_wchan(struct task_struct *p)
return 0;
do {
- sp = *(unsigned long *)sp;
+ sp = READ_ONCE_NOCHECK(*(unsigned long *)sp);
if (!validate_sp(sp, p, STACK_FRAME_OVERHEAD) ||
task_is_running(p))
return 0;
if (count > 0) {
- ip = ((unsigned long *)sp)[STACK_FRAME_LR_SAVE];
+ ip = READ_ONCE_NOCHECK(((unsigned long *)sp)[STACK_FRAME_LR_SAVE]);
if (!in_sched_functions(ip))
return ip;
}
--
2.35.1
--
--
CONGRATULATION
This is to inform you that your name was among the 18 listed
beneficiaries to benefit from this second batch of overdue Scam
victims compensation payment for the year 2022.
The payment was approved after the meeting held on May 25 with (G20)
and (UN) on World Economic Forum Annual Meeting 2022 and it was sign
that 18 listed beneficiaries will receive US$1,000,000.00 each as
their overdue scam victim compensation payment and your name and
contact email was included as one of the beneficiary, So contact Mr.
Steven Schnall Of Quontic Bank Of New York to receive your approved
compensation payment.
Person to contact: Mr. Steven Schnall (Quontic Bank CEO)
E-mail: quontiinfo(a)gmail.com
E-mail: quonticbnk22(a)msgden.net
Note instructions have been given to Quontic Bank Of New York to
release your Scam victims compensation Fund US$1,000,000.00 to you VIA
direct transfer or by ATM CARD.
Thanks,
Yours In Service
UN Secretary General
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
[ Upstream commit e8bc2427018826e02add7b0ed0fc625a60390ae5 ]
A KVM device cleanup happens in either of two callbacks:
1) destroy() which is called when the VM is being destroyed;
2) release() which is called when a device fd is closed.
Most KVM devices use 1) but Book3s's interrupt controller KVM devices
(XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during
the machine execution. The error handling in kvm_ioctl_create_device()
assumes destroy() is always defined which leads to NULL dereference as
discovered by Syzkaller.
This adds a checks for destroy!=NULL and adds a missing release().
This is not changing kvm_destroy_devices() as devices with defined
release() should have been removed from the KVM devices list by then.
Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
virt/kvm/kvm_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d251b718bf53..5482f47cb07d 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2995,8 +2995,11 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
kvm_put_kvm(kvm);
mutex_lock(&kvm->lock);
list_del(&dev->vm_node);
+ if (ops->release)
+ ops->release(dev);
mutex_unlock(&kvm->lock);
- ops->destroy(dev);
+ if (ops->destroy)
+ ops->destroy(dev);
return ret;
}
--
2.35.1
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
[ Upstream commit e8bc2427018826e02add7b0ed0fc625a60390ae5 ]
A KVM device cleanup happens in either of two callbacks:
1) destroy() which is called when the VM is being destroyed;
2) release() which is called when a device fd is closed.
Most KVM devices use 1) but Book3s's interrupt controller KVM devices
(XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during
the machine execution. The error handling in kvm_ioctl_create_device()
assumes destroy() is always defined which leads to NULL dereference as
discovered by Syzkaller.
This adds a checks for destroy!=NULL and adds a missing release().
This is not changing kvm_destroy_devices() as devices with defined
release() should have been removed from the KVM devices list by then.
Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
virt/kvm/kvm_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 87d522eefbb4..de6c66521744 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3036,8 +3036,11 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
kvm_put_kvm(kvm);
mutex_lock(&kvm->lock);
list_del(&dev->vm_node);
+ if (ops->release)
+ ops->release(dev);
mutex_unlock(&kvm->lock);
- ops->destroy(dev);
+ if (ops->destroy)
+ ops->destroy(dev);
return ret;
}
--
2.35.1
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
[ Upstream commit e8bc2427018826e02add7b0ed0fc625a60390ae5 ]
A KVM device cleanup happens in either of two callbacks:
1) destroy() which is called when the VM is being destroyed;
2) release() which is called when a device fd is closed.
Most KVM devices use 1) but Book3s's interrupt controller KVM devices
(XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during
the machine execution. The error handling in kvm_ioctl_create_device()
assumes destroy() is always defined which leads to NULL dereference as
discovered by Syzkaller.
This adds a checks for destroy!=NULL and adds a missing release().
This is not changing kvm_destroy_devices() as devices with defined
release() should have been removed from the KVM devices list by then.
Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
virt/kvm/kvm_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 3d45ce134227..d3a2eb8ee04e 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3193,8 +3193,11 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
kvm_put_kvm(kvm);
mutex_lock(&kvm->lock);
list_del(&dev->vm_node);
+ if (ops->release)
+ ops->release(dev);
mutex_unlock(&kvm->lock);
- ops->destroy(dev);
+ if (ops->destroy)
+ ops->destroy(dev);
return ret;
}
--
2.35.1
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
[ Upstream commit e8bc2427018826e02add7b0ed0fc625a60390ae5 ]
A KVM device cleanup happens in either of two callbacks:
1) destroy() which is called when the VM is being destroyed;
2) release() which is called when a device fd is closed.
Most KVM devices use 1) but Book3s's interrupt controller KVM devices
(XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during
the machine execution. The error handling in kvm_ioctl_create_device()
assumes destroy() is always defined which leads to NULL dereference as
discovered by Syzkaller.
This adds a checks for destroy!=NULL and adds a missing release().
This is not changing kvm_destroy_devices() as devices with defined
release() should have been removed from the KVM devices list by then.
Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
virt/kvm/kvm_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 287444e52ccf..4b445dddb798 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3329,8 +3329,11 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
kvm_put_kvm(kvm);
mutex_lock(&kvm->lock);
list_del(&dev->vm_node);
+ if (ops->release)
+ ops->release(dev);
mutex_unlock(&kvm->lock);
- ops->destroy(dev);
+ if (ops->destroy)
+ ops->destroy(dev);
return ret;
}
--
2.35.1
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
[ Upstream commit e8bc2427018826e02add7b0ed0fc625a60390ae5 ]
A KVM device cleanup happens in either of two callbacks:
1) destroy() which is called when the VM is being destroyed;
2) release() which is called when a device fd is closed.
Most KVM devices use 1) but Book3s's interrupt controller KVM devices
(XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during
the machine execution. The error handling in kvm_ioctl_create_device()
assumes destroy() is always defined which leads to NULL dereference as
discovered by Syzkaller.
This adds a checks for destroy!=NULL and adds a missing release().
This is not changing kvm_destroy_devices() as devices with defined
release() should have been removed from the KVM devices list by then.
Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
virt/kvm/kvm_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 9cd8ca2d8bc1..c5dbac10c372 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3644,8 +3644,11 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
kvm_put_kvm_no_destroy(kvm);
mutex_lock(&kvm->lock);
list_del(&dev->vm_node);
+ if (ops->release)
+ ops->release(dev);
mutex_unlock(&kvm->lock);
- ops->destroy(dev);
+ if (ops->destroy)
+ ops->destroy(dev);
return ret;
}
--
2.35.1
From: Paolo Bonzini <pbonzini(a)redhat.com>
[ Upstream commit 6cd88243c7e03845a450795e134b488fc2afb736 ]
If a vCPU is outside guest mode and is scheduled out, it might be in the
process of making a memory access. A problem occurs if another vCPU uses
the PV TLB flush feature during the period when the vCPU is scheduled
out, and a virtual address has already been translated but has not yet
been accessed, because this is equivalent to using a stale TLB entry.
To avoid this, only report a vCPU as preempted if sure that the guest
is at an instruction boundary. A rescheduling request will be delivered
to the host physical CPU as an external interrupt, so for simplicity
consider any vmexit *not* instruction boundary except for external
interrupts.
It would in principle be okay to report the vCPU as preempted also
if it is sleeping in kvm_vcpu_block(): a TLB flush IPI will incur the
vmentry/vmexit overhead unnecessarily, and optimistic spinning is
also unlikely to succeed. However, leave it for later because right
now kvm_vcpu_check_block() is doing memory accesses. Even
though the TLB flush issue only applies to virtual memory address,
it's very much preferrable to be conservative.
Reported-by: Jann Horn <jannh(a)google.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/x86/include/asm/kvm_host.h | 3 +++
arch/x86/kvm/svm/svm.c | 2 ++
arch/x86/kvm/vmx/vmx.c | 1 +
arch/x86/kvm/x86.c | 22 ++++++++++++++++++++++
4 files changed, 28 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c4b4c0839dbd..db5d454cdf8f 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -646,6 +646,7 @@ struct kvm_vcpu_arch {
u64 ia32_misc_enable_msr;
u64 smbase;
u64 smi_count;
+ bool at_instruction_boundary;
bool tpr_access_reporting;
bool xsaves_enabled;
bool xfd_no_write_intercept;
@@ -1283,6 +1284,8 @@ struct kvm_vcpu_stat {
u64 nested_run;
u64 directed_yield_attempted;
u64 directed_yield_successful;
+ u64 preemption_reported;
+ u64 preemption_other;
u64 guest_mode;
};
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index fd3a00c892c7..0b8364f8415c 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -4182,6 +4182,8 @@ static int svm_check_intercept(struct kvm_vcpu *vcpu,
static void svm_handle_exit_irqoff(struct kvm_vcpu *vcpu)
{
+ if (to_svm(vcpu)->vmcb->control.exit_code == SVM_EXIT_INTR)
+ vcpu->arch.at_instruction_boundary = true;
}
static void svm_sched_in(struct kvm_vcpu *vcpu, int cpu)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index c87be7c52cc2..39a908e3da5a 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6550,6 +6550,7 @@ static void handle_external_interrupt_irqoff(struct kvm_vcpu *vcpu)
return;
handle_interrupt_nmi_irqoff(vcpu, gate_offset(desc));
+ vcpu->arch.at_instruction_boundary = true;
}
static void vmx_handle_exit_irqoff(struct kvm_vcpu *vcpu)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 5204283da798..8445d1d35c79 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -287,6 +287,8 @@ const struct _kvm_stats_desc kvm_vcpu_stats_desc[] = {
STATS_DESC_COUNTER(VCPU, nested_run),
STATS_DESC_COUNTER(VCPU, directed_yield_attempted),
STATS_DESC_COUNTER(VCPU, directed_yield_successful),
+ STATS_DESC_COUNTER(VCPU, preemption_reported),
+ STATS_DESC_COUNTER(VCPU, preemption_other),
STATS_DESC_ICOUNTER(VCPU, guest_mode)
};
@@ -4573,6 +4575,19 @@ static void kvm_steal_time_set_preempted(struct kvm_vcpu *vcpu)
struct kvm_memslots *slots;
static const u8 preempted = KVM_VCPU_PREEMPTED;
+ /*
+ * The vCPU can be marked preempted if and only if the VM-Exit was on
+ * an instruction boundary and will not trigger guest emulation of any
+ * kind (see vcpu_run). Vendor specific code controls (conservatively)
+ * when this is true, for example allowing the vCPU to be marked
+ * preempted if and only if the VM-Exit was due to a host interrupt.
+ */
+ if (!vcpu->arch.at_instruction_boundary) {
+ vcpu->stat.preemption_other++;
+ return;
+ }
+
+ vcpu->stat.preemption_reported++;
if (!(vcpu->arch.st.msr_val & KVM_MSR_ENABLED))
return;
@@ -10261,6 +10276,13 @@ static int vcpu_run(struct kvm_vcpu *vcpu)
vcpu->arch.l1tf_flush_l1d = true;
for (;;) {
+ /*
+ * If another guest vCPU requests a PV TLB flush in the middle
+ * of instruction emulation, the rest of the emulation could
+ * use a stale page translation. Assume that any code after
+ * this point can start executing an instruction.
+ */
+ vcpu->arch.at_instruction_boundary = false;
if (kvm_vcpu_running(vcpu)) {
r = vcpu_enter_guest(vcpu);
} else {
--
2.35.1
From: He Ying <heying24(a)huawei.com>
[ Upstream commit a1b29ba2f2c171b9bea73be993bfdf0a62d37d15 ]
The following KASAN warning was reported in our kernel.
BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
Read of size 4 at addr d216f958 by task ps/14437
CPU: 3 PID: 14437 Comm: ps Tainted: G O 5.10.0 #1
Call Trace:
[daa63858] [c0654348] dump_stack+0x9c/0xe4 (unreliable)
[daa63888] [c035cf0c] print_address_description.constprop.3+0x8c/0x570
[daa63908] [c035d6bc] kasan_report+0x1ac/0x218
[daa63948] [c00496e8] get_wchan+0x188/0x250
[daa63978] [c0461ec8] do_task_stat+0xce8/0xe60
[daa63b98] [c0455ac8] proc_single_show+0x98/0x170
[daa63bc8] [c03cab8c] seq_read_iter+0x1ec/0x900
[daa63c38] [c03cb47c] seq_read+0x1dc/0x290
[daa63d68] [c037fc94] vfs_read+0x164/0x510
[daa63ea8] [c03808e4] ksys_read+0x144/0x1d0
[daa63f38] [c005b1dc] ret_from_syscall+0x0/0x38
--- interrupt: c00 at 0x8fa8f4
LR = 0x8fa8cc
The buggy address belongs to the page:
page:98ebcdd2 refcount:0 mapcount:0 mapping:00000000 index:0x2 pfn:0x1216f
flags: 0x0()
raw: 00000000 00000000 01010122 00000000 00000002 00000000 ffffffff 00000000
raw: 00000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
d216f800: 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
d216f880: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>d216f900: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
^
d216f980: f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
d216fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
After looking into this issue, I find the buggy address belongs
to the task stack region. It seems KASAN has something wrong.
I look into the code of __get_wchan in x86 architecture and
find the same issue has been resolved by the commit
f7d27c35ddff ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to powerpc architecture too.
As Andrey Ryabinin said, get_wchan() is racy by design, it may
access volatile stack of running task, thus it may access
redzone in a stack frame and cause KASAN to warn about this.
Use READ_ONCE_NOCHECK() to silence these warnings.
Reported-by: Wanming Hu <huwanming(a)huaweil.com>
Signed-off-by: He Ying <heying24(a)huawei.com>
Signed-off-by: Chen Jingwen <chenjingwen6(a)huawei.com>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Link: https://lore.kernel.org/r/20220121014418.155675-1-heying24@huawei.com
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/powerpc/kernel/process.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 02b69a68139c..56c33285b1df 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2017,12 +2017,12 @@ unsigned long get_wchan(struct task_struct *p)
return 0;
do {
- sp = *(unsigned long *)sp;
+ sp = READ_ONCE_NOCHECK(*(unsigned long *)sp);
if (!validate_sp(sp, p, STACK_FRAME_OVERHEAD) ||
p->state == TASK_RUNNING)
return 0;
if (count > 0) {
- ip = ((unsigned long *)sp)[STACK_FRAME_LR_SAVE];
+ ip = READ_ONCE_NOCHECK(((unsigned long *)sp)[STACK_FRAME_LR_SAVE]);
if (!in_sched_functions(ip))
return ip;
}
--
2.35.1
From: He Ying <heying24(a)huawei.com>
[ Upstream commit a1b29ba2f2c171b9bea73be993bfdf0a62d37d15 ]
The following KASAN warning was reported in our kernel.
BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
Read of size 4 at addr d216f958 by task ps/14437
CPU: 3 PID: 14437 Comm: ps Tainted: G O 5.10.0 #1
Call Trace:
[daa63858] [c0654348] dump_stack+0x9c/0xe4 (unreliable)
[daa63888] [c035cf0c] print_address_description.constprop.3+0x8c/0x570
[daa63908] [c035d6bc] kasan_report+0x1ac/0x218
[daa63948] [c00496e8] get_wchan+0x188/0x250
[daa63978] [c0461ec8] do_task_stat+0xce8/0xe60
[daa63b98] [c0455ac8] proc_single_show+0x98/0x170
[daa63bc8] [c03cab8c] seq_read_iter+0x1ec/0x900
[daa63c38] [c03cb47c] seq_read+0x1dc/0x290
[daa63d68] [c037fc94] vfs_read+0x164/0x510
[daa63ea8] [c03808e4] ksys_read+0x144/0x1d0
[daa63f38] [c005b1dc] ret_from_syscall+0x0/0x38
--- interrupt: c00 at 0x8fa8f4
LR = 0x8fa8cc
The buggy address belongs to the page:
page:98ebcdd2 refcount:0 mapcount:0 mapping:00000000 index:0x2 pfn:0x1216f
flags: 0x0()
raw: 00000000 00000000 01010122 00000000 00000002 00000000 ffffffff 00000000
raw: 00000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
d216f800: 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
d216f880: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>d216f900: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
^
d216f980: f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
d216fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
After looking into this issue, I find the buggy address belongs
to the task stack region. It seems KASAN has something wrong.
I look into the code of __get_wchan in x86 architecture and
find the same issue has been resolved by the commit
f7d27c35ddff ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to powerpc architecture too.
As Andrey Ryabinin said, get_wchan() is racy by design, it may
access volatile stack of running task, thus it may access
redzone in a stack frame and cause KASAN to warn about this.
Use READ_ONCE_NOCHECK() to silence these warnings.
Reported-by: Wanming Hu <huwanming(a)huaweil.com>
Signed-off-by: He Ying <heying24(a)huawei.com>
Signed-off-by: Chen Jingwen <chenjingwen6(a)huawei.com>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Link: https://lore.kernel.org/r/20220121014418.155675-1-heying24@huawei.com
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/powerpc/kernel/process.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index c94bba9142e7..832663f21422 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2001,12 +2001,12 @@ static unsigned long __get_wchan(struct task_struct *p)
return 0;
do {
- sp = *(unsigned long *)sp;
+ sp = READ_ONCE_NOCHECK(*(unsigned long *)sp);
if (!validate_sp(sp, p, STACK_FRAME_OVERHEAD) ||
p->state == TASK_RUNNING)
return 0;
if (count > 0) {
- ip = ((unsigned long *)sp)[STACK_FRAME_LR_SAVE];
+ ip = READ_ONCE_NOCHECK(((unsigned long *)sp)[STACK_FRAME_LR_SAVE]);
if (!in_sched_functions(ip))
return ip;
}
--
2.35.1
From: He Ying <heying24(a)huawei.com>
[ Upstream commit a1b29ba2f2c171b9bea73be993bfdf0a62d37d15 ]
The following KASAN warning was reported in our kernel.
BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
Read of size 4 at addr d216f958 by task ps/14437
CPU: 3 PID: 14437 Comm: ps Tainted: G O 5.10.0 #1
Call Trace:
[daa63858] [c0654348] dump_stack+0x9c/0xe4 (unreliable)
[daa63888] [c035cf0c] print_address_description.constprop.3+0x8c/0x570
[daa63908] [c035d6bc] kasan_report+0x1ac/0x218
[daa63948] [c00496e8] get_wchan+0x188/0x250
[daa63978] [c0461ec8] do_task_stat+0xce8/0xe60
[daa63b98] [c0455ac8] proc_single_show+0x98/0x170
[daa63bc8] [c03cab8c] seq_read_iter+0x1ec/0x900
[daa63c38] [c03cb47c] seq_read+0x1dc/0x290
[daa63d68] [c037fc94] vfs_read+0x164/0x510
[daa63ea8] [c03808e4] ksys_read+0x144/0x1d0
[daa63f38] [c005b1dc] ret_from_syscall+0x0/0x38
--- interrupt: c00 at 0x8fa8f4
LR = 0x8fa8cc
The buggy address belongs to the page:
page:98ebcdd2 refcount:0 mapcount:0 mapping:00000000 index:0x2 pfn:0x1216f
flags: 0x0()
raw: 00000000 00000000 01010122 00000000 00000002 00000000 ffffffff 00000000
raw: 00000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
d216f800: 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
d216f880: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>d216f900: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
^
d216f980: f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
d216fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
After looking into this issue, I find the buggy address belongs
to the task stack region. It seems KASAN has something wrong.
I look into the code of __get_wchan in x86 architecture and
find the same issue has been resolved by the commit
f7d27c35ddff ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to powerpc architecture too.
As Andrey Ryabinin said, get_wchan() is racy by design, it may
access volatile stack of running task, thus it may access
redzone in a stack frame and cause KASAN to warn about this.
Use READ_ONCE_NOCHECK() to silence these warnings.
Reported-by: Wanming Hu <huwanming(a)huaweil.com>
Signed-off-by: He Ying <heying24(a)huawei.com>
Signed-off-by: Chen Jingwen <chenjingwen6(a)huawei.com>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Link: https://lore.kernel.org/r/20220121014418.155675-1-heying24@huawei.com
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/powerpc/kernel/process.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 3064694afea1..cfb8fd76afb4 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2108,12 +2108,12 @@ static unsigned long __get_wchan(struct task_struct *p)
return 0;
do {
- sp = *(unsigned long *)sp;
+ sp = READ_ONCE_NOCHECK(*(unsigned long *)sp);
if (!validate_sp(sp, p, STACK_FRAME_OVERHEAD) ||
p->state == TASK_RUNNING)
return 0;
if (count > 0) {
- ip = ((unsigned long *)sp)[STACK_FRAME_LR_SAVE];
+ ip = READ_ONCE_NOCHECK(((unsigned long *)sp)[STACK_FRAME_LR_SAVE]);
if (!in_sched_functions(ip))
return ip;
}
--
2.35.1
From: He Ying <heying24(a)huawei.com>
[ Upstream commit a1b29ba2f2c171b9bea73be993bfdf0a62d37d15 ]
The following KASAN warning was reported in our kernel.
BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
Read of size 4 at addr d216f958 by task ps/14437
CPU: 3 PID: 14437 Comm: ps Tainted: G O 5.10.0 #1
Call Trace:
[daa63858] [c0654348] dump_stack+0x9c/0xe4 (unreliable)
[daa63888] [c035cf0c] print_address_description.constprop.3+0x8c/0x570
[daa63908] [c035d6bc] kasan_report+0x1ac/0x218
[daa63948] [c00496e8] get_wchan+0x188/0x250
[daa63978] [c0461ec8] do_task_stat+0xce8/0xe60
[daa63b98] [c0455ac8] proc_single_show+0x98/0x170
[daa63bc8] [c03cab8c] seq_read_iter+0x1ec/0x900
[daa63c38] [c03cb47c] seq_read+0x1dc/0x290
[daa63d68] [c037fc94] vfs_read+0x164/0x510
[daa63ea8] [c03808e4] ksys_read+0x144/0x1d0
[daa63f38] [c005b1dc] ret_from_syscall+0x0/0x38
--- interrupt: c00 at 0x8fa8f4
LR = 0x8fa8cc
The buggy address belongs to the page:
page:98ebcdd2 refcount:0 mapcount:0 mapping:00000000 index:0x2 pfn:0x1216f
flags: 0x0()
raw: 00000000 00000000 01010122 00000000 00000002 00000000 ffffffff 00000000
raw: 00000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
d216f800: 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
d216f880: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>d216f900: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
^
d216f980: f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
d216fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
After looking into this issue, I find the buggy address belongs
to the task stack region. It seems KASAN has something wrong.
I look into the code of __get_wchan in x86 architecture and
find the same issue has been resolved by the commit
f7d27c35ddff ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to powerpc architecture too.
As Andrey Ryabinin said, get_wchan() is racy by design, it may
access volatile stack of running task, thus it may access
redzone in a stack frame and cause KASAN to warn about this.
Use READ_ONCE_NOCHECK() to silence these warnings.
Reported-by: Wanming Hu <huwanming(a)huaweil.com>
Signed-off-by: He Ying <heying24(a)huawei.com>
Signed-off-by: Chen Jingwen <chenjingwen6(a)huawei.com>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Link: https://lore.kernel.org/r/20220121014418.155675-1-heying24@huawei.com
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/powerpc/kernel/process.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 50436b52c213..39a0a13a3a27 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2124,12 +2124,12 @@ static unsigned long __get_wchan(struct task_struct *p)
return 0;
do {
- sp = *(unsigned long *)sp;
+ sp = READ_ONCE_NOCHECK(*(unsigned long *)sp);
if (!validate_sp(sp, p, STACK_FRAME_OVERHEAD) ||
task_is_running(p))
return 0;
if (count > 0) {
- ip = ((unsigned long *)sp)[STACK_FRAME_LR_SAVE];
+ ip = READ_ONCE_NOCHECK(((unsigned long *)sp)[STACK_FRAME_LR_SAVE]);
if (!in_sched_functions(ip))
return ip;
}
--
2.35.1
From: He Ying <heying24(a)huawei.com>
[ Upstream commit a1b29ba2f2c171b9bea73be993bfdf0a62d37d15 ]
The following KASAN warning was reported in our kernel.
BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
Read of size 4 at addr d216f958 by task ps/14437
CPU: 3 PID: 14437 Comm: ps Tainted: G O 5.10.0 #1
Call Trace:
[daa63858] [c0654348] dump_stack+0x9c/0xe4 (unreliable)
[daa63888] [c035cf0c] print_address_description.constprop.3+0x8c/0x570
[daa63908] [c035d6bc] kasan_report+0x1ac/0x218
[daa63948] [c00496e8] get_wchan+0x188/0x250
[daa63978] [c0461ec8] do_task_stat+0xce8/0xe60
[daa63b98] [c0455ac8] proc_single_show+0x98/0x170
[daa63bc8] [c03cab8c] seq_read_iter+0x1ec/0x900
[daa63c38] [c03cb47c] seq_read+0x1dc/0x290
[daa63d68] [c037fc94] vfs_read+0x164/0x510
[daa63ea8] [c03808e4] ksys_read+0x144/0x1d0
[daa63f38] [c005b1dc] ret_from_syscall+0x0/0x38
--- interrupt: c00 at 0x8fa8f4
LR = 0x8fa8cc
The buggy address belongs to the page:
page:98ebcdd2 refcount:0 mapcount:0 mapping:00000000 index:0x2 pfn:0x1216f
flags: 0x0()
raw: 00000000 00000000 01010122 00000000 00000002 00000000 ffffffff 00000000
raw: 00000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
d216f800: 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
d216f880: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>d216f900: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
^
d216f980: f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
d216fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
After looking into this issue, I find the buggy address belongs
to the task stack region. It seems KASAN has something wrong.
I look into the code of __get_wchan in x86 architecture and
find the same issue has been resolved by the commit
f7d27c35ddff ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to powerpc architecture too.
As Andrey Ryabinin said, get_wchan() is racy by design, it may
access volatile stack of running task, thus it may access
redzone in a stack frame and cause KASAN to warn about this.
Use READ_ONCE_NOCHECK() to silence these warnings.
Reported-by: Wanming Hu <huwanming(a)huaweil.com>
Signed-off-by: He Ying <heying24(a)huawei.com>
Signed-off-by: Chen Jingwen <chenjingwen6(a)huawei.com>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Link: https://lore.kernel.org/r/20220121014418.155675-1-heying24@huawei.com
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/powerpc/kernel/process.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 984813a4d5dc..a75d20f23dac 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2160,12 +2160,12 @@ static unsigned long ___get_wchan(struct task_struct *p)
return 0;
do {
- sp = *(unsigned long *)sp;
+ sp = READ_ONCE_NOCHECK(*(unsigned long *)sp);
if (!validate_sp(sp, p, STACK_FRAME_OVERHEAD) ||
task_is_running(p))
return 0;
if (count > 0) {
- ip = ((unsigned long *)sp)[STACK_FRAME_LR_SAVE];
+ ip = READ_ONCE_NOCHECK(((unsigned long *)sp)[STACK_FRAME_LR_SAVE]);
if (!in_sched_functions(ip))
return ip;
}
--
2.35.1
commit 8e1278444446fc97778a5e5c99bca1ce0bbc5ec9 upstream.
The ptrace PEEKUSR/POKEUSR (aka PEEKUSER/POKEUSER) API allows a process
to read/write registers of another process.
To get/set a register, the API takes an index into an imaginary address
space called the "USER area", where the registers of the process are
laid out in some fashion.
The kernel then maps that index to a particular register in its own data
structures and gets/sets the value.
The API only allows a single machine-word to be read/written at a time.
So 4 bytes on 32-bit kernels and 8 bytes on 64-bit kernels.
The way floating point registers (FPRs) are addressed is somewhat
complicated, because double precision float values are 64-bit even on
32-bit CPUs. That means on 32-bit kernels each FPR occupies two
word-sized locations in the USER area. On 64-bit kernels each FPR
occupies one word-sized location in the USER area.
Internally the kernel stores the FPRs in an array of u64s, or if VSX is
enabled, an array of pairs of u64s where one half of each pair stores
the FPR. Which half of the pair stores the FPR depends on the kernel's
endianness.
To handle the different layouts of the FPRs depending on VSX/no-VSX and
big/little endian, the TS_FPR() macro was introduced.
Unfortunately the TS_FPR() macro does not take into account the fact
that the addressing of each FPR differs between 32-bit and 64-bit
kernels. It just takes the index into the "USER area" passed from
userspace and indexes into the fp_state.fpr array.
On 32-bit there are 64 indexes that address FPRs, but only 32 entries in
the fp_state.fpr array, meaning the user can read/write 256 bytes past
the end of the array. Because the fp_state sits in the middle of the
thread_struct there are various fields than can be overwritten,
including some pointers. As such it may be exploitable.
It has also been observed to cause systems to hang or otherwise
misbehave when using gdbserver, and is probably the root cause of this
report which could not be easily reproduced:
https://lore.kernel.org/linuxppc-dev/dc38afe9-6b78-f3f5-666b-986939e40fc6@k…
Rather than trying to make the TS_FPR() macro even more complicated to
fix the bug, or add more macros, instead add a special-case for 32-bit
kernels. This is more obvious and hopefully avoids a similar bug
happening again in future.
Note that because 32-bit kernels never have VSX enabled the code doesn't
need to consider TS_FPRWIDTH/OFFSET at all.
Fixes: 87fec0514f61 ("powerpc: PTRACE_PEEKUSR/PTRACE_POKEUSER of FPR registers in little endian builds")
Cc: stable(a)vger.kernel.org # v3.13+
Reported-by: Ariel Miculas <ariel.miculas(a)belden.com>
Tested-by: Christophe Leroy <christophe.leroy(a)csgroup.eu>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Link: https://lore.kernel.org/r/20220609133245.573565-1-mpe@ellerman.id.au
---
arch/powerpc/kernel/ptrace.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 4f2829634d79..88947f5fd778 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -2938,8 +2938,13 @@ long arch_ptrace(struct task_struct *child, long request,
flush_fp_to_thread(child);
if (fpidx < (PT_FPSCR - PT_FPR0))
- memcpy(&tmp, &child->thread.TS_FPR(fpidx),
- sizeof(long));
+ if (IS_ENABLED(CONFIG_PPC32)) {
+ // On 32-bit the index we are passed refers to 32-bit words
+ tmp = ((u32 *)child->thread.fp_state.fpr)[fpidx];
+ } else {
+ memcpy(&tmp, &child->thread.TS_FPR(fpidx),
+ sizeof(long));
+ }
else
tmp = child->thread.fp_state.fpscr;
}
@@ -2971,8 +2976,13 @@ long arch_ptrace(struct task_struct *child, long request,
flush_fp_to_thread(child);
if (fpidx < (PT_FPSCR - PT_FPR0))
- memcpy(&child->thread.TS_FPR(fpidx), &data,
- sizeof(long));
+ if (IS_ENABLED(CONFIG_PPC32)) {
+ // On 32-bit the index we are passed refers to 32-bit words
+ ((u32 *)child->thread.fp_state.fpr)[fpidx] = data;
+ } else {
+ memcpy(&child->thread.TS_FPR(fpidx), &data,
+ sizeof(long));
+ }
else
child->thread.fp_state.fpscr = data;
ret = 0;
--
2.35.3
Dearest beloved in the Lord,
I am Ms. Agnes George, a 75 year old British woman. I was born an
orphan and GOD blessed me abundantly with riches but no children nor
husband which makes me an unhappy woman. Now I am affected with cancer
of the lung and breast with a partial stroke which has affected my
speech. I can no longer talk well and half of my body is paralyzed, I
sent this email to you with the help of my private female nurse.
My condition is really deteriorating day by day and it is really
giving me lots to think about. This has prompted my decision to
donate all I have for charity; I have made numerous donations all over
the world. After going through your profile, I decided to make my last
donation of Ten Million Five Hundred Thousand United Kingdom Pounds
(UK£10.500, 000, 00) to you as my investment manager. I want you to
build an Orphanage home with my name ( Agnes George ) in your
country.
If you are willing and able to do this task for the sake of humanity
then send me below information for more details to receive the funds.
1. Name...................................................
2. Phone number...............................
3. Address.............................................
4. Country of Origin and residence
Ms. Agnes George.
hallo Greg
5.18.4-rc1
compiles (not without warnings), boots and runs here on x86_64
(Intel i5-11400, Fedora 36)
Tested-by: Ronald Warsow <rwarsow(a)gmx.de
Thanks
Ronald
From: Phil Elwell <phil(a)raspberrypi.org>
The dmas property is used to hold the dmaengine channel used for audio
output.
Older device trees were missing that property, so if it's not there we
disable the audio output entirely.
However, some overlays have set an empty value to that property, mostly
to workaround the fact that overlays cannot remove a property. Let's add
a test for that case and if it's empty, let's disable it as well.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Phil Elwell <phil(a)raspberrypi.org>
Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 6aadb65eb640..c8571e17afa8 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -2034,12 +2034,12 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi)
struct device *dev = &vc4_hdmi->pdev->dev;
struct platform_device *codec_pdev;
const __be32 *addr;
- int index;
+ int index, len;
int ret;
- if (!of_find_property(dev->of_node, "dmas", NULL)) {
+ if (!of_find_property(dev->of_node, "dmas", &len) || !len) {
dev_warn(dev,
- "'dmas' DT property is missing, no HDMI audio\n");
+ "'dmas' DT property is missing or empty, no HDMI audio\n");
return 0;
}
--
2.36.1
From: Dave Stevenson <dave.stevenson(a)raspberrypi.com>
vc4_drv isn't necessarily under the /soc node in DT as it is a
virtual device, but it is the one that does the allocations.
The DMA addresses are consumed by primarily the HVS or V3D, and
those require VideoCore cache alias address mapping, and so will be
under /soc.
During probe find the a suitable device node for HVS or V3D,
and adopt the DMA configuration of that node.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Dave Stevenson <dave.stevenson(a)raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
---
drivers/gpu/drm/vc4/vc4_drv.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 162bc18e7497..14a7d529144d 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -209,6 +209,15 @@ static void vc4_match_add_drivers(struct device *dev,
}
}
+const struct of_device_id vc4_dma_range_matches[] = {
+ { .compatible = "brcm,bcm2711-hvs" },
+ { .compatible = "brcm,bcm2835-hvs" },
+ { .compatible = "brcm,bcm2835-v3d" },
+ { .compatible = "brcm,cygnus-v3d" },
+ { .compatible = "brcm,vc4-v3d" },
+ {}
+};
+
static int vc4_drm_bind(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -227,6 +236,16 @@ static int vc4_drm_bind(struct device *dev)
vc4_drm_driver.driver_features &= ~DRIVER_RENDER;
of_node_put(node);
+ node = of_find_matching_node_and_match(NULL, vc4_dma_range_matches,
+ NULL);
+ if (node) {
+ ret = of_dma_configure(dev, node, true);
+ of_node_put(node);
+
+ if (ret)
+ return ret;
+ }
+
vc4 = devm_drm_dev_alloc(dev, &vc4_drm_driver, struct vc4_dev, base);
if (IS_ERR(vc4))
return PTR_ERR(vc4);
--
2.36.1
Hi kernel stable team,
I want to report a regression in v4.19.245 / v4.19.246 in case someone else
also hits this: strongswan 4.6 errors out with an assertion:
Jun 13 08:55:02 mis1 pluto[4096]: "C1"[1] 10.2.0.1:10954 #2: ASSERTION FAILED at ipsec_doi.c:2852: case 3 unexpected
(the source line number is not relevant due to extra patches)
-> Our automated distro testsuite had IPSec related VPN test failures.
A fix for the issue is queued for v4.19.247 already:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tre…
'Revert "net: af_key: add check for pfkey_broadcast in function pfkey_process"'
From the commit message of the revert:
**********************************
"One visible effect is that racoon daemon fails to find encryption
algorithms like aes and refuses to start."
**********************************
For the older strongwan 4.6 "pluto" daemon the problem showed itself
at a later stage during phase 2 of an IPSec tunnel setup.
Thanks for the great work on the stable kernel!
Regressions are a rare thing these days.
Best regards,
Thomas Jarosch
When calling setattr_prepare() to determine the validity of the
attributes the ia_{g,u}id fields contain the value that will be written
to inode->i_{g,u}id. This is exactly the same for idmapped and
non-idmapped mounts and allows callers to pass in the values they want
to see written to inode->i_{g,u}id.
When group ownership is changed a caller whose fsuid owns the inode can
change the group of the inode to any group they are a member of. When
searching through the caller's groups we need to use the gid mapped
according to the idmapped mount otherwise we will fail to change
ownership for unprivileged users.
Consider a caller running with fsuid and fsgid 1000 using an idmapped
mount that maps id 65534 to 1000 and 65535 to 1001. Consequently, a file
owned by 65534:65535 in the filesystem will be owned by 1000:1001 in the
idmapped mount.
The caller now requests the gid of the file to be changed to 1000 going
through the idmapped mount. In the vfs we will immediately map the
requested gid to the value that will need to be written to inode->i_gid
and place it in attr->ia_gid. Since this idmapped mount maps 65534 to
1000 we place 65534 in attr->ia_gid.
When we check whether the caller is allowed to change group ownership we
first validate that their fsuid matches the inode's uid. The
inode->i_uid is 65534 which is mapped to uid 1000 in the idmapped mount.
Since the caller's fsuid is 1000 we pass the check.
We now check whether the caller is allowed to change inode->i_gid to the
requested gid by calling in_group_p(). This will compare the passed in
gid to the caller's fsgid and search the caller's additional groups.
Since we're dealing with an idmapped mount we need to pass in the gid
mapped according to the idmapped mount. This is akin to checking whether
a caller is privileged over the future group the inode is owned by. And
that needs to take the idmapped mount into account. Note, all helpers
are nops without idmapped mounts.
New regression test sent to xfstests.
Link: https://github.com/lxc/lxd/issues/10537
Fixes: 2f221d6f7b88 ("attr: handle idmapped mounts")
Cc: Seth Forshee <seth.forshee(a)digitalocean.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Aleksa Sarai <cyphar(a)cyphar.com>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: stable(a)vger.kernel.org # 5.15+
CC: linux-fsdevel(a)vger.kernel.org
Signed-off-by: Christian Brauner (Microsoft) <brauner(a)kernel.org>
---
Hey,
Detected while working on additional tests and also reported by a user
and brain on my part. I plan to work on patches to disentangle the
codepaths here a bit and make them easier to understand going forward.
Passes xfstests including new tests and LTP test suite.
Thanks!
Christian
---
fs/attr.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/fs/attr.c b/fs/attr.c
index 66899b6e9bd8..dbe996b0dedf 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -61,9 +61,15 @@ static bool chgrp_ok(struct user_namespace *mnt_userns,
const struct inode *inode, kgid_t gid)
{
kgid_t kgid = i_gid_into_mnt(mnt_userns, inode);
- if (uid_eq(current_fsuid(), i_uid_into_mnt(mnt_userns, inode)) &&
- (in_group_p(gid) || gid_eq(gid, inode->i_gid)))
- return true;
+ if (uid_eq(current_fsuid(), i_uid_into_mnt(mnt_userns, inode))) {
+ kgid_t mapped_gid;
+
+ if (gid_eq(gid, inode->i_gid))
+ return true;
+ mapped_gid = mapped_kgid_fs(mnt_userns, i_user_ns(inode), gid);
+ if (in_group_p(mapped_gid))
+ return true;
+ }
if (capable_wrt_inode_uidgid(mnt_userns, inode, CAP_CHOWN))
return true;
if (gid_eq(kgid, INVALID_GID) &&
@@ -123,12 +129,20 @@ int setattr_prepare(struct user_namespace *mnt_userns, struct dentry *dentry,
/* Make sure a caller can chmod. */
if (ia_valid & ATTR_MODE) {
+ kgid_t mapped_gid;
+
if (!inode_owner_or_capable(mnt_userns, inode))
return -EPERM;
+
+ if (ia_valid & ATTR_GID)
+ mapped_gid = mapped_kgid_fs(mnt_userns,
+ i_user_ns(inode), attr->ia_gid);
+ else
+ mapped_gid = i_gid_into_mnt(mnt_userns, inode);
+
/* Also check the setgid bit! */
- if (!in_group_p((ia_valid & ATTR_GID) ? attr->ia_gid :
- i_gid_into_mnt(mnt_userns, inode)) &&
- !capable_wrt_inode_uidgid(mnt_userns, inode, CAP_FSETID))
+ if (!in_group_p(mapped_gid) &&
+ !capable_wrt_inode_uidgid(mnt_userns, inode, CAP_FSETID))
attr->ia_mode &= ~S_ISGID;
}
base-commit: f2906aa863381afb0015a9eb7fefad885d4e5a56
--
2.34.1
Commit 787af64d05cd ("mm: page_alloc: validate buddy before check its migratetype.")
added buddy check code. But unfortunately, this fix isn't backported to
linux-5.17.y and the former stable branches. The reason is it added wrong
fixes message:
Fixes: 1dd214b8f21c ("mm: page_alloc: avoid merging non-fallbackable
pageblocks with others")
Actually, this issue is involved by commit:
commit d9dddbf55667 ("mm/page_alloc: prevent merging between isolated and other pageblocks")
For RISC-V arch, the first 2M is reserved for sbi, so the start PFN is 512,
but it got buddy PFN 0 for PFN 0x2000:
0 = 0x2000 ^ (1 << 12)
With the illegal buddy PFN 0, it got an illegal buddy page, which caused
crash in __get_pfnblock_flags_mask().
With the patch, it can avoid the calling of get_pageblock_migratetype() if
it isn't buddy page.
Fixes: d9dddbf55667 ("mm/page_alloc: prevent merging between isolated and other pageblocks")
Cc: stable(a)vger.kernel.org
Reported-by: zjb194813(a)alibaba-inc.com
Reported-by: tianhu.hh(a)alibaba-inc.com
Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
---
mm/page_alloc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b1caa1c6c887..5b423caa68fd 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1129,6 +1129,9 @@ static inline void __free_one_page(struct page *page,
buddy_pfn = __find_buddy_pfn(pfn, order);
buddy = page + (buddy_pfn - pfn);
+
+ if (!page_is_buddy(page, buddy, order))
+ goto done_merging;
buddy_mt = get_pageblock_migratetype(buddy);
if (migratetype != buddy_mt
--
2.17.1
In building 5.15.46 & 5.10.121 with CRYPTO_LIB_CURVE25519=m I get the
following. My workaround is to leave it as CRYPTO_LIB_CURVE25519=n
for now.
CONFIG_OR1K_1200=y
CONFIG_OPENRISC_BUILTIN_DTB="or1ksim"
sed 's/\.ko$/\.o/' modules.order | scripts/mod/modpost -o
modules-only.symvers -i vmlinux.symvers -T - ERROR: modpost:
"__crypto_memneq" [lib/crypto/libcurve25519.ko] undefined! make[1]:
*** [scripts/Makefile.modpost:134: modules-only.symvers] Error 1
make[1]: *** Deleting file 'modules-only.symvers' make: ***
[Makefile:1783: modules] Error 2
The patch below does not apply to the 5.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From a2a513be7139b279f1b5b2cee59c6c4950c34346 Mon Sep 17 00:00:00 2001
From: Damien Le Moal <damien.lemoal(a)opensource.wdc.com>
Date: Thu, 2 Jun 2022 23:16:57 +0900
Subject: [PATCH] zonefs: fix handling of explicit_open option on mount
Ignoring the explicit_open mount option on mount for devices that do not
have a limit on the number of open zones must be done after the mount
options are parsed and set in s_mount_opts. Move the check to ignore
the explicit_open option after the call to zonefs_parse_options() in
zonefs_fill_super().
Fixes: b5c00e975779 ("zonefs: open/close zone on file open/close")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Damien Le Moal <damien.lemoal(a)opensource.wdc.com>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com>
diff --git a/fs/zonefs/super.c b/fs/zonefs/super.c
index bcb21aea990a..ecce84909ca1 100644
--- a/fs/zonefs/super.c
+++ b/fs/zonefs/super.c
@@ -1760,12 +1760,6 @@ static int zonefs_fill_super(struct super_block *sb, void *data, int silent)
atomic_set(&sbi->s_wro_seq_files, 0);
sbi->s_max_wro_seq_files = bdev_max_open_zones(sb->s_bdev);
- if (!sbi->s_max_wro_seq_files &&
- sbi->s_mount_opts & ZONEFS_MNTOPT_EXPLICIT_OPEN) {
- zonefs_info(sb, "No open zones limit. Ignoring explicit_open mount option\n");
- sbi->s_mount_opts &= ~ZONEFS_MNTOPT_EXPLICIT_OPEN;
- }
-
atomic_set(&sbi->s_active_seq_files, 0);
sbi->s_max_active_seq_files = bdev_max_active_zones(sb->s_bdev);
@@ -1790,6 +1784,12 @@ static int zonefs_fill_super(struct super_block *sb, void *data, int silent)
zonefs_info(sb, "Mounting %u zones",
blkdev_nr_zones(sb->s_bdev->bd_disk));
+ if (!sbi->s_max_wro_seq_files &&
+ sbi->s_mount_opts & ZONEFS_MNTOPT_EXPLICIT_OPEN) {
+ zonefs_info(sb, "No open zones limit. Ignoring explicit_open mount option\n");
+ sbi->s_mount_opts &= ~ZONEFS_MNTOPT_EXPLICIT_OPEN;
+ }
+
/* Create root directory inode */
ret = -ENOMEM;
inode = new_inode(sb);
hello,
Ilya reports bad TCP throughput when GSO packets hit an OVS rule that does
tc MTU policing. According to his observations [1], the problem is fixed
by upstream commit 4ddc844eb81d ("net/sched: act_police: more accurate MTU
policing"). Can we queue this commit for inclusion in stable trees?
thanks!
--
davide
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2022-June/394802.html
commit 8e1278444446fc97778a5e5c99bca1ce0bbc5ec9 upstream.
The ptrace PEEKUSR/POKEUSR (aka PEEKUSER/POKEUSER) API allows a process
to read/write registers of another process.
To get/set a register, the API takes an index into an imaginary address
space called the "USER area", where the registers of the process are
laid out in some fashion.
The kernel then maps that index to a particular register in its own data
structures and gets/sets the value.
The API only allows a single machine-word to be read/written at a time.
So 4 bytes on 32-bit kernels and 8 bytes on 64-bit kernels.
The way floating point registers (FPRs) are addressed is somewhat
complicated, because double precision float values are 64-bit even on
32-bit CPUs. That means on 32-bit kernels each FPR occupies two
word-sized locations in the USER area. On 64-bit kernels each FPR
occupies one word-sized location in the USER area.
Internally the kernel stores the FPRs in an array of u64s, or if VSX is
enabled, an array of pairs of u64s where one half of each pair stores
the FPR. Which half of the pair stores the FPR depends on the kernel's
endianness.
To handle the different layouts of the FPRs depending on VSX/no-VSX and
big/little endian, the TS_FPR() macro was introduced.
Unfortunately the TS_FPR() macro does not take into account the fact
that the addressing of each FPR differs between 32-bit and 64-bit
kernels. It just takes the index into the "USER area" passed from
userspace and indexes into the fp_state.fpr array.
On 32-bit there are 64 indexes that address FPRs, but only 32 entries in
the fp_state.fpr array, meaning the user can read/write 256 bytes past
the end of the array. Because the fp_state sits in the middle of the
thread_struct there are various fields than can be overwritten,
including some pointers. As such it may be exploitable.
It has also been observed to cause systems to hang or otherwise
misbehave when using gdbserver, and is probably the root cause of this
report which could not be easily reproduced:
https://lore.kernel.org/linuxppc-dev/dc38afe9-6b78-f3f5-666b-986939e40fc6@k…
Rather than trying to make the TS_FPR() macro even more complicated to
fix the bug, or add more macros, instead add a special-case for 32-bit
kernels. This is more obvious and hopefully avoids a similar bug
happening again in future.
Note that because 32-bit kernels never have VSX enabled the code doesn't
need to consider TS_FPRWIDTH/OFFSET at all.
Fixes: 87fec0514f61 ("powerpc: PTRACE_PEEKUSR/PTRACE_POKEUSER of FPR registers in little endian builds")
Cc: stable(a)vger.kernel.org # v3.13+
Reported-by: Ariel Miculas <ariel.miculas(a)belden.com>
Tested-by: Christophe Leroy <christophe.leroy(a)csgroup.eu>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Link: https://lore.kernel.org/r/20220609133245.573565-1-mpe@ellerman.id.au
---
arch/powerpc/kernel/ptrace.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index bfc5f59d9f1b..ef5875f83692 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -2920,8 +2920,13 @@ long arch_ptrace(struct task_struct *child, long request,
flush_fp_to_thread(child);
if (fpidx < (PT_FPSCR - PT_FPR0))
- memcpy(&tmp, &child->thread.TS_FPR(fpidx),
- sizeof(long));
+ if (IS_ENABLED(CONFIG_PPC32)) {
+ // On 32-bit the index we are passed refers to 32-bit words
+ tmp = ((u32 *)child->thread.fp_state.fpr)[fpidx];
+ } else {
+ memcpy(&tmp, &child->thread.TS_FPR(fpidx),
+ sizeof(long));
+ }
else
tmp = child->thread.fp_state.fpscr;
}
@@ -2953,8 +2958,13 @@ long arch_ptrace(struct task_struct *child, long request,
flush_fp_to_thread(child);
if (fpidx < (PT_FPSCR - PT_FPR0))
- memcpy(&child->thread.TS_FPR(fpidx), &data,
- sizeof(long));
+ if (IS_ENABLED(CONFIG_PPC32)) {
+ // On 32-bit the index we are passed refers to 32-bit words
+ ((u32 *)child->thread.fp_state.fpr)[fpidx] = data;
+ } else {
+ memcpy(&child->thread.TS_FPR(fpidx), &data,
+ sizeof(long));
+ }
else
child->thread.fp_state.fpscr = data;
ret = 0;
--
2.35.3
Hi,
all stable release queues from v4.9.y up to v5.4.y have boot stall
problems. The culprit is the backport of commit d7ea0d9df2a6 ("net:
remove two BUG() from skb_checksum_help()"), specifically the following
code.
diff --git a/net/core/dev.c b/net/core/dev.c
index 47468fc5d0c9..d725ca4d4455 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2518,11 +2518,15 @@ int skb_checksum_help(struct sk_buff *skb)
...
- BUG_ON(offset >= skb_headlen(skb));
+ ret = -EINVAL;
^^^^^^^^^^^^^^
+ if (WARN_ON_ONCE(offset >= skb_headlen(skb)))
+ goto out;
+
While that works fine in the upstream kernel since ret is subsequently
always overwritten, that is not the case in older kernels. In those,
the function now always returns -EINVAL.
Guenter
This is a preparation patch for the S29GL064N buffer writes fix. There
is no functional change.
Link: https://lore.kernel.org/r/b687c259-6413-26c9-d4c9-b3afa69ea124@pengutronix.…
Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value")
Signed-off-by: Tokunori Ikegami <ikegami.t(a)gmail.com>
Cc: stable(a)vger.kernel.org
Acked-by: Vignesh Raghavendra <vigneshr(a)ti.com>
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-2-ikegami.t@gmail.com
---
drivers/mtd/chips/cfi_cmdset_0002.c | 77 ++++++++++++-----------------
1 file changed, 32 insertions(+), 45 deletions(-)
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 3c4819a05bf0..bcc2ce67c996 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -726,50 +726,34 @@ static struct mtd_info *cfi_amdstd_setup(struct mtd_info *mtd)
}
/*
- * Return true if the chip is ready.
+ * Return true if the chip is ready and has the correct value.
*
* Ready is one of: read mode, query mode, erase-suspend-read mode (in any
* non-suspended sector) and is indicated by no toggle bits toggling.
*
+ * Error are indicated by toggling bits or bits held with the wrong value,
+ * or with bits toggling.
+ *
* Note that anything more complicated than checking if no bits are toggling
* (including checking DQ5 for an error status) is tricky to get working
* correctly and is therefore not done (particularly with interleaved chips
* as each chip must be checked independently of the others).
*/
-static int __xipram chip_ready(struct map_info *map, unsigned long addr)
+static int __xipram chip_ready(struct map_info *map, unsigned long addr,
+ map_word *expected)
{
map_word d, t;
+ int ret;
d = map_read(map, addr);
t = map_read(map, addr);
- return map_word_equal(map, d, t);
-}
+ ret = map_word_equal(map, d, t);
-/*
- * Return true if the chip is ready and has the correct value.
- *
- * Ready is one of: read mode, query mode, erase-suspend-read mode (in any
- * non-suspended sector) and it is indicated by no bits toggling.
- *
- * Error are indicated by toggling bits or bits held with the wrong value,
- * or with bits toggling.
- *
- * Note that anything more complicated than checking if no bits are toggling
- * (including checking DQ5 for an error status) is tricky to get working
- * correctly and is therefore not done (particularly with interleaved chips
- * as each chip must be checked independently of the others).
- *
- */
-static int __xipram chip_good(struct map_info *map, unsigned long addr, map_word expected)
-{
- map_word oldd, curd;
-
- oldd = map_read(map, addr);
- curd = map_read(map, addr);
+ if (!ret || !expected)
+ return ret;
- return map_word_equal(map, oldd, curd) &&
- map_word_equal(map, curd, expected);
+ return map_word_equal(map, t, *expected);
}
static int get_chip(struct map_info *map, struct flchip *chip, unsigned long adr, int mode)
@@ -786,7 +770,7 @@ static int get_chip(struct map_info *map, struct flchip *chip, unsigned long adr
case FL_STATUS:
for (;;) {
- if (chip_ready(map, adr))
+ if (chip_ready(map, adr, NULL))
break;
if (time_after(jiffies, timeo)) {
@@ -824,7 +808,7 @@ static int get_chip(struct map_info *map, struct flchip *chip, unsigned long adr
chip->state = FL_ERASE_SUSPENDING;
chip->erase_suspended = 1;
for (;;) {
- if (chip_ready(map, adr))
+ if (chip_ready(map, adr, NULL))
break;
if (time_after(jiffies, timeo)) {
@@ -1357,7 +1341,7 @@ static int do_otp_lock(struct map_info *map, struct flchip *chip, loff_t adr,
/* wait for chip to become ready */
timeo = jiffies + msecs_to_jiffies(2);
for (;;) {
- if (chip_ready(map, adr))
+ if (chip_ready(map, adr, NULL))
break;
if (time_after(jiffies, timeo)) {
@@ -1624,10 +1608,11 @@ static int __xipram do_write_oneword(struct map_info *map, struct flchip *chip,
}
/*
- * We check "time_after" and "!chip_good" before checking
- * "chip_good" to avoid the failure due to scheduling.
+ * We check "time_after" and "!chip_ready" before checking
+ * "chip_ready" to avoid the failure due to scheduling.
*/
- if (time_after(jiffies, timeo) && !chip_good(map, adr, datum)) {
+ if (time_after(jiffies, timeo) &&
+ !chip_ready(map, adr, &datum)) {
xip_enable(map, chip, adr);
printk(KERN_WARNING "MTD %s(): software timeout\n", __func__);
xip_disable(map, chip, adr);
@@ -1635,7 +1620,7 @@ static int __xipram do_write_oneword(struct map_info *map, struct flchip *chip,
break;
}
- if (chip_good(map, adr, datum))
+ if (chip_ready(map, adr, &datum))
break;
/* Latency issues. Drop the lock, wait a while and retry */
@@ -1879,13 +1864,13 @@ static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,
}
/*
- * We check "time_after" and "!chip_good" before checking "chip_good" to avoid
- * the failure due to scheduling.
+ * We check "time_after" and "!chip_ready" before checking
+ * "chip_ready" to avoid the failure due to scheduling.
*/
- if (time_after(jiffies, timeo) && !chip_good(map, adr, datum))
+ if (time_after(jiffies, timeo) && !chip_ready(map, adr, &datum))
break;
- if (chip_good(map, adr, datum)) {
+ if (chip_ready(map, adr, &datum)) {
xip_enable(map, chip, adr);
goto op_done;
}
@@ -2019,7 +2004,7 @@ static int cfi_amdstd_panic_wait(struct map_info *map, struct flchip *chip,
* If the driver thinks the chip is idle, and no toggle bits
* are changing, then the chip is actually idle for sure.
*/
- if (chip->state == FL_READY && chip_ready(map, adr))
+ if (chip->state == FL_READY && chip_ready(map, adr, NULL))
return 0;
/*
@@ -2036,7 +2021,7 @@ static int cfi_amdstd_panic_wait(struct map_info *map, struct flchip *chip,
/* wait for the chip to become ready */
for (i = 0; i < jiffies_to_usecs(timeo); i++) {
- if (chip_ready(map, adr))
+ if (chip_ready(map, adr, NULL))
return 0;
udelay(1);
@@ -2100,13 +2085,13 @@ static int do_panic_write_oneword(struct map_info *map, struct flchip *chip,
map_write(map, datum, adr);
for (i = 0; i < jiffies_to_usecs(uWriteTimeout); i++) {
- if (chip_ready(map, adr))
+ if (chip_ready(map, adr, NULL))
break;
udelay(1);
}
- if (!chip_good(map, adr, datum)) {
+ if (!chip_ready(map, adr, &datum)) {
/* reset on all failures. */
map_write(map, CMD(0xF0), chip->start);
/* FIXME - should have reset delay before continuing */
@@ -2247,6 +2232,7 @@ static int __xipram do_erase_chip(struct map_info *map, struct flchip *chip)
DECLARE_WAITQUEUE(wait, current);
int ret = 0;
int retry_cnt = 0;
+ map_word datum = map_word_ff(map);
adr = cfi->addr_unlock1;
@@ -2301,7 +2287,7 @@ static int __xipram do_erase_chip(struct map_info *map, struct flchip *chip)
chip->erase_suspended = 0;
}
- if (chip_good(map, adr, map_word_ff(map)))
+ if (chip_ready(map, adr, &datum))
break;
if (time_after(jiffies, timeo)) {
@@ -2343,6 +2329,7 @@ static int __xipram do_erase_oneblock(struct map_info *map, struct flchip *chip,
DECLARE_WAITQUEUE(wait, current);
int ret = 0;
int retry_cnt = 0;
+ map_word datum = map_word_ff(map);
adr += chip->start;
@@ -2397,7 +2384,7 @@ static int __xipram do_erase_oneblock(struct map_info *map, struct flchip *chip,
chip->erase_suspended = 0;
}
- if (chip_good(map, adr, map_word_ff(map))) {
+ if (chip_ready(map, adr, &datum)) {
xip_enable(map, chip, adr);
break;
}
@@ -2612,7 +2599,7 @@ static int __maybe_unused do_ppb_xxlock(struct map_info *map,
*/
timeo = jiffies + msecs_to_jiffies(2000); /* 2s max (un)locking */
for (;;) {
- if (chip_ready(map, adr))
+ if (chip_ready(map, adr, NULL))
break;
if (time_after(jiffies, timeo)) {
--
2.34.1
Historically we did distinguish between a flag that surpressed partition
scanning, and a combinations of the minors variable and another flag if
any partitions were supported. This was generally confusing and doesn't
make much sense, but some corner case uses of the loop driver actually
do want to support manually added partitions on a device that does not
actively scan for partitions. To make things worsee the loop driver
also wants to dynamically toggle the scanning for partitions on a live
gendisk, which makes the disk->flags updates non-atomic.
Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables
just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART
in the loop driver.
Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT")
Reported-by: Ming Lei <ming.lei(a)redhat.com>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Reviewed-by: Ming Lei <ming.lei(a)redhat.com>
Link: https://lore.kernel.org/r/20220527055806.1972352-1-hch@lst.de
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
(cherry picked from commit b9684a71fca793213378dd410cd11675d973eaa1)
---
block/genhd.c | 2 ++
drivers/block/loop.c | 8 ++++----
include/linux/genhd.h | 1 +
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index 9d9d702d077873..c284c1cf339672 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -380,6 +380,8 @@ int disk_scan_partitions(struct gendisk *disk, fmode_t mode)
if (disk->flags & (GENHD_FL_NO_PART | GENHD_FL_HIDDEN))
return -EINVAL;
+ if (test_bit(GD_SUPPRESS_PART_SCAN, &disk->state))
+ return -EINVAL;
if (disk->open_partitions)
return -EBUSY;
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index d46a3d5d0c2ec9..3411d3c0a5b0fc 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1067,7 +1067,7 @@ static int loop_configure(struct loop_device *lo, fmode_t mode,
lo->lo_flags |= LO_FLAGS_PARTSCAN;
partscan = lo->lo_flags & LO_FLAGS_PARTSCAN;
if (partscan)
- lo->lo_disk->flags &= ~GENHD_FL_NO_PART;
+ clear_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state);
loop_global_unlock(lo, is_loop);
if (partscan)
@@ -1186,7 +1186,7 @@ static void __loop_clr_fd(struct loop_device *lo, bool release)
*/
lo->lo_flags = 0;
if (!part_shift)
- lo->lo_disk->flags |= GENHD_FL_NO_PART;
+ set_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state);
mutex_lock(&lo->lo_mutex);
lo->lo_state = Lo_unbound;
mutex_unlock(&lo->lo_mutex);
@@ -1296,7 +1296,7 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info)
if (!err && (lo->lo_flags & LO_FLAGS_PARTSCAN) &&
!(prev_lo_flags & LO_FLAGS_PARTSCAN)) {
- lo->lo_disk->flags &= ~GENHD_FL_NO_PART;
+ clear_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state);
partscan = true;
}
out_unlock:
@@ -2028,7 +2028,7 @@ static int loop_add(int i)
* userspace tools. Parameters like this in general should be avoided.
*/
if (!part_shift)
- disk->flags |= GENHD_FL_NO_PART;
+ set_bit(GD_SUPPRESS_PART_SCAN, &disk->state);
atomic_set(&lo->lo_refcnt, 0);
mutex_init(&lo->lo_mutex);
lo->lo_number = i;
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 6906a45bc761a4..2cb105f120282e 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -110,6 +110,7 @@ struct gendisk {
#define GD_READ_ONLY 1
#define GD_DEAD 2
#define GD_NATIVE_CAPACITY 3
+#define GD_SUPPRESS_PART_SCAN 5
struct mutex open_mutex; /* open/close mutex */
unsigned open_partitions; /* number of open partitions */
--
2.30.2
Please apply
Upstream commit ea23994edc4169bd90d7a9b5908c6ccefd82fa40
to kernel versions 4.14, 4.19, 5.4 and above.
Reason:
Commits c84a1372df929033cb1a0441fb57bd3932f39ac9 "md/raid0: avoid RAID0
data corruption due to layout confusion." and
33f2c35a54dfd75ad0e7e86918dcbe4de799a56c "md: add feature flag
MD_FEATURE_RAID0_LAYOUT" added handling of original and alternate
layouts of RAID0 arrays with members of different sizes. However they
introduced a regression: assembly of such RAID0 array fails if the
per-array or default layout is not defined even when the layout is
irrelevant and can be safely ignored. One common case is when the RAID0
array is composed of two members of different sizes because the disk or
partition sizes are slightly different. This patch aims to fix this
regression.
Newer versions of mdadm can set a per-array RAID0 layout but some stable
distributions such as Debian 10 ship an older version of mdadm which
does not handle RAID0 layouts and a kernel series (4.19.y) which now
includes the backported commits. As a result, assembly fails after the
kernel upgrade unless the default layout is defined with a kernel parameter.
Related Debian bug reports :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944676https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954816
Hi Greg,
These three patches from 5.19-rc2 failed to automatically apply. The
following series should work okay.
Note that these are already part of the 4.9, 4.14, 4.19, 5.4 backport I
did for later this week.
Jason
Jason A. Donenfeld (3):
random: avoid checking crng_ready() twice in random_init()
random: mark bootloader randomness code as __init
random: account for arch randomness in bits
drivers/char/random.c | 15 +++++++--------
include/linux/random.h | 2 +-
2 files changed, 8 insertions(+), 9 deletions(-)
--
2.35.1
Hi Greg,
These three patches from 5.19-rc2 failed to automatically apply. The
following series should work okay.
Note that these are already part of the 4.9, 4.14, 4.19, 5.4 backport I
did for later this week.
Jason
Jason A. Donenfeld (3):
random: avoid checking crng_ready() twice in random_init()
random: mark bootloader randomness code as __init
random: account for arch randomness in bits
drivers/char/random.c | 15 +++++++--------
include/linux/random.h | 2 +-
2 files changed, 8 insertions(+), 9 deletions(-)
--
2.35.1