* [PATCH] bluetooth: hidp: fix information leak to userland
From: Vasiliy Kulikov @ 2010-10-30 14:26 UTC (permalink / raw)
To: kernel-janitors
Cc: Marcel Holtmann, Gustavo F. Padovan, David S. Miller, Jiri Kosina,
Michael Poole, Bastien Nocera, linux-bluetooth, netdev,
linux-kernel
Structure hidp_conninfo is copied to userland with version, product,
vendor and name fields unitialized if both session->input and session->hid
are NULL. It leads to leaking of contents of kernel stack memory.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
---
Compile tested.
net/bluetooth/hidp/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index c0ee8b3..29544c2 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -107,6 +107,7 @@ static void __hidp_unlink_session(struct hidp_session *session)
static void __hidp_copy_session(struct hidp_session *session, struct hidp_conninfo *ci)
{
+ memset(ci, 0, sizeof(*ci));
bacpy(&ci->bdaddr, &session->bdaddr);
ci->flags = session->flags;
@@ -115,7 +116,6 @@ static void __hidp_copy_session(struct hidp_session *session, struct hidp_connin
ci->vendor = 0x0000;
ci->product = 0x0000;
ci->version = 0x0000;
- memset(ci->name, 0, 128);
if (session->input) {
ci->vendor = session->input->id.vendor;
--
1.7.0.4
^ permalink raw reply related
* [PATCH] net: core: scm: fix information leak to userland
From: Vasiliy Kulikov @ 2010-10-30 14:26 UTC (permalink / raw)
To: kernel-janitors
Cc: David S. Miller, Eric W. Biederman, Eric Dumazet, Tejun Heo,
Serge E. Hallyn, netdev, linux-kernel
Structure cmsghdr is copied to userland with padding bytes
unitialized on architectures where __kernel_size_t is unsigned long.
It leads to leaking of contents of kernel stack memory.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
---
Compile tested.
net/core/scm.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/core/scm.c b/net/core/scm.c
index 413cab8..a4a9b70 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -233,6 +233,7 @@ int put_cmsg(struct msghdr * msg, int level, int type, int len, void *data)
msg->msg_flags |= MSG_CTRUNC;
cmlen = msg->msg_controllen;
}
+ memset(&cmhdr, 0, sizeof(cmhdr));
cmhdr.cmsg_level = level;
cmhdr.cmsg_type = type;
cmhdr.cmsg_len = cmlen;
--
1.7.0.4
^ permalink raw reply related
* [PATCH] net: core: sock: fix information leak to userland
From: Vasiliy Kulikov @ 2010-10-30 14:26 UTC (permalink / raw)
To: kernel-janitors
Cc: David S. Miller, Eric Dumazet, Eric W. Biederman, Herbert Xu,
Paul E. McKenney, netdev, linux-kernel
"Address" variable might be not fully initialized in sock->ops->get_name().
The only current implementation is get_name(), it leaves some padding
fields of sockaddr_tipc uninitialized. It leads to leaking of contents
of kernel stack memory.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
---
Compile tested.
net/core/sock.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 3eed542..759dd81 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -930,6 +930,7 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
{
char address[128];
+ memset(&address, 0, sizeof(address));
if (sock->ops->getname(sock, (struct sockaddr *)address, &lv, 2))
return -ENOTCONN;
if (lv < len)
--
1.7.0.4
^ permalink raw reply related
* [PATCH] ipv4: netfilter: arp_tables: fix information leak to userland
From: Vasiliy Kulikov @ 2010-10-30 14:26 UTC (permalink / raw)
To: kernel-janitors
Cc: Patrick McHardy, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
netfilter-devel, netfilter, coreteam, netdev, linux-kernel
Structure arpt_getinfo is copied to userland with the field "name"
that has the last elements unitialized. It leads to leaking of
contents of kernel stack memory.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
---
Compile tested.
net/ipv4/netfilter/arp_tables.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
index 3cad259..3fac340 100644
--- a/net/ipv4/netfilter/arp_tables.c
+++ b/net/ipv4/netfilter/arp_tables.c
@@ -927,6 +927,7 @@ static int get_info(struct net *net, void __user *user,
private = &tmp;
}
#endif
+ memset(&info, 0, sizeof(info));
info.valid_hooks = t->valid_hooks;
memcpy(info.hook_entry, private->hook_entry,
sizeof(info.hook_entry));
--
1.7.0.4
^ permalink raw reply related
* [PATCH] ipv4: netfilter: ip_tables: fix information leak to userland
From: Vasiliy Kulikov @ 2010-10-30 14:26 UTC (permalink / raw)
To: kernel-janitors
Cc: Patrick McHardy, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
netfilter-devel, netfilter, coreteam, netdev, linux-kernel
Structure ipt_getinfo is copied to userland with the field "name"
that has the last elements unitialized. It leads to leaking of
contents of kernel stack memory.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
---
Compile tested.
net/ipv4/netfilter/ip_tables.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
index d31b007..a846d63 100644
--- a/net/ipv4/netfilter/ip_tables.c
+++ b/net/ipv4/netfilter/ip_tables.c
@@ -1124,6 +1124,7 @@ static int get_info(struct net *net, void __user *user,
private = &tmp;
}
#endif
+ memset(&info, 0, sizeof(info));
info.valid_hooks = t->valid_hooks;
memcpy(info.hook_entry, private->hook_entry,
sizeof(info.hook_entry));
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] net: core: scm: fix information leak to userland
From: Eric Dumazet @ 2010-10-30 14:33 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kernel-janitors, David S. Miller, Eric W. Biederman, Tejun Heo,
Serge E. Hallyn, netdev, linux-kernel
In-Reply-To: <1288448796-6147-1-git-send-email-segooon@gmail.com>
Le samedi 30 octobre 2010 à 18:26 +0400, Vasiliy Kulikov a écrit :
> Structure cmsghdr is copied to userland with padding bytes
> unitialized on architectures where __kernel_size_t is unsigned long.
> It leads to leaking of contents of kernel stack memory.
>
> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
> ---
> Compile tested.
>
> net/core/scm.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/scm.c b/net/core/scm.c
> index 413cab8..a4a9b70 100644
> --- a/net/core/scm.c
> +++ b/net/core/scm.c
> @@ -233,6 +233,7 @@ int put_cmsg(struct msghdr * msg, int level, int type, int len, void *data)
> msg->msg_flags |= MSG_CTRUNC;
> cmlen = msg->msg_controllen;
> }
> + memset(&cmhdr, 0, sizeof(cmhdr));
> cmhdr.cmsg_level = level;
> cmhdr.cmsg_type = type;
> cmhdr.cmsg_len = cmlen;
???
struct cmsghdr {
__kernel_size_t cmsg_len; /* data byte count, including hdr */
int cmsg_level; /* originating protocol */
int cmsg_type; /* protocol-specific type */
};
Could you explain where are the padding bytes ?
^ permalink raw reply
* Re: [PATCH] net: core: sock: fix information leak to userland
From: Eric Dumazet @ 2010-10-30 14:35 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kernel-janitors, David S. Miller, Eric W. Biederman, Herbert Xu,
Paul E. McKenney, netdev, linux-kernel
In-Reply-To: <1288448801-6303-1-git-send-email-segooon@gmail.com>
Le samedi 30 octobre 2010 à 18:26 +0400, Vasiliy Kulikov a écrit :
> "Address" variable might be not fully initialized in sock->ops->get_name().
> The only current implementation is get_name(), it leaves some padding
> fields of sockaddr_tipc uninitialized. It leads to leaking of contents
> of kernel stack memory.
>
> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
> ---
> Compile tested.
>
> net/core/sock.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 3eed542..759dd81 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -930,6 +930,7 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
> {
> char address[128];
>
> + memset(&address, 0, sizeof(address));
> if (sock->ops->getname(sock, (struct sockaddr *)address, &lv, 2))
> return -ENOTCONN;
> if (lv < len)
???
Please fix the real bug.
^ permalink raw reply
* Re: [PATCH] net: core: sock: fix information leak to userland
From: Vasiliy Kulikov @ 2010-10-30 14:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: kernel-janitors, David S. Miller, Eric W. Biederman, Herbert Xu,
Paul E. McKenney, netdev, linux-kernel
In-Reply-To: <1288449350.2680.970.camel@edumazet-laptop>
On Sat, Oct 30, 2010 at 16:35 +0200, Eric Dumazet wrote:
> Le samedi 30 octobre 2010 à 18:26 +0400, Vasiliy Kulikov a écrit :
> > "Address" variable might be not fully initialized in sock->ops->get_name().
> > The only current implementation is get_name(), it leaves some padding
> > fields of sockaddr_tipc uninitialized. It leads to leaking of contents
> > of kernel stack memory.
> >
> > Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
> > ---
> > Compile tested.
> >
> > net/core/sock.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/core/sock.c b/net/core/sock.c
> > index 3eed542..759dd81 100644
> > --- a/net/core/sock.c
> > +++ b/net/core/sock.c
> > @@ -930,6 +930,7 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
> > {
> > char address[128];
> >
> > + memset(&address, 0, sizeof(address));
> > if (sock->ops->getname(sock, (struct sockaddr *)address, &lv, 2))
> > return -ENOTCONN;
> > if (lv < len)
>
> ???
>
> Please fix the real bug.
What if somebody want to create his own implementation of getname()?
IMO it's much safer to introduce memset() here and relax getname()'s
responsibilities. Quite many drivers "forget" to initialize outputs
structures. E.g. new net_device's private field is kzalloc'ed to
simplify driver's code.
--
Vasiliy
^ permalink raw reply
* Re: [PATCH] net: core: scm: fix information leak to userland
From: Vasiliy Kulikov @ 2010-10-30 14:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: kernel-janitors, David S. Miller, Eric W. Biederman, Tejun Heo,
Serge E. Hallyn, netdev, linux-kernel
In-Reply-To: <1288449205.2680.968.camel@edumazet-laptop>
On Sat, Oct 30, 2010 at 16:33 +0200, Eric Dumazet wrote:
> Le samedi 30 octobre 2010 à 18:26 +0400, Vasiliy Kulikov a écrit :
> > Structure cmsghdr is copied to userland with padding bytes
> > unitialized on architectures where __kernel_size_t is unsigned long.
> > It leads to leaking of contents of kernel stack memory.
> >
> > Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
> > ---
> > Compile tested.
> >
> > net/core/scm.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/core/scm.c b/net/core/scm.c
> > index 413cab8..a4a9b70 100644
> > --- a/net/core/scm.c
> > +++ b/net/core/scm.c
> > @@ -233,6 +233,7 @@ int put_cmsg(struct msghdr * msg, int level, int type, int len, void *data)
> > msg->msg_flags |= MSG_CTRUNC;
> > cmlen = msg->msg_controllen;
> > }
> > + memset(&cmhdr, 0, sizeof(cmhdr));
> > cmhdr.cmsg_level = level;
> > cmhdr.cmsg_type = type;
> > cmhdr.cmsg_len = cmlen;
>
>
> ???
>
> struct cmsghdr {
> __kernel_size_t cmsg_len; /* data byte count, including hdr */
> int cmsg_level; /* originating protocol */
> int cmsg_type; /* protocol-specific type */
> };
>
> Could you explain where are the padding bytes ?
Ah, sorry, nowhere :) int is stored quite OK after long. Please ignore this patch.
Thanks,
--
Vasiliy
^ permalink raw reply
* Re: [PATCH] af_unix: unix_write_space() use keyed wakeups
From: Davide Libenzi @ 2010-10-30 15:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alban Crequy, David S. Miller, Stephen Hemminger, Cyrill Gorcunov,
Alexey Dobriyan, netdev, linux-kernel, Pauli Nieminen,
Rainer Weikusat
In-Reply-To: <1288421084.2680.717.camel@edumazet-laptop>
On Sat, 30 Oct 2010, Eric Dumazet wrote:
> This patch is a specialization of commit 37e5540b3c9d (epoll keyed
> wakeups: make sockets use keyed wakeups).
Whoops, I must have missed AF_UNIX :)
Looks good to me.
- Davide
^ permalink raw reply
* Pica8 - Linux Cloud Switch
From: Lin Pica8 @ 2010-10-30 16:54 UTC (permalink / raw)
To: netdev
Hello,
For your information :
http://www.pica8.org/
http://www.networkworld.com/news/2010/102810-pica8-opensource-switching.html?page=1
Mail : pica8@gmail.org
^ permalink raw reply
* Re: [PATCH] macvlan: Introduce 'passthru' mode to takeover the underlying device
From: Michael S. Tsirkin @ 2010-10-30 16:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sridhar Samudrala, Patrick McHardy, Stephen Hemminger, netdev,
kvm@vger.kernel.org
In-Reply-To: <201010291545.17910.arnd@arndb.de>
On Fri, Oct 29, 2010 at 03:45:17PM +0200, Arnd Bergmann wrote:
> On Friday 29 October 2010, Sridhar Samudrala wrote:
> > With the current default 'vepa' mode, a KVM guest using virtio with
> > macvtap backend has the following limitations.
> > - cannot change/add a mac address on the guest virtio-net
>
> I believe this could be changed if there is a neeed, but I actually
> consider it one of the design points of macvlan that the guest
> is not able to change the mac address. With 802.1Qbg you rely on
> the switch being able to identify the guest by its MAC address,
> which the host kernel must ensure.
>
> > - cannot create a vlan device on the guest virtio-net
>
> Why not? If this doesn't work, it's probably a bug!
> Why does the passthru mode enable it if it doesn't work
> already?
>
> > - cannot enable promiscuous mode on guest virtio-net
>
> Could you elaborate why such a setup would be useful?
>
> Arnd
E.g. to support bridging in the guest.
--
MST
^ permalink raw reply
* Re: [PATCH] macvlan: Introduce 'passthru' mode to takeover the underlying device
From: Michael S. Tsirkin @ 2010-10-30 17:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sridhar Samudrala, Patrick McHardy, Stephen Hemminger, netdev,
kvm@vger.kernel.org
In-Reply-To: <201010291545.17910.arnd@arndb.de>
On Fri, Oct 29, 2010 at 03:45:17PM +0200, Arnd Bergmann wrote:
> On Friday 29 October 2010, Sridhar Samudrala wrote:
> > With the current default 'vepa' mode, a KVM guest using virtio with
> > macvtap backend has the following limitations.
> > - cannot change/add a mac address on the guest virtio-net
>
> I believe this could be changed if there is a neeed, but I actually
> consider it one of the design points of macvlan that the guest
> is not able to change the mac address.
It's a policy question that we should not set at the kernel level.
> With 802.1Qbg you rely on
> the switch being able to identify the guest by its MAC address,
> which the host kernel must ensure.
This is required to be able to get feature parity with
both tun and device assignment. At the moment, changing
the mac when using macvtap silently breaks guest networking.
--
MST
^ permalink raw reply
* @ms_world you won!
From: (ms-world) @ 2010-10-30 18:07 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: YOU HAVE WON A PRIZE.doc --]
[-- Type: application/msword, Size: 196096 bytes --]
^ permalink raw reply
* Re: [PATCH] af_unix: optimize unix_dgram_poll()
From: Davide Libenzi @ 2010-10-30 17:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: Davide Libenzi, Alban Crequy, David S. Miller, Stephen Hemminger,
Cyrill Gorcunov, Alexey Dobriyan, netdev,
Linux Kernel Mailing List, Pauli Nieminen, Rainer Weikusat
In-Reply-To: <1288432420.2680.933.camel@edumazet-laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 740 bytes --]
On Sat, 30 Oct 2010, Eric Dumazet wrote:
> Le vendredi 29 octobre 2010 à 13:46 -0700, Davide Libenzi a écrit :
>
> > Also, why not using the existing wait->key instead of adding a poll2()?
>
> Indeed, if wait is not null, we have in wait->key the interest of
> poller. If a particular poll() function is expensive, it can test these
> bits.
>
> Thanks !
>
> Note: I chose the 'goto skip_write' to make this patch really obvious.
Plain agreement on th patch, and I understand the indent overflow
concerns, but why not ...
/*
* No write status requested, avoid expensive OUT tests.
*/
if (wait && !(wait->key & (POLLWRBAND | POLLWRNORM | POLLOUT)))
return mask
The write-test code is the last one we do anyway.
- Davide
^ permalink raw reply
* Re: [PATCH 1/2] IPv6: conntrack: Use protocol-related initialization routine to initial queues of IPv6 connection track
From: Pascal Hambourg @ 2010-10-30 18:41 UTC (permalink / raw)
To: David Miller; +Cc: kaber, shanwei, yasuyuki.kozakai, netfilter-devel, netdev
In-Reply-To: <20100126.051147.256313206.davem@davemloft.net>
Hello,
David Miller a écrit :
>
> Anyways, meanwhile I'll apply the fix. And yes I know it needs
> to go to stable too... :-)
It appears that the patch "ipv6: reassembly: use seperate reassembly
queues for conntrack and local delivery" went to both the 2.6.32 and
2.6.27 stable branches, but the fix from Shan Wei went to the 2.6.32
branch only, not to the 2.6.27 branch. However I checked that it applies
on the latest 2.6.27 release, and fixes the problem.
Could someone submit it for the next 2.6.27 stable release ? Or if I
have to do it, what is the process ?
Thanks.
^ permalink raw reply
* [PATCH 1/2] ixgb: Don't check for vlan group on transmit.
From: Jesse Gross @ 2010-10-30 18:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jeff Kirsher, Jesse Brandeburg, PJ Waskiewicz
On transmit, the ixgb driver will only use vlan acceleration if a
vlan group is configured. This can lead to tags getting dropped
when bridging because the networking core assumes that a driver
that claims vlan acceleration support can do it at all times. This
change should have been part of commit eab6d18d "vlan: Don't check for
vlan group before vlan_tx_tag_present." but was missed.
Signed-off-by: Jesse Gross <jesse@nicira.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
---
drivers/net/ixgb/ixgb_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index caa8192..d18194e 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -1498,7 +1498,7 @@ ixgb_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
DESC_NEEDED)))
return NETDEV_TX_BUSY;
- if (adapter->vlgrp && vlan_tx_tag_present(skb)) {
+ if (vlan_tx_tag_present(skb)) {
tx_flags |= IXGB_TX_FLAGS_VLAN;
vlan_id = vlan_tx_tag_get(skb);
}
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] igb: Don't depend on vlan group for receive size.
From: Jesse Gross @ 2010-10-30 18:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jeff Kirsher, Jesse Brandeburg, PJ Waskiewicz
In-Reply-To: <1288464591-31528-1-git-send-email-jesse@nicira.com>
The igb driver currently sets its maximum receive size based on
whether a vlan group is configured. However, this causes it to
completely drop MTU sized vlan packets when there is no vlan
group, preventing them from showing up in tcpdump, etc.
Signed-off-by: Jesse Gross <jesse@nicira.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
---
drivers/net/igb/igb_main.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 892d196..5d1c13c 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -2830,13 +2830,10 @@ static inline int igb_set_vf_rlpml(struct igb_adapter *adapter, int size,
**/
static void igb_rlpml_set(struct igb_adapter *adapter)
{
- u32 max_frame_size = adapter->max_frame_size;
+ u32 max_frame_size = adapter->max_frame_size + VLAN_TAG_SIZE;
struct e1000_hw *hw = &adapter->hw;
u16 pf_id = adapter->vfs_allocated_count;
- if (adapter->vlgrp)
- max_frame_size += VLAN_TAG_SIZE;
-
/* if vfs are enabled we set RLPML to the largest possible request
* size and set the VMOLR RLPML to the size we need */
if (pf_id) {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] net: core: scm: fix information leak to userland
From: David Miller @ 2010-10-30 19:12 UTC (permalink / raw)
To: segooon
Cc: kernel-janitors, ebiederm, eric.dumazet, tj, serge, netdev,
linux-kernel
In-Reply-To: <1288448796-6147-1-git-send-email-segooon@gmail.com>
Your patches are almost entirely baseless.
You haven't even made an effort to show a real case, in detail,
where your patches actually fix a bug. The CMSG case shows
that you didn't even bother to look at the assembly of even
one architecture to see if padding bytes even existed in the
structure, and that furthermore even if they existed that they
would leak out ever.
I don't even buy the "preventative nature" argument for the
address[128] thing. If a protocol is leaking kernel memory in that
case, it also isn't filling in the address value properly, which is a
bug times two.
I absolutely am not applying these patches, sorry.
^ permalink raw reply
* Re: NULL pointer dereference at netxen_nic_probe+0x813/0x9a0
From: Denis Kirjanov @ 2010-10-30 19:56 UTC (permalink / raw)
To: David Miller; +Cc: bjorn.helgaas, amit.salecha, netdev, linux-kernel
In-Reply-To: <20101029.125403.71123384.davem@davemloft.net>
On 10/29/2010 11:54 PM, David Miller wrote:
> From: Denis Kirjanov <dkirjanov@kernel.org>
> Date: Fri, 29 Oct 2010 23:47:22 +0400
>
>>> This is on current Linus upstream as of this morning (8128057)
>>> on an HP DL785:
>>>
>>> QLogic/NetXen Network Driver v4.0.74
>>> netxen_nic 0000:07:00.0: PCI INT A -> GSI 30 (level, low) -> IRQ 30
>>> netxen_nic 0000:07:00.0: setting latency timer to 64
>>> netxen_nic 0000:07:00.0: 2MB memory map
>>> netxen_nic 0000:07:00.0: loading firmware from flash
>>> netxen_nic 0000:07:00.0: using 64-bit dma mask
>>> kernel: Quad Gig LP Board S/N TI9ABK0266 Chip rev 0x42
>>> netxen_nic 0000:07:00.0: firmware v4.0.520 [legacy]
>>> netxen_nic 0000:07:00.0: irq 72 for MSI/MSI-X
>>> netxen_nic 0000:07:00.0: irq 73 for MSI/MSI-X
>>> netxen_nic 0000:07:00.0: irq 74 for MSI/MSI-X
>>> netxen_nic 0000:07:00.0: irq 75 for MSI/MSI-X
>>> netxen_nic 0000:07:00.0: using msi-x interrupts
>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
>>> IP: [<ffffffff8160afda>] netxen_nic_probe+0x813/0x9a0
>>> PGD 0
>>> Oops: 0002 [#1] SMP
>>> last sysfs file:
>>> CPU 0
>>> Modules linked in:
>>>
>>> Pid: 1650, comm: work_for_cpu Not tainted 2.6.36-07338-g8128057 #269
>>> /ProLiant DL785 G5
>>> RIP: 0010:[<ffffffff8160afda>] [<ffffffff8160afda>]
>>> netxen_nic_probe+0x813/0x9a0
>>> RSP: 0018:ffff8806138abe30 EFLAGS: 00010246
>>> RAX: 0000000000000010 RBX: ffff8806139126c0 RCX: 0000000000000000
>>> RDX: 0000000000000000 RSI: ffff880613895616 RDI: ffff880613912000
>>> RBP: ffff8806138abe90 R08: 0000000000000000 R09: ffff8806138abb80
>>> R10: 0000000000000000 R11: 0000000000000000 R12: ffff880613912000
>>> R13: ffff8812174f7000 R14: ffff880613912000 R15: ffff8812174f7000
>>> FS: 0000000000000000(0000) GS:ffff8800cfa00000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> CR2: 0000000000000010 CR3: 0000000001c07000 CR4: 00000000000006f0
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> Process work_for_cpu (pid: 1650, threadinfo ffff8806138aa000, task
>>> ffff880616f12be0)
>>> Stack:
>>> ffff8812174f7090 0000000000000246 ffff8806138abe90 ffff8812174f7000
>>> 00008806138abfd8 0000000000000282 68cd0025b30068cc ffff880c17439d30
>>> ffff8812174f7090 ffff8812174f7000 ffff8812174f7208 0000000000000000
>>> Call Trace:
>>> [<ffffffff81203696>] local_pci_probe+0x48/0x91
>>> [<ffffffff81052bae>] ? do_work_for_cpu+0x0/0x26
>>> [<ffffffff81052bc1>] do_work_for_cpu+0x13/0x26
>>> [<ffffffff81052bae>] ? do_work_for_cpu+0x0/0x26
>>> [<ffffffff81057a7b>] kthread+0x81/0x89
>>> [<ffffffff81003854>] kernel_thread_helper+0x4/0x10
>>> [<ffffffff810579fa>] ? kthread+0x0/0x89
>>> [<ffffffff81003850>] ? kernel_thread_helper+0x0/0x10
>>> Code: 00 eb 15 49 8d bf 90 00 00 00 48 c7 c6 1b 2e aa 81 31 c0 e8 c0
>>> 4e cd ff 4c 89 f7 e8 d6 bb ee ff 49 8b 96 00 03 00 00 48 8d 42 10 <f0>
>>> 80 4a 10 01 4c 89 f7 e8 a3 7e ed ff 85 c0 41 89 c4 74 2a 49
>>> RIP [<ffffffff8160afda>] netxen_nic_probe+0x813/0x9a0
>>> RSP <ffff8806138abe30>
>>> CR2: 0000000000000010
>>> ---[ end trace 059c7071bbf8de1f ]---
>> Could you please try the following patch.
>
> Why do you need to touch the queue state at all in the probing code?
>
> Until the first ->open() occurs, the queue state is "don't care."
>
> The netif_carrier_off() call is fine.
>
Ok, thanks Dave, now I see.
[PATCH] netxen_nic: Fix the tx queue manipulation bug in netxen_nic_probe
We should not stop the egress queue during probe because it is wrong.
Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
---
drivers/net/netxen/netxen_nic_main.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 50820be..bc156b0 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1240,7 +1240,6 @@ netxen_setup_netdev(struct netxen_adapter *adapter,
dev_warn(&pdev->dev, "failed to read mac addr\n");
netif_carrier_off(netdev);
- netif_stop_queue(netdev);
err = register_netdev(netdev);
if (err) {
--
1.7.0
^ permalink raw reply related
* Re: [RFC PATCH 1/1] vhost: TX used buffer guest signal accumulation
From: Michael S. Tsirkin @ 2010-10-30 20:06 UTC (permalink / raw)
To: Shirley Ma; +Cc: David Miller, netdev, kvm, linux-kernel
In-Reply-To: <1288366988.4110.5.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2192 bytes --]
On Fri, Oct 29, 2010 at 08:43:08AM -0700, Shirley Ma wrote:
> On Fri, 2010-10-29 at 10:10 +0200, Michael S. Tsirkin wrote:
> > Hmm. I don't yet understand. We are still doing copies into the per-vq
> > buffer, and the data copied is really small. Is it about cache line
> > bounces? Could you try figuring it out?
>
> per-vq buffer is much less expensive than 3 put_copy() call. I will
> collect the profiling data to show that.
What about __put_user? Maybe the access checks are the ones
that add the cost here? I attach patches to strip access checks:
they are not needed as we do them on setup time already, anyway.
Can you try them out and see if performance is improved for you please?
On top of this, we will need to add some scheme to accumulate signals,
but that is a separate issue.
> > > > 2. How about flushing out queued stuff before we exit
> > > > the handle_tx loop? That would address most of
> > > > the spec issue.
> > >
> > > The performance is almost as same as the previous patch. I will
> > resubmit
> > > the modified one, adding vhost_add_used_and_signal_n after handle_tx
> > > loop for processing pending queue.
> > >
> > > This patch was a part of modified macvtap zero copy which I haven't
> > > submitted yet. I found this helped vhost TX in general. This pending
> > > queue will be used by DMA done later, so I put it in vq instead of a
> > > local variable in handle_tx.
> > >
> > > Thanks
> > > Shirley
> >
> > BTW why do we need another array? Isn't heads field exactly what we
> > need
> > here?
>
> head field is only for up to 32, the more used buffers add and signal
> accumulated the better performance is from test results.
I think we should separate the used update and signalling. Interrupts
are expensive so I can believe accumulating even up to 100 of them
helps. But used head copies are already prety cheap. If we cut the
overhead by x32, that should make them almost free?
> That's was one
> of the reason I didn't use heads. The other reason was I used these
> buffer for pending dma done in mavctap zero copy patch. It could be up
> to vq->num in worse case.
We can always increase that, not an issue.
> Thanks
> Shirley
[-- Attachment #2: 1 --]
[-- Type: text/plain, Size: 809 bytes --]
commit f983547ed65a90c73b3e5eeee707041cc04acb0e
Author: Michael S. Tsirkin <mst@redhat.com>
Date: Tue Sep 21 14:18:01 2010 +0200
vhost: copy_to_user -> __copy_to_user
We do access_ok checks at setup time, so we don't need to
redo them on each access.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 54ba561..5109bc0 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1245,7 +1245,7 @@ static int __vhost_add_used_n(struct vhost_virtqueue *vq,
start = vq->last_used_idx % vq->num;
used = vq->used->ring + start;
- if (copy_to_user(used, heads, count * sizeof *used)) {
+ if (__copy_to_user(used, heads, count * sizeof *used)) {
vq_err(vq, "Failed to write used");
return -EFAULT;
}
[-- Attachment #3: 2 --]
[-- Type: text/plain, Size: 2889 bytes --]
commit 85337783cb9487246ed067592e50a5ee800e2683
Author: Michael S. Tsirkin <mst@redhat.com>
Date: Sun Sep 19 15:56:30 2010 +0200
vhost: get/put_user -> __get/__put_user
We do access_ok checks on all ring values on an ioctl,
so we don't need to redo them on each access.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 3440197..54ba561 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1082,7 +1082,7 @@ int vhost_get_vq_desc(struct vhost_dev *dev, struct vhost_virtqueue *vq,
/* Check it isn't doing very strange things with descriptor numbers. */
last_avail_idx = vq->last_avail_idx;
- if (unlikely(get_user(vq->avail_idx, &vq->avail->idx))) {
+ if (unlikely(__get_user(vq->avail_idx, &vq->avail->idx))) {
vq_err(vq, "Failed to access avail idx at %p\n",
&vq->avail->idx);
return -EFAULT;
@@ -1103,8 +1103,8 @@ int vhost_get_vq_desc(struct vhost_dev *dev, struct vhost_virtqueue *vq,
/* Grab the next descriptor number they're advertising, and increment
* the index we've seen. */
- if (unlikely(get_user(head,
- &vq->avail->ring[last_avail_idx % vq->num]))) {
+ if (unlikely(__get_user(head,
+ &vq->avail->ring[last_avail_idx % vq->num]))) {
vq_err(vq, "Failed to read head: idx %d address %p\n",
last_avail_idx,
&vq->avail->ring[last_avail_idx % vq->num]);
@@ -1203,17 +1203,17 @@ int vhost_add_used(struct vhost_virtqueue *vq, unsigned int head, int len)
/* The virtqueue contains a ring of used buffers. Get a pointer to the
* next entry in that used ring. */
used = &vq->used->ring[vq->last_used_idx % vq->num];
- if (put_user(head, &used->id)) {
+ if (__put_user(head, &used->id)) {
vq_err(vq, "Failed to write used id");
return -EFAULT;
}
- if (put_user(len, &used->len)) {
+ if (__put_user(len, &used->len)) {
vq_err(vq, "Failed to write used len");
return -EFAULT;
}
/* Make sure buffer is written before we update index. */
smp_wmb();
- if (put_user(vq->last_used_idx + 1, &vq->used->idx)) {
+ if (__put_user(vq->last_used_idx + 1, &vq->used->idx)) {
vq_err(vq, "Failed to increment used idx");
return -EFAULT;
}
@@ -1306,7 +1306,7 @@ void vhost_signal(struct vhost_dev *dev, struct vhost_virtqueue *vq)
* interrupts. */
smp_mb();
- if (get_user(flags, &vq->avail->flags)) {
+ if (__get_user(flags, &vq->avail->flags)) {
vq_err(vq, "Failed to get flags");
return;
}
@@ -1357,7 +1357,7 @@ bool vhost_enable_notify(struct vhost_virtqueue *vq)
/* They could have slipped one in as we were doing that: make
* sure it's written, then check again. */
smp_mb();
- r = get_user(avail_idx, &vq->avail->idx);
+ r = __get_user(avail_idx, &vq->avail->idx);
if (r) {
vq_err(vq, "Failed to check avail idx at %p: %d\n",
&vq->avail->idx, r);
^ permalink raw reply related
* Re: [PATCH] macvlan: Introduce 'passthru' mode to takeover the underlying device
From: Sridhar Samudrala @ 2010-10-30 20:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Patrick McHardy, Stephen Hemminger, Michael S. Tsirkin, netdev,
kvm@vger.kernel.org
In-Reply-To: <201010291545.17910.arnd@arndb.de>
On 10/29/2010 6:45 AM, Arnd Bergmann wrote:
> On Friday 29 October 2010, Sridhar Samudrala wrote:
>> With the current default 'vepa' mode, a KVM guest using virtio with
>> macvtap backend has the following limitations.
>> - cannot change/add a mac address on the guest virtio-net
> I believe this could be changed if there is a neeed, but I actually
> consider it one of the design points of macvlan that the guest
> is not able to change the mac address. With 802.1Qbg you rely on
> the switch being able to identify the guest by its MAC address,
> which the host kernel must ensure.
>
Currently the host cannot prevent a guest user from trying to change/add
a mac address
on the guest virtio-net. From guest point of view, the request succeeds,
but the incoming packets
are dropped siliently by the host interface.
>> - cannot create a vlan device on the guest virtio-net
> Why not? If this doesn't work, it's probably a bug!
Because the host is not aware of the guest vlan tag and the host
external interface will filter out
incoming vlan tagged packets.
> Why does the passthru mode enable it if it doesn't work
> already?
>
passthru mode puts the host external interface in promiscuous mode which
allows vlan tagged
packets to be received.
Even in tap/bridge mode, this works because adding an external interface
to the bridge causes it to be
put in promiscuous mode.
Thanks
Sridhar
^ permalink raw reply
* [PATCH 00/39] Cleanup WARN #defines
From: Joe Perches @ 2010-10-30 21:08 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-alpha, linux-kernel, linux-arm-kernel, linux-omap,
linux-tegra, linuxppc-dev, linux-pm, discuss, linux-acpi,
linux1394-devel, dri-devel, intel-gfx, linux-media,
socketcan-core, netdev, linux-usb, linux-wireless, devel,
linux-scsi, devel, linux-fbdev, linux-fsdevel, linux-nfs,
linux-arch, linux-mm, alsa-devel
WARN uses sometimes use KERN_<level> but mostly don't
have any prefix.
Change the WARN macros and the warn_slowpath function to preface
KERN_WARNING and remove all the KERN_<level> uses from WARN sites.
Neatening clean up of include/asm-generic/bug.h
Update WARN macros
Add KERN_WARNING to WARN output
Remove any KERN_<level> from WARN uses
Coalesce formats
Align WARN arguments
Add some missing newlines to WARN uses
Add some missing first test argument (1, fmt, args) to WARN uses
Joe Perches (39):
include/asm-generic/bug.h: Update WARN macros
arch/alpha: Update WARN uses
arch/arm: Update WARN uses
arch/powerpc: Update WARN uses
arch/x86: Update WARN uses
drivers/acpi: Update WARN uses
drivers/base: Update WARN uses
drivers/block: Update WARN uses
drivers/cpuidle: Update WARN uses
drivers/firewire: Update WARN uses
drivers/firmware: Update WARN uses
drivers/gpio: Update WARN uses
drivers/gpu/drm: Update WARN uses
drivers/media/video: Update WARN uses
drivers/mfd: Update WARN uses
drivers/net/can: Update WARN uses
drivers/net/usb: Update WARN uses
drivers/net/wireless/iwlwifi: Update WARN uses
drivers/regulator: Update WARN uses
drivers/scsi/fcoe: Update WARN uses
drivers/staging: Update WARN uses
drivers/usb/musb: Update WARN uses
drivers/video/omap2/dss: Update WARN uses
fs/nfsd: Update WARN uses
fs/notify/inotify: Update WARN uses
fs/sysfs: Update WARN uses
fs/proc: Update WARN uses
fs: Update WARN uses
include/linux/device.h: Update WARN uses
kernel/irq: Update WARN uses
kernel/panic.c: Update warn_slowpath to use %pV
kernel: Update WARN uses
lib: Update WARN uses
mm: Update WARN uses
net/core/dev.c: Update WARN uses
net/ipv4/tcp.c: Update WARN uses
net/mac80211: Update WARN uses
net/rfkill/input.c: Update WARN uses
sound/soc/codecs/wm_hubs.c: Update WARN uses
arch/alpha/kernel/pci-sysfs.c | 14 ++--
arch/arm/mach-davinci/clock.c | 4 +-
arch/arm/mach-davinci/da830.c | 2 +-
arch/arm/mach-davinci/da850.c | 12 ++--
arch/arm/mach-omap2/clkt_clksel.c | 12 ++--
arch/arm/mach-omap2/clock.c | 16 ++--
arch/arm/mach-omap2/devices.c | 4 +-
arch/arm/mach-omap2/omap_hwmod.c | 47 +++++++-----
arch/arm/mach-omap2/pm34xx.c | 7 +-
arch/arm/mach-omap2/serial.c | 2 +-
arch/arm/mach-omap2/timer-gp.c | 3 +-
arch/arm/mach-tegra/clock.c | 3 +-
arch/arm/mach-tegra/timer.c | 2 +-
arch/arm/mach-u300/padmux.c | 14 +---
arch/arm/plat-omap/omap-pm-noop.c | 10 ++--
arch/powerpc/kernel/hw_breakpoint.c | 4 +-
arch/x86/kernel/acpi/boot.c | 2 +-
arch/x86/kernel/apic/apic.c | 2 +-
arch/x86/kernel/apic/es7000_32.c | 2 +-
arch/x86/kernel/cpu/perf_event.c | 4 +-
arch/x86/kernel/pci-calgary_64.c | 4 +-
arch/x86/kernel/tsc_sync.c | 4 +-
arch/x86/kernel/xsave.c | 2 +-
arch/x86/mm/ioremap.c | 5 +-
arch/x86/mm/pageattr-test.c | 2 +-
arch/x86/mm/pageattr.c | 5 +-
arch/x86/platform/sfi/sfi.c | 4 +-
drivers/acpi/ec.c | 4 +-
drivers/base/class.c | 4 +-
drivers/base/core.c | 5 +-
drivers/base/memory.c | 4 +-
drivers/base/sys.c | 10 +--
drivers/block/floppy.c | 2 +-
drivers/cpuidle/driver.c | 2 +-
drivers/firewire/core-transaction.c | 6 +-
drivers/firmware/dmi_scan.c | 2 +-
drivers/gpio/gpiolib.c | 4 +-
drivers/gpio/it8761e_gpio.c | 2 +-
drivers/gpu/drm/drm_crtc_helper.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 3 +-
drivers/gpu/drm/radeon/evergreen.c | 2 +-
drivers/gpu/drm/radeon/r100.c | 4 +-
drivers/gpu/drm/radeon/r300.c | 2 +-
drivers/gpu/drm/radeon/r600.c | 4 +-
drivers/gpu/drm/radeon/radeon_fence.c | 3 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 3 +-
drivers/gpu/drm/radeon/rs400.c | 2 +-
drivers/gpu/drm/radeon/rs600.c | 4 +-
drivers/media/video/s5p-fimc/fimc-core.c | 2 +-
drivers/media/video/sr030pc30.c | 2 +-
drivers/mfd/ezx-pcap.c | 5 +-
drivers/net/can/mscan/mscan.c | 2 +-
drivers/net/usb/ipheth.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-agn-sta.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 6 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
drivers/regulator/core.c | 3 +-
drivers/scsi/fcoe/libfcoe.c | 2 +-
drivers/staging/memrar/memrar_allocator.c | 2 +-
drivers/staging/solo6x10/solo6010-v4l2-enc.c | 2 +-
drivers/usb/musb/musb_host.c | 6 +-
drivers/video/omap2/dss/core.c | 3 +-
fs/bio.c | 2 +-
fs/buffer.c | 2 +-
fs/nfsd/nfs4state.c | 3 +-
fs/notify/inotify/inotify_fsnotify.c | 4 +-
fs/proc/generic.c | 9 +--
fs/super.c | 5 +-
fs/sysfs/dir.c | 3 +-
fs/sysfs/file.c | 4 +-
fs/sysfs/group.c | 4 +-
fs/sysfs/symlink.c | 10 +--
include/asm-generic/bug.h | 101 ++++++++++++++++----------
include/linux/device.h | 2 +-
kernel/irq/chip.c | 2 +-
kernel/irq/manage.c | 2 +-
kernel/notifier.c | 2 +-
kernel/panic.c | 40 +++++------
kernel/pm_qos_params.c | 6 +-
lib/debugobjects.c | 21 +++---
lib/iomap.c | 2 +-
lib/kobject.c | 9 +--
lib/kobject_uevent.c | 4 +-
lib/list_debug.c | 24 +++----
lib/plist.c | 12 ++--
mm/percpu.c | 4 +-
mm/vmalloc.c | 5 +-
net/core/dev.c | 3 +-
net/ipv4/tcp.c | 16 ++---
net/mac80211/agg-tx.c | 5 +-
net/mac80211/iface.c | 4 +-
net/mac80211/mlme.c | 2 +-
net/mac80211/rx.c | 4 +-
net/mac80211/tx.c | 4 +-
net/mac80211/util.c | 4 +-
net/mac80211/work.c | 4 +-
net/rfkill/input.c | 5 +-
sound/soc/codecs/wm_hubs.c | 2 +-
99 files changed, 319 insertions(+), 330 deletions(-)
--
1.7.3.1.g432b3.dirty
^ permalink raw reply
* [PATCH 16/39] drivers/net/can: Update WARN uses
From: Joe Perches @ 2010-10-30 21:08 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Wolfgang Grandegger, socketcan-core, netdev, linux-kernel
In-Reply-To: <cover.1288471897.git.joe@perches.com>
Add missing newlines.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/can/mscan/mscan.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/can/mscan/mscan.c b/drivers/net/can/mscan/mscan.c
index 64c378c..74cd880 100644
--- a/drivers/net/can/mscan/mscan.c
+++ b/drivers/net/can/mscan/mscan.c
@@ -182,7 +182,7 @@ static int mscan_restart(struct net_device *dev)
priv->can.state = CAN_STATE_ERROR_ACTIVE;
WARN(!(in_8(®s->canmisc) & MSCAN_BOHOLD),
- "bus-off state expected");
+ "bus-off state expected\n");
out_8(®s->canmisc, MSCAN_BOHOLD);
/* Re-enable receive interrupts. */
out_8(®s->canrier, MSCAN_RX_INTS_ENABLE);
--
1.7.3.1.g432b3.dirty
^ permalink raw reply related
* [PATCH 17/39] drivers/net/usb: Update WARN uses
From: Joe Perches @ 2010-10-30 21:08 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Greg Kroah-Hartman, linux-usb, netdev, linux-kernel
In-Reply-To: <cover.1288471897.git.joe@perches.com>
Add missing newlines.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/usb/ipheth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index b2bcf99..7d42f9a 100644
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -363,7 +363,7 @@ static int ipheth_tx(struct sk_buff *skb, struct net_device *net)
/* Paranoid */
if (skb->len > IPHETH_BUF_SIZE) {
- WARN(1, "%s: skb too large: %d bytes", __func__, skb->len);
+ WARN(1, "%s: skb too large: %d bytes\n", __func__, skb->len);
dev->net->stats.tx_dropped++;
dev_kfree_skb_irq(skb);
return NETDEV_TX_OK;
--
1.7.3.1.g432b3.dirty
^ 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