From: Ben Greear <greearb@candelatech.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, kaber@trash.net
Subject: Re: SO_BINDTODEVICE mismatch with man page & comments.
Date: Fri, 14 Sep 2007 16:09:38 -0700 [thread overview]
Message-ID: <46EB14B2.8010805@candelatech.com> (raw)
In-Reply-To: <20070914.154316.59469764.davem@davemloft.net>
David Miller wrote:
> From: Ben Greear <greearb@candelatech.com>
> Date: Fri, 14 Sep 2007 15:37:45 -0700
>
>> I will try the patch, but it will probably not be until Monday.
>> The existing code actually can be made to work by passing in
>> a 4+ byte string and setting the first byte to zero, and as
>> far as I can see, that remains the same with the new patch.
>
> You said the route wasn't cleared correctly in your test, and that's
> one part I'm concerned about making sure is fixed.
> To be honest I'm slightly angry at you. I can travel for 24 hours
> non-stop on trains and planes and still be mostly responsive to people
> and apply patches. But I simply ask you to test a simple patch for a
> test case you said you already have and you can't do it until
> Monday?!?!?
>
> This is why I typically low priority all reports from you, sorry for
> not doing so this time too. :-/
My previous report was because I was trying to get Xorp to work with BINDTODEVICE, and
Xorp's a huge complicated beast. Due to it's actual use of the socket it would be very
hard to trigger (or notice) the route bug, and since we use a 4-byte null
string instead of depending on the bool value, I think it works around
it anyway.
The reason xorp wasn't working for me when I made the report was a problem
with the netlink headers I was compiling against (didn't support the > 255 routing
tables), but I didn't figure that out until later. Since the BINDTODEVICE route clearing
code in the kernel appeared to be broken, I thought that might have been the
problem, but in that I was wrong. I _do_ think the logic was/is wrong, it's just
that I was hitting something else in this particular case.
So, I will have to write a whole new app to test your fix properly, and I
plan to do so, but it will probably be next week.
I appreciate your responsiveness on the patch, as always, and will not be
overly offended if you choose to ignore subsequent reports from me.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
prev parent reply other threads:[~2007-09-14 23:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-04 22:45 SO_BINDTODEVICE mismatch with man page & comments Ben Greear
2007-09-12 15:08 ` David Miller
2007-09-14 20:12 ` David Miller
2007-09-14 22:11 ` Ben Greear
2007-09-14 22:29 ` David Miller
2007-09-14 22:37 ` Ben Greear
2007-09-14 22:43 ` David Miller
2007-09-14 23:09 ` Ben Greear [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=46EB14B2.8010805@candelatech.com \
--to=greearb@candelatech.com \
--cc=davem@davemloft.net \
--cc=kaber@trash.net \
--cc=netdev@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.