From: Alexandru Moise <00moses.alexander00@gmail.com>
To: Jeff Mahoney <jeffm@suse.com>
Cc: clm@fb.com, jbacik@fb.com, dsterba@suse.com,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] btrfs: zero out delayed node upon allocation
Date: Sun, 25 Oct 2015 19:50:55 +0000 [thread overview]
Message-ID: <20151025195055.GA5021@gmail.com> (raw)
In-Reply-To: <562CFE51.8080700@suse.com>
> > This allows us to trim out half of btrfs_init_delayed_node() which
> > is now reduntant.
>
> It's redundant if kmem_cache_zalloc is used, but you haven't
> documented that doing so is now required. For all of these changes
> you've posted, if they're to be accepted, I'd really prefer to set up
> the slab with a constructor instead. Then we don't need to worry
> about such guarantees. The object returned via kmem_cache_alloc will
> always be properly initialized.
Well I wouldn't say it's *required* just makes this particular piece
of code neater, since we memset-zero the node's inode_item _anyways_.
I like the constructor idea though, do you suggest I should invest in
that idea?
>
> This makes assumptions about atomic_t and what atomic_set does that
> aren't guaranteed to be true. When accessors/mutators are part of the
> API they should be used.
>
> - -Jeff
You're right, taking out that atomic_set was really stupid. I'll
resent the patch with a proper explanation in the commit message and
put the atomic_set back.
Unless you feel that the change is rather pointless, I'll gladly back
off :-).
Regards,
Alex
next prev parent reply other threads:[~2015-10-25 16:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-25 17:48 [PATCH] btrfs: zero out delayed node upon allocation Alexandru Moise
2015-10-25 16:07 ` Jeff Mahoney
2015-10-25 19:50 ` Alexandru Moise [this message]
2015-10-25 17:33 ` Jeff Mahoney
2015-10-25 20:38 ` Alexandru Moise
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=20151025195055.GA5021@gmail.com \
--to=00moses.alexander00@gmail.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=jbacik@fb.com \
--cc=jeffm@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@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.