* [PATCH 6/9] pcmcia: convert net pcmcia drivers to use new CIS helpers
From: Dominik Brodowski @ 2009-10-18 23:07 UTC (permalink / raw)
To: linux-pcmcia; +Cc: Dominik Brodowski, David S. Miller, netdev
In-Reply-To: <1255907255-28297-5-git-send-email-linux@dominikbrodowski.net>
Use the new CIS helpers in net pcmcia drivers, which allows for
a few code cleanups.
CC: David S. Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
---
drivers/net/pcmcia/3c574_cs.c | 18 ++--
drivers/net/pcmcia/3c589_cs.c | 24 ++---
drivers/net/pcmcia/fmvj18x_cs.c | 51 ++++-----
drivers/net/pcmcia/nmclan_cs.c | 19 ++--
drivers/net/pcmcia/smc91c92_cs.c | 238 +++++++++++---------------------------
drivers/net/pcmcia/xirc2ps_cs.c | 101 ++++++----------
6 files changed, 154 insertions(+), 297 deletions(-)
diff --git a/drivers/net/pcmcia/3c574_cs.c b/drivers/net/pcmcia/3c574_cs.c
index b58965a..6449290 100644
--- a/drivers/net/pcmcia/3c574_cs.c
+++ b/drivers/net/pcmcia/3c574_cs.c
@@ -344,13 +344,13 @@ static int tc574_config(struct pcmcia_device *link)
{
struct net_device *dev = link->priv;
struct el3_private *lp = netdev_priv(dev);
- tuple_t tuple;
- __le16 buf[32];
int last_fn, last_ret, i, j;
unsigned int ioaddr;
__be16 *phys_addr;
char *cardname;
__u32 config;
+ u8 *buf;
+ size_t len;
phys_addr = (__be16 *)dev->dev_addr;
@@ -378,16 +378,14 @@ static int tc574_config(struct pcmcia_device *link)
/* The 3c574 normally uses an EEPROM for configuration info, including
the hardware address. The future products may include a modem chip
and put the address in the CIS. */
- tuple.Attributes = 0;
- tuple.TupleData = (cisdata_t *)buf;
- tuple.TupleDataMax = 64;
- tuple.TupleOffset = 0;
- tuple.DesiredTuple = 0x88;
- if (pcmcia_get_first_tuple(link, &tuple) == 0) {
- pcmcia_get_tuple_data(link, &tuple);
+
+ len = pcmcia_get_tuple(link, 0x88, &buf);
+ if (buf && len >= 6) {
for (i = 0; i < 3; i++)
- phys_addr[i] = htons(le16_to_cpu(buf[i]));
+ phys_addr[i] = htons(le16_to_cpu(buf[i * 2]));
+ kfree(buf);
} else {
+ kfree(buf); /* 0 < len < 6 */
EL3WINDOW(0);
for (i = 0; i < 3; i++)
phys_addr[i] = htons(read_eeprom(ioaddr, i + 10));
diff --git a/drivers/net/pcmcia/3c589_cs.c b/drivers/net/pcmcia/3c589_cs.c
index 569fb06..ea04356 100644
--- a/drivers/net/pcmcia/3c589_cs.c
+++ b/drivers/net/pcmcia/3c589_cs.c
@@ -256,22 +256,15 @@ static int tc589_config(struct pcmcia_device *link)
{
struct net_device *dev = link->priv;
struct el3_private *lp = netdev_priv(dev);
- tuple_t tuple;
- __le16 buf[32];
- __be16 *phys_addr;
+ __be16 *phys_addr = NULL;
int last_fn, last_ret, i, j, multi = 0, fifo;
unsigned int ioaddr;
char *ram_split[] = {"5:3", "3:1", "1:1", "3:5"};
+ u8 *buf;
+ size_t len;
DEBUG(0, "3c589_config(0x%p)\n", link);
- phys_addr = (__be16 *)dev->dev_addr;
- tuple.Attributes = 0;
- tuple.TupleData = (cisdata_t *)buf;
- tuple.TupleDataMax = sizeof(buf);
- tuple.TupleOffset = 0;
- tuple.Attributes = TUPLE_RETURN_COMMON;
-
/* Is this a 3c562? */
if (link->manf_id != MANFID_3COM)
printk(KERN_INFO "3c589_cs: hmmm, is this really a "
@@ -301,12 +294,13 @@ static int tc589_config(struct pcmcia_device *link)
/* The 3c589 has an extra EEPROM for configuration info, including
the hardware address. The 3c562 puts the address in the CIS. */
- tuple.DesiredTuple = 0x88;
- if (pcmcia_get_first_tuple(link, &tuple) == 0) {
- pcmcia_get_tuple_data(link, &tuple);
- for (i = 0; i < 3; i++)
- phys_addr[i] = htons(le16_to_cpu(buf[i]));
+ len = pcmcia_get_tuple(link, 0x88, &buf);
+ if (buf && len >= 6) {
+ for (i = 0; i < 3; i++)
+ phys_addr[i] = htons(le16_to_cpu(buf[i*2]));
+ kfree(buf);
} else {
+ kfree(buf); /* 0 < len < 6 */
for (i = 0; i < 3; i++)
phys_addr[i] = htons(read_eeprom(ioaddr, i));
if (phys_addr[0] == htons(0x6060)) {
diff --git a/drivers/net/pcmcia/fmvj18x_cs.c b/drivers/net/pcmcia/fmvj18x_cs.c
index c7a2bbf..58954a6 100644
--- a/drivers/net/pcmcia/fmvj18x_cs.c
+++ b/drivers/net/pcmcia/fmvj18x_cs.c
@@ -350,32 +350,30 @@ static int fmvj18x_ioprobe(struct pcmcia_device *p_dev,
return 0; /* strange, but that's what the code did already before... */
}
-
static int fmvj18x_config(struct pcmcia_device *link)
{
struct net_device *dev = link->priv;
local_info_t *lp = netdev_priv(dev);
- tuple_t tuple;
- u_short buf[32];
int i, last_fn = RequestIO, last_ret = 0, ret;
unsigned int ioaddr;
cardtype_t cardtype;
char *card_name = "unknown";
- u_char *node_id;
+ u8 *buf;
+ size_t len;
+ u_char buggybuf[32];
DEBUG(0, "fmvj18x_config(0x%p)\n", link);
- tuple.TupleData = (u_char *)buf;
- tuple.TupleDataMax = 64;
- tuple.TupleOffset = 0;
- tuple.DesiredTuple = CISTPL_FUNCE;
- tuple.TupleOffset = 0;
- if (pcmcia_get_first_tuple(link, &tuple) == 0) {
+ len = pcmcia_get_tuple(link, CISTPL_FUNCE, &buf);
+ if (buf)
+ kfree(buf);
+
+ if (len) {
+ /* Yes, I have CISTPL_FUNCE. Let's check CISTPL_MANFID */
last_ret = pcmcia_loop_config(link, fmvj18x_ioprobe, NULL);
if (last_ret != 0)
goto cs_failed;
- /* Yes, I have CISTPL_FUNCE. Let's check CISTPL_MANFID */
switch (link->manf_id) {
case MANFID_TDK:
cardtype = TDK;
@@ -482,21 +480,21 @@ static int fmvj18x_config(struct pcmcia_device *link)
case CONTEC:
case NEC:
case KME:
- tuple.DesiredTuple = CISTPL_FUNCE;
- tuple.TupleOffset = 0;
- CS_CHECK(GetFirstTuple, pcmcia_get_first_tuple(link, &tuple));
- tuple.TupleOffset = 0;
- CS_CHECK(GetTupleData, pcmcia_get_tuple_data(link, &tuple));
if (cardtype == MBH10304) {
- /* MBH10304's CIS_FUNCE is corrupted */
- node_id = &(tuple.TupleData[5]);
card_name = "FMV-J182";
- } else {
- while (tuple.TupleData[0] != CISTPL_FUNCE_LAN_NODE_ID ) {
- CS_CHECK(GetNextTuple, pcmcia_get_next_tuple(link, &tuple));
- CS_CHECK(GetTupleData, pcmcia_get_tuple_data(link, &tuple));
+
+ len = pcmcia_get_tuple(link, CISTPL_FUNCE, &buf);
+ if (len < 11) {
+ kfree(buf);
+ goto failed;
}
- node_id = &(tuple.TupleData[2]);
+ /* Read MACID from CIS */
+ for (i = 5; i < 11; i++)
+ dev->dev_addr[i] = buf[i];
+ kfree(buf);
+ } else {
+ if (pcmcia_get_mac_from_cis(link, dev))
+ goto failed;
if( cardtype == TDK ) {
card_name = "TDK LAK-CD021";
} else if( cardtype == LA501 ) {
@@ -509,9 +507,6 @@ static int fmvj18x_config(struct pcmcia_device *link)
card_name = "C-NET(PC)C";
}
}
- /* Read MACID from CIS */
- for (i = 0; i < 6; i++)
- dev->dev_addr[i] = node_id[i];
break;
case UNGERMANN:
/* Read MACID from register */
@@ -521,12 +516,12 @@ static int fmvj18x_config(struct pcmcia_device *link)
break;
case XXX10304:
/* Read MACID from Buggy CIS */
- if (fmvj18x_get_hwinfo(link, tuple.TupleData) == -1) {
+ if (fmvj18x_get_hwinfo(link, buggybuf) == -1) {
printk(KERN_NOTICE "fmvj18x_cs: unable to read hardware net address.\n");
goto failed;
}
for (i = 0 ; i < 6; i++) {
- dev->dev_addr[i] = tuple.TupleData[i];
+ dev->dev_addr[i] = buggybuf[i];
}
card_name = "FMV-J182";
break;
diff --git a/drivers/net/pcmcia/nmclan_cs.c b/drivers/net/pcmcia/nmclan_cs.c
index 5ed6339..4b96b35 100644
--- a/drivers/net/pcmcia/nmclan_cs.c
+++ b/drivers/net/pcmcia/nmclan_cs.c
@@ -661,8 +661,8 @@ static int nmclan_config(struct pcmcia_device *link)
{
struct net_device *dev = link->priv;
mace_private *lp = netdev_priv(dev);
- tuple_t tuple;
- u_char buf[64];
+ u8 *buf;
+ size_t len;
int i, last_ret, last_fn;
unsigned int ioaddr;
@@ -677,14 +677,13 @@ static int nmclan_config(struct pcmcia_device *link)
ioaddr = dev->base_addr;
/* Read the ethernet address from the CIS. */
- tuple.DesiredTuple = 0x80 /* CISTPL_CFTABLE_ENTRY_MISC */;
- tuple.TupleData = buf;
- tuple.TupleDataMax = 64;
- tuple.TupleOffset = 0;
- tuple.Attributes = 0;
- CS_CHECK(GetFirstTuple, pcmcia_get_first_tuple(link, &tuple));
- CS_CHECK(GetTupleData, pcmcia_get_tuple_data(link, &tuple));
- memcpy(dev->dev_addr, tuple.TupleData, ETHER_ADDR_LEN);
+ len = pcmcia_get_tuple(link, 0x80, &buf);
+ if (!buf || len < ETHER_ADDR_LEN) {
+ kfree(buf);
+ goto failed;
+ }
+ memcpy(dev->dev_addr, buf, ETHER_ADDR_LEN);
+ kfree(buf);
/* Verify configuration by reading the MACE ID. */
{
diff --git a/drivers/net/pcmcia/smc91c92_cs.c b/drivers/net/pcmcia/smc91c92_cs.c
index af03759..df92bcd 100644
--- a/drivers/net/pcmcia/smc91c92_cs.c
+++ b/drivers/net/pcmcia/smc91c92_cs.c
@@ -126,12 +126,6 @@ struct smc_private {
int rx_ovrn;
};
-struct smc_cfg_mem {
- tuple_t tuple;
- cisparse_t parse;
- u_char buf[255];
-};
-
/* Special definitions for Megahertz multifunction cards */
#define MEGAHERTZ_ISR 0x0380
@@ -408,34 +402,7 @@ static int cvt_ascii_address(struct net_device *dev, char *s)
return 0;
}
-/*====================================================================*/
-
-static int first_tuple(struct pcmcia_device *handle, tuple_t *tuple,
- cisparse_t *parse)
-{
- int i;
-
- i = pcmcia_get_first_tuple(handle, tuple);
- if (i != 0)
- return i;
- i = pcmcia_get_tuple_data(handle, tuple);
- if (i != 0)
- return i;
- return pcmcia_parse_tuple(tuple, parse);
-}
-
-static int next_tuple(struct pcmcia_device *handle, tuple_t *tuple,
- cisparse_t *parse)
-{
- int i;
-
- if ((i = pcmcia_get_next_tuple(handle, tuple)) != 0 ||
- (i = pcmcia_get_tuple_data(handle, tuple)) != 0)
- return i;
- return pcmcia_parse_tuple(tuple, parse);
-}
-
-/*======================================================================
+/*====================================================================
Configuration stuff for Megahertz cards
@@ -490,15 +457,10 @@ static int mhz_mfc_config(struct pcmcia_device *link)
{
struct net_device *dev = link->priv;
struct smc_private *smc = netdev_priv(dev);
- struct smc_cfg_mem *cfg_mem;
win_req_t req;
memreq_t mem;
int i;
- cfg_mem = kmalloc(sizeof(struct smc_cfg_mem), GFP_KERNEL);
- if (!cfg_mem)
- return -ENOMEM;
-
link->conf.Attributes |= CONF_ENABLE_SPKR;
link->conf.Status = CCSR_AUDIO_ENA;
link->irq.Attributes =
@@ -510,7 +472,8 @@ static int mhz_mfc_config(struct pcmcia_device *link)
/* The Megahertz combo cards have modem-like CIS entries, so
we have to explicitly try a bunch of port combinations. */
if (pcmcia_loop_config(link, mhz_mfc_config_check, NULL))
- goto free_cfg_mem;
+ return -ENODEV;
+
dev->base_addr = link->io.BasePort1;
/* Allocate a memory window, for accessing the ISR */
@@ -519,7 +482,8 @@ static int mhz_mfc_config(struct pcmcia_device *link)
req.AccessSpeed = 0;
i = pcmcia_request_window(&link, &req, &link->win);
if (i != 0)
- goto free_cfg_mem;
+ return -ENODEV;
+
smc->base = ioremap(req.Base, req.Size);
mem.CardOffset = mem.Page = 0;
if (smc->manfid == MANFID_MOTOROLA)
@@ -531,18 +495,32 @@ static int mhz_mfc_config(struct pcmcia_device *link)
&& (smc->cardid == PRODID_MEGAHERTZ_EM3288))
mhz_3288_power(link);
-free_cfg_mem:
- kfree(cfg_mem);
- return -ENODEV;
+ return 0;
}
+static int pcmcia_get_versmac(struct pcmcia_device *p_dev,
+ tuple_t *tuple,
+ void *priv)
+{
+ struct net_device *dev = priv;
+ cisparse_t parse;
+
+ if (pcmcia_parse_tuple(tuple, &parse))
+ return -EINVAL;
+
+ if ((parse.version_1.ns > 3) &&
+ (cvt_ascii_address(dev,
+ (parse.version_1.str + parse.version_1.ofs[3]))))
+ return 0;
+
+ return -EINVAL;
+};
+
static int mhz_setup(struct pcmcia_device *link)
{
struct net_device *dev = link->priv;
- struct smc_cfg_mem *cfg_mem;
- tuple_t *tuple;
- cisparse_t *parse;
- u_char *buf, *station_addr;
+ size_t len;
+ u8 *buf;
int rc;
/* Read the station address from the CIS. It is stored as the last
@@ -552,56 +530,22 @@ static int mhz_setup(struct pcmcia_device *link)
return 0;
/* Workarounds for broken cards start here. */
-
- cfg_mem = kmalloc(sizeof(struct smc_cfg_mem), GFP_KERNEL);
- if (!cfg_mem)
- return -1;
-
- tuple = &cfg_mem->tuple;
- parse = &cfg_mem->parse;
- buf = cfg_mem->buf;
-
- tuple->Attributes = tuple->TupleOffset = 0;
- tuple->TupleData = (cisdata_t *)buf;
- tuple->TupleDataMax = 255;
-
/* Ugh -- the EM1144 card has two VERS_1 tuples!?! */
- tuple->DesiredTuple = CISTPL_VERS_1;
- if (first_tuple(link, tuple, parse) != 0) {
- rc = -1;
- goto free_cfg_mem;
- }
- /* Ugh -- the EM1144 card has two VERS_1 tuples!?! */
- if (next_tuple(link, tuple, parse) != 0)
- first_tuple(link, tuple, parse);
- if (parse->version_1.ns > 3) {
- station_addr = parse->version_1.str + parse->version_1.ofs[3];
- if (cvt_ascii_address(dev, station_addr) == 0) {
- rc = 0;
- goto free_cfg_mem;
- }
- }
+ if (!pcmcia_loop_tuple(link, CISTPL_VERS_1, pcmcia_get_versmac, dev))
+ return 0;
/* Another possibility: for the EM3288, in a special tuple */
- tuple->DesiredTuple = 0x81;
- if (pcmcia_get_first_tuple(link, tuple) != 0) {
- rc = -1;
- goto free_cfg_mem;
- }
- if (pcmcia_get_tuple_data(link, tuple) != 0) {
- rc = -1;
- goto free_cfg_mem;
- }
- buf[12] = '\0';
- if (cvt_ascii_address(dev, buf) == 0) {
- rc = 0;
- goto free_cfg_mem;
- }
rc = -1;
-free_cfg_mem:
- kfree(cfg_mem);
- return rc;
-}
+ len = pcmcia_get_tuple(link, 0x81, &buf);
+ if (buf && len >= 13) {
+ buf[12] = '\0';
+ if (cvt_ascii_address(dev, buf))
+ rc = 0;
+ }
+ kfree(buf);
+
+ return rc;
+};
/*======================================================================
@@ -691,58 +635,21 @@ static int smc_config(struct pcmcia_device *link)
return i;
}
+
static int smc_setup(struct pcmcia_device *link)
{
struct net_device *dev = link->priv;
- struct smc_cfg_mem *cfg_mem;
- tuple_t *tuple;
- cisparse_t *parse;
- cistpl_lan_node_id_t *node_id;
- u_char *buf, *station_addr;
- int i, rc;
-
- cfg_mem = kmalloc(sizeof(struct smc_cfg_mem), GFP_KERNEL);
- if (!cfg_mem)
- return -ENOMEM;
-
- tuple = &cfg_mem->tuple;
- parse = &cfg_mem->parse;
- buf = cfg_mem->buf;
-
- tuple->Attributes = tuple->TupleOffset = 0;
- tuple->TupleData = (cisdata_t *)buf;
- tuple->TupleDataMax = 255;
/* Check for a LAN function extension tuple */
- tuple->DesiredTuple = CISTPL_FUNCE;
- i = first_tuple(link, tuple, parse);
- while (i == 0) {
- if (parse->funce.type == CISTPL_FUNCE_LAN_NODE_ID)
- break;
- i = next_tuple(link, tuple, parse);
- }
- if (i == 0) {
- node_id = (cistpl_lan_node_id_t *)parse->funce.data;
- if (node_id->nb == 6) {
- for (i = 0; i < 6; i++)
- dev->dev_addr[i] = node_id->id[i];
- rc = 0;
- goto free_cfg_mem;
- }
- }
+ if (!pcmcia_get_mac_from_cis(link, dev))
+ return 0;
+
/* Try the third string in the Version 1 Version/ID tuple. */
if (link->prod_id[2]) {
- station_addr = link->prod_id[2];
- if (cvt_ascii_address(dev, station_addr) == 0) {
- rc = 0;
- goto free_cfg_mem;
- }
+ if (cvt_ascii_address(dev, link->prod_id[2]) == 0)
+ return 0;
}
-
- rc = -1;
-free_cfg_mem:
- kfree(cfg_mem);
- return rc;
+ return -1;
}
/*====================================================================*/
@@ -801,41 +708,31 @@ static int osi_load_firmware(struct pcmcia_device *link)
return err;
}
-static int osi_setup(struct pcmcia_device *link, u_short manfid, u_short cardid)
+static int pcmcia_osi_mac(struct pcmcia_device *p_dev,
+ tuple_t *tuple,
+ void *priv)
{
- struct net_device *dev = link->priv;
- struct smc_cfg_mem *cfg_mem;
- tuple_t *tuple;
- u_char *buf;
- int i, rc;
+ struct net_device *dev = priv;
+ int i;
- cfg_mem = kmalloc(sizeof(struct smc_cfg_mem), GFP_KERNEL);
- if (!cfg_mem)
- return -1;
+ if (tuple->TupleDataLen < 8)
+ return -EINVAL;
+ if (tuple->TupleData[0] != 0x04)
+ return -EINVAL;
+ for (i = 0; i < 6; i++)
+ dev->dev_addr[i] = tuple->TupleData[i+2];
+ return 0;
+};
- tuple = &cfg_mem->tuple;
- buf = cfg_mem->buf;
- tuple->Attributes = TUPLE_RETURN_COMMON;
- tuple->TupleData = (cisdata_t *)buf;
- tuple->TupleDataMax = 255;
- tuple->TupleOffset = 0;
+static int osi_setup(struct pcmcia_device *link, u_short manfid, u_short cardid)
+{
+ struct net_device *dev = link->priv;
+ int rc;
/* Read the station address from tuple 0x90, subtuple 0x04 */
- tuple->DesiredTuple = 0x90;
- i = pcmcia_get_first_tuple(link, tuple);
- while (i == 0) {
- i = pcmcia_get_tuple_data(link, tuple);
- if ((i != 0) || (buf[0] == 0x04))
- break;
- i = pcmcia_get_next_tuple(link, tuple);
- }
- if (i != 0) {
- rc = -1;
- goto free_cfg_mem;
- }
- for (i = 0; i < 6; i++)
- dev->dev_addr[i] = buf[i+2];
+ if (pcmcia_loop_tuple(link, 0x90, pcmcia_osi_mac, dev))
+ return -1;
if (((manfid == MANFID_OSITECH) &&
(cardid == PRODID_OSITECH_SEVEN)) ||
@@ -843,7 +740,7 @@ static int osi_setup(struct pcmcia_device *link, u_short manfid, u_short cardid)
(cardid == PRODID_PSION_NET100))) {
rc = osi_load_firmware(link);
if (rc)
- goto free_cfg_mem;
+ return rc;
} else if (manfid == MANFID_OSITECH) {
/* Make sure both functions are powered up */
set_bits(0x300, link->io.BasePort1 + OSITECH_AUI_PWR);
@@ -853,10 +750,7 @@ static int osi_setup(struct pcmcia_device *link, u_short manfid, u_short cardid)
inw(link->io.BasePort1 + OSITECH_AUI_PWR),
inw(link->io.BasePort1 + OSITECH_RESET_ISR));
}
- rc = 0;
-free_cfg_mem:
- kfree(cfg_mem);
- return rc;
+ return 0;
}
static int smc91c92_suspend(struct pcmcia_device *link)
diff --git a/drivers/net/pcmcia/xirc2ps_cs.c b/drivers/net/pcmcia/xirc2ps_cs.c
index 3dd6ba6..8ed8449 100644
--- a/drivers/net/pcmcia/xirc2ps_cs.c
+++ b/drivers/net/pcmcia/xirc2ps_cs.c
@@ -371,28 +371,6 @@ static void do_powerdown(struct net_device *dev);
static int do_stop(struct net_device *dev);
/*=============== Helper functions =========================*/
-static int
-first_tuple(struct pcmcia_device *handle, tuple_t *tuple, cisparse_t *parse)
-{
- int err;
-
- if ((err = pcmcia_get_first_tuple(handle, tuple)) == 0 &&
- (err = pcmcia_get_tuple_data(handle, tuple)) == 0)
- err = pcmcia_parse_tuple(tuple, parse);
- return err;
-}
-
-static int
-next_tuple(struct pcmcia_device *handle, tuple_t *tuple, cisparse_t *parse)
-{
- int err;
-
- if ((err = pcmcia_get_next_tuple(handle, tuple)) == 0 &&
- (err = pcmcia_get_tuple_data(handle, tuple)) == 0)
- err = pcmcia_parse_tuple(tuple, parse);
- return err;
-}
-
#define SelectPage(pgnr) outb((pgnr), ioaddr + XIRCREG_PR)
#define GetByte(reg) ((unsigned)inb(ioaddr + (reg)))
#define GetWord(reg) ((unsigned)inw(ioaddr + (reg)))
@@ -761,6 +739,26 @@ xirc2ps_config_check(struct pcmcia_device *p_dev,
}
+
+static int pcmcia_get_mac_ce(struct pcmcia_device *p_dev,
+ tuple_t *tuple,
+ void *priv)
+{
+ struct net_device *dev = priv;
+ int i;
+
+ if (tuple->TupleDataLen != 13)
+ return -EINVAL;
+ if ((tuple->TupleData[0] != 2) || (tuple->TupleData[1] != 1) ||
+ (tuple->TupleData[2] != 6))
+ return -EINVAL;
+ /* another try (James Lehmer's CE2 version 4.1)*/
+ for (i = 2; i < 6; i++)
+ dev->dev_addr[i] = tuple->TupleData[i+2];
+ return 0;
+};
+
+
/****************
* xirc2ps_config() is scheduled to run after a CARD_INSERTION event
* is received, to configure the PCMCIA socket, and to make the
@@ -774,9 +772,9 @@ xirc2ps_config(struct pcmcia_device * link)
unsigned int ioaddr;
tuple_t tuple;
cisparse_t parse;
- int err, i;
- u_char buf[64];
- cistpl_lan_node_id_t *node_id = (cistpl_lan_node_id_t*)parse.funce.data;
+ int err;
+ u8 *buf;
+ size_t len;
local->dingo_ccr = NULL;
@@ -827,49 +825,28 @@ xirc2ps_config(struct pcmcia_device * link)
}
/* get the ethernet address from the CIS */
- tuple.DesiredTuple = CISTPL_FUNCE;
- for (err = first_tuple(link, &tuple, &parse); !err;
- err = next_tuple(link, &tuple, &parse)) {
- /* Once I saw two CISTPL_FUNCE_LAN_NODE_ID entries:
- * the first one with a length of zero the second correct -
- * so I skip all entries with length 0 */
- if (parse.funce.type == CISTPL_FUNCE_LAN_NODE_ID
- && ((cistpl_lan_node_id_t *)parse.funce.data)->nb)
- break;
- }
- if (err) { /* not found: try to get the node-id from tuple 0x89 */
- tuple.DesiredTuple = 0x89; /* data layout looks like tuple 0x22 */
- if ((err = pcmcia_get_first_tuple(link, &tuple)) == 0 &&
- (err = pcmcia_get_tuple_data(link, &tuple)) == 0) {
- if (tuple.TupleDataLen == 8 && *buf == CISTPL_FUNCE_LAN_NODE_ID)
- memcpy(&parse, buf, 8);
- else
- err = -1;
- }
- }
- if (err) { /* another try (James Lehmer's CE2 version 4.1)*/
- tuple.DesiredTuple = CISTPL_FUNCE;
- for (err = first_tuple(link, &tuple, &parse); !err;
- err = next_tuple(link, &tuple, &parse)) {
- if (parse.funce.type == 0x02 && parse.funce.data[0] == 1
- && parse.funce.data[1] == 6 && tuple.TupleDataLen == 13) {
- buf[1] = 4;
- memcpy(&parse, buf+1, 8);
- break;
+ err = pcmcia_get_mac_from_cis(link, dev);
+
+ /* not found: try to get the node-id from tuple 0x89 */
+ if (err) {
+ len = pcmcia_get_tuple(link, 0x89, &buf);
+ /* data layout looks like tuple 0x22 */
+ if (buf && len == 8) {
+ if (*buf == CISTPL_FUNCE_LAN_NODE_ID)
+ memcpy(&parse, buf, 8);
+ else
+ err = -1;
}
- }
+ kfree(buf);
}
+
+ if (err)
+ err = pcmcia_loop_tuple(link, CISTPL_FUNCE, pcmcia_get_mac_ce, dev);
+
if (err) {
printk(KNOT_XIRC "node-id not found in CIS\n");
goto failure;
}
- node_id = (cistpl_lan_node_id_t *)parse.funce.data;
- if (node_id->nb != 6) {
- printk(KNOT_XIRC "malformed node-id in CIS\n");
- goto failure;
- }
- for (i=0; i < 6; i++)
- dev->dev_addr[i] = node_id->id[i];
link->io.IOAddrLines =10;
link->io.Attributes1 = IO_DATA_PATH_WIDTH_16;
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH][RFC]: ingress socket filter by mark
From: Maciej Żenczykowski @ 2009-10-18 23:09 UTC (permalink / raw)
To: hadi; +Cc: Eric Dumazet, netdev, David Miller, Atis Elsts
In-Reply-To: <1255897680.4815.63.camel@dogo.mojatatu.com>
I haven't looked at the patches, but I do not believe requiring
marking to be symmetric to be a good idea.
Example:
- a relatively complex router/load balancer setup
- normal (no mark) packets get routed/load balanced to destinations
which are healthy
- a separate job which health checks the destinations (and updates the
no mark routing table on destination health state transitions) - it
uses socket marking to select a separate routing table which throws
all load at a specific destination host.
ie. the socket marking is used to explicitly direct load at a specific
destination host.
Obviously only the transmit path is affected. There is no marking
happening on the receive path.
Another example would be tunneling. I'd envision something like:
ip tunnel add vtun0 mode gre remote ... local ... tos inherit ttl 64 mark 0x1234
ip rule add fwmark 0x1234 lookup 250
ip route add 192.168.1.0/24 dev eth0 table 250
ip route add default via 192.168.1.1 dev eth0 table 250
ip route add default dev vtun0 table main
(obviously this is just an example and not fully fleshed out,
furthermore ip tunnel doesn't currently support mark, nor do the
tunnel modules themselves)
If you do want to allow explicit incoming mark filtering use another
socket option (SO_MARK_RCV) and a different/new socket field.
>> I vote for extending BPF, and not adding the price of a compare
>> for each packet. Only users wanting mark filtering should pay the price.
I agree that being able to filter on mark in bpf makes a lot of sense.
I wonder if we're not hitting the filters potentially before the mark
is set though (on receive at least)...
I'm nowhere near sure but I think packets get diverted/cloned to
tcpdump before they hit the ip stack (and thus potentially get marked
by ip(6)table mangle rules)
^ permalink raw reply
* Re: [PATCH 0/2] Reduce number of GFP_ATOMIC allocation failures
From: Karol Lewandowski @ 2009-10-19 0:36 UTC (permalink / raw)
To: Frans Pop
Cc: Karol Lewandowski, Mel Gorman, Andrew Morton, stable,
Rafael J. Wysocki, David Miller, reinette chatre, Kalle Valo,
John W. Linville, Pekka Enberg, Bartlomiej Zolnierkiewicz, netdev,
linux-kernel, linux-mm@kvack.org
In-Reply-To: <200910190031.23237.elendil@planet.nl>
On Mon, Oct 19, 2009 at 12:31:15AM +0200, Frans Pop wrote:
> Hi Karol,
Hi,
> > I've tried merging 'akpm' (517d08699b25) into clean 2.6.30 tree and
> > got suspend-breakage which makes it untestable for me. (I've tried
> > reverting drm, suspend, and other commits... all that failed.)
> >
> > Is there mm-related git tree hidden somewhere? ... or broken out
> > mm-related patches that were sent to Andrew ... or maybe it's possible
> > to get "git log -p" from Mel's private repo? Anything?
>
> Please try reverting 373c0a7e + 8aa7e847 [1] on top of 2.6.31. I've finally
> been able to solidly trace the main regression to that. I'm doing some
> final confirmation tests now and will mail detailed results afterwards.
>
> It would be great if you could confirm if that fixes the issue for you too.
Sadly, reverting these patches didn't fix my problem. I've just
tested it -- I still get allocation failures.
Thanks.
e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
e100 0000:00:03.0: PCI INT A -> Link[LNKC] -> GSI 9 (level, low) -> IRQ 9
e100 0000:00:03.0: PME# disabled
e100: eth0: e100_probe: addr 0xe8120000, irq 9, MAC addr 00:10:a4:89:e8:84
ifconfig: page allocation failure. order:5, mode:0x8020
Pid: 2390, comm: ifconfig Not tainted 2.6.31+frans-00002-g90702f9 #1
Call Trace:
[<c015c4c3>] ? __alloc_pages_nodemask+0x405/0x44a
[<c0104de7>] ? dma_generic_alloc_coherent+0x4a/0xab
[<c0104d9d>] ? dma_generic_alloc_coherent+0x0/0xab
[<d1428b6f>] ? e100_alloc_cbs+0xc7/0x174 [e100]
[<d1429bfe>] ? e100_up+0x1b/0xf5 [e100]
[<d1429cef>] ? e100_open+0x17/0x41 [e100]
[<c02f86ff>] ? dev_open+0x8f/0xc5
[<c02f7eb9>] ? dev_change_flags+0xa2/0x155
[<c032da86>] ? devinet_ioctl+0x22a/0x51c
[<c02eba9e>] ? sock_ioctl+0x0/0x1e4
[<c02ebc5e>] ? sock_ioctl+0x1c0/0x1e4
[<c02eba9e>] ? sock_ioctl+0x0/0x1e4
[<c017f21e>] ? vfs_ioctl+0x16/0x4a
[<c017fae5>] ? do_vfs_ioctl+0x48a/0x4c1
[<c016811b>] ? handle_mm_fault+0x1e0/0x42c
[<c0348c4b>] ? do_page_fault+0x2ce/0x2e4
[<c017fb48>] ? sys_ioctl+0x2c/0x42
[<c0102748>] ? sysenter_do_call+0x12/0x26
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
Normal per-cpu:
CPU 0: hi: 90, btch: 15 usd: 37
Active_anon:25140 active_file:4336 inactive_anon:26654
inactive_file:3697 unevictable:0 dirty:7 writeback:0 unstable:0
free:981 slab:1766 mapped:4904 pagetables:456 bounce:0
DMA free:1116kB min:124kB low:152kB high:184kB active_anon:4304kB inactive_anon:4944kB active_file:764kB inactive_file:740kB unevictable:0kB present:15868kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 238 238
Normal free:2808kB min:1908kB low:2384kB high:2860kB active_anon:96256kB inactive_anon:101672kB active_file:16580kB inactive_file:14048kB unevictable:0kB present:243776kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 13*4kB 5*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1116kB
Normal: 454*4kB 62*8kB 31*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2808kB
13458 total pagecache pages
5159 pages in swap cache
Swap cache stats: add 34436, delete 29277, find 9023/11337
Free swap = 465460kB
Total swap = 514040kB
65520 pages RAM
1663 pages reserved
12098 pages shared
55983 pages non-shared
e100 0000:00:03.0: firmware: requesting e100/d101s_ucode.bin
ADDRCONF(NETDEV_UP): eth0: link is not ready
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net-next-2.6] inet: rename some inet_sock fields
From: David Miller @ 2009-10-19 1:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AD74E35.9080004@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 15 Oct 2009 18:30:45 +0200
> In order to have better cache layouts of struct sock (separate zones
> for rx/tx paths), we need this preliminary patch.
>
> Goal is to transfert fields used at lookup time in the first
> read-mostly cache line (inside struct sock_common) and move sk_refcnt
> to a separate cache line (only written by rx path)
>
> This patch adds inet_ prefix to daddr, rcv_saddr, dport, num, saddr,
> sport and id fields. This allows a future patch to define these
> fields as macros, like sk_refcnt, without name clashes.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] cosa: Kill off the use of the old ioctl path
From: David Miller @ 2009-10-19 1:54 UTC (permalink / raw)
To: alan; +Cc: netdev
In-Reply-To: <20091014152224.30363.72926.stgit@localhost.localdomain>
From: Alan Cox <alan@linux.intel.com>
Date: Wed, 14 Oct 2009 16:22:24 +0100
> Signed-off-by: Alan Cox <alan@linux.intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: sk_drops consolidation part 2
From: David Miller @ 2009-10-19 1:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AD6F598.4080007@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 15 Oct 2009 12:12:40 +0200
> - skb_kill_datagram() can increment sk->sk_drops itself, not callers.
>
> - UDP on IPV4 & IPV6 dropped frames (because of bad checksum or policy checks) increment sk_drops
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: kernel panic in latest vanilla stable, while using nameif with "alive" pppoe interfaces
From: Michal Ostrowski @ 2009-10-19 3:34 UTC (permalink / raw)
To: Denys Fedoryschenko; +Cc: netdev, linux-ppp, paulus, mostrows
In-Reply-To: <200910190002.39937.denys@visp.net.lb>
Here's my theory on this after an inital look...
Looking at the oops report and disassembly of the actual module binary
that caused the oops, one can deduce that:
Execution was in pppoe_flush_dev(). %ebx contained the pointer "struct
pppox_sock *po", which is what we faulted on, excuting "cmp %eax, 0x190(%ebx)".
%ebx value was 0xffffffff (hence we got "NULL pointer dereference at 0x18f").
At this point "i" (stored in %esi) is 15 (valid), meaning that we got a value
of 0xffffffff in pn->hash_table[i].
From this I'd hypothesize that the combination of dev_put() and release_sock()
may have allowed us to free "pn". At the bottom of the loop we alreayd
recognize that since locks are dropped we're responsible for handling
invalidation of objects, and perhaps that should be extended to "pn" as well.
--
Michal Ostrowski
mostrows@gmail.com
---
drivers/net/pppoe.c | 86 ++++++++++++++++++++++++++----
--------------------
1 files changed, 45 insertions(+), 41 deletions(-)
diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index 7cbf6f9..720c4ea 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -296,6 +296,7 @@ static void pppoe_flush_dev(struct net_device *dev)
BUG_ON(dev == NULL);
+restart:
pn = pppoe_pernet(dev_net(dev));
if (!pn) /* already freed */
return;
@@ -303,48 +304,51 @@ static void pppoe_flush_dev(struct net_device *dev)
write_lock_bh(&pn->hash_lock);
for (i = 0; i < PPPOE_HASH_SIZE; i++) {
struct pppox_sock *po = pn->hash_table[i];
+ struct sock *sk;
- while (po != NULL) {
- struct sock *sk;
- if (po->pppoe_dev != dev) {
- po = po->next;
- continue;
- }
- sk = sk_pppox(po);
- spin_lock(&flush_lock);
- po->pppoe_dev = NULL;
- spin_unlock(&flush_lock);
- dev_put(dev);
-
- /* We always grab the socket lock, followed by the
- * hash_lock, in that order. Since we should
- * hold the sock lock while doing any unbinding,
- * we need to release the lock we're holding.
- * Hold a reference to the sock so it doesn't disappear
- * as we're jumping between locks.
- */
+ while (po && po->pppoe_dev != dev) {
+ po = po->next;
+ }
- sock_hold(sk);
+ if (po == NULL) {
+ continue;
+ }
- write_unlock_bh(&pn->hash_lock);
- lock_sock(sk);
+ sk = sk_pppox(po);
- if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND)) {
- pppox_unbind_sock(sk);
- sk->sk_state = PPPOX_ZOMBIE;
- sk->sk_state_change(sk);
- }
+ spin_lock(&flush_lock);
+ po->pppoe_dev = NULL;
+ spin_unlock(&flush_lock);
- release_sock(sk);
- sock_put(sk);
+ dev_put(dev);
- /* Restart scan at the beginning of this hash chain.
- * While the lock was dropped the chain contents may
- * have changed.
- */
- write_lock_bh(&pn->hash_lock);
- po = pn->hash_table[i];
- }
+ /* We always grab the socket lock, followed by the
+ * hash_lock, in that order. Since we should
+ * hold the sock lock while doing any unbinding,
+ * we need to release the lock we're holding.
+ * Hold a reference to the sock so it doesn't disappear
+ * as we're jumping between locks.
+ */
+
+ sock_hold(sk);
+
+ write_unlock_bh(&pn->hash_lock);
+ lock_sock(sk);
+
+ if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND)) {
+ pppox_unbind_sock(sk);
+ sk->sk_state = PPPOX_ZOMBIE;
+ sk->sk_state_change(sk);
+ }
+
+ release_sock(sk);
+ sock_put(sk);
+
+ /* Restart the flush process from the beginning. While
+ * the lock was dropped the chain contents may have
+ * changed, and sock_put may have made things go away.
+ */
+ goto restart;
}
write_unlock_bh(&pn->hash_lock);
}
--
1.6.3.3
On Sun, Oct 18, 2009 at 4:02 PM, Denys Fedoryschenko <denys@visp.net.lb> wrote:
>
> I have server running as pppoe NAS.
> Tried to rename customers without dropping pppd connections first, got panic
> after few seconds.
> Panic triggerable at 2.6.30.4 and 2.6.31.4
> pppoe users running on eth2
> pppoe flags:
> 1457 root /usr/sbin/pppoe-server -I eth2 -k -L 172.16.1.1 -R
> 172.16.1.2 -N 253 -C gpzone -S gpzone
>
>
> Commands sequence that i think triggered that:
>
> ip link set eth0 down
> ip link set eth1 down
> ip link set eth2 down
> nameif etherx 00:16:76:8D:83:BA
> nameif eth0 00:19:e0:72:4a:37
> nameif eth1 00:19:e0:72:4a:4b
>
> ip addr flush dev eth0
> ip addr flush dev eth1
> ip addr add X.X.X.X/29 dev eth0
> ip addr add 192.168.2.177/24 dev eth0
> ip addr add 192.168.0.1/32 dev eth1
> ip addr add 127.0.0.0/8 dev lo
> #ip link set eth0 up
> ip link set eth0 up
> ip link set eth1 up
> ip link set lo up
> ip route add 0.0.0.0/0 via X.X.X.X
>
>
> [ 103.428591] r8169: eth0: link up
> [ 103.430360] r8169: eth1: link up
> [ 113.361528] BUG: unable to handle kernel
> NULL pointer dereference
> at 0000018f
> [ 113.361717] IP:
> [<f8868269>] pppoe_device_event+0x80/0x12c [pppoe]
> [ 113.361853] *pdpt = 000000003411a001
> *pde = 0000000000000000
> Oct 18 23:59:40 194.146.153.93
> [ 113.362012] Oops: 0000 [#1]
> SMP
> Oct 18 23:59:40 194.146.153.93
> [ 113.362166] last sysfs file: /sys/devices/virtual/vc/vcs3/dev
> [ 113.362246] Modules linked in:
> netconsole
> configfs
> act_skbedit
> sch_ingress
> sch_prio
> cls_flow
> cls_u32
> em_meta
> cls_basic
> xt_dscp
> xt_DSCP
> ipt_REJECT
> ts_bm
> xt_string
> xt_hl
> ifb
> cls_fw
> sch_tbf
> sch_htb
> act_ipt
> act_mirred
> xt_MARK
> pppoe
> pppox
> ppp_generic
> slhc
> xt_TCPMSS
> xt_mark
> xt_tcpudp
> iptable_mangle
> iptable_nat
> nf_nat
> rtc_cmos
> nf_conntrack_ipv4
> rtc_core
> nf_conntrack
> rtc_lib
> nf_defrag_ipv4
> iptable_filter
> ip_tables
> x_tables
> 8021q
> garp
> stp
> llc
> loop
> sata_sil
> pata_atiixp
> pata_acpi
> ata_generic
> libata
> 8139cp
> usb_storage
> mtdblock
> mtd_blkdevs
> mtd
> sr_mod
> cdrom
> tulip
> r8169
> sky2
> via_velocity
> via_rhine
> sis900
> ne2k_pci
> 8390
> skge
> tg3
> libphy
> 8139too
> e1000
> e100
> usbhid
> ohci_hcd
> uhci_hcd
> ehci_hcd
> usbcore
> nls_base
> Oct 18 23:59:40 194.146.153.93
> [ 113.362344]
> [ 113.362344] Pid: 2858, comm: pppd Not tainted (2.6.31.4-build-0047 #7)
> [ 113.362344] EIP: 0060:[<f8868269>] EFLAGS: 00010286 CPU: 0
> [ 113.362344] EIP is at pppoe_device_event+0x80/0x12c [pppoe]
> [ 113.362344] EAX: f4fbe000 EBX: ffffffff ECX: f6cea5a0 EDX: f7403680
> [ 113.362344] ESI: 0000000f EDI: f6cea5e0 EBP: f4145e34 ESP: f4145e1c
> [ 113.362344] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [ 113.362344] Process pppd (pid: 2858, ti=f4145000 task=f4112ff0
> task.ti=f4145000)
> [ 113.362344] Stack:
> [ 113.362344] f4fbe220
> f4fbe000
> f6cea5a0
> f886a430
> fffffff5
> 00000000
> f4145e54
> c01422b3
> Oct 18 23:59:40 194.146.153.93
> [ 113.362344] <0>
> f4fbe000
> 00000009
> f8a457d8
> f4fbe000
> f8850190
> 00001091
> f4145e64
> c0142361
> Oct 18 23:59:40 194.146.153.93
> [ 113.362344] <0>
> ffffffff
> 00000000
> f4145e74
> c029ffbf
> f4fbe000
> 000010d0
> f4145e90
> c029fa70
> Oct 18 23:59:40 194.146.153.93
> [ 113.362344] Call Trace:
> [ 113.362344] [<c01422b3>] ? notifier_call_chain+0x2b/0x4a
> [ 113.362344] [<c0142361>] ? raw_notifier_call_chain+0xc/0xe
> [ 113.362344] [<c029ffbf>] ? dev_close+0x4c/0x8c
> [ 113.362344] [<c029fa70>] ? dev_change_flags+0xa5/0x158
> [ 113.362344] [<c02da633>] ? devinet_ioctl+0x21a/0x503
> [ 113.362344] [<c02db693>] ? inet_ioctl+0x8d/0xa6
> [ 113.362344] [<c0292b21>] ? sock_ioctl+0x1c8/0x1ec
> [ 113.362344] [<c0292959>] ? sock_ioctl+0x0/0x1ec
> [ 113.362344] [<c019af2b>] ? vfs_ioctl+0x22/0x69
> [ 113.362344] [<c019b435>] ? do_vfs_ioctl+0x41f/0x459
> [ 113.362344] [<c02934eb>] ? sys_send+0x18/0x1a
> [ 113.362344] [<c011942f>] ? do_page_fault+0x242/0x26f
> [ 113.362344] [<c019b49b>] ? sys_ioctl+0x2c/0x45
> [ 113.362344] [<c0102975>] ? syscall_call+0x7/0xb
> [ 113.362344] Code:
> c9
> 00
> 00
> 00
> 89
> c7
> 31
> f6
> 83
> c7
> 40
> 89
> f8
> e8
> cc
> 60
> a9
> c7
> 8b
> 45
> ec
> 05
> 20
> 02
> 00
> 00
> 89
> 45
> e8
> 8b
> 4d
> f0
> 8b
> 1c
> b1
> e9
> 8c
> 00
> 00
> 00
> 8b
> 45
> ec
> Oct 18 23:59:40 194.146.153.93
> 83
> 90
> 01
> 00
> 00
> 74
> 08
> 8b
> 9b
> 8c
> 01
> 00
> 00
> eb
> 79
> b8
> c0
> a6
> 86
> f8
> Oct 18 23:59:40 194.146.153.93
> [ 113.362344] EIP: [<f8868269>]
> pppoe_device_event+0x80/0x12c [pppoe]
> SS:ESP 0068:f4145e1c
> [ 113.362344] CR2: 000000000000018f
> [ 113.373124] ---[ end trace f6fe64a307e97f3b ]---
> [ 113.373203] Kernel panic - not syncing: Fatal exception in interrupt
> [ 113.373286] Pid: 2858, comm: pppd Tainted: G D 2.6.31.4-build-0047
> #7
> [ 113.373379] Call Trace:
> [ 113.373479] [<c02fc496>] ? printk+0xf/0x11
> [ 113.373561] [<c02fc3e7>] panic+0x39/0xd9
> [ 113.373656] [<c01059b7>] oops_end+0x8b/0x9a
> [ 113.373727] [<c0118f6d>] no_context+0x13d/0x147
> [ 113.373800] [<c011908a>] __bad_area_nosemaphore+0x113/0x11b
> [ 113.373881] [<c02953b3>] ? sock_alloc_send_pskb+0x8b/0x24a
> [ 113.373959] [<c0121801>] ? __wake_up_sync_key+0x3b/0x45
> [ 113.374030] [<c0131967>] ? irq_exit+0x39/0x5c
> [ 113.374107] [<c0104393>] ? do_IRQ+0x80/0x96
> [ 113.374183] [<c0102f49>] ? common_interrupt+0x29/0x30
> [ 113.374259] [<c011909f>] bad_area_nosemaphore+0xd/0x10
> [ 113.374348] [<c0119301>] do_page_fault+0x114/0x26f
> [ 113.374526] [<c01191ed>] ? do_page_fault+0x0/0x26f
> [ 113.374605] [<c02fe506>] error_code+0x66/0x6c
> [ 113.374683] [<c02d007b>] ? tcp_v4_send_ack+0xa3/0x10e
> [ 113.374764] [<c01191ed>] ? do_page_fault+0x0/0x26f
> [ 113.374850] [<f8868269>] ? pppoe_device_event+0x80/0x12c [pppoe]
> [ 113.374928] [<c01422b3>] notifier_call_chain+0x2b/0x4a
> [ 113.375012] [<c0142361>] raw_notifier_call_chain+0xc/0xe
> [ 113.375097] [<c029ffbf>] dev_close+0x4c/0x8c
> [ 113.375169] [<c029fa70>] dev_change_flags+0xa5/0x158
> [ 113.375239] [<c02da633>] devinet_ioctl+0x21a/0x503
> [ 113.375318] [<c02db693>] inet_ioctl+0x8d/0xa6
> [ 113.375411] [<c0292b21>] sock_ioctl+0x1c8/0x1ec
> [ 113.375491] [<c0292959>] ? sock_ioctl+0x0/0x1ec
> [ 113.375574] [<c019af2b>] vfs_ioctl+0x22/0x69
> [ 113.375653] [<c019b435>] do_vfs_ioctl+0x41f/0x459
> [ 113.375734] [<c02934eb>] ? sys_send+0x18/0x1a
> [ 113.375813] [<c011942f>] ? do_page_fault+0x242/0x26f
> [ 113.375884] [<c019b49b>] sys_ioctl+0x2c/0x45
> [ 113.375960] [<c0102975>] syscall_call+0x7/0xb
> [ 113.376041] Rebooting in 5 seconds..
^ permalink raw reply related
* ARP Table Access
From: Pawel Pastuszak @ 2009-10-19 3:35 UTC (permalink / raw)
To: netdev
Hi All,
Can anybody guide me to how to access ARP Table to lookup an MAC
access for IP address inside an Network Interface driver (net_dev)?
Also how can i insert into the ARP Table.
Thanks,
Pawel
^ permalink raw reply
* Re: [PATCH 4/4 v3] net: Fix for dst_negative_advice
From: Stephen Hemminger @ 2009-10-19 4:12 UTC (permalink / raw)
To: Krishna Kumar; +Cc: davem, netdev, herbert, Krishna Kumar, dada1
In-Reply-To: <20091018130816.3960.87384.sendpatchset@localhost.localdomain>
On Sun, 18 Oct 2009 18:38:16 +0530
Krishna Kumar <krkumar2@in.ibm.com> wrote:
> From: Krishna Kumar <krkumar2@in.ibm.com>
>
> dst_negative_advice() should check for changed dst and reset
> sk_tx_queue_mapping accordingly. Pass sock to the callers of
> dst_negative_advice.
>
> (sk_reset_txq is defined just for use by dst_negative_advice. The
> only way I could find to get around this is to move dst_negative_()
> from dst.h to dst.c, include sock.h in dst.c, etc)
>
> Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
> ---
> include/net/dst.h | 12 ++++++++++--
> net/core/sock.c | 6 ++++++
> net/dccp/timer.c | 4 ++--
> net/decnet/af_decnet.c | 2 +-
> net/ipv4/tcp_timer.c | 4 ++--
> 5 files changed, 21 insertions(+), 7 deletions(-)
>
> diff -ruNp org/include/net/dst.h new/include/net/dst.h
> --- org/include/net/dst.h 2009-10-16 21:30:56.000000000 +0530
> +++ new/include/net/dst.h 2009-10-16 21:31:30.000000000 +0530
> @@ -222,11 +222,19 @@ static inline void dst_confirm(struct ds
> neigh_confirm(dst->neighbour);
> }
>
> -static inline void dst_negative_advice(struct dst_entry **dst_p)
> +static inline void dst_negative_advice(struct dst_entry **dst_p,
> + struct sock *sk)
> {
> struct dst_entry * dst = *dst_p;
> - if (dst && dst->ops->negative_advice)
> + if (dst && dst->ops->negative_advice) {
> *dst_p = dst->ops->negative_advice(dst);
> +
> + if (dst != *dst_p) {
> + extern void sk_reset_txq(struct sock *sk);
> +
> + sk_reset_txq(sk);
> + }
> + }
> }
>
> static inline void dst_link_failure(struct sk_buff *skb)
> diff -ruNp org/net/core/sock.c new/net/core/sock.c
> --- org/net/core/sock.c 2009-10-16 21:30:56.000000000 +0530
> +++ new/net/core/sock.c 2009-10-16 21:32:33.000000000 +0530
> @@ -352,6 +352,12 @@ discard_and_relse:
> }
> EXPORT_SYMBOL(sk_receive_skb);
>
> +void sk_reset_txq(struct sock *sk)
> +{
> + sk_tx_queue_clear(sk);
> +}
> +EXPORT_SYMBOL(sk_reset_txq);
> +
> struct dst_entry *__sk_dst_check(struct sock *sk, u32 cookie)
> {
> struct dst_entry *dst = sk->sk_dst_cache;
> diff -ruNp org/net/dccp/timer.c new/net/dccp/timer.c
> --- org/net/dccp/timer.c 2009-10-16 21:30:56.000000000 +0530
> +++ new/net/dccp/timer.c 2009-10-16 21:31:30.000000000 +0530
> @@ -38,7 +38,7 @@ static int dccp_write_timeout(struct soc
>
> if (sk->sk_state == DCCP_REQUESTING || sk->sk_state == DCCP_PARTOPEN) {
> if (icsk->icsk_retransmits != 0)
> - dst_negative_advice(&sk->sk_dst_cache);
> + dst_negative_advice(&sk->sk_dst_cache, sk);
> retry_until = icsk->icsk_syn_retries ?
> : sysctl_dccp_request_retries;
> } else {
> @@ -63,7 +63,7 @@ static int dccp_write_timeout(struct soc
> Golden words :-).
> */
>
> - dst_negative_advice(&sk->sk_dst_cache);
> + dst_negative_advice(&sk->sk_dst_cache, sk);
> }
>
> retry_until = sysctl_dccp_retries2;
> diff -ruNp org/net/decnet/af_decnet.c new/net/decnet/af_decnet.c
> --- org/net/decnet/af_decnet.c 2009-10-16 21:30:56.000000000 +0530
> +++ new/net/decnet/af_decnet.c 2009-10-16 21:31:30.000000000 +0530
> @@ -1955,7 +1955,7 @@ static int dn_sendmsg(struct kiocb *iocb
> }
>
> if ((flags & MSG_TRYHARD) && sk->sk_dst_cache)
> - dst_negative_advice(&sk->sk_dst_cache);
> + dst_negative_advice(&sk->sk_dst_cache, sk);
>
> mss = scp->segsize_rem;
> fctype = scp->services_rem & NSP_FC_MASK;
> diff -ruNp org/net/ipv4/tcp_timer.c new/net/ipv4/tcp_timer.c
> --- org/net/ipv4/tcp_timer.c 2009-10-16 21:30:56.000000000 +0530
> +++ new/net/ipv4/tcp_timer.c 2009-10-16 21:31:30.000000000 +0530
> @@ -141,14 +141,14 @@ static int tcp_write_timeout(struct sock
>
> if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
> if (icsk->icsk_retransmits)
> - dst_negative_advice(&sk->sk_dst_cache);
> + dst_negative_advice(&sk->sk_dst_cache, sk);
> retry_until = icsk->icsk_syn_retries ? : sysctl_tcp_syn_retries;
> } else {
> if (retransmits_timed_out(sk, sysctl_tcp_retries1)) {
> /* Black hole detection */
> tcp_mtu_probing(icsk, sk);
>
> - dst_negative_advice(&sk->sk_dst_cache);
> + dst_negative_advice(&sk->sk_dst_cache, sk);
> }
>
> retry_until = sysctl_tcp_retries2;
It is good that your patch is broken in pieces, but will the intermediate patches
still function correctly. I.e are they bisect safe?
^ permalink raw reply
* Re: [PATCH 1/2] ethoc: inline regs access
From: David Miller @ 2009-10-19 4:24 UTC (permalink / raw)
To: thomas; +Cc: netdev, thierry.reding, nios2-dev, linux-kernel
In-Reply-To: <1254961003-2453-1-git-send-email-thomas@wytron.com.tw>
From: Thomas Chou <thomas@wytron.com.tw>
Date: Thu, 8 Oct 2009 08:16:42 +0800
> Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] ethoc: clear only pending irqs
From: David Miller @ 2009-10-19 4:24 UTC (permalink / raw)
To: thomas; +Cc: netdev, thierry.reding, nios2-dev, linux-kernel
In-Reply-To: <1254961003-2453-2-git-send-email-thomas@wytron.com.tw>
From: Thomas Chou <thomas@wytron.com.tw>
Date: Thu, 8 Oct 2009 08:16:43 +0800
> This patch fixed the problem of dropped packets due to lost of
> interrupt requests. We should only clear what was pending at the
> moment we read the irq source reg.
>
> Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Applied.
^ permalink raw reply
* Re: [PATCH] fix section mismatch in fec.c
From: David Miller @ 2009-10-19 4:27 UTC (permalink / raw)
To: sfking; +Cc: linux-kernel, netdev
In-Reply-To: <200910181525.48574.sfking@fdwdc.com>
From: Steven King <sfking@fdwdc.com>
Date: Sun, 18 Oct 2009 15:25:48 -0700
> */
> -int __init fec_enet_init(struct net_device *dev, int index)
> +static int
> +fec_enet_init(struct net_device *dev, int index)
> {
Don't change coding style when fixing a bug.
Fix this up and resubmit your fix, thanks.
^ permalink raw reply
* Re: [PATCH 0/5] IPsec: convert to ahash
From: David Miller @ 2009-10-19 4:34 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20091008084631.GJ15653@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 8 Oct 2009 10:46:31 +0200
> This patchset converts the authentication header (ah4/ah6) IPsec protocol
> over to the new ahash interface. With this patchset IPsec is completely
> converted to ahash. The esp protocol is already converted to ahash by
> converting the authenc crypto algorithm.
All applied to net-next-2.6, thanks Steffen!
^ permalink raw reply
* Re: [PATCH 4/4 v3] net: Fix for dst_negative_advice
From: Krishna Kumar2 @ 2009-10-19 4:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dada1, davem, herbert, netdev
In-Reply-To: <20091019131209.1c782c8a@s6510>
Stephen Hemminger <shemminger@vyatta.com> wrote on 10/19/2009 09:42:09 AM:
> > diff -ruNp org/net/ipv4/tcp_timer.c new/net/ipv4/tcp_timer.c
> > --- org/net/ipv4/tcp_timer.c 2009-10-16 21:30:56.000000000 +0530
> > +++ new/net/ipv4/tcp_timer.c 2009-10-16 21:31:30.000000000 +0530
> > @@ -141,14 +141,14 @@ static int tcp_write_timeout(struct sock
> >
> > if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
> > if (icsk->icsk_retransmits)
> > - dst_negative_advice(&sk->sk_dst_cache);
> > + dst_negative_advice(&sk->sk_dst_cache, sk);
> > retry_until = icsk->icsk_syn_retries ? : sysctl_tcp_syn_retries;
> > } else {
> > if (retransmits_timed_out(sk, sysctl_tcp_retries1)) {
> > /* Black hole detection */
> > tcp_mtu_probing(icsk, sk);
> >
> > - dst_negative_advice(&sk->sk_dst_cache);
> > + dst_negative_advice(&sk->sk_dst_cache, sk);
> > }
> >
> > retry_until = sysctl_tcp_retries2;
>
> It is good that your patch is broken in pieces, but will the intermediate
patches
> still function correctly. I.e are they bisect safe?
I have only compile tested each patch, but I assume it could break
something.
Individual patches can be made to function correctly by renaming patch#2 to
patch#4 and move patch#3 and #4 ahead.
Should I resubmit with the changed order?
Thanks,
- KK
^ permalink raw reply
* dccp-test-tree [PATCH 1/1]: Count lost data packets in a burst loss
From: Gerrit Renker @ 2009-10-19 5:16 UTC (permalink / raw)
To: dccp; +Cc: Ivo Calado, netdev
In-Reply-To: <4AD4B67F.8040208@embedded.ufcg.edu.br>
dccp: Generalise data-loss condition
This patch is thanks to Ivo Calado who had integrated this function into one
of the TFRC-SP patches.
It generalises the task of determining data loss from RFC 43430, 7.7.1.
Let S_A, S_B be sequence numbers such that S_B is "after" S_A, and let
N_B be the NDP count of packet S_B. Then, using module-2^48 arithmetic,
D = S_B - S_A - 1 is an upper bound of the number of lost data packets,
D - N_B is an approximation of the number of lost data packets
(there are cases where this is not exact).
The patch implements this as
dccp_loss_count(S_A, S_B, N_B) := max(S_B - S_A - 1 - N_B, 0)
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/dccp.h | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
--- a/net/dccp/dccp.h
+++ b/net/dccp/dccp.h
@@ -153,18 +153,27 @@ static inline u64 max48(const u64 seq1,
}
/**
- * dccp_loss_free - Evaluates condition for data loss from RFC 4340, 7.7.1
- * @s1: start sequence number
- * @s2: end sequence number
+ * dccp_loss_count - Approximate the number of lost data packets in a burst loss
+ * @s1: last known sequence number before the loss ('hole')
+ * @s2: first sequence number seen after the 'hole'
* @ndp: NDP count on packet with sequence number @s2
- * Returns true if the sequence range s1...s2 has no data loss.
*/
-static inline bool dccp_loss_free(const u64 s1, const u64 s2, const u64 ndp)
+static inline u64 dccp_loss_count(const u64 s1, const u64 s2, const u64 ndp)
{
s64 delta = dccp_delta_seqno(s1, s2);
WARN_ON(delta < 0);
- return (u64)delta <= ndp + 1;
+ delta -= ndp + 1;
+
+ return delta > 0 ? delta : 0;
+}
+
+/**
+ * dccp_loss_free - Evaluate condition for data loss from RFC 4340, 7.7.1
+ */
+static inline bool dccp_loss_free(const u64 s1, const u64 s2, const u64 ndp)
+{
+ return dccp_loss_count(s1, s2, ndp) == 0;
}
enum {
^ permalink raw reply
* Re: [PATCHv2 1/4] First Patch on TFRC-SP. Copy base files from TFRC
From: Gerrit Renker @ 2009-10-19 5:21 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev
In-Reply-To: <4AD4B677.4000308@embedded.ufcg.edu.br>
[-- Attachment #1: Type: text/plain, Size: 263 bytes --]
| First Patch on TFRC-SP.
Please find attached one edit that I made.
I added unwinding the initialisation of tfrc_lib in the case where the
initialisation of tfrc_sp_lib fails. Unwinding is now done in the reverse
order of the steps done during initialisation.
[-- Attachment #2: 1.diff --]
[-- Type: text/x-diff, Size: 689 bytes --]
--- a/net/dccp/ccid.c
+++ b/net/dccp/ccid.c
@@ -223,7 +223,7 @@ int __init ccid_initialize_builtins(void
err = tfrc_sp_lib_init();
if (err)
- return err;
+ goto unwind_tfrc_lib;
for (i = 0; i < ARRAY_SIZE(ccids); i++) {
err = ccid_activate(ccids[i]);
@@ -235,8 +235,10 @@ int __init ccid_initialize_builtins(void
unwind_registrations:
while(--i >= 0)
ccid_deactivate(ccids[i]);
- tfrc_lib_exit();
+
tfrc_sp_lib_exit();
+unwind_tfrc_lib:
+ tfrc_lib_exit();
return err;
}
@@ -246,6 +248,6 @@ void ccid_cleanup_builtins(void)
for (i = 0; i < ARRAY_SIZE(ccids); i++)
ccid_deactivate(ccids[i]);
- tfrc_lib_exit();
tfrc_sp_lib_exit();
+ tfrc_lib_exit();
}
^ permalink raw reply
* Re: [PATCH 1/4] Adds random ect generation to tfrc-sp sender side
From: Gerrit Renker @ 2009-10-19 5:23 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev
In-Reply-To: <4AD4B790.9000701@embedded.ufcg.edu.br>
| Adds random ect generation to tfrc-sp sender side.
I thought about this and found several reasons why it would be better to
defer ECN Nonce sums to a later implementation.
1) At the moment the code always sets ECT(0). Even if it would
alternate ECT(0) and ECT(1), this would later be overwritten by ECT(0)
in dccp_msghdr_parse(). Ok, this could be fixed, but the real problem
is that the underlying machinery does not support ECN nonces, since
* ECN / DiffServ information is in two separate places of the
inet_sock (u8 `tos' field and u8 `tclass' field of ipv6_pinfo);
* the ECN driver sits in include/net/inet_ecn.h as
#define INET_ECN_xmit(sk) do { inet_sk(sk)->tos |= INET_ECN_ECT_0; } while (0)
* hence this would need to be revised and the best way to make an
acceptable suggestion would be a coded proof of concept that
changing the underlying implementation does have benefits.
On the receiver side the situation is the same. The function
tfrc_sp_check_ecn_sum(), introduced in Patch 2/4 of the TFRC-SP sender
implementation is only referenced in Patch 2/2 of the CCID-4 set, where
it ends, without side effect in "TODO: consider ecn sum test fail".
That is, at the moment both the sender and receiver side of the ECN Nonce
sum verification are placeholders which currently have no effect.
2) As far as I can see the ECN Nonce is an optimisation, an
"optional addition to Explicit Congestion Notification [RFC3168]
improving its robustness against malicious or accidental
concealment of marked packets [...]" (from the abstract)
Hence if at all, we would only have a benefit of adding the ECN Nonce
verification on top of an already verified implementation.
3) Starting an implementation throws up further questions that need to
be addressed, both the basis and the extension need to be verified.
I would like to suggest to implement the basis, that is CCID-4 with ECN
(using plain ECT(0)), test with that until it works satisfactorily, and
then continue adding measures such as the ECN Nonce verification.
Nothing is lost, once we are at this stage we can return to this set of
initial patches and revise the situation based on the insights gained
with ECT(0) experience.
In summary, I would like to suggest to remove the ECN verification for
the moment and focus on the "basic" issues first.
Would you be ok with that?
Appendix
--------
| +int tfrc_sp_get_random_ect(struct tfrc_tx_li_data *li_data, u64 seqn)
| +{
| + int ect;
| + struct tfrc_ecn_echo_sum_entry *sum;
| +
| + /* TODO: implement random ect*/
| + ect = INET_ECN_ECT_0;
| +
| + sum = kmem_cache_alloc(tfrc_ecn_echo_sum_slab, GFP_ATOMIC);
For a later implementation, there should be protection against NULL, e.g.
if (sum == NULL) {
DCCP_CRIT("Problem here ...");
return 0;
}
| +
| + sum->previous = li_data->ecn_sums_head;
| + sum->ecn_echo_sum = (sum->previous->ecn_echo_sum) ? !ect : ect;
(Also for later) I wonder how to do the sums, with RFC 3168
ECT(0) = 0x2 => !0x2 = 0
ECT(1) = 0x1 => !0x1 = 0
>From the addition table in RFC 3540, section 2,
ECT(0) + ECT(0) = 0
ECT(0) + ECT(1) = 1
ECT(1) + ECT(1) = 0
One way could be
sum->ecn_echo_sum ^= (ect == INET_ECN_ECT_1);
^ permalink raw reply
* Re: [PATCH 3/4] Implement dropped packets option
From: Gerrit Renker @ 2009-10-19 5:24 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev
In-Reply-To: <4AD4B80D.8090207@embedded.ufcg.edu.br>
| +static struct tfrc_tx_hist_entry*
| + tfrc_sp_seek_tx_entry(struct tfrc_tx_hist_entry *head,
| + u64 seqno, u32 backward)
| +{
| + if (head == NULL)
| + return NULL;
| +
| + while (head->seqno != seqno) {
| + head = head->next;
| +
| + if (head == NULL)
| + return NULL;
| + }
| +
| + while (backward-- > 0) {
| + head = head->next;
| +
| + if (head == NULL)
| + return NULL;
| + }
| +
| + return head;
| +}
| +
| +/*
| + * tfrc_sp_p_from_loss_intervals_opt - calcs p from loss interval option
| + * li_data: data parsed from options
| + * head: contains ccval info
| + * curr_ccval: current ccval
| + * seqno: last acked seqno
| + */
| +u32 tfrc_sp_p_from_loss_intervals_opt(struct tfrc_tx_li_data *li_data,
| + struct tfrc_tx_hist_entry *head,
| + u8 curr_ccval, u64 seqno)
| +{
<snip>
| +
| + for (i = 1; i <= k; i++) {
| + i_i = li_data->loss_interval_data[i];
| + i_totl += i_i;
| + ccval = tfrc_sp_seek_tx_entry(head, seqno, i_totl - 1)->ccval;
tfrc_sp_seek_tx_entry() can return NULL (as per above implementation). Then this
will crash/panic.
<snip>
| +
| + if (i > 1)
| + i_tot1 += i_i * tfrc_lh_weights[i-2];
| + }
| +
| + ccval = tfrc_sp_seek_tx_entry(head, seqno,
| + li_data->loss_interval_data[1] - 1)->ccval;
Here it can also crash.
Getting a sender-based implementation right is complex, since it requires to
enforce consistency and garbage collection for so many data structures.
That is why I think it would be easier to start with a receiver-based implementation
and then grow it into a sender-based implementation if it shows promise.
^ permalink raw reply
* Re: [PATCHv2 2/4] Implement loss counting on TFRC-SP receiver
From: Gerrit Renker @ 2009-10-19 5:26 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev
In-Reply-To: <4AD4B67F.8040208@embedded.ufcg.edu.br>
[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]
| --- dccp_tree_work03.orig/net/dccp/ccids/lib/packet_history_sp.c 2009-10-08 22:58:21.418908270 -0300
| +++ dccp_tree_work03/net/dccp/ccids/lib/packet_history_sp.c 2009-10-08 22:59:07.442411383 -0300
| @@ -243,6 +243,7 @@
| {
| u64 s0 = tfrc_rx_hist_loss_prev(h)->tfrchrx_seqno,
| s1 = tfrc_rx_hist_entry(h, 1)->tfrchrx_seqno,
| + n1 = tfrc_rx_hist_entry(h, 1)->tfrchrx_ndp,
| s2 = tfrc_rx_hist_entry(h, 2)->tfrchrx_seqno,
| s3 = DCCP_SKB_CB(skb)->dccpd_seq;
I have removed the old definition of n1, which was further below and which caused this warning.
net/dccp/ccids/lib/packet_history_sp.c:276:7: warning: symbol 'n1' shadows an earlier
net/dccp/ccids/lib/packet_history_sp.c:247:6: originally declared here
I thought again about the earlier suggestion to make 'num_losses' u64. Since li_losses sums the values
stored in num_losses, it needs to have the same size (currently it is u32). But then another thought is
that if there are so many losses that u32 overflows, then the performance is so bad anyway that it is
better to turn off the receiver. Hence I have reverted it to u32, as per your original patch.
Please find attached a patch of the changes I made. As per posting, I have separated out the dccp.h part,
since it is also useful in general.
[-- Attachment #2: 2.diff --]
[-- Type: text/x-diff, Size: 991 bytes --]
--- a/net/dccp/ccids/lib/packet_history_sp.c
+++ b/net/dccp/ccids/lib/packet_history_sp.c
@@ -272,7 +272,6 @@ static int __two_after_loss(struct tfrc_
/* S0 < S3 < S1 */
if (dccp_loss_free(s0, s3, n3)) {
- u64 n1 = tfrc_rx_hist_entry(h, 1)->tfrchrx_ndp;
if (dccp_loss_free(s3, s1, n1)) {
/* hole between S0 and S1 filled by S3 */
--- a/net/dccp/ccids/lib/packet_history_sp.h
+++ b/net/dccp/ccids/lib/packet_history_sp.h
@@ -117,7 +117,7 @@ struct tfrc_rx_hist {
u32 packet_size,
bytes_recvd;
ktime_t bytes_start;
- u64 num_losses;
+ u32 num_losses;
};
/**
--- a/net/dccp/ccids/lib/loss_interval_sp.c
+++ b/net/dccp/ccids/lib/loss_interval_sp.c
@@ -203,7 +203,8 @@ bool tfrc_sp_lh_interval_add(struct tfrc
cur->li_seqno = cong_evt_seqno;
cur->li_ccval = cong_evt->tfrchrx_ccval;
cur->li_is_closed = false;
- cur->li_losses = rh->num_losses;
+
+ cur->li_losses = rh->num_losses;
rh->num_losses = 0;
if (++lh->counter == 1)
^ permalink raw reply
* Re: possible circular locking dependency in ISDN PPP
From: Xiaotian Feng @ 2009-10-19 5:27 UTC (permalink / raw)
To: Tilman Schmidt; +Cc: LKML, isdn4linux, Netdev
In-Reply-To: <4ADB93C4.4090607@imap.cc>
---> isdn_net_get_locked_lp
--->lock &nd->queue_lock
--->lock &nd->queue->xmit_lock
.....................
---->unlock &nd->queue_lock
---> isdn_net_writebuf_skb (called with &nd->queue->xmit_lock locked)
---->isdn_net_inc_frame_cnt
---->isdn_net_device_busy
----> lock &nd->queue_lock
So there's a circular locking dependency.. Looking into isdn_net_get_locked_lp()
static __inline__ isdn_net_local * isdn_net_get_locked_lp(isdn_net_dev *nd)
{
unsigned long flags;
isdn_net_local *lp;
spin_lock_irqsave(&nd->queue_lock, flags);
lp = nd->queue; /* get lp on top of queue */
spin_lock(&nd->queue->xmit_lock);
while (isdn_net_lp_busy(nd->queue)) {
spin_unlock(&nd->queue->xmit_lock);
nd->queue = nd->queue->next;
if (nd->queue == lp) { /* not found -- should never happen */
lp = NULL;
goto errout;
}
spin_lock(&nd->queue->xmit_lock);
}
lp = nd->queue;
nd->queue = nd->queue->next;
local_bh_disable();
errout:
spin_unlock_irqrestore(&nd->queue_lock, flags);
return lp;
}
Why do we need to hold xmit_lock while using
isdn_net_lp_busy(nd->queue) ? Can following patch fix this bug?
---
diff --git a/drivers/isdn/i4l/isdn_net.h b/drivers/isdn/i4l/isdn_net.h
index 74032d0..7511f08 100644
--- a/drivers/isdn/i4l/isdn_net.h
+++ b/drivers/isdn/i4l/isdn_net.h
@@ -83,19 +83,19 @@ static __inline__ isdn_net_local *
isdn_net_get_locked_lp(isdn_net_dev *nd)
spin_lock_irqsave(&nd->queue_lock, flags);
lp = nd->queue; /* get lp on top of queue */
- spin_lock(&nd->queue->xmit_lock);
while (isdn_net_lp_busy(nd->queue)) {
- spin_unlock(&nd->queue->xmit_lock);
nd->queue = nd->queue->next;
if (nd->queue == lp) { /* not found -- should never happen */
lp = NULL;
goto errout;
}
- spin_lock(&nd->queue->xmit_lock);
}
lp = nd->queue;
nd->queue = nd->queue->next;
+ spin_unlock_irqrestore(&nd->queue_lock, flags);
+ spin_lock(&lp->xmit_lock);
local_bh_disable();
+ return lp;
errout:
spin_unlock_irqrestore(&nd->queue_lock, flags);
return lp;
On Mon, Oct 19, 2009 at 6:16 AM, Tilman Schmidt <tilman@imap.cc> wrote:
> A test of PPP over ISDN with ipppd, capidrv and the so far unmerged
> CAPI port of the Gigaset driver produced the following lockdep
> message:
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.32-rc4-testing #7
> -------------------------------------------------------
> ipppd/28379 is trying to acquire lock:
> (&netdev->queue_lock){......}, at: [<e62ad0fd>] isdn_net_device_busy+0x2c/0x74 [isdn]
>
> but task is already holding lock:
> (&netdev->local->xmit_lock){+.....}, at: [<e62aefc2>] isdn_net_write_super+0x3f/0x6e [isdn]
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&netdev->local->xmit_lock){+.....}:
> [<c0157e9c>] __lock_acquire+0xa12/0xb99
> [<c01580ac>] lock_acquire+0x89/0xa0
> [<c0373249>] _spin_lock+0x1b/0x2a
> [<e62b9d1c>] isdn_ppp_xmit+0xf0/0x5b0 [isdn]
> [<e62b03f0>] isdn_net_start_xmit+0x4c6/0x66b [isdn]
> [<c0307e75>] dev_hard_start_xmit+0x251/0x2e4
> [<c0317bcc>] sch_direct_xmit+0x4f/0x122
> [<c030829c>] dev_queue_xmit+0x2ae/0x412
> [<c030d748>] neigh_resolve_output+0x1f2/0x23c
> [<c0329b9c>] ip_finish_output2+0x1b1/0x1db
> [<c0329c25>] ip_finish_output+0x5f/0x62
> [<c0329cb5>] ip_output+0x8d/0x92
> [<c03290c0>] ip_local_out+0x18/0x1b
> [<c032932c>] ip_push_pending_frames+0x269/0x2c1
> [<c033fd78>] raw_sendmsg+0x618/0x6b0
> [<c0347ac9>] inet_sendmsg+0x3b/0x48
> [<c02fa5b5>] __sock_sendmsg+0x45/0x4e
> [<c02fad4b>] sock_sendmsg+0xb8/0xce
> [<c02faea0>] sys_sendmsg+0x13f/0x192
> [<c02fbeb2>] sys_socketcall+0x157/0x18e
> [<c0102974>] sysenter_do_call+0x12/0x32
>
> -> #0 (&netdev->queue_lock){......}:
> [<c0157da9>] __lock_acquire+0x91f/0xb99
> [<c01580ac>] lock_acquire+0x89/0xa0
> [<c03732db>] _spin_lock_irqsave+0x24/0x34
> [<e62ad0fd>] isdn_net_device_busy+0x2c/0x74 [isdn]
> [<e62aeee3>] isdn_net_writebuf_skb+0x6e/0xc2 [isdn]
> [<e62aefd4>] isdn_net_write_super+0x51/0x6e [isdn]
> [<e62bc26f>] isdn_ppp_write+0x3a8/0x3bc [isdn]
> [<e62b785a>] isdn_write+0x1d9/0x1f9 [isdn]
> [<c01c42c5>] vfs_write+0x84/0xdf
> [<c01c43b9>] sys_write+0x3b/0x60
> [<c0102974>] sysenter_do_call+0x12/0x32
>
> other info that might help us debug this:
>
> 1 lock held by ipppd/28379:
> #0: (&netdev->local->xmit_lock){+.....}, at: [<e62aefc2>] isdn_net_write_super+0x3f/0x6e [isdn]
>
> stack backtrace:
> Pid: 28379, comm: ipppd Not tainted 2.6.32-rc4-testing #7
> Call Trace:
> [<c03710dc>] ? printk+0xf/0x13
> [<c015714d>] print_circular_bug+0x90/0x9c
> [<c0157da9>] __lock_acquire+0x91f/0xb99
> [<c01580ac>] lock_acquire+0x89/0xa0
> [<e62ad0fd>] ? isdn_net_device_busy+0x2c/0x74 [isdn]
> [<c03732db>] _spin_lock_irqsave+0x24/0x34
> [<e62ad0fd>] ? isdn_net_device_busy+0x2c/0x74 [isdn]
> [<e62ad0fd>] isdn_net_device_busy+0x2c/0x74 [isdn]
> [<e62aeee3>] isdn_net_writebuf_skb+0x6e/0xc2 [isdn]
> [<e62aefd4>] isdn_net_write_super+0x51/0x6e [isdn]
> [<e62bc26f>] isdn_ppp_write+0x3a8/0x3bc [isdn]
> [<e62b785a>] isdn_write+0x1d9/0x1f9 [isdn]
> [<c01c3b6c>] ? rw_verify_area+0x8a/0xad
> [<e62b7681>] ? isdn_write+0x0/0x1f9 [isdn]
> [<c01c42c5>] vfs_write+0x84/0xdf
> [<c01c43b9>] sys_write+0x3b/0x60
> [<c0102974>] sysenter_do_call+0x12/0x32
>
> The message appeared shortly after initiating the connection,
> during the PPP negotiation, just when the IP address was assigned.
> The system continued to run normally, and the connection was
> successfully established. Full log showing the entire connection
> (with capidrv and Gigaset driver debugging output enabled, 70 kB),
> available at http://www.phoenixsoftware.de/~ts/ppp-lockprob-full.log
> in case someone's interested. It shows the messages from ipppd
> about the IP address assignment arriving in the middle of the
> lockdep message.
>
> I cannot say whether this is a regression. My previous tests of
> that scenario were done on a machine with an Nvidia graphics card
> where the lockdep machinery would refuse to run because of the
> kernel being tainted by the Nvidia driver, so I wouldn't have seen
> anything one way or another.
>
> Btw, one of those "NOHZ: local_softirq_pending 08" messages is also
> present in the log, but that's 28 seconds later so I'd be surprised
> if the two were related.
>
> Any hints about the possible cause and seriousness of that
> message would be welcome. I'm particularly interested, of course,
> in finding out whether the Gigaset driver might somehow be causing
> it, even though it doesn't appear anywhere in the backtraces.
>
> aTdHvAaNnKcSe
> Tilman
>
> --
> Tilman Schmidt E-Mail: tilman@imap.cc
> Bonn, Germany
> Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
> Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
>
>
^ permalink raw reply related
* [PATCH] myri10ge: improve port type reporting in ethtool output
From: Brice Goglin @ 2009-10-19 5:35 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Network Development list
Improve the reporting of the port type in ethtool,
update for new boards.
Signed-off-by: Brice Goglin <brice@myri.com>
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -75,7 +75,7 @@
#include "myri10ge_mcp.h"
#include "myri10ge_mcp_gen_header.h"
-#define MYRI10GE_VERSION_STR "1.5.0-1.432"
+#define MYRI10GE_VERSION_STR "1.5.1-1.450"
MODULE_DESCRIPTION("Myricom 10G driver (10GbE)");
MODULE_AUTHOR("Maintainer: help@myri.com");
@@ -1601,6 +1601,8 @@ myri10ge_get_settings(struct net_device *netdev,
struct ethtool_cmd *cmd)
cmd->autoneg = AUTONEG_DISABLE;
cmd->speed = SPEED_10000;
cmd->duplex = DUPLEX_FULL;
+ cmd->supported = SUPPORTED_10000baseT_Full;
+ cmd->advertising = ADVERTISED_10000baseT_Full;
/*
* parse the product code to deterimine the interface type
@@ -1623,10 +1625,19 @@ myri10ge_get_settings(struct net_device *netdev,
struct ethtool_cmd *cmd)
return 0;
}
}
- if (*ptr == 'R' || *ptr == 'Q') {
- /* We've found either an XFP or quad ribbon fiber */
+ if (*ptr == '2')
+ ptr++;
+ if (*ptr == 'R' || *ptr == 'Q' || *ptr == 'S') {
+ /* We've found either an XFP, quad ribbon fiber, or SFP+ */
cmd->port = PORT_FIBRE;
+ cmd->supported |= SUPPORTED_FIBRE;
+ cmd->advertising |= ADVERTISED_FIBRE;
}
+ if (*ptr == 'R' || *ptr == 'S')
+ cmd->transceiver = XCVR_EXTERNAL;
+ else
+ cmd->transceiver = XCVR_INTERNAL;
+
return 0;
}
^ permalink raw reply
* Re: [OT] ntop / GPL (was Re: PF_RING: Include in main line kernel?)
From: Jarek Poplawski @ 2009-10-19 5:55 UTC (permalink / raw)
To: Harald Welte; +Cc: Brad Doctor, netdev, Luca Deri
In-Reply-To: <20091018124706.GG27747@prithivi.gnumonks.org>
On Sun, Oct 18, 2009 at 02:47:06PM +0200, Harald Welte wrote:
> Hi Jarek, Brad, Luca,
>
> [putting my gpl-violations.org hat on]
>
> On Wed, Oct 14, 2009 at 06:46:11PM +0200, Jarek Poplawski wrote:
> > Brad Doctor wrote, On 10/14/2009 04:33 PM:
> >
> > > Download ntop
> > >
> > > ntop is distributed under the GNU GPL. In order to be entitled to download
> > > ntop you must accept the GNU license.
> >
> > I can't find such a thing neither in GNU GPL v2:
>
> This is true. The GPL does never need to be accepted for mere use (i.e.
> running) the program. This is at least true for the continental european
> copyright systems, where any legally obtained copy of a program implicitly
> carries the permission for running the program. Only for any other activity
> you will need to accept the license.
>
> but, like others posted in this thread, ntop is not the PF_RING code.
ntop doesn't matter here at all:
if ((X uses the stock GPL license.) &&
(Y is distributed under the GNU GPL) &&
(In order to be entitled to download Y
you must accept the GNU license.) &&
(The GPL does never need to be accepted for mere use.))
is logically false.
BTW, legal systems don't matter here at all.
Jarek P.
^ permalink raw reply
* Re: [PATCH] AF_UNIX: Fix deadlock on connecting to shutdown socket
From: David Miller @ 2009-10-19 6:18 UTC (permalink / raw)
To: tomoki.sekiyama.qu
Cc: linux-kernel, netdev, alan, satoshi.oshima.fk, hidehiro.kawai.ez,
hideo.aoki.tk
In-Reply-To: <4ADC010C.5070809@hitachi.com>
From: Tomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com>
Date: Mon, 19 Oct 2009 15:02:52 +0900
> I found a deadlock bug in UNIX domain socket, which makes able to DoS
> attack against the local machine by non-root users.
...
> Why this happens:
> Error checks between unix_socket_connect() and unix_wait_for_peer() are
> inconsistent. The former calls the latter to wait until the backlog is
> processed. Despite the latter returns without doing anything when the
> socket is shutdown, the former doesn't check the shutdown state and
> just retries calling the latter forever.
>
> Patch:
> The patch below adds shutdown check into unix_socket_connect(), so
> connect(2) to the shutdown socket will return -ECONREFUSED.
>
> Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com>
> Signed-off-by: Masanori Yoshida <masanori.yoshida.tv@hitachi.com>
Looks good, applied, thank you!
^ permalink raw reply
* [PATCH] AF_UNIX: Fix deadlock on connecting to shutdown socket
From: Tomoki Sekiyama @ 2009-10-19 6:02 UTC (permalink / raw)
To: linux-kernel, netdev, alan
Cc: davem, satoshi.oshima.fk, hidehiro.kawai.ez, hideo.aoki.tk
Hi,
I found a deadlock bug in UNIX domain socket, which makes able to DoS
attack against the local machine by non-root users.
How to reproduce:
1. Make a listening AF_UNIX/SOCK_STREAM socket with an abstruct
namespace(*), and shutdown(2) it.
2. Repeat connect(2)ing to the listening socket from the other sockets
until the connection backlog is full-filled.
3. connect(2) takes the CPU forever. If every core is taken, the
system hangs.
PoC code: (Run as many times as cores on SMP machines.)
int main(void)
{
int ret;
int csd;
int lsd;
struct sockaddr_un sun;
/* make an abstruct name address (*) */
memset(&sun, 0, sizeof(sun));
sun.sun_family = PF_UNIX;
sprintf(&sun.sun_path[1], "%d", getpid());
/* create the listening socket and shutdown */
lsd = socket(AF_UNIX, SOCK_STREAM, 0);
bind(lsd, (struct sockaddr *)&sun, sizeof(sun));
listen(lsd, 1);
shutdown(lsd, SHUT_RDWR);
/* connect loop */
alarm(15); /* forcely exit the loop after 15 sec */
for (;;) {
csd = socket(AF_UNIX, SOCK_STREAM, 0);
ret = connect(csd, (struct sockaddr *)&sun, sizeof(sun));
if (-1 == ret) {
perror("connect()");
break;
}
puts("Connection OK");
}
return 0;
}
(*) Make sun_path[0] = 0 to use the abstruct namespace.
If a file-based socket is used, the system doesn't deadlock because
of context switches in the file system layer.
Why this happens:
Error checks between unix_socket_connect() and unix_wait_for_peer() are
inconsistent. The former calls the latter to wait until the backlog is
processed. Despite the latter returns without doing anything when the
socket is shutdown, the former doesn't check the shutdown state and
just retries calling the latter forever.
Patch:
The patch below adds shutdown check into unix_socket_connect(), so
connect(2) to the shutdown socket will return -ECONREFUSED.
Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com>
Signed-off-by: Masanori Yoshida <masanori.yoshida.tv@hitachi.com>
---
net/unix/af_unix.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 51ab497..fc820cd 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1074,6 +1074,8 @@ restart:
err = -ECONNREFUSED;
if (other->sk_state != TCP_LISTEN)
goto out_unlock;
+ if (other->sk_shutdown & RCV_SHUTDOWN)
+ goto out_unlock;
if (unix_recvq_full(other)) {
err = -EAGAIN;
--
Tomoki Sekiyama
Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: tomoki.sekiyama.qu@hitachi.com
^ permalink raw reply related
* [PATCH 1/2] bluetooth: scheduling while atomic bug fix
From: Dave Young @ 2009-10-19 6:24 UTC (permalink / raw)
To: marcel-kz+m5ild9QBg9hUCZPvPmw
Cc: alan-qBU/x9rampVanCEyBjwyrvXRex20P6io,
oliver-fJ+pQTUTwRTk1uMJSBkQmQ, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Due to driver core changes dev_set_drvdata will call kzalloc which should be
in might_sleep context, but hci_conn_add will be called in atomic context
Like dev_set_name move dev_set_drvdata to work queue function.
oops as following:
Oct 2 17:41:59 darkstar kernel: [ 438.001341] BUG: sleeping function called from invalid context at mm/slqb.c:1546
Oct 2 17:41:59 darkstar kernel: [ 438.001345] in_atomic(): 1, irqs_disabled(): 0, pid: 2133, name: sdptool
Oct 2 17:41:59 darkstar kernel: [ 438.001348] 2 locks held by sdptool/2133:
Oct 2 17:41:59 darkstar kernel: [ 438.001350] #0: (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.+.}, at: [<faa1d2f5>] lock_sock+0xa/0xc [l2cap]
Oct 2 17:41:59 darkstar kernel: [ 438.001360] #1: (&hdev->lock){+.-.+.}, at: [<faa20e16>] l2cap_sock_connect+0x103/0x26b [l2cap]
Oct 2 17:41:59 darkstar kernel: [ 438.001371] Pid: 2133, comm: sdptool Not tainted 2.6.31-mm1 #2
Oct 2 17:41:59 darkstar kernel: [ 438.001373] Call Trace:
Oct 2 17:41:59 darkstar kernel: [ 438.001381] [<c022433f>] __might_sleep+0xde/0xe5
Oct 2 17:41:59 darkstar kernel: [ 438.001386] [<c0298843>] __kmalloc+0x4a/0x15a
Oct 2 17:41:59 darkstar kernel: [ 438.001392] [<c03f0065>] ? kzalloc+0xb/0xd
Oct 2 17:41:59 darkstar kernel: [ 438.001396] [<c03f0065>] kzalloc+0xb/0xd
Oct 2 17:41:59 darkstar kernel: [ 438.001400] [<c03f04ff>] device_private_init+0x15/0x3d
Oct 2 17:41:59 darkstar kernel: [ 438.001405] [<c03f24c5>] dev_set_drvdata+0x18/0x26
Oct 2 17:41:59 darkstar kernel: [ 438.001414] [<fa51fff7>] hci_conn_init_sysfs+0x40/0xd9 [bluetooth]
Oct 2 17:41:59 darkstar kernel: [ 438.001422] [<fa51cdc0>] ? hci_conn_add+0x128/0x186 [bluetooth]
Oct 2 17:41:59 darkstar kernel: [ 438.001429] [<fa51ce0f>] hci_conn_add+0x177/0x186 [bluetooth]
Oct 2 17:41:59 darkstar kernel: [ 438.001437] [<fa51cf8a>] hci_connect+0x3c/0xfb [bluetooth]
Oct 2 17:41:59 darkstar kernel: [ 438.001442] [<faa20e87>] l2cap_sock_connect+0x174/0x26b [l2cap]
Oct 2 17:41:59 darkstar kernel: [ 438.001448] [<c04c8df5>] sys_connect+0x60/0x7a
Oct 2 17:41:59 darkstar kernel: [ 438.001453] [<c024b703>] ? lock_release_non_nested+0x84/0x1de
Oct 2 17:41:59 darkstar kernel: [ 438.001458] [<c028804b>] ? might_fault+0x47/0x81
Oct 2 17:41:59 darkstar kernel: [ 438.001462] [<c028804b>] ? might_fault+0x47/0x81
Oct 2 17:41:59 darkstar kernel: [ 438.001468] [<c033361f>] ? __copy_from_user_ll+0x11/0xce
Oct 2 17:41:59 darkstar kernel: [ 438.001472] [<c04c9419>] sys_socketcall+0x82/0x17b
Oct 2 17:41:59 darkstar kernel: [ 438.001477] [<c020329d>] syscall_call+0x7/0xb
Signed-off-by: Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/bluetooth/hci_sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.31.orig/net/bluetooth/hci_sysfs.c 2009-10-09 20:50:43.000000000 +0800
+++ linux-2.6.31/net/bluetooth/hci_sysfs.c 2009-10-10 21:24:56.000000000 +0800
@@ -92,6 +92,8 @@ static void add_conn(struct work_struct
dev_set_name(&conn->dev, "%s:%d", hdev->name, conn->handle);
+ dev_set_drvdata(&conn->dev, conn);
+
if (device_add(&conn->dev) < 0) {
BT_ERR("Failed to register connection device");
return;
@@ -144,8 +146,6 @@ void hci_conn_init_sysfs(struct hci_conn
conn->dev.class = bt_class;
conn->dev.parent = &hdev->dev;
- dev_set_drvdata(&conn->dev, conn);
-
device_initialize(&conn->dev);
INIT_WORK(&conn->work_add, add_conn);
^ 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