On 8/9/24 20:31, Dan Carpenter wrote:
Hello Chengguang Xu,
Commit 719784ba706c ("ceph: add new field max_file_size in
ceph_fs_client") from Jul 19, 2018 (linux-next), leads to the
following Smatch static checker warning:
fs/ceph/mds_client.c:6157 ceph_mdsc_handle_mdsmap()
warn: truncated comparison 'mdsc->mdsmap->m_max_file_size' 'u64max' to 's64max'
fs/ceph/mds_client.c
6142 newmap = ceph_mdsmap_decode(mdsc, &p, end, ceph_msgr2(mdsc->fsc->client));
m_max_file_size comes from the user here
6143 if (IS_ERR(newmap)) {
6144 err = PTR_ERR(newmap);
6145 goto bad_unlock;
6146 }
6147
6148 /* swap into place */
6149 if (mdsc->mdsmap) {
6150 oldmap = mdsc->mdsmap;
6151 mdsc->mdsmap = newmap;
6152 check_new_map(mdsc, newmap, oldmap);
6153 ceph_mdsmap_destroy(oldmap);
6154 } else {
6155 mdsc->mdsmap = newmap; /* first mds map */
6156 }
--> 6157 mdsc->fsc->max_file_size = min((loff_t)mdsc->mdsmap->m_max_file_size,
High positive values are cast to negative so we end up with a negative
max_file_size. I dont' see that this causes an issue though...
In MDS sever side I didn't see any case will it be a negative value yet.
So this cast is safe.
We can just ignore it by sending a patch to dismiss this warning.
Thanks
- Xiubo
6158 MAX_LFS_FILESIZE);
6159
6160 __wake_requests(mdsc, &mdsc->waiting_for_map);
6161 ceph_monc_got_map(&mdsc->fsc->client->monc, CEPH_SUB_MDSMAP,
6162 mdsc->mdsmap->m_epoch);
6163
6164 mutex_unlock(&mdsc->mutex);
6165 schedule_delayed(mdsc, 0);
6166 return;
6167
6168 bad_unlock:
6169 mutex_unlock(&mdsc->mutex);
6170 bad:
6171 pr_err_client(cl, "error decoding mdsmap %d. Shutting down mount.\n",
6172 err);
6173 ceph_umount_begin(mdsc->fsc->sb);
6174 ceph_msg_dump(msg);
6175 return;
6176 }
regards,
dan carpenter
