All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <error27@gmail.com>
To: fdmanana@suse.com
Cc: linux-btrfs@vger.kernel.org
Subject: [bug report] btrfs: drop extent map range more efficiently
Date: Mon, 27 Feb 2023 15:31:33 +0300	[thread overview]
Message-ID: <Y/yipSVozUDEZKow@kili> (raw)

Hello Filipe Manana,

The patch db21370bffbc: "btrfs: drop extent map range more
efficiently" from Sep 19, 2022, leads to the following Smatch static
checker warning:

	fs/btrfs/extent_map.c:767 btrfs_drop_extent_map_range()
	passing uninitialized variable 'flags'

fs/btrfs/extent_map.c
    740         while (em) {
    741                 /* extent_map_end() returns exclusive value (last byte + 1). */
    742                 const u64 em_end = extent_map_end(em);
    743                 struct extent_map *next_em = NULL;
    744                 u64 gen;
    745                 unsigned long flags;
                        ^^^^^^^^^^^^^^^^^^^

    746                 bool modified;
    747                 bool compressed;
    748 
    749                 if (em_end < end) {
    750                         next_em = next_extent_map(em);
    751                         if (next_em) {
    752                                 if (next_em->start < end)
    753                                         refcount_inc(&next_em->refs);
    754                                 else
    755                                         next_em = NULL;
    756                         }
    757                 }
    758 
    759                 if (skip_pinned && test_bit(EXTENT_FLAG_PINNED, &em->flags)) {
    760                         start = em_end;
    761                         if (end != (u64)-1)
    762                                 len = start + len - em_end;
    763                         goto next;
    764                 }
    765 
    766                 clear_bit(EXTENT_FLAG_PINNED, &em->flags);
--> 767                 clear_bit(EXTENT_FLAG_LOGGING, &flags);
                                                       ^^^^^^
flags is uninitialized at this point.  This clear_bit() is a no-op.

    768                 modified = !list_empty(&em->list);
    769 
    770                 /*
    771                  * The extent map does not cross our target range, so no need to
    772                  * split it, we can remove it directly.
    773                  */
    774                 if (em->start >= start && em_end <= end)
    775                         goto remove_em;
    776 
    777                 flags = em->flags;
    778                 gen = em->generation;
    779                 compressed = test_bit(EXTENT_FLAG_COMPRESSED, &em->flags);

regards,
dan carpenter

             reply	other threads:[~2023-02-27 12:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27 12:31 Dan Carpenter [this message]
2023-02-27 21:59 ` [bug report] btrfs: drop extent map range more efficiently David Sterba

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=Y/yipSVozUDEZKow@kili \
    --to=error27@gmail.com \
    --cc=fdmanana@suse.com \
    --cc=linux-btrfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.