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? > 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 provide a working patch that you think should do the same thing without these dep-of: patches, that would be great! thanks, greg k-h
