netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Yannick Koehler <yannick@koehler.name>
Cc: netdev@vger.kernel.org
Subject: Re: Unix Socket buffer attribution
Date: Wed, 23 Jan 2013 19:35:53 +0100	[thread overview]
Message-ID: <20130123183553.GA13433@order.stressinduktion.org> (raw)
In-Reply-To: <CAJ4BwwFYKYOJoP34cGqWyE_AzxMwDNqFG-XDjLB6ZdO4nQmY4w@mail.gmail.com>

On Wed, Jan 23, 2013 at 11:41:16AM -0500, Yannick Koehler wrote:
> I did some more research, I found out that netlink and
> sock_queue_err_skb does the same trick that I claim to be missing
> under the net/unix/af_unix.c.  After adding the code, I got a problem
> since af_unix.c "_recvmsg()" functions assume that the skb->sk is
> holding the peer socket not the current one related to the receive
> skb.  It extract the sun_path name from it.  Since with UDP each
> packet may have a different peer, the only solution I found was to use
> the skb control block to hold the peer name.  The problem is that this
> cb member is 48 bytes in length and sun_path is 108 bytes in size.  So
> I had to increase it from 48 to 160 bytes.
> 
> This obviously increase the cost of an SKB struct, so I do not really
> like this solution. But at least it seems to prove my point and now,
> with this I can have my clients working except the one mis-behaving.
> I am attaching a patch.

Yes, you cannot do that. I would try to place a refcounted pointer to the
original sk in unix_skb_params. Perhaps a refcounted unix_address will dot the
trick, too.

      reply	other threads:[~2013-01-23 18:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-22  2:01 Unix Socket buffer attribution Yannick Koehler
2013-01-23  9:59 ` Hannes Frederic Sowa
2013-01-23 16:39   ` Yannick Koehler
2013-01-23 11:42 ` Cong Wang
2013-01-23 14:26   ` Eric Dumazet
2013-01-23 16:36     ` Yannick Koehler
2013-01-23 16:56       ` Eric Dumazet
2013-01-23 17:13         ` Eric Dumazet
2013-01-23 17:36           ` Yannick Koehler
2013-01-23 16:41 ` Yannick Koehler
2013-01-23 18:35   ` Hannes Frederic Sowa [this message]

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=20130123183553.GA13433@order.stressinduktion.org \
    --to=hannes@stressinduktion.org \
    --cc=netdev@vger.kernel.org \
    --cc=yannick@koehler.name \
    /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).