* Server Rental Service in HK
From: boris @ 2012-04-02 9:47 UTC (permalink / raw)
Dear All,
We have our own datacenter in Hong Kong & provide email/application/web rental service to clients.We are APNIC member & provide clean IP to clients.
Dell? PowerEdge? EnterpriseRack Mount Server
-Intel(R) Xeon(R) E3-1240 Processor (3.3GHz, 8M Cache, Turbo, 4C/8T, 80W)
-8GB RAM, 2x4GB, 1333MHz, DDR-3, Dual Ranked UDIMMs
-500GB, 3.5", 6Gbps SAS x 2
-Raid 1 Mirroring Protection
-Remote KVM (iDRAC6 Enterprise)
Dell(TM) PowerEdge(TM) R410 Rack Mount Server
-Intel(R) Quad Core E5606 Xeon(R) CPU, 2.13GHz, 4M Cache, 4.86 GT/s QPI
-4GB Memory (2x2GB), 1333MHz Dual Ranked RDIMMs Fully-Buffered
-500GB 7.2K RPM SATAII 3.5" Hard Drive x 2
-iDRAC6 Enterprise or Express (Remote KVM Management)
Every Dedicated Server Hosting Solution Also Includes:
Software Specification
- CentOS / Fedora / Debian / FreeBSD / Ubuntu / Redhat Linux
- Full root-level access
- Data Center Facilities
- Shared Local & International Bandwidth
- 2 IP Addresses Allocation
- Un-interruptible Power Supply (UPS) backed up by private diesel generator
- FM200¡§based fire suppression system
- 24x7 CRAC Air Conditioning and Humidity Control
- 24x7 Security Control
- 24x7 Remote Hand Service
Pls send us email for further information.Thanks,
Boris
boris@cloudluca.com
If you do not wish to further receive this event message, email "borislamsv2@gmail.com" to unsubscribe this message or remove your email from the list.
^ permalink raw reply
* [PATCH 3.3.0] phy:icplus:fix Auto Power Saving in ip101a_config_init.
From: Srinivas KANDAGATLA @ 2012-04-02 10:02 UTC (permalink / raw)
To: netdev; +Cc: davem, peppe.cavallaro, srinivas.kandagatla
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch fixes Auto Power Saving configuration in ip101a_config_init
which was broken as there is no phy register write followed after
setting IP101A_APS_ON flag.
This patch also fixes the return value of ip101a_config_init.
Without this patch ip101a_config_init returns 2 which is not an error
accroding to IS_ERR and the mac driver will continue accessing 2 as
valid pointer to phy_dev resulting in memory fault.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
Hi All,
This patch fixes broken ip101a_config_init in icplus.c.
Thanks,
srini
drivers/net/phy/icplus.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/icplus.c b/drivers/net/phy/icplus.c
index 0856e1b..f08c85a 100644
--- a/drivers/net/phy/icplus.c
+++ b/drivers/net/phy/icplus.c
@@ -162,7 +162,8 @@ static int ip101a_g_config_init(struct phy_device *phydev)
/* Enable Auto Power Saving mode */
c = phy_read(phydev, IP10XX_SPEC_CTRL_STATUS);
c |= IP101A_G_APS_ON;
- return c;
+
+ return phy_write(phydev, IP10XX_SPEC_CTRL_STATUS, c);
}
static int ip175c_read_status(struct phy_device *phydev)
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Implement IP_EVIL socket option (RFC 3514)
From: Martin Lucina @ 2012-04-02 9:42 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <20120402.053544.1502825597915995582.davem@davemloft.net>
davem@davemloft.net said:
> 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
I missed the former patch completely, sorry about that. Googling for "evil
bit implementation" did turn up the ipt_evil patch but no corresponding
patch to actually let an application *set* the bit.
--
Martin Lucina
http://lucina.net/ (interwebs/blogs/rants/consulting)
martin@lucina.net (smtp/xmpp/jabber/gtalk)
@matolucina (twitter)
^ permalink raw reply
* Re: [PATCH v5 2/2] Ethernet driver for the WIZnet W5100 chip
From: Mike Sinkovsky @ 2012-04-02 9:40 UTC (permalink / raw)
To: Mark Brown; +Cc: netdev, linux-kernel
In-Reply-To: <20120331212303.GB19965@sirena.org.uk>
01.04.2012 3:23, Mark Brown wrote:
> On Fri, Mar 30, 2012 at 01:00:06PM +0600, Mike Sinkovsky wrote:
>
>> +config WIZNET_W5100
>> + tristate "WIZnet W5100 Ethernet support"
>> + depends on ARM || BLACKFIN
>
> What are the architecture dependencies here?
Original driver from chip manufacturer was written for ARM, and now we
use it on Blackfin.
Completely untested on other arch's, but should work. Maybe.
>> +static irqreturn_t w5100_interrupt(int irq, void *ndev_instance)
>> +{
>> + struct net_device *ndev = ndev_instance;
>> + struct w5100_priv *priv = netdev_priv(ndev);
>> +
>> + int ir = w5100_read(priv, W5100_S0_IR);
>> + w5100_write(priv, W5100_S0_IR, ir);
>> +
>> + if (ir& S0_IR_RECV) {
>> + if (napi_schedule_prep(&priv->napi)) {
>> + w5100_write(priv, W5100_IMR, 0);
>> + mmiowb();
>> + __napi_schedule(&priv->napi);
>> + }
>> + }
>> +
>> + if (ir& S0_IR_SENDOK) {
>> + if (unlikely(netif_queue_stopped(ndev)))
>> + netif_wake_queue(ndev);
>> + }
>> +
>> + return IRQ_HANDLED;
>
> This unconditionally acknowledges the interrupt even if one wasn't
> reported by the device.
Hm? Don't get you.
W5100_S0_IR register is R/W1C - writing back clears it.
Or what do you mean?
>> + irq = platform_get_irq(pdev, 0);
>> + if (irq< 0)
>> + return irq;
>> + ret = devm_request_irq(&pdev->dev, irq, w5100_interrupt,
>> + IRQ_TYPE_LEVEL_LOW, name, ndev);
>> + if (ret< 0)
>> + return ret;
>> + priv->irq = irq;
>> +
>> + link = platform_get_resource(pdev, IORESOURCE_IO, 0);
>> + if (!link) {
>> + priv->link_gpio = -1;
>
> This is rather an abuse of the resource API and will run into trouble on
> device tree based systems. You should use platform data for non-DT
> systems.
Ok, will move it to struct wiznet_platform_data.
But here is downside - this gpio is optional, and if board doesn't have
it - it must be initialized as negative value, not just omitted.
>> + if (request_irq(priv->link_irq, w5100_detect_link,
>> + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
>> + link_name, priv->ndev)< 0)
>
> Suggest using request_any_context_irq() to increase the range of
> supported interrupt controllers.
Could it be anything but hard irq?
But there is another bug - it should be devm_request_irq...
:)
>> +err_register:
>> + free_netdev(ndev);
>> + platform_set_drvdata(pdev, NULL);
>> + dev_info(&pdev->dev, "probe failed (%d)\n", err);
>
> This will be done for you by the driver core.
You mean platform_set_drvdata() and dev_info()? Maybe.
I'm sure platform_driver will not do free_netdev() for me.
--
Mike
^ 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
* 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: 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: [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
* [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
* 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
* 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
* 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 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] 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: 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 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 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] 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] 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 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: 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] 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: 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: 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: 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
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