* [PATCH 3/4] batman-adv: Remove vis info element in free_info
From: Sven Eckelmann @ 2011-01-30 12:11 UTC (permalink / raw)
To: davem; +Cc: netdev, Sven Eckelmann
In-Reply-To: <1296389504-11208-1-git-send-email-sven@narfation.org>
The free_info function will be called when no reference to the info
object exists anymore. It must be ensured that the allocated memory
gets freed and not only the elements which are managed by the info
object.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
net/batman-adv/vis.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/batman-adv/vis.c b/net/batman-adv/vis.c
index 0be55be..988296c 100644
--- a/net/batman-adv/vis.c
+++ b/net/batman-adv/vis.c
@@ -64,6 +64,7 @@ static void free_info(struct kref *ref)
spin_unlock_bh(&bat_priv->vis_list_lock);
kfree_skb(info->skb_packet);
+ kfree(info);
}
/* Compare two vis packets, used by the hashing algorithm */
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/4] batman-adv: Make vis info stack traversal threadsafe
From: Sven Eckelmann @ 2011-01-30 12:11 UTC (permalink / raw)
To: davem; +Cc: netdev, Sven Eckelmann
In-Reply-To: <1296389504-11208-1-git-send-email-sven@narfation.org>
The batman-adv vis server has to a stack which stores all information
about packets which should be send later. This stack is protected
with a spinlock that is used to prevent concurrent write access to it.
The send_vis_packets function has to take all elements from the stack
and send them to other hosts over the primary interface. The send will
be initiated without the lock which protects the stack.
The implementation using list_for_each_entry_safe has the problem that
it stores the next element as "safe ptr" to allow the deletion of the
current element in the list. The list may be modified during the
unlock/lock pair in the loop body which may make the safe pointer
not pointing to correct next element.
It is safer to remove and use the first element from the stack until no
elements are available. This does not need reduntant information which
would have to be validated each time the lock was removed.
Reported-by: Russell Senior <russell@personaltelco.net>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
net/batman-adv/vis.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/batman-adv/vis.c b/net/batman-adv/vis.c
index 988296c..de1022c 100644
--- a/net/batman-adv/vis.c
+++ b/net/batman-adv/vis.c
@@ -816,7 +816,7 @@ static void send_vis_packets(struct work_struct *work)
container_of(work, struct delayed_work, work);
struct bat_priv *bat_priv =
container_of(delayed_work, struct bat_priv, vis_work);
- struct vis_info *info, *temp;
+ struct vis_info *info;
spin_lock_bh(&bat_priv->vis_hash_lock);
purge_vis_packets(bat_priv);
@@ -826,8 +826,9 @@ static void send_vis_packets(struct work_struct *work)
send_list_add(bat_priv, bat_priv->my_vis_info);
}
- list_for_each_entry_safe(info, temp, &bat_priv->vis_send_list,
- send_list) {
+ while (!list_empty(&bat_priv->vis_send_list)) {
+ info = list_first_entry(&bat_priv->vis_send_list,
+ typeof(*info), send_list);
kref_get(&info->refcount);
spin_unlock_bh(&bat_priv->vis_hash_lock);
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] net: Add compat ioctl support for the ipv4 multicast ioctl SIOCGETSGCNT
From: Arnd Bergmann @ 2011-01-30 12:26 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, David Miller, Eric Dumazet, Patrick McHardy
In-Reply-To: <m18vy3uof7.fsf@fess.ebiederm.org>
On Sunday 30 January 2011 03:15:56 Eric W. Biederman wrote:
> A trivial compact ioctl implementation would conflict with:
> SIOCAX25ADDUID
> SIOCAIPXPRISLT
> SIOCGETSGCNT_IN6
> SIOCGETSGCNT
> SIOCRSSCAUSE
> SIOCX25SSUBSCRIP
> SIOCX25SDTEFACILITIES
Since you have compiled the list, did you see if these are all handled
compatible, or would it make sense to create patches for the other
protocols as well, to handle them individually?
> This was necessary because unfortunately the struct layout for the SIOCGETSGCNT
> has unsigned longs in it so changes between 32bit and 64bit kernels.
>
> This change was sufficient to run a 32bit ip multicast routing daemon on a
> 64bit kernel.
>
> Reported-by: Bill Fenner <fenner@aristanetworks.com>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Looks good,
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> +#ifdef CONFIG_COMPAT
> +static int compat_raw_ioctl(struct sock *sk, unsigned int cmd, unsigned long arg)
> +{
> + switch (cmd) {
> + case SIOCOUTQ:
> + case SIOCINQ:
> + return -ENOIOCTLCMD;
I would have suggested doing
return raw_ioctl(sk, cmd, (unsigned long)compat_ptr(arg));
here, but returning -ENOIOCTLCMD is equivalent and correct. Your solution
is slightly more compact, the other one would be slightly faster.
Arnd
^ permalink raw reply
* Re: [PATCH]netdev: add driver for enc424j600 ethernet chip on SPI bus
From: Balaji Venkatachalam @ 2011-01-30 12:34 UTC (permalink / raw)
To: David Miller
Cc: romieu, netdev, mirqus, mohan, blue.cube, lanconelli.claudio,
sriram, vbalaji.acs
In-Reply-To: <AANLkTimC3bsvT24cz4A+iJfjgL3LxBWxKzb182ocqbiL@mail.gmail.com>
I am extremely sorry, for having overlooked the details. It is not my
intent to rush through the review process. I hold the reviewers time
and feedback valuable and will ensure that this will not repeat again.
^ permalink raw reply
* [PATCH net-2.6 0/5] bnx2x: Minor link related fixes
From: Yaniv Rosner @ 2011-01-30 14:14 UTC (permalink / raw)
To: davem; +Cc: netdev, eilong
Hi Dave,
The following patch series describe some link fixes in bnx2x driver
Please consider applying it to net-2.6.
Thanks,
Yaniv
^ permalink raw reply
* [PATCH net-2.6 3/5] bnx2x: Fix port swap for BCM8073
From: Yaniv Rosner @ 2011-01-30 14:15 UTC (permalink / raw)
To: davem; +Cc: netdev, eilong
Fix link on BCM57712 + BCM8073 when port swap is enabled. Common PHY reset was done on the wrong port.
Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_link.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_link.c b/drivers/net/bnx2x/bnx2x_link.c
index b1c667a..dd1210f 100644
--- a/drivers/net/bnx2x/bnx2x_link.c
+++ b/drivers/net/bnx2x/bnx2x_link.c
@@ -7688,10 +7688,13 @@ static u8 bnx2x_8073_common_init_phy(struct bnx2x *bp,
struct bnx2x_phy phy[PORT_MAX];
struct bnx2x_phy *phy_blk[PORT_MAX];
u16 val;
- s8 port;
+ s8 port = 0;
s8 port_of_path = 0;
-
- bnx2x_ext_phy_hw_reset(bp, 0);
+ u32 swap_val, swap_override;
+ swap_val = REG_RD(bp, NIG_REG_PORT_SWAP);
+ swap_override = REG_RD(bp, NIG_REG_STRAP_OVERRIDE);
+ port ^= (swap_val && swap_override);
+ bnx2x_ext_phy_hw_reset(bp, port);
/* PART1 - Reset both phys */
for (port = PORT_MAX - 1; port >= PORT_0; port--) {
u32 shmem_base, shmem2_base;
--
1.7.1
^ permalink raw reply related
* [PATCH net-2.6 1/5] bnx2x: Remove setting XAUI low-power for BCM8073
From: Yaniv Rosner @ 2011-01-30 14:14 UTC (permalink / raw)
To: davem; +Cc: netdev, eilong
A rare link issue with the BCM8073 PHY may occur due to setting XAUI low power mode, while the PHY microcode already does that.
The fix is not to set set XAUI low power mode for this PHY.
Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_link.c | 44 ----------------------------------------
1 files changed, 0 insertions(+), 44 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_link.c b/drivers/net/bnx2x/bnx2x_link.c
index 7160ec5..53a95a2 100644
--- a/drivers/net/bnx2x/bnx2x_link.c
+++ b/drivers/net/bnx2x/bnx2x_link.c
@@ -3948,48 +3948,6 @@ static u8 bnx2x_8073_8727_external_rom_boot(struct bnx2x *bp,
return rc;
}
-static void bnx2x_8073_set_xaui_low_power_mode(struct bnx2x *bp,
- struct bnx2x_phy *phy)
-{
- u16 val;
- bnx2x_cl45_read(bp, phy,
- MDIO_PMA_DEVAD, MDIO_PMA_REG_8073_CHIP_REV, &val);
-
- if (val == 0) {
- /* Mustn't set low power mode in 8073 A0 */
- return;
- }
-
- /* Disable PLL sequencer (use read-modify-write to clear bit 13) */
- bnx2x_cl45_read(bp, phy,
- MDIO_XS_DEVAD, MDIO_XS_PLL_SEQUENCER, &val);
- val &= ~(1<<13);
- bnx2x_cl45_write(bp, phy,
- MDIO_XS_DEVAD, MDIO_XS_PLL_SEQUENCER, val);
-
- /* PLL controls */
- bnx2x_cl45_write(bp, phy, MDIO_XS_DEVAD, 0x805E, 0x1077);
- bnx2x_cl45_write(bp, phy, MDIO_XS_DEVAD, 0x805D, 0x0000);
- bnx2x_cl45_write(bp, phy, MDIO_XS_DEVAD, 0x805C, 0x030B);
- bnx2x_cl45_write(bp, phy, MDIO_XS_DEVAD, 0x805B, 0x1240);
- bnx2x_cl45_write(bp, phy, MDIO_XS_DEVAD, 0x805A, 0x2490);
-
- /* Tx Controls */
- bnx2x_cl45_write(bp, phy, MDIO_XS_DEVAD, 0x80A7, 0x0C74);
- bnx2x_cl45_write(bp, phy, MDIO_XS_DEVAD, 0x80A6, 0x9041);
- bnx2x_cl45_write(bp, phy, MDIO_XS_DEVAD, 0x80A5, 0x4640);
-
- /* Rx Controls */
- bnx2x_cl45_write(bp, phy, MDIO_XS_DEVAD, 0x80FE, 0x01C4);
- bnx2x_cl45_write(bp, phy, MDIO_XS_DEVAD, 0x80FD, 0x9249);
- bnx2x_cl45_write(bp, phy, MDIO_XS_DEVAD, 0x80FC, 0x2015);
-
- /* Enable PLL sequencer (use read-modify-write to set bit 13) */
- bnx2x_cl45_read(bp, phy, MDIO_XS_DEVAD, MDIO_XS_PLL_SEQUENCER, &val);
- val |= (1<<13);
- bnx2x_cl45_write(bp, phy, MDIO_XS_DEVAD, MDIO_XS_PLL_SEQUENCER, val);
-}
-
/******************************************************************/
/* BCM8073 PHY SECTION */
/******************************************************************/
@@ -4148,8 +4106,6 @@ static u8 bnx2x_8073_config_init(struct bnx2x_phy *phy,
bnx2x_8073_set_pause_cl37(params, phy, vars);
- bnx2x_8073_set_xaui_low_power_mode(bp, phy);
-
bnx2x_cl45_read(bp, phy,
MDIO_PMA_DEVAD, MDIO_PMA_REG_M8051_MSGOUT_REG, &tmp1);
--
1.7.1
^ permalink raw reply related
* [PATCH net-2.6 2/5] bnx2x: Fix LED blink rate on BCM84823
From: Yaniv Rosner @ 2011-01-30 14:14 UTC (permalink / raw)
To: davem; +Cc: netdev, eilong
Fix blink rate of activity LED of the BCM84823 on 10G link
Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_link.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_link.c b/drivers/net/bnx2x/bnx2x_link.c
index 53a95a2..b1c667a 100644
--- a/drivers/net/bnx2x/bnx2x_link.c
+++ b/drivers/net/bnx2x/bnx2x_link.c
@@ -6475,6 +6475,18 @@ static void bnx2x_848xx_set_link_led(struct bnx2x_phy *phy,
MDIO_PMA_DEVAD,
MDIO_PMA_REG_8481_LED1_MASK,
0x80);
+
+ /* Tell LED3 to blink on source */
+ bnx2x_cl45_read(bp, phy,
+ MDIO_PMA_DEVAD,
+ MDIO_PMA_REG_8481_LINK_SIGNAL,
+ &val);
+ val &= ~(7<<6);
+ val |= (1<<6); /* A83B[8:6]= 1 */
+ bnx2x_cl45_write(bp, phy,
+ MDIO_PMA_DEVAD,
+ MDIO_PMA_REG_8481_LINK_SIGNAL,
+ val);
}
break;
}
--
1.7.1
^ permalink raw reply related
* [PATCH net-2.6 4/5] bnx2x: Fix potential link loss in multi-function mode
From: Yaniv Rosner @ 2011-01-30 14:15 UTC (permalink / raw)
To: davem; +Cc: netdev, eilong
All functions on a port should be set to take the MDC/MDIO lock to avoid contention on the bus
Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 18 +++++++++++-------
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 8cdcf5b..404d93e 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -5296,10 +5296,6 @@ static int bnx2x_init_hw_common(struct bnx2x *bp, u32 load_code)
}
}
- bp->port.need_hw_lock = bnx2x_hw_lock_required(bp,
- bp->common.shmem_base,
- bp->common.shmem2_base);
-
bnx2x_setup_fan_failure_detection(bp);
/* clear PXP2 attentions */
@@ -5503,9 +5499,6 @@ static int bnx2x_init_hw_port(struct bnx2x *bp)
bnx2x_init_block(bp, MCP_BLOCK, init_stage);
bnx2x_init_block(bp, DMAE_BLOCK, init_stage);
- bp->port.need_hw_lock = bnx2x_hw_lock_required(bp,
- bp->common.shmem_base,
- bp->common.shmem2_base);
if (bnx2x_fan_failure_det_req(bp, bp->common.shmem_base,
bp->common.shmem2_base, port)) {
u32 reg_addr = (port ? MISC_REG_AEU_ENABLE1_FUNC_1_OUT_0 :
@@ -8379,6 +8372,17 @@ static void __devinit bnx2x_get_port_hwinfo(struct bnx2x *bp)
(ext_phy_type != PORT_HW_CFG_XGXS_EXT_PHY_TYPE_NOT_CONN))
bp->mdio.prtad =
XGXS_EXT_PHY_ADDR(ext_phy_config);
+
+ /*
+ * Check if hw lock is required to access MDC/MDIO bus to the PHY(s)
+ * In MF mode, it is set to cover self test cases
+ */
+ if (IS_MF(bp))
+ bp->port.need_hw_lock = 1;
+ else
+ bp->port.need_hw_lock = bnx2x_hw_lock_required(bp,
+ bp->common.shmem_base,
+ bp->common.shmem2_base);
}
static void __devinit bnx2x_get_mac_hwinfo(struct bnx2x *bp)
--
1.7.1
^ permalink raw reply related
* [PATCH net-2.6 5/5] bnx2x: Update bnx2x version to 1.62.00-5
From: Yaniv Rosner @ 2011-01-30 14:15 UTC (permalink / raw)
To: davem; +Cc: netdev, eilong
Update bnx2x version to 1.62.00-5
Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 8e41837..653c624 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -22,8 +22,8 @@
* (you will need to reboot afterwards) */
/* #define BNX2X_STOP_ON_ERROR */
-#define DRV_MODULE_VERSION "1.62.00-4"
-#define DRV_MODULE_RELDATE "2011/01/18"
+#define DRV_MODULE_VERSION "1.62.00-5"
+#define DRV_MODULE_RELDATE "2011/01/30"
#define BNX2X_BC_VER 0x040200
#define BNX2X_MULTI_QUEUE
--
1.7.1
^ permalink raw reply related
* Blog coverage of Consistent Network Device Naming
From: Matt Domsch @ 2011-01-30 14:23 UTC (permalink / raw)
To: linux-hotplug, netdev
There has been a good bit of blog coverage over the Consistent Network
Device Naming (biosdevname) feature this past week. If you're curious:
A Lesson In Persistency by Rahul Sundaram
http://fedoranext.wordpress.com/2010/12/07/a-lesson-in-persistency
NetworkWorld 2011-01-24 by Joe Brockmeier
http://www.networkworld.com/community/fedora-15-changes-network-device-naming
Matt Domsch's blog and repost on dell.com
http://domsch.com/blog/?p=455 2011-01-23
http://en.community.dell.com/dell-blogs/enterprise/b/tech-center/archive/2011/01/24/consistent-network-device-naming-coming-to-fedora-15.aspx
LWN.net
http://lwn.net/Articles/424859/#Comments
Slashdot
http://linux.slashdot.org/story/11/01/26/0252220/Fedora-15-Changes-Network-Device-Naming-Scheme
Digitizor
http://digitizor.com/2011/01/25/fedora-15-network-device-naming/ Digitizor 2011-01-25
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [PATCH] net: Add compat ioctl support for the ipv4 multicast ioctl SIOCGETSGCNT
From: Eric W. Biederman @ 2011-01-30 18:15 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: netdev, David Miller, Eric Dumazet, Patrick McHardy
In-Reply-To: <201101301326.14390.arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> On Sunday 30 January 2011 03:15:56 Eric W. Biederman wrote:
>> A trivial compact ioctl implementation would conflict with:
>> SIOCAX25ADDUID
>> SIOCAIPXPRISLT
>> SIOCGETSGCNT_IN6
>> SIOCGETSGCNT
>> SIOCRSSCAUSE
>> SIOCX25SSUBSCRIP
>> SIOCX25SDTEFACILITIES
>
> Since you have compiled the list, did you see if these are all handled
> compatible, or would it make sense to create patches for the other
> protocols as well, to handle them individually?
I didn't look. I had a specific pre-existing application that didn't
work, and those ioctls meant the existing solutions for network compat
ioctls wouldn't work and the infrastructure needed fixing.
>> +#ifdef CONFIG_COMPAT
>> +static int compat_raw_ioctl(struct sock *sk, unsigned int cmd, unsigned long arg)
>> +{
>> + switch (cmd) {
>> + case SIOCOUTQ:
>> + case SIOCINQ:
>> + return -ENOIOCTLCMD;
>
> I would have suggested doing
>
> return raw_ioctl(sk, cmd, (unsigned long)compat_ptr(arg));
>
> here, but returning -ENOIOCTLCMD is equivalent and correct. Your solution
> is slightly more compact, the other one would be slightly faster.
Correct and maintainable is fine by me.
Right now my network stack performance problems are almost all rtnl_lock
hold time problems.
Eric
^ permalink raw reply
* Re: [PATCH] net: Add compat ioctl support for the ipv4 multicast ioctl SIOCGETSGCNT
From: Arnd Bergmann @ 2011-01-30 18:59 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, David Miller, Eric Dumazet, Patrick McHardy
In-Reply-To: <m18vy2tfzn.fsf@fess.ebiederm.org>
On Sunday 30 January 2011 19:15:40 Eric W. Biederman wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
> > On Sunday 30 January 2011 03:15:56 Eric W. Biederman wrote:
> >> A trivial compact ioctl implementation would conflict with:
> >> SIOCAX25ADDUID
> >> SIOCAIPXPRISLT
> >> SIOCGETSGCNT_IN6
> >> SIOCGETSGCNT
> >> SIOCRSSCAUSE
> >> SIOCX25SSUBSCRIP
> >> SIOCX25SDTEFACILITIES
> >
> > Since you have compiled the list, did you see if these are all handled
> > compatible, or would it make sense to create patches for the other
> > protocols as well, to handle them individually?
>
> I didn't look. I had a specific pre-existing application that didn't
> work, and those ioctls meant the existing solutions for network compat
> ioctls wouldn't work and the infrastructure needed fixing.
I just looked at all users of SIOCPROTOPRIVATE to check what else
is needed here, for reference. What I found is:
* appletalk, ipx and x25 have full compat_ioctl support.
* ax25 needs some real work in order to be usable in compat mode.
* phonet and rose use only data structures that are compatible,
so adding support would be trivial.
* ip multicast actually needs support for SIOCGETVIFCNT in
addition to SIOCGETSGCNT to be complete.
* ipv6 multicast needs the same patch as ipv4 multicast for
SIOCGETMIFCNT_IN6/SIOCGETSGCNT_IN6.
It would probably be a good idea if someone could complete the
work on ipv4/v6 multicast compat_ioctl, on top of your patch.
Arnd
^ permalink raw reply
* [PATCH] net: Fix ipv6 neighbour unregister_sysctl_table warning
From: Eric W. Biederman @ 2011-01-30 20:15 UTC (permalink / raw)
To: netdev; +Cc: David Miller, YOSHIFUJI Hideaki
In my testing of 2.6.37 I was occassionally getting a warning about
sysctl table entries being unregistered in the wrong order. Digging
in it turns out this dates back to the last great sysctl reorg done
where Al Viro introduced the requirement that sysctl directories
needed to be created before and destroyed after the files in them.
It turns out that in that great reorg /proc/sys/net/ipv6/neigh was
overlooked. So this patch fixes that oversight and makes an annoying
warning message go away.
>------------[ cut here ]------------
>WARNING: at kernel/sysctl.c:1992 unregister_sysctl_table+0x134/0x164()
>Pid: 23951, comm: kworker/u:3 Not tainted 2.6.37-350888.2010AroraKernelBeta.fc14.x86_64 #1
>Call Trace:
> [<ffffffff8103e034>] warn_slowpath_common+0x80/0x98
> [<ffffffff8103e061>] warn_slowpath_null+0x15/0x17
> [<ffffffff810452f8>] unregister_sysctl_table+0x134/0x164
> [<ffffffff810e7834>] ? kfree+0xc4/0xd1
> [<ffffffff813439b2>] neigh_sysctl_unregister+0x22/0x3a
> [<ffffffffa02cd14e>] addrconf_ifdown+0x33f/0x37b [ipv6]
> [<ffffffff81331ec2>] ? skb_dequeue+0x5f/0x6b
> [<ffffffffa02ce4a5>] addrconf_notify+0x69b/0x75c [ipv6]
> [<ffffffffa02eb953>] ? ip6mr_device_event+0x98/0xa9 [ipv6]
> [<ffffffff813d2413>] notifier_call_chain+0x32/0x5e
> [<ffffffff8105bdea>] raw_notifier_call_chain+0xf/0x11
> [<ffffffff8133cdac>] call_netdevice_notifiers+0x45/0x4a
> [<ffffffff8133d2b0>] rollback_registered_many+0x118/0x201
> [<ffffffff8133d3af>] unregister_netdevice_many+0x16/0x6d
> [<ffffffff8133d571>] default_device_exit_batch+0xa4/0xb8
> [<ffffffff81337c42>] ? cleanup_net+0x0/0x194
> [<ffffffff81337a2a>] ops_exit_list+0x4e/0x56
> [<ffffffff81337d36>] cleanup_net+0xf4/0x194
> [<ffffffff81053318>] process_one_work+0x187/0x280
> [<ffffffff8105441b>] worker_thread+0xff/0x19f
> [<ffffffff8105431c>] ? worker_thread+0x0/0x19f
> [<ffffffff8105776d>] kthread+0x7d/0x85
> [<ffffffff81003824>] kernel_thread_helper+0x4/0x10
> [<ffffffff810576f0>] ? kthread+0x0/0x85
> [<ffffffff81003820>] ? kernel_thread_helper+0x0/0x10
>---[ end trace 8a7e9310b35e9486 ]---
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
net/ipv6/sysctl_net_ipv6.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index fa1d8f4..7cb65ef 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -15,6 +15,8 @@
#include <net/addrconf.h>
#include <net/inet_frag.h>
+static struct ctl_table empty[1];
+
static ctl_table ipv6_table_template[] = {
{
.procname = "route",
@@ -35,6 +37,12 @@ static ctl_table ipv6_table_template[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "neigh",
+ .maxlen = 0,
+ .mode = 0555,
+ .child = empty,
+ },
{ }
};
@@ -152,7 +160,6 @@ static struct ctl_table_header *ip6_base;
int ipv6_static_sysctl_register(void)
{
- static struct ctl_table empty[1];
ip6_base = register_sysctl_paths(net_ipv6_ctl_path, empty);
if (ip6_base == NULL)
return -ENOMEM;
--
1.6.5.2.143.g8cc62
^ permalink raw reply related
* [PATCH] isdn: icn: Fix potentially wrong string handling
From: Stefan Weil @ 2011-01-30 20:31 UTC (permalink / raw)
To: Karsten Keil
Cc: Stefan Weil, Karsten Keil, David S. Miller, Tejun Heo,
Steven Rostedt, netdev, linux-kernel
This warning was reported by cppcheck:
drivers/isdn/icn/icn.c:1641: error: Dangerous usage of 'rev' (strncpy doesn't always 0-terminate it)
If strncpy copied 20 bytes, the destination string rev was not terminated.
The patch adds one more byte to rev and makes sure that this byte is
always 0.
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Tejun Heo <tj@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
---
drivers/isdn/icn/icn.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/isdn/icn/icn.c b/drivers/isdn/icn/icn.c
index f2b5bab..540c181 100644
--- a/drivers/isdn/icn/icn.c
+++ b/drivers/isdn/icn/icn.c
@@ -1627,7 +1627,7 @@ __setup("icn=", icn_setup);
static int __init icn_init(void)
{
char *p;
- char rev[20];
+ char rev[21];
memset(&dev, 0, sizeof(icn_dev));
dev.memaddr = (membase & 0x0ffc000);
@@ -1638,6 +1638,7 @@ static int __init icn_init(void)
if ((p = strchr(revision, ':'))) {
strncpy(rev, p + 1, 20);
+ rev[20] = '\0';
p = strchr(rev, '$');
if (p)
*p = 0;
--
1.7.2.3
^ permalink raw reply related
* [PATCH kernel 2.6.38rc2-git7] axnet_cs: reduce delay time at ei_rx_overrun
From: Ken Kawasaki @ 2011-01-30 21:16 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110111205558.98fcab01.ken_kawasaki@spring.nifty.jp>
axnet_cs:
mdelay of 10ms is too long at ei_rx_overrun.
It should be reduced to 2ms.
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
---
--- linux-2.6.38-rc2-git7/drivers/net/pcmcia/axnet_cs.c.orig 2011-01-29 19:56:56.261560045 +0900
+++ linux-2.6.38-rc2-git7/drivers/net/pcmcia/axnet_cs.c 2011-01-30 11:00:12.500397574 +0900
@@ -1488,12 +1488,10 @@ static void ei_rx_overrun(struct net_dev
/*
* Wait a full Tx time (1.2ms) + some guard time, NS says 1.6ms total.
- * Early datasheets said to poll the reset bit, but now they say that
- * it "is not a reliable indicator and subsequently should be ignored."
- * We wait at least 10ms.
+ * We wait at least 2ms.
*/
- mdelay(10);
+ mdelay(2);
/*
* Reset RBCR[01] back to zero as per magic incantation.
^ permalink raw reply
* Oops with ipsec vpn on latest 2.6.38-rc2+ kernel
From: Roland Dreier @ 2011-01-30 22:55 UTC (permalink / raw)
To: netdev
With an up-to-date kernel (head is 1f0324caefd3), I'm seeing the following oops
when I try to send traffic (I think it's my first name server query)
through an ipsec VPN
(set up with the shrew client):
[ 307.861225] BUG: unable to handle kernel NULL pointer dereference
at (null)
[ 307.865272] IP: [< (null)>] (null)
[ 307.868654] PGD 0
[ 307.871146] Oops: 0010 [#1] SMP
[ 307.873642] last sysfs file:
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:0b/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/voltage_now
[ 307.876302] CPU 0
[ 307.876329] Modules linked in: hidp hid ip6table_filter deflate
zlib_deflate ip6_tables ctr twofish_generic twofish_x86_64
twofish_common camellia serpent blowfish cast5 des_generic aesni_intel
cryptd aes_x86_64 aes_generic xcbc rmd160 xt_CHECKSUM iptable_mangle
sha512_generic binfmt_misc ipt_MASQUERADE iptable_nat nf_nat
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack sha256_generic
ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge
sha1_generic stp crypto_null af_key joydev parport_pc dm_crypt ppdev
snd_hda_codec_hdmi rfcomm snd_hda_codec_conexant arc4 sco bnep
thinkpad_acpi l2cap iwlagn snd_hda_intel snd_hda_codec snd_hwdep
snd_pcm iwlcore uvcvideo snd_seq_midi snd_rawmidi mac80211
snd_seq_midi_event videodev v4l2_compat_ioctl32 btusb snd_seq
bluetooth cfg80211 snd_timer snd_seq_device psmouse serio_raw snd
snd_page_alloc intel_ips soundcore nvram tpm_tis tpm tpm_bios lp
parport i915 drm_kms_helper e1000e drm ahci libahci i2c_algo_bit video
[ 307.898289]
[ 307.901550] Pid: 3140, comm: ssh Not tainted 2.6.38-999-generic
#201101281114 2901CTO/2901CTO
[ 307.904894] RIP: 0010:[<0000000000000000>] [< (null)>]
(null)
[ 307.908301] RSP: 0018:ffff880231b13ad0 EFLAGS: 00010246
[ 307.911679] RAX: ffffffff81a643c0 RBX: 0000000000000000 RCX: ffff88023105b180
[ 307.915069] RDX: ffff88023105b180 RSI: ffffffff814e5a50 RDI: ffff88023105b180
[ 307.918484] RBP: ffff880231b13b88 R08: 0000000000000008 R09: ffff880231b13be8
[ 307.921901] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000008
[ 307.925304] R13: 0000000000000000 R14: ffff880231b13e58 R15: ffff88022fe223c0
[ 307.928756] FS: 00007fd52fccc7e0(0000) GS:ffff8800bb000000(0000)
knlGS:0000000000000000
[ 307.932232] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 307.935709] CR2: 0000000000000000 CR3: 0000000204452000 CR4: 00000000000006f0
[ 307.939253] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 307.942752] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 307.946109] Process ssh (pid: 3140, threadinfo ffff880231b12000,
task ffff88022dda5b00)
[ 307.949520] Stack:
[ 307.952869] ffffffff814e6347 ffff880231b13af8 0000000000000246
ffff88022fe224c8
[ 307.956302] ffff880231b13be8 0000003d31b13b18 ffff880231b13e98
ffffffff814e5a50
[ 307.959728] ffff88023105be00 ffff880231b13b48 ffffffff814defc3
ffff880231b13c08
[ 307.963144] Call Trace:
[ 307.966528] [<ffffffff814e6347>] ? ip_append_data+0x787/0xab0
[ 307.969967] [<ffffffff814e5a50>] ? ip_generic_getfrag+0x0/0xa0
[ 307.973414] [<ffffffff814defc3>] ? ipv4_dst_blackhole+0x1c3/0x210
[ 307.976864] [<ffffffff815a115e>] ? _raw_spin_lock_bh+0x1e/0x30
[ 307.980287] [<ffffffff8150bd09>] udp_sendmsg+0x389/0x790
[ 307.983732] [<ffffffff815143d9>] inet_sendmsg+0x69/0xc0
[ 307.987138] [<ffffffff8149cb3a>] sock_sendmsg+0x10a/0x120
[ 307.990552] [<ffffffff8107e663>] ? queue_delayed_work_on+0xb3/0x110
[ 307.994033] [<ffffffff815a1099>] ? _raw_spin_unlock_bh+0x19/0x20
[ 307.997455] [<ffffffff814b8260>] ? __dst_free+0x50/0xa0
[ 308.000868] [<ffffffff815a1099>] ? _raw_spin_unlock_bh+0x19/0x20
[ 308.004274] [<ffffffff8150adcb>] ? udp_lib_rehash+0x11b/0x140
[ 308.007675] [<ffffffff8150b2ef>] ? udp_v4_rehash+0x2f/0x40
[ 308.011108] [<ffffffff8149adaa>] ? sockfd_lookup_light+0x4a/0x80
[ 308.014548] [<ffffffff8149d75a>] sys_sendto+0x13a/0x190
[ 308.017982] [<ffffffff815a0e0e>] ? _raw_spin_lock+0xe/0x20
[ 308.021395] [<ffffffff81156c30>] ? fd_install+0x60/0x70
[ 308.024770] [<ffffffff8100c002>] system_call_fastpath+0x16/0x1b
[ 308.028141] Code: Bad RIP value.
[ 308.031547] RIP [< (null)>] (null)
[ 308.034952] RSP <ffff880231b13ad0>
[ 308.038330] CR2: 0000000000000000
[ 308.041823] ---[ end trace 12c863de1da69f98 ]---
This wasn't happening with Ubuntu's 2.6.37 kernels. I haven't gotten too far
with debugging this yet, but any ideas of things to look at would be
appreciated.
Thanks,
Roland
^ permalink raw reply
* RE: Realtek r8168C / r8169 driver VLAN TAG stripping
From: hayeswang @ 2011-01-31 5:45 UTC (permalink / raw)
To: 'Francois Romieu', 'Anand Raj Manickam'
Cc: netdev, 'Ivan Vecera'
In-Reply-To: <20110128120624.GA8100@electric-eye.fr.zoreil.com>
> Reading my rev1.0 8168c datasheet from may 2007, when there
> is no tx offload, no checksumming, the tx descriptor layout
> should be the same as the perennial 8169 tx descriptor layout.
>
> Either (1) the VLAN registers and descriptor layout is
> different for this chipset or (2) something prevents the
> register / descriptor write (read ?) to be completely
> effective or (3) there is something beyond the 8168 or
> (4) there is a 8168 hardware bug.
>
> 1 : Hayes may answer. You can give Realtek's own driver a try btw.
> 2 : Seen before. It could be a software or a (non-8168) hardware one.
> I have no idea if your hardware setup includes a single card with
> four ports or four independent cards with their own 8168 or worse.
> 3 : See the hardware setup part of (2).
> 4 : I don't hope so. Hayes may answer as well.
>
I find nothing wrong for the source code of kernel. I think it should work. Only
the tx descriptor need to be set for the tx. For the receiving, the register
0xe0 (CPlusCmd) bit 6 (RxVlan) should be set. That is all. And I don't get any
information about hardware bug, so I really don't know what's wrong. I will
check it after the vacation of Chinese New Year.
Best Regards,
Hayes
^ permalink raw reply
* Re: pull request: batman-adv 2011-01-30
From: David Miller @ 2011-01-31 6:19 UTC (permalink / raw)
To: sven; +Cc: netdev
In-Reply-To: <1296389504-11208-1-git-send-email-sven@narfation.org>
From: Sven Eckelmann <sven@narfation.org>
Date: Sun, 30 Jan 2011 13:11:40 +0100
> Hi,
>
> I would like to propose following patches for net-2.6.git/2.6.38. These are
> important fixes for kernel oopses/memory leaks. I already send this exact same
> request in 201101301036.57928.sven@narfation.org were you requested a new patch
> series posting.
>
> I cannot reduce the number of fixes any more because it makes no sense to fix
> one Oops and leave the other one open. I've already removed the fixes for the
> protocol implementation errors from the first patchset.
>
> The following changes since commit aa0adb1a85e159cf57f0e11282bc6c9e3606a5f3:
>
> batman-adv: Use "__attribute__" shortcut macros (2011-01-16 03:25:19 +0100)
>
> are available in the git repository at:
> git://git.open-mesh.org/ecsv/linux-merge.git batman-adv/merge-oopsonly
Pulled, thanks a lot.
^ permalink raw reply
* Re: [PATCH net-2.6 0/5] bnx2x: Minor link related fixes
From: David Miller @ 2011-01-31 6:26 UTC (permalink / raw)
To: yanivr; +Cc: netdev, eilong
In-Reply-To: <1296396874.10095.49.camel@lb-tlvb-dmitry>
From: "Yaniv Rosner" <yanivr@broadcom.com>
Date: Sun, 30 Jan 2011 16:14:34 +0200
> The following patch series describe some link fixes in bnx2x driver
> Please consider applying it to net-2.6.
All applied, thanks.
^ permalink raw reply
* Re: Oops with ipsec vpn on latest 2.6.38-rc2+ kernel
From: Roland Dreier @ 2011-01-31 8:42 UTC (permalink / raw)
To: netdev
In-Reply-To: <AANLkTi=OTfax3CFzD9xBHbjV0RRB7aNEpHD0p9nm1cOB@mail.gmail.com>
> With an up-to-date kernel (head is 1f0324caefd3), I'm seeing the following oops
> when I try to send traffic (I think it's my first name server query)
> through an ipsec VPN (set up with the shrew client
So I bisected this down to d33e455337ea ("net: Abstract default MTU metric
calculation behind an accessor.") and indeed I verified that the call to
dst_mtu() in ip_append_data() is calling a NULL dst->ops->default_mtu
Haven't debugged which dst this is or why it's missing that method yet...
- R.
^ permalink raw reply
* Re: [PATCH V10 00/15] ptp: IEEE 1588 hardware clock support
From: Thomas Gleixner @ 2011-01-31 9:29 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
John Stultz, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Benjamin Herrenschmidt, H. Peter Anvin, Ingo Molnar,
Mike Frysinger, Paul Mackerras, Russell King
In-Reply-To: <cover.1296124770.git.richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
On Thu, 27 Jan 2011, Richard Cochran wrote:
> Here is version 10 of the PHC patch series. We missed the boat for
> 2.6.38, but I hope this can be merged for the next one.
>
> Reviewers: I think its done. How can I get this merged?
Looks pretty good. I go through the patches again and I'd like to have
a ack/reviewed by from John. The whole thing can go through
tip/timers.
> Arch maintainers (arm, blackfin, powerpc, x86): I have added you on
> CC in the hope of getting your acks for the new syscall.
I'll take the x86 one right away. For the other archs we can apply
those patches via the arch trees even during the merge window.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: add second list for IRDA
From: Samuel Ortiz @ 2011-01-31 10:46 UTC (permalink / raw)
To: Wolfram Sang; +Cc: netdev, David Miller
In-Reply-To: <20110124193424.GA6759@pengutronix.de>
On Mon, Jan 24, 2011 at 08:34:24PM +0100, Wolfram Sang wrote:
> On Fri, Nov 26, 2010 at 01:09:21PM +0100, Samuel Ortiz wrote:
>
> > Hi Wolfgang,
>
> Wolfram, please ;)
Sorry about that...
> > On Tue, Nov 23, 2010 at 07:10:13PM +0100, Wolfram Sang wrote:
> > > The irda-users-list is currently almost dead and subscribers-only. Adding
> > > netdev increases the audience which might help to not overlook a bugreport
> > > (again).
> > Makes sense. I'll carry this patch, thanks.
>
> Ping. I could also send this to trivial@ with your ack if that makes it easier?
>
That's probably going to be faster. So yes, please add my:
Acked-by: Samuel Ortiz <samuel@sortiz.org>
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: IAMT broken by commit 82776a4bcd7aa5fbcd2e6339b3ce88b727dd40ab
From: Aurelien Jarno @ 2011-01-31 11:45 UTC (permalink / raw)
To: Allan, Bruce W; +Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A900118D29D0A@orsmsx509.amr.corp.intel.com>
Hi,
On Tue, Jun 01, 2010 at 04:33:27PM -0700, Allan, Bruce W wrote:
> I will look into this in the next couple days.
>
> -----Original Message-----
> From: Aurelien Jarno [mailto:aurelien@aurel32.net]
> Sent: Saturday, May 29, 2010 6:02 PM
> To: Allan, Bruce W; Kirsher, Jeffrey T
> Cc: netdev@vger.kernel.org
> Subject: IAMT broken by commit 82776a4bcd7aa5fbcd2e6339b3ce88b727dd40ab
>
> Hi,
>
> I have recently upgrade my kernel, and found that Intel AMT support is
> not working anymore as expected. I have configured IAMT so that is
> always available, even when the machine is off ("Desktop: ON in S0, S3,
> S4-5").
>
> On recent kernels, IAMT support does not work after the machine has
> been powered-off. Even worse, it also goes into this state when I try
> to reboot it.
>
> I have done a bisect and got this commit:
>
> | commit 82776a4bcd7aa5fbcd2e6339b3ce88b727dd40ab
> | Author: Bruce Allan <bruce.w.allan@intel.com>
> | Date: Fri Aug 14 14:35:33 2009 +0000
> |
> | e1000e: WoL does not work on 82577/82578 with manageability enabled
> |
> | With manageability (Intel AMT) enabled via BIOS, PHY wakeup does not get
> | configured on newer parts which use PHY wakeup vs. MAC wakeup which causes
> | WoL to not work. The driver should configure PHY wakeup whether or not
> | manageability is enabled.
> |
> | Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> | Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> | Signed-off-by: David S. Miller <davem@davemloft.net>
>
> I have tried to revert it on recent kernels (2.6.34), and IAMT is then
> working as expected. My machine is using a Gigabyte EQ45M-S2 motherboard
> with an 82567LM-3 ethernet chip (8086:10de), that is a different model
> than the one of the original problem.
>
> I do wonder if the changes in the patch should not only be done on some
> chip models, and I will appreciate any help in fixing this issue.
>
Just a short mail to say this problem is still present in 2.6.38-rc2.
The same solution still applies, that is reverting the above commit.
Note that reverting the first hunk only is enough to get it working
again.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply
* x25: possible skb leak on bad facilities
From: Andy Whitcroft @ 2011-01-31 13:08 UTC (permalink / raw)
To: Andrew Hendry, David S. Miller
Cc: John Hughes, linux-x25, netdev, linux-kernel, Tim Gardner
Looking at the changes introduced in the commit below, we seem to
introduce an skb leak when a packet with bad facilities are present:
commit a6331d6f9a4298173b413cf99a40cc86a9d92c37
Author: andrew hendry <andrew.hendry@gmail.com>
Date: Wed Nov 3 12:54:53 2010 +0000
memory corruption in X.25 facilities parsing
If I am understanding things correctly then we trigger a -1 return to
the main packet dispatch loop, this being non-zero implies that we have
requeued the skb and it should not be freed. As it was not requeued,
I believe the skb is no longer referenced and then is leaked.
Perhaps someone better aquainted with this code could review my analysis
in the patch leader below. If accurate I believe we need the patch below
to resolve this. If it is not then I suspect a comment is required on
the -1 return.
Thoughts?
-apw
>From 5728c05fb669e8ee1e6d20fb7a71916362039411 Mon Sep 17 00:00:00 2001
From: Andy Whitcroft <apw@canonical.com>
Date: Mon, 31 Jan 2011 10:37:36 +0000
Subject: [PATCH] x25: drop packet on invalid facility headers
The commit below introduced additional checks for invalid facilities,
and a new return path when these were detected:
commit a6331d6f9a4298173b413cf99a40cc86a9d92c37
Author: andrew hendry <andrew.hendry@gmail.com>
Date: Wed Nov 3 12:54:53 2010 +0000
memory corruption in X.25 facilities parsing
This new return path short circuits packet handling, the new return -1
below:
static int x25_state1_machine(struct sock *sk, struct sk_buff *skb,
int frametype)
{
[...]
len = x25_parse_facilities(skb, &x25->facilities,
&x25->dte_facilities,
&x25->vc_facil_mask);
if (len > 0)
skb_pull(skb, len);
else
return -1;
[...]
This return code is passed back up the chain (via x25_process_rx_frame)
and is interpreted as below by the caller:
int x25_backlog_rcv(struct sock *sk, struct sk_buff *skb)
{
int queued = x25_process_rx_frame(sk, skb);
if (!queued)
kfree_skb(skb);
return 0;
}
Here we interpret the non-zero status as indicating the skb has been
requeued and should be preserved. As we have not actually done so it
will be leaked.
Fix this up by indicating that the packet should be dropped.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
---
net/x25/x25_in.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/x25/x25_in.c b/net/x25/x25_in.c
index f729f02..213b93a 100644
--- a/net/x25/x25_in.c
+++ b/net/x25/x25_in.c
@@ -120,7 +120,7 @@ static int x25_state1_machine(struct sock *sk, struct sk_buff *skb, int frametyp
if (len > 0)
skb_pull(skb, len);
else
- return -1;
+ return 0;
/*
* Copy any Call User Data.
*/
--
1.7.1
^ 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