From: Dan Carpenter <dan.carpenter@oracle.com>
To: hch@lst.de
Cc: Christoph Hellwig <hch@lst.de>, linux-nfs@vger.kernel.org
Subject: re: pnfs/blocklayout: refactor extent processing
Date: Mon, 15 Sep 2014 22:37:07 +0300 [thread overview]
Message-ID: <20140915193707.GA19241@mwanda> (raw)
Hello Christoph Hellwig,
The patch ca0fe1dfa5ac: "pnfs/blocklayout: refactor extent
processing" from Sep 10, 2014, leads to the following static checker
warning:
fs/nfs/blocklayout/blocklayout.c:558 bl_alloc_extent()
warn: use 'gfp_mask' here instead of GFP_XXX?
fs/nfs/blocklayout/blocklayout.c
544 static int
545 bl_alloc_extent(struct xdr_stream *xdr, struct pnfs_layout_hdr *lo,
546 struct layout_verification *lv, struct list_head *extents,
547 gfp_t gfp_mask)
548 {
549 struct pnfs_block_extent *be;
550 struct nfs4_deviceid id;
551 int error;
552 __be32 *p;
553
554 p = xdr_inline_decode(xdr, 28 + NFS4_DEVICEID4_SIZE);
555 if (!p)
556 return -EIO;
557
558 be = kzalloc(sizeof(*be), GFP_NOFS);
^^^^^^^^
The caller uses gfp_mask for it's kzalloc().
559 if (!be)
560 return -ENOMEM;
561
562 memcpy(&id, p, NFS4_DEVICEID4_SIZE);
563 p += XDR_QUADLEN(NFS4_DEVICEID4_SIZE);
Also on the same theme.
fs/nfs/blocklayout/dev.c
227 static int
228 bl_parse_concat(struct nfs_server *server, struct pnfs_block_dev *d,
229 struct pnfs_block_volume *volumes, int idx, gfp_t gfp_mask)
^^^^^^^^
230 {
231 struct pnfs_block_volume *v = &volumes[idx];
232 u64 len = 0;
233 int ret, i;
234
235 d->children = kcalloc(v->concat.volumes_count,
236 sizeof(struct pnfs_block_dev), GFP_KERNEL);
^^^^^^^^^^
237 if (!d->children)
238 return -ENOMEM;
239
240 for (i = 0; i < v->concat.volumes_count; i++) {
241 ret = bl_parse_deviceid(server, &d->children[i],
242 volumes, v->concat.volumes[i], gfp_mask);
243 if (ret)
244 return ret;
245
fs/nfs/blocklayout/dev.c
256 static int
257 bl_parse_stripe(struct nfs_server *server, struct pnfs_block_dev *d,
258 struct pnfs_block_volume *volumes, int idx, gfp_t gfp_mask)
^^^^^^^^
259 {
260 struct pnfs_block_volume *v = &volumes[idx];
261 u64 len = 0;
262 int ret, i;
263
264 d->children = kcalloc(v->stripe.volumes_count,
265 sizeof(struct pnfs_block_dev), GFP_KERNEL);
^^^^^^^^^^
266 if (!d->children)
267 return -ENOMEM;
268
269 for (i = 0; i < v->stripe.volumes_count; i++) {
270 ret = bl_parse_deviceid(server, &d->children[i],
271 volumes, v->stripe.volumes[i], gfp_mask);
272 if (ret)
regards,
dan carpenter
reply other threads:[~2014-09-15 19:37 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20140915193707.GA19241@mwanda \
--to=dan.carpenter@oracle.com \
--cc=hch@lst.de \
--cc=linux-nfs@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;
as well as URLs for NNTP newsgroup(s).