* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 21:31 UTC (permalink / raw)
To: Thomas Graf; +Cc: kaber, netdev, David Miller
In-Reply-To: <20060630211043.GO14627@postel.suug.ch>
On Fri, 2006-30-06 at 23:10 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-30 16:54
> > I agree - and i try hard to document but at times there's too much
> > and a line needs to be drawn.
> > As an example:
> > the eth->ifb->ifb case though is a very corner case. All the IMQ types
> > need to only redirect to one ifb; while i test it ive always seen the
> > test as more of a boundary check than a useful setup.
>
> Maybe you should just start by explaining why it doesn't work,
> your original explanation doesn't make much sense.
>
Better to explain the reason for ifb first:
ifb exists initially as a replacement for IMQ.
1) qdiscs/policies that are per device as opposed to system wide.
This now allows for sharing.
2) Allows for queueing incoming traffic for shaping instead of
dropping.
In other wise, the main use is for multiple devices to redirect to it.
Main desire is not for it to redirect to any other ifb device or eth
devices. I actually tried to get it to do that, but run into issues
of complexity and and came up with decision to drop instead of killing
the machine.
Other than that, it can redirect to any other devices - but may still
not be meaningful.
I have been thinking of Herberts change of qdisc_is_running and this may
help actually.
> > And Thomas: I do keep notebooks ;-> I doodle about everything, they dont
> > all fit in my knapsack anymore so sometimes when i say i will go and
> > refer to my notes, it is real.
>
> It's plain arrogant to rely code understanding on information that
> is not available to others. It makes everyone being dependant on
> you, very nice.
>
I try hard to document more than many many people. I give tutorials, I
write papers when time allows, I spend time responding to emails. And i
do it all for the love of the game.
But lets look at the other side of the coin:
Dont you think it is polite to ask when something is not clear instead
of making assumptions?
> To put it in another way, if you would do your job right when
> writing the code, contacting or CCing you upon changes would
> be only of a formal matter since the code is understandable and
> the intent is clear or documented.
I wish I could achieve that. I dont think theres any piece of code that
reaches those standards in the kernel actually. And if theres a piece of
code that achieves that it should be emulated. Most of the times, things
that are hard are not about the code but about issues like algorithmics,
embedded policies etc (I think you are saying the same).
cheers,
jamal
^ permalink raw reply
* Re: IPVS Sysctl Variables
From: David Miller @ 2006-06-30 21:20 UTC (permalink / raw)
To: horms; +Cc: netdev, wensong, ja
In-Reply-To: <20060630061940.GA31956@verge.net.au>
From: Horms <horms@verge.net.au>
Date: Fri, 30 Jun 2006 15:19:41 +0900
> there are quite a number of entries under /proc/sys/net/ipv4/vs,
> I swear that they were documented in Documentation/networking/
> at some stage, but perhaps I am dreaming.
>
> In any case, if I clean up the information at the following URL (which a
> probably complete list of what the options are and what they do, you don't
> have to check if you don't want to), is it appropriate for inclusion in
> Documentation/networking/, and if so, should it be in ip-sysctl.txt, or
> elsewhere?
>
> http://www.linuxvirtualserver.org/docs/sysctl.html
Good question, maybe ip-sysctl.txt is getting a bit crowded.
I therefore wouldn't mind you putting this into networking/ipvs-sysctl.txt
Thanks Simon.
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Thomas Graf @ 2006-06-30 21:20 UTC (permalink / raw)
To: jamal; +Cc: netdev, David Miller, Patrick McHardy
In-Reply-To: <1151701767.5270.289.camel@jzny2>
* jamal <hadi@cyberus.ca> 2006-06-30 17:09
> On Fri, 2006-30-06 at 19:13 +0200, Thomas Graf wrote:
> > Index: net-2.6.git/drivers/net/ifb.c
> > ===================================================================
> > --- net-2.6.git.orig/drivers/net/ifb.c
> > +++ net-2.6.git/drivers/net/ifb.c
> > @@ -158,19 +158,23 @@ static int ifb_xmit(struct sk_buff *skb,
> > stats->tx_packets++;
> > stats->tx_bytes+=skb->len;
> >
> > - if (!from || !skb->input_dev) {
> > + if (!from || !skb->iif) {
>
> Can you have something similar to what you did in
> tcf_match_indev above?
>
> i.e grab dev by skb->iif so as to increment refcount - if it doesnt
> exist it becomes equivalent to !skb->input_dev and if it exists you drop
> the ref inside the else below after changing input_dev
A non-existant iif is already equivalent to !iif since it jumps
into the same branch. Grabing a reference is completely pointless,
the netdevice represented by skb->iif is at this point until the
packet gets queued covered by a reference taken in netif_rx().
^ permalink raw reply
* Re: [1/4] [IPV6]: Remove redundant length check on input
From: David Miller @ 2006-06-30 21:19 UTC (permalink / raw)
To: herbert; +Cc: Ananda.Raju, netdev
In-Reply-To: <20060630054209.GA28558@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 30 Jun 2006 15:42:09 +1000
> I've added GSO for TCPv6 and updated Ananda's patch. Please note that
> the following patches have only been compile-tested.
I applied this and pushed it to Linus, let's cross our fingers :)
^ permalink raw reply
* Re: [PATCH 9/15] pcmcia: hostap_cs.c - 0xc00f, 0x0000 conflicts with pcnet_cs
From: Pavel Roskin @ 2006-06-30 21:18 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: linux-pcmcia, netdev, jkmaline, hostap, linville
In-Reply-To: <20060630195920.GJ9095@dominikbrodowski.de>
Hi Dominik,
On Fri, 2006-06-30 at 21:59 +0200, Dominik Brodowski wrote:
> - PCMCIA_DEVICE_MANF_CARD(0xc00f, 0x0000),
> +/* PCMCIA_DEVICE_MANF_CARD(0xc00f, 0x0000), conflict with pcnet_cs */
That's fine if we also add symbolic names. I could identify two
hostap_cs compatible cards using this ID :
card "Allied Telesyn AT-WCL452"
version "Allied Telesyn", "AT-WCL452 Wireless PCMCIA Radio", "Ver.
1.00"
manfid 0xc00f, 0x0000
bind "hostap_cs"
card "corega WL PCCL-11"
version "corega", "WL PCCL-11", "ISL37300P", "RevA"
manfid 0xc00f, 0x0000
bind "hostap_cs"
(from http://www.handhelds.org/hypermail/oe-commits/41/4121.html)
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: RDMA will be reverted
From: David Miller @ 2006-06-30 21:16 UTC (permalink / raw)
To: rdreier; +Cc: netdev, akpm
In-Reply-To: <ada3bdmfjug.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Fri, 30 Jun 2006 13:51:19 -0700
> And I can't think of a single other example of a case where we
> refused to merge a driver, not because of any issues with the driver
> code, but because we don't like the hardware it drives and think
> that people shouldn't be able to use the HW with Linux. And it
> makes me sad that we're doing that here.
The TOE folks have tried to submit their hooks and drivers
on several occaisions, and we've rejected it every time.
I definitely don't want the iWARP stuff to go in until we
have a long good discussion about this. And you have a good
week long opportunity to do so as I'm about to go on vacation
until next Friday :-)
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Thomas Graf @ 2006-06-30 21:10 UTC (permalink / raw)
To: jamal; +Cc: David Miller, netdev, kaber
In-Reply-To: <1151700884.5270.278.camel@jzny2>
* jamal <hadi@cyberus.ca> 2006-06-30 16:54
> I agree - and i try hard to document but at times there's too much
> and a line needs to be drawn.
> As an example:
> the eth->ifb->ifb case though is a very corner case. All the IMQ types
> need to only redirect to one ifb; while i test it ive always seen the
> test as more of a boundary check than a useful setup.
Maybe you should just start by explaining why it doesn't work,
your original explanation doesn't make much sense.
> And Thomas: I do keep notebooks ;-> I doodle about everything, they dont
> all fit in my knapsack anymore so sometimes when i say i will go and
> refer to my notes, it is real.
It's plain arrogant to rely code understanding on information that
is not available to others. It makes everyone being dependant on
you, very nice.
To put it in another way, if you would do your job right when
writing the code, contacting or CCing you upon changes would
be only of a formal matter since the code is understandable and
the intent is clear or documented.
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 21:09 UTC (permalink / raw)
To: Thomas Graf; +Cc: netdev, David Miller, Patrick McHardy
In-Reply-To: <20060630171348.GI14627@postel.suug.ch>
Ok, I think found the last patch you posted, comments below (I have to
run off soon):
On Fri, 2006-30-06 at 19:13 +0200, Thomas Graf wrote:
> There you go, leaves ifb broken as-is, at least prevents it
> from crashing randomly when the input_dev disappears.
>
I hope the above comment does show up in the logs ;->
> [NET]: Use interface index to keep input device information
>
> ===================================================================
> --- net-2.6.git.orig/include/net/pkt_cls.h
> +++ net-2.6.git/include/net/pkt_cls.h
> @@ -352,14 +352,19 @@ tcf_change_indev(struct tcf_proto *tp, c
> static inline int
> tcf_match_indev(struct sk_buff *skb, char *indev)
> {
> + int ret = 1;
> +
> if (indev[0]) {
> - if (!skb->input_dev)
> - return 0;
> - if (strcmp(indev, skb->input_dev->name))
> + struct net_device *dev;
> +
> + dev = dev_get_by_index(skb->iif);
> + if (!dev)
> return 0;
> + ret = !strcmp(indev, dev->name);
> + dev_put(dev);
> }
>
[..]
> Index: net-2.6.git/drivers/net/ifb.c
> ===================================================================
> --- net-2.6.git.orig/drivers/net/ifb.c
> +++ net-2.6.git/drivers/net/ifb.c
> @@ -158,19 +158,23 @@ static int ifb_xmit(struct sk_buff *skb,
> stats->tx_packets++;
> stats->tx_bytes+=skb->len;
>
> - if (!from || !skb->input_dev) {
> + if (!from || !skb->iif) {
Can you have something similar to what you did in
tcf_match_indev above?
i.e grab dev by skb->iif so as to increment refcount - if it doesnt
exist it becomes equivalent to !skb->input_dev and if it exists you drop
the ref inside the else below after changing input_dev
> dev_kfree_skb(skb);
> stats->rx_dropped++;
> return ret;
> } else {
> + struct net_device *iif;
> /*
> * note we could be going
> * ingress -> egress or
> * egress -> ingress
> */
> - skb->dev = skb->input_dev;
> - skb->input_dev = dev;
> + iif = __dev_get_by_index(skb->iif);
> + if (!iif)
> + goto dropped;
> + skb->dev = iif;
> + skb->iif = dev->ifindex;
> if (from & AT_INGRESS) {
> skb_pull(skb, skb->dev->hard_header_len);
> } else {
> -
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 28 of 39] IB/ipath - Fixes a bug where our delay for EEPROM no longer works due to compiler reordering
From: Roland Dreier @ 2006-06-30 21:08 UTC (permalink / raw)
To: Andrew Morton
Cc: Bryan O'Sullivan, mst, openib-general, linux-kernel, netdev
In-Reply-To: <20060629170711.757a97d2.akpm@osdl.org>
> > static void i2c_wait_for_writes(struct ipath_devdata *dd)
> > {
> > + mb();
> > (void)ipath_read_kreg32(dd, dd->ipath_kregs->kr_scratch);
> > }
> That's a bit weird. I wouldn't have expected the compiler to muck around
> with a readl().
I never liked this patch. The last time it came up there were
conflicting answers about whether it was a code generation bug or a
real issue talking to hardware or what. At the least I think this
merits a big comment explain what's going on -- and even better would
be really understanding the bug that's being fixed so that we're
confident it is indeed a real fix.
- R.
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 20:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kaber, tgraf
In-Reply-To: <20060630.133348.68039806.davem@davemloft.net>
On Fri, 2006-30-06 at 13:33 -0700, David Miller wrote:
> From: Thomas Graf <tgraf@suug.ch>
> Date: Fri, 30 Jun 2006 22:30:34 +0200
>
> > Lack of stylistic commas is less of a concern, rather the lack of
> > comments and notes where absolutely essential.
>
> Yes, intent is very important to document when it is not
> obvious.
>
I agree - and i try hard to document but at times there's too much
and a line needs to be drawn.
As an example:
the eth->ifb->ifb case though is a very corner case. All the IMQ types
need to only redirect to one ifb; while i test it ive always seen the
test as more of a boundary check than a useful setup.
And Thomas: I do keep notebooks ;-> I doodle about everything, they dont
all fit in my knapsack anymore so sometimes when i say i will go and
refer to my notes, it is real.
cheers,
jamal
^ permalink raw reply
* Re: RDMA will be reverted
From: Roland Dreier @ 2006-06-30 20:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, akpm
In-Reply-To: <20060629.124628.88476747.davem@davemloft.net>
You snipped my question about what specifically you wanted reverted,
so I'm going to assume that after cooling down and understanding the
situation, you're OK with everything that's in Linus's tree...
> The integration of iWARP with the Linux networking, while much better
> than TOE, is still heavily flawed.
>
> What most people might not realize when using this stuff is that:
>
> 1) None of their firewall rules will apply to the iWARP communications.
> 2) None of their packet scheduling configurations can be applied to
> the iWARP communications.
> 3) It is not possible to encapsulate iWARP traffic in IPSEC
Yes, there are tradeoffs with iWARP. However, there seem to be users
who are willing to make those tradeoffs. And I can't think of a
single other example of a case where we refused to merge a driver, not
because of any issues with the driver code, but because we don't like
the hardware it drives and think that people shouldn't be able to use
the HW with Linux. And it makes me sad that we're doing that here.
Don't get me wrong, I'm all for rejecting patches that make the core
networking stack worse or harder to maintain or are bad patches for
whatever reason. I know that the present is science fiction, but I
always thought that the forbidden technologies would be stuff like
nanotech or human cloning -- I never would have guessed that iWARP
would be in that category.
Anyway, what is your feeling about changes strictly under
drivers/infiniband that add low-level driver support for iWARP
devices? The changes that Steve Wise proposed aren't strictly
necessary for iWARP support -- they just make things work better when
routes change.
Thanks,
Roland
^ permalink raw reply
* RE: [PATCH 2.6.17] support for TSO over IPv6
From: Leonid Grossman @ 2006-06-30 20:46 UTC (permalink / raw)
To: Herbert Xu, Ananda Raju
Cc: netdev, jgarzik, shemminger, Ravinandan Arakali,
sivakumar.subramani, Sriram Rapuru, Michael Chan
> -----Original Message-----
> From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
> Sent: Thursday, June 29, 2006 5:39 PM
> To: Ananda Raju
> Cc: netdev@vger.kernel.org; jgarzik@pobox.com;
> shemminger@osdl.org; Leonid Grossman; Ravinandan Arakali;
> sivakumar.subramani@neterion.com; Sriram Rapuru; Michael Chan
> Subject: Re: [PATCH 2.6.17] support for TSO over IPv6
>
> BTW, does your card handle ECN correctly? If not then we
> should change the new ECN bit to apply to both TCPv4 and TCPv6 since
>
> 1) We now have a piece of hardware that handles TSO6 and it
> doesn't do ECN.
> 2) It's quite likely that if the NIC can handle ECN in TCPv4
> then it can do
> it in TCPv6.
Hi Herbert,
For TSO, our current ASIC replicates the two bits (ECE and CWR) across
every datagram sent out.
Are we saying that the correct behavior should be:
If ECE == 1, then set it to one for all datagrams.
If CWR == 1, then set it to one for the first datagram, and set it to
zero for the rest?
Thanks,
Leonid
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 20:42 UTC (permalink / raw)
To: Thomas Graf; +Cc: Patrick McHardy, netdev, David Miller
In-Reply-To: <20060630200812.GM14627@postel.suug.ch>
On Fri, 2006-30-06 at 22:08 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-30 15:34
> > So assuming it is taken in mirred (i havent thought of where it is
> > decremented), why would using the ifindex be better?
>
> The issue exists regardless of mirred/ifb. As soon as the packet is
> queued for the first time we leave netif_receive_skb() and the dev
> reference is dropped. Therefore in order to allow functionality
> like tcf_match_indev() at egress we have to either take a reference
> or ensure that we can catch the unlikely case of the device having
> disappeared. I think everyone would agree to use device pointers
> if only mirred would acquire it.
Thomas, this is certainly more reasonable explanation.
On Fri, 2006-30-06 at 13:17 -0700, David Miller wrote:
> We have a
> lot of bits of state that sit in the sk_buff but which are used by
> a tiny minority, yet the space consumption is eaten by everyone.
>
>
> Maybe when the IFB and mirred are in more widespread use we can
> investigate a different approach.
>
Not unreasonable.
So saving the bits for the majority trumps the need for slightly more
cycles in mirred/ifb until they get more widespread.
> Another part of this issue is that if you use a pointer there is no
> clean place to clean up the input_dev reference within the scope it is
> actually used.
>
>
> The only reliable place is kfree_skb() which is far
> beyond the scope that this ->input_dev thing is used.
>
And i cant think of a good place to do it.
> We have a lot
> of problems in some parts of the networking because object references
> are held for too long. One example is all the awful side effects of
> the way the bridge netfilter code holds onto object references for
> long periods of time in the netfilter call chains.
>
> And we know the refcounting is broken. And one way we know to fix
> the refcounting without incurring the cost upon everyone is to
> use an interface index and only make the input_dev users eat the
> atomic operation incurred by grabbing the reference.
>
> And even for the input_dev users, it isn't such a big deal, there
> are other costs already associated with hitting these actions and
> devices that use input_dev, the atomic reference grab there should
> be lost in the noise I think.
Alright guys - lets get the change in. I wish we had this specific
discussion sooner.
Thomas, can you post your latest incarnation so i can mow comment more
peacefully? ;->
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: David Miller @ 2006-06-30 20:33 UTC (permalink / raw)
To: tgraf; +Cc: hadi, kaber, netdev
In-Reply-To: <20060630203034.GN14627@postel.suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Fri, 30 Jun 2006 22:30:34 +0200
> Lack of stylistic commas is less of a concern, rather the lack of
> comments and notes where absolutely essential.
Yes, intent is very important to document when it is not
obvious.
Everyone is guilty of not doing this from time to time. :)
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Thomas Graf @ 2006-06-30 20:30 UTC (permalink / raw)
To: jamal; +Cc: Patrick McHardy, David Miller, netdev
In-Reply-To: <1151697554.5270.241.camel@jzny2>
* jamal <hadi@cyberus.ca> 2006-06-30 15:59
> One thing is clear in my mind at least (and i have said it several
> times): I am not as good at the semantics as either yourself or Thomas
> or Dave or Acme etc but i have tons of other things that compensate for.
> Probably "not as good" is not the best description - rather my brain
> cells put less respect on the stylistic commas than they do on the
> message. Perhaps it's dylexsia or me trying to subconsciouly maximize my
> time. If you push me hard, however, i will get close to do just as a
> good job as you;-> Still, cant live without you guys!
Lack of stylistic commas is less of a concern, rather the lack of
comments and notes where absolutely essential. You explained to me
that stacking ifb devices is not supported in order to avoid tx lock
deadlocks. There is not a single note or hint anywhere that would
remotely imply this. When questioned about things like that you often
refer to notes you have somewhere on paper, promising to get back once
looked up, eventually that happens, in this thread it didn't.
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: jamal @ 2006-06-30 20:19 UTC (permalink / raw)
To: Shailabh Nagar
Cc: netdev, linux-kernel, csturtiv, balbir, jlan, Valdis.Kletnieks,
Paul Jackson, Andrew Morton
In-Reply-To: <44A5770F.3080206@watson.ibm.com>
On Fri, 2006-30-06 at 15:10 -0400, Shailabh Nagar wrote:
>
> Also to get feedback on this kind of usage of the nl_pid field, the
> approach etc.
>
It does not look unreasonable. I think you may have issues when you have
multiple such sockets opened within a single process. But
do some testing and see how it goes.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: David Miller @ 2006-06-30 20:17 UTC (permalink / raw)
To: hadi; +Cc: kaber, tgraf, netdev
In-Reply-To: <1151696426.5270.224.camel@jzny2>
From: jamal <hadi@cyberus.ca>
Date: Fri, 30 Jun 2006 15:40:26 -0400
> My arguement was:
> dev get by index per device will involve a a) lookup + b) incrementing
> the refcount.
> if i use the dev pointer in that path then it becomes only #b
>
> in both cases, you need to increment the counter and then somewhere
> decrement it.
The position is that ->input_dev usage is not fast path.
It may be a fast path in your mirred and ifb devices, but for the rest
of the networking and %99 of users it is totally unused. We have a
lot of bits of state that sit in the sk_buff but which are used by
a tiny minority, yet the space consumption is eaten by everyone.
Maybe when the IFB and mirred are in more widespread use we can
investigate a different approach.
But at this time any change that makes fringe sk_buff state objects
shrink or disappear will be seriously considered.
Another part of this issue is that if you use a pointer there is no
clean place to clean up the input_dev reference within the scope it is
actually used. The only reliable place is kfree_skb() which is far
beyond the scope that this ->input_dev thing is used. We have a lot
of problems in some parts of the networking because object references
are held for too long. One example is all the awful side effects of
the way the bridge netfilter code holds onto object references for
long periods of time in the netfilter call chains.
And we know the refcounting is broken. And one way we know to fix
the refcounting without incurring the cost upon everyone is to
use an interface index and only make the input_dev users eat the
atomic operation incurred by grabbing the reference.
And even for the input_dev users, it isn't such a big deal, there
are other costs already associated with hitting these actions and
devices that use input_dev, the atomic reference grab there should
be lost in the noise I think.
^ permalink raw reply
* [PATCH 14/15] com20020_cs: more device support
From: Dominik Brodowski @ 2006-06-30 20:03 UTC (permalink / raw)
To: linux-pcmcia; +Cc: netdev
In-Reply-To: <20060630200146.GN9095@dominikbrodowski.de>
From: Marc Sowen <Marc.Sowen@ibeo-as.de>
Date: Sun, 25 Jun 2006 01:56:24 -0700
Subject: [PATCH] com20020_cs: more device support
Enable the com20020_cs arcnet driver to see the SoHard (now Mercury
Computer Systems Inc.) SH ARC-PCMCIA card.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
---
drivers/net/pcmcia/com20020_cs.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/pcmcia/com20020_cs.c b/drivers/net/pcmcia/com20020_cs.c
index 441de82..48434d7 100644
--- a/drivers/net/pcmcia/com20020_cs.c
+++ b/drivers/net/pcmcia/com20020_cs.c
@@ -387,7 +387,10 @@ static int com20020_resume(struct pcmcia
}
static struct pcmcia_device_id com20020_ids[] = {
- PCMCIA_DEVICE_PROD_ID12("Contemporary Control Systems, Inc.", "PCM20 Arcnet Adapter", 0x59991666, 0x95dfffaf),
+ PCMCIA_DEVICE_PROD_ID12("Contemporary Control Systems, Inc.",
+ "PCM20 Arcnet Adapter", 0x59991666, 0x95dfffaf),
+ PCMCIA_DEVICE_PROD_ID12("SoHard AG",
+ "SH ARC PCMCIA", 0xf8991729, 0x69dff0c7),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, com20020_ids);
--
1.4.0
^ permalink raw reply related
* [PATCH 9/15] pcmcia: hostap_cs.c - 0xc00f,0x0000 conflicts with pcnet_cs
From: Dominik Brodowski @ 2006-06-30 19:59 UTC (permalink / raw)
To: linux-pcmcia; +Cc: jkmaline, hostap, netdev, linville
In-Reply-To: <20060630195753.GI9095@dominikbrodowski.de>
From: Komuro <komurojun-mbn@nifty.com>
Date: Mon, 17 Apr 2006 21:41:21 +0900
Subject: [PATCH] pcmcia: hostap_cs.c - 0xc00f,0x0000 conflicts with pcnet_cs
Comment out the ID 0xc00f,0x0000 in hostap_cs.c, as it conflicts with the
pcnet_cs driver.
Signed-off-by: komurojun-mbn@nifty.com
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
---
drivers/net/wireless/hostap/hostap_cs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_cs.c b/drivers/net/wireless/hostap/hostap_cs.c
index db03dc2..fbb4189 100644
--- a/drivers/net/wireless/hostap/hostap_cs.c
+++ b/drivers/net/wireless/hostap/hostap_cs.c
@@ -844,7 +844,7 @@ static struct pcmcia_device_id hostap_cs
PCMCIA_DEVICE_MANF_CARD(0x02d2, 0x0001),
PCMCIA_DEVICE_MANF_CARD(0x50c2, 0x0001),
PCMCIA_DEVICE_MANF_CARD(0x50c2, 0x7300),
- PCMCIA_DEVICE_MANF_CARD(0xc00f, 0x0000),
+/* PCMCIA_DEVICE_MANF_CARD(0xc00f, 0x0000), conflict with pcnet_cs */
PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0002),
PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0005),
PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0010),
--
1.4.0
^ permalink raw reply related
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Thomas Graf @ 2006-06-30 20:08 UTC (permalink / raw)
To: jamal; +Cc: David Miller, netdev, Patrick McHardy
In-Reply-To: <1151696083.5270.218.camel@jzny2>
* jamal <hadi@cyberus.ca> 2006-06-30 15:34
> I thought we went past that point already - and i made it clear that
> the reference is _not_ taken in netif_receive_skb().
>
> So assuming it is taken in mirred (i havent thought of where it is
> decremented), why would using the ifindex be better?
The issue exists regardless of mirred/ifb. As soon as the packet is
queued for the first time we leave netif_receive_skb() and the dev
reference is dropped. Therefore in order to allow functionality
like tcf_match_indev() at egress we have to either take a reference
or ensure that we can catch the unlikely case of the device having
disappeared. I think everyone would agree to use device pointers
if only mirred would acquire it.
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 19:59 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David Miller, netdev, Thomas Graf
In-Reply-To: <44A5606B.5080003@trash.net>
On Fri, 2006-30-06 at 19:33 +0200, Patrick McHardy wrote:
> jamal wrote:
> > You are attempting to change architecture (which works just fine) in the way you
> > think it should work - and then point to something as a bug because it
> > doesnt work the way you think it should work.
> > This is a problem not just with you BTW, but with Patrick as well (although he has
> > gotten better lately). There is a huge difference for example when dealing with
> > Herbert. My approach in situations like this, which you dont have to follow, is
> > to ask first what the intent was then if i dont like the intent try to convince the
> > owner that there maybe better ways. Or why they are wrong.
>
> Well, I thought I stay out of this, but since you mention me ..
>
I think you will add value to the discussion ;->
Regardless, we need to settle these kind of issues so we can work better
together. A while back i said was going to bring some of these issues at
the next netconf - but since the discussion is happening already, lets
do it here. Maybe we should take this discussion privately?
> I also had the feeling it has gotten easier working with you lately,
The feeling is mutual.
> but I can understand Thomas's pain, I had the same thoughts more than
> once. Your code often does have an enormous amount of bugs and
> whitespace and other stylistic problems and working with you can be
> challenging for multiple reasons, for example having to go to endless,
One thing is clear in my mind at least (and i have said it several
times): I am not as good at the semantics as either yourself or Thomas
or Dave or Acme etc but i have tons of other things that compensate for.
Probably "not as good" is not the best description - rather my brain
cells put less respect on the stylistic commas than they do on the
message. Perhaps it's dylexsia or me trying to subconsciouly maximize my
time. If you push me hard, however, i will get close to do just as a
good job as you;-> Still, cant live without you guys!
I would describe the majority of the fixes you have sent against me to
fall into the stylistic category and into fixing TheLinuxWay (i.e same
bug in multiple places and files). This is not to say i am not at fault,
or there havent been issues which made me wonder, but we may have
different metrics of what bugs i would call my mom and say "Mom, I just
fixed enormous amount of bugs".
[As an example if you went hunting around the kernel, you will find a
lot of things that dont totally conform to lindent rules. You could
literally send 100s of patches].
Perhaps it is the language usage that puts us at odds at times.
> often entirely pointless discussions for obvious fixes,
You may see it that way - I dont and so when that happens it is not by
any means to engage in a meaningless debate.
The discussions are typically of the same nature as i just had with
Thomas (just a simple one line change in ifb which looked very
"obvious").
The way it goes is that there is a certain assumption made, and a
solution is suggested in the form of a patch. Accepting such a patch
(which i once in a while dont even get to see until it is in) means a
lot of the other assumptions get invalidated and is followed by tons of
"bug fixes". This has happened a few times to me. And once or twice i
have bitched because i ended having to support some user for days with
the wrong view.
> especially if you're already pissed by noticing 50 bugs at once.
I dont get agitated by 100 patches which fix stylistic issues or real
bugs - although i would have preferred to see the non-obvious first
before they go in just in case or at least CCed on submission.
Where i get irritated, depending on how my day is going: when i see even
a single patch laded with implicit insults. It comes out to me as
unnecessary arrogance and immaturity. It may not be intentional use of
language, but thats how it comes out.
> The reason why you
> might be able to work better with Herbert is IMO that he usually
> doesn't touch what you seem to feel is "your area".
I think it's the maturity approach perhaps. With Herbert, it ends up
being about solving the problem; there are always moments of tension and
what may appear as endless discussion (look at the thread on
qdisc_is_running), but in the end it doesnt turn out into a high school
debate to prove one is better than the other. So maybe it is the mutual
respect and maturity in the discussion.
In regards to "areas", you may be right; i cross more into Herberts path
than he does mine.
My reaction in this may be related to the way i treat other people and
my expectations:
When i submit patches to i would make sure i cc people who i think have
stakes or better insight in that area even if they seem irrelevant.
In-fact i may have even private conversations with them first if they
are large patches.
As an example i would make sure i cc you if i had some netfilter issues
or Herbert when i submit ipsec patches and we would have a gazillion
discussions which would sometimes result in the patches being totally
re-written. It doesnt make me happy all the time (especially when i have
to drop patches), but in the end it made me work better with that person
and removes doubt in my mind that i have missed something. Unfortunately
this approach (even in non-linux areas) is a lot of times
taken for a weakness.
cheers,
jamal
> Besides that, I
> never changed anything in your architecture, only fixed massive
> amounts of bugs.
>
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 19:40 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Thomas Graf, David Miller, netdev
In-Reply-To: <44A56294.7030309@trash.net>
On Fri, 2006-30-06 at 19:42 +0200, Patrick McHardy wrote:
> jamal wrote:
> > Thomas makes the claim, this can be achieved only by using an ifindex.
> > And i havent been able to see how. I have a small performance problem if
> > i just use ifindex. Using ifindex will eventually save 32 bits on the
> > 64 bit machines. I posed the question as to which was more beneficial
> > as a solution that hasnt been addressed.
>
> Are we still talking about this? Its easy: a pointer without taking
> a reference can become stale,
I should have been clear: reference gets taken in mirred.
> with ifindex you do the lookup right
> when using it, so you either get an result or you don't.
My arguement was:
dev get by index per device will involve a a) lookup + b) incrementing
the refcount.
if i use the dev pointer in that path then it becomes only #b
in both cases, you need to increment the counter and then somewhere
decrement it.
cheers,
jamal
> It also
> saves atomic operations for anyone _not_ using it, which is that
> vast majority of users. So the patch clearly makes sense to me.
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-30 19:34 UTC (permalink / raw)
To: Thomas Graf; +Cc: David Miller, netdev, Patrick McHardy
In-Reply-To: <20060630174251.GK14627@postel.suug.ch>
On Fri, 2006-30-06 at 19:42 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-30 13:32
> > Thomas makes the claim, this can be achieved only by using an ifindex.
> > And i havent been able to see how. I have a small performance problem if
> > i just use ifindex. Using ifindex will eventually save 32 bits on the
> > 64 bit machines. I posed the question as to which was more beneficial
> > as a solution that hasnt been addressed.
>
> I'd appreciate if you'd stop sperading lies.
>
> I claimed it to be the
> best solution, not the only one. Everyone agrees that it's possible
> to use a pointer and take a reference in netif_receive_skb() while
> it also seems obvious to most that it's not a good idea to take two
> additional atomic operations in the fast path for this purpose.
I thought we went past that point already - and i made it clear that
the reference is _not_ taken in netif_receive_skb().
So assuming it is taken in mirred (i havent thought of where it is
decremented), why would using the ifindex be better?
cheers,
jamal
^ permalink raw reply
* Re: Please pull 'upstream' branch of wireless-2.6 (revised)
From: John W. Linville @ 2006-06-30 19:27 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
In-Reply-To: <44A551C4.8090208@garzik.org>
On Fri, Jun 30, 2006 at 12:31:00PM -0400, Jeff Garzik wrote:
> >The following changes since commit
> >fcc18e83e1f6fd9fa6b333735bf0fcd530655511:
> > Malcolm Parsons:
> > uclinux: use PER_LINUX_32BIT in binfmt_flat
> >
> >are found in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
> > upstream
>
> nothing pulled?
Odd, the changes seem to be there...did you happen to pull zd1211rw
first? I based that branch off the HEAD of the upstream branch.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Shailabh Nagar @ 2006-06-30 19:19 UTC (permalink / raw)
To: Shailabh Nagar
Cc: Andrew Morton, Paul Jackson, Valdis.Kletnieks, jlan, balbir,
csturtiv, linux-kernel, Jamal, netdev
In-Reply-To: <44A5770F.3080206@watson.ibm.com>
Shailabh Nagar wrote:
> Shailabh Nagar wrote:
>
>
<snip>
> Index: linux-2.6.17-mm3equiv/kernel/taskstats.c
> ===================================================================
> --- linux-2.6.17-mm3equiv.orig/kernel/taskstats.c 2006-06-30 11:57:14.000000000 -0400
> +++ linux-2.6.17-mm3equiv/kernel/taskstats.c 2006-06-30 13:58:36.000000000 -0400
> @@ -266,7 +266,7 @@ void taskstats_exit_send(struct task_str
> struct sk_buff *rep_skb;
> void *reply;
> size_t size;
> - int is_thread_group;
> + int is_thread_group, setid;
> struct nlattr *na;
>
> if (!family_registered || !tidstats)
> @@ -320,7 +320,8 @@ void taskstats_exit_send(struct task_str
> nla_nest_end(rep_skb, na);
>
> send:
> - send_reply(rep_skb, 0, TASKSTATS_MSG_MULTICAST);
> + setid = (smp_processor_id()%TASKSTATS_CPUS_PER_SET)+1;
> + send_reply(rep_skb, setid, TASKSTATS_MSG_MULTICAST);
This should be
send_reply(rep_skb, setid, TASKSTATS_MSG_UNICAST);
> return;
>
> nla_put_failure:
> Index: linux-2.6.17-mm3equiv/Documentation/accounting/getdelays.c
> ===================================================================
> --- linux-2.6.17-mm3equiv.orig/Documentation/accounting/getdelays.c 2006-06-28 16:08:56.000000000 -0400
> +++ linux-2.6.17-mm3equiv/Documentation/accounting/getdelays.c 2006-06-30 14:09:28.000000000 -0400
> @@ -40,7 +40,7 @@ int done = 0;
> /*
> * Create a raw netlink socket and bind
> */
> -static int create_nl_socket(int protocol, int groups)
> +static int create_nl_socket(int protocol, int cpugroup)
> {
> socklen_t addr_len;
> int fd;
> @@ -52,7 +52,8 @@ static int create_nl_socket(int protocol
>
> memset(&local, 0, sizeof(local));
> local.nl_family = AF_NETLINK;
> - local.nl_groups = groups;
> + local.nl_groups = TASKSTATS_LISTEN_GROUP;
> + local.nl_pid = cpugroup;
>
> if (bind(fd, (struct sockaddr *) &local, sizeof(local)) < 0)
> goto error;
> @@ -203,7 +204,7 @@ int main(int argc, char *argv[])
> pid_t rtid = 0;
> int cmd_type = TASKSTATS_TYPE_TGID;
> int c, status;
> - int forking = 0;
> + int forking = 0, cpugroup = 0;
> struct sigaction act = {
> .sa_handler = SIG_IGN,
> .sa_mask = SA_NOMASK,
> @@ -222,7 +223,7 @@ int main(int argc, char *argv[])
>
> while (1) {
>
> - c = getopt(argc, argv, "t:p:c:");
> + c = getopt(argc, argv, "t:p:c:g:l");
> if (c < 0)
> break;
>
> @@ -252,8 +253,14 @@ int main(int argc, char *argv[])
> }
> forking = 1;
> break;
> + case 'g':
> + cpugroup = atoi(optarg);
> + break;
> + case 'l':
> + loop = 1;
> + break;
> default:
> - printf("usage %s [-t tgid][-p pid][-c cmd]\n", argv[0]);
> + printf("usage %s [-t tgid][-p pid][-c cmd][-g cpugroup][-l]\n", argv[0]);
> exit(-1);
> break;
> }
> @@ -266,7 +273,7 @@ int main(int argc, char *argv[])
> /* Send Netlink request message & get reply */
>
> if ((nl_sd =
> - create_nl_socket(NETLINK_GENERIC, TASKSTATS_LISTEN_GROUP)) < 0)
> + create_nl_socket(NETLINK_GENERIC, cpugroup)) < 0)
> err(1, "error creating Netlink socket\n");
>
>
> @@ -287,10 +294,10 @@ int main(int argc, char *argv[])
>
>
> if (!forking && sendto_fd(nl_sd, (char *) &req, req.n.nlmsg_len) < 0)
> + if ((!forking && !loop) &&
> + sendto_fd(nl_sd, (char *) &req, req.n.nlmsg_len) < 0)
> err(1, "error sending message via Netlink\n");
>
> - act.sa_handler = SIG_IGN;
> - sigemptyset(&act.sa_mask);
> if (sigaction(SIGINT, &act, NULL) < 0)
> err(1, "sigaction failed for SIGINT\n");
>
> @@ -349,10 +356,11 @@ int main(int argc, char *argv[])
> rtid = *(int *) NLA_DATA(na);
> break;
> case TASKSTATS_TYPE_STATS:
> - if (rtid == tid) {
> + if (rtid == tid || loop) {
> print_taskstats((struct taskstats *)
> NLA_DATA(na));
> - done = 1;
> + if (!loop)
> + done = 1;
> }
> break;
> }
> @@ -369,7 +377,7 @@ int main(int argc, char *argv[])
> if (done)
> break;
> }
> - while (1);
> + while (loop);
>
> close(nl_sd);
> return 0;
>
^ 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