* Re: [PATCH 2/3] net: packet: fix information leak to userland
From: Vasiliy Kulikov @ 2010-11-07 12:06 UTC (permalink / raw)
To: walter harms
Cc: kernel-janitors, David S. Miller, Jiri Pirko, Eric Dumazet,
netdev, linux-kernel
In-Reply-To: <4CD68F7E.5050407@bfs.de>
On Sun, Nov 07, 2010 at 12:37 +0100, walter harms wrote:
> Am 06.11.2010 15:39, schrieb Vasiliy Kulikov:
> > On Mon, Nov 01, 2010 at 10:14 +0100, walter harms wrote:
> >> Vasiliy Kulikov schrieb:
> >>> @@ -1719,7 +1719,7 @@ static int packet_getname_spkt(struct socket *sock, struct sockaddr *uaddr,
> >>> rcu_read_lock();
> >>> dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex);
> >>> if (dev)
> >>> - strlcpy(uaddr->sa_data, dev->name, 15);
> >>> + strncpy(uaddr->sa_data, dev->name, 14);
> >>> else
> >>> memset(uaddr->sa_data, 0, 14);
> >>
> >> if i understand the code correcly the max size for dev->name is IFNAMSIZ.
> >
> > For dev->name - IFNAMSIZ, for uaddr->sa_data - 14.
> >
>
>
> did not notice, since uaddr->sa_data should take dev->name this does no look very
> clever. How is the size of sa_data defined ?
Magic size...
~/linux/include/linux/socket.h:
struct sockaddr {
sa_family_t sa_family; /* address family, AF_xxx */
char sa_data[14]; /* 14 bytes of protocol address */
};
> Would it hurt when some uses IFNAMSIZ here ?
If copy _to_ sa_data string of maximum IFNAMSIZ bytes - yes.
In packet_getname_spkt() the output buffer is 128 bytes, so it doesn't
really overflows anything. I don't think that *_getname() implementations
don't know this.
> Perhaps someone who know more about the network stack can figure out what is actualy done
> with uaddr->sa_data.
Yeah, also I wonder whether it is always NULL-terminated string or not.
> looks like a can of worms.
>
>
> In packet_bind_spkt() they will copy a char[15], obviously it is a real problem.
No, packet_bind_spkt() copies 14-byte string into array of 15 bytes.
The vice versa would be a bug.
> re,
> wh
>
>
> >> You can simply that part:
> >>
> >> memset(uaddr->sa_data, 0, IFNAMSIZ);
> >> dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex);
> >> if (dev)
> >> strlcpy(uaddr->sa_data, dev->name, IFNAMSIZ);
> >
> > This will overflow uaddr->sa_data. Also I don't see any difficulty to
> > fill the array only once.
> >
> >> you should send that as separate patch.
> >> re,
> >> wh
> >>
> >>
> >>> rcu_read_unlock();
> >>> @@ -1742,6 +1742,7 @@ static int packet_getname(struct socket *sock, struct sockaddr *uaddr,
> >>> sll->sll_family = AF_PACKET;
> >>> sll->sll_ifindex = po->ifindex;
> >>> sll->sll_protocol = po->num;
> >>> + sll->sll_pkttype = 0;
> >>> rcu_read_lock();
> >>> dev = dev_get_by_index_rcu(sock_net(sk), po->ifindex);
> >>> if (dev) {
> >
> > Thanks,
> >
--
Vasiliy
^ permalink raw reply
* Re: [PATCH] firewire: net: rate-limit log spam at transmit failure
From: Maxim Levitsky @ 2010-11-07 12:04 UTC (permalink / raw)
To: Stefan Richter; +Cc: linux1394-devel, netdev@vger.kernel.org
In-Reply-To: <4CD68925.8080302@s5r6.in-berlin.de>
On Sun, 2010-11-07 at 12:10 +0100, Stefan Richter wrote:
> Maxim Levitsky wrote:
> > On Sun, 2010-11-07 at 00:23 +0100, Stefan Richter wrote:
> >> On 6 Nov, Stefan Richter wrote:
> >>> Then I tried an XIO2213A card in the AMD PC (again the Intel PC as peer)
> >>> and got 243 times "failed: 12" i.e. RCODE_BUSY and 81 times "failed: 10"
> >>> i.e. RCODE_SEND_ERROR during ftp transfer of a >500 MB large file from
> >>> XIO2213A to FW323.
> >
> > I also am getting strange results (but very good compared to what I had
> > recently).
> >
> > With all your patches, I get very stable TCP and UDP streams from laptop
> > to desktop at 180~190 Mbits/s.
> >
> > However, the opposite direction (desktop->laptop) still suffers from
> > tlabel exhaustion.
> > I added some printks, and I see, clearly that netif_stop_queue doesn't
> > always work (probably this is intended?).
> >
> > If I replace == with >= in inc_queue_packets and similar in
> > dec_queued_packets, then tlabel exhaustion disappears, and I get ~240
> > Mbit/s on TCP and UDP.
>
> Remind me, is this FireWire 800? And what controllers in particular? I get
> about half of your numbers with FireWire 400 connections.
Firewire 400.
Laptop: Ricoh R5C832
Desktop: TI TSB43AB22A
>
> The == vs. >= is a good hint. If .ndo_start_xmit can be entered by multiple
> CPUs, the upper limit will clearly exceeded eventually.
>
> With >= instead of ==, the same test as that quoted above gives 71x RCODE_BUSY
> + 0x RCODE_SEND_ERROR, and 59x RCODE_BUSY + 0x RCODE_SEND_ERROR in a
> repetition. (0x + 0x in the other direction.) There were no RCODE_CANCELLED
> occurrences, which I had occasionally in the past.
RCODE_CANCELLED is result of timeout timer which is set to run with 0
jiffies in the future.
>
> I then tried
>
> if (dev->queued_packets >= FWNET_MAX_QUEUED_PACKETS)
> return NETDEV_TX_BUSY;
>
> at the top of fwnet_tx but it did not change the amount of RCODE_BUSY, which
> is not too surprising. So next I should have a look at the responder side again.
I see RCODE_BUSY sometimes too.
>
> BTW, FireWire 400 CardBus controllers usually feature a limitation of max_rec
> = 1024 (maximum size of asynchronous packets they can receive). Incidentally,
> the VT6306 card that I used in my other tests from yesterday is one of those.
> So, since link fragmentation is quite common due to this kind of cards, I
> should perhaps count queued fragments instead of queued datagrams.
>
> > UDP transfers work quite well, tested for few minutes.
> > TCP transfers unfortunelly trigger (probably a hardware) bug in notebook
> > OHCI controller (I have seen that meny times so far.)
> >
> > Transfer just stops, and controller goes south.
> > If I unload the firewire-ohci, then when I load it:
> >
> > [ 2062.632532] firewire_ohci 0000:07:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> > [ 2072.650173] firewire_ohci: Failed to reset ohci card.
> > [ 2072.650267] firewire_ohci 0000:07:00.0: PCI INT A disabled
> > [ 2072.650314] firewire_ohci: probe of 0000:07:00.0 failed with error -16
> >
> >
> > Only suspend to ram helps bring it back from that state.
>
> On the bright side, s2ram fixes things for once instead of breaking them...
Well, of course after s2ram I have to reload the firewire-ohci to make
it work, but that is separate issue.
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [PATCH] firewire: net: rate-limit log spam at transmit failure
From: Stefan Richter @ 2010-11-07 12:03 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux1394-devel, netdev@vger.kernel.org
In-Reply-To: <1289100737.3277.32.camel@maxim-laptop>
Maxim Levitsky wrote:
> I have here my own hack to set the transaction timeout,
You can use firecontrol to set it on-the-fly. To set it on node ffc2 i.e. the
node with phy ID 2, and controller 1 (i.e. libraw1394 "port" 1):
# echo "w . 2 0xfffff0000018 4 3" | firecontrol 1
This sets the whole-seconds part to 3, which gives you 3.1 seconds timeout if
the fractional part at 0xfffff000001c is still at its default value of 0.1
seconds, i.e. 800 << 19 (subsecond part in units of (1/8000)s shifted by 19).
# { echo "r . 2 0xfffff0000018 4"; echo "r . 2 0xfffff000001c 4"; } |
firecontrol 1
displays the current register value on node ffc2 at port 1. Type "help" in
firecontrol for more available firecontrol commands.
--
Stefan Richter
-=====-==-=- =-== --===
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 2/3] net: packet: fix information leak to userland
From: walter harms @ 2010-11-07 11:37 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kernel-janitors, David S. Miller, Jiri Pirko, Eric Dumazet,
netdev, linux-kernel
In-Reply-To: <20101106143911.GA17428@albatros>
Am 06.11.2010 15:39, schrieb Vasiliy Kulikov:
> On Mon, Nov 01, 2010 at 10:14 +0100, walter harms wrote:
>>
>>
>> Vasiliy Kulikov schrieb:
>>> packet_getname_spkt() doesn't initialize all members of sa_data field of
>>> sockaddr struct if strlen(dev->name) < 13. This structure is then copied
>>> to userland. It leads to leaking of contents of kernel stack memory.
>>> We have to fully fill sa_data with strncpy() instead of strlcpy().
>>>
>>> The same with packet_getname(): it doesn't initialize sll_pkttype field of
>>> sockaddr_ll. Set it to zero.
>>>
>>> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
>>> ---
>>> net/packet/af_packet.c | 3 ++-
>>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
>>> index 3616f27..0856a13 100644
>>> --- a/net/packet/af_packet.c
>>> +++ b/net/packet/af_packet.c
>>> @@ -1719,7 +1719,7 @@ static int packet_getname_spkt(struct socket *sock, struct sockaddr *uaddr,
>>> rcu_read_lock();
>>> dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex);
>>> if (dev)
>>> - strlcpy(uaddr->sa_data, dev->name, 15);
>>> + strncpy(uaddr->sa_data, dev->name, 14);
>>> else
>>> memset(uaddr->sa_data, 0, 14);
>>
>> if i understand the code correcly the max size for dev->name is IFNAMSIZ.
>
> For dev->name - IFNAMSIZ, for uaddr->sa_data - 14.
>
did not notice, since uaddr->sa_data should take dev->name this does no look very
clever. How is the size of sa_data defined ? Would it hurt when some uses IFNAMSIZ here ?
Perhaps someone who know more about the network stack can figure out what is actualy done
with uaddr->sa_data.
looks like a can of worms.
In packet_bind_spkt() they will copy a char[15], obviously it is a real problem.
re,
wh
>> You can simply that part:
>>
>> memset(uaddr->sa_data, 0, IFNAMSIZ);
>> dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex);
>> if (dev)
>> strlcpy(uaddr->sa_data, dev->name, IFNAMSIZ);
>
> This will overflow uaddr->sa_data. Also I don't see any difficulty to
> fill the array only once.
>
>> you should send that as separate patch.
>> re,
>> wh
>>
>>
>>> rcu_read_unlock();
>>> @@ -1742,6 +1742,7 @@ static int packet_getname(struct socket *sock, struct sockaddr *uaddr,
>>> sll->sll_family = AF_PACKET;
>>> sll->sll_ifindex = po->ifindex;
>>> sll->sll_protocol = po->num;
>>> + sll->sll_pkttype = 0;
>>> rcu_read_lock();
>>> dev = dev_get_by_index_rcu(sock_net(sk), po->ifindex);
>>> if (dev) {
>
> Thanks,
>
^ permalink raw reply
* Re: [PATCH] firewire: net: rate-limit log spam at transmit failure
From: Stefan Richter @ 2010-11-07 11:10 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: netdev@vger.kernel.org, linux1394-devel
In-Reply-To: <1289100404.3277.28.camel@maxim-laptop>
Maxim Levitsky wrote:
> On Sun, 2010-11-07 at 00:23 +0100, Stefan Richter wrote:
>> On 6 Nov, Stefan Richter wrote:
>>> Then I tried an XIO2213A card in the AMD PC (again the Intel PC as peer)
>>> and got 243 times "failed: 12" i.e. RCODE_BUSY and 81 times "failed: 10"
>>> i.e. RCODE_SEND_ERROR during ftp transfer of a >500 MB large file from
>>> XIO2213A to FW323.
>
> I also am getting strange results (but very good compared to what I had
> recently).
>
> With all your patches, I get very stable TCP and UDP streams from laptop
> to desktop at 180~190 Mbits/s.
>
> However, the opposite direction (desktop->laptop) still suffers from
> tlabel exhaustion.
> I added some printks, and I see, clearly that netif_stop_queue doesn't
> always work (probably this is intended?).
>
> If I replace == with >= in inc_queue_packets and similar in
> dec_queued_packets, then tlabel exhaustion disappears, and I get ~240
> Mbit/s on TCP and UDP.
Remind me, is this FireWire 800? And what controllers in particular? I get
about half of your numbers with FireWire 400 connections.
The == vs. >= is a good hint. If .ndo_start_xmit can be entered by multiple
CPUs, the upper limit will clearly exceeded eventually.
With >= instead of ==, the same test as that quoted above gives 71x RCODE_BUSY
+ 0x RCODE_SEND_ERROR, and 59x RCODE_BUSY + 0x RCODE_SEND_ERROR in a
repetition. (0x + 0x in the other direction.) There were no RCODE_CANCELLED
occurrences, which I had occasionally in the past.
I then tried
if (dev->queued_packets >= FWNET_MAX_QUEUED_PACKETS)
return NETDEV_TX_BUSY;
at the top of fwnet_tx but it did not change the amount of RCODE_BUSY, which
is not too surprising. So next I should have a look at the responder side again.
BTW, FireWire 400 CardBus controllers usually feature a limitation of max_rec
= 1024 (maximum size of asynchronous packets they can receive). Incidentally,
the VT6306 card that I used in my other tests from yesterday is one of those.
So, since link fragmentation is quite common due to this kind of cards, I
should perhaps count queued fragments instead of queued datagrams.
> UDP transfers work quite well, tested for few minutes.
> TCP transfers unfortunelly trigger (probably a hardware) bug in notebook
> OHCI controller (I have seen that meny times so far.)
>
> Transfer just stops, and controller goes south.
> If I unload the firewire-ohci, then when I load it:
>
> [ 2062.632532] firewire_ohci 0000:07:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [ 2072.650173] firewire_ohci: Failed to reset ohci card.
> [ 2072.650267] firewire_ohci 0000:07:00.0: PCI INT A disabled
> [ 2072.650314] firewire_ohci: probe of 0000:07:00.0 failed with error -16
>
>
> Only suspend to ram helps bring it back from that state.
On the bright side, s2ram fixes things for once instead of breaking them...
--
Stefan Richter
-=====-==-=- =-== --===
http://arcgraph.de/sr/
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
^ permalink raw reply
* Re: [Security] [SECURITY] Fix leaking of kernel heap addresses via /proc
From: Oliver Hartkopp @ 2010-11-07 10:28 UTC (permalink / raw)
To: David Miller
Cc: torvalds, drosenberg, chas, kuznet, pekkas, jmorris, yoshfuji,
kaber, remi.denis-courmont, netdev, security
In-Reply-To: <20101106.165703.193714684.davem@davemloft.net>
On 07.11.2010 00:57, David Miller wrote:
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Sat, 6 Nov 2010 13:50:32 -0700
>
>> On Saturday, November 6, 2010, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
>>>
>>> Clearly, in most cases we cannot just remove the field from the /proc
>>> output, as this would break a number of userspace programs that rely on
>>> consistency. However, I propose that we replace the address with a "0"
>>> rather than leaking this information.
>>
>> I really think it would be much better to use the unidentified number
>> or similar.
>>
>> Just replacing with zeroes is annoying, and has the potential of
>> losing actual information.
>
> I would really like to see the specific examples of where this is
> happening, it sounds like something very silly to me.
Indeed Urs and me had a similar discussion before we decided to put different
(user relevant) content into the procfs output and break the current layout:
http://patchwork.ozlabs.org/patch/70282/
The layout break was ok in this case as the people using the CAN procfs stuff
do this only when facing problems (with their applications) at runtime.
A discussed approach that won't break the procfs layout was to set the values
to "0" and only fill them with real content depending on CONFIG_DEBUG_INFO .
Would that fit here?
Or maybe a different config option CONFIG_DEBUG_KERNEL_ADDR would do the job,
as i don't know which distros enable CONFIG_DEBUG_INFO by default ...
Regards,
Oliver
^ permalink raw reply
* [PATCH] NET: pktgen - fix compile warning
From: Dmitry Torokhov @ 2010-11-07 6:11 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Nelson Elhage
This should fix the following warning:
net/core/pktgen.c: In function ‘pktgen_if_write’:
net/core/pktgen.c:890: warning: comparison of distinct pointer types lacks a cast
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---
Unless somebody already beat me to it...
net/core/pktgen.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index fbce4b0..1992cd0 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -887,7 +887,7 @@ static ssize_t pktgen_if_write(struct file *file,
i += len;
if (debug) {
- size_t copy = min(count, 1023);
+ size_t copy = min_t(size_t, count, 1023);
char tb[copy + 1];
if (copy_from_user(tb, user_buffer, copy))
return -EFAULT;
--
Dmitry
^ permalink raw reply related
* [PATCH] ath9k_htc: Add support for device ID 3346
From: Haitao Zhang @ 2010-11-07 4:50 UTC (permalink / raw)
To: Luis R. Rodriguez, Jouni Malinen, Vasanthakumar Thiagarajan,
Senthil Balasubramanian
This patch adds support for USB dongle with device ID 3346 from IMC Networks.
Signed-off-by: Haitao Zhang <minipanda@linuxrobot.org>
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 6576f68..2f6b1e9 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -35,6 +35,7 @@ static struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x07D1, 0x3A10) }, /* Dlink Wireless 150 */
{ USB_DEVICE(0x13D3, 0x3327) }, /* Azurewave */
{ USB_DEVICE(0x13D3, 0x3328) }, /* Azurewave */
+ { USB_DEVICE(0x13D3, 0x3346) }, /* IMC Networks */
{ USB_DEVICE(0x04CA, 0x4605) }, /* Liteon */
{ USB_DEVICE(0x083A, 0xA704) }, /* SMC Networks */
{ },
--
1.7.0.4
^ permalink raw reply related
* netconf2010 web page
From: David Miller @ 2010-11-07 3:50 UTC (permalink / raw)
To: netdev
Slides etc. available at:
http://vger.kernel.org/netconf2010.html
Enjoy!
^ permalink raw reply
* Re: [PATCH] firewire: net: rate-limit log spam at transmit failure
From: Maxim Levitsky @ 2010-11-07 3:32 UTC (permalink / raw)
To: Stefan Richter; +Cc: linux1394-devel, netdev@vger.kernel.org
In-Reply-To: <1289100404.3277.28.camel@maxim-laptop>
[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]
On Sun, 2010-11-07 at 05:26 +0200, Maxim Levitsky wrote:
> On Sun, 2010-11-07 at 00:23 +0100, Stefan Richter wrote:
> > On 6 Nov, Stefan Richter wrote:
> > > Then I tried an XIO2213A card in the AMD PC (again the Intel PC as peer)
> > > and got 243 times "failed: 12" i.e. RCODE_BUSY and 81 times "failed: 10"
> > > i.e. RCODE_SEND_ERROR during ftp transfer of a >500 MB large file from
> > > XIO2213A to FW323.
> >
>
> I also am getting strange results (but very good compared to what I had
> recently).
>
> With all your patches, I get very stable TCP and UDP streams from laptop
> to desktop at 180~190 Mbits/s.
>
> However, the opposite direction (desktop->laptop) still suffers from
> tlabel exhaustion.
> I added some printks, and I see, clearly that netif_stop_queue doesn't
> always work (probably this is intended?).
>
> If I replace == with >= in inc_queue_packets and similar in
> dec_queued_packets, then tlabel exhaustion disappears, and I get ~240
> Mbit/s on TCP and UDP.
>
> UDP transfers work quite well, tested for few minutes.
> TCP transfers unfortunelly trigger (probably a hardware) bug in notebook
> OHCI controller (I have seen that meny times so far.)
>
> Transfer just stops, and controller goes south.
> If I unload the firewire-ohci, then when I load it:
>
> [ 2062.632532] firewire_ohci 0000:07:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [ 2072.650173] firewire_ohci: Failed to reset ohci card.
> [ 2072.650267] firewire_ohci 0000:07:00.0: PCI INT A disabled
> [ 2072.650314] firewire_ohci: probe of 0000:07:00.0 failed with error -16
>
>
> Only suspend to ram helps bring it back from that state.
>
> Best regards,
> Maxim Levitsky
>
To be clear, I use patches I attached on top of today mainline.
I have here my own hack to set the transaction timeout, because
update_split_timeout isn't called here at all, because nobody writes
to corresponding CSR registers.
Maybe I miss something though.
Best regards,
Maxim Levitsky
[-- Attachment #2: patches.tar.bz2 --]
[-- Type: application/x-bzip-compressed-tar, Size: 4498 bytes --]
^ permalink raw reply
* Re: [PATCH] firewire: net: rate-limit log spam at transmit failure
From: Maxim Levitsky @ 2010-11-07 3:26 UTC (permalink / raw)
To: Stefan Richter; +Cc: linux1394-devel, netdev@vger.kernel.org
In-Reply-To: <tkrat.276aeae22ec60090@s5r6.in-berlin.de>
On Sun, 2010-11-07 at 00:23 +0100, Stefan Richter wrote:
> On 6 Nov, Stefan Richter wrote:
> > Then I tried an XIO2213A card in the AMD PC (again the Intel PC as peer)
> > and got 243 times "failed: 12" i.e. RCODE_BUSY and 81 times "failed: 10"
> > i.e. RCODE_SEND_ERROR during ftp transfer of a >500 MB large file from
> > XIO2213A to FW323.
>
I also am getting strange results (but very good compared to what I had
recently).
With all your patches, I get very stable TCP and UDP streams from laptop
to desktop at 180~190 Mbits/s.
However, the opposite direction (desktop->laptop) still suffers from
tlabel exhaustion.
I added some printks, and I see, clearly that netif_stop_queue doesn't
always work (probably this is intended?).
If I replace == with >= in inc_queue_packets and similar in
dec_queued_packets, then tlabel exhaustion disappears, and I get ~240
Mbit/s on TCP and UDP.
UDP transfers work quite well, tested for few minutes.
TCP transfers unfortunelly trigger (probably a hardware) bug in notebook
OHCI controller (I have seen that meny times so far.)
Transfer just stops, and controller goes south.
If I unload the firewire-ohci, then when I load it:
[ 2062.632532] firewire_ohci 0000:07:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[ 2072.650173] firewire_ohci: Failed to reset ohci card.
[ 2072.650267] firewire_ohci 0000:07:00.0: PCI INT A disabled
[ 2072.650314] firewire_ohci: probe of 0000:07:00.0 failed with error -16
Only suspend to ram helps bring it back from that state.
Best regards,
Maxim Levitsky
^ permalink raw reply
* (unknown),
From: NOKIA MOBILE XMAS-PROMO @ 2010-11-07 3:00 UTC (permalink / raw)
Congratulation: Dear Winner,
You have been awarded £600.000.00 GBP.
in the NOKIA MOBILE-LOTTO Satellite
Software email lottery in which e-mail addresses are picked randomly by
Software powered by the internet through the worldwide website.
Your email address, attached to Ref Number:5, 7, 14, 17, 18, 43 with
Serial Number:1979-12 Verification Number:CY-085-333-0, and consequently
won the lottery in the "A" Category. You have therefore been approved for
a lump sum pay out of £600.000.00 GBP.
===============================
Contact: Mr.GARRY MOOR.
E-mail: garrym_2010@yahoo.co.jp
Please Indicate Your Means Of Delivery:
1: by courier Service
2: bank to bank wire transfer
================================
Provide him with the informations as stated below:
1. Name________________
2. Address:______________
3. Marital Status:__________
4. Age:__________________
5. Sex:__________________
6. Nationality:____________
7. Country of Residence:____
8. Occupation:____________
9. Telephone Number& Fax Number____
10.Draw Number above:___________
These details facilitate the due process and the release of winnings to
avoid unnecessary delays and complications in the processing of your
winnings.
Sincerely,
Mr. GARRY MOOR
Online Games Director
NOKIA MOBILE XMAS-PROMO.
NOKIA CONNECTING PEOPLE.
^ permalink raw reply
* Re: [Security] [SECURITY] Fix leaking of kernel heap addresses via /proc
From: David Miller @ 2010-11-06 23:57 UTC (permalink / raw)
To: torvalds
Cc: drosenberg, chas, kuznet, pekkas, jmorris, yoshfuji, kaber,
remi.denis-courmont, netdev, security
In-Reply-To: <AANLkTimC01SViEOObgf2N2VcLTYO59rOAbHaKf2RM54w@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat, 6 Nov 2010 13:50:32 -0700
> On Saturday, November 6, 2010, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
>>
>> Clearly, in most cases we cannot just remove the field from the /proc
>> output, as this would break a number of userspace programs that rely on
>> consistency. However, I propose that we replace the address with a "0"
>> rather than leaking this information.
>
> I really think it would be much better to use the unidentified number
> or similar.
>
> Just replacing with zeroes is annoying, and has the potential of
> losing actual information.
I would really like to see the specific examples of where this is
happening, it sounds like something very silly to me.
^ permalink raw reply
* Re: [Security] [SECURITY] Fix leaking of kernel heap addresses via /proc
From: Ted Ts'o @ 2010-11-06 23:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dan Rosenberg, chas@cmf.nrl.navy.mil, davem@davemloft.net,
kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, jmorris@namei.org,
yoshfuji@linux-ipv6.org, kaber@trash.net,
remi.denis-courmont@nokia.com, netdev@vger.kernel.org,
security@kernel.org
In-Reply-To: <AANLkTimC01SViEOObgf2N2VcLTYO59rOAbHaKf2RM54w@mail.gmail.com>
On Sat, Nov 06, 2010 at 01:50:32PM -0700, Linus Torvalds wrote:
> On Saturday, November 6, 2010, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
> > Clearly, in most cases we cannot just remove the field from the /proc
> > output, as this would break a number of userspace programs that rely on
> > consistency. However, I propose that we replace the address with a "0"
> > rather than leaking this information.
>
> I really think it would be much better to use the unidentified number
> or similar.
>
> Just replacing with zeroes is annoying, and has the potential of
> losing actual information.
Are there any userspace programs that might be reasonably expected to
_use_ this information? If there is, we could just pick a random
number at boot time, and then XOR the heap adddress with that random
number.
- Ted
^ permalink raw reply
* Re: [Security] [SECURITY] Fix leaking of kernel heap addresses via /proc
From: Linus Torvalds @ 2010-11-06 20:50 UTC (permalink / raw)
To: Dan Rosenberg
Cc: chas@cmf.nrl.navy.mil, davem@davemloft.net, kuznet@ms2.inr.ac.ru,
pekkas@netcore.fi, jmorris@namei.org, yoshfuji@linux-ipv6.org,
kaber@trash.net, remi.denis-courmont@nokia.com,
netdev@vger.kernel.org, security@kernel.org
In-Reply-To: <1289074307.3090.100.camel@Dan>
On Saturday, November 6, 2010, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
>
> Clearly, in most cases we cannot just remove the field from the /proc
> output, as this would break a number of userspace programs that rely on
> consistency. However, I propose that we replace the address with a "0"
> rather than leaking this information.
I really think it would be much better to use the unidentified number
or similar.
Just replacing with zeroes is annoying, and has the potential of
losing actual information.
Linus
^ permalink raw reply
* [SECURITY] Fix leaking of kernel heap addresses via /proc
From: Dan Rosenberg @ 2010-11-06 20:11 UTC (permalink / raw)
To: chas, davem, kuznet, pekkas, jmorris, yoshfuji, kaber,
remi.denis-courmont
Cc: netdev, security
Maintainers,
I am planning on submitting a series of patches to resolve the leakage
of kernel heap addresses to userspace via network protocol /proc
interfaces. Revealing this information is a bad idea from a security
perspective for a number of reasons, the most obvious of which is it
provides unprivileged users a mechanism by which to create a structure
in the kernel heap containing function pointers, obtain the address of
that structure, and overwrite those function pointers by leveraging
other vulnerabilities. It is my hope that by eliminating this
information leakage, in conjunction with making statically-declared
function pointer tables read-only (to be done in a separate patch
series), we can at least add a small hurdle for the exploitation of a
subset of kernel vulnerabilities.
Here's the list of protocols that I've identified as leaking socket
structure addresses via their /proc interfaces:
atm
ipv4
ipv6
key
netlink
packet
phonet
unix
There may be others, and I will continue looking for more examples, but
this is at least a good start.
Clearly, in most cases we cannot just remove the field from the /proc
output, as this would break a number of userspace programs that rely on
consistency. However, I propose that we replace the address with a "0"
rather than leaking this information.
I'm writing this email before submitting a patch to ask if anyone would
have any objections to this change, and if anyone can foresee anything
breaking as a result of this. Please let me know if you're on board,
have some doubts, or are totally opposed, and I can get this patch ready
for submission.
Thanks,
Dan Rosenberg
^ permalink raw reply
* Sky2 2.6.36-09934-g2aab243 DMAR error with tcp timestamp enabled
From: Michael Breuer @ 2010-11-06 16:57 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jarek Poplawski, David Miller, netdev
In-Reply-To: <4B69AD5C.5030601@majjas.com>
Basically, if I enable tcp timestamps (now disabled) I get a sky2 hang.
As with the earlier issue the effects are not seen until after a couple
days of uptime and seem exacerbated by load.
I can't 100% confirm that the problem is not occurring without tcp
timestamps, but will leave the system up for a while to try to confirm.
This didn't occur previously without tcp timestamps enabled, but I also
pulled git changes between the two events.
I'm now also on 2.6.37-rc1.... I did a quick scan and didn't see any
obvious commits between 2.6.36-09934 and -rc1 that would have affected this.
From the log:
Nov 2 05:41:54 mail kernel: DRHD: handling fault status reg 2
Nov 2 05:41:54 mail kernel: DMAR:[DMA Read] Request device [06:00.0]
fault addr ffea3000
Nov 2 05:41:54 mail kernel: DMAR:[fault reason 06] PTE Read access is
not set
Nov 2 05:41:54 mail kernel: sky2 0000:06:00.0: error interrupt
status=0x80000000
Nov 2 05:41:54 mail kernel: sky2 0000:06:00.0: PCI hardware error (0x2010)
Nov 2 05:42:01 mail clamd[9755]: SelfCheck: Database status OK.
Nov 2 05:42:11 mail root: ping of potter failed
Nov 2 05:42:16 mail kernel: ------------[ cut here ]------------
Nov 2 05:42:16 mail kernel: WARNING: at net/sched/sch_generic.c:258
dev_watchdog+0x251/0x260()
Nov 2 05:42:16 mail kernel: Hardware name: System Product Name
Nov 2 05:42:16 mail kernel: NETDEV WATCHDOG: eth0 (sky2): transmit
queue 0 timed out
Nov 2 05:42:16 mail kernel: Modules linked in: cpufreq_stats
ip6table_filter ip6table_mangle ip6_tables ipt_MASQUERADE iptable_nat
nf_nat iptable_mangle iptable_raw ebtable_nat ebtables bridge stp
appletalk psnap llc nfsd lockd nfs_acl auth_rpcgss exportfs coretemp
sunrpc acpi_cpufreq mperf sit tunnel4 ipt_LOG nf_conntrack_netbios_ns
nf_conntrack_ftp xt_DSCP xt_dscp xt_mark nf_conntrack_ipv6
nf_defrag_ipv6 xt_state xt_multiport ipv6 kvm_intel kvm
snd_hda_codec_analog snd_ens1371 gameport snd_rawmidi snd_ac97_codec
snd_hda_intel snd_hda_codec ac97_bus snd_hwdep snd_seq snd_seq_device
snd_pcm gspca_spca505 gspca_main snd_timer videodev snd v4l1_compat
i2c_i801 sky2 v4l2_compat_ioctl32 iTCO_wdt pcspkr asus_atk0110
i7core_edac edac_core soundcore iTCO_vendor_support snd_page_alloc
microcode raid456 async_raid6_recov async_pq raid6_pq async_xor xor
async_memcpy async_tx raid1 ata_generic firewire_ohci pata_acpi
firewire_core crc_itu_t pata_marvell nouveau ttm drm_kms_helper drm
i2c_algo_bit i2c_core video output [
Nov 2 05:42:16 mail kernel: last unloaded: ip6_tables]
Nov 2 05:42:16 mail kernel: Pid: 0, comm: swapper Tainted: G W
2.6.36-09934-g2aab243 #44
Nov 2 05:42:16 mail kernel: Call Trace:
Nov 2 05:42:16 mail kernel: <IRQ> [<ffffffff81058a4f>]
warn_slowpath_common+0x7f/0xc0
Nov 2 05:42:16 mail kernel: [<ffffffff81058b46>]
warn_slowpath_fmt+0x46/0x50
Nov 2 05:42:16 mail kernel: [<ffffffff814603d1>] dev_watchdog+0x251/0x260
Nov 2 05:42:16 mail kernel: [<ffffffff8108a4a6>] ?
tick_program_event+0x26/0x30
Nov 2 05:42:16 mail kernel: [<ffffffff8107eed4>] ?
hrtimer_interrupt+0x134/0x240
Nov 2 05:42:16 mail kernel: [<ffffffff81068ab0>]
run_timer_softirq+0x160/0x390
Nov 2 05:42:16 mail kernel: [<ffffffff8108a368>] ?
tick_dev_program_event+0x48/0x110
Nov 2 05:42:16 mail kernel: [<ffffffff81460180>] ? dev_watchdog+0x0/0x260
Nov 2 05:42:16 mail kernel: [<ffffffff8105f981>] __do_softirq+0xb1/0x220
Nov 2 05:42:16 mail kernel: [<ffffffff8100cfdc>] call_softirq+0x1c/0x30
Nov 2 05:42:16 mail kernel: [<ffffffff8100ea15>] do_softirq+0x65/0xa0
Nov 2 05:42:16 mail kernel: [<ffffffff8105f845>] irq_exit+0x85/0x90
Nov 2 05:42:16 mail kernel: [<ffffffff81511d61>] do_IRQ+0x71/0xf0
Nov 2 05:42:16 mail kernel: [<ffffffff8150a7d3>] ret_from_intr+0x0/0x11
Nov 2 05:42:16 mail kernel: <EOI> [<ffffffff812e4165>] ?
intel_idle+0xd5/0x170
Nov 2 05:42:16 mail kernel: [<ffffffff812e4148>] ? intel_idle+0xb8/0x170
Nov 2 05:42:16 mail kernel: [<ffffffff81425b51>]
cpuidle_idle_call+0x91/0x150
Nov 2 05:42:16 mail kernel: [<ffffffff8100aa8b>] cpu_idle+0xbb/0x150
Nov 2 05:42:16 mail kernel: [<ffffffff814f1785>] rest_init+0x75/0x80
Nov 2 05:42:16 mail kernel: [<ffffffff81b4ae9b>] start_kernel+0x3dc/0x3e7
Nov 2 05:42:16 mail kernel: [<ffffffff81b4a346>]
x86_64_start_reservations+0x131/0x135
Nov 2 05:42:16 mail kernel: [<ffffffff81b4a450>]
x86_64_start_kernel+0x106/0x115
Nov 2 05:42:16 mail kernel: ---[ end trace d9d3a1889f8925bf ]---
Nov 2 05:42:16 mail kernel: sky2 0000:06:00.0: eth0: tx timeout
Nov 2 05:42:16 mail kernel: sky2 0000:06:00.0: eth0: transmit ring 29
.. 117 report=29 done=29
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Ben Greear @ 2010-11-06 17:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: NetDev, linux-kernel, Tejun Heo
In-Reply-To: <1289028392.2665.2418.camel@edumazet-laptop>
On 11/06/2010 12:26 AM, Eric Dumazet wrote:
> Le vendredi 05 novembre 2010 à 17:07 -0700, Ben Greear a écrit :
>
>> We just tried creating 1000 macvlans with IPv6 addrs on a 64-bit machine
>> with 12GB RAM. Only around 520 interfaces properly set their IPs, and
>> again there are errors about of-of-memory from 'ip', but no obvious
>> splats in dmesg.
>>
>> 'top' shows 10G or so free.
>>
>> It will take some time to figure out what exactly is returning
>> the ENOMEM....
>
> At least, nothing to do with percpu stuff ?
At least I don't see any percpu dumps in dmesg. I vaguely remember
someone posting some ipv6 address scalability patches some time back.
I think they had to hack on /proc fs as well. I'll see if I can
dig those up.
> Make sure udev / hotplug is not the problem, if you create your devices
> very fast.
We can create the macvlans w/out problem, though I'm sure that could
be sped up. The problem is when we try to add IPv6 addresses to
them.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH 2/2] net: Detect and ignore netif_stop_queue() calls before register_netdev()
From: Guillaume Chazarain @ 2010-11-06 16:39 UTC (permalink / raw)
To: davem, netdev; +Cc: Guillaume Chazarain
In-Reply-To: <1289061572-5029-1-git-send-email-guichaz@gmail.com>
After e6484930d7c73d324bccda7d43d131088da697b9: net: allocate tx queues in register_netdevice
These calls make net drivers oops at load time, so let's avoid people
git-bisect'ing known problems.
Signed-off-by: Guillaume Chazarain <guichaz@gmail.com>
---
include/linux/netdevice.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 072652d..d8fd2c2 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1554,6 +1554,11 @@ static inline void netif_tx_wake_all_queues(struct net_device *dev)
static inline void netif_tx_stop_queue(struct netdev_queue *dev_queue)
{
+ if (WARN_ON(!dev_queue)) {
+ printk(KERN_INFO "netif_stop_queue() cannot be called before "
+ "register_netdev()");
+ return;
+ }
set_bit(__QUEUE_STATE_XOFF, &dev_queue->state);
}
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] skge: Remove tx queue stopping in skge_devinit()
From: Guillaume Chazarain @ 2010-11-06 16:39 UTC (permalink / raw)
To: davem, netdev; +Cc: Guillaume Chazarain
After e6484930d7c73d324bccda7d43d131088da697b9: net: allocate tx queues in register_netdevice
It causes an Oops at skge_probe() time.
Signed-off-by: Guillaume Chazarain <guichaz@gmail.com>
---
drivers/net/skge.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/skge.c b/drivers/net/skge.c
index bfec2e0..220e039 100644
--- a/drivers/net/skge.c
+++ b/drivers/net/skge.c
@@ -3858,7 +3858,6 @@ static struct net_device *skge_devinit(struct skge_hw *hw, int port,
/* device is off until link detection */
netif_carrier_off(dev);
- netif_stop_queue(dev);
return dev;
}
--
1.7.1
^ permalink raw reply related
* [PATCH kernel 2.6.37-rc1] axnet_cs: fix resume problem for some Ax88790 chip
From: Ken Kawasaki @ 2010-11-06 15:11 UTC (permalink / raw)
To: netdev
In-Reply-To: <20101030071751.63611ede.ken_kawasaki@spring.nifty.jp>
axnet_cs:
Some Ax88790 chip need to reinitialize the CISREG_CCSR register
after resume.
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
---
--- linux-2.6.37-rc1/drivers/net/pcmcia/axnet_cs.c.orig 2010-11-06 07:48:17.000000000 +0900
+++ linux-2.6.37-rc1/drivers/net/pcmcia/axnet_cs.c 2010-11-06 08:08:40.000000000 +0900
@@ -111,13 +111,14 @@ static irqreturn_t ax_interrupt(int irq,
CISREG_CCSR
typedef struct axnet_dev_t {
struct pcmcia_device *p_dev;
- caddr_t base;
- struct timer_list watchdog;
- int stale, fast_poll;
- u_short link_status;
- u_char duplex_flag;
- int phy_id;
- int flags;
+ caddr_t base;
+ struct timer_list watchdog;
+ int stale, fast_poll;
+ u_short link_status;
+ u_char duplex_flag;
+ int phy_id;
+ int flags;
+ int active_low;
} axnet_dev_t;
static inline axnet_dev_t *PRIV(struct net_device *dev)
@@ -322,6 +323,8 @@ static int axnet_config(struct pcmcia_de
if (info->flags & IS_AX88790)
outb(0x10, dev->base_addr + AXNET_GPIO); /* select Internal PHY */
+ info->active_low = 0;
+
for (i = 0; i < 32; i++) {
j = mdio_read(dev->base_addr + AXNET_MII_EEP, i, 1);
j2 = mdio_read(dev->base_addr + AXNET_MII_EEP, i, 2);
@@ -329,15 +332,18 @@ static int axnet_config(struct pcmcia_de
if ((j != 0) && (j != 0xffff)) break;
}
- /* Maybe PHY is in power down mode. (PPD_SET = 1)
- Bit 2 of CCSR is active low. */
if (i == 32) {
+ /* Maybe PHY is in power down mode. (PPD_SET = 1)
+ Bit 2 of CCSR is active low. */
pcmcia_write_config_byte(link, CISREG_CCSR, 0x04);
for (i = 0; i < 32; i++) {
j = mdio_read(dev->base_addr + AXNET_MII_EEP, i, 1);
j2 = mdio_read(dev->base_addr + AXNET_MII_EEP, i, 2);
if (j == j2) continue;
- if ((j != 0) && (j != 0xffff)) break;
+ if ((j != 0) && (j != 0xffff)) {
+ info->active_low = 1;
+ break;
+ }
}
}
@@ -383,8 +389,12 @@ static int axnet_suspend(struct pcmcia_d
static int axnet_resume(struct pcmcia_device *link)
{
struct net_device *dev = link->priv;
+ axnet_dev_t *info = PRIV(dev);
if (link->open) {
+ if (info->active_low == 1)
+ pcmcia_write_config_byte(link, CISREG_CCSR, 0x04);
+
axnet_reset_8390(dev);
AX88190_init(dev, 1);
netif_device_attach(dev);
^ permalink raw reply
* Re: [PATCH 2/3] net: packet: fix information leak to userland
From: Vasiliy Kulikov @ 2010-11-06 14:39 UTC (permalink / raw)
To: walter harms
Cc: kernel-janitors, David S. Miller, Jiri Pirko, Eric Dumazet,
netdev, linux-kernel
In-Reply-To: <4CCE84E2.9050801@bfs.de>
On Mon, Nov 01, 2010 at 10:14 +0100, walter harms wrote:
>
>
> Vasiliy Kulikov schrieb:
> > packet_getname_spkt() doesn't initialize all members of sa_data field of
> > sockaddr struct if strlen(dev->name) < 13. This structure is then copied
> > to userland. It leads to leaking of contents of kernel stack memory.
> > We have to fully fill sa_data with strncpy() instead of strlcpy().
> >
> > The same with packet_getname(): it doesn't initialize sll_pkttype field of
> > sockaddr_ll. Set it to zero.
> >
> > Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
> > ---
> > net/packet/af_packet.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> > index 3616f27..0856a13 100644
> > --- a/net/packet/af_packet.c
> > +++ b/net/packet/af_packet.c
> > @@ -1719,7 +1719,7 @@ static int packet_getname_spkt(struct socket *sock, struct sockaddr *uaddr,
> > rcu_read_lock();
> > dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex);
> > if (dev)
> > - strlcpy(uaddr->sa_data, dev->name, 15);
> > + strncpy(uaddr->sa_data, dev->name, 14);
> > else
> > memset(uaddr->sa_data, 0, 14);
>
> if i understand the code correcly the max size for dev->name is IFNAMSIZ.
For dev->name - IFNAMSIZ, for uaddr->sa_data - 14.
> You can simply that part:
>
> memset(uaddr->sa_data, 0, IFNAMSIZ);
> dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex);
> if (dev)
> strlcpy(uaddr->sa_data, dev->name, IFNAMSIZ);
This will overflow uaddr->sa_data. Also I don't see any difficulty to
fill the array only once.
> you should send that as separate patch.
> re,
> wh
>
>
> > rcu_read_unlock();
> > @@ -1742,6 +1742,7 @@ static int packet_getname(struct socket *sock, struct sockaddr *uaddr,
> > sll->sll_family = AF_PACKET;
> > sll->sll_ifindex = po->ifindex;
> > sll->sll_protocol = po->num;
> > + sll->sll_pkttype = 0;
> > rcu_read_lock();
> > dev = dev_get_by_index_rcu(sock_net(sk), po->ifindex);
> > if (dev) {
Thanks,
--
Vasiliy
^ permalink raw reply
* Re: [RFC v2] ipvs: allow transmit of GRO aggregated skbs
From: Simon Horman @ 2010-11-06 14:28 UTC (permalink / raw)
To: Julian Anastasov; +Cc: lvs-devel, netdev
In-Reply-To: <alpine.LFD.2.00.1011061608510.4009@ja.ssi.bg>
On Sat, Nov 06, 2010 at 04:18:21PM +0200, Julian Anastasov wrote:
>
> Hello,
>
> On Sat, 6 Nov 2010, Simon Horman wrote:
>
> >This is a first attempt at allowing LVS to transmit
> >skbs of greater than MTU length that have been aggregated by GRO.
> >
> >I have lightly tested the ip_vs_dr_xmit() portion of this patch and
> >although it seems to work I am unsure that netif_needs_gso() is the correct
> >test to use.
>
> ip_forward() uses !skb_is_gso(skb), so may be it is
> enough to check for GRO instead of using netif_needs_gso?
Thanks, I'll look into that.
^ permalink raw reply
* Re: [RFC v2] ipvs: allow transmit of GRO aggregated skbs
From: Julian Anastasov @ 2010-11-06 14:18 UTC (permalink / raw)
To: Simon Horman; +Cc: lvs-devel, netdev
In-Reply-To: <20101105235411.GA2443@verge.net.au>
Hello,
On Sat, 6 Nov 2010, Simon Horman wrote:
> This is a first attempt at allowing LVS to transmit
> skbs of greater than MTU length that have been aggregated by GRO.
>
> I have lightly tested the ip_vs_dr_xmit() portion of this patch and
> although it seems to work I am unsure that netif_needs_gso() is the correct
> test to use.
ip_forward() uses !skb_is_gso(skb), so may be it is
enough to check for GRO instead of using netif_needs_gso?
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> ---
>
> * LRO is still an outstanding issue, but as its deprecated in favour
> of GRO perhaps it doesn't need to be solved.
>
> * v1
> - Based on 2.6.35
>
> * v2
> - Rebase on current nf-next-2.6 tree (~2.6.37-rc1)
> --- lvs-test-2.6.orig/net/netfilter/ipvs/ip_vs_xmit.c 2010-10-30 11:43:37.000000000 +0900
> +++ lvs-test-2.6/net/netfilter/ipvs/ip_vs_xmit.c 2010-11-06 08:09:17.000000000 +0900
> @@ -1008,7 +1012,8 @@ ip_vs_dr_xmit(struct sk_buff *skb, struc
>
> /* MTU checking */
> mtu = dst_mtu(&rt->dst);
> - if ((iph->frag_off & htons(IP_DF)) && skb->len > mtu) {
> + if ((iph->frag_off & htons(IP_DF)) && skb->len > mtu &&
> + !netif_needs_gso(rt->dst.dev, skb)) {
> icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
> ip_rt_put(rt);
> IP_VS_DBG_RL("%s(): frag needed\n", __func__);
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* PERSONAL
From: Harry Barnes @ 2010-11-06 12:32 UTC (permalink / raw)
To: netdev
Hello,
This is Harry Barnes of the US Marine Corps, but redeployed to Iraq, and presently stationed in Mosul. I will like to share some very vital information that would bring some good financial returns to us in just a few weeks or days depending on how fast we pursue the matter. I am seeking your assistance to evacuate the sum of $28m to you,as far as I can be assured that it will be safe in your care until I complete my service here.
This may not be the best medium to make this kind of contact because of the numerous scam offers transmitted through the Internet, but it is all I have access to for now. I will be very grateful if you can give me the opportunity to discuss this matter with you by assuring me that you will not use any part of it against me in anyway, I hope you understand my limitations here. Should you have reasons to reject this offer, please destroy this mail as any leakage will be too bad for us.
Respectfully,
Harry Barnes.
^ 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