Hello Chris Mason,

The patch 263524b4ac6b: "Btrfs: split up __extent_writepage to lower
stack usage" from May 21, 2014, leads to the following static checker
warning:

        fs/btrfs/extent_io.c:4071 try_release_extent_state()
        warn: use 'mask' here instead of GFP_XXX?

fs/btrfs/extent_io.c
  4053  static int try_release_extent_state(struct extent_map_tree *map,
  4054                                      struct extent_io_tree *tree,
  4055                                      struct page *page, gfp_t mask)
  4056  {
  4057          u64 start = page_offset(page);
  4058          u64 end = start + PAGE_CACHE_SIZE - 1;
  4059          int ret = 1;
  4060  
  4061          if (test_range_bit(tree, start, end,
  4062                             EXTENT_IOBITS, 0, NULL))
  4063                  ret = 0;
  4064          else {
  4065                  if ((mask & GFP_NOFS) == GFP_NOFS)
  4066                          mask = GFP_NOFS;
  4067                  /*
  4068                   * at this point we can safely clear everything except 
the
  4069                   * locked bit and the nodatasum bit
  4070                   */
  4071                  ret = clear_extent_bit(tree, start, end,
  4072                                   ~(EXTENT_LOCKED | EXTENT_NODATASUM),
  4073                                   0, 0, NULL, GFP_ATOMIC);
                                                     ^^^^^^^^^^
It upsets the static checkers to keep "mask" around when we don't use it
anymore.

  4074  
  4075                  /* if clear_extent_bit failed for enomem reasons,
  4076                   * we can't allow the release to continue.
  4077                   */
  4078                  if (ret < 0)
  4079                          ret = 0;
  4080                  else
  4081                          ret = 1;
  4082          }
  4083          return ret;
  4084  }

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to