* Re: [PATCH] net: Don't drop route cache entry in ipv4_negative_advice unless PTMU expired
From: David Miller @ 2010-03-22 3:53 UTC (permalink / raw)
To: guenter.roeck; +Cc: netdev, viro, den
In-Reply-To: <1269009673-25497-1-git-send-email-guenter.roeck@ericsson.com>
From: Guenter Roeck <guenter.roeck@ericsson.com>
Date: Fri, 19 Mar 2010 07:41:13 -0700
> TCP sessions over IPv4 can get stuck if routers between endpoints
> do not fragment packets but implement PMTU instead.
This bug actually only applies to a much more specific case.
It only occurs when the router we end up using is the result of
receiving a redirect to it.
If we use the configured route, and do not get redirected, the problem
never happens.
In any case, your patch is correct, and I'll add some clarification to
the commit message when I check this in.
Thanks a lot!
^ permalink raw reply
* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: Herbert Xu @ 2010-03-22 3:52 UTC (permalink / raw)
To: David Miller; +Cc: timo.teras, netdev
In-Reply-To: <20100321.201258.184825751.davem@davemloft.net>
On Sun, Mar 21, 2010 at 08:12:58PM -0700, David Miller wrote:
>
> Good point, I was misunderstanding how things work now and how
> that would change with your proposal.
>
> Having multiple xfrm_dsts exist for an IPSEC route seems fine
> to me.
Thanks for the confirmation.
Timo, let's roll along with the per-cpu xfrm_dst approach.
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] xfrm: cache bundle lookup results in flow cache
From: Herbert Xu @ 2010-03-22 3:52 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev, David S. Miller
In-Reply-To: <4BA5D95B.4020004@iki.fi>
On Sun, Mar 21, 2010 at 10:31:23AM +0200, Timo Teräs wrote:
>
>> Ok, we can do that to skip 2. But I think 1 would be still useful.
>> It'd probably be good to actually have flow_cache_ops pointer in
>> each entry instead of the atomic_t pointer.
>>
>> The reasoning:
>> - we can then have type-based checks that the reference count
>> is valid (e.g. policy's refcount must not go to zero, it's bug,
>> and we can call dst_release which warns if refcount goes to
>> negative); imho it's hack to call atomic_dec instead of the
>> real type's xxx_put
>> - the flow cache needs to somehow know if the entry is stale so
>> it'll try to refresh it atomically; e.g. if there's no
>> check for 'stale', the lookup returns stale xfrm_dst. we'd
>> then need new api to update the stale entry, or flush it out
>> and repeat the lookup. the virtual get could check for it being
>> stale (if so release the entry) and then return null for the
>> generic code to call the resolver atomically
>> - for paranoia we can actually check the type of the object in
>> cache via the ops (if needed)
The reason I'd prefer to keep the current scheme is to avoid
an additional indirect function call on each packet.
The way it would work is (we need flow_cache_lookup to return
fle instead of the object):
fle = flow_cache_lookup
xdst = fle->object
if (xdst is stale) {
flow_cache_mark_obsolete(fle)
fle = flow_cache_lookup
xdst = fle->object
if (xdst is stale)
return error
}
Where flow_cache_mark_obsolete would set a flag in the fle that's
checked by flow_cache_lookup. To prevent the very rare case
where we mark an entry obsolete incorrectly, the resolver function
should double-check that the existing entry is indeed obsolete
before making a new one.
This way we give the overhead over to the slow path where the
bundle is stale.
You were saying that our bundles are going stale very frequently,
that would sound like a bug that we should look into. The whole
caching scheme is pointless if the bundle is going stale every
other packet.
> - could cache bundle OR policy for outgoing stuff. it's useful
> to cache the policy in case we need to sleep, or if it's a
> policy forbidding traffic. in those cases there's no bundle
> to cache at all. alternatively we can make dummy bundles that
> are marked invalid and are just used to keep a reference to
> the policy.
My instinct is to go with dummy bundles. That way given the
direction we know exactly what object type it is. Having mixed
object types is just too much of a pain.
> Oh, this also implies that the resolver function should be
> changed to get the old stale object so it can re-use it to
> get the policy object instead of searching it all over again.
That should be easy to implement. Just prefill the obj argument
to the resolver with either NULL or the stale object.
For the bundle resolver, it should also remove the stale bundle
from the policy bundle list and drop its reference.
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] net: dev_getfirstbyhwtype() optimization
From: David Miller @ 2010-03-22 3:39 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1268947645.2894.166.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 18 Mar 2010 22:27:25 +0100
> Use RCU to avoid RTNL use in dev_getfirstbyhwtype()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH] can: bfin_can: switch to common Blackfin can header
From: David Miller @ 2010-03-22 3:39 UTC (permalink / raw)
To: vapier.adi
Cc: socketcan-core, netdev, uclinux-dist-devel, oliver.hartkopp,
urs.thuermann
In-Reply-To: <8bd0f97a1003182335l3c121d87v9369145852c9545d@mail.gmail.com>
From: Mike Frysinger <vapier.adi@gmail.com>
Date: Fri, 19 Mar 2010 02:35:17 -0400
> On Wed, Mar 17, 2010 at 01:51, David Miller wrote:
>> From: Mike Frysinger <vapier.adi@gmail.com>
>>> if the next tree is merged into linux-next, then the header is already there
>>
>> Just get your stuff merged properly to Linus then resubmit
>> your patch.
>
> Linus has pulled my tree, so there shouldnt be any reason to not merge
> this patch now
If you can't understand what the heck the word "RESUMBIT" means,
then I'm not even going to pay attention to you anymore.
I keep telling you to resubmit the thing when it'll work correctly
because it makes things 1,000 times easier for me then crawling
through the mailing list and patchwork history trying to fish out
your patch and figure out if it's the right one or not.
^ permalink raw reply
* Re: [PATCH] pktgen node allocation
From: David Miller @ 2010-03-22 3:37 UTC (permalink / raw)
To: robert; +Cc: eric.dumazet, netdev
In-Reply-To: <19363.32154.39665.185451@gargle.gargle.HOWL>
From: robert@herjulf.net
Date: Fri, 19 Mar 2010 14:35:22 +0100
>
> Eric Dumazet writes:
> > Le vendredi 19 mars 2010 à 09:44 +0100, Robert Olsson a écrit :
> >
> > I cannot understand how this can help.
> >
> > __netdev_alloc_skb() is supposed to already take into account NUMA
> > properties :
> >
> > int node = dev->dev.parent ? dev_to_node(dev->dev.parent) : -1;
> >
> > If this doesnt work, we should correct core stack, not only pktgen :)
> >
> > Are you allocating memory in the node where pktgen CPU is running or the
> > node close to the NIC ?
>
> I didn't say it should help the idea was to give some hooks to
> experiment and see effects with different node memory allocations.
> There are many degrees of freedom wrt buses(device)/CPU/menory.
I think it's a useful feature and by default the netdev alloc
is still used, so... applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] can: sja1000: add read/write routines for 8, 16 and 32-bit register access
From: David Miller @ 2010-03-22 3:37 UTC (permalink / raw)
To: w.sang; +Cc: yegor_sub1, netdev, socketcan-core
In-Reply-To: <20100320035639.GB26934@pengutronix.de>
From: Wolfram Sang <w.sang@pengutronix.de>
Date: Sat, 20 Mar 2010 04:56:39 +0100
> On Fri, Mar 19, 2010 at 11:50:44AM +0100, Yegor Yefremov wrote:
>> SJA1000: add read/write routines for 8, 16 and 32-bit register access
>>
>> add routines for 8, 16 and 32-bit access like in
>> drivers/i2c/busses/i2c-pca-platform.c
>>
>> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
>
> Acked-by: Wolfram Sang <w.sang@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] can: sja1000: allow shared interrupt definition
From: David Miller @ 2010-03-22 3:36 UTC (permalink / raw)
To: wg; +Cc: yegor_sub1, netdev, socketcan-core
In-Reply-To: <4BA37868.5040303@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Fri, 19 Mar 2010 14:13:12 +0100
> Yegor Yefremov wrote:
>> SJA1000: allow shared interrupt definition
>>
>> extend the AND mask, so that IRQF_SHARED flag remains
>>
>> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
>
> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Applied.
^ permalink raw reply
* Re: [PATCH] Improved network performance by balancing Rx against other work
From: David Miller @ 2010-03-22 3:21 UTC (permalink / raw)
To: peter.chubb; +Cc: netdev
In-Reply-To: <87tysfu05d.wl%peterc@chubb.wattle.id.au>
From: Peter Chubb <peter.chubb@nicta.com.au>
Date: Wed, 17 Mar 2010 13:55:58 +1100
> The general approach is to restrict the work done in the Rx-side
> processing to just 32 or so packets at a time then call
> sys_sched_yield() to allow other system processing to get a look in.
> Currently, NAPI processing happens in soft IRQ context, and much of it
> with interrupts off.
This is a deficiency in the locking done by such drivers. Many
drivers lock properly and do not disable hardware interrupts during
NAPI processing. Not only is this more efficient, it also makes
the driver more profilable. For example, on cpus with only timer
based profiling everything done in NAPI context can be seen.
> In addition, because so much runs with interrupts disabled,
> real-time performance sucks.
Please respin your analysis to be done with a sane driver, one that
does not disable hardware interrupts. Doing so is a driver, rather
than a fundamental, issue of NAPI.
Avoiding hardware interrupt disabling also has another huge benefit,
it means that the transmit path of the driver need not disable
hardware interrupts either since that already runs in software
interrupt disabled context.
Your analysis was essentially done with broken driver(s), so I think
I can stop reading here.
^ permalink raw reply
* Re: [PATCH RFC] tun: add ioctl to modify vnet header size
From: David Miller @ 2010-03-22 3:17 UTC (permalink / raw)
To: mst
Cc: dlstevens, David.Woodhouse, herbert, linux-kernel, netdev,
netdev-owner, paul.moore, sri
In-Reply-To: <20100317221117.GA7541@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Thu, 18 Mar 2010 00:11:17 +0200
> All this does is set how much of the buffer to skip, this option does
> not allocate any memory. So if you set it to a value > length that you
> passed in, you get -EINVAL. Anything else should work. Negative values
> are checked for and return -EINVAL when you try to set it. At least,
> all that's by design - pls take a look at the code and if you see any
> issues, speak up please.
>
> I agree we don't really need to support very large values here,
> it just seemed less work.
This all looks fine to me, submit a final version to me via
whatever means you feel is appropriate.
^ permalink raw reply
* Re: [RFC] GTSM for IPv6
From: David Miller @ 2010-03-22 3:16 UTC (permalink / raw)
To: pekkas; +Cc: shemminger, yoshfuji, netdev
In-Reply-To: <alpine.LRH.2.00.1003191959050.31512@netcore.fi>
From: Pekka Savola <pekkas@netcore.fi>
Date: Fri, 19 Mar 2010 20:02:48 +0200 (EET)
> On Fri, 19 Mar 2010, Stephen Hemminger wrote:
>> Also RFC doesn't explicitly address GTSM on IPV6.
>> Maybe the RFC editors think the problem will magically no longer exist
>> in IPv6 world because everyone will be using IPsec.
>
> Hmm. When I was editing the RFC, I seem to have put in some text about
> IPv6 (i.e. difference in TTL vs Hop Count naming). As far as I know,
> there is no other difference :-)
>
> In IPV6_MIN_HOPS hops would seem to point toward the "number of hops"
> which is logically the opposite: 255-$value. So maybe
> IPV6_MIN_HOPCOUNT is better. But I can live with it either way :-)
Stephen, make whatever decision your deem appropriate about
the name and resubmit this for net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: David Miller @ 2010-03-22 3:12 UTC (permalink / raw)
To: herbert; +Cc: timo.teras, netdev
In-Reply-To: <20100322014010.GA14182@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 22 Mar 2010 09:40:10 +0800
> On Sun, Mar 21, 2010 at 06:36:56PM -0700, David Miller wrote:
>>
>> And as a consequence, making the xfrm_dst's be per-cpu would mess with
>> route metrics for TCP.
>
> Actually xfrm_dst currently relies on IPv4 rt objects to maintain
> the metrics. So as long as IPv4 routes are still global, then the
> metrics won't be affected as far as can I see.
>
> Did I miss something?
Good point, I was misunderstanding how things work now and how
that would change with your proposal.
Having multiple xfrm_dsts exist for an IPSEC route seems fine
to me.
^ permalink raw reply
* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: Herbert Xu @ 2010-03-22 1:40 UTC (permalink / raw)
To: David Miller; +Cc: timo.teras, netdev
In-Reply-To: <20100321.183656.173864141.davem@davemloft.net>
On Sun, Mar 21, 2010 at 06:36:56PM -0700, David Miller wrote:
>
> And as a consequence, making the xfrm_dst's be per-cpu would mess with
> route metrics for TCP.
Actually xfrm_dst currently relies on IPv4 rt objects to maintain
the metrics. So as long as IPv4 routes are still global, then the
metrics won't be affected as far as can I see.
Did I miss something?
> I'm willing to consider this seriously, to be honest.
I would consider that too. But right now I'm just looking for
the bare minimum to solve the problem at hand :)
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 net-next-2.6] net: snmp mib cleanup
From: David Miller @ 2010-03-22 1:38 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1268980566.2894.231.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 19 Mar 2010 07:36:06 +0100
> There is no point to align or pad mibs to cache lines, they are per cpu
> allocated with a 8 bytes alignment anyway.
> This wastes space for no gain. This patch removes __SNMP_MIB_ALIGN__
>
> Since SNMP mibs contain "unsigned long" fields only, we can relax the
> allocation alignment from "unsigned long long" to "unsigned long"
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Also applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next-2.6] atm: Use kasprintf
From: David Miller @ 2010-03-22 1:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1268956106.2894.211.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 19 Mar 2010 00:48:26 +0100
> Use kasprintf in atm_proc_dev_register()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: speedup netdev_set_master()
From: David Miller @ 2010-03-22 1:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1268955460.2894.207.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 19 Mar 2010 00:37:40 +0100
> We currently force a synchronize_net() in netdev_set_master()
>
> This seems necessary only when a slave had a master and we dismantle it.
>
> In the other case ("ifenslave bond0 ethO"), we dont need this long
> delay.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: David Miller @ 2010-03-22 1:36 UTC (permalink / raw)
To: herbert; +Cc: timo.teras, netdev
In-Reply-To: <20100322013257.GA14080@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 22 Mar 2010 09:32:57 +0800
> On Sun, Mar 21, 2010 at 06:28:46PM -0700, David Miller wrote:
>> From: Herbert Xu <herbert@gondor.apana.org.au>
>> Date: Sat, 20 Mar 2010 23:17:51 +0800
>>
>> > Actually I just realised that the other way we can fix this is
>> > to make xfrm_dst objects per-cpu just like IPv4 routes. That
>> > is, when you fail to find an xfrm_dst object in the per-cpu
>> > cache, you dont' bother calling xfrm_find_bundle but just make
>> > a new bundle.
>>
>> How are ipv4 routing cache entries per-cpu? That would screw up route
>> metrics for TCP sockets quite a lot if they were.
>
> You're right of course, s/just like IPv4 routes// :)
And as a consequence, making the xfrm_dst's be per-cpu would mess with
route metrics for TCP.
If we do something like that, then there is simply no reason any
longer to have such fine-grained routing metrics if the one thing that
would use it heavily (ipsec) stops doing so completely.
At that point we can go to a host cache for metrics just like BSD, and
pull all of the metrics out of struct dst (enormous win as it makes
all routes significantly smaller).
I'm willing to consider this seriously, to be honest.
^ permalink raw reply
* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: Herbert Xu @ 2010-03-22 1:32 UTC (permalink / raw)
To: David Miller; +Cc: timo.teras, netdev
In-Reply-To: <20100321.182846.232914131.davem@davemloft.net>
On Sun, Mar 21, 2010 at 06:28:46PM -0700, David Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Sat, 20 Mar 2010 23:17:51 +0800
>
> > Actually I just realised that the other way we can fix this is
> > to make xfrm_dst objects per-cpu just like IPv4 routes. That
> > is, when you fail to find an xfrm_dst object in the per-cpu
> > cache, you dont' bother calling xfrm_find_bundle but just make
> > a new bundle.
>
> How are ipv4 routing cache entries per-cpu? That would screw up route
> metrics for TCP sockets quite a lot if they were.
You're right of course, s/just like IPv4 routes// :)
--
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 net-next-2.6] tcp: Add SNMP counter for DEFER_ACCEPT
From: David Miller @ 2010-03-22 1:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1269013038.3048.58.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 19 Mar 2010 16:37:18 +0100
> Its currently hard to diagnose when ACK frames are dropped because an
> application set TCP_DEFER_ACCEPT on its listening socket.
>
> See http://bugzilla.kernel.org/show_bug.cgi?id=15507
>
> This patch adds a SNMP value, named TCPDeferAcceptDrop
>
> netstat -s | grep TCPDeferAcceptDrop
> TCPDeferAcceptDrop: 0
>
> This counter is incremented every time we drop a pure ACK frame received
> by a socket in SYN_RECV state because its SYNACK retrans count is lower
> than defer_accept value.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] bonding: flush unicast and multicast lists when changing type
From: David Miller @ 2010-03-22 1:32 UTC (permalink / raw)
To: jpirko; +Cc: netdev, fubar, bonding-devel
In-Reply-To: <20100319140023.GC2811@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Fri, 19 Mar 2010 15:00:23 +0100
> After the type change, addresses in unicast and multicast lists wouldn't make
> sense, not to mention possible different lenghts. So flush both lists here.
>
> Note "dev_addr_discard" will be very soon replaced by "dev_mc_flush" (once
> mc_list conversion will be done).
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied, but maybe these should be EXPORT_SYMBOL_GPL? Just
asking...
^ permalink raw reply
* Re: [PATCH] net: rtnetlink: ignore NETDEV_PRE_TYPE_CHANGE in rtnetlink_event()
From: David Miller @ 2010-03-22 1:31 UTC (permalink / raw)
To: kaber; +Cc: jpirko, netdev
In-Reply-To: <4BA38D50.4090909@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Fri, 19 Mar 2010 15:42:24 +0100
> Ignore the new NETDEV_PRE_TYPE_CHANGE event in rtnetlink_event() since
> there have been no changes userspace needs to be notified of.
>
> Also add a comment to the netdev notifier event definitions to remind
> people to update the exclusion list when adding new event types.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Applied.
^ permalink raw reply
* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: David Miller @ 2010-03-22 1:28 UTC (permalink / raw)
To: herbert; +Cc: timo.teras, netdev
In-Reply-To: <20100320151751.GB2950@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 20 Mar 2010 23:17:51 +0800
> Actually I just realised that the other way we can fix this is
> to make xfrm_dst objects per-cpu just like IPv4 routes. That
> is, when you fail to find an xfrm_dst object in the per-cpu
> cache, you dont' bother calling xfrm_find_bundle but just make
> a new bundle.
How are ipv4 routing cache entries per-cpu? That would screw up route
metrics for TCP sockets quite a lot if they were.
^ permalink raw reply
* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: David Miller @ 2010-03-22 1:26 UTC (permalink / raw)
To: herbert; +Cc: timo.teras, netdev
In-Reply-To: <20100320151751.GB2950@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 20 Mar 2010 23:17:51 +0800
> Now Dave, my impression is that we picked the per-cpu design
> because it was the best data structure we had back in 2002,
> right?
Basically.
It was envisioned that flows at that level of detail would be spread
between different cpus, and that individual flows wouldn't propagate
onto multiple cpus much, if at all. And if they did, no big deal we
have an entry in the cache of those cpus.
Do we know cases where it happens often?
In any event, RCU would certainly fit the bill just as easily and I
have no qualms against going in that direction.
Timo mentioned the socket overrides, we handle them at the top level
right before we look into the flow cache and I think it should stay
that way and we shouldn't bother tossing those into the flow cache at
all. Just my humble opinion on this :-)
^ permalink raw reply
* Re: [PATCH] TCP: check min TTL on received ICMP packets
From: David Miller @ 2010-03-22 1:12 UTC (permalink / raw)
To: stephen.hemminger; +Cc: netdev, pekkas
In-Reply-To: <27142077.3891269129914984.JavaMail.root@tahiti.vyatta.com>
From: Stephen Hemminger <stephen.hemminger@vyatta.com>
Date: Sat, 20 Mar 2010 17:05:14 -0700 (PDT)
>> From: Stephen Hemminger <shemminger@vyatta.com>
>> Date: Thu, 18 Mar 2010 14:27:32 -0700
>>
>> > Please apply to 2.6.33 since it basically a "follow correct RFC"
>> > fix to original GTSM patch.
>>
>
> I meant 2.6.34... min_ttl is not in 2.6.33
Gotcha.
^ permalink raw reply
* Re: [PATCH] Cosmetic:Partially remove deprecated __initcall() and change to
From: Justin P. mattock @ 2010-03-22 1:04 UTC (permalink / raw)
To: Randy Dunlap
Cc: trivial, linux-arm-kernel, linux-audit, uclinux-dist-devel,
linux-cris-kernel, linux-ia64, linux-mips, linux-parisc,
linux-s390, selinux, sparclinux, x86, netdev, linux-kernel
In-Reply-To: <4BA6BAF3.10603@xenotime.net>
On 03/21/2010 05:33 PM, Randy Dunlap wrote:
> On 03/19/10 16:24, Justin P. Mattock wrote:
>> On 03/19/2010 03:56 PM, Randy Dunlap wrote:
>>> On 03/19/10 12:51, Justin P. Mattock wrote:
>>>> After doing some things on a small issue,
>>>> I noticed through web surfing, that there were patches
>>>> submitted pertaining that __initcall is deprecated,
>>>> and device_initcall should be used.
>>>
>>> Where was this discussion? Do you have any pointers to it?
>>>
>>
>> The best info on this is scripts/checkpatch.pl
>> line #2664
>>
>> when I found this I just did a quick search of __initcall
>> (which gives hits here and there)
>> https://patchwork.kernel.org/patch/23344/
>> (also found others at around 2008 or so)
>
> Thanks. IMO there should be something in the kernel source tree
> that says explicitly that __initcall is deprecated and should be
> replaced by using<whatever should be used>. That's missing.
>
agree..
I should of searched the source tree for something
that says deprecated and so forth before doing anything(the
checkpatch.pl was something I noticed down the line but doesn't say
deprecated(say's explicitly).
>
>>> I don't see any mention of __initcall being deprecated in
>>> Linus' mainline git tree, or in linux-next, or in mmotm.
>>> Where are those patches?
>>>
>>
>> I don't know(I'm out of the social pipeline when it comes to Linux news,
>> and updates)..
>> like in the explanation part of the patch
>> I was looking into something else, then ran into this,
>> so as a break(from what I was originally doing)
>> decided to do this and submit.
>>
>>>
>>>> So as a change of subject(since what I was looking at
>>>> was frustrating me),I decided to grep the whole tree
>>>> and make the change(partially).
>>>>
>>>> Currently I'm running this patch on my system, kernel compiles
>>>> without any errors or warnings.(thought there would be a speed increase
>>>> but didn't see much(if any)).
>>>
>>> No, __initcall(x) is just a shorthand version of typing
>>> device_initcall(x). They do the same thing.
>>>
>>
>> yep, that's what I found out as well(reason for the cosmetic
>> in the subject line).
>>
>>>> Biggest problem I have though is testing this on other hardware types
>>>> (I only have a macbook,and an iMac).
>>>> So please if you have the access to other arch/hardware types please
>>>> test.
>>>>
>>>> Now what I mean by partially is the __initcall function is still
>>>> there, so(if any) userspace apps/libs depend on this it's there
>>>> so they dont break and/or any other subsystem, that needs time
>>>> to make the changes.
>>>
>>> The only thing that might be affected is building out-of-tree drivers,
>>> but those are easy to fix.
>>>
>>
>> alright..main concern is making sure things don't break in the
>> kernel(even though things do).
>>
>> I can have a go at the header files, submit
>> then if it's something people agree they want to do, then they
>> can go from there(if not it's fine as well).
>>
>>>> Note:
>>>> the remaining files that still have __initcall in them are:
>>>> (according to grep)
>>>>
>>>> arch/um/include/shared/init.h
>>>> include/linux/init.h
>>>> scripts/checkpatch.pl
>>>>
>>>> either I or somebody else, can change this(although a bit
>>>> concerned about breaking things).
>>>>
>>>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>>> ---
>
>
In any case I'll leave this to you guys to decide.
The patch is in cyberspace now, so if/when this ever
is decided it's there(patch), then can be used then.
Justin P. Mattock
^ 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