From: David Howells <dhowells@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: dhowells@redhat.com, torvalds@linux-foundation.org,
kwc@citi.umich.edu, Trond.Myklebust@netapp.com,
linux-kernel@vger.kernel.org, smfrench@gmail.com,
nfsv4@linux-nfs.org
Subject: Re: [PATCH] KEYS: Make request_key() and co fundamentally asynchronous
Date: Mon, 17 Sep 2007 11:56:00 +0100 [thread overview]
Message-ID: <16559.1190026560@redhat.com> (raw)
In-Reply-To: <20070914165938.9a429e02.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
> So who's going to review this? Nobody? Well gee, maybe it was my turn
> anyway.
Well, Kevin Coffman has reviewed it and tested it against his NFS keys patches.
> checkpatch generates a pile of warnings, all of which afacit are legit.
For this warning:
ERROR: need space after that ',' (ctx:WxV)
#627: FILE: security/keys/internal.h:28:
+#define kenter(FMT, ...) no_printk("==> %s("FMT")\n",__FUNCTION__ ,##__VA_ARGS__)
^
This is with good reason. Some versions of cpp get the ## resolution "wrong"
if __VA_ARGS__ is empty (ie: there are no arguments to the macro that
correspond to the "..."). This can be worked around by abutting the "," the
"##" and the "__VA_ARGS__" with no spaces, and inserting a space before the
comma.
If I remember correctly, the comma won't be removed if it doesn't abut the
##__VA_ARGS__, and the comma and everthing that abuts it on its LHS can be
removed if there's also no space. Without the "##", the comma isn't removed.
Consider the result of doing x("a"); where x(y, ...) is #defined to each of the
folowing:
DEFINITION RESULT
=============================== =======================
printk(y, __VA_ARGS__) print(y, );
printk(y ,__VA_ARGS__) print(y ,);
printk(y,##__VA_ARGS__) print();
printk(y, ##__VA_ARGS__) print(y, );
printk(y ,##__VA_ARGS__) print(y );
> It'd be nice to add a comment explaining to the long-suffering reader why
> down_write_nested() is used here.
I'll change the comment to:
/* make sure no one's trying to change or use the key when we mark it
* - we tell lockdep that we might nest because we might be revoking an
* authorisation key whilst holding the sem on a key we've just
* instantiated
*/
> You could actually use kstrdup() here, I think.
I could, but that potentially wastes time in two ways: firstly, there can be an
error before we've finished setting up, and that can lead to us having wasted
the time spent making the copy; and secondly, the call to kstrdup itself wastes
a bit of time because of the extra call made.
On the other hand, the code might end up a bit shorter, and isn't particularly
fast path anyway.
> rka->callout_info gets leaked later on (goto auth_key_revoked)
Fixed.
> Apart from that the changes look reasonable to me, but I am not a suitable
> reviewer for keys, NFS or rxrpc stuff. Who is??
Kevin Coffman and Trond for the NFS stuff, both of whom are CC'd.
David
next prev parent reply other threads:[~2007-09-17 10:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-12 14:25 [PATCH] KEYS: Make request_key() and co fundamentally asynchronous David Howells
2007-09-14 23:59 ` Andrew Morton
2007-09-17 10:56 ` David Howells [this message]
2007-09-17 11:03 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2007-09-17 13:17 David Howells
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=16559.1190026560@redhat.com \
--to=dhowells@redhat.com \
--cc=Trond.Myklebust@netapp.com \
--cc=akpm@linux-foundation.org \
--cc=kwc@citi.umich.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=smfrench@gmail.com \
--cc=torvalds@linux-foundation.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