* Re: Connection tracking and vlan
From: Patrick McHardy @ 2009-11-02 16:33 UTC (permalink / raw)
To: Adayadil Thomas
Cc: Ben Greear, Eric W. Biederman, Eric Dumazet, Herbert Xu,
Linux Netdev List, Netfilter Development Mailinglist
In-Reply-To: <fb7befa20911020814q2c4bcd1bj7e2b5a4c17ba0f89@mail.gmail.com>
Adayadil Thomas wrote:
> If the vlan id is used for hash, it still may not avoid the problem completely,
> i.e. in case of both connections hashing to the same bucket.
>
> I was wondering about your opinion about adding an optional member to the tuple
> structure, vid (for vlan id).
>
> I have attached the patch for this change. I would be grateful for any comments
> such as dependencies on the rest of the system.
Absolutely not, conntrack is not meant to deal with anything below
the network layer and I don't want to add any hacks for the bridge
netfilter "integration", which has already caused an endless amount
of problems. Additionally this is just one of many possible identifiers
people might want to use to distinguish similar entries and has a
number of practical issues, like breaking asymetric setups using
different VLANs for each direction.
I might be willing to consider a generically usable numerical
identifier to distinguish similar entries, something like
"conntrack zones". This could also help with the defragmentation
issue discussed earlier, the identifier would also be added to
the defragmentation identifier, for asymetric setups the interfaces
would be put in the same "zone".
But it would be preferrable if we could do this using network
namespaces somehow.
^ permalink raw reply
* Re: Connection tracking and vlan
From: Eric Dumazet @ 2009-11-02 16:41 UTC (permalink / raw)
To: Patrick McHardy
Cc: Adayadil Thomas, Ben Greear, Eric W. Biederman, Herbert Xu,
Linux Netdev List, Netfilter Development Mailinglist
In-Reply-To: <4AEF09E7.2010004@trash.net>
Patrick McHardy a écrit :
>
> But it would be preferrable if we could do this using network
> namespaces somehow.
eg eth0.100 and eth0.101 on namespace 1, eth0.200 and eth0.201 on namespace 2 ?
Can we do that with current kernel ? (different vlans on an unique physical device)
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: John W. Linville @ 2009-11-02 16:46 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jarek Poplawski, Johannes Berg, Bartlomiej Zolnierkiewicz,
Pekka Enberg, David Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20091102091038.GA9044@elte.hu>
On Mon, Nov 02, 2009 at 10:10:38AM +0100, Ingo Molnar wrote:
>
> * John W. Linville <linville@tuxdriver.com> wrote:
<snip>
> > Ever since Bartlomiej decided to tear himself away from
> > drivers/staging, he has been nothing but negative -- petty, whining,
> > indignat, whatever. Just what has he done to merit any special
> > consideration here? Why should he have any sort of veto over rt2x00?
>
> I got curious, as my past experience with Bartlomiej is that he is a
> factual, reliable, knowledgable upstream driver developer interested in
> difficult pieces of code others are reluctant to touch, for whom it is
> rather atypical to get 'petty, whining, indignant'.
YMMV...
<snip>
> Bartlomiej's reply (<1255792104.3434.2.camel@johannes.local>) ignored
> the attack (gracefully) and replied to the technical portion only:
>
> | > Tell me you're kidding -- comparing 2k duplicated LOC with a driver
> | > that ships its own wifi stack?
> |
> | Why would I be?
> |
> | 1) The patch is submitted to kernel _proper_ not kernel staging so I
> | see no excuse for duplicating 2-4 KLOC and it should be fixed.
> |
> | 2) The fact that the some staging driver consists in 90% of crap
> | doesn't mean that it doesn't have some good design ideas.. (i.e.
> | abstracting chipset registers access in a discussed case)
>
> To which technical point Johannes elected not to reply. (Effectively
> conceding Bartlomiej's point as per lkml discussion rules.)
Really? "Last post wins" is the rule? I hope you are joking...
> I can understand David trusting your judgement and not wanting to get
> involved in the fine details, but having read the surrounding discussion
> i dont understand your interpretation of the events, and i dont
> understand on what basis you launched your very serious accusation, that
> he is being 'petty, whining, indignant'. Every reply from him in that
> thread is the exact opposite of that. Care to elaborate?
Despite your links, we seem to be reading different threads. I'm not
sure I can reach your conclusions even with the most generous reading
of Bartlomiej's posts and the most critical readings of _everyone_
else's.
It seems Bartlomiej has taken it personally that we don't like having
the Ralink vendor drivers in the staging tree and he has decided to be
an irritant in linux-wireless as some sort of revenge. As a bonus,
he has thrown-in some random ramblings attacking the inclusion of
Pulseaudio in Fedora and criticizing Dave's handling of the ide tree.
And worst of all he has chosen to make a big stink about whether or
not the rt2x00 family of drivers (which shares tons of code already,
BTW) is sharing enough code for his taste in drivers that are currently
under active development.
Now you have come along to defend him for whatever your reasons,
and you have chosen to act as if Bartlomiej has been ignored simply
because you don't like the responses he got. Further, you seem to
expect me to have given him some veto over a driver for which has
has contributed essentially nothing[1]. Why? Simply because he doesn't
agree with the driver maintainer's JUDGMENT CALL? Or mine? Or Dave's?
And for all his objections, he can't be bothered to offer a patch?
I can only guess as to why you are being deferential to Bartlomiej
and overlooking not only how he has treated the rest of us but also
that his technical complaint is minor. I can only ask you to consider
that maybe Bartlomiej is not so aggrieved as he claims.
John
[1] Even his bug reports and code reviews have clearly been from the
perspective of "you should just be using the staging driver".
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Connection tracking and vlan
From: Patrick McHardy @ 2009-11-02 16:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: Adayadil Thomas, Ben Greear, Eric W. Biederman, Herbert Xu,
Linux Netdev List, Netfilter Development Mailinglist
In-Reply-To: <4AEF0BAA.7050800@gmail.com>
Eric Dumazet wrote:
> Patrick McHardy a écrit :
>> But it would be preferrable if we could do this using network
>> namespaces somehow.
>
> eg eth0.100 and eth0.101 on namespace 1, eth0.200 and eth0.201 on namespace 2 ?
>
> Can we do that with current kernel ? (different vlans on an unique physical device)
By default the underlying device needs to exist in the same namespace
in which the VLAN device is created. I believe it should be possible
to move the VLAN device to a different namespace after creating it,
but I'm not sure about that.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RFC: netdev: allow ethtool physical id to drop rtnl_lock
From: Stephen Hemminger @ 2009-11-02 16:51 UTC (permalink / raw)
To: David Miller; +Cc: mchan, netdev
In-Reply-To: <20091102.001710.209808608.davem@davemloft.net>
On Mon, 02 Nov 2009 00:17:10 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: "Michael Chan" <mchan@broadcom.com>
> Date: Sat, 31 Oct 2009 09:44:22 -0700
>
> >
> > On Fri, 2009-10-30 at 10:42 -0700, Stephen Hemminger wrote:
> >> The ethtool operation to blink LED can take an indeterminately long time,
> >> blocking out other operations (via rtnl_lock). This patch is an attempt
> >> to work around the problem.
> >>
> >> It does need more discussion, because it will mean that drivers that formerly
> >> were protected from changes during blink aren't. For example, user could
> >> start device blinking, and then plug in cable causing change netlink event
> >> to change state or pull cable and have device come down.
> >
> > Yeah, the biggest concern is shutting down the device while it is still
> > blinking. During shutdown, some devices are brought to low power state
> > and the chip will no longer respond to I/Os to blink the LEDs. On some
> > systems, this can cause bus hang or NMI.
>
> Right, and for this reason we'll either need find some way to stop
> the LED blinking when the device is brought down.
>
> We can deal with this in a way such that we'll never need to bug
> the drivers again if we want to mess with the implementation again.
>
> Create a "netif_phys_id_loop_iter()" that, along with a netdev
> pointer, takes a "u32 data" which is whatever was passed in to
> ethtool_ops->id().
>
> The drivers then structure their loops like:
>
> while (1) {
> blink_it_baby();
> data = netif_phys_id_loop_iter(dev, data);
> if (!data)
> break;
> }
>
> Next, we take that:
>
> if (data == 0)
> data = UINT_MAX / 2;
>
> That every driver seems to do, and stick it in the ethtool op dispatch
> in net/core/ethtool.c so it doesn't need to be duplicated (and
> potentially forgotten) in every implementation.
>
> Finally, in netif_phys_id_loop_iter() we put something like:
>
> u32 netif_phys_id_loop_iter(struct netdev *dev, u32 data)
> {
> if (dev->reg_state == NETREG_UNREGISTERING)
> return 0;
> if (msleep_interruptible(500))
> return 0;
> return data - 2;
> }
>
> Then, unregister somehow blocks on the ->phys_id() hitting that
> NETREG_UNREGISTERING check and returning.
>
> Anyways, you get the idea.
For compatibility, I was thinking of adding a new ethtool hook that
moves the blinking loop into ethtool.
static int ethtool_phys_blink(struct net_device *dev, u32 secs)
{
while (secs > 0) {
dev->ethtool_ps->phys_led(dev, ETH_LED_ON);
...
dev->ethtool_ps->phys_led(dev, ETH_LED_OFF);
}
dev->ethtool_ops->phys_led(dev, ETH_LED_NORMAL);
}
static int ethtool_phys_id(struct net_device *dev, void __user *useraddr)
{
struct ethtool_value id;
if (copy_from_user(&id, useraddr, sizeof(id)))
return -EFAULT;
if (dev->ethtool_ops->phys_led)
return ethtool_phys_blink(dev, id.data);
if (dev->ethtool_ops->phys_id)
return dev->ethtool_ops->phys_id(dev, id.data);
else
return -EOPNOTSUPP;
}
--
^ permalink raw reply
* [PATCH] cnic: ensure ulp_type is not negative
From: Roel Kluin @ 2009-11-02 16:53 UTC (permalink / raw)
To: netdev, Andrew Morton, LKML, mchan
`ulp_type' is signed, make sure it is not negative
when we read the array element.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
drivers/net/cnic.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 3bf1b04..f384b0a 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -347,7 +347,7 @@ int cnic_register_driver(int ulp_type, struct cnic_ulp_ops *ulp_ops)
{
struct cnic_dev *dev;
- if (ulp_type >= MAX_CNIC_ULP_TYPE) {
+ if (ulp_type < 0 || ulp_type >= MAX_CNIC_ULP_TYPE) {
printk(KERN_ERR PFX "cnic_register_driver: Bad type %d\n",
ulp_type);
return -EINVAL;
@@ -393,7 +393,7 @@ int cnic_unregister_driver(int ulp_type)
struct cnic_ulp_ops *ulp_ops;
int i = 0;
- if (ulp_type >= MAX_CNIC_ULP_TYPE) {
+ if (ulp_type < 0 || ulp_type >= MAX_CNIC_ULP_TYPE) {
printk(KERN_ERR PFX "cnic_unregister_driver: Bad type %d\n",
ulp_type);
return -EINVAL;
@@ -449,7 +449,7 @@ static int cnic_register_device(struct cnic_dev *dev, int ulp_type,
struct cnic_local *cp = dev->cnic_priv;
struct cnic_ulp_ops *ulp_ops;
- if (ulp_type >= MAX_CNIC_ULP_TYPE) {
+ if (ulp_type < 0 || ulp_type >= MAX_CNIC_ULP_TYPE) {
printk(KERN_ERR PFX "cnic_register_device: Bad type %d\n",
ulp_type);
return -EINVAL;
@@ -490,7 +490,7 @@ static int cnic_unregister_device(struct cnic_dev *dev, int ulp_type)
struct cnic_local *cp = dev->cnic_priv;
int i = 0;
- if (ulp_type >= MAX_CNIC_ULP_TYPE) {
+ if (ulp_type < 0 || ulp_type >= MAX_CNIC_ULP_TYPE) {
printk(KERN_ERR PFX "cnic_unregister_device: Bad type %d\n",
ulp_type);
return -EINVAL;
^ permalink raw reply related
* Re: [RFC] bridge: check address size
From: Stephen Hemminger @ 2009-11-02 16:54 UTC (permalink / raw)
To: David Miller; +Cc: nneul, netdev
In-Reply-To: <20091102.000756.222203879.davem@davemloft.net>
On Mon, 02 Nov 2009 00:07:56 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 29 Oct 2009 15:24:08 -0700
>
> > - if (dev->flags & IFF_LOOPBACK || dev->type != ARPHRD_ETHER)
> > + /* Don't allow bridging non ethernet like devices */
> > + if (dev->flags & IFF_LOOPBACK
> > + || dev->type != ARPHRD_ETHER
> > + || dev->addr_len != ETH_ALEN)
>
> Please format this as:
>
> > + if (dev->flags & IFF_LOOPBACK ||
> > + dev->type != ARPHRD_ETHER ||
> > + dev->addr_len != ETH_ALEN)
>
> What you're doing in the patch follows the GNU coding standards, no
> the kernel ones. :-)
Sure, I never saw which side to put conditionals as part of coding standard document.
--
^ permalink raw reply
* Re: [net-next-2.6 PATCH v4 3/3] TCPCT part 1c: initial SYN exchange with SYNACK data
From: Joe Perches @ 2009-11-02 17:00 UTC (permalink / raw)
To: William Allen Simpson; +Cc: Eric Dumazet, Linux Kernel Network Developers
In-Reply-To: <4AEECFA8.1080306@gmail.com>
On Mon, 2009-11-02 at 07:25 -0500, William Allen Simpson wrote:
> For complex tests, this makes the code much more readable and easier to
> visually verify on code walk-through:
>
> + if (0 < tmp_opt.cookie_plus
> + && tmp_opt.saw_tstamp
> + && !tp->cookie_out_never
> + && (0 < sysctl_tcp_cookie_size
> + || (NULL != tp->cookie_values
> + && 0 < tp->cookie_values->cookie_desired))) {
>
> Consistent use of security style would have obviated a lot of foolish >= 0
> tests that seem to be constantly in need of fixing. It's a bad idea to
> depend on the compiler to catch non-executable code.
Linus wrote a long time back (5+ years):
The reason for "if (x == 8)" comes from the way we're taught to think.
Arguing against that _fact_ is just totally non-productive, and you have
to _force_ yourself to write it the other way around.
And that just means that you will do other mistakes. You'll spend your
time thinking about trying to express your conditionals in strange ways,
and then not think about the _real_ issue.
So let's make a few rules:
- write your logical expressions the way people EXPECT them to be
written. No silly rules that make no sense.
Ergo:
if (x == 8)
is the ONE AND ONLY SANE WAY.
- avoid using assignment inside logical expressions unless you have a
damn good reason to.
Ergo: write
error = myfunction(xxxx)
if (error) {
...
instead of writing
if (error = myfunction(xxxx))
....
which is just unreadable and stupid.
- Don't get hung about stupid rules.
Ergo: sometimes assignments in conditionals make sense, especially in
loops. Don't avoid them just because of some silly rule. But strive to
use an explicit equality test when you do so:
while ((a = function(b)) != 0)
...
is fine.
- The compiler warns about the mistakes that remain, if you follow these
rules.
- mistakes happen. Deal with it. Having tons of rules just makes them
more likely. Expect mistakes, and make sure they are fixed quickly
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: John W. Linville @ 2009-11-02 17:01 UTC (permalink / raw)
To: Ingo Molnar
Cc: Johannes Berg, Jarek Poplawski, Bartlomiej Zolnierkiewicz,
Pekka Enberg, David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091102100702.GA16963-X9Un+BFzKDI@public.gmane.org>
On Mon, Nov 02, 2009 at 11:07:02AM +0100, Ingo Molnar wrote:
>
> * Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
> > On Mon, 2009-11-02 at 10:10 +0100, Ingo Molnar wrote:
> >
> > > So i have read the thread you and Bartlomiej referenced:
> > >
> > > http://lkml.org/lkml/2009/10/17/81
> > >
> > > ... and my understanding of that discussion is very different from
> > > yours. Here is my annotated history of the beginnings of that
> > > discussion:
> >
> > [snip]
> >
> > You shouldn't ignore all previous interaction between Bart and us --
> > which wasn't pretty: http://thread.gmane.org/gmane.linux.kernel/901892
>
> I have seen that exchange too - here's the lkml.org link for those who
> like the lkml.org format:
>
> http://lkml.org/lkml/2009/10/13/186
>
> And i can see no supporting fact here either, for the (very serious)
> accusation launched by John Linville, that Bartlomiej is 'petty,
> whining, indignant'. In my reading he is the opposite of that, even in
> this second thread you point out.
Again, you seem to be very generous to Bartlomiej and very critical of
the rest of us in your readings.
> So, no matter how much you disagree about the code and its direction,
> please either back up your assertion with specific links to a pattern of
> misbehavior or apologize for the ad-hominen attacks against Bartlomiej.
His behavior is evident in the threads you cited. How you do not
see that is a mystery.
> > Of course we were biased when he came around with that petty code
> > duplication argument, since it seemed to support only his agenda of
> > working only with the staging drivers.
>
> Why do you think that disagreeing in the past gives you the right to get
> into ad-hominens? You should concentrate on the code and on the
> technical side, not on the person making the argument.
>
> Also, why do you characterise a code duplication argument as 'petty'?
Did you actually look at the thread? Or did you simply here "code
duplication" and run with it?
> Bloat and unnecessary technical forking is the #1 enemy of Linux.
> Integrating code and infrastructure is the #1 strength of Linux.
>
> Upstream subsystems/drivers running away with their private
> implementations has its clear costs:
...which has nothing to do with the case at hand. Please do not
perpetuate this myth. If anything, your argument applies far more
to the drivers in staging that Bartlomiej has focused his attention
upon until recently.
<snip>
> [ I dont know why drivers/staging/ is even an argument here - he argued
> about the technical qualities of a new upstream driver, not about a
> staging driver. Upstream drivers are to be held to higher standards,
> _especially_ now that we can isolate not-clean-enough-yet drivers into
> drivers/staging/, without hurting users. ]
If you had been keeping-up, you would realize that Bartlomiej is upset
about our criticisms of the Ralink drivers in staging. That would seem
to be the reason he has made himself such an irritant in linux-wireless
over the past few weeks.
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Connection tracking and vlan
From: Eric W. Biederman @ 2009-11-02 17:02 UTC (permalink / raw)
To: Patrick McHardy
Cc: Eric Dumazet, Adayadil Thomas, Ben Greear, Herbert Xu,
Linux Netdev List, Netfilter Development Mailinglist
In-Reply-To: <4AEF0D69.7070205@trash.net>
Patrick McHardy <kaber@trash.net> writes:
> Eric Dumazet wrote:
>> Patrick McHardy a écrit :
>>> But it would be preferrable if we could do this using network
>>> namespaces somehow.
>>
>> eg eth0.100 and eth0.101 on namespace 1, eth0.200 and eth0.201 on namespace 2 ?
>>
>> Can we do that with current kernel ? (different vlans on an unique physical device)
>
> By default the underlying device needs to exist in the same namespace
> in which the VLAN device is created. I believe it should be possible
> to move the VLAN device to a different namespace after creating it,
> but I'm not sure about that.
There should be no problem moving the vlan device after it is created.
Eric
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next-2.6 PATCH v4 3/3] TCPCT part 1c: initial SYN exchange with SYNACK data
From: Eric Dumazet @ 2009-11-02 17:04 UTC (permalink / raw)
To: William Allen Simpson; +Cc: Linux Kernel Network Developers, Ilpo Järvinen
In-Reply-To: <4AEF0603.7060502@gmail.com>
William Allen Simpson a écrit :
> It will be, when we have running code, as I'm loath to publish until I'm
> certain it *can* be implemented.
This is why RFC is better before coding. To avoid wasting time on experiments
that have a fatal flaw. Once included in an official kernel, we wont be able
to change some parameters very easily (think about 253 constant you use)
Or do you think only *you* can understand what's going on, and we should
just trust you ?
>
> I've something like 40 RFCs published over the years.
I believe I know who you are, Mr William Allen Simpson, you dont need to
repeat how much work you did in the past. This is a bit annoying.
Some patches need 6-12 months of polishing before inclusion, there is nothing
wrong about it. It only depends on your cooperation and patience.
And yes, even if a patch comes from Linus Torvald himself, I can talk if
it does not please me.
SYNFLOOD problem is more than 13 years old, I am quite surprised its becoming
so urgent we should accept your patches "as is".
May I suggest to switch to normal mode, ie you prepare a next round of
patches, you submit them, we review them, [repeat 0-N time(s)], we Ack them ?
^ permalink raw reply
* Re: [net-next-2.6 PATCH RFC] TCPCT part 1d: generate Responder Cookie
From: William Allen Simpson @ 2009-11-02 17:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Developers, Linux Kernel Network Developers
In-Reply-To: <4AEEDBBC.40800@gmail.com>
Eric Dumazet wrote:
> Large part of network code is run by softirq handler, and a softirq handler
> is not preemptable with another softirq (including itself).
>
Thank you. That's helpful to know, as some existing locks have a "bh".
I've never figured out the ip_local_deliver_finish() context.
Knowing that there can only be one instance of the tcp stack running at
any one time, and the cpu never changes even after being interrupted, will
make it much easier to code.
>> Perhaps a function header comment that mentions it?
>
> So we are going to add a header to thousand of functions repeating this prereq ?
>
That's my usual practice. (Dozens would be more accurate in this case.)
I've always found it helpful for those coming after me, and sure would have
found it helpful now myself.... Repetitious, but well worth it.
Especially at tcp_v4_rcv(), as that's called through a vector named
"handler", which was particularly hard to track down.
It has an innocuous header "From tcp_input.c", that doesn't seem to have
anything to do with current reality.... (It's really called from
ip_input.c via af_inet.c).
>> All I know is (from testing) that the tcp_minisockets.c caller is sometimes
>> called in a fashion that requires atomic allocation, and other times
>> does not!
>
> Maybe callers have different contexts (running from softirq handler or
> from process context). Atomic ops are expensive and we try to avoid them
> if/when possible.
>
>> See my "Subject: query: tcpdump versus atomic?" thread from Oct 14th.
>
> You probably add a bug in your kernel, leaving a function with unpaired lock/unlock
> of notallow_something/allow_something
>
(No, I've not yet added locks; obviously, I'm still asking about them.)
Unlikely, as it was easy to reproduce by changing one line, without *any* of
my code present. Usually works, but doesn't work with tcpdump running on
the interface:
struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req, struct sk_buff *skb)
{
- struct sock *newsk = inet_csk_clone(sk, req, GFP_ATOMIC);
+ struct sock *newsk = inet_csk_clone(sk, req, GFP_KERNEL);
if (newsk != NULL) {
[ 2.876485] eth0: RealTek RTL8139 at 0x2000, 00:40:2b:6b:61:36, IRQ 17
[ 2.876490] eth0: Identified 8139 chip type 'RTL-8101'
[ 88.997594] device eth0 entered promiscuous mode
[ 114.827403] BUG: scheduling while atomic: swapper/0/0x10000100
[ 114.827462] Modules linked in: lp snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd ppdev iTCO_wdt iTCO_vendor_support psmouse soundcore parport_pc intel_agp parport agpgart pcspkr serio_raw shpchp snd_page_alloc 8139too aic7xxx 8139cp
scsi_transport_spi mii floppy
[ 114.827493]
[ 114.827497] Pid: 0, comm: swapper Not tainted (2.6.32-rc3 #4) Imperial
[ 114.827501] EIP: 0060:[<c0123295>] EFLAGS: 00000246 CPU: 0
[ 114.827512] EIP is at native_safe_halt+0x5/0x10
[ 114.827515] EAX: c0740000 EBX: 00000000 ECX: ffff4b6e EDX: 00000000
[ 114.827519] ESI: c07992c0 EDI: c0743000 EBP: c0741fa0 ESP: c0741fa0
[ 114.827522] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 114.827525] CR0: 8005003b CR2: 09278fc4 CR3: 04b56000 CR4: 00000690
[ 114.827529] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 114.827532] DR6: ffff0ff0 DR7: 00000400
[ 114.827535] Call Trace:
[ 114.827546] [<c01098b5>] default_idle+0x65/0x90
[ 114.827550] [<c0102062>] cpu_idle+0x52/0x90
[ 114.827558] [<c056cc23>] rest_init+0x53/0x60
[ 114.827565] [<c079c93d>] start_kernel+0x328/0x390
[ 114.827569] [<c079c3ce>] ? unknown_bootoption+0x0/0x1f6
[ 114.827574] [<c079c07e>] i386_start_kernel+0x7e/0xa8
[ 136.570632] device eth0 left promiscuous mode
> There are books about linux internals that you could read if you want some extra
> documentation. Dont ask me details, I never read them :)
>
Sorry, I've only read much of the Documentation directory (some parts
repeatedly), and Googled for more specific information. Pretty sparse!
Thank you again for your patient explanation.
^ permalink raw reply
* [PATCHv2] tun: export underlying socket
From: Michael S. Tsirkin @ 2009-11-02 17:20 UTC (permalink / raw)
To: David Miller, Eric Dumazet; +Cc: Paul Moore, netdev, herbert
In-Reply-To: <20090910125929.GA32593@redhat.com>
Tun device looks similar to a packet socket
in that both pass complete frames from/to userspace.
This patch fills in enough fields in the socket underlying tun driver
to support sendmsg/recvmsg operations, and message flags
MSG_TRUNC and MSG_DONTWAIT, and exports access to this socket
to modules. Regular read/write behaviour is unchanged.
This way, code using raw sockets to inject packets
into a physical device, can support injecting
packets into host network stack almost without modification.
First user of this interface will be vhost virtualization
accelerator.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
Changes from v1:
addressed comments from review
This patch is on top of net-next master.
vhost which is the first user of this interface is intended to be merged
through Rusty's virtio tree, so I think it's easiest to merge this patch
trough that tree, as well, as part of the vhost patchset.
Makes sense? Please comment.
Usage example in vhost is here:
http://git.kernel.org/?p=linux/kernel/git/mst/vhost.git;a=commitdiff;h=030c5e25539e8fb14ca9130621710b7a006f3c1c
An alternative approach would be to make sendmsg work on tun fd from
userspace as well as from kernel: a uniform way to work with a network
device and the host stack might be useful there, as well. Kernel users
could then do sockfd_lookup to get the socket. I decided against it for
now as it requires more code and touches net core.
Please comment.
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 4fdfa2a..18f8876 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -144,6 +144,7 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
err = 0;
tfile->tun = tun;
tun->tfile = tfile;
+ tun->socket.file = file;
dev_hold(tun->dev);
sock_hold(tun->socket.sk);
atomic_inc(&tfile->count);
@@ -158,6 +159,7 @@ static void __tun_detach(struct tun_struct *tun)
/* Detach from net device */
netif_tx_lock_bh(tun->dev);
tun->tfile = NULL;
+ tun->socket.file = NULL;
netif_tx_unlock_bh(tun->dev);
/* Drop read queue */
@@ -387,7 +389,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
/* Notify and wake up reader process */
if (tun->flags & TUN_FASYNC)
kill_fasync(&tun->fasync, SIGIO, POLL_IN);
- wake_up_interruptible(&tun->socket.wait);
+ wake_up_interruptible_poll(&tun->socket.wait, POLLIN |
+ POLLRDNORM | POLLRDBAND);
return NETDEV_TX_OK;
drop:
@@ -743,7 +746,7 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
len = min_t(int, skb->len, len);
skb_copy_datagram_const_iovec(skb, 0, iv, total, len);
- total += len;
+ total += skb->len;
tun->dev->stats.tx_packets++;
tun->dev->stats.tx_bytes += len;
@@ -751,34 +754,23 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
return total;
}
-static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
- unsigned long count, loff_t pos)
+static ssize_t tun_do_read(struct tun_struct *tun,
+ struct kiocb *iocb, const struct iovec *iv,
+ ssize_t len, int noblock)
{
- struct file *file = iocb->ki_filp;
- struct tun_file *tfile = file->private_data;
- struct tun_struct *tun = __tun_get(tfile);
DECLARE_WAITQUEUE(wait, current);
struct sk_buff *skb;
- ssize_t len, ret = 0;
-
- if (!tun)
- return -EBADFD;
+ ssize_t ret = 0;
DBG(KERN_INFO "%s: tun_chr_read\n", tun->dev->name);
- len = iov_length(iv, count);
- if (len < 0) {
- ret = -EINVAL;
- goto out;
- }
-
add_wait_queue(&tun->socket.wait, &wait);
while (len) {
current->state = TASK_INTERRUPTIBLE;
/* Read frames from the queue */
if (!(skb=skb_dequeue(&tun->socket.sk->sk_receive_queue))) {
- if (file->f_flags & O_NONBLOCK) {
+ if (noblock) {
ret = -EAGAIN;
break;
}
@@ -805,6 +797,27 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
current->state = TASK_RUNNING;
remove_wait_queue(&tun->socket.wait, &wait);
+ return ret;
+}
+
+static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
+ unsigned long count, loff_t pos)
+{
+ struct file *file = iocb->ki_filp;
+ struct tun_file *tfile = file->private_data;
+ struct tun_struct *tun = __tun_get(tfile);
+ ssize_t len, ret;
+
+ if (!tun)
+ return -EBADFD;
+ len = iov_length(iv, count);
+ if (len < 0) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ ret = tun_do_read(tun, iocb, iv, len, file->f_flags & O_NONBLOCK);
+ ret = min_t(ssize_t, ret, len);
out:
tun_put(tun);
return ret;
@@ -847,7 +860,8 @@ static void tun_sock_write_space(struct sock *sk)
return;
if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
- wake_up_interruptible_sync(sk->sk_sleep);
+ wake_up_interruptible_sync_poll(sk->sk_sleep, POLLOUT |
+ POLLWRNORM | POLLWRBAND);
tun = container_of(sk, struct tun_sock, sk)->tun;
kill_fasync(&tun->fasync, SIGIO, POLL_OUT);
@@ -858,6 +872,37 @@ static void tun_sock_destruct(struct sock *sk)
free_netdev(container_of(sk, struct tun_sock, sk)->tun->dev);
}
+static int tun_sendmsg(struct kiocb *iocb, struct socket *sock,
+ struct msghdr *m, size_t total_len)
+{
+ struct tun_struct *tun = container_of(sock, struct tun_struct, socket);
+ return tun_get_user(tun, m->msg_iov, total_len,
+ m->msg_flags & MSG_DONTWAIT);
+}
+
+static int tun_recvmsg(struct kiocb *iocb, struct socket *sock,
+ struct msghdr *m, size_t total_len,
+ int flags)
+{
+ struct tun_struct *tun = container_of(sock, struct tun_struct, socket);
+ int ret;
+ if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
+ return -EINVAL;
+ ret = tun_do_read(tun, iocb, m->msg_iov, total_len,
+ flags & MSG_DONTWAIT);
+ if (ret > total_len) {
+ m->msg_flags |= MSG_TRUNC;
+ ret = flags & MSG_TRUNC ? ret : total_len;
+ }
+ return ret;
+}
+
+/* Ops structure to mimic raw sockets with tun */
+static const struct proto_ops tun_socket_ops = {
+ .sendmsg = tun_sendmsg,
+ .recvmsg = tun_recvmsg,
+};
+
static struct proto tun_proto = {
.name = "tun",
.owner = THIS_MODULE,
@@ -986,6 +1031,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
goto err_free_dev;
init_waitqueue_head(&tun->socket.wait);
+ tun->socket.ops = &tun_socket_ops;
sock_init_data(&tun->socket, sk);
sk->sk_write_space = tun_sock_write_space;
sk->sk_sndbuf = INT_MAX;
@@ -1489,6 +1535,23 @@ static void tun_cleanup(void)
rtnl_link_unregister(&tun_link_ops);
}
+/* Get an underlying socket object from tun file. Returns error unless file is
+ * attached to a device. The returned object works like a packet socket, it
+ * can be used for sock_sendmsg/sock_recvmsg. The caller is responsible for
+ * holding a reference to the file for as long as the socket is in use. */
+struct socket *tun_get_socket(struct file *file)
+{
+ struct tun_struct *tun;
+ if (file->f_op != &tun_fops)
+ return ERR_PTR(-EINVAL);
+ tun = tun_get(file);
+ if (!tun)
+ return ERR_PTR(-EBADFD);
+ tun_put(tun);
+ return &tun->socket;
+}
+EXPORT_SYMBOL_GPL(tun_get_socket);
+
module_init(tun_init);
module_exit(tun_cleanup);
MODULE_DESCRIPTION(DRV_DESCRIPTION);
diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h
index 3f5fd52..404abe0 100644
--- a/include/linux/if_tun.h
+++ b/include/linux/if_tun.h
@@ -86,4 +86,18 @@ struct tun_filter {
__u8 addr[0][ETH_ALEN];
};
+#ifdef __KERNEL__
+#if defined(CONFIG_TUN) || defined(CONFIG_TUN_MODULE)
+struct socket *tun_get_socket(struct file *);
+#else
+#include <linux/err.h>
+#include <linux/errno.h>
+struct file;
+struct socket;
+static inline struct socket *tun_get_socket(struct file *f)
+{
+ return ERR_PTR(-EINVAL);
+}
+#endif /* CONFIG_TUN */
+#endif /* __KERNEL__ */
#endif /* __IF_TUN_H */
^ permalink raw reply related
* Re: pull request: wireless-next-2.6 2009-10-28
From: Luis Correia @ 2009-11-02 17:32 UTC (permalink / raw)
To: John W. Linville
Cc: Ingo Molnar, Johannes Berg, Jarek Poplawski,
Bartlomiej Zolnierkiewicz, Pekka Enberg, David Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20091102170114.GE14046@tuxdriver.com>
[huge snip]
This is going to be my last reply to this thread (even if I get to be insulted).
I'm not a coder, I'm a tester and administrator for the rt2x00 project.
I'm not happy about the current state of the rt2x00 in-kernel drivers.
I tend to agree that more could be done.
Even though I'm not a coder, I could be hipotetically responsable for
the current situation. It is my job function to motivate people to
work on the rt2x00 in-kernel drivers, but apparently I've failed here.
It's not an atitude problem, as some have suggested, it's just life.
About Bartlomiej, there is only one more thing that I'll say:
I've searched on my GMail archives and the only patch Bart has
provided so far for the rt2x00 project is this:
[PATCH] MAINTAINERS: rt2x00 list is moderated
Which, while technically correct, adds nothing to the project.
So, I will personally continue to ignore Bart's comments, regards and
rants, until he provides patches for rt2x00 that actually make the
driver better.
Luis Correia
rt2x00 project admin,
(but not writing this email as an official project statement)
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Randy Dunlap @ 2009-11-02 17:36 UTC (permalink / raw)
To: Luis Correia
Cc: John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Bartlomiej Zolnierkiewicz, Pekka Enberg, David Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <efe7343f0911020932l21a570c8u9478568329d38e2c@mail.gmail.com>
Luis Correia wrote:
> [huge snip]
>
> This is going to be my last reply to this thread (even if I get to be insulted).
>
> I'm not a coder, I'm a tester and administrator for the rt2x00 project.
> I'm not happy about the current state of the rt2x00 in-kernel drivers.
> I tend to agree that more could be done.
>
> Even though I'm not a coder, I could be hipotetically responsable for
> the current situation. It is my job function to motivate people to
> work on the rt2x00 in-kernel drivers, but apparently I've failed here.
> It's not an atitude problem, as some have suggested, it's just life.
>
> About Bartlomiej, there is only one more thing that I'll say:
>
> I've searched on my GMail archives and the only patch Bart has
> provided so far for the rt2x00 project is this:
>
> [PATCH] MAINTAINERS: rt2x00 list is moderated
>
> Which, while technically correct, adds nothing to the project.
whatever. That patch still needs to be applied.
> So, I will personally continue to ignore Bart's comments, regards and
> rants, until he provides patches for rt2x00 that actually make the
> driver better.
>
> Luis Correia
> rt2x00 project admin,
> (but not writing this email as an official project statement)
--
~Randy
^ permalink raw reply
* Re: [net-next-2.6 PATCH RFC] TCPCT part 1d: generate Responder Cookie
From: Eric Dumazet @ 2009-11-02 17:42 UTC (permalink / raw)
To: William Allen Simpson
Cc: Linux Kernel Developers, Linux Kernel Network Developers
In-Reply-To: <4AEF1534.4090506@gmail.com>
William Allen Simpson a écrit :
> Eric Dumazet wrote:
>> Large part of network code is run by softirq handler, and a softirq
>> handler
>> is not preemptable with another softirq (including itself).
>>
> Thank you. That's helpful to know, as some existing locks have a "bh".
> I've never figured out the ip_local_deliver_finish() context.
>
> Knowing that there can only be one instance of the tcp stack running at
> any one time, and the cpu never changes even after being interrupted, will
> make it much easier to code.
Correction :
There is one instance of sofirq handler running per cpu.
So TCP (or UDP) stack can run simultaneously on several (and eventually all online) cpus.
This is why we still need some locks in various places.
>>
> (No, I've not yet added locks; obviously, I'm still asking about them.)
>
> Unlikely, as it was easy to reproduce by changing one line, without
> *any* of
> my code present. Usually works, but doesn't work with tcpdump running on
> the interface:
Yes, tcpdump has the nasty habit to consume a lot of ram, queuing a copy of
all network traffic on an af_packet socket. (or using a mmap buffer, it depends
on libpcap version you use)
>
> struct sock *tcp_create_openreq_child(struct sock *sk, struct
> request_sock *req, struct sk_buff *skb)
> {
> - struct sock *newsk = inet_csk_clone(sk, req, GFP_ATOMIC);
> + struct sock *newsk = inet_csk_clone(sk, req, GFP_KERNEL);
Here you want a GFP_KERNEL allocation, that is allowed to sleep if there is not
enough available memory. (It's allowed to sleep to let some processes to free
bit of ram, eventually)
But as the caller of tcp_create_openreq_child() runs from {soft}irq context,
its not allowed to sleep at all, even 10 usecs.
Therefore, linux kernel kindly warns you that's its illegal and deadlockable.
Dont change GFP_ATOMIC here, its really there for a valid reason.
And be prepared to get a NULL result from allocation.
If your machine has problems when running tcpdump, maybe it lacks some ram, maybe you could
tune tcpdump socket to not exhaust all LOWMEM.
I see your kernel is 32bits, so you have only 860 MB of kernel memory, called LOWMEM.
I believe last kernels might have some problems in OOM situations...
^ permalink raw reply
* Re: [net-next-2.6 PATCH v4 3/3] TCPCT part 1c: initial SYN exchange with SYNACK data
From: William Allen Simpson @ 2009-11-02 17:50 UTC (permalink / raw)
To: Joe Perches; +Cc: Eric Dumazet, Linux Kernel Network Developers
In-Reply-To: <1257181219.28925.13.camel@Joe-Laptop.home>
Joe Perches wrote:
> Linus wrote a long time back (5+ years):
>
> The reason for "if (x == 8)" comes from the way we're taught to think.
> Arguing against that _fact_ is just totally non-productive, and you have
> to _force_ yourself to write it the other way around.
>
Interesting. I've not been able to Google this quote.
I actually think as I write it, finding the other ragged and hard to
visually review. But apparently it's an issue for ESL or something,
taught to think in another way.
Therefore, I'll re-code as Linus has prescribed. Sadly, I'm having
very bad luck verifying coding examples by checking against the
installed base, as I found thousands of lines following more usual
secure coding practices....
Thank you.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v4 2/3] TCPCT part 1b: sysctl_tcp_cookie_size, socket option TCP_COOKIE_TRANSACTIONS, functions
From: William Allen Simpson @ 2009-11-02 17:54 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20091102.025150.73299764.davem@davemloft.net>
David Miller wrote:
> Yes, it is a problem.
>
> You can allocate the bit when you add the feature.
>
Sadly, I've been having very bad luck in my choice of code base, and
reviewing other similar code -- it seemed the common practice was to
specify the interface completely (even those bits not yet used).
I'll remove that line in the next pass.
^ permalink raw reply
* Re: [PATCH] cnic: ensure ulp_type is not negative
From: Michael Chan @ 2009-11-02 17:56 UTC (permalink / raw)
To: Roel Kluin; +Cc: netdev@vger.kernel.org, Andrew Morton, LKML, davem
In-Reply-To: <4AEF0E98.5050304@gmail.com>
On Mon, 2009-11-02 at 08:53 -0800, Roel Kluin wrote:
> `ulp_type' is signed, make sure it is not negative
> when we read the array element.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Looks good to me. Thanks.
Acked-by: Michael Chan <mchan@broadcom.com>
> ---
> drivers/net/cnic.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
> index 3bf1b04..f384b0a 100644
> --- a/drivers/net/cnic.c
> +++ b/drivers/net/cnic.c
> @@ -347,7 +347,7 @@ int cnic_register_driver(int ulp_type, struct cnic_ulp_ops *ulp_ops)
> {
> struct cnic_dev *dev;
>
> - if (ulp_type >= MAX_CNIC_ULP_TYPE) {
> + if (ulp_type < 0 || ulp_type >= MAX_CNIC_ULP_TYPE) {
> printk(KERN_ERR PFX "cnic_register_driver: Bad type %d\n",
> ulp_type);
> return -EINVAL;
> @@ -393,7 +393,7 @@ int cnic_unregister_driver(int ulp_type)
> struct cnic_ulp_ops *ulp_ops;
> int i = 0;
>
> - if (ulp_type >= MAX_CNIC_ULP_TYPE) {
> + if (ulp_type < 0 || ulp_type >= MAX_CNIC_ULP_TYPE) {
> printk(KERN_ERR PFX "cnic_unregister_driver: Bad type %d\n",
> ulp_type);
> return -EINVAL;
> @@ -449,7 +449,7 @@ static int cnic_register_device(struct cnic_dev *dev, int ulp_type,
> struct cnic_local *cp = dev->cnic_priv;
> struct cnic_ulp_ops *ulp_ops;
>
> - if (ulp_type >= MAX_CNIC_ULP_TYPE) {
> + if (ulp_type < 0 || ulp_type >= MAX_CNIC_ULP_TYPE) {
> printk(KERN_ERR PFX "cnic_register_device: Bad type %d\n",
> ulp_type);
> return -EINVAL;
> @@ -490,7 +490,7 @@ static int cnic_unregister_device(struct cnic_dev *dev, int ulp_type)
> struct cnic_local *cp = dev->cnic_priv;
> int i = 0;
>
> - if (ulp_type >= MAX_CNIC_ULP_TYPE) {
> + if (ulp_type < 0 || ulp_type >= MAX_CNIC_ULP_TYPE) {
> printk(KERN_ERR PFX "cnic_unregister_device: Bad type %d\n",
> ulp_type);
> return -EINVAL;
>
^ permalink raw reply
* Re: [net-next-2.6 PATCH v4 3/3] TCPCT part 1c: initial SYN exchange with SYNACK data
From: William Allen Simpson @ 2009-11-02 18:10 UTC (permalink / raw)
To: Linux Kernel Network Developers
Cc: Ilpo Järvinen, Eric Dumazet, Joe Perches
In-Reply-To: <4AE6E7C0.2050408@gmail.com>
Another style question:
+struct tcp_extend_values {
+ u8 cookie_bakery[TCP_COOKIE_MAX];
+ u8 cookie_plus;
+ u8 cookie_in_always:1,
+ cookie_out_never:1;
+};
+
+static inline struct tcp_extend_values *tcp_xv(const struct request_values *rvp)
+{
+ return (struct tcp_extend_values *)rvp;
+}
Some examples have "struct request_values" as the first element, others
don't. I started with it, and then removed it (as essentially nil).
Is there a preference?
^ permalink raw reply
* Re: [net-next-2.6 PATCH v4 3/3] TCPCT part 1c: initial SYN exchange with SYNACK data
From: Joe Perches @ 2009-11-02 18:16 UTC (permalink / raw)
To: William Allen Simpson
Cc: Linux Kernel Network Developers, Ilpo Järvinen, Eric Dumazet
In-Reply-To: <4AEF207C.9030002@gmail.com>
On Mon, 2009-11-02 at 13:10 -0500, William Allen Simpson wrote:
> Another style question:
>
> +struct tcp_extend_values {
> + u8 cookie_bakery[TCP_COOKIE_MAX];
> + u8 cookie_plus;
> + u8 cookie_in_always:1,
> + cookie_out_never:1;
> +};
> +
> +static inline struct tcp_extend_values *tcp_xv(const struct request_values *rvp)
> +{
> + return (struct tcp_extend_values *)rvp;
> +}
>
> Some examples have "struct request_values" as the first element, others
> don't. I started with it, and then removed it (as essentially nil).
>
> Is there a preference?
I don't know, but I do have a bias against casting
const to non-const.
cheers, Joe
^ permalink raw reply
* Re: [PATCH] Multicast packet reassembly can fail
From: Steve Chen @ 2009-11-02 18:36 UTC (permalink / raw)
To: Herbert Xu; +Cc: rick.jones2, mhuth, David Stevens, Eric Dumazet, netdev
In-Reply-To: <20091029180450.GA31044@gondor.apana.org.au>
On Thu, 2009-10-29 at 14:04 -0400, Herbert Xu wrote:
> Steve Chen <schen@mvista.com> wrote:
> >
> > of the interface that the application is expecting the packet. It
> > appears to bind on interface based on that casual observation. I'll
> > have to study the code in detail to be able to say for sure.
>
> Well if it does bind to the interface then that explains the
> failure. And the fix is "if it hurts, don't do it" :)
>
> Cheers,
The packet drop was tracked to rp_filter. All packets received as
expected after disabling rp_filter. Thank you all for the inputs.
Regards,
Steve
^ permalink raw reply
* Re: RFC: netdev: allow ethtool physical id to drop rtnl_lock
From: Ben Hutchings @ 2009-11-02 18:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, mchan, netdev
In-Reply-To: <20091102085121.7416fa8f@nehalam>
On Mon, 2009-11-02 at 08:51 -0800, Stephen Hemminger wrote:
[...]
> For compatibility, I was thinking of adding a new ethtool hook that
> moves the blinking loop into ethtool.
>
> static int ethtool_phys_blink(struct net_device *dev, u32 secs)
> {
> while (secs > 0) {
> dev->ethtool_ps->phys_led(dev, ETH_LED_ON);
> ...
> dev->ethtool_ps->phys_led(dev, ETH_LED_OFF);
> }
> dev->ethtool_ops->phys_led(dev, ETH_LED_NORMAL);
> }
[...]
We could even force this on unconverted drivers, but using a longer
loop period to allow for slow blinking:
static int ethtool_phys_id_loop(struct net_device *dev, u32 secs)
{
u32 timeout;
int rc;
for (;;) {
timeout = min_t(u32, secs, 5);
secs -= timeout;
rc = dev->ethtool_ops->phys_id(dev, timeout);
if (rc || secs == 0)
return rc;
...
}
}
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: John W. Linville @ 2009-11-02 18:29 UTC (permalink / raw)
To: Randy Dunlap
Cc: Luis Correia, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Bartlomiej Zolnierkiewicz, Pekka Enberg, David Miller,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4AEF1894.2010809-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>
On Mon, Nov 02, 2009 at 09:36:20AM -0800, Randy Dunlap wrote:
> Luis Correia wrote:
> > [huge snip]
> >
> > This is going to be my last reply to this thread (even if I get to be insulted).
> >
> > I'm not a coder, I'm a tester and administrator for the rt2x00 project.
> > I'm not happy about the current state of the rt2x00 in-kernel drivers.
> > I tend to agree that more could be done.
> >
> > Even though I'm not a coder, I could be hipotetically responsable for
> > the current situation. It is my job function to motivate people to
> > work on the rt2x00 in-kernel drivers, but apparently I've failed here.
> > It's not an atitude problem, as some have suggested, it's just life.
> >
> > About Bartlomiej, there is only one more thing that I'll say:
> >
> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> >
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> >
> > Which, while technically correct, adds nothing to the project.
>
> whatever. That patch still needs to be applied.
And, in fact, it has been...already in linux-2.6:
commit b5654f5e7fc414a6e69b3647db2b043257c9e62e
Author: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Mon Oct 26 16:49:50 2009 -0700
MAINTAINERS: rt2x00 list is moderated
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Signed-off-by: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Hth...
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Ivo van Doorn @ 2009-11-02 18:43 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Randy Dunlap, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Bartlomiej Zolnierkiewicz,
Pekka Enberg, David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4AEF1894.2010809-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>
Well and then another rt2x00 developer discovered this nice little
fight about rt2x00 on the mailinglists...
First for the record, because at the start people where talking about the
maintainership of rt2x00, one thing needs to be straight:
As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
drivers/net/wireless/rt2x00 folder.
At this time I am hold the position within the rt2x00 team which is making the
decisions about the rt2x00 code and design.
I am also the one that is (N)Acks the patches from others when they are send
to the rt2x00-users or linux-wireless mailinglist.
As for my behavior in discussions:
I am doing my best to listen to all complains regarding the rt2x00 code and design and
improve it if the complainer has a valid point. However, obviously I can disagree with
the complainer and in that case I will explain to that person _why_ I disagree. It is up
to the complainer to convince me that he is right, agree with my response, or whine.
Now as for more specific responses:
On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> rt2800 drivers have their maintainers and I would like to know what they
> are doing besides complaining about users and staging tree..
Working for Avanade, Zarafa and as freelancer for Linux Magazine.
But I guess you mean rt2x00 specific work?
Well that list consists of:
- Listening to people complain
- Responding to those people, because otherwise they complain that they are being ignored.
- Following bug reports, and request testing or additional information if required
- Bugfixing
- Reviewing patches from contributors
- Applying patches from contributors
- Discussing improvements over patches from contributors
Well nothing of this list should be new to you, but apparently you needed some confirmation.
On Thursday 29 October 2009, Johannes Berg wrote:
> On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
>
> > In case you're concerned, I actually agree with John and others
> > on this issue, and disagree with your position.
>
> In this particular case, I think it makes more sense to duplicate the
> code _especially_ because it's not working yet. That frees people
> hacking on it of having to worry about breaking other devices.
Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
in the previous discussion.
On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> I find it rather disappointing that all my review comments regarding
> rt2800pci support were just completely ignored and then the initial
> patch was merged just as it was..
Your code review comments were commented upon with my reasons
why this code duplication exists. I even admitted that when the time is
ready I will remove the code duplication.
On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
The review concerns regarding the duplicate code would only reduce the
amount of code. It would not magically fix bugs (at least the chance of that
would be quite small).
So far rt2800usb performs better then rt2800pci, and the difference gets
only bigger when I use the exact same register initialization from rt2800usb
in rt2800pci.
But Bartjmoiej knows that the register initialization can be exactly the same,
from his experience with the staging drivers.
So far hasn't been interested in sharing the knowledge in what must be
changed in rt2800pci/usb to make them both work with the same register
initialization.
On Monday 02 November 2009, Randy Dunlap wrote:
> Luis Correia wrote:
> > [huge snip]
> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> >
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> >
> > Which, while technically correct, adds nothing to the project.
>
> whatever. That patch still needs to be applied.
And I haven't seen anybody stating the opposite...
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox