From: Dan Carpenter <dan.carpenter@oracle.com>
To: dchinner@redhat.com
Cc: linux-xfs@vger.kernel.org
Subject: [bug report] xfs: use perag for ialloc btree cursors
Date: Thu, 10 Jun 2021 09:16:18 +0300 [thread overview]
Message-ID: <YMGuMliXClE/dz5y@mwanda> (raw)
Hello Dave Chinner,
This is a semi-automatic email about new static checker warnings.
The patch 7b13c5155182: "xfs: use perag for ialloc btree cursors"
from Jun 2, 2021, leads to the following Smatch complaint:
fs/xfs/libxfs/xfs_ialloc.c:2403 xfs_imap()
error: we previously assumed 'pag' could be null (see line 2294)
fs/xfs/libxfs/xfs_ialloc.c
2286 ASSERT(ino != NULLFSINO);
2287
2288 /*
2289 * Split up the inode number into its parts.
2290 */
2291 pag = xfs_perag_get(mp, XFS_INO_TO_AGNO(mp, ino));
2292 agino = XFS_INO_TO_AGINO(mp, ino);
2293 agbno = XFS_AGINO_TO_AGBNO(mp, agino);
2294 if (!pag || agbno >= mp->m_sb.sb_agblocks ||
^^^
Checks for NULL
2295 ino != XFS_AGINO_TO_INO(mp, pag->pag_agno, agino)) {
2296 error = -EINVAL;
2297 #ifdef DEBUG
2298 /*
2299 * Don't output diagnostic information for untrusted inodes
2300 * as they can be invalid without implying corruption.
2301 */
2302 if (flags & XFS_IGET_UNTRUSTED)
2303 goto out_drop;
^^^^^^^^^^^^^
2304 if (!pag) {
^^^^
2305 xfs_alert(mp,
2306 "%s: agno (%d) >= mp->m_sb.sb_agcount (%d)",
2307 __func__, XFS_INO_TO_AGNO(mp, ino),
2308 mp->m_sb.sb_agcount);
2309 }
2310 if (agbno >= mp->m_sb.sb_agblocks) {
2311 xfs_alert(mp,
2312 "%s: agbno (0x%llx) >= mp->m_sb.sb_agblocks (0x%lx)",
2313 __func__, (unsigned long long)agbno,
2314 (unsigned long)mp->m_sb.sb_agblocks);
2315 }
2316 if (pag && ino != XFS_AGINO_TO_INO(mp, pag->pag_agno, agino)) {
2317 xfs_alert(mp,
2318 "%s: ino (0x%llx) != XFS_AGINO_TO_INO() (0x%llx)",
2319 __func__, ino,
2320 XFS_AGINO_TO_INO(mp, pag->pag_agno, agino));
2321 }
2322 xfs_stack_trace();
2323 #endif /* DEBUG */
2324 goto out_drop;
2325 }
2326
2327 /*
2328 * For bulkstat and handle lookups, we have an untrusted inode number
2329 * that we have to verify is valid. We cannot do this just by reading
2330 * the inode buffer as it may have been unlinked and removed leaving
2331 * inodes in stale state on disk. Hence we have to do a btree lookup
2332 * in all cases where an untrusted inode number is passed.
2333 */
2334 if (flags & XFS_IGET_UNTRUSTED) {
2335 error = xfs_imap_lookup(mp, tp, pag, agino, agbno,
2336 &chunk_agbno, &offset_agbno, flags);
2337 if (error)
2338 goto out_drop;
2339 goto out_map;
2340 }
2341
2342 /*
2343 * If the inode cluster size is the same as the blocksize or
2344 * smaller we get to the buffer by simple arithmetics.
2345 */
2346 if (M_IGEO(mp)->blocks_per_cluster == 1) {
2347 offset = XFS_INO_TO_OFFSET(mp, ino);
2348 ASSERT(offset < mp->m_sb.sb_inopblock);
2349
2350 imap->im_blkno = XFS_AGB_TO_DADDR(mp, pag->pag_agno, agbno);
2351 imap->im_len = XFS_FSB_TO_BB(mp, 1);
2352 imap->im_boffset = (unsigned short)(offset <<
2353 mp->m_sb.sb_inodelog);
2354 error = 0;
2355 goto out_drop;
2356 }
2357
2358 /*
2359 * If the inode chunks are aligned then use simple maths to
2360 * find the location. Otherwise we have to do a btree
2361 * lookup to find the location.
2362 */
2363 if (M_IGEO(mp)->inoalign_mask) {
2364 offset_agbno = agbno & M_IGEO(mp)->inoalign_mask;
2365 chunk_agbno = agbno - offset_agbno;
2366 } else {
2367 error = xfs_imap_lookup(mp, tp, pag, agino, agbno,
2368 &chunk_agbno, &offset_agbno, flags);
2369 if (error)
2370 goto out_drop;
2371 }
2372
2373 out_map:
2374 ASSERT(agbno >= chunk_agbno);
2375 cluster_agbno = chunk_agbno +
2376 ((offset_agbno / M_IGEO(mp)->blocks_per_cluster) *
2377 M_IGEO(mp)->blocks_per_cluster);
2378 offset = ((agbno - cluster_agbno) * mp->m_sb.sb_inopblock) +
2379 XFS_INO_TO_OFFSET(mp, ino);
2380
2381 imap->im_blkno = XFS_AGB_TO_DADDR(mp, pag->pag_agno, cluster_agbno);
2382 imap->im_len = XFS_FSB_TO_BB(mp, M_IGEO(mp)->blocks_per_cluster);
2383 imap->im_boffset = (unsigned short)(offset << mp->m_sb.sb_inodelog);
2384
2385 /*
2386 * If the inode number maps to a block outside the bounds
2387 * of the file system then return NULL rather than calling
2388 * read_buf and panicing when we get an error from the
2389 * driver.
2390 */
2391 if ((imap->im_blkno + imap->im_len) >
2392 XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks)) {
2393 xfs_alert(mp,
2394 "%s: (im_blkno (0x%llx) + im_len (0x%llx)) > sb_dblocks (0x%llx)",
2395 __func__, (unsigned long long) imap->im_blkno,
2396 (unsigned long long) imap->im_len,
2397 XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks));
2398 error = -EINVAL;
2399 goto out_drop;
2400 }
2401 error = 0;
2402 out_drop:
2403 xfs_perag_put(pag);
^^^
Dereferenced inside the function call
2404 return error;
2405 }
regards,
dan carpenter
next reply other threads:[~2021-06-10 6:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 6:16 Dan Carpenter [this message]
2021-06-10 22:37 ` [PATCH] xfs: perag may be null in xfs_imap() Dave Chinner
2021-06-10 22:48 ` Darrick J. Wong
2021-06-11 0:57 ` Allison Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YMGuMliXClE/dz5y@mwanda \
--to=dan.carpenter@oracle.com \
--cc=dchinner@redhat.com \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox