On Tue, Jan 7, 2025 at 2:05 PM Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Jan 07, 2025 at 01:21:12PM +0100, Ilya Dryomov wrote: > > On Mon, Jan 6, 2025 at 4:28 PM Greg Kroah-Hartman > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > 6.6-stable review patch. If anyone has any objections, please let me know. > > > > > > ------------------ > > > > > > From: Xiubo Li <xiubli@xxxxxxxxxx> > > > > > > [ Upstream commit 38d46409c4639a1d659ebfa70e27a8bed6b8ee1d ] > > > > > > Multiple CephFS mounts on a host is increasingly common so > > > disambiguating messages like this is necessary and will make it easier > > > to debug issues. > > > > > > At the same this will improve the debug logs to make them easier to > > > troubleshooting issues, such as print the ino# instead only printing > > > the memory addresses of the corresponding inodes and print the dentry > > > names instead of the corresponding memory addresses for the dentry,etc. > > > > > > Link: https://tracker.ceph.com/issues/61590 > > > Signed-off-by: Xiubo Li <xiubli@xxxxxxxxxx> > > > Reviewed-by: Patrick Donnelly <pdonnell@xxxxxxxxxx> > > > Reviewed-by: Milind Changire <mchangir@xxxxxxxxxx> > > > Signed-off-by: Ilya Dryomov <idryomov@xxxxxxxxx> > > > Stable-dep-of: 550f7ca98ee0 ("ceph: give up on paths longer than PATH_MAX") > > > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> > > > --- > > > fs/ceph/acl.c | 6 +- > > > fs/ceph/addr.c | 279 +++++++++-------- > > > fs/ceph/caps.c | 710 +++++++++++++++++++++++++------------------ > > > fs/ceph/crypto.c | 39 ++- > > > fs/ceph/debugfs.c | 6 +- > > > fs/ceph/dir.c | 218 +++++++------ > > > fs/ceph/export.c | 39 +-- > > > fs/ceph/file.c | 245 ++++++++------- > > > fs/ceph/inode.c | 485 ++++++++++++++++------------- > > > fs/ceph/ioctl.c | 13 +- > > > fs/ceph/locks.c | 57 ++-- > > > fs/ceph/mds_client.c | 558 +++++++++++++++++++--------------- > > > fs/ceph/mdsmap.c | 24 +- > > > fs/ceph/metric.c | 5 +- > > > fs/ceph/quota.c | 29 +- > > > fs/ceph/snap.c | 174 ++++++----- > > > fs/ceph/super.c | 70 +++-- > > > fs/ceph/super.h | 6 + > > > fs/ceph/xattr.c | 96 +++--- > > > 19 files changed, 1747 insertions(+), 1312 deletions(-) > > > > Hi Greg, > > > > This is a huge patch, albeit mostly mechanical. Commit 550f7ca98ee0 > > ("ceph: give up on paths longer than PATH_MAX") for which this patch is > > a dependency just removes the affected log message, so it could be > > backported with a trivial conflict resolution instead of taking in > > 5c5f0d2b5f92 ("libceph: add doutc and *_client debug macros support") > > and 38d46409c463 ("ceph: print cluster fsid and client global_id in all > > debug logs") to arrange for a "clean" backport. > > > > Great, can you send such a backport? Sure, you should have one for 5.10-6.1 and a separate one for 6.6 in your inbox now. > > > Were these cherry picks done in an automated fashion by a tool that > > tries to identify and pull prerequisite patches based on "git blame" > > output? > > Yes. > > > The result appears to go against the rules laid out in > > Documentation/process/stable-kernel-rules.rst (particularly the limit > > on the number of lines), so I wanted to clarify the expected workflow > > of the stable team in this area. Are "clean" backports considered to > > justify additional prerequisite patches of this size even when the > > conflict resolution is "take ours" or otherwise trivial? > > Yes. Keeping the tree in sync is almost always preferred over "one-off" > changes that have to be hand-provided, when the maintainer is not > involved to ensure that we don't break anything. But if you want to In this case this lead to pulling in 1 file changed, 38 insertions(+) and 19 files changed, 1747 insertions(+), 1312 deletions(-) patches as dependencies to satisfy the backport of 1 file changed, 4 insertions(+), 5 deletions(-) patch. Is this OK given that stable-kernel-rules.rst still has "It cannot be bigger than 100 lines, with context." as one of the rules for what kind of patches are accepted? Thanks, Ilya
