[PATCH 02/18] flag parameters: socket and socketpair

[PATCH 02/18] flag parameters: socket and socketpair

[Ulrich Drepper]

This patch adds support for flag values which are ORed to the type passwd
to socket and socketpair.  The additional code is minimal.  Beside
decoding the flags with the library function introduced in a prior patch
all that has to be done is to pass the new value around.

The internal functions sock_alloc_fd and sock_map_fd get a new parameters
and all callers are changed.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
#include <netinet/in.h>
#include <sys/socket.h>

#define PORT 57392

#define SOCK_CLOEXEC 0x40000000

int
main (void)
{
  int fd;
  fd = socket (PF_INET, SOCK_STREAM, 0);
  if (fd == -1)
    {
      puts ("socket(0) failed");
      return 1;
    }
  int coe = fcntl (fd, F_GETFD);
  if (coe == -1)
    {
      puts ("fcntl failed");
      return 1;
    }
  if (coe & FD_CLOEXEC)
    {
      puts ("socket(0) set close-on-exec flag");
      return 1;
    }
  close (fd);

  fd = socket (PF_INET, SOCK_STREAM|SOCK_CLOEXEC, 0);
  if (fd == -1)
    {
      puts ("socket(SOCK_CLOEXEC) failed");
      return 1;
    }
  coe = fcntl (fd, F_GETFD);
  if (coe == -1)
    {
      puts ("fcntl failed");
      return 1;
    }
  if ((coe & FD_CLOEXEC) == 0)
    {
      puts ("socket(SOCK_CLOEXEC) does not set close-on-exec flag");
      return 1;
    }
  close (fd);

  int fds[2];
  if (socketpair (PF_UNIX, SOCK_STREAM, 0, fds) == -1)
    {
      puts ("socketpair(0) failed");
      return 1;
    }
  for (int i = 0; i < 2; ++i)
    {
      coe = fcntl (fds[i], F_GETFD);
      if (coe == -1)
        {
          puts ("fcntl failed");
          return 1;
        }
      if (coe & FD_CLOEXEC)
        {
          printf ("socketpair(0) set close-on-exec flag for fds[%d]\n", i);
          return 1;
        }
      close (fds[i]);
    }

  if (socketpair (PF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0, fds) == -1)
    {
      puts ("socketpair(SOCK_CLOEXEC) failed");
      return 1;
    }
  for (int i = 0; i < 2; ++i)
    {
      coe = fcntl (fds[i], F_GETFD);
      if (coe == -1)
        {
          puts ("fcntl failed");
          return 1;
        }
      if ((coe & FD_CLOEXEC) == 0)
        {
          printf ("socketpair(SOCK_CLOEXEC) does not set close-on-exec flag for fds[%d]\n", i);
          return 1;
        }
      close (fds[i]);
    }

  puts ("OK");

  return 0;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 include/linux/net.h |    5 ++++-
 net/9p/trans_fd.c   |    2 +-
 net/sctp/socket.c   |    2 +-
 net/socket.c        |   31 +++++++++++++++++++++++--------
 4 files changed, 29 insertions(+), 11 deletions(-)


Signed-off-by: Ulrich Drepper <drepper@redhat.com>

diff --git a/include/linux/net.h b/include/linux/net.h
index 71f7dd5..fcd3694 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -91,6 +91,9 @@ enum sock_type {
 	SOCK_SEQPACKET	= 5,
 	SOCK_DCCP	= 6,
 	SOCK_PACKET	= 10,
+
+	/* Flag values, ORed to the types above.  */
+	SOCK_CLOEXEC	= 0x40000000
 };
 
 #define SOCK_MAX (SOCK_PACKET + 1)
@@ -208,7 +211,7 @@ extern int   	     sock_sendmsg(struct socket *sock, struct msghdr *msg,
 				  size_t len);
 extern int	     sock_recvmsg(struct socket *sock, struct msghdr *msg,
 				  size_t size, int flags);
-extern int 	     sock_map_fd(struct socket *sock);
+extern int 	     sock_map_fd(struct socket *sock, int flags);
 extern struct socket *sockfd_lookup(int fd, int *err);
 #define		     sockfd_put(sock) fput(sock->file)
 extern int	     net_ratelimit(void);
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index f624dff..25931c0 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -1173,7 +1173,7 @@ static int p9_socket_open(struct p9_trans *trans, struct socket *csocket)
 	int fd, ret;
 
 	csocket->sk->sk_allocation = GFP_NOIO;
-	fd = sock_map_fd(csocket);
+	fd = sock_map_fd(csocket, 0);
 	if (fd < 0) {
 		P9_EPRINTK(KERN_ERR, "p9_socket_open: failed to map fd\n");
 		return fd;
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index e7e3baf..5034b1d 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -3812,7 +3812,7 @@ static int sctp_getsockopt_peeloff(struct sock *sk, int len, char __user *optval
 		goto out;
 
 	/* Map the socket to an unused fd that can be returned to the user.  */
-	retval = sock_map_fd(newsock);
+	retval = sock_map_fd(newsock, 0);
 	if (retval < 0) {
 		sock_release(newsock);
 		goto out;
diff --git a/net/socket.c b/net/socket.c
index 66c4a8c..1df03ae 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -85,6 +85,7 @@
 #include <linux/audit.h>
 #include <linux/wireless.h>
 #include <linux/nsproxy.h>
+#include <linux/flagsremap.h>
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>
@@ -348,11 +349,11 @@ static struct dentry_operations sockfs_dentry_operations = {
  *	but we take care of internal coherence yet.
  */
 
-static int sock_alloc_fd(struct file **filep)
+static int sock_alloc_fd(struct file **filep, int flags)
 {
 	int fd;
 
-	fd = get_unused_fd();
+	fd = get_unused_fd_flags(flags);
 	if (likely(fd >= 0)) {
 		struct file *file = get_empty_filp();
 
@@ -395,10 +396,10 @@ static int sock_attach_fd(struct socket *sock, struct file *file)
 	return 0;
 }
 
-int sock_map_fd(struct socket *sock)
+int sock_map_fd(struct socket *sock, int flags)
 {
 	struct file *newfile;
-	int fd = sock_alloc_fd(&newfile);
+	int fd = sock_alloc_fd(&newfile, flags);
 
 	if (likely(fd >= 0)) {
 		int err = sock_attach_fd(sock, newfile);
@@ -1213,16 +1214,25 @@ int sock_create_kern(int family, int type, int protocol, struct socket **res)
 	return __sock_create(&init_net, family, type, protocol, res, 1);
 }
 
+static const struct flags_rmap sock_file_flags_remap[] = {
+	{ SOCK_CLOEXEC, O_CLOEXEC },
+};
+
 asmlinkage long sys_socket(int family, int type, int protocol)
 {
 	int retval;
 	struct socket *sock;
+	int fflags;
+
+	type = flags_remap(sock_file_flags_remap,
+			   ARRAY_SIZE(sock_file_flags_remap),
+			   type, &fflags);
 
 	retval = sock_create(family, type, protocol, &sock);
 	if (retval < 0)
 		goto out;
 
-	retval = sock_map_fd(sock);
+	retval = sock_map_fd(sock, fflags);
 	if (retval < 0)
 		goto out_release;
 
@@ -1245,6 +1256,11 @@ asmlinkage long sys_socketpair(int family, int type, int protocol,
 	struct socket *sock1, *sock2;
 	int fd1, fd2, err;
 	struct file *newfile1, *newfile2;
+	int fflags;
+
+	type = flags_remap(sock_file_flags_remap,
+			   ARRAY_SIZE(sock_file_flags_remap),
+			   type, &fflags);
 
 	/*
 	 * Obtain the first socket and check if the underlying protocol
@@ -1263,13 +1279,13 @@ asmlinkage long sys_socketpair(int family, int type, int protocol,
 	if (err < 0)
 		goto out_release_both;
 
-	fd1 = sock_alloc_fd(&newfile1);
+	fd1 = sock_alloc_fd(&newfile1, fflags);
 	if (unlikely(fd1 < 0)) {
 		err = fd1;
 		goto out_release_both;
 	}
 
-	fd2 = sock_alloc_fd(&newfile2);
+	fd2 = sock_alloc_fd(&newfile2, fflags);
 	if (unlikely(fd2 < 0)) {
 		err = fd2;
 		put_filp(newfile1);
@@ -1425,7 +1450,7 @@ asmlinkage long sys_accept(int fd, struct sockaddr __user *upeer_sockaddr,
 	 */
 	__module_get(newsock->ops->owner);
 
-	newfd = sock_alloc_fd(&newfile);
+	newfd = sock_alloc_fd(&newfile, 0);
 	if (unlikely(newfd < 0)) {
 		err = newfd;
 		sock_release(newsock);

Re: [PATCH 02/18] flag parameters: socket and socketpair

[YOSHIFUJI Hideaki / 吉藤英明]

In article <200805050342.m453gktl029817@devserv.devel.redhat.com> (at Sun, 4 May 2008 23:42:46 -0400), Ulrich Drepper <drepper@redhat.com> says:

> This patch adds support for flag values which are ORed to the type passwd
> to socket and socketpair.  The additional code is minimal.  Beside
> decoding the flags with the library function introduced in a prior patch
> all that has to be done is to pass the new value around.
> 
> The internal functions sock_alloc_fd and sock_map_fd get a new parameters
> and all callers are changed.

Well, this seems the only patch that overrides basic context of the
arguments.  (Or, we have already "flags" argument for other APIs
that do not require new API.)

To me, it seems overriding 2nd argument is a too ad-hoc workaround,
and introducing new syscalls with flags is cleaner, e.g.,
    psocket(family, socktype, protocol, flags);
    psocketpair(d, type, protocol, int sv[2], flags);

--yoshfuji

Re: [PATCH 02/18] flag parameters: socket and socketpair

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

YOSHIFUJI Hideaki / 吉藤英明 wrote:

> To me, it seems overriding 2nd argument is a too ad-hoc workaround,
> and introducing new syscalls with flags is cleaner, e.g.,
>     psocket(family, socktype, protocol, flags);
>     psocketpair(d, type, protocol, int sv[2], flags);

While I agree, you missed the initial discussion where Alan, DaveM, and
Linus expressed preference for this overloading.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgelFUACgkQ2ijCOnn/RHSt1ACgx5ksBu0jMDqZDcG01PmJ4Jel
EywAoKLQ8pEKcB+bY+vDzaOaZvLyPag0
=6iYM
-----END PGP SIGNATURE-----

Re: [PATCH 02/18] flag parameters: socket and socketpair

[David Miller]

From: Ulrich Drepper <drepper@redhat.com>
Date: Sun, 4 May 2008 23:42:46 -0400

> This patch adds support for flag values which are ORed to the type passwd
> to socket and socketpair.  The additional code is minimal.  Beside
> decoding the flags with the library function introduced in a prior patch
> all that has to be done is to pass the new value around.
> 
> The internal functions sock_alloc_fd and sock_map_fd get a new parameters
> and all callers are changed.
...
> Signed-off-by: Ulrich Drepper <drepper@redhat.com>

Acked-by: David S. Miller <davem@davemloft.net>

Re: [PATCH 02/18] flag parameters: socket and socketpair

[Andrew Morton]

On Sun, 4 May 2008 23:42:46 -0400 Ulrich Drepper <drepper@redhat.com> wrote:

> +static const struct flags_rmap sock_file_flags_remap[] = {
> +	{ SOCK_CLOEXEC, O_CLOEXEC },
> +};
> +
>  asmlinkage long sys_socket(int family, int type, int protocol)
>  {
>  	int retval;
>  	struct socket *sock;
> +	int fflags;
> +
> +	type = flags_remap(sock_file_flags_remap,
> +			   ARRAY_SIZE(sock_file_flags_remap),
> +			   type, &fflags);

oh, so that's what it does.

afaict we only ever remap one or two flags.  Would it not be more efficient
to do that inline?  Something along the lines of:

	type = flag_remap(type, &fflags, SOCK_whatever, O_whatever);
	type = flag_remap(type, &fflags, SOCK_whatever2, O_whatever2);

?

Re: [PATCH 02/18] flag parameters: socket and socketpair

[Davide Libenzi]

On Mon, 5 May 2008, Andrew Morton wrote:

> On Sun, 4 May 2008 23:42:46 -0400 Ulrich Drepper <drepper@redhat.com> wrote:
> 
> > +static const struct flags_rmap sock_file_flags_remap[] = {
> > +	{ SOCK_CLOEXEC, O_CLOEXEC },
> > +};
> > +
> >  asmlinkage long sys_socket(int family, int type, int protocol)
> >  {
> >  	int retval;
> >  	struct socket *sock;
> > +	int fflags;
> > +
> > +	type = flags_remap(sock_file_flags_remap,
> > +			   ARRAY_SIZE(sock_file_flags_remap),
> > +			   type, &fflags);
> 
> oh, so that's what it does.
> 
> afaict we only ever remap one or two flags.  Would it not be more efficient
> to do that inline?  Something along the lines of:
> 
> 	type = flag_remap(type, &fflags, SOCK_whatever, O_whatever);
> 	type = flag_remap(type, &fflags, SOCK_whatever2, O_whatever2);
> 
> ?

I think it is better to keep it able to remap more than one flag, with a 
single call, that is table driven.



- Davide

Re: [PATCH 02/18] flag parameters: socket and socketpair

[Andrew Morton]

On Mon, 5 May 2008 19:13:14 -0700 (PDT) Davide Libenzi <davidel@xmailserver.org> wrote:

> On Mon, 5 May 2008, Andrew Morton wrote:
> 
> > On Sun, 4 May 2008 23:42:46 -0400 Ulrich Drepper <drepper@redhat.com> wrote:
> > 
> > > +static const struct flags_rmap sock_file_flags_remap[] = {
> > > +	{ SOCK_CLOEXEC, O_CLOEXEC },
> > > +};
> > > +
> > >  asmlinkage long sys_socket(int family, int type, int protocol)
> > >  {
> > >  	int retval;
> > >  	struct socket *sock;
> > > +	int fflags;
> > > +
> > > +	type = flags_remap(sock_file_flags_remap,
> > > +			   ARRAY_SIZE(sock_file_flags_remap),
> > > +			   type, &fflags);
> > 
> > oh, so that's what it does.
> > 
> > afaict we only ever remap one or two flags.  Would it not be more efficient
> > to do that inline?  Something along the lines of:
> > 
> > 	type = flag_remap(type, &fflags, SOCK_whatever, O_whatever);
> > 	type = flag_remap(type, &fflags, SOCK_whatever2, O_whatever2);
> > 
> > ?
> 
> I think it is better to keep it able to remap more than one flag, with a 
> single call, that is table driven.
> 

The table-driven approach is slower for one and probably two bits and it is
somewhat less readable.  What do we gain in return for this?

Re: [PATCH 02/18] flag parameters: socket and socketpair

[Davide Libenzi]

On Mon, 5 May 2008, Andrew Morton wrote:

> On Mon, 5 May 2008 19:13:14 -0700 (PDT) Davide Libenzi <davidel@xmailserver.org> wrote:
> 
> > On Mon, 5 May 2008, Andrew Morton wrote:
> > 
> > > On Sun, 4 May 2008 23:42:46 -0400 Ulrich Drepper <drepper@redhat.com> wrote:
> > > 
> > > > +static const struct flags_rmap sock_file_flags_remap[] = {
> > > > +	{ SOCK_CLOEXEC, O_CLOEXEC },
> > > > +};
> > > > +
> > > >  asmlinkage long sys_socket(int family, int type, int protocol)
> > > >  {
> > > >  	int retval;
> > > >  	struct socket *sock;
> > > > +	int fflags;
> > > > +
> > > > +	type = flags_remap(sock_file_flags_remap,
> > > > +			   ARRAY_SIZE(sock_file_flags_remap),
> > > > +			   type, &fflags);
> > > 
> > > oh, so that's what it does.
> > > 
> > > afaict we only ever remap one or two flags.  Would it not be more efficient
> > > to do that inline?  Something along the lines of:
> > > 
> > > 	type = flag_remap(type, &fflags, SOCK_whatever, O_whatever);
> > > 	type = flag_remap(type, &fflags, SOCK_whatever2, O_whatever2);
> > > 
> > > ?
> > 
> > I think it is better to keep it able to remap more than one flag, with a 
> > single call, that is table driven.
> > 
> 
> The table-driven approach is slower for one and probably two bits and it is
> somewhat less readable.  What do we gain in return for this?

I think we can spend a few hours countering each other Pros&Cons about 
performance, size, style, etc...
Not worth if you ask me. So if you like the other way better, ask Uli to 
fix it your way.



- Davide

Re: [PATCH 02/18] flag parameters: socket and socketpair

[Alan Cox]

> > > 	type = flag_remap(type, &fflags, SOCK_whatever, O_whatever);
> > > 	type = flag_remap(type, &fflags, SOCK_whatever2, O_whatever2);
> > > 
> > > ?
> > 
> > I think it is better to keep it able to remap more than one flag, with a 
> > single call, that is table driven.
> > 
> 
> The table-driven approach is slower for one and probably two bits and it is
> somewhat less readable.  What do we gain in return for this?

Acute over-engineering ?

We've got lots of space for flag bits so surely we can do remap with a
shift and mask.

	flags = (type >> SOCK_FLAG_SHIFT) & SOCK_FLAG_MASK;
	type = type & SOCK_TYPE_MASK

For most boxes

SOCK_TYPE_MASK can easily be 0xFF
SOCK_FLAG_MASK O_CLOEXEC
SOCK_FLAG_SHIFT 0

and tweaked a bit depending what other flags we want.

In Linux we could actually just do SOCK_STREAM|O_CLOEXEC but that would be
bad news for portability to other OS where the trick might well not work.

Re: [PATCH 02/18] flag parameters: socket and socketpair

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Morton wrote:
> afaict we only ever remap one or two flags.

So far.  I have plans for at least one more flag: the one we'll
hopefully have sometime soon to request non-sequential file descriptors.
 There is no reason why there shouldn't be even more in future.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIH8OK2ijCOnn/RHQRAgd/AJ47rSUE8UZotXuce4mp6SMWn08OQACdH8tS
kcd8c40jXlDlE1LySSdf5mQ=
=7KVe
-----END PGP SIGNATURE-----

Re: [PATCH 02/18] flag parameters: socket and socketpair

[Andrew Morton]

On Mon, 05 May 2008 19:33:46 -0700 Ulrich Drepper <drepper@redhat.com> wrote:

> Andrew Morton wrote:
> > afaict we only ever remap one or two flags.
> 
> So far.  I have plans for at least one more flag: the one we'll
> hopefully have sometime soon to request non-sequential file descriptors.
>  There is no reason why there shouldn't be even more in future.

oh.  More overhead.

Sorry to sound slow, but what do we gain from all this?  Your covering
description was heavy in references to some earlier discussion to which I
obviously paid little attention and now I'm lost.

Re: [PATCH 02/18] flag parameters: socket and socketpair

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Morton wrote:
> Sorry to sound slow, but what do we gain from all this?  Your covering
> description was heavy in references to some earlier discussion to which I
> obviously paid little attention and now I'm lost.

What we gain is that the only change for a new flag is a new entry in
the appropriate table.  The reference to non-sequential file descriptors
refers to

  http://lwn.net/Articles/236724/

Not this specific incarnation of the functionality, but something like this.

A few more points:

- - for the socket functions we can share the table

- - in most cases the loop isn't even entered since the flag value is
  zero.  In any case, the loop is ended once all flags have been mapped

- - in case this code is really called often, than the code is in the
  cache and it is shorter than each of possible multiple copies of the
  unrolled loop


Anyway, we spent already far too much time on this.  If you want to see
it changed tell me.  It's really not important.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIH8lM2ijCOnn/RHQRAta6AKC39ty8FdiRYjRxxHDoG2T/N1hhywCeKPcZ
L/iDtbf9DozMmEfoLY8nlbk=
=B+YO
-----END PGP SIGNATURE-----

Re: [PATCH 02/18] flag parameters: socket and socketpair

[Andrew Morton]

On Mon, 05 May 2008 19:58:20 -0700 Ulrich Drepper <drepper@redhat.com> wrote:

> Andrew Morton wrote:
> > Sorry to sound slow, but what do we gain from all this?  Your covering
> > description was heavy in references to some earlier discussion to which I
> > obviously paid little attention and now I'm lost.
> 
> What we gain is that the only change for a new flag is a new entry in
> the appropriate table.  The reference to non-sequential file descriptors
> refers to
> 
>   http://lwn.net/Articles/236724/

What I meant was "what does this whole patchset do"?  Believe it or not,
for a new reader, that is somewhat unobvious.  Perhaps one could work it out
with sufficient googling and thread-trolling.

Re: [PATCH 02/18] flag parameters: socket and socketpair

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Morton wrote:
> What I meant was "what does this whole patchset do"?  Believe it or not,
> for a new reader, that is somewhat unobvious.  Perhaps one could work it out
> with sufficient googling and thread-trolling.

It adds flag parameters in all the places where none is present to
control aspects of the returned file descriptor(s).  So far atomic
close-on-exec and setting non-blocking mode are implemented.  More can
follow if wanted.  Similar to the O_CLOEXEC and F_DUPFD_CLOEXEC
extensions which I wrote several moons ago.  Just two weeks ago I pointed at

   http://bugzilla.redhat.com/show_bug.cgi?id=443321

as a case which we cannot really fix without these kind of extensions.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIH8w22ijCOnn/RHQRAjNvAJkBJxBR3uI8HfPIUqcMezLjFK/d2QCfXS4v
IH7T6AFb/j9V4tWtlWi0Bcs=
=lLFY
-----END PGP SIGNATURE-----

Re: [PATCH 02/18] flag parameters: socket and socketpair

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Morton wrote:
> oh.  More overhead.

One alternative: I can simply do away with the remapping and just
allocate the bits for the new constants (EFD_CLOEXEC) to match those of
the O_* constants.  This means we can still reuse the low bits which
aren't available in the O_* constants.  It means, though, that the
constants are architecture specific since O_CLOEXEC, for instance, has
different values for different architectures.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIH8pf2ijCOnn/RHQRAnlPAKCPxPVuaW+nXpCaxNsPmrAunBqt6gCfetlU
41ZicojDFl0TmVX34p8Z1CA=
=q+B/
-----END PGP SIGNATURE-----