All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <clm@fb.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: Btrfs: split up __extent_writepage to lower stack usage
Date: Mon, 9 Jun 2014 10:48:04 -0400	[thread overview]
Message-ID: <5395C924.7070004@fb.com> (raw)
In-Reply-To: <20140609144014.GA8771@mwanda>

On 06/09/2014 10:40 AM, Dan Carpenter wrote:
> 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.

Thanks Dan, I'll switch this around to make it more clear.

-chris

      reply	other threads:[~2014-06-09 14:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-09 14:40 Btrfs: split up __extent_writepage to lower stack usage Dan Carpenter
2014-06-09 14:48 ` Chris Mason [this message]

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=5395C924.7070004@fb.com \
    --to=clm@fb.com \
    --cc=dan.carpenter@oracle.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.