From: Greg Kroah-Hartman Date: Sun, 11 Jul 2021 18:12:35 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v5.4.132~24 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=fd90d2c611c1f583073cf7d85c9b6f89a49259cd;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: block-return-the-correct-bvec-when-checking-for-gaps.patch erofs-fix-error-return-code-in-erofs_read_superblock.patch exfat-handle-wrong-stream-entry-size-in-exfat_readdir.patch fscrypt-don-t-ignore-minor_hash-when-hash-is-0.patch fscrypt-fix-derivation-of-siphash-keys-on-big-endian-cpus.patch io_uring-fix-blocking-inline-submission.patch mailbox-qcom-ipcc-fix-ipcc-mbox-channel-exhaustion.patch media-exynos4-is-remove-a-now-unused-integer.patch mmc-block-disable-cmdq-on-the-ioctl-path.patch mmc-vub3000-fix-control-request-direction.patch scsi-fc-correct-rhba-attributes-length.patch scsi-target-cxgbit-unmap-dma-buffer-before-calling-target_execute_cmd.patch tpm-replace-warn_once-with-dev_err_once-in-tpm_tis_status.patch --- diff --git a/queue-5.10/block-return-the-correct-bvec-when-checking-for-gaps.patch b/queue-5.10/block-return-the-correct-bvec-when-checking-for-gaps.patch new file mode 100644 index 00000000000..45aae8f242f --- /dev/null +++ b/queue-5.10/block-return-the-correct-bvec-when-checking-for-gaps.patch @@ -0,0 +1,81 @@ +From c9c9762d4d44dcb1b2ba90cfb4122dc11ceebf31 Mon Sep 17 00:00:00 2001 +From: Long Li +Date: Mon, 7 Jun 2021 12:34:05 -0700 +Subject: block: return the correct bvec when checking for gaps + +From: Long Li + +commit c9c9762d4d44dcb1b2ba90cfb4122dc11ceebf31 upstream. + +After commit 07173c3ec276 ("block: enable multipage bvecs"), a bvec can +have multiple pages. But bio_will_gap() still assumes one page bvec while +checking for merging. If the pages in the bvec go across the +seg_boundary_mask, this check for merging can potentially succeed if only +the 1st page is tested, and can fail if all the pages are tested. + +Later, when SCSI builds the SG list the same check for merging is done in +__blk_segment_map_sg_merge() with all the pages in the bvec tested. This +time the check may fail if the pages in bvec go across the +seg_boundary_mask (but tested okay in bio_will_gap() earlier, so those +BIOs were merged). If this check fails, we end up with a broken SG list +for drivers assuming the SG list not having offsets in intermediate pages. +This results in incorrect pages written to the disk. + +Fix this by returning the multi-page bvec when testing gaps for merging. + +Cc: Jens Axboe +Cc: Johannes Thumshirn +Cc: Pavel Begunkov +Cc: Ming Lei +Cc: Tejun Heo +Cc: "Matthew Wilcox (Oracle)" +Cc: Jeffle Xu +Cc: linux-kernel@vger.kernel.org +Cc: stable@vger.kernel.org +Fixes: 07173c3ec276 ("block: enable multipage bvecs") +Signed-off-by: Long Li +Reviewed-by: Ming Lei +Reviewed-by: Christoph Hellwig +Link: https://lore.kernel.org/r/1623094445-22332-1-git-send-email-longli@linuxonhyperv.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/bio.h | 12 ++++-------- + 1 file changed, 4 insertions(+), 8 deletions(-) + +--- a/include/linux/bio.h ++++ b/include/linux/bio.h +@@ -38,9 +38,6 @@ + #define bio_offset(bio) bio_iter_offset((bio), (bio)->bi_iter) + #define bio_iovec(bio) bio_iter_iovec((bio), (bio)->bi_iter) + +-#define bio_multiple_segments(bio) \ +- ((bio)->bi_iter.bi_size != bio_iovec(bio).bv_len) +- + #define bvec_iter_sectors(iter) ((iter).bi_size >> 9) + #define bvec_iter_end_sector(iter) ((iter).bi_sector + bvec_iter_sectors((iter))) + +@@ -252,7 +249,7 @@ static inline void bio_clear_flag(struct + + static inline void bio_get_first_bvec(struct bio *bio, struct bio_vec *bv) + { +- *bv = bio_iovec(bio); ++ *bv = mp_bvec_iter_bvec(bio->bi_io_vec, bio->bi_iter); + } + + static inline void bio_get_last_bvec(struct bio *bio, struct bio_vec *bv) +@@ -260,10 +257,9 @@ static inline void bio_get_last_bvec(str + struct bvec_iter iter = bio->bi_iter; + int idx; + +- if (unlikely(!bio_multiple_segments(bio))) { +- *bv = bio_iovec(bio); +- return; +- } ++ bio_get_first_bvec(bio, bv); ++ if (bv->bv_len == bio->bi_iter.bi_size) ++ return; /* this bio only has a single bvec */ + + bio_advance_iter(bio, &iter, iter.bi_size); + diff --git a/queue-5.10/erofs-fix-error-return-code-in-erofs_read_superblock.patch b/queue-5.10/erofs-fix-error-return-code-in-erofs_read_superblock.patch new file mode 100644 index 00000000000..5f734cff490 --- /dev/null +++ b/queue-5.10/erofs-fix-error-return-code-in-erofs_read_superblock.patch @@ -0,0 +1,37 @@ +From 0508c1ad0f264a24c4643701823a45f6c9bd8146 Mon Sep 17 00:00:00 2001 +From: Wei Yongjun +Date: Wed, 19 May 2021 14:16:57 +0000 +Subject: erofs: fix error return code in erofs_read_superblock() + +From: Wei Yongjun + +commit 0508c1ad0f264a24c4643701823a45f6c9bd8146 upstream. + +'ret' will be overwritten to 0 if erofs_sb_has_sb_chksum() return true, +thus 0 will return in some error handling cases. Fix to return negative +error code -EINVAL instead of 0. + +Link: https://lore.kernel.org/r/20210519141657.3062715-1-weiyongjun1@huawei.com +Fixes: b858a4844cfb ("erofs: support superblock checksum") +Cc: stable # 5.5+ +Reported-by: Hulk Robot +Signed-off-by: Wei Yongjun +Reviewed-by: Gao Xiang +Reviewed-by: Chao Yu +Signed-off-by: Gao Xiang +Signed-off-by: Greg Kroah-Hartman + +--- + fs/erofs/super.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/erofs/super.c ++++ b/fs/erofs/super.c +@@ -155,6 +155,7 @@ static int erofs_read_superblock(struct + goto out; + } + ++ ret = -EINVAL; + blkszbits = dsb->blkszbits; + /* 9(512 bytes) + LOG_SECTORS_PER_BLOCK == LOG_BLOCK_SIZE */ + if (blkszbits != LOG_BLOCK_SIZE) { diff --git a/queue-5.10/exfat-handle-wrong-stream-entry-size-in-exfat_readdir.patch b/queue-5.10/exfat-handle-wrong-stream-entry-size-in-exfat_readdir.patch new file mode 100644 index 00000000000..de214de5679 --- /dev/null +++ b/queue-5.10/exfat-handle-wrong-stream-entry-size-in-exfat_readdir.patch @@ -0,0 +1,69 @@ +From 1e5654de0f51890f88abd409ebf4867782431e81 Mon Sep 17 00:00:00 2001 +From: Namjae Jeon +Date: Fri, 11 Jun 2021 09:40:24 +0900 +Subject: exfat: handle wrong stream entry size in exfat_readdir() + +From: Namjae Jeon + +commit 1e5654de0f51890f88abd409ebf4867782431e81 upstream. + +The compatibility issue between linux exfat and exfat of some camera +company was reported from Florian. In their exfat, if the number of files +exceeds any limit, the DataLength in stream entry of the directory is +no longer updated. So some files created from camera does not show in +linux exfat. because linux exfat doesn't allow that cpos becomes larger +than DataLength of stream entry. This patch check DataLength in stream +entry only if the type is ALLOC_NO_FAT_CHAIN and add the check ensure +that dentry offset does not exceed max dentries size(256 MB) to avoid +the circular FAT chain issue. + +Fixes: ca06197382bd ("exfat: add directory operations") +Cc: stable@vger.kernel.org # v5.9 +Reported-by: Florian Cramer +Reviewed-by: Sungjong Seo +Tested-by: Chris Down +Signed-off-by: Namjae Jeon +Signed-off-by: Greg Kroah-Hartman + +--- + fs/exfat/dir.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/fs/exfat/dir.c ++++ b/fs/exfat/dir.c +@@ -62,7 +62,7 @@ static void exfat_get_uniname_from_ext_e + static int exfat_readdir(struct inode *inode, loff_t *cpos, struct exfat_dir_entry *dir_entry) + { + int i, dentries_per_clu, dentries_per_clu_bits = 0, num_ext; +- unsigned int type, clu_offset; ++ unsigned int type, clu_offset, max_dentries; + sector_t sector; + struct exfat_chain dir, clu; + struct exfat_uni_name uni_name; +@@ -85,6 +85,8 @@ static int exfat_readdir(struct inode *i + + dentries_per_clu = sbi->dentries_per_clu; + dentries_per_clu_bits = ilog2(dentries_per_clu); ++ max_dentries = (unsigned int)min_t(u64, MAX_EXFAT_DENTRIES, ++ (u64)sbi->num_clusters << dentries_per_clu_bits); + + clu_offset = dentry >> dentries_per_clu_bits; + exfat_chain_dup(&clu, &dir); +@@ -108,7 +110,7 @@ static int exfat_readdir(struct inode *i + } + } + +- while (clu.dir != EXFAT_EOF_CLUSTER) { ++ while (clu.dir != EXFAT_EOF_CLUSTER && dentry < max_dentries) { + i = dentry & (dentries_per_clu - 1); + + for ( ; i < dentries_per_clu; i++, dentry++) { +@@ -244,7 +246,7 @@ static int exfat_iterate(struct file *fi + if (err) + goto unlock; + get_new: +- if (cpos >= i_size_read(inode)) ++ if (ei->flags == ALLOC_NO_FAT_CHAIN && cpos >= i_size_read(inode)) + goto end_of_dir; + + err = exfat_readdir(inode, &cpos, &de); diff --git a/queue-5.10/fscrypt-don-t-ignore-minor_hash-when-hash-is-0.patch b/queue-5.10/fscrypt-don-t-ignore-minor_hash-when-hash-is-0.patch new file mode 100644 index 00000000000..ef64c21344d --- /dev/null +++ b/queue-5.10/fscrypt-don-t-ignore-minor_hash-when-hash-is-0.patch @@ -0,0 +1,60 @@ +From 77f30bfcfcf484da7208affd6a9e63406420bf91 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Thu, 27 May 2021 16:52:36 -0700 +Subject: fscrypt: don't ignore minor_hash when hash is 0 + +From: Eric Biggers + +commit 77f30bfcfcf484da7208affd6a9e63406420bf91 upstream. + +When initializing a no-key name, fscrypt_fname_disk_to_usr() sets the +minor_hash to 0 if the (major) hash is 0. + +This doesn't make sense because 0 is a valid hash code, so we shouldn't +ignore the filesystem-provided minor_hash in that case. Fix this by +removing the special case for 'hash == 0'. + +This is an old bug that appears to have originated when the encryption +code in ext4 and f2fs was moved into fs/crypto/. The original ext4 and +f2fs code passed the hash by pointer instead of by value. So +'if (hash)' actually made sense then, as it was checking whether a +pointer was NULL. But now the hashes are passed by value, and +filesystems just pass 0 for any hashes they don't have. There is no +need to handle this any differently from the hashes actually being 0. + +It is difficult to reproduce this bug, as it only made a difference in +the case where a filename's 32-bit major hash happened to be 0. +However, it probably had the largest chance of causing problems on +ubifs, since ubifs uses minor_hash to do lookups of no-key names, in +addition to using it as a readdir cookie. ext4 only uses minor_hash as +a readdir cookie, and f2fs doesn't use minor_hash at all. + +Fixes: 0b81d0779072 ("fs crypto: move per-file encryption from f2fs tree to fs/crypto") +Cc: # v4.6+ +Link: https://lore.kernel.org/r/20210527235236.2376556-1-ebiggers@kernel.org +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman + +--- + fs/crypto/fname.c | 10 +++------- + 1 file changed, 3 insertions(+), 7 deletions(-) + +--- a/fs/crypto/fname.c ++++ b/fs/crypto/fname.c +@@ -344,13 +344,9 @@ int fscrypt_fname_disk_to_usr(const stru + offsetof(struct fscrypt_nokey_name, sha256)); + BUILD_BUG_ON(BASE64_CHARS(FSCRYPT_NOKEY_NAME_MAX) > NAME_MAX); + +- if (hash) { +- nokey_name.dirhash[0] = hash; +- nokey_name.dirhash[1] = minor_hash; +- } else { +- nokey_name.dirhash[0] = 0; +- nokey_name.dirhash[1] = 0; +- } ++ nokey_name.dirhash[0] = hash; ++ nokey_name.dirhash[1] = minor_hash; ++ + if (iname->len <= sizeof(nokey_name.bytes)) { + memcpy(nokey_name.bytes, iname->name, iname->len); + size = offsetof(struct fscrypt_nokey_name, bytes[iname->len]); diff --git a/queue-5.10/fscrypt-fix-derivation-of-siphash-keys-on-big-endian-cpus.patch b/queue-5.10/fscrypt-fix-derivation-of-siphash-keys-on-big-endian-cpus.patch new file mode 100644 index 00000000000..a940947d977 --- /dev/null +++ b/queue-5.10/fscrypt-fix-derivation-of-siphash-keys-on-big-endian-cpus.patch @@ -0,0 +1,98 @@ +From 2fc2b430f559fdf32d5d1dd5ceaa40e12fb77bdf Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Sat, 5 Jun 2021 00:50:33 -0700 +Subject: fscrypt: fix derivation of SipHash keys on big endian CPUs + +From: Eric Biggers + +commit 2fc2b430f559fdf32d5d1dd5ceaa40e12fb77bdf upstream. + +Typically, the cryptographic APIs that fscrypt uses take keys as byte +arrays, which avoids endianness issues. However, siphash_key_t is an +exception. It is defined as 'u64 key[2];', i.e. the 128-bit key is +expected to be given directly as two 64-bit words in CPU endianness. + +fscrypt_derive_dirhash_key() and fscrypt_setup_iv_ino_lblk_32_key() +forgot to take this into account. Therefore, the SipHash keys used to +index encrypted+casefolded directories differ on big endian vs. little +endian platforms, as do the SipHash keys used to hash inode numbers for +IV_INO_LBLK_32-encrypted directories. This makes such directories +non-portable between these platforms. + +Fix this by always using the little endian order. This is a breaking +change for big endian platforms, but this should be fine in practice +since these features (encrypt+casefold support, and the IV_INO_LBLK_32 +flag) aren't known to actually be used on any big endian platforms yet. + +Fixes: aa408f835d02 ("fscrypt: derive dirhash key for casefolded directories") +Fixes: e3b1078bedd3 ("fscrypt: add support for IV_INO_LBLK_32 policies") +Cc: # v5.6+ +Link: https://lore.kernel.org/r/20210605075033.54424-1-ebiggers@kernel.org +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman + +--- + fs/crypto/keysetup.c | 40 ++++++++++++++++++++++++++++++++-------- + 1 file changed, 32 insertions(+), 8 deletions(-) + +--- a/fs/crypto/keysetup.c ++++ b/fs/crypto/keysetup.c +@@ -210,15 +210,40 @@ out_unlock: + return err; + } + ++/* ++ * Derive a SipHash key from the given fscrypt master key and the given ++ * application-specific information string. ++ * ++ * Note that the KDF produces a byte array, but the SipHash APIs expect the key ++ * as a pair of 64-bit words. Therefore, on big endian CPUs we have to do an ++ * endianness swap in order to get the same results as on little endian CPUs. ++ */ ++static int fscrypt_derive_siphash_key(const struct fscrypt_master_key *mk, ++ u8 context, const u8 *info, ++ unsigned int infolen, siphash_key_t *key) ++{ ++ int err; ++ ++ err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf, context, info, infolen, ++ (u8 *)key, sizeof(*key)); ++ if (err) ++ return err; ++ ++ BUILD_BUG_ON(sizeof(*key) != 16); ++ BUILD_BUG_ON(ARRAY_SIZE(key->key) != 2); ++ le64_to_cpus(&key->key[0]); ++ le64_to_cpus(&key->key[1]); ++ return 0; ++} ++ + int fscrypt_derive_dirhash_key(struct fscrypt_info *ci, + const struct fscrypt_master_key *mk) + { + int err; + +- err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf, HKDF_CONTEXT_DIRHASH_KEY, +- ci->ci_nonce, FSCRYPT_FILE_NONCE_SIZE, +- (u8 *)&ci->ci_dirhash_key, +- sizeof(ci->ci_dirhash_key)); ++ err = fscrypt_derive_siphash_key(mk, HKDF_CONTEXT_DIRHASH_KEY, ++ ci->ci_nonce, FSCRYPT_FILE_NONCE_SIZE, ++ &ci->ci_dirhash_key); + if (err) + return err; + ci->ci_dirhash_key_initialized = true; +@@ -253,10 +278,9 @@ static int fscrypt_setup_iv_ino_lblk_32_ + if (mk->mk_ino_hash_key_initialized) + goto unlock; + +- err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf, +- HKDF_CONTEXT_INODE_HASH_KEY, NULL, 0, +- (u8 *)&mk->mk_ino_hash_key, +- sizeof(mk->mk_ino_hash_key)); ++ err = fscrypt_derive_siphash_key(mk, ++ HKDF_CONTEXT_INODE_HASH_KEY, ++ NULL, 0, &mk->mk_ino_hash_key); + if (err) + goto unlock; + /* pairs with smp_load_acquire() above */ diff --git a/queue-5.10/io_uring-fix-blocking-inline-submission.patch b/queue-5.10/io_uring-fix-blocking-inline-submission.patch new file mode 100644 index 00000000000..3f04a834463 --- /dev/null +++ b/queue-5.10/io_uring-fix-blocking-inline-submission.patch @@ -0,0 +1,40 @@ +From 976517f162a05f4315b2373fd11585c395506259 Mon Sep 17 00:00:00 2001 +From: Pavel Begunkov +Date: Wed, 9 Jun 2021 12:07:25 +0100 +Subject: io_uring: fix blocking inline submission + +From: Pavel Begunkov + +commit 976517f162a05f4315b2373fd11585c395506259 upstream. + +There is a complaint against sys_io_uring_enter() blocking if it submits +stdin reads. The problem is in __io_file_supports_async(), which +sees that it's a cdev and allows it to be processed inline. + +Punt char devices using generic rules of io_file_supports_async(), +including checking for presence of *_iter() versions of rw callbacks. +Apparently, it will affect most of cdevs with some exceptions like +null and zero devices. + +Cc: stable@vger.kernel.org +Reported-by: Birk Hirdman +Signed-off-by: Pavel Begunkov +Link: https://lore.kernel.org/r/d60270856b8a4560a639ef5f76e55eb563633599.1623236455.git.asml.silence@gmail.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + fs/io_uring.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/io_uring.c ++++ b/fs/io_uring.c +@@ -2770,7 +2770,7 @@ static bool io_file_supports_async(struc + return true; + return false; + } +- if (S_ISCHR(mode) || S_ISSOCK(mode)) ++ if (S_ISSOCK(mode)) + return true; + if (S_ISREG(mode)) { + if (io_bdev_nowait(file->f_inode->i_sb->s_bdev) && diff --git a/queue-5.10/mailbox-qcom-ipcc-fix-ipcc-mbox-channel-exhaustion.patch b/queue-5.10/mailbox-qcom-ipcc-fix-ipcc-mbox-channel-exhaustion.patch new file mode 100644 index 00000000000..6d8686e0d63 --- /dev/null +++ b/queue-5.10/mailbox-qcom-ipcc-fix-ipcc-mbox-channel-exhaustion.patch @@ -0,0 +1,51 @@ +From d6fbfdbc12745ce24bcd348dbf7e652353b3e59c Mon Sep 17 00:00:00 2001 +From: Sibi Sankar +Date: Wed, 16 Jun 2021 23:12:58 +0530 +Subject: mailbox: qcom-ipcc: Fix IPCC mbox channel exhaustion + +From: Sibi Sankar + +commit d6fbfdbc12745ce24bcd348dbf7e652353b3e59c upstream. + +Fix IPCC (Inter-Processor Communication Controller) channel exhaustion by +setting the channel private data to NULL on mbox shutdown. + +Err Logs: +remoteproc: MBA booted without debug policy, loading mpss +remoteproc: glink-edge: failed to acquire IPC channel +remoteproc: failed to probe subdevices for remoteproc: -16 + +Fixes: fa74a0257f45 ("mailbox: Add support for Qualcomm IPCC") +Signed-off-by: Sibi Sankar +Cc: stable@vger.kernel.org +Reviewed-by: Bjorn Andersson +Reviewed-by: Manivannan Sadhasivam +Signed-off-by: Jassi Brar +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mailbox/qcom-ipcc.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/mailbox/qcom-ipcc.c ++++ b/drivers/mailbox/qcom-ipcc.c +@@ -155,6 +155,11 @@ static int qcom_ipcc_mbox_send_data(stru + return 0; + } + ++static void qcom_ipcc_mbox_shutdown(struct mbox_chan *chan) ++{ ++ chan->con_priv = NULL; ++} ++ + static struct mbox_chan *qcom_ipcc_mbox_xlate(struct mbox_controller *mbox, + const struct of_phandle_args *ph) + { +@@ -184,6 +189,7 @@ static struct mbox_chan *qcom_ipcc_mbox_ + + static const struct mbox_chan_ops ipcc_mbox_chan_ops = { + .send_data = qcom_ipcc_mbox_send_data, ++ .shutdown = qcom_ipcc_mbox_shutdown, + }; + + static int qcom_ipcc_setup_mbox(struct qcom_ipcc *ipcc) diff --git a/queue-5.10/media-exynos4-is-remove-a-now-unused-integer.patch b/queue-5.10/media-exynos4-is-remove-a-now-unused-integer.patch new file mode 100644 index 00000000000..9439f15a512 --- /dev/null +++ b/queue-5.10/media-exynos4-is-remove-a-now-unused-integer.patch @@ -0,0 +1,31 @@ +From 29dd19e3ac7b2a8671ebeac02859232ce0e34f58 Mon Sep 17 00:00:00 2001 +From: Mauro Carvalho Chehab +Date: Tue, 11 May 2021 17:03:21 +0200 +Subject: media: exynos4-is: remove a now unused integer + +From: Mauro Carvalho Chehab + +commit 29dd19e3ac7b2a8671ebeac02859232ce0e34f58 upstream. + +The usage of pm_runtime_resume_and_get() removed the need of a +temporary integer. So, drop it. + +Fixes: 59f96244af94 ("media: exynos4-is: fix pm_runtime_get_sync() usage count") +Reported-by: Stephen Rothwell +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/platform/exynos4-is/media-dev.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/media/platform/exynos4-is/media-dev.c ++++ b/drivers/media/platform/exynos4-is/media-dev.c +@@ -1280,7 +1280,6 @@ static DEVICE_ATTR(subdev_conf_mode, S_I + static int cam_clk_prepare(struct clk_hw *hw) + { + struct cam_clk *camclk = to_cam_clk(hw); +- int ret; + + if (camclk->fmd->pmf == NULL) + return -ENODEV; diff --git a/queue-5.10/mmc-block-disable-cmdq-on-the-ioctl-path.patch b/queue-5.10/mmc-block-disable-cmdq-on-the-ioctl-path.patch new file mode 100644 index 00000000000..d5e61a1beb5 --- /dev/null +++ b/queue-5.10/mmc-block-disable-cmdq-on-the-ioctl-path.patch @@ -0,0 +1,59 @@ +From 70b52f09080565030a530a784f1c9948a7f48ca3 Mon Sep 17 00:00:00 2001 +From: Bean Huo +Date: Tue, 4 May 2021 22:32:09 +0200 +Subject: mmc: block: Disable CMDQ on the ioctl path +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Bean Huo + +commit 70b52f09080565030a530a784f1c9948a7f48ca3 upstream. + +According to the eMMC Spec: +"When command queuing is enabled (CMDQ Mode En bit in CMDQ_MODE_EN +field is set to ‘1’) class 11 commands are the only method through +which data transfer tasks can be issued. Existing data transfer +commands, namely CMD18/CMD17 and CMD25/CMD24, are not supported when +command queuing is enabled." +which means if CMDQ is enabled, the FFU commands will not be supported. +To fix this issue, just simply disable CMDQ on the ioctl path, and +re-enable CMDQ once ioctl request is completed. + +Tested-by: Michael Brunner +Signed-off-by: Bean Huo +Acked-by: Adrian Hunter +Fixes: 1e8e55b67030 (mmc: block: Add CQE support) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210504203209.361597-1-huobean@gmail.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/core/block.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/mmc/core/block.c ++++ b/drivers/mmc/core/block.c +@@ -1003,6 +1003,12 @@ static void mmc_blk_issue_drv_op(struct + + switch (mq_rq->drv_op) { + case MMC_DRV_OP_IOCTL: ++ if (card->ext_csd.cmdq_en) { ++ ret = mmc_cmdq_disable(card); ++ if (ret) ++ break; ++ } ++ fallthrough; + case MMC_DRV_OP_IOCTL_RPMB: + idata = mq_rq->drv_op_data; + for (i = 0, ret = 0; i < mq_rq->ioc_count; i++) { +@@ -1013,6 +1019,8 @@ static void mmc_blk_issue_drv_op(struct + /* Always switch back to main area after RPMB access */ + if (rpmb_ioctl) + mmc_blk_part_switch(card, 0); ++ else if (card->reenable_cmdq && !card->ext_csd.cmdq_en) ++ mmc_cmdq_enable(card); + break; + case MMC_DRV_OP_BOOT_WP: + ret = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_WP, diff --git a/queue-5.10/mmc-vub3000-fix-control-request-direction.patch b/queue-5.10/mmc-vub3000-fix-control-request-direction.patch new file mode 100644 index 00000000000..57240b9b2f6 --- /dev/null +++ b/queue-5.10/mmc-vub3000-fix-control-request-direction.patch @@ -0,0 +1,38 @@ +From 3c0bb3107703d2c58f7a0a7a2060bb57bc120326 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Fri, 21 May 2021 15:30:26 +0200 +Subject: mmc: vub3000: fix control-request direction + +From: Johan Hovold + +commit 3c0bb3107703d2c58f7a0a7a2060bb57bc120326 upstream. + +The direction of the pipe argument must match the request-type direction +bit or control requests may fail depending on the host-controller-driver +implementation. + +Fix the SET_ROM_WAIT_STATES request which erroneously used +usb_rcvctrlpipe(). + +Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver") +Cc: stable@vger.kernel.org # 3.0 +Signed-off-by: Johan Hovold +Link: https://lore.kernel.org/r/20210521133026.17296-1-johan@kernel.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/vub300.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/mmc/host/vub300.c ++++ b/drivers/mmc/host/vub300.c +@@ -2279,7 +2279,7 @@ static int vub300_probe(struct usb_inter + if (retval < 0) + goto error5; + retval = +- usb_control_msg(vub300->udev, usb_rcvctrlpipe(vub300->udev, 0), ++ usb_control_msg(vub300->udev, usb_sndctrlpipe(vub300->udev, 0), + SET_ROM_WAIT_STATES, + USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, + firmware_rom_wait_states, 0x0000, NULL, 0, HZ); diff --git a/queue-5.10/scsi-fc-correct-rhba-attributes-length.patch b/queue-5.10/scsi-fc-correct-rhba-attributes-length.patch new file mode 100644 index 00000000000..30f431aacad --- /dev/null +++ b/queue-5.10/scsi-fc-correct-rhba-attributes-length.patch @@ -0,0 +1,37 @@ +From 40445fd2c9fa427297acdfcc2c573ff10493f209 Mon Sep 17 00:00:00 2001 +From: Javed Hasan +Date: Thu, 3 Jun 2021 03:14:03 -0700 +Subject: scsi: fc: Correct RHBA attributes length + +From: Javed Hasan + +commit 40445fd2c9fa427297acdfcc2c573ff10493f209 upstream. + +As per the FC-GS-5 specification, attribute lengths of node_name and +manufacturer should in range of "4 to 64 Bytes" only. + +Link: https://lore.kernel.org/r/20210603101404.7841-2-jhasan@marvell.com +Fixes: e721eb0616f6 ("scsi: scsi_transport_fc: Match HBA Attribute Length with HBAAPI V2.0 definitions") +CC: stable@vger.kernel.org +Reviewed-by: Himanshu Madhani +Signed-off-by: Javed Hasan +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + include/scsi/fc/fc_ms.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/include/scsi/fc/fc_ms.h ++++ b/include/scsi/fc/fc_ms.h +@@ -63,8 +63,8 @@ enum fc_fdmi_hba_attr_type { + * HBA Attribute Length + */ + #define FC_FDMI_HBA_ATTR_NODENAME_LEN 8 +-#define FC_FDMI_HBA_ATTR_MANUFACTURER_LEN 80 +-#define FC_FDMI_HBA_ATTR_SERIALNUMBER_LEN 80 ++#define FC_FDMI_HBA_ATTR_MANUFACTURER_LEN 64 ++#define FC_FDMI_HBA_ATTR_SERIALNUMBER_LEN 64 + #define FC_FDMI_HBA_ATTR_MODEL_LEN 256 + #define FC_FDMI_HBA_ATTR_MODELDESCR_LEN 256 + #define FC_FDMI_HBA_ATTR_HARDWAREVERSION_LEN 256 diff --git a/queue-5.10/scsi-target-cxgbit-unmap-dma-buffer-before-calling-target_execute_cmd.patch b/queue-5.10/scsi-target-cxgbit-unmap-dma-buffer-before-calling-target_execute_cmd.patch new file mode 100644 index 00000000000..7aee7915ff4 --- /dev/null +++ b/queue-5.10/scsi-target-cxgbit-unmap-dma-buffer-before-calling-target_execute_cmd.patch @@ -0,0 +1,116 @@ +From 6ecdafaec79d4b3388a5b017245f23a0ff9d852d Mon Sep 17 00:00:00 2001 +From: Varun Prakash +Date: Wed, 14 Apr 2021 18:09:09 +0530 +Subject: scsi: target: cxgbit: Unmap DMA buffer before calling target_execute_cmd() + +From: Varun Prakash + +commit 6ecdafaec79d4b3388a5b017245f23a0ff9d852d upstream. + +Instead of calling dma_unmap_sg() after completing WRITE I/O, call +dma_unmap_sg() before calling target_execute_cmd() to sync the DMA buffer. + +Link: https://lore.kernel.org/r/1618403949-3443-1-git-send-email-varun@chelsio.com +Cc: # 5.4+ +Signed-off-by: Varun Prakash +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/target/iscsi/cxgbit/cxgbit_ddp.c | 19 ++++++++++--------- + drivers/target/iscsi/cxgbit/cxgbit_target.c | 21 ++++++++++++++++++--- + 2 files changed, 28 insertions(+), 12 deletions(-) + +--- a/drivers/target/iscsi/cxgbit/cxgbit_ddp.c ++++ b/drivers/target/iscsi/cxgbit/cxgbit_ddp.c +@@ -265,12 +265,13 @@ void cxgbit_unmap_cmd(struct iscsi_conn + struct cxgbit_cmd *ccmd = iscsit_priv_cmd(cmd); + + if (ccmd->release) { +- struct cxgbi_task_tag_info *ttinfo = &ccmd->ttinfo; +- +- if (ttinfo->sgl) { ++ if (cmd->se_cmd.se_cmd_flags & SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC) { ++ put_page(sg_page(&ccmd->sg)); ++ } else { + struct cxgbit_sock *csk = conn->context; + struct cxgbit_device *cdev = csk->com.cdev; + struct cxgbi_ppm *ppm = cdev2ppm(cdev); ++ struct cxgbi_task_tag_info *ttinfo = &ccmd->ttinfo; + + /* Abort the TCP conn if DDP is not complete to + * avoid any possibility of DDP after freeing +@@ -280,14 +281,14 @@ void cxgbit_unmap_cmd(struct iscsi_conn + cmd->se_cmd.data_length)) + cxgbit_abort_conn(csk); + ++ if (unlikely(ttinfo->sgl)) { ++ dma_unmap_sg(&ppm->pdev->dev, ttinfo->sgl, ++ ttinfo->nents, DMA_FROM_DEVICE); ++ ttinfo->nents = 0; ++ ttinfo->sgl = NULL; ++ } + cxgbi_ppm_ppod_release(ppm, ttinfo->idx); +- +- dma_unmap_sg(&ppm->pdev->dev, ttinfo->sgl, +- ttinfo->nents, DMA_FROM_DEVICE); +- } else { +- put_page(sg_page(&ccmd->sg)); + } +- + ccmd->release = false; + } + } +--- a/drivers/target/iscsi/cxgbit/cxgbit_target.c ++++ b/drivers/target/iscsi/cxgbit/cxgbit_target.c +@@ -997,17 +997,18 @@ static int cxgbit_handle_iscsi_dataout(s + struct scatterlist *sg_start; + struct iscsi_conn *conn = csk->conn; + struct iscsi_cmd *cmd = NULL; ++ struct cxgbit_cmd *ccmd; ++ struct cxgbi_task_tag_info *ttinfo; + struct cxgbit_lro_pdu_cb *pdu_cb = cxgbit_rx_pdu_cb(csk->skb); + struct iscsi_data *hdr = (struct iscsi_data *)pdu_cb->hdr; + u32 data_offset = be32_to_cpu(hdr->offset); +- u32 data_len = pdu_cb->dlen; ++ u32 data_len = ntoh24(hdr->dlength); + int rc, sg_nents, sg_off; + bool dcrc_err = false; + + if (pdu_cb->flags & PDUCBF_RX_DDP_CMP) { + u32 offset = be32_to_cpu(hdr->offset); + u32 ddp_data_len; +- u32 payload_length = ntoh24(hdr->dlength); + bool success = false; + + cmd = iscsit_find_cmd_from_itt_or_dump(conn, hdr->itt, 0); +@@ -1022,7 +1023,7 @@ static int cxgbit_handle_iscsi_dataout(s + cmd->data_sn = be32_to_cpu(hdr->datasn); + + rc = __iscsit_check_dataout_hdr(conn, (unsigned char *)hdr, +- cmd, payload_length, &success); ++ cmd, data_len, &success); + if (rc < 0) + return rc; + else if (!success) +@@ -1060,6 +1061,20 @@ static int cxgbit_handle_iscsi_dataout(s + cxgbit_skb_copy_to_sg(csk->skb, sg_start, sg_nents, skip); + } + ++ ccmd = iscsit_priv_cmd(cmd); ++ ttinfo = &ccmd->ttinfo; ++ ++ if (ccmd->release && ttinfo->sgl && ++ (cmd->se_cmd.data_length == (cmd->write_data_done + data_len))) { ++ struct cxgbit_device *cdev = csk->com.cdev; ++ struct cxgbi_ppm *ppm = cdev2ppm(cdev); ++ ++ dma_unmap_sg(&ppm->pdev->dev, ttinfo->sgl, ttinfo->nents, ++ DMA_FROM_DEVICE); ++ ttinfo->nents = 0; ++ ttinfo->sgl = NULL; ++ } ++ + check_payload: + + rc = iscsit_check_dataout_payload(cmd, hdr, dcrc_err); diff --git a/queue-5.10/series b/queue-5.10/series index c530ccb4c8c..8351e55c812 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -578,3 +578,16 @@ selftests-vm-pkeys-refill-shadow-register-after-impl.patch perf-llvm-return-enomem-when-asprintf-fails.patch csky-fix-syscache.c-fallthrough-warning.patch csky-syscache-fixup-duplicate-cache-flush.patch +exfat-handle-wrong-stream-entry-size-in-exfat_readdir.patch +scsi-fc-correct-rhba-attributes-length.patch +scsi-target-cxgbit-unmap-dma-buffer-before-calling-target_execute_cmd.patch +mailbox-qcom-ipcc-fix-ipcc-mbox-channel-exhaustion.patch +fscrypt-don-t-ignore-minor_hash-when-hash-is-0.patch +fscrypt-fix-derivation-of-siphash-keys-on-big-endian-cpus.patch +tpm-replace-warn_once-with-dev_err_once-in-tpm_tis_status.patch +erofs-fix-error-return-code-in-erofs_read_superblock.patch +block-return-the-correct-bvec-when-checking-for-gaps.patch +io_uring-fix-blocking-inline-submission.patch +mmc-block-disable-cmdq-on-the-ioctl-path.patch +mmc-vub3000-fix-control-request-direction.patch +media-exynos4-is-remove-a-now-unused-integer.patch diff --git a/queue-5.10/tpm-replace-warn_once-with-dev_err_once-in-tpm_tis_status.patch b/queue-5.10/tpm-replace-warn_once-with-dev_err_once-in-tpm_tis_status.patch new file mode 100644 index 00000000000..433514ebb47 --- /dev/null +++ b/queue-5.10/tpm-replace-warn_once-with-dev_err_once-in-tpm_tis_status.patch @@ -0,0 +1,81 @@ +From 0178f9d0f60ba07e09bab57381a3ef18e2c1fd7f Mon Sep 17 00:00:00 2001 +From: Jarkko Sakkinen +Date: Wed, 9 Jun 2021 16:26:19 +0300 +Subject: tpm: Replace WARN_ONCE() with dev_err_once() in tpm_tis_status() + +From: Jarkko Sakkinen + +commit 0178f9d0f60ba07e09bab57381a3ef18e2c1fd7f upstream. + +Do not tear down the system when getting invalid status from a TPM chip. +This can happen when panic-on-warn is used. + +Instead, introduce TPM_TIS_INVALID_STATUS bitflag and use it to trigger +once the error reporting per chip. In addition, print out the value of +TPM_STS for improved forensics. + +Link: https://lore.kernel.org/keyrings/YKzlTR1AzUigShtZ@kroah.com/ +Fixes: 55707d531af6 ("tpm_tis: Add a check for invalid status") +Cc: stable@vger.kernel.org +Signed-off-by: Jarkko Sakkinen +Reviewed-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/tpm/tpm_tis_core.c | 25 ++++++++++++++++++------- + drivers/char/tpm/tpm_tis_core.h | 3 ++- + 2 files changed, 20 insertions(+), 8 deletions(-) + +--- a/drivers/char/tpm/tpm_tis_core.c ++++ b/drivers/char/tpm/tpm_tis_core.c +@@ -196,13 +196,24 @@ static u8 tpm_tis_status(struct tpm_chip + return 0; + + if (unlikely((status & TPM_STS_READ_ZERO) != 0)) { +- /* +- * If this trips, the chances are the read is +- * returning 0xff because the locality hasn't been +- * acquired. Usually because tpm_try_get_ops() hasn't +- * been called before doing a TPM operation. +- */ +- WARN_ONCE(1, "TPM returned invalid status\n"); ++ if (!test_and_set_bit(TPM_TIS_INVALID_STATUS, &priv->flags)) { ++ /* ++ * If this trips, the chances are the read is ++ * returning 0xff because the locality hasn't been ++ * acquired. Usually because tpm_try_get_ops() hasn't ++ * been called before doing a TPM operation. ++ */ ++ dev_err(&chip->dev, "invalid TPM_STS.x 0x%02x, dumping stack for forensics\n", ++ status); ++ ++ /* ++ * Dump stack for forensics, as invalid TPM_STS.x could be ++ * potentially triggered by impaired tpm_try_get_ops() or ++ * tpm_find_get_ops(). ++ */ ++ dump_stack(); ++ } ++ + return 0; + } + +--- a/drivers/char/tpm/tpm_tis_core.h ++++ b/drivers/char/tpm/tpm_tis_core.h +@@ -83,6 +83,7 @@ enum tis_defaults { + + enum tpm_tis_flags { + TPM_TIS_ITPM_WORKAROUND = BIT(0), ++ TPM_TIS_INVALID_STATUS = BIT(1), + }; + + struct tpm_tis_data { +@@ -90,7 +91,7 @@ struct tpm_tis_data { + int locality; + int irq; + bool irq_tested; +- unsigned int flags; ++ unsigned long flags; + void __iomem *ilb_base_addr; + u16 clkrun_enabled; + wait_queue_head_t int_queue;