* Re: Question: How to configure the Ethernet receive buffer allocation (was: (no subject)).
From: Eric Dumazet @ 2012-10-13 10:29 UTC (permalink / raw)
To: Ronny Meeus; +Cc: netdev
In-Reply-To: <CAMJ=MEdu9EtYhYHFyXD04b7M4BseX6oDfmB=NB9CAfMo59pxow@mail.gmail.com>
On Sat, 2012-10-13 at 12:14 +0200, Ronny Meeus wrote:
> The ideal solution would be to have a solution were we use a packet
> ring to store the packets in but use a standard socket to receive the
> packets from this ring. In this way we can combine the ideal memory
> usage of the packet ring solution (in fact almost no overhead)
> combined with the virtual memory that must not be wasted in the
> application space.
>
> I have no clue whether this is possible ...
But how do you know before receiving packet from network that its size
will be 1000 instead of 1500 ?
Packet ring is nice when you have the right size, or else you need to
add a copy of packets. Or you dedicate an ethernet device for an
application (direct delivery to user land, no skbs at all)
2.6.32 kernel is a bit old for us on netdev.
If you try latest kernel (Linus tree), you'll discover we no longer use
one kmalloc-4096 entry to store a packet.
However, with MTU=1500, we still consume around 2048 bytes per packet
(including overhead)
If you really cant change packet size and stay at 1000, you could try :
reducing device mtu, to lower wasted ram per packet
^ permalink raw reply
* Re: Question: How to configure the Ethernet receive buffer allocation (was: (no subject)).
From: Ronny Meeus @ 2012-10-13 11:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1350124173.21172.14017.camel@edumazet-glaptop>
On Sat, Oct 13, 2012 at 12:29 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sat, 2012-10-13 at 12:14 +0200, Ronny Meeus wrote:
>
>> The ideal solution would be to have a solution were we use a packet
>> ring to store the packets in but use a standard socket to receive the
>> packets from this ring. In this way we can combine the ideal memory
>> usage of the packet ring solution (in fact almost no overhead)
>> combined with the virtual memory that must not be wasted in the
>> application space.
>>
>> I have no clue whether this is possible ...
>
> But how do you know before receiving packet from network that its size
> will be 1000 instead of 1500 ?
>
> Packet ring is nice when you have the right size, or else you need to
> add a copy of packets. Or you dedicate an ethernet device for an
> application (direct delivery to user land, no skbs at all)
This is in fact the case. This is a dedicated interface and the
packets will not be bigger than 1000 bytes.
>
> 2.6.32 kernel is a bit old for us on netdev.
>
> If you try latest kernel (Linus tree), you'll discover we no longer use
> one kmalloc-4096 entry to store a packet.
>
> However, with MTU=1500, we still consume around 2048 bytes per packet
> (including overhead)
>
> If you really cant change packet size and stay at 1000, you could try :
> reducing device mtu, to lower wasted ram per packet
>
In the mean time I use 64K pages for the kernel and then I see that 2K
buffers are getting used, so I gained already a large amount of
memory.
By reducing the MTU to 1000, it consumes buffers of 2048bytes.
Still not clear to me whether it is possible to combine the packet
ring only in kernel space and receive packets from it using a normal
socket operation?
^ permalink raw reply
* Re: [BUG] Kernel recieves DNS reply, but doesn't deliver it to a waiting application
From: Andrew Savchenko @ 2012-10-13 12:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <20121003232548.eb6b6b22.bircoph@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2517 bytes --]
Hello,
On Wed, 3 Oct 2012 23:25:48 +0400 Andrew Savchenko wrote:
> I encountered a very weird bug: after a while of uptime kernel stops to deliver
> DNS reply to applications. Tcpdump shows that correct reply is recieved, but
> strace shows inquiring application never recieves it and ends with timeout,
> epoll_wait() always returns 0:
> a slice from: $ host kernel.org 8.8.8.8:
>
> sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53),
> sin_addr=inet_addr("8.8.8.8")}, msg_iov(1)=[{"\266\344\1\0\0\1\0\0\0\0\0\0\6k
> ernel\3org\0\0\1\0\1", 28}], msg_controllen=0, msg_flags=0}, 0) = 28
> epoll_wait(3, {}, 64, 0) = 0
> epoll_wait(3, {}, 64, 4999) = 0
>
> Though tcpdump shows a normal reply:
>
> 20:28:44.162897 IP 10.7.74.7.43167 > 8.8.8.8.domain: 46820+ A? kernel.org. (28)
> 20:28:44.221308 IP 8.8.8.8.domain > 10.7.74.7.43167: 46820 1/0/0 A 149.20.4.69
> (44)
>
> After this bug has occured, it is no longer possible to perform DNS request on
> the crippled system. I tried to stop/restart all network-related daemons, to
> recreate network interfaces whenever possible (e.g. pppX devices), but with no
> help. I use iptables and ebtables on this host, but reseting them (flushing all
> chains, removing user chains, setting all policies to ACCEPT) doesn't help. The
> only worknig solution is to reboot the system.
>
> This bug happens rarely and randomly (about once in 7-12 days on 24x7 available
> production system), but I had it 5 times already. Due to rare and random nature
> of the bug I can't bisect it.
>
> This problem occured after I updated vanilla kernel from 2.6.39.4 to 3.4.6.
> Afterward I updated kernel to 3.4.10 in the hope that this will fix the
> problem, but with no result. (I updated kernel due to commit
> 2ce42ec4ef551b08d2e5d26775d838ac640f82ad, which describes somewhat similar
> issue, though I don't use I/OAT engine due to lack of hardware support.)
>
> More details, attached trace files and kernel configs are available at bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=48081
>
> In a few days I'll try 3.4.12 (I need to rebuild kernel anyway due to unrelated
> issue) and will report if this bug will occur again. But please note it may
> take several weeks to check this.
I got this problem again with 3.4.12 kernel. System lasted less than
a week and reboot was the only option...
Best regards,
Andrew Savchenko
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [patch] RDS: fix an integer overflow check
From: Jeff Liu @ 2012-10-13 13:25 UTC (permalink / raw)
To: Dan Carpenter
Cc: Venkat Venkatsubra, David S. Miller, rds-devel, netdev,
kernel-janitors
In-Reply-To: <20121012073146.GA9543@elgon.mountain>
On 10/12/2012 03:31 PM, Dan Carpenter wrote:
> "len" is an int. We verified that len was postive already. Since
> PAGE_SIZE is specified as an unsigned long, the type it promoted to
> unsigned and the condition is never true.
>
> I'm not sure this check is actually needed. It might be that we could
> just remove it?
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/net/rds/info.c b/net/rds/info.c
> index 9a6b4f6..4d62618 100644
> --- a/net/rds/info.c
> +++ b/net/rds/info.c
> @@ -176,7 +176,7 @@ int rds_info_getsockopt(struct socket *sock, int optname, char __user *optval,
>
> /* check for all kinds of wrapping and the like */
> start = (unsigned long)optval;
> - if (len < 0 || len + PAGE_SIZE - 1 < len || start + len < start) {
Looks the original thought is to check up len + (PAGE_SIZE - 1) < len to
avoid integer overflow, but lack of a "()".
However, we only have one add operation in this function which were
shown as following:
nr_pages = (PAGE_ALIGN(start + len) - (start & PAGE_MASK))
>> PAGE_SHIFT;
I also gone through the call chains, there is no other (start + len)
operations for all transport, I think it's safe to remove this check up
if so.
Thanks,
-Jeff
> + if (len < 0 || len > INT_MAX - (PAGE_SIZE - 1) || start + len < start) {
> ret = -EINVAL;
> goto out;
> }
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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
* Dear Friend ,
From: info @ 2012-10-13 13:40 UTC (permalink / raw)
To: Recipients
I am Sgt Jason H .Kane , A US Army serving in the 3rd Infantry Division in Iraq. Now in Afghanistan I want you to read this mail carefully and understand it.
In 2003, my men and I found over $900 million in Saddam Hussein's hideout in Baghdad, we sent some back to the Iraq government after counting it in a classified location, but we also kept some behind for ourselves. Some of the money we shared among ourselves worth over $200 million, I kept my own share for a while in a secured place.
I need someone to help me receive it , since i have found a secured way of getting the package out of Iraq for you to pick up through the help of a Red Cross Society or pilots that enjoy some immunities with us while in Iraq .
I do not know for how long I will remain here as I have been lucky to survive 3 suicide bomb attacks by Afghanistan Militant which one of my leg was amputed , i know my survival was an act of God and Pure Divine intervention from God .
I need someone I can trust, since i have already lost a box of gold to someone that said he will help me, I won't like to make the same mistake. The total amount of money is $7.5 million.
View the below link to verify/confirm my statement.
http://news.bbc.co.uk/2/hi/middle_east/2988455.stm
If you can handle this deal let me know immediately, you will receive 20% of the money , all you need to do is to find a safe place where you can keep the box till i leave Afghanistan .
Regards,
Sgt Jason H .Kane
^ permalink raw reply
* Re: [BUG] Kernel recieves DNS reply, but doesn't deliver it to a waiting application
From: Eric Dumazet @ 2012-10-13 13:44 UTC (permalink / raw)
To: Andrew Savchenko; +Cc: netdev
In-Reply-To: <20121013163639.87abca00.bircoph@gmail.com>
On Sat, 2012-10-13 at 16:36 +0400, Andrew Savchenko wrote:
> Hello,
>
> On Wed, 3 Oct 2012 23:25:48 +0400 Andrew Savchenko wrote:
> > I encountered a very weird bug: after a while of uptime kernel stops to deliver
> > DNS reply to applications. Tcpdump shows that correct reply is recieved, but
> > strace shows inquiring application never recieves it and ends with timeout,
> > epoll_wait() always returns 0:
> > a slice from: $ host kernel.org 8.8.8.8:
> >
> > sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53),
> > sin_addr=inet_addr("8.8.8.8")}, msg_iov(1)=[{"\266\344\1\0\0\1\0\0\0\0\0\0\6k
> > ernel\3org\0\0\1\0\1", 28}], msg_controllen=0, msg_flags=0}, 0) = 28
> > epoll_wait(3, {}, 64, 0) = 0
> > epoll_wait(3, {}, 64, 4999) = 0
> >
> > Though tcpdump shows a normal reply:
> >
> > 20:28:44.162897 IP 10.7.74.7.43167 > 8.8.8.8.domain: 46820+ A? kernel.org. (28)
> > 20:28:44.221308 IP 8.8.8.8.domain > 10.7.74.7.43167: 46820 1/0/0 A 149.20.4.69
> > (44)
> >
> > After this bug has occured, it is no longer possible to perform DNS request on
> > the crippled system. I tried to stop/restart all network-related daemons, to
> > recreate network interfaces whenever possible (e.g. pppX devices), but with no
> > help. I use iptables and ebtables on this host, but reseting them (flushing all
> > chains, removing user chains, setting all policies to ACCEPT) doesn't help. The
> > only worknig solution is to reboot the system.
> >
> > This bug happens rarely and randomly (about once in 7-12 days on 24x7 available
> > production system), but I had it 5 times already. Due to rare and random nature
> > of the bug I can't bisect it.
> >
> > This problem occured after I updated vanilla kernel from 2.6.39.4 to 3.4.6.
> > Afterward I updated kernel to 3.4.10 in the hope that this will fix the
> > problem, but with no result. (I updated kernel due to commit
> > 2ce42ec4ef551b08d2e5d26775d838ac640f82ad, which describes somewhat similar
> > issue, though I don't use I/OAT engine due to lack of hardware support.)
> >
> > More details, attached trace files and kernel configs are available at bugzilla:
> > https://bugzilla.kernel.org/show_bug.cgi?id=48081
> >
> > In a few days I'll try 3.4.12 (I need to rebuild kernel anyway due to unrelated
> > issue) and will report if this bug will occur again. But please note it may
> > take several weeks to check this.
>
> I got this problem again with 3.4.12 kernel. System lasted less than
> a week and reboot was the only option...
You should investigate and check where the incoming packet is lost
Tools :
netstat -s
drop_monitor module and dropwatch command
cat /proc/net/udp
^ permalink raw reply
* Re: [rds-devel] [patch] RDS: fix an integer overflow check
From: Jeff Liu @ 2012-10-13 13:45 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev, rds-devel, kernel-janitors, David S. Miller
In-Reply-To: <50796BD4.4000608@oracle.com>
On 10/13/2012 09:25 PM, Jeff Liu wrote:
> On 10/12/2012 03:31 PM, Dan Carpenter wrote:
>> "len" is an int. We verified that len was postive already. Since
>> PAGE_SIZE is specified as an unsigned long, the type it promoted to
>> unsigned and the condition is never true.
>>
>> I'm not sure this check is actually needed. It might be that we could
>> just remove it?
>>
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>
>> diff --git a/net/rds/info.c b/net/rds/info.c
>> index 9a6b4f6..4d62618 100644
>> --- a/net/rds/info.c
>> +++ b/net/rds/info.c
>> @@ -176,7 +176,7 @@ int rds_info_getsockopt(struct socket *sock, int optname, char __user *optval,
>>
>> /* check for all kinds of wrapping and the like */
>> start = (unsigned long)optval;
>> - if (len < 0 || len + PAGE_SIZE - 1 < len || start + len < start) {
> Looks the original thought is to check up len + (PAGE_SIZE - 1) < len to
> avoid integer overflow, but lack of a "()".
>
> However, we only have one add operation in this function which were
> shown as following:
> nr_pages = (PAGE_ALIGN(start + len) - (start & PAGE_MASK))
> >> PAGE_SHIFT;
>
> I also gone through the call chains, there is no other (start + len)
Sorry, here is a typo. "start + len" is already well-checked.
Actually, I means there is no other "len + (PAGE_SIZE - 1)" operations.
Thanks,
-Jeff
> operations for all transport, I think it's safe to remove this check up
> if so.
>
> Thanks,
> -Jeff
>> + if (len < 0 || len > INT_MAX - (PAGE_SIZE - 1) || start + len < start) {
>> ret = -EINVAL;
>> goto out;
>> }
>> --
>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> _______________________________________________
> rds-devel mailing list
> rds-devel@oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/rds-devel
^ permalink raw reply
* [net: stable request] dst->obsolete handling in 2.6.32-stable kernels - invalid cached routes never invalidated
From: Benjamin LaHaise @ 2012-10-13 17:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Hello David et al,
While investigating a problem on a 2.6.32 kernels (still present in 2.6.32.60)
where a change to an ipv4 route was not taking effect, I came across the
"dst->obsolete has become pointless" thread from November 2011 which is
related, eventually finding the problem fixed (or at least worked around) in
2.6.34 by "ipv4: check rt_genid in dst_check" aka
d11a4dc18bf41719c9f0d7ed494d295dd2973b92.
What I am seeing is that dst->obsolete is never being set for a cached
output route that becomes obsolete. For example, a cached route for
10.0.0.3 is never marked obsolete when the route for 10.0.0.3 is removed
from the routing table -- dst_check() and sk_dst_check() never invalidate
the cached dst because of the test for dst->obsolete (which remains 0).
Reproducing the issue is easily done:
# assuming eth0 has some ip and default route
ifconfig eth1 9.0.0.1/8
route add -host 10.0.0.3 gw 9.0.0.2 # assuming there is a 9.0.0.2
nc -u 10.0.0.3 1234
# <enter a few lines and note the packets sent to eth1 via 9.0.0.2>
# On another terminal, without exiting nc, delete the route to 10.0.0.3
route del -host 10.0.0.3 gw 9.0.0.2
# Go back to the first terminal and send a few more packets by
# entering another line or two to nc. Note the packets still go via
# eth1, even though they should now be transmitted via the default
# route on eth0.
To fix this bug, would it be possible to get commit
d11a4dc18bf41719c9f0d7ed494d295dd2973b92 queued up for 2.6.32-stable?
Setting dst.obsolete to -1 seems to be the least invasive way of fixing
this bug. Thanks a bunch,
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* [PATCH] sock filter: fix copy of filter from userspace
From: Stephen Hemminger @ 2012-10-13 18:40 UTC (permalink / raw)
To: Jiri Pirko, David S. Miller; +Cc: netdev
The sk_unattached_filter_create function is passed a socket
filter structure and the copies the contents of the filter from
userspace. Sparse detected that this code was incorrectly using
memcpy when it needed to use copy_from_user instead.
The only use of sk_unattached_filter_create at present is in
the team driver.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/core/filter.c 2012-10-09 10:35:03.183141638 -0700
+++ b/net/core/filter.c 2012-10-13 11:33:05.955531440 -0700
@@ -666,7 +666,9 @@ int sk_unattached_filter_create(struct s
fp = kmalloc(fsize + sizeof(*fp), GFP_KERNEL);
if (!fp)
return -ENOMEM;
- memcpy(fp->insns, fprog->filter, fsize);
+
+ if (copy_from_user(fp->insns, fprog->filter, fsize))
+ return -EFAULT;
atomic_set(&fp->refcnt, 1);
fp->len = fprog->len;
^ permalink raw reply
* Re: [PATCH] sock filter: fix copy of filter from userspace
From: Jiri Pirko @ 2012-10-13 19:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jiri Pirko, David S. Miller, netdev
In-Reply-To: <20121013114032.2d1c1434@nehalam.linuxnetplumber.net>
Sat, Oct 13, 2012 at 08:40:32PM CEST, shemminger@vyatta.com wrote:
>The sk_unattached_filter_create function is passed a socket
>filter structure and the copies the contents of the filter from
>userspace. Sparse detected that this code was incorrectly using
>memcpy when it needed to use copy_from_user instead.
Hmm. fprog->filter is in this case allocated and filled in kernel.
So memcpy is good.
Not sure how to handle this correctly. Either we remove "__user" or we
redefine "struct sock_fprog" for sk_unattached_filter_create() use.
Any thoughts?
>
>The only use of sk_unattached_filter_create at present is in
>the team driver.
>
>Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
>
>--- a/net/core/filter.c 2012-10-09 10:35:03.183141638 -0700
>+++ b/net/core/filter.c 2012-10-13 11:33:05.955531440 -0700
>@@ -666,7 +666,9 @@ int sk_unattached_filter_create(struct s
> fp = kmalloc(fsize + sizeof(*fp), GFP_KERNEL);
> if (!fp)
> return -ENOMEM;
>- memcpy(fp->insns, fprog->filter, fsize);
>+
>+ if (copy_from_user(fp->insns, fprog->filter, fsize))
>+ return -EFAULT;
>
> atomic_set(&fp->refcnt, 1);
> fp->len = fprog->len;
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" 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: [net: stable request] dst->obsolete handling in 2.6.32-stable kernels - invalid cached routes never invalidated
From: David Miller @ 2012-10-13 22:26 UTC (permalink / raw)
To: bcrl; +Cc: netdev
In-Reply-To: <20121013175240.GK5453@kvack.org>
From: Benjamin LaHaise <bcrl@kvack.org>
Date: Sat, 13 Oct 2012 13:52:40 -0400
> To fix this bug, would it be possible to get commit
> d11a4dc18bf41719c9f0d7ed494d295dd2973b92 queued up for 2.6.32-stable?
> Setting dst.obsolete to -1 seems to be the least invasive way of fixing
> this bug. Thanks a bunch,
I do not manage, nor care, about 2.6.32-stable kernels.
I'm going back as far as 3.0.x at this point, so other people
have to take care of the older stuff.
^ permalink raw reply
* Re: [BUG] Kernel recieves DNS reply, but doesn't deliver it to a waiting application
From: Andrew Savchenko @ 2012-10-13 23:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1350135860.21172.14606.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]
Hello,
On Sat, 13 Oct 2012 15:44:20 +0200 Eric Dumazet wrote:
> On Sat, 2012-10-13 at 16:36 +0400, Andrew Savchenko wrote:
> > On Wed, 3 Oct 2012 23:25:48 +0400 Andrew Savchenko wrote:
> > > I encountered a very weird bug: after a while of uptime kernel stops to deliver
> > > DNS reply to applications. Tcpdump shows that correct reply is recieved, but
> > > strace shows inquiring application never recieves it and ends with timeout,
> > > epoll_wait() always returns 0:
> > > a slice from: $ host kernel.org 8.8.8.8:
[...]
> > > In a few days I'll try 3.4.12 (I need to rebuild kernel anyway due to unrelated
> > > issue) and will report if this bug will occur again. But please note it may
> > > take several weeks to check this.
> >
> > I got this problem again with 3.4.12 kernel. System lasted less than
> > a week and reboot was the only option...
>
> You should investigate and check where the incoming packet is lost
>
> Tools :
>
> netstat -s
>
> drop_monitor module and dropwatch command
>
> cat /proc/net/udp
Thank you for you reply; I updated my kernel to 3.4.14, enabled
CONFIG_NET_DROP_MONITOR, and installed dropwatch utility.
I will report back when the bug will struck again.
This may take a weak or two, however.
Best regards,
Andrew Savchenko
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* (unknown),
From: moumitad @ 2012-10-14 2:03 UTC (permalink / raw)
Complement of the day from DR. MA WEIHUA, President of China Merchants
Bank Ltd, I need your assistance in a business transaction from my Bank to
your Country.
Contact me on : ma.weihua@live.hk
Thanks,
DR Ma Weihua
^ permalink raw reply
* enquiry
From: Royaldoc International Globe @ 2012-10-13 0:10 UTC (permalink / raw)
Royaldoc International Globe,
103, Park son road,
Carlifonia,USA.
63-1-3522 2501
royaldoc@inbox.org.tw
We are interested in purchasing your products and I would like to
make an inquiry. can you inform me of your minimum order quantity? and
also your maximum order quantity, if there is any available sample do
let me know.
Sincerely,
Purchase Manager
Alan Smith
^ permalink raw reply
* (unknown),
From: moumitad @ 2012-10-14 2:32 UTC (permalink / raw)
Complement of the day from DR. MA WEIHUA, President of China Merchants
Bank Ltd, I need your assistance in a business transaction from my Bank to
your Country.
Contact me on : ma.weihua@live.hk
Thanks,
DR Ma Weihua
^ permalink raw reply
* Re: [STABLE REQUEST] add: e1000: fix lockdep splat in shutdown handler
From: Ben Hutchings @ 2012-10-14 9:47 UTC (permalink / raw)
To: David Miller, Steven Rostedt
Cc: linux-kernel, netdev, tglx, stable, jesse.brandeburg,
jeffrey.t.kirsher
In-Reply-To: <20121011.182214.2229957213838024407.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
On Thu, 2012-10-11 at 18:22 -0400, David Miller wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
> Date: Thu, 11 Oct 2012 18:09:45 -0400
>
> > Can you add this to the 3.2 stable tree.
> >
> > commit 3a3847e007aae732d64d8fd1374126393e9879a3
> > Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
> > Date: Wed Jan 4 20:23:33 2012 +0000
> >
> > e1000: fix lockdep splat in shutdown handler
>
> Acked-by: David S. Miller <davem@davemloft.net>
Added to the queue, thanks.
Ben.
--
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* (unknown),
From: Alexey Dobriyan @ 2012-10-14 10:57 UTC (permalink / raw)
To: rostedt, David.Laight, nab, anton, netdev
http://www.hzsonic.com/en/wp-content/themes/twentyten/career.html
^ permalink raw reply
* [patch net] vlan: fix bond/team enslave of vlan challenged slave/port
From: Jiri Pirko @ 2012-10-14 14:30 UTC (permalink / raw)
To: netdev; +Cc: davem, fubar, andy, kaber, jstanley
In vlan_uses_dev() check for number of vlan devs rather than existence
of vlan_info. The reason is that vlan id 0 is there without appropriate
vlan dev on it by default which prevented from enslaving vlan challenged
dev.
Reported-by: Jon Stanley <jstanley@rmrf.net>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
drivers/net/bonding/bond_main.c | 2 +-
net/8021q/vlan_core.c | 9 ++++++++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index b721902..b2530b0 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1519,7 +1519,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
/* no need to lock since we're protected by rtnl_lock */
if (slave_dev->features & NETIF_F_VLAN_CHALLENGED) {
pr_debug("%s: NETIF_F_VLAN_CHALLENGED\n", slave_dev->name);
- if (bond_vlan_used(bond)) {
+ if (vlan_uses_dev(bond_dev)) {
pr_err("%s: Error: cannot enslave VLAN challenged slave %s on VLAN enabled bond %s\n",
bond_dev->name, slave_dev->name, bond_dev->name);
return -EPERM;
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index fbbf1fa..65e06ab 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -366,6 +366,13 @@ EXPORT_SYMBOL(vlan_vids_del_by_dev);
bool vlan_uses_dev(const struct net_device *dev)
{
- return rtnl_dereference(dev->vlan_info) ? true : false;
+ struct vlan_info *vlan_info;
+
+ ASSERT_RTNL();
+
+ vlan_info = rtnl_dereference(dev->vlan_info);
+ if (!vlan_info)
+ return false;
+ return vlan_info->grp.nr_vlan_devs ? true : false;
}
EXPORT_SYMBOL(vlan_uses_dev);
--
1.7.11.4
^ permalink raw reply related
* Re: regression in bonding driver with VLAN challenged interfaces when 8021q module is loaded
From: Jiri Pirko @ 2012-10-14 14:32 UTC (permalink / raw)
To: Jon Stanley; +Cc: fubar, andy, netdev, linux-kernel, jpirko
In-Reply-To: <CAJtaB1v95Z2b78cKUPYrZtriF6BuHwD2=StyhV3gGOOquNt7fw@mail.gmail.com>
Thu, Oct 11, 2012 at 04:28:40PM CEST, jstanley@rmrf.net wrote:
>Since commit cc0e40700656b09d93b062ef6c818aa45429d09a, there is a
>problem if you have the 8021q module loaded and you then attempt to
>enslave a VLAN challenged interface. This is because VLAN 0 is
>automatically added to the bond, and the new bond_vlan_used() function
>simply checks for an empty list in bond->vlan_list without taking into
>account that VLAN0 might be on the interface.
>
>This specifically affects IPoIB interfaces in a bond if you do a
>down/up cycle on the bond post-boot (during boot, the bonding module
>is loaded prior to the 8021q module, so everything is fine).
>
>Let me know if further information or testing is needed.
Thanks for the report. I just fixed this by following patch:
http://patchwork.ozlabs.org/patch/191363/
^ permalink raw reply
* regression when connecting to ipv6 localhost
From: Jan Hinnerk Stosch @ 2012-10-14 15:38 UTC (permalink / raw)
To: netdev
Hi,
I detected a small regression since linux 3.6.0:
When I run "ntpq -p" to query the status of my ntp-daemon I receive a
timeout (localhost.localdomain: timed out, nothing received
***Request timed out). Strace shows that connecting to the ipv6
loopback interface times out. If I explicitly use ipv4 (ntpq -4 -p)
everything works as intended. Downgrading to linux 3.5.6 solves that
issue.
I reported a bug both to my distribution
(https://bugs.archlinux.org/task/31775) and to the kernel bugtracker
(https://bugzilla.kernel.org/show_bug.cgi?id=48741) not knowing
exactly which component caused the regression, so I was told to ask
this here. At the kernel-report you find an strace and tcpdump output.
If you need any further information just tell me, but be patient as me
kernel knowledge tends to zero.
Thanks in advance, Jan Hinnerk
^ permalink raw reply
* [PATCH] usb/ipheth: Add iPhone 5 support
From: Jan Ceuleers @ 2012-10-14 17:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Jay Purohit, Valdis Kletnieks
In-Reply-To: <20121011.171540.781078040657458587.davem@davemloft.net>
From: Jay Purohit <jspurohit@velocitylimitless.com>
I noticed that the iPhone ethernet driver did not support
iPhone 5. I quickly added support to it in my kernel, here's
a patch.
Signed-off-by: Jay Purohit <jspurohit@velocitylimitless.com>
Acked-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Jan Ceuleers <jan.ceuleers@computer.org>
---
Resubmitting on behalf of Jay, as he may have toolchain issues.
drivers/net/usb/ipheth.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index a28a983..534d8be 100644
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -62,6 +62,7 @@
#define USB_PRODUCT_IPAD 0x129a
#define USB_PRODUCT_IPHONE_4_VZW 0x129c
#define USB_PRODUCT_IPHONE_4S 0x12a0
+#define USB_PRODUCT_IPHONE_5 0x12a8
#define IPHETH_USBINTF_CLASS 255
#define IPHETH_USBINTF_SUBCLASS 253
@@ -113,6 +114,10 @@ static struct usb_device_id ipheth_table[] = {
USB_VENDOR_APPLE, USB_PRODUCT_IPHONE_4S,
IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
IPHETH_USBINTF_PROTO) },
+ { USB_DEVICE_AND_INTERFACE_INFO(
+ USB_VENDOR_APPLE, USB_PRODUCT_IPHONE_5,
+ IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
+ IPHETH_USBINTF_PROTO) },
{ }
};
MODULE_DEVICE_TABLE(usb, ipheth_table);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] netrom: fix info leak via getsockname()
From: Clément Lecigne @ 2012-10-14 18:23 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 951 bytes --]
The following patch fixes a 3 bytes info leak via getsockname() on
AF_NETROM socket.
Details:
typedef struct {
char ax25_call[7]; /* 6 call + SSID (shifted ascii!) */
} ax25_address;
struct sockaddr_ax25 {
__kernel_sa_family_t sax25_family;
ax25_address sax25_call;
int sax25_ndigis;
/* Digipeater ax25_address sets follow */
};
After compilation, gcc will add 3 padding bytes after sax25_call to
align sax25_ndigis and nr_getname does not clear these padding bytes
before returning to userland, poc attached.
Signed-off-by: Clement Lecigne <clemun@gmail.com>
--- a/net/netrom/af_netrom.c
+++ b/net/netrom/af_netrom.c
@@ -838,6 +838,8 @@ static int nr_getname(struct socket *sock, struct
sockaddr *uaddr,
struct sock *sk = sock->sk;
struct nr_sock *nr = nr_sk(sk);
+ memset(sax, 0, sizeof(struct sockaddr_ax25));
+
lock_sock(sk);
if (peer != 0) {
if (sk->sk_state != TCP_ESTABLISHED) {
[-- Attachment #2: netrom.c --]
[-- Type: text/x-csrc, Size: 3217 bytes --]
/* netrom.c - getsockname() 3 bytes infoleak.
*
* (c) clem1.be - 2o12
*/
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <errno.h>
#include <unistd.h>
#include <time.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/syscall.h>
#include <linux/netrom.h>
/* from Jon Oberheide sploit
*/
void kernop(int fd)
{
const int randcalls[] = {
__NR_read, __NR_write, __NR_open, __NR_close, __NR_stat, __NR_lstat,
__NR_lseek, __NR_rt_sigaction, __NR_rt_sigprocmask, __NR_ioctl,
__NR_access, __NR_pipe, __NR_sched_yield, __NR_mremap, __NR_dup,
__NR_dup2, __NR_getitimer, __NR_setitimer, __NR_getpid, __NR_fcntl,
__NR_flock, __NR_getdents, __NR_getcwd, __NR_gettimeofday,
__NR_getrlimit, __NR_getuid, __NR_getgid, __NR_geteuid, __NR_getegid,
__NR_getppid, __NR_getpgrp, __NR_getgroups, __NR_getresuid,
__NR_getresgid, __NR_getpgid, __NR_getsid,__NR_getpriority,
__NR_sched_getparam, __NR_sched_get_priority_max
};
const int randsopts[] = { SOL_SOCKET, AF_APPLETALK };
int ret, len;
char buf[1024];
do
{
switch (rand() % 3)
{
case 0:
ret = syscall(randcalls[rand() % sizeof(randcalls)/sizeof(randcalls[0])]);
break;
case 1:
len = (rand() % 2) ? sizeof(int) : sizeof(buf);
ret = getsockopt(fd, randsopts[rand() % sizeof(randsopts)/sizeof(randsopts[0])], rand() % 130, &buf, &len);
break;
case 2:
len = (rand() % 2) ? sizeof(int) : sizeof(buf);
ret = setsockopt(fd, randsopts[rand() % sizeof(randsopts)/sizeof(randsopts[0])], rand() % 130, &buf, len);
break;
}
}
while (ret < 0);
}
void dump(unsigned char * data, unsigned int len)
{
unsigned int dp, p;
const char trans[] =
"................................ !\"#$%&'()*+,-./0123456789"
":;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklm"
"nopqrstuvwxyz{|}~...................................."
"....................................................."
"........................................";
for (dp = 1; dp <= len; dp++)
{
printf("%02x ", data[dp-1]);
if ( (dp % 8) == 0 )
{
printf("| ");
p = dp;
for ( dp -= 8; dp < p; dp++ ) {
printf("%c", trans[data[dp]]);
}
printf("\n");
}
}
return;
}
int main(void)
{
struct sockaddr_ax25 sa;
int s, salen;
char prev[sizeof sa];
s = socket(AF_NETROM, SOCK_SEQPACKET, 0);
if (s < 0)
return -1;
srand(time(NULL) ^ getpid());
while (1)
{
kernop(s);
memset(&sa, 0, sizeof sa);
salen = sizeof sa;
if (getsockname(s, (struct sockaddr *) &sa, &salen) == 0)
{
if (memcmp(&sa, prev, salen) != 0)
{
dump((unsigned char *) &sa, salen);
memcpy(&prev, &sa, salen);
sleep(2);
}
}
}
close(s);
return 0;
}
^ permalink raw reply
* Re: [STABLE REQUEST] add: e1000: fix lockdep splat in shutdown handler
From: Thomas Gleixner @ 2012-10-14 19:24 UTC (permalink / raw)
To: Steven Rostedt
Cc: Ben Hutchings, LKML, netdev, David S. Miller, stable,
Jesse Brandeburg, Jeff Kirsher
In-Reply-To: <1349993385.24256.79.camel@gandalf.local.home>
On Thu, 11 Oct 2012, Steven Rostedt wrote:
> commit 3a3847e007aae732d64d8fd1374126393e9879a3
> Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Date: Wed Jan 4 20:23:33 2012 +0000
>
> e1000: fix lockdep splat in shutdown handler
as I discussed with Jesse on IRC, there is another possible deadlock
lurking in the e1000 code.
static void e1000_reinit_safe(struct e1000_adapter *adapter)
{
while (test_and_set_bit(__E1000_RESETTING, &adapter->flags))
msleep(1);
mutex_lock(&adapter->mutex);
e1000_down(adapter);
e1000_down() waits on the various work tasks to shut down, but those
work functions might be blocked on the adapter mutex.
I have no idea how I managed to trigger that one, but it's real. The
task dump I got out of the machine shows stuff waiting on each other
forever.
I can't give you a receipe to reprodruce. Looking at the code this is
not very surprising. It takes quite some coincidence of having
e1000_reinit_safe() being invoked and the delayed work timer bringing
the work on right after e1000_reinit_safe() took the adapter mutex.
Thanks,
tglx
^ permalink raw reply
* Re: regression when connecting to ipv6 localhost
From: Eric Dumazet @ 2012-10-14 19:29 UTC (permalink / raw)
To: Jan Hinnerk Stosch; +Cc: netdev
In-Reply-To: <CAO_aot5U16KLjqtXp2ZS7d+T0WvVY7OXPaA3t2bbN=uvboVV3Q@mail.gmail.com>
On Sun, 2012-10-14 at 17:38 +0200, Jan Hinnerk Stosch wrote:
> Hi,
> I detected a small regression since linux 3.6.0:
> When I run "ntpq -p" to query the status of my ntp-daemon I receive a
> timeout (localhost.localdomain: timed out, nothing received
> ***Request timed out). Strace shows that connecting to the ipv6
> loopback interface times out. If I explicitly use ipv4 (ntpq -4 -p)
> everything works as intended. Downgrading to linux 3.5.6 solves that
> issue.
> I reported a bug both to my distribution
> (https://bugs.archlinux.org/task/31775) and to the kernel bugtracker
> (https://bugzilla.kernel.org/show_bug.cgi?id=48741) not knowing
> exactly which component caused the regression, so I was told to ask
> this here. At the kernel-report you find an strace and tcpdump output.
> If you need any further information just tell me, but be patient as me
> kernel knowledge tends to zero.
> Thanks in advance, Jan Hinnerk
> --
What gives :
cat /etc/ntp.conf
lsof -p `pidof ntpd`
ntpq -p ::1
^ permalink raw reply
* [PATCH] checkpatch: Improve network block comment style checking
From: Joe Perches @ 2012-10-14 19:35 UTC (permalink / raw)
To: Larry Finger, Andrew Morton; +Cc: Andy Whitcroft, LKML, netdev
In-Reply-To: <50787432.8030805@lwfinger.net>
Some comment styles in net and drivers/net are flagged inappropriately.
Avoid proclaiming inline comments like:
int a = b; /* some comment */
and block comments like:
/*********************
* some comment
********************/
are defective.
Tested with
$ cat drivers/net/t.c
/* foo */
/*
* foo
*/
/* foo
*/
/* foo
* bar */
/****************************
* some long block comment
***************************/
struct foo {
int bar; /* another test */
};
$
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Joe Perches <joe@perches.com>
---
scripts/checkpatch.pl | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 21a9f5d..f18750e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1890,8 +1890,10 @@ sub process {
}
if ($realfile =~ m@^(drivers/net/|net/)@ &&
- $rawline !~ m@^\+[ \t]*(\/\*|\*\/)@ &&
- $rawline =~ m@^\+[ \t]*.+\*\/[ \t]*$@) {
+ $rawline !~ m@^\+[ \t]*\*/[ \t]*$@ && #trailing */
+ $rawline !~ m@^\+.*/\*.*\*/[ \t]*$@ && #inline /*...*/
+ $rawline !~ m@^\+.*\*{2,}/[ \t]*$@ && #trailing **/
+ $rawline =~ m@^\+[ \t]*.+\*\/[ \t]*$@) { #non blank */
WARN("NETWORKING_BLOCK_COMMENT_STYLE",
"networking block comments put the trailing */ on a separate line\n" . $herecurr);
}
^ permalink raw reply related
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