On Thu, 2021-09-23 at 18:56 +0530, khiremat@xxxxxxxxxx wrote: > From: Kotresh HR <khiremat@xxxxxxxxxx> > > The "error_string" in the metadata of MClientSession is being > parsed by kclient to validate whether the session is blocklisted. > The "error_string" is for humans and shouldn't be relied on it. > Hence added the flag to MClientsession to indicate the session > is blocklisted. > > URL: https://tracker.ceph.com/issues/47450 > Signed-off-by: Kotresh HR <khiremat@xxxxxxxxxx> > --- > fs/ceph/mds_client.c | 13 +++++++++++++ > include/linux/ceph/ceph_fs.h | 2 ++ > 2 files changed, 15 insertions(+) > > diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c > index 44bc780b2b0e..f3c023c17963 100644 > --- a/fs/ceph/mds_client.c > +++ b/fs/ceph/mds_client.c > @@ -3407,6 +3407,19 @@ static void handle_session(struct ceph_mds_session *session, > } > } > > + if (msg_version >= 5) { > + u32 len; > + u32 flags; > + /* version >= 4, metric_spec (struct_v, struct_cv, len, metric_flag) */ > + ceph_decode_skip_n(&p, end, 2 + sizeof(u32) * 2, bad); > + /* version >= 5, flags */ > + ceph_decode_32_safe(&p, end, flags, bad); > + if (flags & CEPH_SESSION_BLOCKLISTED) { > + pr_info("mds%d session blocklisted\n", session->s_mds); Things are likely to not work well if this flag is set. Maybe this should be a pr_warn? > + blocklisted = true; > + } > + } > + > mutex_lock(&mdsc->mutex); > if (op == CEPH_SESSION_CLOSE) { > ceph_get_mds_session(session); > diff --git a/include/linux/ceph/ceph_fs.h b/include/linux/ceph/ceph_fs.h > index bc2699feddbe..7ad6c3d0db7d 100644 > --- a/include/linux/ceph/ceph_fs.h > +++ b/include/linux/ceph/ceph_fs.h > @@ -302,6 +302,8 @@ enum { > CEPH_SESSION_REQUEST_FLUSH_MDLOG, > }; > > +#define CEPH_SESSION_BLOCKLISTED (1 << 0) /* session blocklisted */ > + > extern const char *ceph_session_op_name(int op); > > struct ceph_mds_session_head { This looks reasonable, but incomplete. If the msg_version >= 5, then we probably also don't need to scan for "blacklisted" in the strings, right? In fact, it looks like we can avoid doing most of __decode_session_metadata in that case and can just skip over the text blob section. -- Jeff Layton <jlayton@xxxxxxxxxx>
