* Re: [BUGFIX][PATCH 3/3] memcg/tcp: ignore tcp usage before accounting started
From: David Miller @ 2012-04-02 3:41 UTC (permalink / raw)
To: glommer; +Cc: kamezawa.hiroyu, netdev, akpm
In-Reply-To: <4F742983.1080402@parallels.com>
From: Glauber Costa <glommer@parallels.com>
Date: Thu, 29 Mar 2012 11:21:07 +0200
> On 03/29/2012 09:10 AM, KAMEZAWA Hiroyuki wrote:
>> tcp memcontrol starts accouting after res->limit is set. So, if a sockets
>> starts before setting res->limit, there are already used resource.
>> After setting res->limit, the resource (already used) will be uncharged and
>> make res_counter below 0 because they are not charged. This causes warning.
>>
>> This patch fixes that by adding res_counter_uncharge_nowarn().
>> (*) We cannot avoid this while we have 'account start' switch.
>>
>> Signed-off-by: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com>
>
> Fine by me.
>
> Acked-by: Glauber Costa <glommer@parallels.com>
I'm not applying patches that simply ignore accounting counter
underflows.
You must either:
1) Integrate the socket's existing usage when the limit is set.
2) Avoid accounting completely for a socket that started before
the limit was set.
No half-way solutions, please. Otherwise it is impossible to design
validations of the resource usage for a particular socket or group of
sockets, because they can always be potentially "wrong" and over the
limit. That's a design for a buggy system.
^ permalink raw reply
* Re: [PATCH] net: check the length of the data before dereferencing it
From: Changli Gao @ 2012-04-02 3:45 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, kaber, pablo, netfilter-devel, netdev
In-Reply-To: <20120401.232942.1829187970291547571.davem@davemloft.net>
On Mon, Apr 2, 2012 at 11:29 AM, David Miller <davem@davemloft.net> wrote:
>
> Tag Eric, you're it.
>
> You ACK'd this patch, so you get to show how this is actually able
> to cause some kind of problem.
>
> I assert that this is adding a useless test, that doesn't fix any kind
> of possible crash or misbehavior. If length == 1 at the default:, the
> code will absolutely do the right thing.
>
> Prove me wrong.
Thinking about a malformed tcp segment, which has no data but silly
options, and whose last byte is neither TCPOPT_EOL or TCPOPT_NOP, we
will try to dereference one byte over the boundary when parsing the
options. I know we have skb_shared_info at the end and it won't cause
any crash, but should we rely on this fact?
--
Regards,
Changli Gao(xiaosuo@gmail.com)
--
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: [PATCH] net: check the length of the data before dereferencing it
From: Eric Dumazet @ 2012-04-02 3:45 UTC (permalink / raw)
To: David Miller; +Cc: xiaosuo, kaber, pablo, netfilter-devel, netdev
In-Reply-To: <20120401.232942.1829187970291547571.davem@davemloft.net>
On Sun, 2012-04-01 at 23:29 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 02 Apr 2012 05:19:33 +0200
>
> >> @@ -3845,6 +3845,8 @@ void tcp_parse_options(const struct sk_buff *skb, struct tcp_options_received *o
> >> length--;
> >> continue;
> >> default:
> >> + if (length < 2)
> >> + return;
> >> opsize = *ptr++;
> >> if (opsize < 2) /* "silly options" */
> >> return;
> >
> > Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Tag Eric, you're it.
>
> You ACK'd this patch, so you get to show how this is actually able
> to cause some kind of problem.
>
> I assert that this is adding a useless test, that doesn't fix any kind
> of possible crash or misbehavior. If length == 1 at the default:, the
> code will absolutely do the right thing.
>
> Prove me wrong.
No problem.
You can have NOP,NOP,NOP,EVIL-OPTION
initial length=4 (multiple of 4)
We can read 5 bytes, and access 'out of bound' memory.
Usually not a problem since we have many bytes after our head.
^ permalink raw reply
* Re: [PATCH] net: check the length of the data before dereferencing it
From: Eric Dumazet @ 2012-04-02 3:53 UTC (permalink / raw)
To: Changli Gao; +Cc: David Miller, kaber, pablo, netfilter-devel, netdev
In-Reply-To: <CABa6K_HfWckb=sv7oQatv2ZJm3EKJE0mutQQ-OiddXiR6E7eHg@mail.gmail.com>
On Mon, 2012-04-02 at 11:45 +0800, Changli Gao wrote:
> Thinking about a malformed tcp segment, which has no data but silly
> options, and whose last byte is neither TCPOPT_EOL or TCPOPT_NOP, we
> will try to dereference one byte over the boundary when parsing the
> options. I know we have skb_shared_info at the end and it won't cause
> any crash, but should we rely on this fact?
>
No we cant rely on this, kmemcheck might barf on us.
Your patch (and the netfilter one) is fine.
^ permalink raw reply
* Re: [PATCH] net: check the length of the data before dereferencing it
From: David Miller @ 2012-04-02 3:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiaosuo, kaber, pablo, netfilter-devel, netdev
In-Reply-To: <1333338345.2325.6591.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 02 Apr 2012 05:45:45 +0200
> Usually not a problem since we have many bytes after our head.
We always have bytes after the head, it's guarenteed, and whether it's
garbage bytes or skb_shared_info() it simply doesn't matter.
^ permalink raw reply
* Re: [PATCH] net: check the length of the data before dereferencing it
From: David Miller @ 2012-04-02 3:57 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiaosuo, kaber, pablo, netfilter-devel, netdev
In-Reply-To: <1333338797.2325.6610.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 02 Apr 2012 05:53:17 +0200
> On Mon, 2012-04-02 at 11:45 +0800, Changli Gao wrote:
>
>> Thinking about a malformed tcp segment, which has no data but silly
>> options, and whose last byte is neither TCPOPT_EOL or TCPOPT_NOP, we
>> will try to dereference one byte over the boundary when parsing the
>> options. I know we have skb_shared_info at the end and it won't cause
>> any crash, but should we rely on this fact?
>>
>
> No we cant rely on this, kmemcheck might barf on us.
Give me a break.
The code does the right thing, in every possible case, and
in every possible valid state of an SKB.
If we can't make kmemcheck handle that, tough, I'm not adding useless
tests to a function, specifically tests which are always there and
that don't fix anything.
^ permalink raw reply
* Re: [PATCH] net: check the length of the data before dereferencing it
From: Eric Dumazet @ 2012-04-02 3:58 UTC (permalink / raw)
To: David Miller; +Cc: xiaosuo, kaber, pablo, netfilter-devel, netdev
In-Reply-To: <20120401.235533.147910953675133023.davem@davemloft.net>
On Sun, 2012-04-01 at 23:55 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 02 Apr 2012 05:45:45 +0200
>
> > Usually not a problem since we have many bytes after our head.
>
> We always have bytes after the head, it's guarenteed, and whether it's
> garbage bytes or skb_shared_info() it simply doesn't matter.
Then you have to add a kmemcheck_something() to make this clear and
avoid possible warnings.
^ permalink raw reply
* Re: [PATCH] net: check the length of the data before dereferencing it
From: Eric Dumazet @ 2012-04-02 3:59 UTC (permalink / raw)
To: David Miller; +Cc: xiaosuo, kaber, pablo, netfilter-devel, netdev
In-Reply-To: <20120401.235724.1615627410446519543.davem@davemloft.net>
On Sun, 2012-04-01 at 23:57 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 02 Apr 2012 05:53:17 +0200
>
> > On Mon, 2012-04-02 at 11:45 +0800, Changli Gao wrote:
> >
> >> Thinking about a malformed tcp segment, which has no data but silly
> >> options, and whose last byte is neither TCPOPT_EOL or TCPOPT_NOP, we
> >> will try to dereference one byte over the boundary when parsing the
> >> options. I know we have skb_shared_info at the end and it won't cause
> >> any crash, but should we rely on this fact?
> >>
> >
> > No we cant rely on this, kmemcheck might barf on us.
>
> Give me a break.
Sure. End of discussion.
^ permalink raw reply
* Re: [PATCH] net: check the length of the data before dereferencing it
From: David Miller @ 2012-04-02 4:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiaosuo, kaber, pablo, netfilter-devel, netdev
In-Reply-To: <1333339105.2325.6622.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 02 Apr 2012 05:58:25 +0200
> On Sun, 2012-04-01 at 23:55 -0400, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Mon, 02 Apr 2012 05:45:45 +0200
>>
>> > Usually not a problem since we have many bytes after our head.
>>
>> We always have bytes after the head, it's guarenteed, and whether it's
>> garbage bytes or skb_shared_info() it simply doesn't matter.
>
> Then you have to add a kmemcheck_something() to make this clear and
> avoid possible warnings.
That's perfectly fine and would document the situation. And we can
add a similar annotation to the two other nearly identical pieces of
code in net/netfilter/nf_conntrack_proto_tcp.c
^ permalink raw reply
* Re: [PATCH firmware 1/3] rtl_nic: update firmware for RTL8111E-VL
From: Ben Hutchings @ 2012-04-02 4:26 UTC (permalink / raw)
To: Hayes Wang; +Cc: dwmw2, romieu, netdev, kernel-team, linux-kernel
In-Reply-To: <1332840075-5991-1-git-send-email-hayeswang@realtek.com>
[-- Attachment #1: Type: text/plain, Size: 125 bytes --]
Applied all 3, thanks.
Ben.
--
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] net: check the length of the data before dereferencing it
From: Changli Gao @ 2012-04-02 4:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, kaber, pablo, netfilter-devel, netdev
In-Reply-To: <1333338797.2325.6610.camel@edumazet-glaptop>
On Mon, Apr 2, 2012 at 11:53 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> No we cant rely on this, kmemcheck might barf on us.
>
> Your patch (and the netfilter one) is fine.
>
>
Got it. Thanks. FYI, the tcp options are copied to the stack before
being parsed.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] net: check the length of the data before dereferencing it
From: Eric Dumazet @ 2012-04-02 4:54 UTC (permalink / raw)
To: Changli Gao; +Cc: David Miller, kaber, pablo, netfilter-devel, netdev
In-Reply-To: <CABa6K_Hc7ZVVR6XvhEXKHNf_YNnrMNQLBTbxksvAJwAV9fer6w@mail.gmail.com>
On Mon, 2012-04-02 at 12:47 +0800, Changli Gao wrote:
> Got it. Thanks. FYI, the tcp options are copied to the stack before
> being parsed.
>
What do you mean ?
code looks like :
const struct tcphdr *th = tcp_hdr(skb);
int length = (th->doff * 4) - sizeof(struct tcphdr);
ptr = (const unsigned char *)(th + 1);
Therefore ptr points somewhere in skb->head ...
^ permalink raw reply
* Re: [PATCH V2 net-next 00/28] ethtool: support time stamping and phc clocks
From: David Miller @ 2012-04-02 4:55 UTC (permalink / raw)
To: richardcochran
Cc: mporter, e1000-devel, netdev, jacob.e.keller, john.ronciak,
bhutchings
In-Reply-To: <cover.1333289292.git.richardcochran@gmail.com>
From: Richard Cochran <richardcochran@gmail.com>
Date: Sun, 1 Apr 2012 17:19:45 +0200
> Support for SO_TIMESTAMPING of network packets and PTP Hardware Clocks
> has been expanding over the last year or two. In an ideal world, every
> host would have exactly one PTP hardware clock, and every Ethernet MAC
> would support SO_TIMESTAMPING on both the transmit and receive paths.
> However, since we do not yet have full coverage for these features,
> user space programs need a way to discover what a given interface
> supports in these two areas.
...
> This series exposes the hardware and driver capabilities known to user
> space via ethtool.
>
> Since the PHC code was first merged, this has become the number one
> requested new feature.
>
> Patch number 3 applies on top of my recent two igb/phc patches.
> Patch number 12 applies on top of my recent e100 patch.
>
> The new feature has been tested on the following hardware:
>
> igb Hardware time stamping in the MAC
> dp83640 Hardware time stamping in the PHY
> r8169 Software Tx time stamping in the MAC
No real objections from me, Ben?
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 21/51] ipvs: Stop using NLA_PUT*().
From: Simon Horman @ 2012-04-02 5:01 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <1333335521-1348-22-git-send-email-davem@davemloft.net>
On Sun, Apr 01, 2012 at 10:58:11PM -0400, David S. Miller wrote:
> From: "David S. Miller" <davem@davemloft.net>
>
> These macros contain a hidden goto, and are thus extremely error
> prone and make code hard to audit.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Hi Dave,
do you want me to take this patch or do you plan to take it directly?
In any case
Acked-by: Simon Horman <horms@verge.net.au>
^ permalink raw reply
* Re: [PATCH 21/51] ipvs: Stop using NLA_PUT*().
From: David Miller @ 2012-04-02 5:03 UTC (permalink / raw)
To: horms; +Cc: netdev
In-Reply-To: <20120402050142.GA20454@verge.net.au>
From: Simon Horman <horms@verge.net.au>
Date: Mon, 2 Apr 2012 14:01:49 +0900
> do you want me to take this patch or do you plan to take it directly?
I plan to take the whole series, otherwise I can't put the
commit in at the end that deletes these interfaces.
> Acked-by: Simon Horman <horms@verge.net.au>
Thanks.
^ permalink raw reply
* Re: [PATCH] via-rhine: fix wait-bit inversion.
From: Andreas Mohr @ 2012-04-02 5:43 UTC (permalink / raw)
To: David Miller; +Cc: romieu, netdev, andi, DavidLv
In-Reply-To: <20120401.231044.2143460898946854493.davem@davemloft.net>
Hi,
On Sun, Apr 01, 2012 at 11:10:44PM -0400, David Miller wrote:
> From: Francois Romieu <romieu@fr.zoreil.com>
> Date: Mon, 2 Apr 2012 00:35:00 +0200
>
> > From: Andreas Mohr <andi@lisas.de>
> >
> > Bug appeared in a384a33bb1c9ec2d99db2046b41f57023fa7d77b
> > ("via-rhine: RHINE_WAIT_FOR macro removal). It can be noticed
> > during suspend/resume.
> >
> > Signed-off-by: Andreas Mohr <andi@lisas.de>
> > Acked-by: Francois Romieu <romieu@fr.zoreil.com>
> > Cc: David Lv <DavidLv@viatech.com.cn>
>
> Applied and queued up for -stable, thanks.
Fully happy with all "automatisms" (Signed-off-by etc. -
I didn't bother at that time for such a minor step),
thank you for very fast/cooperative handling to all involved parties!
Side note (not mentioned yet): that fix was sufficient to get HEAD
(well, at least f2cedb63df14342) working, too.
Thanks,
Andreas Mohr
^ permalink raw reply
* Re: [PATCH 21/51] ipvs: Stop using NLA_PUT*().
From: Simon Horman @ 2012-04-02 6:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120402.010302.1302861329843358875.davem@davemloft.net>
On Mon, Apr 02, 2012 at 01:03:02AM -0400, David Miller wrote:
> From: Simon Horman <horms@verge.net.au>
> Date: Mon, 2 Apr 2012 14:01:49 +0900
>
> > do you want me to take this patch or do you plan to take it directly?
>
> I plan to take the whole series, otherwise I can't put the
> commit in at the end that deletes these interfaces.
Thanks, got it.
^ permalink raw reply
* Re: [PATCH] net: check the length of the data before dereferencing it
From: Changli Gao @ 2012-04-02 6:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, kaber, pablo, netfilter-devel, netdev
In-Reply-To: <1333342467.2325.6739.camel@edumazet-glaptop>
On Mon, Apr 2, 2012 at 12:54 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2012-04-02 at 12:47 +0800, Changli Gao wrote:
>
>> Got it. Thanks. FYI, the tcp options are copied to the stack before
>> being parsed.
>>
>
> What do you mean ?
>
> code looks like :
>
> const struct tcphdr *th = tcp_hdr(skb);
> int length = (th->doff * 4) - sizeof(struct tcphdr);
>
> ptr = (const unsigned char *)(th + 1);
>
>
>
> Therefore ptr points somewhere in skb->head ...
>
>
>
Oh, sorry. I forgot to add the condition when I wrote it down. I mean
the code in netfilter.
unsigned char buff[(15 * 4) - sizeof(struct tcphdr)];
const unsigned char *ptr;
int length = (tcph->doff*4) - sizeof(struct tcphdr);
if (!length)
return;
ptr = skb_header_pointer(skb, dataoff + sizeof(struct tcphdr),
length, buff);
BUG_ON(ptr == NULL);
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] net: check the length of the data before dereferencing it
From: Eric Dumazet @ 2012-04-02 6:43 UTC (permalink / raw)
To: Changli Gao; +Cc: David Miller, kaber, pablo, netfilter-devel, netdev
In-Reply-To: <CABa6K_GUMGC-cWPJyG_EcX_J3+w3cq4eZhuYqZYFgbcHHaXCNQ@mail.gmail.com>
On Mon, 2012-04-02 at 14:27 +0800, Changli Gao wrote:
> On Mon, Apr 2, 2012 at 12:54 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Mon, 2012-04-02 at 12:47 +0800, Changli Gao wrote:
> >
> >> Got it. Thanks. FYI, the tcp options are copied to the stack before
> >> being parsed.
> >>
> >
> > What do you mean ?
> >
> > code looks like :
> >
> > const struct tcphdr *th = tcp_hdr(skb);
> > int length = (th->doff * 4) - sizeof(struct tcphdr);
> >
> > ptr = (const unsigned char *)(th + 1);
> >
> >
> >
> > Therefore ptr points somewhere in skb->head ...
> >
> >
> >
>
> Oh, sorry. I forgot to add the condition when I wrote it down. I mean
> the code in netfilter.
>
> unsigned char buff[(15 * 4) - sizeof(struct tcphdr)];
> const unsigned char *ptr;
> int length = (tcph->doff*4) - sizeof(struct tcphdr);
>
> if (!length)
> return;
>
> ptr = skb_header_pointer(skb, dataoff + sizeof(struct tcphdr),
> length, buff);
> BUG_ON(ptr == NULL);
>
Doesnt really save us, skb_header_pointer() copies only if block not
directly and fully accessible in skb->head
So if skb->head contains exactly the tcp options, we still can read one
uninit byte.
So potential problem in netfilter too.
^ permalink raw reply
* How to enable phy's interrupt correctly using phylib?
From: lin jason @ 2012-04-02 8:16 UTC (permalink / raw)
To: netdev
Dear:
The design is a MAC connected to a Marvell phy.
Phy's interrupt will be triggered for some conditions, like link status changed,
and then it will trigger MAC's interrupt.
But phy itself has no direct interrupt connected to CPU.
I used phylib to implement the network driver (MAC driver).
When link status changed, I need to do something in MAC's irq.
In linux 2.6.36, I used phy_enable_interrupts() in MAC driver.
But after linux 2.6.37, this function is not used directly by any drivers.
Interrupt connection:
PHY ------> MAC ------> CPU
How to enable phy's interrupt correctly using phylib?
^ permalink raw reply
* [RFC] How to enable phy's interrupt correctly using phylib?
From: lin jason @ 2012-04-02 8:41 UTC (permalink / raw)
To: netdev
Dear:
Sorry for the previous message with no category.
------------------------------------------------------------------------------------
The design is a MAC connected to a Marvell phy.
Phy's interrupt will be triggered for some conditions, like link status changed,
and then it will trigger MAC's interrupt.
But phy itself has no direct interrupt connected to CPU.
I used phylib to implement the network driver (MAC driver).
When link status changed, I need to do something in MAC's irq.
In linux 2.6.36, I used phy_enable_interrupts() in MAC driver.
But after linux 2.6.37, this function is not used directly by any drivers.
Interrupt connection:
PHY ------> MAC ------> CPU
Maybe you can use phy_start_interrupts().
But the phy has no interrupt connected to CPU,
it will failed when request_irq().
And it will not execute phy_enable_interrupts(phydev).
How to enable phy's interrupt correctly using phylib?
^ permalink raw reply
* RE: [REGRESSION][PATCH V4 1/3] bpf jit: Make the filter.c::__load_pointer helper non-static for the jits
From: David Laight @ 2012-04-02 9:18 UTC (permalink / raw)
To: Jan Seiffert, netdev
Cc: linux-kernel, linuxppc-dev, Matt Evans, Eric Dumazet,
David S. Miller
In-Reply-To: <4F75CC63.10405@googlemail.com>
> The function is renamed to make it a little more clear what it does.
> It is not added to any .h because it is not for general
> consumption, only for bpf internal use (and so by the jits).
I'd have thought it better to put in into a bfp_internal.h
(or similar) with a big warning there about the asm users.
Possibly even worth adding some other defs that the asm
files will need (if there are any).
David
^ permalink raw reply
* Re: [PATCH] Implement IP_EVIL socket option (RFC 3514)
From: Martin Lucina @ 2012-04-02 9:24 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <20120401.152048.267766557618433051.davem@davemloft.net>
davem@davemloft.net said:
>
> I'm extremely disappointed with the april fools submissions this
> year to be honest...
Well, with Anonymous making their own distro, and the advertised "takedown
of the Internet" on Saturday, it seemed timeley. I guess I should have
written a more convincing blurb in the commit message...
--
Martin Lucina
http://lucina.net/ (interwebs/blogs/rants/consulting)
martin@lucina.net (smtp/xmpp/jabber/gtalk)
@matolucina (twitter)
^ permalink raw reply
* RE: [RFC] net: bpf_jit: Two pass JIT and other changes
From: David Laight @ 2012-04-02 9:28 UTC (permalink / raw)
To: Indan Zupancic, Eric Dumazet, netdev, linux-kernel
In-Reply-To: <5185e05a69d88b5f12b5656358745b1a.squirrel@webmail.greenhost.nl>
> 1) Sadly, gcc isn't always smart enough to inline emit_code().
> So turn it into a macro to force gcc to inline it. This saves
> about 500 bytes. Tested with gcc 4.6.0. An alternative to the
> macro would be to create inline emit_code1(), emit_code2() etc.
Does giving it the __attribute__((always_inline)) help?
I had to mark a load of small static functions that way
after a minor change (possibly to the overall size)
stopped gcc inlining everything.
I have also noticed in the past that gcc tends to generate
better code for #define than when inlining functions.
David
^ permalink raw reply
* Re: [PATCH] Implement IP_EVIL socket option (RFC 3514)
From: David Miller @ 2012-04-02 9:35 UTC (permalink / raw)
To: martin; +Cc: linux-kernel, netdev
In-Reply-To: <20120402092410.GA7601@dezo.moloch.sk>
From: Martin Lucina <martin@lucina.net>
Date: Mon, 2 Apr 2012 11:24:10 +0200
> davem@davemloft.net said:
>>
>> I'm extremely disappointed with the april fools submissions this
>> year to be honest...
>
> Well, with Anonymous making their own distro, and the advertised "takedown
> of the Internet" on Saturday, it seemed timeley. I guess I should have
> written a more convincing blurb in the commit message...
It wasn't the blurb it was simply that you're at least the third
person to submit a patch like this over the years, here's one:
http://www.version6.net/patches/linux-2.4.20-rfc3514.dif
Someone did a netfilter iptables module too:
http://www.gossamer-threads.com/lists/linux/kernel/431645
^ 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