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 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.