* [PATCH 1/4] batman-adv: Fix kernel panic when fetching vis data on a vis server
From: Sven Eckelmann @ 2011-01-30 12:11 UTC (permalink / raw)
To: davem; +Cc: netdev, Linus Lüssing, Sven Eckelmann
In-Reply-To: <1296389504-11208-1-git-send-email-sven@narfation.org>
From: Linus Lüssing <linus.luessing@web.de>
The hash_iterate removal introduced a bug leading to a kernel panic when
fetching the vis data on a vis server. That commit forgot to rename one
variable name, which this commit fixes now.
Reported-by: Russell Senior <russell@personaltelco.net>
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
net/batman-adv/vis.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/batman-adv/vis.c b/net/batman-adv/vis.c
index cd4c423..f69a374 100644
--- a/net/batman-adv/vis.c
+++ b/net/batman-adv/vis.c
@@ -268,10 +268,10 @@ int vis_seq_print_text(struct seq_file *seq, void *offset)
buff_pos += sprintf(buff + buff_pos, "%pM,",
entry->addr);
- for (i = 0; i < packet->entries; i++)
+ for (j = 0; j < packet->entries; j++)
buff_pos += vis_data_read_entry(
buff + buff_pos,
- &entries[i],
+ &entries[j],
entry->addr,
entry->primary);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/4] batman-adv: Remove vis info on hashing errors
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>
A newly created vis info object must be removed when it couldn't be
added to the hash. The old_info which has to be replaced was already
removed and isn't related to the hash anymore.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
net/batman-adv/vis.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/batman-adv/vis.c b/net/batman-adv/vis.c
index f69a374..0be55be 100644
--- a/net/batman-adv/vis.c
+++ b/net/batman-adv/vis.c
@@ -444,7 +444,7 @@ static struct vis_info *add_packet(struct bat_priv *bat_priv,
info);
if (hash_added < 0) {
/* did not work (for some reason) */
- kref_put(&old_info->refcount, free_info);
+ kref_put(&info->refcount, free_info);
info = NULL;
}
--
1.7.2.3
^ permalink raw reply related
* [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
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