* [PATCH 6/7] isdn/gigaset: ignore irrelevant device responses
From: Tilman Schmidt @ 2010-05-23 0:27 UTC (permalink / raw)
To: Karsten Keil, David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Karsten Keil, Hansjoerg Lipp,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
i4ldeveloper-JX7+OpRa80SjiSfgN6Y1Ib39b6g2fGNp
In-Reply-To: <20100522-patch-gigaset-00.tilman-ZTO5kqT2PaM@public.gmane.org>
Downgrade the Gigaset driver's reaction to unknown AT responses from
the device from warning to debug level, and remove the handling of
some device responses which aren't relevant for the driver's
operation.
Signed-off-by: Tilman Schmidt <tilman-ZTO5kqT2PaM@public.gmane.org>
---
drivers/isdn/gigaset/ev-layer.c | 67 ++++++++------------------------------
drivers/isdn/gigaset/gigaset.h | 5 +--
2 files changed, 16 insertions(+), 56 deletions(-)
diff --git a/drivers/isdn/gigaset/ev-layer.c b/drivers/isdn/gigaset/ev-layer.c
index 84a8901..78c7844 100644
--- a/drivers/isdn/gigaset/ev-layer.c
+++ b/drivers/isdn/gigaset/ev-layer.c
@@ -35,53 +35,40 @@
#define RT_RING 2
#define RT_NUMBER 3
#define RT_STRING 4
-#define RT_HEX 5
#define RT_ZCAU 6
/* Possible ASCII responses */
#define RSP_OK 0
-#define RSP_BUSY 1
-#define RSP_CONNECT 2
+#define RSP_ERROR 1
#define RSP_ZGCI 3
#define RSP_RING 4
-#define RSP_ZAOC 5
-#define RSP_ZCSTR 6
-#define RSP_ZCFGT 7
-#define RSP_ZCFG 8
-#define RSP_ZCCR 9
-#define RSP_EMPTY 10
-#define RSP_ZLOG 11
-#define RSP_ZCAU 12
-#define RSP_ZMWI 13
-#define RSP_ZABINFO 14
-#define RSP_ZSMLSTCHG 15
+#define RSP_ZVLS 5
+#define RSP_ZCAU 6
+
+/* responses with values to store in at_state */
+/* - numeric */
#define RSP_VAR 100
#define RSP_ZSAU (RSP_VAR + VAR_ZSAU)
#define RSP_ZDLE (RSP_VAR + VAR_ZDLE)
-#define RSP_ZVLS (RSP_VAR + VAR_ZVLS)
#define RSP_ZCTP (RSP_VAR + VAR_ZCTP)
+/* - string */
#define RSP_STR (RSP_VAR + VAR_NUM)
#define RSP_NMBR (RSP_STR + STR_NMBR)
#define RSP_ZCPN (RSP_STR + STR_ZCPN)
#define RSP_ZCON (RSP_STR + STR_ZCON)
#define RSP_ZBC (RSP_STR + STR_ZBC)
#define RSP_ZHLC (RSP_STR + STR_ZHLC)
-#define RSP_ERROR -1 /* ERROR */
+
#define RSP_WRONG_CID -2 /* unknown cid in cmd */
-#define RSP_UNKNOWN -4 /* unknown response */
-#define RSP_FAIL -5 /* internal error */
#define RSP_INVAL -6 /* invalid response */
+#define RSP_NODEV -9 /* device not connected */
#define RSP_NONE -19
#define RSP_STRING -20
#define RSP_NULL -21
-#define RSP_RETRYFAIL -22
-#define RSP_RETRY -23
-#define RSP_SKIP -24
#define RSP_INIT -27
#define RSP_ANY -26
#define RSP_LAST -28
-#define RSP_NODEV -9
/* actions for process_response */
#define ACT_NOTHING 0
@@ -259,13 +246,6 @@ struct reply_t gigaset_tab_nocid[] =
/* misc. */
{RSP_ERROR, -1, -1, -1, -1, -1, {ACT_ERROR} },
-{RSP_ZCFGT, -1, -1, -1, -1, -1, {ACT_DEBUG} },
-{RSP_ZCFG, -1, -1, -1, -1, -1, {ACT_DEBUG} },
-{RSP_ZLOG, -1, -1, -1, -1, -1, {ACT_DEBUG} },
-{RSP_ZMWI, -1, -1, -1, -1, -1, {ACT_DEBUG} },
-{RSP_ZABINFO, -1, -1, -1, -1, -1, {ACT_DEBUG} },
-{RSP_ZSMLSTCHG, -1, -1, -1, -1, -1, {ACT_DEBUG} },
-
{RSP_ZCAU, -1, -1, -1, -1, -1, {ACT_ZCAU} },
{RSP_NONE, -1, -1, -1, -1, -1, {ACT_DEBUG} },
{RSP_ANY, -1, -1, -1, -1, -1, {ACT_WARN} },
@@ -363,10 +343,6 @@ struct reply_t gigaset_tab_cid[] =
/* misc. */
{RSP_ZCON, -1, -1, -1, -1, -1, {ACT_DEBUG} },
-{RSP_ZCCR, -1, -1, -1, -1, -1, {ACT_DEBUG} },
-{RSP_ZAOC, -1, -1, -1, -1, -1, {ACT_DEBUG} },
-{RSP_ZCSTR, -1, -1, -1, -1, -1, {ACT_DEBUG} },
-
{RSP_ZCAU, -1, -1, -1, -1, -1, {ACT_ZCAU} },
{RSP_NONE, -1, -1, -1, -1, -1, {ACT_DEBUG} },
{RSP_ANY, -1, -1, -1, -1, -1, {ACT_WARN} },
@@ -389,20 +365,11 @@ static const struct resp_type_t {
{"ZVLS", RSP_ZVLS, RT_NUMBER},
{"ZCTP", RSP_ZCTP, RT_NUMBER},
{"ZDLE", RSP_ZDLE, RT_NUMBER},
- {"ZCFGT", RSP_ZCFGT, RT_NUMBER},
- {"ZCCR", RSP_ZCCR, RT_NUMBER},
- {"ZMWI", RSP_ZMWI, RT_NUMBER},
{"ZHLC", RSP_ZHLC, RT_STRING},
{"ZBC", RSP_ZBC, RT_STRING},
{"NMBR", RSP_NMBR, RT_STRING},
{"ZCPN", RSP_ZCPN, RT_STRING},
{"ZCON", RSP_ZCON, RT_STRING},
- {"ZAOC", RSP_ZAOC, RT_STRING},
- {"ZCSTR", RSP_ZCSTR, RT_STRING},
- {"ZCFG", RSP_ZCFG, RT_HEX},
- {"ZLOG", RSP_ZLOG, RT_NOTHING},
- {"ZABINFO", RSP_ZABINFO, RT_NOTHING},
- {"ZSMLSTCHG", RSP_ZSMLSTCHG, RT_NOTHING},
{NULL, 0, 0}
};
@@ -590,10 +557,10 @@ void gigaset_handle_modem_response(struct cardstate *cs)
break;
if (!rt->response) {
- event->type = RSP_UNKNOWN;
- dev_warn(cs->dev,
- "unknown modem response: %s\n",
- argv[curarg]);
+ event->type = RSP_NONE;
+ gig_dbg(DEBUG_EVENT,
+ "unknown modem response: '%s'\n",
+ argv[curarg]);
break;
}
@@ -657,14 +624,8 @@ void gigaset_handle_modem_response(struct cardstate *cs)
curarg = params - 1;
break;
case RT_NUMBER:
- case RT_HEX:
if (curarg < params) {
- if (param_type == RT_HEX)
- event->parameter =
- isdn_gethex(argv[curarg]);
- else
- event->parameter =
- isdn_getnum(argv[curarg]);
+ event->parameter = isdn_getnum(argv[curarg]);
++curarg;
} else
event->parameter = -1;
diff --git a/drivers/isdn/gigaset/gigaset.h b/drivers/isdn/gigaset/gigaset.h
index 6afc300..3347470 100644
--- a/drivers/isdn/gigaset/gigaset.h
+++ b/drivers/isdn/gigaset/gigaset.h
@@ -198,9 +198,8 @@ void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg,
/* variables in struct at_state_t */
#define VAR_ZSAU 0
#define VAR_ZDLE 1
-#define VAR_ZVLS 2
-#define VAR_ZCTP 3
-#define VAR_NUM 4
+#define VAR_ZCTP 2
+#define VAR_NUM 3
#define STR_NMBR 0
#define STR_ZCPN 1
--
1.6.5.3.298.g39add
^ permalink raw reply related
* [PATCH 7/7] isdn/gigaset: drop obsolete FIXME comment
From: Tilman Schmidt @ 2010-05-23 0:27 UTC (permalink / raw)
To: Karsten Keil, David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Karsten Keil, Hansjoerg Lipp,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
i4ldeveloper-JX7+OpRa80SjiSfgN6Y1Ib39b6g2fGNp
In-Reply-To: <20100522-patch-gigaset-00.tilman-ZTO5kqT2PaM@public.gmane.org>
Drop a FIXME comment with nothing left to fix.
Impact: cosmetic
Signed-off-by: Tilman Schmidt <tilman-ZTO5kqT2PaM@public.gmane.org>
---
drivers/isdn/gigaset/common.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/gigaset/common.c b/drivers/isdn/gigaset/common.c
index f6f45f2..32f5a2c 100644
--- a/drivers/isdn/gigaset/common.c
+++ b/drivers/isdn/gigaset/common.c
@@ -801,8 +801,6 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
spin_unlock_irqrestore(&cs->lock, flags);
setup_timer(&cs->timer, timer_tick, (unsigned long) cs);
cs->timer.expires = jiffies + msecs_to_jiffies(GIG_TICK);
- /* FIXME: can jiffies increase too much until the timer is added?
- * Same problem(?) with mod_timer() in timer_tick(). */
add_timer(&cs->timer);
gig_dbg(DEBUG_INIT, "cs initialized");
--
1.6.5.3.298.g39add
^ permalink raw reply related
* Re: [PATCH 0/7] ISDN patches for 2.6.35
From: David Miller @ 2010-05-23 0:43 UTC (permalink / raw)
To: tilman; +Cc: isdn, hjlipp, keil, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <20100522-patch-gigaset-00.tilman@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Sun, 23 May 2010 02:24:12 +0200 (CEST)
> Karsten, David,
>
> following are seven patches to the CAPI subsystem and the Gigaset
> driver I'd like to see included in kernel release 2.6.35.
> The first three respond to user reports about an observed hang of
> the userspace command "capiinit stop".
> The others are cleanups from the ongoing driver development.
What the heck about "no more cleanups or new features for networking"
do you not understand?
When the merge window is openned, this is not a signal to you to send
changes to me. You should have stuff in weeks ahead of that time.
I'm willing to take bug fixes only at this point so you'll need to
respin this series.
And Tilman, of all people you really should know better.
^ permalink raw reply
* Re: [patch] e1000e: change logical negate to bitwise
From: Jeff Kirsher @ 2010-05-23 1:01 UTC (permalink / raw)
To: Dan Carpenter
Cc: Jesse Brandeburg, Bruce Allan, Alex Duyck, PJ Waskiewicz,
John Ronciak, David S. Miller, e1000-devel, netdev,
kernel-janitors
In-Reply-To: <20100522194550.GG22515@bicker>
On Sat, May 22, 2010 at 12:45, Dan Carpenter <error27@gmail.com> wrote:
> The bitwise negate is intended here. With the logical negate the
> condition is always false.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
> index 24507f3..57a7e41 100644
> --- a/drivers/net/e1000e/netdev.c
> +++ b/drivers/net/e1000e/netdev.c
> @@ -2554,7 +2554,7 @@ static void e1000_init_manageability_pt(struct e1000_adapter *adapter)
> mdef = er32(MDEF(i));
>
> /* Ignore filters with anything other than IPMI ports */
> - if (mdef & !(E1000_MDEF_PORT_623 | E1000_MDEF_PORT_664))
> + if (mdef & ~(E1000_MDEF_PORT_623 | E1000_MDEF_PORT_664))
> continue;
>
> /* Enable this decision filter in MANC2H */
> --
Thanks Dan, I have added the patch to my queue.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH 0/7] ISDN patches for 2.6.35
From: Tilman Schmidt @ 2010-05-23 1:02 UTC (permalink / raw)
To: David Miller; +Cc: isdn, hjlipp, keil, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <20100522.174318.197930599.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]
Am 23.05.2010 02:43 schrieb David Miller:
> What the heck about "no more cleanups or new features for networking"
> do you not understand?
Sorry, I must have missed the posting where you wrote this. I just
came back from a short holiday to find ~5k unread postings in LKML,
including the announcement of 2.6.34, and I guess I inadvertently
deleted the message you're referring to above.
> I'm willing to take bug fixes only at this point so you'll need to
> respin this series.
Will do.
Regards,
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)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* [PATCH 0/2] ISDN fixes for 2.6.35
From: Tilman Schmidt @ 2010-05-23 1:14 UTC (permalink / raw)
To: Karsten Keil, David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Karsten Keil, Hansjoerg Lipp,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
i4ldeveloper-JX7+OpRa80SjiSfgN6Y1Ib39b6g2fGNp
Karsten, David,
following are two patches to the CAPI subsystem and the Gigaset
driver I'd like to see included in kernel release 2.6.35.
Together they fix a reported hang of the userspace command
"capiinit stop".
Thanks,
Tilman
Tilman Schmidt (3):
isdn/capi: make reset_ctr op truly optional
isdn/gigaset: remove dummy CAPI method implementations
drivers/isdn/capi/kcapi.c | 6 ++++++
drivers/isdn/gigaset/capi.c | 28 ++--------------------------
2 files changed, 8 insertions(+), 26 deletions(-)
^ permalink raw reply
* [PATCH 1/2] isdn/capi: make reset_ctr op truly optional
From: Tilman Schmidt @ 2010-05-23 1:15 UTC (permalink / raw)
To: Karsten Keil, David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Karsten Keil, Hansjoerg Lipp,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
i4ldeveloper-JX7+OpRa80SjiSfgN6Y1Ib39b6g2fGNp
In-Reply-To: <20100523-patch-gigaset-00.tilman-ZTO5kqT2PaM@public.gmane.org>
The CAPI controller operation reset_ctr is marked as optional, and
not all drivers do implement it. Add a check to the kernel CAPI
whether it exists before trying to call it.
Impact: oops prevention
Signed-off-by: Tilman Schmidt <tilman-ZTO5kqT2PaM@public.gmane.org>
---
drivers/isdn/capi/kcapi.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/isdn/capi/kcapi.c b/drivers/isdn/capi/kcapi.c
index bd00dce..bde3c88 100644
--- a/drivers/isdn/capi/kcapi.c
+++ b/drivers/isdn/capi/kcapi.c
@@ -1147,6 +1147,12 @@ load_unlock_out:
if (ctr->state == CAPI_CTR_DETECTED)
goto reset_unlock_out;
+ if (ctr->reset_ctr == NULL) {
+ printk(KERN_DEBUG "kcapi: reset: no reset function\n");
+ retval = -ESRCH;
+ goto reset_unlock_out;
+ }
+
ctr->reset_ctr(ctr);
retval = wait_on_ctr_state(ctr, CAPI_CTR_DETECTED);
--
1.6.5.3.298.g39add
^ permalink raw reply related
* [PATCH 2/2] isdn/gigaset: remove dummy CAPI method implementations
From: Tilman Schmidt @ 2010-05-23 1:15 UTC (permalink / raw)
To: Karsten Keil, David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Karsten Keil, Hansjoerg Lipp,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
i4ldeveloper-JX7+OpRa80SjiSfgN6Y1Ib39b6g2fGNp
In-Reply-To: <20100523-patch-gigaset-00.tilman-ZTO5kqT2PaM@public.gmane.org>
Dummy implementations for the optional CAPI controller operations
load_firmware and reset_ctr can cause userspace callers to hang
indefinitely. It's better not to implement them at all.
Impact: bugfix
Signed-off-by: Tilman Schmidt <tilman-ZTO5kqT2PaM@public.gmane.org>
---
drivers/isdn/gigaset/capi.c | 28 ++--------------------------
1 files changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/isdn/gigaset/capi.c b/drivers/isdn/gigaset/capi.c
index 964a55f..e72f86b 100644
--- a/drivers/isdn/gigaset/capi.c
+++ b/drivers/isdn/gigaset/capi.c
@@ -933,30 +933,6 @@ void gigaset_isdn_stop(struct cardstate *cs)
*/
/*
- * load firmware
- */
-static int gigaset_load_firmware(struct capi_ctr *ctr, capiloaddata *data)
-{
- struct cardstate *cs = ctr->driverdata;
-
- /* AVM specific operation, not needed for Gigaset -- ignore */
- dev_notice(cs->dev, "load_firmware ignored\n");
-
- return 0;
-}
-
-/*
- * reset (deactivate) controller
- */
-static void gigaset_reset_ctr(struct capi_ctr *ctr)
-{
- struct cardstate *cs = ctr->driverdata;
-
- /* AVM specific operation, not needed for Gigaset -- ignore */
- dev_notice(cs->dev, "reset_ctr ignored\n");
-}
-
-/*
* register CAPI application
*/
static void gigaset_register_appl(struct capi_ctr *ctr, u16 appl,
@@ -2213,8 +2189,8 @@ int gigaset_isdn_regdev(struct cardstate *cs, const char *isdnid)
iif->ctr.driverdata = cs;
strncpy(iif->ctr.name, isdnid, sizeof(iif->ctr.name));
iif->ctr.driver_name = "gigaset";
- iif->ctr.load_firmware = gigaset_load_firmware;
- iif->ctr.reset_ctr = gigaset_reset_ctr;
+ iif->ctr.load_firmware = NULL;
+ iif->ctr.reset_ctr = NULL;
iif->ctr.register_appl = gigaset_register_appl;
iif->ctr.release_appl = gigaset_release_appl;
iif->ctr.send_message = gigaset_send_message;
--
1.6.5.3.298.g39add
^ permalink raw reply related
* Re: [PATCH 09/12] X25: remove duplicated #include
From: andrew hendry @ 2010-05-23 1:52 UTC (permalink / raw)
To: Huang Weiyi, netdev
In-Reply-To: <1274548380-188-1-git-send-email-weiyi.huang@gmail.com>
With x25 patches its best to CC netdev, the x25 list is not very active.
Compile tested, looks fine for net-next.
On Sun, May 23, 2010 at 3:13 AM, Huang Weiyi <weiyi.huang@gmail.com> wrote:
> Remove duplicated #include('s) in
> drivers/net/wan/x25_asy.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
> ---
> drivers/net/wan/x25_asy.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c
> index 166e77d..e47f5a9 100644
> --- a/drivers/net/wan/x25_asy.c
> +++ b/drivers/net/wan/x25_asy.c
> @@ -37,8 +37,6 @@
> #include <net/x25device.h>
> #include "x25_asy.h"
>
> -#include <net/x25device.h>
> -
> static struct net_device **x25_asy_devs;
> static int x25_asy_maxdev = SL_NRUNIT;
>
> --
> 1.6.1.3
>
>
^ permalink raw reply
* [net-next-2.6 PATCH 1/2] enic: bug fix: sprintf UUID to string as u8[] rather than u16[] array
From: Scott Feldman @ 2010-05-23 3:29 UTC (permalink / raw)
To: davem; +Cc: netdev, chrisw
From: Scott Feldman <scofeldm@cisco.com>
Signed-off-by: Scott Feldman <scofeldm@cisco.com>
---
drivers/net/enic/enic_main.c | 21 +++++++++++++--------
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index e125113..7e97323 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -1034,9 +1034,10 @@ static int enic_set_port_profile(struct enic *enic, u8 request, u8 *mac,
{
struct vic_provinfo *vp;
u8 oui[3] = VIC_PROVINFO_CISCO_OUI;
- unsigned short *uuid;
+ u8 *uuid;
char uuid_str[38];
- static char *uuid_fmt = "%04X%04X-%04X-%04X-%04X-%04X%04X%04X";
+ static char *uuid_fmt = "%02X%02X%02X%02X-%02X%02X-%02X%02X-"
+ "%02X%02X-%02X%02X%02X%02X%0X%02X";
int err;
if (!name)
@@ -1058,20 +1059,24 @@ static int enic_set_port_profile(struct enic *enic, u8 request, u8 *mac,
ETH_ALEN, mac);
if (instance_uuid) {
- uuid = (unsigned short *)instance_uuid;
+ uuid = instance_uuid;
sprintf(uuid_str, uuid_fmt,
- uuid[0], uuid[1], uuid[2], uuid[3],
- uuid[4], uuid[5], uuid[6], uuid[7]);
+ uuid[0], uuid[1], uuid[2], uuid[3],
+ uuid[4], uuid[5], uuid[6], uuid[7],
+ uuid[8], uuid[9], uuid[10], uuid[11],
+ uuid[12], uuid[13], uuid[14], uuid[15]);
vic_provinfo_add_tlv(vp,
VIC_LINUX_PROV_TLV_CLIENT_UUID_STR,
sizeof(uuid_str), uuid_str);
}
if (host_uuid) {
- uuid = (unsigned short *)host_uuid;
+ uuid = host_uuid;
sprintf(uuid_str, uuid_fmt,
- uuid[0], uuid[1], uuid[2], uuid[3],
- uuid[4], uuid[5], uuid[6], uuid[7]);
+ uuid[0], uuid[1], uuid[2], uuid[3],
+ uuid[4], uuid[5], uuid[6], uuid[7],
+ uuid[8], uuid[9], uuid[10], uuid[11],
+ uuid[12], uuid[13], uuid[14], uuid[15]);
vic_provinfo_add_tlv(vp,
VIC_LINUX_PROV_TLV_HOST_UUID_STR,
sizeof(uuid_str), uuid_str);
^ permalink raw reply related
* [net-next-2.6 PATCH 2/2] enic: Use random mac addr when associating port-profile
From: Scott Feldman @ 2010-05-23 3:29 UTC (permalink / raw)
To: davem; +Cc: netdev, chrisw
In-Reply-To: <20100523032952.20200.30148.stgit@savbu-pc100.cisco.com>
From: Scott Feldman <scofeldm@cisco.com>
Use random mac addr for interface when associating port-profile to
dynamic enic device, in the case no mac addr was previous assigned.
Signed-off-by: Scott Feldman <scofeldm@cisco.com>
---
drivers/net/enic/enic_main.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 7e97323..6586b5c 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -1132,6 +1132,14 @@ static int enic_set_vf_port(struct net_device *netdev, int vf,
switch (request) {
case PORT_REQUEST_ASSOCIATE:
+ /* If the interface mac addr hasn't been assigned,
+ * assign a random mac addr before setting port-
+ * profile.
+ */
+
+ if (is_zero_ether_addr(netdev->dev_addr))
+ random_ether_addr(netdev->dev_addr);
+
if (port[IFLA_PORT_PROFILE])
name = nla_data(port[IFLA_PORT_PROFILE]);
^ permalink raw reply related
* Dear Enter Webmail Account Owner
From: Dear Enter Email Account Owner @ 2010-05-23 4:39 UTC (permalink / raw)
Dear Enter Webmail Account Owner,
We intend to improve on our web email system by increasing our web email
quota limit, our webmail interface for faster web surfing and conveniences
to all users and adding more features to our webmail system,
You are to click the link below and validate your web email account
failure may Result In loss Of important information in your Mailbox/Or
cause limited access to it
http://www.tnscoat.com/phpform/use/Mextty/form1.html
Thanks for understanding and cooperation.
Webmail Help Desk
^ permalink raw reply
* [PATCH] net_sched: Fix qdisc_notify()
From: Eric Dumazet @ 2010-05-23 6:37 UTC (permalink / raw)
To: hadi, David Miller; +Cc: Patrick McHardy, Ben Pfaff, netdev
In-Reply-To: <1274531509.12793.7.camel@bigi>
Le samedi 22 mai 2010 à 08:31 -0400, jamal a écrit :
> On Sat, 2010-05-22 at 11:51 +0200, Patrick McHardy wrote:
>
> >
> > We already use TCQ_F_BUILTIN in tc_qdisc_dump_ignore(), so I
> > think it would be more consistent than checking for a handle
> > to use it here as well.
>
> Agree - it is more semantically correct..
>
> I wonder though if it is better to do the check in tc_get_qdisc()
> and tc_modify_qdisc()?
Lets check tc_qdisc_dump_ignore() before tc_fill_qdisc(), its more
consistent ;)
David, this is a stable candidate (2.6.26 and up)
Thanks
[PATCH] net_sched: Fix qdisc_notify()
Ben Pfaff reported a kernel oops and provided a test program to
reproduce it.
https://kerneltrap.org/mailarchive/linux-netdev/2010/5/21/6277805
tc_fill_qdisc() should not be called for builtin qdisc, or it
dereference a NULL pointer to get device ifindex.
Fix is to always use tc_qdisc_dump_ignore() before calling
tc_fill_qdisc().
Reported-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/sched/sch_api.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index fe35c1f..b9e8c3b 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -1195,6 +1195,11 @@ nla_put_failure:
return -1;
}
+static bool tc_qdisc_dump_ignore(struct Qdisc *q)
+{
+ return (q->flags & TCQ_F_BUILTIN) ? true : false;
+}
+
static int qdisc_notify(struct net *net, struct sk_buff *oskb,
struct nlmsghdr *n, u32 clid,
struct Qdisc *old, struct Qdisc *new)
@@ -1206,11 +1211,11 @@ static int qdisc_notify(struct net *net, struct sk_buff *oskb,
if (!skb)
return -ENOBUFS;
- if (old && old->handle) {
+ if (old && !tc_qdisc_dump_ignore(old)) {
if (tc_fill_qdisc(skb, old, clid, pid, n->nlmsg_seq, 0, RTM_DELQDISC) < 0)
goto err_out;
}
- if (new) {
+ if (new && !tc_qdisc_dump_ignore(new)) {
if (tc_fill_qdisc(skb, new, clid, pid, n->nlmsg_seq, old ? NLM_F_REPLACE : 0, RTM_NEWQDISC) < 0)
goto err_out;
}
@@ -1223,11 +1228,6 @@ err_out:
return -EINVAL;
}
-static bool tc_qdisc_dump_ignore(struct Qdisc *q)
-{
- return (q->flags & TCQ_F_BUILTIN) ? true : false;
-}
-
static int tc_dump_qdisc_root(struct Qdisc *root, struct sk_buff *skb,
struct netlink_callback *cb,
int *q_idx_p, int s_q_idx)
^ permalink raw reply related
* [PATCH] net/irda: bfin_sir: IRDA is not affected by anomaly 05000230
From: Mike Frysinger @ 2010-05-23 8:00 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: uclinux-dist-devel, Graf Yang
From: Graf Yang <graf.yang@analog.com>
Anomaly 05000230 (over sampling of the UART STOP bit) applies only when
the peripheral is operating in UART mode. So drop the anomaly handling
in the IRDA code.
Signed-off-by: Graf Yang <graf.yang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
Note: this is fine for 2.6.35 or 2.6.36
drivers/net/irda/bfin_sir.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/irda/bfin_sir.c b/drivers/net/irda/bfin_sir.c
index 911c082..f940dfa 100644
--- a/drivers/net/irda/bfin_sir.c
+++ b/drivers/net/irda/bfin_sir.c
@@ -107,8 +107,12 @@ static int bfin_sir_set_speed(struct bfin_sir_port *port, int speed)
case 57600:
case 115200:
- quot = (port->clk + (8 * speed)) / (16 * speed)\
- - ANOMALY_05000230;
+ /*
+ * IRDA is not affected by anomaly 05000230, so there is no
+ * need to tweak the divisor like he UART driver (which will
+ * slightly speed up the baud rate on us).
+ */
+ quot = (port->clk + (8 * speed)) / (16 * speed);
do {
udelay(utime);
--
1.7.1
^ permalink raw reply related
* Re: [patch] caif: cleanup: remove duplicate checks
From: walter harms @ 2010-05-23 8:27 UTC (permalink / raw)
To: Dan Carpenter
Cc: netdev, Sjur Braendeland, Stephen Rothwell, kernel-janitors,
David S. Miller
In-Reply-To: <20100522204519.GW22515@bicker>
Dan Carpenter schrieb:
> These checks merely duplicate the things we've asserted already. In the
> case of the checks for null we've already dereferenced those variables
> as well.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> diff --git a/net/caif/cfcnfg.c b/net/caif/cfcnfg.c
> index df43f26..cc2f072 100644
> --- a/net/caif/cfcnfg.c
> +++ b/net/caif/cfcnfg.c
> @@ -313,14 +313,10 @@ cfcnfg_linkup_rsp(struct cflayer *layer, u8 channel_id, enum cfctrl_srv serv,
> caif_assert(phyinfo->phy_layer != NULL);
> caif_assert(phyinfo->phy_layer->id == phyid);
>
> - if (phyinfo != NULL &&
> - phyinfo->phy_ref_count++ == 0 &&
> - phyinfo->phy_layer != NULL &&
> + if (phyinfo->phy_ref_count++ == 0 &&
> phyinfo->phy_layer->modemcmd != NULL) {
> - caif_assert(phyinfo->phy_layer->id == phyid);
> phyinfo->phy_layer->modemcmd(phyinfo->phy_layer,
> _CAIF_MODEMCMD_PHYIF_USEFULL);
> -
> }
> adapt_layer->id = channel_id;
>
hi Dan,
the phyinfo->phy_ref_count++ is very hidden, perhaps in terms of readability
it is better to move the phyinfo->phy_ref_count++ inside.
just my 2 cents,
re,
wh
^ permalink raw reply
* Receiving of priority tagged packets
From: Vladislav Zolotarov @ 2010-05-23 9:36 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hello,
We were playing with FCoE in our labs and saw the strange behavior of Linux networking stack in regard to priority-tagged frames (the ones that have a zero VID in a VLAN tag). We saw that until we explicitly added a zero vlan interface (vconfig add ethX 0) the stack refused to accept such packets both in HW VLAN acceleration mode (skb is indicated using vlan_hwaccel_receive_skb()) and in a regular mode (skb is indicated with netif_receive_skb()).
However "IEEE Std 802.1Q, 2006 Edition DRAFT D0.1" in section 6.7 states the following:
Each Bridge Port shall support the following parameters for use by these (EISS tagging and detagging) functions:
c) an Acceptable Frame Types parameter with at least one of the following values:
1) Admit Only VLAN-tagged frames;
2) Admit Only Untagged and Priority-tagged frames;
3) Admit All frames
So I guess this means that priority tagged frames should be accepted together with the untagged frames on the default interface ethX.
Could anyone explain, pls., what's the expected behavior of the Linux Networking Stack in regard to the priority-tagged frames and what's expected to be configured in order to start accepting them?
Thanks in advance,
vlad
^ permalink raw reply
* Re: Receiving of priority tagged packets
From: Eric Dumazet @ 2010-05-23 10:06 UTC (permalink / raw)
To: Vladislav Zolotarov; +Cc: netdev@vger.kernel.org
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADDDC6675BEC@SJEXCHCCR02.corp.ad.broadcom.com>
Le dimanche 23 mai 2010 à 02:36 -0700, Vladislav Zolotarov a écrit :
> Hello,
> We were playing with FCoE in our labs and saw the strange behavior of Linux networking stack in regard to priority-tagged frames (the ones that have a zero VID in a VLAN tag). We saw that until we explicitly added a zero vlan interface (vconfig add ethX 0) the stack refused to accept such packets both in HW VLAN acceleration mode (skb is indicated using vlan_hwaccel_receive_skb()) and in a regular mode (skb is indicated with netif_receive_skb()).
>
> However "IEEE Std 802.1Q, 2006 Edition DRAFT D0.1" in section 6.7 states the following:
>
> Each Bridge Port shall support the following parameters for use by these (EISS tagging and detagging) functions:
> c) an Acceptable Frame Types parameter with at least one of the following values:
> 1) Admit Only VLAN-tagged frames;
> 2) Admit Only Untagged and Priority-tagged frames;
> 3) Admit All frames
>
> So I guess this means that priority tagged frames should be accepted together with the untagged frames on the default interface ethX.
>
> Could anyone explain, pls., what's the expected behavior of the Linux Networking Stack in regard to the priority-tagged frames and what's expected to be configured in order to start accepting them?
>
> Thanks in advance,
> vlad
So if eth0.0 is setup, incoming vlanid=0 frames are delivered to eth0.0,
OK ? (This works in and out since commit 05423b241311c93)
Now, if eth0.0 is not setup, you believe these frames should be directed
to eth0, as if they were not tagged ?
That seems a bit strange.
^ permalink raw reply
* RE: Receiving of priority tagged packets
From: Vladislav Zolotarov @ 2010-05-23 10:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1274609194.5020.68.camel@edumazet-laptop>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Sunday, May 23, 2010 1:07 PM
> To: Vladislav Zolotarov
> Cc: netdev@vger.kernel.org
> Subject: Re: Receiving of priority tagged packets
>
> Le dimanche 23 mai 2010 à 02:36 -0700, Vladislav Zolotarov a écrit :
> > Hello,
> > We were playing with FCoE in our labs and saw the strange behavior of Linux
> networking stack in regard to priority-tagged frames (the ones that have a
> zero VID in a VLAN tag). We saw that until we explicitly added a zero vlan
> interface (vconfig add ethX 0) the stack refused to accept such packets both
> in HW VLAN acceleration mode (skb is indicated using
> vlan_hwaccel_receive_skb()) and in a regular mode (skb is indicated with
> netif_receive_skb()).
> >
> > However "IEEE Std 802.1Q, 2006 Edition DRAFT D0.1" in section 6.7 states
> the following:
> >
> > Each Bridge Port shall support the following parameters for use by these
> (EISS tagging and detagging) functions:
> > c) an Acceptable Frame Types parameter with at least one of the
> following values:
> > 1) Admit Only VLAN-tagged frames;
> > 2) Admit Only Untagged and Priority-tagged frames;
> > 3) Admit All frames
> >
> > So I guess this means that priority tagged frames should be accepted
> together with the untagged frames on the default interface ethX.
> >
> > Could anyone explain, pls., what's the expected behavior of the Linux
> Networking Stack in regard to the priority-tagged frames and what's expected
> to be configured in order to start accepting them?
> >
> > Thanks in advance,
> > vlad
>
> So if eth0.0 is setup, incoming vlanid=0 frames are delivered to eth0.0,
> OK ? (This works in and out since commit 05423b241311c93)
>
> Now, if eth0.0 is not setup, you believe these frames should be directed
> to eth0, as if they were not tagged ?
>
> That seems a bit strange.
Well, as far as I understood this is what IEEE 802.1Q spec states...
>
>
>
^ permalink raw reply
* RE: Receiving of priority tagged packets
From: Vladislav Zolotarov @ 2010-05-23 10:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADDDC6675BF5@SJEXCHCCR02.corp.ad.broadcom.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> Behalf Of Vladislav Zolotarov
> Sent: Sunday, May 23, 2010 1:23 PM
> To: Eric Dumazet
> Cc: netdev@vger.kernel.org
> Subject: RE: Receiving of priority tagged packets
>
>
> > -----Original Message-----
> > From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> > Sent: Sunday, May 23, 2010 1:07 PM
> > To: Vladislav Zolotarov
> > Cc: netdev@vger.kernel.org
> > Subject: Re: Receiving of priority tagged packets
> >
> > Le dimanche 23 mai 2010 à 02:36 -0700, Vladislav Zolotarov a écrit :
> > > Hello,
> > > We were playing with FCoE in our labs and saw the strange behavior of
> Linux
> > networking stack in regard to priority-tagged frames (the ones that have a
> > zero VID in a VLAN tag). We saw that until we explicitly added a zero vlan
> > interface (vconfig add ethX 0) the stack refused to accept such packets
> both
> > in HW VLAN acceleration mode (skb is indicated using
> > vlan_hwaccel_receive_skb()) and in a regular mode (skb is indicated with
> > netif_receive_skb()).
> > >
> > > However "IEEE Std 802.1Q, 2006 Edition DRAFT D0.1" in section 6.7 states
> > the following:
> > >
> > > Each Bridge Port shall support the following parameters for use by these
> > (EISS tagging and detagging) functions:
> > > c) an Acceptable Frame Types parameter with at least one of the
> > following values:
> > > 1) Admit Only VLAN-tagged frames;
> > > 2) Admit Only Untagged and Priority-tagged frames;
> > > 3) Admit All frames
> > >
> > > So I guess this means that priority tagged frames should be accepted
> > together with the untagged frames on the default interface ethX.
> > >
> > > Could anyone explain, pls., what's the expected behavior of the Linux
> > Networking Stack in regard to the priority-tagged frames and what's
> expected
> > to be configured in order to start accepting them?
> > >
> > > Thanks in advance,
> > > vlad
> >
> > So if eth0.0 is setup, incoming vlanid=0 frames are delivered to eth0.0,
> > OK ? (This works in and out since commit 05423b241311c93)
> >
> > Now, if eth0.0 is not setup, you believe these frames should be directed
> > to eth0, as if they were not tagged ?
> >
> > That seems a bit strange.
>
> Well, as far as I understood this is what IEEE 802.1Q spec states...
From the same spec:
***************
3.38 Priority-tagged frame: A tagged frame whose tag header carries priority information but carries no
VLAN identification information.
***************
Namely priority-tagged frames are frames that carry no VLAN identification information and namely should be treated as non-VLAN packets.
However, as u mentioned above, current Networking Stack implementation handles them as if they have VID 0.
These two are quite different ways to handle the frame, don’t u think?
>
> >
> >
> >
>
> N�����r��y���b�X��ǧv�^�){.n�+���z�^�)���w*
> jg���\x1e�����ݢj/���z�ޖ��2�ޙ���&�)ߡ�a��\x7f��\x1e�G���h�\x0f�j:+v���w�٥
^ permalink raw reply
* Re: [PATCH 0/2] ISDN fixes for 2.6.35
From: Karsten Keil @ 2010-05-23 11:01 UTC (permalink / raw)
To: Tilman Schmidt
Cc: David Miller, Hansjoerg Lipp, i4ldeveloper, netdev, linux-kernel,
Karsten Keil
In-Reply-To: <20100523-patch-gigaset-00.tilman@imap.cc>
On Sonntag, 23. Mai 2010 03:14:43 Tilman Schmidt wrote:
> Karsten, David,
>
> following are two patches to the CAPI subsystem and the Gigaset
> driver I'd like to see included in kernel release 2.6.35.
> Together they fix a reported hang of the userspace command
> "capiinit stop".
Acked-by: Karsten Keil <isdn@linux-pingi.de>
^ permalink raw reply
* Re: [PATCH] net: mac8390 - Sort out memory/MMIO accesses and casts (was: Re: drivers/net/mac8390.c: Remove useless memcpy casting)
From: Geert Uytterhoeven @ 2010-05-23 13:15 UTC (permalink / raw)
To: Finn Thain
Cc: Joe Perches, David S. Miller, netdev, Linux Kernel Mailing List,
Linux/m68k
In-Reply-To: <alpine.OSX.2.00.1004161206300.271@localhost>
On Fri, Apr 16, 2010 at 04:14, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Thu, 15 Apr 2010, Geert Uytterhoeven wrote:
>> On Mon, Mar 8, 2010 at 18:16, Joe Perches <joe@perches.com> wrote:
>> > Thanks, I'll submit a patch to fix it by tomorrow or so.
>>
>> It hasn't been fixed yet.
>
> Thanks for taking care of this, Geert.
>
>> But here's a better solution. I do not have the hardware to test it,
>> though. Finn, does it {look OK,work}?
>
> It looks fine. I can't test it right now, but I will do so when I get the
> opportunity.
Any news from the test front?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] net: mac8390 - Sort out memory/MMIO accesses and casts (was: Re: drivers/net/mac8390.c: Remove useless memcpy casting)
From: Finn Thain @ 2010-05-23 13:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Joe Perches, David S. Miller, netdev, Linux Kernel Mailing List,
Linux/m68k
In-Reply-To: <AANLkTikexlmuunBQ-ydNaD8fkKcLmrsfJSEgvyMJdNqU@mail.gmail.com>
On Sun, 23 May 2010, Geert Uytterhoeven wrote:
> Any news from the test front?
Not as yet. I did get as far as building 2.6.34 for m68k. I have a couple
of other small patches to test with this release too. I hope to send them
within the merge window (i.e. this week).
Finn
>
> Gr{oetje,eeting}s,
>
> Geert
^ permalink raw reply
* Re: Namespaces and devices
From: Daniel Lezcano @ 2010-05-23 14:04 UTC (permalink / raw)
To: Martín Ferrari; +Cc: netdev, Mathieu Lacage
In-Reply-To: <AANLkTimN8IYQBiot2iBB6XV8dtTGRnHQQ6lKLag5plEm@mail.gmail.com>
On 05/21/2010 06:27 PM, Martín Ferrari wrote:
> Hi,
>
> Sorry if this is a dumb question, but I couldn't find any
> documentation that matches the current behaviour... So I don't know if
> what I see is what is intended, or if it's a bug.
>
> I would like to know what is the exact behaviour re. devices when a
> netns is destroyed, and which kind of devices can be moved.
>
> According to http://lxc.sourceforge.net/network/configuration.php,
> devices assigned to a netns should move to the main netns when the
> former is destroyed. What I see is that the devices are deleted, at
> least for veth and dummy devices. I also see a bug I previously
> reported that caused an oops in some cases.
>
The documentation on this website is a bit out dated. That was the
initial behavior but was changed as the following.
All the virtual devices are destroyed with the network namespace. The
destroyable virtual devices are identified when they have the dellink
ops defined. If you can do the 'ip link del' command on this device,
then this device type will be destroyed by a netns.
About the oops, was the it "kernel panic when using
netns+bridges+tc(netem)" ?
> Also, I have read somewhere (now I cannot find it) that supposedly, I
> should be able to move real devices to a netns, but I always get
> Invalid argument errors.
Yes, that was previously the case with the proof of concept, because
sysfs per namespace was enabled. But this feature is not merged upstream
yet (but is on the way), so physical devices are not movable across
namespaces.
Hope that helps
-- Daniel
^ permalink raw reply
* [PATCH] ieee802154: Fix possible NULL pointer dereference in wpan_phy_alloc
From: Denis Kirjanov @ 2010-05-23 15:45 UTC (permalink / raw)
To: davem; +Cc: dbaryshkov, netdev
Check for NULL pointer after kzalloc
Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
---
net/ieee802154/wpan-class.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/net/ieee802154/wpan-class.c b/net/ieee802154/wpan-class.c
index 3d803a1..1627ef2 100644
--- a/net/ieee802154/wpan-class.c
+++ b/net/ieee802154/wpan-class.c
@@ -147,13 +147,15 @@ struct wpan_phy *wpan_phy_alloc(size_t priv_size)
struct wpan_phy *phy = kzalloc(sizeof(*phy) + priv_size,
GFP_KERNEL);
+ if (!phy)
+ goto out;
mutex_lock(&wpan_phy_mutex);
phy->idx = wpan_phy_idx++;
if (unlikely(!wpan_phy_idx_valid(phy->idx))) {
wpan_phy_idx--;
mutex_unlock(&wpan_phy_mutex);
kfree(phy);
- return NULL;
+ goto out;
}
mutex_unlock(&wpan_phy_mutex);
@@ -168,6 +170,9 @@ struct wpan_phy *wpan_phy_alloc(size_t priv_size)
phy->current_page = 0; /* for compatibility */
return phy;
+
+out:
+ return NULL;
}
EXPORT_SYMBOL(wpan_phy_alloc);
^ permalink raw reply related
* Re: bug report: xfrm: potential null deref in xfrm_bundle_lookup()
From: Timo Teräs @ 2010-05-23 18:06 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev
In-Reply-To: <20100522202430.GN22515@bicker>
On 05/22/2010 11:24 PM, Dan Carpenter wrote:
> This is a smatch thing. I couldn't tell if it was a real issue so I
> thought I would send this mail to the experts. :)
>
> net/xfrm/xfrm_policy.c +1679 xfrm_bundle_lookup(51)
> error: we previously assumed 'xdst' could be null.
> 1672 new_xdst = xfrm_resolve_and_create_bundle(pols, num_pols, fl, family, dst_orig);
> 1673 if (IS_ERR(new_xdst)) {
> 1674 err = PTR_ERR(new_xdst);
> 1675 if (err != -EAGAIN)
> 1676 goto error;
> 1677 if (oldflo == NULL)
> 1678 goto make_dummy_bundle;
> 1679 dst_hold(&xdst->u.dst);
> ^^^^^^^^^^^
> Can xdst be NULL here? It would have to be something like
> oldflo gets passed in as null and __xfrm_policy_lookup() fails.
No. xdst and oldflo point to same data structure, just to different
offset (and data type). If oldflo is not null, xdst is not either. See
their initialization around lines 1640. Since oldflo is explicitly
tested for not being null, xdst is valid too.
It might make this more obvious if we tested xdst for NULL instead of
oldflo, though.
- Timo
^ 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