--- /dev/null
+From 174fe5ba2d1ea0d6c5ab2a7d4aa058d6d497ae4d Mon Sep 17 00:00:00 2001
+From: Kaixu Xia <kaixuxia@tencent.com>
+Date: Thu, 29 Oct 2020 23:46:36 +0800
+Subject: ext4: correctly report "not supported" for {usr,grp}jquota when !CONFIG_QUOTA
+
+From: Kaixu Xia <kaixuxia@tencent.com>
+
+commit 174fe5ba2d1ea0d6c5ab2a7d4aa058d6d497ae4d upstream.
+
+The macro MOPT_Q is used to indicates the mount option is related to
+quota stuff and is defined to be MOPT_NOSUPPORT when CONFIG_QUOTA is
+disabled. Normally the quota options are handled explicitly, so it
+didn't matter that the MOPT_STRING flag was missing, even though the
+usrjquota and grpjquota mount options take a string argument. It's
+important that's present in the !CONFIG_QUOTA case, since without
+MOPT_STRING, the mount option matcher will match usrjquota= followed
+by an integer, and will otherwise skip the table entry, and so "mount
+option not supported" error message is never reported.
+
+[ Fixed up the commit description to better explain why the fix
+ works. --TYT ]
+
+Fixes: 26092bf52478 ("ext4: use a table-driven handler for mount options")
+Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
+Link: https://lore.kernel.org/r/1603986396-28917-1-git-send-email-kaixuxia@tencent.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/super.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/ext4/super.c
++++ b/fs/ext4/super.c
+@@ -1571,8 +1571,8 @@ static const struct mount_opts {
+ {Opt_noquota, (EXT4_MOUNT_QUOTA | EXT4_MOUNT_USRQUOTA |
+ EXT4_MOUNT_GRPQUOTA | EXT4_MOUNT_PRJQUOTA),
+ MOPT_CLEAR | MOPT_Q},
+- {Opt_usrjquota, 0, MOPT_Q},
+- {Opt_grpjquota, 0, MOPT_Q},
++ {Opt_usrjquota, 0, MOPT_Q | MOPT_STRING},
++ {Opt_grpjquota, 0, MOPT_Q | MOPT_STRING},
+ {Opt_offusrjquota, 0, MOPT_Q},
+ {Opt_offgrpjquota, 0, MOPT_Q},
+ {Opt_jqfmt_vfsold, QFMT_VFS_OLD, MOPT_QFMT},
--- /dev/null
+From 7067b2619017d51e71686ca9756b454de0e5826a Mon Sep 17 00:00:00 2001
+From: Joseph Qi <joseph.qi@linux.alibaba.com>
+Date: Tue, 3 Nov 2020 10:29:02 +0800
+Subject: ext4: unlock xattr_sem properly in ext4_inline_data_truncate()
+
+From: Joseph Qi <joseph.qi@linux.alibaba.com>
+
+commit 7067b2619017d51e71686ca9756b454de0e5826a upstream.
+
+It takes xattr_sem to check inline data again but without unlock it
+in case not have. So unlock it before return.
+
+Fixes: aef1c8513c1f ("ext4: let ext4_truncate handle inline data correctly")
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Cc: Tao Ma <boyu.mt@taobao.com>
+Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Reviewed-by: Andreas Dilger <adilger@dilger.ca>
+Link: https://lore.kernel.org/r/1604370542-124630-1-git-send-email-joseph.qi@linux.alibaba.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/inline.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ext4/inline.c
++++ b/fs/ext4/inline.c
+@@ -1890,6 +1890,7 @@ void ext4_inline_data_truncate(struct in
+
+ ext4_write_lock_xattr(inode, &no_expand);
+ if (!ext4_has_inline_data(inode)) {
++ ext4_write_unlock_xattr(inode, &no_expand);
+ *has_inline = 0;
+ ext4_journal_stop(handle);
+ return;
--- /dev/null
+From bcbc0b2e275f0a797de11a10eff495b4571863fc Mon Sep 17 00:00:00 2001
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+Date: Thu, 29 Oct 2020 11:54:42 +0200
+Subject: mei: protect mei_cl_mtu from null dereference
+
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+
+commit bcbc0b2e275f0a797de11a10eff495b4571863fc upstream.
+
+A receive callback is queued while the client is still connected
+but can still be called after the client was disconnected. Upon
+disconnect cl->me_cl is set to NULL, hence we need to check
+that ME client is not-NULL in mei_cl_mtu to avoid
+null dereference.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
+Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
+Link: https://lore.kernel.org/r/20201029095444.957924-2-tomas.winkler@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/mei/client.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/misc/mei/client.h
++++ b/drivers/misc/mei/client.h
+@@ -152,11 +152,11 @@ static inline u8 mei_cl_me_id(const stru
+ *
+ * @cl: host client
+ *
+- * Return: mtu
++ * Return: mtu or 0 if client is not connected
+ */
+ static inline size_t mei_cl_mtu(const struct mei_cl *cl)
+ {
+- return cl->me_cl->props.max_msg_length;
++ return cl->me_cl ? cl->me_cl->props.max_msg_length : 0;
+ }
+
+ /**
--- /dev/null
+From f5785283dd64867a711ca1fb1f5bb172f252ecdf Mon Sep 17 00:00:00 2001
+From: Wengang Wang <wen.gang.wang@oracle.com>
+Date: Fri, 13 Nov 2020 22:52:23 -0800
+Subject: ocfs2: initialize ip_next_orphan
+
+From: Wengang Wang <wen.gang.wang@oracle.com>
+
+commit f5785283dd64867a711ca1fb1f5bb172f252ecdf upstream.
+
+Though problem if found on a lower 4.1.12 kernel, I think upstream has
+same issue.
+
+In one node in the cluster, there is the following callback trace:
+
+ # cat /proc/21473/stack
+ __ocfs2_cluster_lock.isra.36+0x336/0x9e0 [ocfs2]
+ ocfs2_inode_lock_full_nested+0x121/0x520 [ocfs2]
+ ocfs2_evict_inode+0x152/0x820 [ocfs2]
+ evict+0xae/0x1a0
+ iput+0x1c6/0x230
+ ocfs2_orphan_filldir+0x5d/0x100 [ocfs2]
+ ocfs2_dir_foreach_blk+0x490/0x4f0 [ocfs2]
+ ocfs2_dir_foreach+0x29/0x30 [ocfs2]
+ ocfs2_recover_orphans+0x1b6/0x9a0 [ocfs2]
+ ocfs2_complete_recovery+0x1de/0x5c0 [ocfs2]
+ process_one_work+0x169/0x4a0
+ worker_thread+0x5b/0x560
+ kthread+0xcb/0xf0
+ ret_from_fork+0x61/0x90
+
+The above stack is not reasonable, the final iput shouldn't happen in
+ocfs2_orphan_filldir() function. Looking at the code,
+
+ 2067 /* Skip inodes which are already added to recover list, since dio may
+ 2068 * happen concurrently with unlink/rename */
+ 2069 if (OCFS2_I(iter)->ip_next_orphan) {
+ 2070 iput(iter);
+ 2071 return 0;
+ 2072 }
+ 2073
+
+The logic thinks the inode is already in recover list on seeing
+ip_next_orphan is non-NULL, so it skip this inode after dropping a
+reference which incremented in ocfs2_iget().
+
+While, if the inode is already in recover list, it should have another
+reference and the iput() at line 2070 should not be the final iput
+(dropping the last reference). So I don't think the inode is really in
+the recover list (no vmcore to confirm).
+
+Note that ocfs2_queue_orphans(), though not shown up in the call back
+trace, is holding cluster lock on the orphan directory when looking up
+for unlinked inodes. The on disk inode eviction could involve a lot of
+IOs which may need long time to finish. That means this node could hold
+the cluster lock for very long time, that can lead to the lock requests
+(from other nodes) to the orhpan directory hang for long time.
+
+Looking at more on ip_next_orphan, I found it's not initialized when
+allocating a new ocfs2_inode_info structure.
+
+This causes te reflink operations from some nodes hang for very long
+time waiting for the cluster lock on the orphan directory.
+
+Fix: initialize ip_next_orphan as NULL.
+
+Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Changwei Ge <gechangwei@live.cn>
+Cc: Gang He <ghe@suse.com>
+Cc: Jun Piao <piaojun@huawei.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/20201109171746.27884-1-wen.gang.wang@oracle.com
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ocfs2/super.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ocfs2/super.c
++++ b/fs/ocfs2/super.c
+@@ -1733,6 +1733,7 @@ static void ocfs2_inode_init_once(void *
+
+ oi->ip_blkno = 0ULL;
+ oi->ip_clusters = 0;
++ oi->ip_next_orphan = NULL;
+
+ ocfs2_resv_init_once(&oi->ip_la_data_resv);
+
of-address-fix-of_node-memory-leak-in-of_dma_is_cohe.patch
cosa-add-missing-kfree-in-error-path-of-cosa_write.patch
perf-fix-get_recursion_context.patch
+ext4-correctly-report-not-supported-for-usr-grp-jquota-when-config_quota.patch
+ext4-unlock-xattr_sem-properly-in-ext4_inline_data_truncate.patch
+usb-cdc-acm-add-disable_echo-for-renesas-usb-download-mode.patch
+mei-protect-mei_cl_mtu-from-null-dereference.patch
+ocfs2-initialize-ip_next_orphan.patch
--- /dev/null
+From 6d853c9e4104b4fc8d55dc9cd3b99712aa347174 Mon Sep 17 00:00:00 2001
+From: Chris Brandt <chris.brandt@renesas.com>
+Date: Wed, 11 Nov 2020 08:12:09 -0500
+Subject: usb: cdc-acm: Add DISABLE_ECHO for Renesas USB Download mode
+
+From: Chris Brandt <chris.brandt@renesas.com>
+
+commit 6d853c9e4104b4fc8d55dc9cd3b99712aa347174 upstream.
+
+Renesas R-Car and RZ/G SoCs have a firmware download mode over USB.
+However, on reset a banner string is transmitted out which is not expected
+to be echoed back and will corrupt the protocol.
+
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Oliver Neukum <oneukum@suse.com>
+Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
+Link: https://lore.kernel.org/r/20201111131209.3977903-1-chris.brandt@renesas.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/class/cdc-acm.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/usb/class/cdc-acm.c
++++ b/drivers/usb/class/cdc-acm.c
+@@ -1648,6 +1648,15 @@ static const struct usb_device_id acm_id
+ { USB_DEVICE(0x0870, 0x0001), /* Metricom GS Modem */
+ .driver_info = NO_UNION_NORMAL, /* has no union descriptor */
+ },
++ { USB_DEVICE(0x045b, 0x023c), /* Renesas USB Download mode */
++ .driver_info = DISABLE_ECHO, /* Don't echo banner */
++ },
++ { USB_DEVICE(0x045b, 0x0248), /* Renesas USB Download mode */
++ .driver_info = DISABLE_ECHO, /* Don't echo banner */
++ },
++ { USB_DEVICE(0x045b, 0x024D), /* Renesas USB Download mode */
++ .driver_info = DISABLE_ECHO, /* Don't echo banner */
++ },
+ { USB_DEVICE(0x0e8d, 0x0003), /* FIREFLY, MediaTek Inc; andrey.arapov@gmail.com */
+ .driver_info = NO_UNION_NORMAL, /* has no union descriptor */
+ },
projects / thirdparty / kernel / stable-queue.git / commitdiff
