* Re: IP_FREEBIND and binding to in-use addr:ports
From: Andy Grover @ 2013-02-07 18:42 UTC (permalink / raw)
To: target-devel; +Cc: netdev
In-Reply-To: <5112F998.8050605@redhat.com>
On 02/06/2013 04:47 PM, Andy Grover wrote:
> OK, this is weird:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=908368
>
> It appears you can listen on the same address:port if you do it from a
> different iscsi target, or even a different tpg (so there are no
> configfs name collisions). I believe this is because we are setting
> IP_FREEBIND sockopt, so we can configure listening on iscsi portals (aka
> ip:port) before the IP is assigned.
>
> from ip(7):
> IP_FREEBIND (since Linux 2.4)
> If enabled, this boolean option allows binding to an IP address that is
> nonlocal or does not (yet) exist. This permits listening on a socket,
> without requiring the underlying network interface or the specified
> dynamic IP address to be up at the time that the application is trying
> to bind to it. This option is the per-socket equivalent of the
> ip_nonlocal_bind /proc interface described below.
>
> This doesn't say anything about if the address:port is already in use.
> Dave/netdev, should the network stack be returning an error when
> attempting to bind to an address:port already in use even if IP_FREEBIND
> is set, or should the caller be checking for this before trying to
> kernel_bind()?
>
> Or is something else the issue?
Looks like IP_FREEBIND doesn't make a difference. More shortly. -- Andy
^ permalink raw reply
* Re: [PATCH] tcp: sysctl to disable TCP simultaneous connect
From: Kees Cook @ 2013-02-07 18:44 UTC (permalink / raw)
To: Stephen Hemminger
Cc: LKML, Rob Landley, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet,
Neil Horman, Yuchung Cheng, Shan Wei, linux-doc@vger.kernel.org,
netdev, Willy Tarreau
In-Reply-To: <20130207103950.662698ea@nehalam.linuxnetplumber.net>
On Thu, Feb 7, 2013 at 10:39 AM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Thu, 7 Feb 2013 09:52:40 -0800
> Kees Cook <keescook@chromium.org> wrote:
>
>> This is based on Willy Tarreau's patch from 2008[1]. The goal is to
>> close a corner-case of TCP that isn't used and poses a small DoS risk.
>> For systems that do not want to take any risk at all, this is a desirable
>> configuration knob.
>>
>> It is possible for two clients to connect with crossed SYNs without
>> checking sequence numbers. As such, it might be possible to guess a source
>> port number to block a system from making connections to well-known
>> ports and IP addresses (e.g. auto-update checks) without requiring a
>> MiTM position.
>>
>
> This patch probably also breaks TCP STUNT that is used by some applications for NAT
> traversal.
The patch would not break it -- it defaults the sysctl to staying enabled.
If you mean the documentation should be updated, sure, that's easy to do.
David: I know you aren't a fan of this patch, but I'd like to try to
convince you. :) This leaves the feature enabled and add a toggle for
systems (like Chrome OS) that don't want to risk this DoS at all.
There are so very many other toggle, I don't see why this one would be
a problem to add.
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* Re: inaccurate packet scheduling
From: Jiri Pirko @ 2013-02-07 18:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: edumazet, netdev, kuznet, jhs
In-Reply-To: <1360259258.28557.57.camel@edumazet-glaptop>
Thu, Feb 07, 2013 at 06:47:38PM CET, eric.dumazet@gmail.com wrote:
>On Thu, 2013-02-07 at 18:39 +0100, Jiri Pirko wrote:
>> Thu, Feb 07, 2013 at 05:39:35PM CET, eric.dumazet@gmail.com wrote:
>> >On Thu, 2013-02-07 at 17:13 +0100, Jiri Pirko wrote:
>> >
>> >> >I tried kernel with this patch in. I also ported
>> >> >56b765b79e9a78dc7d3f8850ba5e5567205a3ecd to tbf. I'm getting always the
>> >> >similar numbers with iperf. There must be something else needed :/
>> >>
>> >> Any other ideas?
>> >
>> >You didn't post any patch, how can I comment on them ?
>>
>> Okay, sorry, here it is. But as I said, it did not help.
>>
>> Subject: [patch net-next RFC] tbf: improved accuracy at high rates
>>
>> Current TBF uses rate table computed by the "tc" userspace program,
>> which has the following issue:
>>
>> The rate table has 256 entries to map packet lengths to
>> token (time units). With TSO sized packets, the 256 entry granularity
>> leads to loss/gain of rate, making the token bucket inaccurate.
>>
>> Thus, instead of relying on rate table, this patch explicitly computes
>> the time and accounts for packet transmission times with nanosecond
>> granularity.
>>
>> This is a followup to 56b765b79e9a78dc7d3f8850ba5e5567205a3ecd
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> ---
>
>This patch doesnt change q->max_size
>
>So you hit this :
>
>if (qdisc_pkt_len(skb) > q->max_size)
> return qdisc_reshape_fail(skb, sch);
>
>I thought this point was already mentioned in my previous mails.
Right. I think I get it now. the RFC patch I posted enables possibility
to remove the max_size limitation, right?
I'm not really familliar in this area so I had to stare at the code for
a while.
>
>
>
^ permalink raw reply
* Dear Email User;
From: Administrator @ 2013-02-07 18:43 UTC (permalink / raw)
Dear Email User;
You have exceeded the limit of 23432 storage on your mailbox set by your
WEB IT-SERVICE Administrator, and you will be having problems in sending
and receiving mails Until You Re-Validate. You have to update by clicking
on the below link and fill out the information to validate your account.
Please Click the link Below or copy paste to your browser To Validate Your
Mailbox
http://andreadc.com/unetekaivalya/use/tuks/form1.html
Warning!!!
Failure to do this, will result in limited access to your mailbox. failure
to update your account within Three days of this update notification, your
account will be closed permanently.
^ permalink raw reply
* Re: [PATCH] tcp: sysctl to disable TCP simultaneous connect
From: H. Peter Anvin @ 2013-02-07 19:29 UTC (permalink / raw)
To: Kees Cook
Cc: Stephen Hemminger, LKML, Rob Landley, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, Eric Dumazet, Neil Horman, Yuchung Cheng,
Shan Wei, linux-doc@vger.kernel.org, netdev, Willy Tarreau
In-Reply-To: <CAGXu5jJiupzommJYPEYQnk-4i9FUKai0NcPnihLN-QpWV64jtQ@mail.gmail.com>
On 02/07/2013 10:44 AM, Kees Cook wrote:
>>
>> This patch probably also breaks TCP STUNT that is used by some applications for NAT
>> traversal.
>
> The patch would not break it -- it defaults the sysctl to staying enabled.
>
> If you mean the documentation should be updated, sure, that's easy to do.
>
> David: I know you aren't a fan of this patch, but I'd like to try to
> convince you. :) This leaves the feature enabled and add a toggle for
> systems (like Chrome OS) that don't want to risk this DoS at all.
> There are so very many other toggle, I don't see why this one would be
> a problem to add.
>
It is not just STUNT, but in NAT-less configurations behind stateful
firewalls (which is expected to be the norm for IPv6), TCP rendezvous
via crossed SYN is a very effective way to establish peer-to-peer
connections.
-hpa
^ permalink raw reply
* Re: [PATCH] tcp: sysctl to disable TCP simultaneous connect
From: David Miller @ 2013-02-07 19:29 UTC (permalink / raw)
To: keescook
Cc: stephen, linux-kernel, rob, kuznet, jmorris, yoshfuji, kaber,
edumazet, nhorman, ycheng, davidshan, linux-doc, netdev, w
In-Reply-To: <CAGXu5jJiupzommJYPEYQnk-4i9FUKai0NcPnihLN-QpWV64jtQ@mail.gmail.com>
From: Kees Cook <keescook@chromium.org>
Date: Thu, 7 Feb 2013 10:44:02 -0800
> David: I know you aren't a fan of this patch, but I'd like to try to
> convince you. :) This leaves the feature enabled and add a toggle for
> systems (like Chrome OS) that don't want to risk this DoS at all.
> There are so very many other toggle, I don't see why this one would be
> a problem to add.
We're not in the business of allowing the changing of the TCP state
machine behavior like this. Sorry.
^ permalink raw reply
* Null pointers linux3.8-rc6
From: syrine tlili @ 2013-02-07 19:32 UTC (permalink / raw)
To: netdev; +Cc: Jesper Juhl
Hi:
I would like to report some errors related to the usage of unchecked
null pointers.
I also suggest a set of patches to fix the detected errors.
Syrine
diff --git a/a/arch/x86/platform/efi/efi.c b/b/arch/x86/platform/efi/efi.c
index 77cf009..e64c3f4 100644
--- a/a/arch/x86/platform/efi/efi.c
+++ b/b/arch/x86/platform/efi/efi.c
@@ -924,6 +924,8 @@ void __init efi_enter_virtual_mode(void)
new_memmap = krealloc(new_memmap,
(count + 1) * memmap.desc_size,
GFP_KERNEL);
+ if (!new_memmap)
+ return -ENOMEM;
memcpy(new_memmap + (count * memmap.desc_size), md,
memmap.desc_size);
count++;
diff --git a/a/fs/ceph/mdsmap.c b/b/fs/ceph/mdsmap.c
index 73b7d44..d04ab8b 100644
--- a/a/fs/ceph/mdsmap.c
+++ b/b/fs/ceph/mdsmap.c
@@ -132,6 +132,8 @@ struct ceph_mdsmap *ceph_mdsmap_decode(void **p, void *end)
m->m_info[mds].export_targets =
kcalloc(num_export_targets, sizeof(u32),
GFP_NOFS);
+ if (m->m_info[mds].export_targets == NULL)
+ goto badmem;
for (j = 0; j < num_export_targets; j++)
m->m_info[mds].export_targets[j] =
ceph_decode_32(&pexport_targets);
diff --git a/a/drivers/isdn/mISDN/fsm.c b/b/drivers/isdn/mISDN/fsm.c
index 26477d4..07040b2 100644
--- a/a/drivers/isdn/mISDN/fsm.c
+++ b/b/drivers/isdn/mISDN/fsm.c
@@ -34,6 +34,8 @@ mISDN_FsmNew(struct Fsm *fsm,
fsm->jumpmatrix = kzalloc(sizeof(FSMFNPTR) * fsm->state_count *
fsm->event_count, GFP_KERNEL);
+ if (!fsm->jumpmatrix)
+ return -ENOMEM;
for (i = 0; i < fncount; i++)
if ((fnlist[i].state >= fsm->state_count) ||
diff --git a/a/drivers/scsi/megaraid.c b/b/drivers/scsi/megaraid.c
index 9504ec0..37b915f 100644
--- a/a/drivers/scsi/megaraid.c
+++ b/b/drivers/scsi/megaraid.c
@@ -4437,6 +4437,8 @@ mega_internal_command(adapter_t *adapter,
megacmd_t *mc, mega_passthru *pthru)
memset(scb, 0, sizeof(scb_t));
sdev = kzalloc(sizeof(struct scsi_device), GFP_KERNEL);
+ if (!sdev)
+ goto err_out;
scmd->device = sdev;
memset(adapter->int_cdb, 0, sizeof(adapter->int_cdb));
@@ -4482,6 +4484,11 @@ mega_internal_command(adapter_t *adapter,
megacmd_t *mc, mega_passthru *pthru)
scsi_free_command(GFP_KERNEL, scmd);
return rval;
+
+err_out:
+ mutex_unlock(&adapter->int_mtx);
+ scsi_free_command(GFP_KERNEL, scmd);
+ return -ENOMEM;
}
^ permalink raw reply related
* net: rcu warnings in ip6fl_get_first
From: Sasha Levin @ 2013-02-07 19:32 UTC (permalink / raw)
To: David S. Miller, yoshfuji
Cc: Dave Jones, netdev, linux-kernel@vger.kernel.org
Hi guys,
I got the following while fuzzing with trinity inside a KVM tools guest:
[ 51.680236] ===============================
[ 51.681914] [ INFO: suspicious RCU usage. ]
[ 51.683610] 3.8.0-rc6-next-20130206-sasha-00028-g83214f7-dirty #276 Tainted: G W
[ 51.686703] -------------------------------
[ 51.688281] net/ipv6/ip6_flowlabel.c:671 suspicious rcu_dereference_check() usage!
[ 51.691345]
[ 51.691345] other info that might help us debug this:
[ 51.691345]
[ 51.694479]
[ 51.694479] rcu_scheduler_active = 1, debug_locks = 1
[ 51.697650] 2 locks held by trinity/7421:
[ 51.701271] #0: (&p->lock){+.+.+.}, at: [<ffffffff812b049a>] seq_read+0x3a/0x3d0
[ 51.704292] #1: (rcu_read_lock_bh){.+....}, at: [<ffffffff8397cde0>] ip6fl_seq_start+0x0/0xe0
[ 51.707845]
[ 51.707845] stack backtrace:
[ 51.709678] Pid: 7421, comm: trinity Tainted: G W 3.8.0-rc6-next-20130206-sasha-00028-g83214f7-dirty #276
[ 51.713495] Call Trace:
[ 51.714370] [<ffffffff81181fdb>] lockdep_rcu_suspicious+0x10b/0x120
[ 51.716560] [<ffffffff8397caca>] ip6fl_get_first+0x8a/0x140
[ 51.718755] [<ffffffff8397cdb7>] ip6fl_seq_next+0x17/0x40
[ 51.720963] [<ffffffff812b0711>] seq_read+0x2b1/0x3d0
[ 51.723056] [<ffffffff812b0460>] ? seq_lseek+0x110/0x110
[ 51.725238] [<ffffffff812f9c0c>] proc_reg_read+0x9c/0xd0
[ 51.727266] [<ffffffff812f9b70>] ? proc_reg_write+0xd0/0xd0
[ 51.729337] [<ffffffff8128b2eb>] do_loop_readv_writev+0x4b/0x90
[ 51.731846] [<ffffffff8128b566>] do_readv_writev+0xf6/0x1d0
[ 51.734092] [<ffffffff8128b6de>] vfs_readv+0x3e/0x60
[ 51.736015] [<ffffffff8128b750>] sys_readv+0x50/0xd0
[ 51.737930] [<ffffffff83d73d98>] tracesys+0xe1/0xe6
This is the result of commit "ipv6 flowlabel: Convert hash list to RCU." which
mixes between regular and _bh() locking.
Thanks,
Sasha
^ permalink raw reply
* [PATCH wireless-next] brcmsmac: fix u16 overflow warning
From: Tim Gardner @ 2013-02-07 19:35 UTC (permalink / raw)
To: linux-kernel
Cc: Tim Gardner, Brett Rudley, Arend van Spriel, Franky (Zhenhui) Lin,
Hante Meuleman, John W. Linville, Pieter-Paul Giesberts,
Seth Forshee, Hauke Mehrtens, linux-wireless, brcm80211-dev-list,
netdev
DOT11_MIN_BEACON_PERIOD and DOT11_MAX_BEACON_PERIOD are
superfluous. The only invalid beacon period is 0. Comparing
a 16 bit quantity to 0xffff also causes a compile warning:
drivers/net/wireless/brcm80211/brcmsmac/main.c:5560 brcms_c_set_beacon_period()
warn: impossible condition '(period > 65535) => (0-65535 > 65535)'
Observed from smatch analysis.
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
Cc: Hante Meuleman <meuleman@broadcom.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list@broadcom.com
Cc: netdev@vger.kernel.org
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
drivers/net/wireless/brcm80211/brcmsmac/main.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index c26992a..080b54d 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
@@ -101,8 +101,6 @@
#define DOT11_RTS_LEN 16
#define DOT11_CTS_LEN 10
#define DOT11_BA_BITMAP_LEN 128
-#define DOT11_MIN_BEACON_PERIOD 1
-#define DOT11_MAX_BEACON_PERIOD 0xFFFF
#define DOT11_MAXNUMFRAGS 16
#define DOT11_MAX_FRAG_LEN 2346
@@ -5555,8 +5553,7 @@ int brcms_c_set_rateset(struct brcms_c_info *wlc, struct brcm_rateset *rs)
int brcms_c_set_beacon_period(struct brcms_c_info *wlc, u16 period)
{
- if (period < DOT11_MIN_BEACON_PERIOD ||
- period > DOT11_MAX_BEACON_PERIOD)
+ if (period == 0)
return -EINVAL;
wlc->default_bss->beacon_period = period;
--
1.7.9.5
^ permalink raw reply related
* Re: Null pointers linux3.8-rc6
From: David Miller @ 2013-02-07 19:39 UTC (permalink / raw)
To: syrine.tl; +Cc: netdev, jj
In-Reply-To: <CAETb2JPm9rL=ParaVWhhpxE0gEzgw3+4ishf6sHOfm-Khwcw4Q@mail.gmail.com>
From: syrine tlili <syrine.tl@gmail.com>
Date: Thu, 7 Feb 2013 20:32:11 +0100
> I also suggest a set of patches to fix the detected errors.
Your patches are not useful because they have been corrupted by your
email client.
^ permalink raw reply
* Re: Null pointers linux3.8-rc6
From: syrine tlili @ 2013-02-07 19:43 UTC (permalink / raw)
To: David Miller, netdev
In-Reply-To: <20130207.143913.290469260544108221.davem@davemloft.net>
Patches for null pointer check
diff --git a/a/arch/x86/platform/efi/efi.c b/b/arch/x86/platform/efi/efi.c
index 77cf009..e64c3f4 100644
--- a/a/arch/x86/platform/efi/efi.c
+++ b/b/arch/x86/platform/efi/efi.c
@@ -924,6 +924,8 @@ void __init efi_enter_virtual_mode(void)
new_memmap = krealloc(new_memmap,
(count + 1) * memmap.desc_size,
GFP_KERNEL);
+ if (!new_memmap)
+ return -ENOMEM;
memcpy(new_memmap + (count * memmap.desc_size), md,
memmap.desc_size);
count++;
diff --git a/a/fs/ceph/mdsmap.c b/b/fs/ceph/mdsmap.c
index 73b7d44..d04ab8b 100644
--- a/a/fs/ceph/mdsmap.c
+++ b/b/fs/ceph/mdsmap.c
@@ -132,6 +132,8 @@ struct ceph_mdsmap *ceph_mdsmap_decode(void **p, void *end)
m->m_info[mds].export_targets =
kcalloc(num_export_targets, sizeof(u32),
GFP_NOFS);
+ if (m->m_info[mds].export_targets == NULL)
+ goto badmem;
for (j = 0; j < num_export_targets; j++)
m->m_info[mds].export_targets[j] =
ceph_decode_32(&pexport_targets);
diff --git a/a/drivers/isdn/mISDN/fsm.c b/b/drivers/isdn/mISDN/fsm.c
index 26477d4..07040b2 100644
--- a/a/drivers/isdn/mISDN/fsm.c
+++ b/b/drivers/isdn/mISDN/fsm.c
@@ -34,6 +34,8 @@ mISDN_FsmNew(struct Fsm *fsm,
fsm->jumpmatrix = kzalloc(sizeof(FSMFNPTR) * fsm->state_count *
fsm->event_count, GFP_KERNEL);
+ if (!fsm->jumpmatrix)
+ return -ENOMEM;
for (i = 0; i < fncount; i++)
if ((fnlist[i].state >= fsm->state_count) ||
diff --git a/a/drivers/scsi/megaraid.c b/b/drivers/scsi/megaraid.c
index 9504ec0..37b915f 100644
--- a/a/drivers/scsi/megaraid.c
+++ b/b/drivers/scsi/megaraid.c
@@ -4437,6 +4437,8 @@ mega_internal_command(adapter_t *adapter,
megacmd_t *mc, mega_passthru *pthru)
memset(scb, 0, sizeof(scb_t));
sdev = kzalloc(sizeof(struct scsi_device), GFP_KERNEL);
+ if (!sdev)
+ goto err_out;
scmd->device = sdev;
memset(adapter->int_cdb, 0, sizeof(adapter->int_cdb));
@@ -4482,6 +4484,11 @@ mega_internal_command(adapter_t *adapter,
megacmd_t *mc, mega_passthru *pthru)
scsi_free_command(GFP_KERNEL, scmd);
return rval;
+
+err_out:
+ mutex_unlock(&adapter->int_mtx);
+ scsi_free_command(GFP_KERNEL, scmd);
+ return -ENOMEM;
}
On Thu, Feb 7, 2013 at 8:39 PM, David Miller <davem@davemloft.net> wrote:
> From: syrine tlili <syrine.tl@gmail.com>
> Date: Thu, 7 Feb 2013 20:32:11 +0100
>
>> I also suggest a set of patches to fix the detected errors.
>
> Your patches are not useful because they have been corrupted by your
> email client.
^ permalink raw reply related
* Re: Null pointers linux3.8-rc6
From: David Miller @ 2013-02-07 19:51 UTC (permalink / raw)
To: syrine.tl; +Cc: netdev
In-Reply-To: <CAETb2JOYSFJ2FqWhFjN6FsTugcWD1Dg54Y6DvgmtT2wD4v2U-Q@mail.gmail.com>
From: syrine tlili <syrine.tl@gmail.com>
Date: Thu, 7 Feb 2013 20:43:42 +0100
> Patches for null pointer check
You need to provide a more verbose commit message.
You must provide a proper signoff as per Documentation/SubmittingPatches
^ permalink raw reply
* Re: [PATCH, resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
From: Ben Hutchings @ 2013-02-07 20:02 UTC (permalink / raw)
To: Freddy Xin; +Cc: netdev, davem, linux-usb, linux-kernel
In-Reply-To: <1360244360-2700-1-git-send-email-freddy@asix.com.tw>
On Thu, 2013-02-07 at 21:39 +0800, Freddy Xin wrote:
> From: Freddy Xin <freddy@asix.com.tw>
>
> This is a resubmission.
> Added "const" to ethtool_ops structure and fixed the coding style of AX88179_BULKIN_SIZE array.
> Fixed the issue that the default MTU is not 1500.
> Added ax88179_change_mtu function and enabled the hardware jumbo frame function to support an
> MTU higher than 1500.
> Fixed indentation and empty line coding style errors.
> The _nopm version usb functions were added to access register in suspend and resume functions.
> Serveral variables allocted dynamically were removed and replaced by stack variables.
> ax88179_get_eeprom were modified from asix_get_eeprom in asix_common.
>
> This patch adds a driver for ASIX's AX88179 family of USB 3.0/2.0
> to gigabit ethernet adapters. It's based on the AX88xxx driver but
> the usb commands used to access registers for AX88179 are completely different.
> This driver had been verified on x86 system with AX88179/AX88178A and
> Sitcomm LN-032 USB dongles.
>
> Signed-off-by: Freddy Xin <freddy@asix.com.tw>
[...]
> --- /dev/null
> +++ b/drivers/net/usb/ax88179_178a.c
[...]
> +struct ax88179_data {
> + u16 rxctl;
> +};
Should also be declared __packed, as on some architectures it may be
padded to 4 bytes.
rxctl is presumably required to be little-endian (__le16)?
> +struct ax88179_int_data {
> + u16 res1;
> + u8 link;
> + u16 res2;
> + u8 status;
> + u16 res3;
> +} __packed;
Same here, the u16 fields are presumably little-endian?
[...]
> +struct ax88179_rx_pkt_header {
> + u8 l4_csum_err:1,
> + l3_csum_err:1,
> + l4_type:3,
> + l3_type:2,
> + ce:1;
> +
> + u8 vlan_ind:3,
> + rx_ok:1,
> + pri:3,
> + bmc:1;
> +
> + u16 len:13,
> + crc:1,
> + mii:1,
> + drop:1;
> +} __packed;
This won't work on both big-endian systems (assuming this works on x86).
You apparently try to convert the structure in-place in
ax88179_rx_fixup() by calling le32_to_cpus(); that may work if you
define all the bitfields to be part of a u32 but it won't work with the
current definition.
[...]
> +static int
> +ax88179_set_features(struct net_device *net, netdev_features_t features)
> +{
> + u8 tmp;
> + struct usbnet *dev = netdev_priv(net);
> + netdev_features_t changed = net->features ^ features;
> +
> + if (changed & NETIF_F_TSO)
> + net->features ^= NETIF_F_TSO;
> +
> + if (changed & NETIF_F_SG)
> + net->features ^= NETIF_F_SG;
Don't change net->features; the caller will do that for you.
> + if (changed & NETIF_F_IP_CSUM) {
> + ax88179_read_cmd(dev, AX_ACCESS_MAC, AX_TXCOE_CTL, 1, 1, &tmp);
> + tmp ^= AX_TXCOE_TCP | AX_TXCOE_UDP;
> + ax88179_write_cmd(dev, AX_ACCESS_MAC, AX_TXCOE_CTL, 1, 1, &tmp);
> +
> + net->features ^= NETIF_F_IP_CSUM;
> + }
[...]
Isn't tmp going to be in little-endian byte order, so this doesn't work
correctly on a big-endian system?
There are a lot of reads and writes of 16-bit registers using
ax88179_{read,write}_cmd(); maybe you should add
ax88179_{read,write}_le16() to handle this specific case.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH, resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
From: David Miller @ 2013-02-07 20:05 UTC (permalink / raw)
To: bhutchings; +Cc: freddy, netdev, linux-usb, linux-kernel
In-Reply-To: <1360267375.3605.32.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 7 Feb 2013 20:02:55 +0000
> On Thu, 2013-02-07 at 21:39 +0800, Freddy Xin wrote:
>> From: Freddy Xin <freddy@asix.com.tw>
>>
>> This is a resubmission.
>> Added "const" to ethtool_ops structure and fixed the coding style of AX88179_BULKIN_SIZE array.
>> Fixed the issue that the default MTU is not 1500.
>> Added ax88179_change_mtu function and enabled the hardware jumbo frame function to support an
>> MTU higher than 1500.
>> Fixed indentation and empty line coding style errors.
>> The _nopm version usb functions were added to access register in suspend and resume functions.
>> Serveral variables allocted dynamically were removed and replaced by stack variables.
>> ax88179_get_eeprom were modified from asix_get_eeprom in asix_common.
>>
>> This patch adds a driver for ASIX's AX88179 family of USB 3.0/2.0
>> to gigabit ethernet adapters. It's based on the AX88xxx driver but
>> the usb commands used to access registers for AX88179 are completely different.
>> This driver had been verified on x86 system with AX88179/AX88178A and
>> Sitcomm LN-032 USB dongles.
>>
>> Signed-off-by: Freddy Xin <freddy@asix.com.tw>
> [...]
>> --- /dev/null
>> +++ b/drivers/net/usb/ax88179_178a.c
> [...]
>> +struct ax88179_data {
>> + u16 rxctl;
>> +};
>
> Should also be declared __packed, as on some architectures it may be
> padded to 4 bytes.
Packed is evil and should be avoid everywhere that it is possible to
do so. It's going to use byte loads on this u16 on RISC cpus simply
because __packed makes it so that the compiler cannot assume data
alignment any longer.
^ permalink raw reply
* [PATCH wireless-next] brcmsmac: avoid 512 byte stack variable
From: Tim Gardner @ 2013-02-07 20:13 UTC (permalink / raw)
To: linux-kernel
Cc: Tim Gardner, Brett Rudley, Arend van Spriel, Franky (Zhenhui) Lin,
Hante Meuleman, John W. Linville, Seth Forshee,
Pieter-Paul Giesberts, Hauke Mehrtens, linux-wireless,
brcm80211-dev-list, netdev
Dynamically allocate the probe response template which
avoids potential stack corruption. Observed with smatch:
drivers/net/wireless/brcm80211/brcmsmac/main.c:7412 brcms_c_bss_update_probe_resp()
warn: 'prb_resp' puts 512 bytes on stack
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
Cc: Hante Meuleman <meuleman@broadcom.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list@broadcom.com
Cc: netdev@vger.kernel.org
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
drivers/net/wireless/brcm80211/brcmsmac/main.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index c26992a..e392e76 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
@@ -7408,9 +7408,16 @@ brcms_c_bss_update_probe_resp(struct brcms_c_info *wlc,
struct brcms_bss_cfg *cfg,
bool suspend)
{
- u16 prb_resp[BCN_TMPL_LEN / 2];
+ u16 *prb_resp;
int len = BCN_TMPL_LEN;
+ prb_resp = kmalloc(BCN_TMPL_LEN, GFP_ATOMIC);
+ if (!prb_resp) {
+ wiphy_err(wlc->wiphy, "wl: %s: failed to alloc %u bytes\n",
+ __func__, BCN_TMPL_LEN);
+ return;
+ }
+
/*
* write the probe response to hardware, or save in
* the config structure
@@ -7444,6 +7451,8 @@ brcms_c_bss_update_probe_resp(struct brcms_c_info *wlc,
if (suspend)
brcms_c_enable_mac(wlc);
+
+ kfree(prb_resp);
}
void brcms_c_update_probe_resp(struct brcms_c_info *wlc, bool suspend)
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH wireless-next] brcmsmac: fix u16 overflow warning
From: Arend van Spriel @ 2013-02-07 20:18 UTC (permalink / raw)
To: Tim Gardner
Cc: linux-kernel, Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman,
John W. Linville, Pieter-Paul Giesberts, Seth Forshee,
Hauke Mehrtens, linux-wireless, brcm80211-dev-list, netdev
In-Reply-To: <1360265735-42450-1-git-send-email-tim.gardner@canonical.com>
On 02/07/2013 08:35 PM, Tim Gardner wrote:
> DOT11_MIN_BEACON_PERIOD and DOT11_MAX_BEACON_PERIOD are
> superfluous. The only invalid beacon period is 0. Comparing
> a 16 bit quantity to 0xffff also causes a compile warning:
>
> drivers/net/wireless/brcm80211/brcmsmac/main.c:5560 brcms_c_set_beacon_period()
> warn: impossible condition '(period > 65535) => (0-65535 > 65535)'
>
> Observed from smatch analysis.
>
> Cc: Brett Rudley <brudley@broadcom.com>
> Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
> Cc: Hante Meuleman <meuleman@broadcom.com>
> Cc: "John W. Linville" <linville@tuxdriver.com>
> Cc: Pieter-Paul Giesberts <pieterpg@broadcom.com>
> Cc: Seth Forshee <seth.forshee@canonical.com>
> Cc: Hauke Mehrtens <hauke@hauke-m.de>
> Cc: linux-wireless@vger.kernel.org
> Cc: brcm80211-dev-list@broadcom.com
> Cc: netdev@vger.kernel.org
Acked-by: Arend van Spriel <arend@broadcom.com>
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> ---
> drivers/net/wireless/brcm80211/brcmsmac/main.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
> index c26992a..080b54d 100644
> --- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
> +++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
> @@ -101,8 +101,6 @@
> #define DOT11_RTS_LEN 16
> #define DOT11_CTS_LEN 10
> #define DOT11_BA_BITMAP_LEN 128
> -#define DOT11_MIN_BEACON_PERIOD 1
> -#define DOT11_MAX_BEACON_PERIOD 0xFFFF
> #define DOT11_MAXNUMFRAGS 16
> #define DOT11_MAX_FRAG_LEN 2346
>
> @@ -5555,8 +5553,7 @@ int brcms_c_set_rateset(struct brcms_c_info *wlc, struct brcm_rateset *rs)
>
> int brcms_c_set_beacon_period(struct brcms_c_info *wlc, u16 period)
> {
> - if (period < DOT11_MIN_BEACON_PERIOD ||
> - period > DOT11_MAX_BEACON_PERIOD)
> + if (period == 0)
> return -EINVAL;
>
> wlc->default_bss->beacon_period = period;
>
^ permalink raw reply
* Re: [PATCH wireless-next] brcmsmac: avoid 512 byte stack variable
From: Joe Perches @ 2013-02-07 20:19 UTC (permalink / raw)
To: Tim Gardner
Cc: linux-kernel, Brett Rudley, Arend van Spriel,
Franky (Zhenhui) Lin, Hante Meuleman, John W. Linville,
Seth Forshee, Pieter-Paul Giesberts, Hauke Mehrtens,
linux-wireless, brcm80211-dev-list, netdev
In-Reply-To: <1360268032-52414-1-git-send-email-tim.gardner@canonical.com>
On Thu, 2013-02-07 at 13:13 -0700, Tim Gardner wrote:
> Dynamically allocate the probe response template which
> avoids potential stack corruption. Observed with smatch:
trivial:
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
[]
> @@ -7408,9 +7408,16 @@ brcms_c_bss_update_probe_resp(struct brcms_c_info *wlc,
[]
> + prb_resp = kmalloc(BCN_TMPL_LEN, GFP_ATOMIC);
> + if (!prb_resp) {
> + wiphy_err(wlc->wiphy, "wl: %s: failed to alloc %u bytes\n",
> + __func__, BCN_TMPL_LEN);
Please remove the error message.
alloc's don't need specific OOM messages.
The mm subsystem already provides a standardized
message with a dump_stack().
^ permalink raw reply
* Re: [PATCH wireless-next] brcmsmac: avoid 512 byte stack variable
From: Arend van Spriel @ 2013-02-07 20:22 UTC (permalink / raw)
To: Tim Gardner
Cc: linux-kernel, Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman,
John W. Linville, Seth Forshee, Pieter-Paul Giesberts,
Hauke Mehrtens, linux-wireless, brcm80211-dev-list, netdev,
Joe Perches
In-Reply-To: <1360268032-52414-1-git-send-email-tim.gardner@canonical.com>
On 02/07/2013 09:13 PM, Tim Gardner wrote:
> Dynamically allocate the probe response template which
> avoids potential stack corruption. Observed with smatch:
>
> drivers/net/wireless/brcm80211/brcmsmac/main.c:7412 brcms_c_bss_update_probe_resp()
> warn: 'prb_resp' puts 512 bytes on stack
>
> Cc: Brett Rudley <brudley@broadcom.com>
> Cc: Arend van Spriel <arend@broadcom.com>
> Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
> Cc: Hante Meuleman <meuleman@broadcom.com>
> Cc: "John W. Linville" <linville@tuxdriver.com>
> Cc: Seth Forshee <seth.forshee@canonical.com>
> Cc: Pieter-Paul Giesberts <pieterpg@broadcom.com>
> Cc: Hauke Mehrtens <hauke@hauke-m.de>
> Cc: linux-wireless@vger.kernel.org
> Cc: brcm80211-dev-list@broadcom.com
> Cc: netdev@vger.kernel.org
One comment below. When taken care of feel free to add:
Acked-by: Arend van Spriel <arend@broadcom.com>
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> ---
> drivers/net/wireless/brcm80211/brcmsmac/main.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
> index c26992a..e392e76 100644
> --- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
> +++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
> @@ -7408,9 +7408,16 @@ brcms_c_bss_update_probe_resp(struct brcms_c_info *wlc,
> struct brcms_bss_cfg *cfg,
> bool suspend)
> {
> - u16 prb_resp[BCN_TMPL_LEN / 2];
> + u16 *prb_resp;
> int len = BCN_TMPL_LEN;
>
> + prb_resp = kmalloc(BCN_TMPL_LEN, GFP_ATOMIC);
> + if (!prb_resp) {
> + wiphy_err(wlc->wiphy, "wl: %s: failed to alloc %u bytes\n",
> + __func__, BCN_TMPL_LEN);
I believe the kmalloc() call spews enough info upon allocation failure
so please remove the error message here.
> + return;
> + }
> +
> /*
> * write the probe response to hardware, or save in
> * the config structure
> @@ -7444,6 +7451,8 @@ brcms_c_bss_update_probe_resp(struct brcms_c_info *wlc,
>
> if (suspend)
> brcms_c_enable_mac(wlc);
> +
> + kfree(prb_resp);
> }
>
> void brcms_c_update_probe_resp(struct brcms_c_info *wlc, bool suspend)
>
^ permalink raw reply
* Re: [PATCH wireless-next] brcmsmac: avoid 512 byte stack variable
From: Arend van Spriel @ 2013-02-07 20:23 UTC (permalink / raw)
To: Joe Perches
Cc: Tim Gardner, linux-kernel, Brett Rudley, Franky (Zhenhui) Lin,
Hante Meuleman, John W. Linville, Seth Forshee,
Pieter-Paul Giesberts, Hauke Mehrtens, linux-wireless,
brcm80211-dev-list, netdev
In-Reply-To: <1360268386.27863.2.camel@joe-AO722>
On 02/07/2013 09:19 PM, Joe Perches wrote:
> On Thu, 2013-02-07 at 13:13 -0700, Tim Gardner wrote:
>> Dynamically allocate the probe response template which
>> avoids potential stack corruption. Observed with smatch:
>
> trivial:
>
>> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
> []
>> @@ -7408,9 +7408,16 @@ brcms_c_bss_update_probe_resp(struct brcms_c_info *wlc,
> []
>> + prb_resp = kmalloc(BCN_TMPL_LEN, GFP_ATOMIC);
>> + if (!prb_resp) {
>> + wiphy_err(wlc->wiphy, "wl: %s: failed to alloc %u bytes\n",
>> + __func__, BCN_TMPL_LEN);
>
> Please remove the error message.
> alloc's don't need specific OOM messages.
>
> The mm subsystem already provides a standardized
> message with a dump_stack().
You beat me to the finish line :-)
Gr. AvS
^ permalink raw reply
* Re: Null pointers linux3.8-rc6
From: Ben Hutchings @ 2013-02-07 20:23 UTC (permalink / raw)
To: David Miller, syrine.tl; +Cc: netdev
In-Reply-To: <20130207.145147.2001556658631071207.davem@davemloft.net>
On Thu, 2013-02-07 at 14:51 -0500, David Miller wrote:
> From: syrine tlili <syrine.tl@gmail.com>
> Date: Thu, 7 Feb 2013 20:43:42 +0100
>
> > Patches for null pointer check
>
> You need to provide a more verbose commit message.
>
> You must provide a proper signoff as per Documentation/SubmittingPatches
...and send to more appropriate recipients as suggested by
scripts/get_maintainer.pl
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH wireless-next V2] brcmsmac: avoid 512 byte stack variable
From: Tim Gardner @ 2013-02-07 20:28 UTC (permalink / raw)
To: linux-kernel
Cc: Tim Gardner, Brett Rudley, Arend van Spriel, Franky (Zhenhui) Lin,
Hante Meuleman, John W. Linville, Seth Forshee,
Pieter-Paul Giesberts, Hauke Mehrtens, linux-wireless,
brcm80211-dev-list, netdev
In-Reply-To: <51140CFB.1060100@broadcom.com>
Dynamically allocate the probe response template which
avoids potential stack corruption. Observed with smatch:
drivers/net/wireless/brcm80211/brcmsmac/main.c:7412 brcms_c_bss_update_probe_resp()
warn: 'prb_resp' puts 512 bytes on stack
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
Cc: Hante Meuleman <meuleman@broadcom.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list@broadcom.com
Cc: netdev@vger.kernel.org
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
drivers/net/wireless/brcm80211/brcmsmac/main.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index c26992a..ea88abe 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
@@ -7408,9 +7408,13 @@ brcms_c_bss_update_probe_resp(struct brcms_c_info *wlc,
struct brcms_bss_cfg *cfg,
bool suspend)
{
- u16 prb_resp[BCN_TMPL_LEN / 2];
+ u16 *prb_resp;
int len = BCN_TMPL_LEN;
+ prb_resp = kmalloc(BCN_TMPL_LEN, GFP_ATOMIC);
+ if (!prb_resp)
+ return;
+
/*
* write the probe response to hardware, or save in
* the config structure
@@ -7444,6 +7448,8 @@ brcms_c_bss_update_probe_resp(struct brcms_c_info *wlc,
if (suspend)
brcms_c_enable_mac(wlc);
+
+ kfree(prb_resp);
}
void brcms_c_update_probe_resp(struct brcms_c_info *wlc, bool suspend)
--
1.7.9.5
^ permalink raw reply related
* [PATCH] mwl8k: Remove unnecessary alloc/OOM messages
From: Joe Perches @ 2013-02-07 20:37 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: John W. Linville, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, LKML
alloc failures already get standardized OOM
messages and a dump_stack.
Signed-off-by: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
---
drivers/net/wireless/mwl8k.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 224cf91..e31f779 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -1146,7 +1146,6 @@ static int mwl8k_rxq_init(struct ieee80211_hw *hw, int index)
rxq->buf = kcalloc(MWL8K_RX_DESCS, sizeof(*rxq->buf), GFP_KERNEL);
if (rxq->buf == NULL) {
- wiphy_err(hw->wiphy, "failed to alloc RX skbuff list\n");
pci_free_consistent(priv->pdev, size, rxq->rxd, rxq->rxd_dma);
return -ENOMEM;
}
@@ -1439,7 +1438,6 @@ static int mwl8k_txq_init(struct ieee80211_hw *hw, int index)
txq->skb = kcalloc(MWL8K_TX_DESCS, sizeof(*txq->skb), GFP_KERNEL);
if (txq->skb == NULL) {
- wiphy_err(hw->wiphy, "failed to alloc TX skbuff list\n");
pci_free_consistent(priv->pdev, size, txq->txd, txq->txd_dma);
return -ENOMEM;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: BQL support in gianfar causes network hickup
From: Paul Gortmaker @ 2013-02-07 21:05 UTC (permalink / raw)
To: Keitel, Tino (ALC NetworX GmbH)
Cc: Eric Dumazet, Tino Keitel, netdev@vger.kernel.org
In-Reply-To: <9AA65D849A88EB44B5D9B6A8BA098E23042DCF04C8BB@Exchange1.lawo.de>
On 13-02-05 08:00 AM, Keitel, Tino (ALC NetworX GmbH) wrote:
> On Di, 2012-11-27 at 05:32 -0800, Eric Dumazet wrote:
>> On Tue, 2012-11-27 at 13:42 +0100, Keitel, Tino (ALC NetworX GmbH)
>> wrote:
>>> On Di, 2012-11-27 at 04:36 -0800, Eric Dumazet wrote:
>>>>
>>>> Can you reproduce the problem using a single cpu ?
>>>
>>> Yes, it is a single-CPU system.
>>
>> Can you reproduce the problem without PTP running, or disabled in the
>> driver ?
>>
>> (comment the "priv->hwts_tx_en = 1;" line)
>
> I can't reproduce it with that line commented. However, so far I was
> only able to reproduce it when starting the ptp2 client, so maybe this
> is connected.
I found an mpc8315erdb, and built the default yocto build (v3.4.20,
which should have the issue based on your earlier reports.)
>
>> By the way are any errata flagged in gfar_detect_errata() ?
>
> This is from dmesg:
>
> fsl-gianfar e0024000.ethernet: enabled errata workarounds, flags: 0x7
>
> 0x7 would be GFAR_ERRATA_74, GFAR_ERRATA_76 and GFAR_ERRATA_A002
> according to drivers/net/ethernet/freescale/gianfar.h.
The MPC8315ECE.pdf lists the 8315 as having 76 and A002 (amongst
a lot of others.) However the driver only does errata checks
for the 8313 it seems. I also then manually forced the driver
to enable the errata and confirmed I saw 0x7 flag in dmesg.
Finally I added the meta-networking layer to the yocto build to
get a ptpd2 (2.2.0-r1)
On another board, I ran a server as:
ptpd2 -G -C -c -b eth0
On the 8315, I ran the client as:
ptpd2 -g -C -c -b eth0
In neither case (errata off, and errata manually enabled) I did not
manage to get the tx timeout that you got.
There must be something more specific to your environment, your
ptpd client (and args) and perhaps the board itself.
Paul.
--
>
> Regards,
> Tino
>
^ permalink raw reply
* Re: [PATCH 2/2 v2] sierra_net: fix issues with SYNC/RESTART messages and interrupt pipe setup
From: Dan Williams @ 2013-02-07 21:09 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Elina Pasheva, netdev, linux-usb, Rory Filer, Phil Sutter
In-Reply-To: <2485224.kk5J89zEMM@linux-5eaq.site>
On Wed, 2013-02-06 at 21:17 +0100, Oliver Neukum wrote:
> On Wednesday 06 February 2013 12:42:56 Dan Williams wrote:
> > As part of the initialization sequence, the driver sends a SYNC message
> > via the control pipe to the firmware, which appears to request a
> > firmware restart. The firmware responds with an indication via the
> > interrupt pipe set up by usbnet. If the driver does not receive a
> > RESTART indication within a certain amount of time, it will periodically
> > send additional SYNC messages until it receives the RESTART indication.
> >
> > Unfortunately, the interrupt URB is only submitted while the netdev
> > is open, which is usually not the case during initialization, and thus
> > the firmware's RESTART indication is lost. So the driver continues
> > sending SYNC messages, and eventually the firmware crashes when it
> > receives too many. This leads to a wedged netdev.
>
> If I understand this correctly we should stop the interrupt pipe once
> RESTART has been recieved. I am afraid this patch is a bit inefficient.
The firmware may send other indications to the host over the interrupt
pipe at any time, apparently. However, I have not seen firmware send
these indications in practice, so maybe we can ignore this and do as you
suggest.
So how would you suggest to handle this given the constraints?
Basically, we need to allow sierra_net to submit dev->interrupt at
probe/bind and then after a period of time kill it when it's no longer
needed. The problem is that if the interface is set IFF_UP right after
bind but before sierra_net has finished its SYNC/Restart dance, we need
to ensure that sierra_net doesn't kill the URB unconditionally.
One way to do this would be a new usbnet function to subdrivers could
call to submit the URB which would be a NOP if the URB was already
submitted. It would be paired with a function to kill the URB which
would be a NOP if (URB already killed || (IFF_UP and subdriver has
status() hook)). Kinda like refcounting the interrupt URB submission
but not.
Does that sound like a worthwhile approach?
Dan
^ permalink raw reply
* Re: [PATCH 0/2] fix kernel crash with macvtap on top of LRO
From: Michael S. Tsirkin @ 2013-02-07 21:33 UTC (permalink / raw)
To: David Miller
Cc: e1000-devel, linux-driver, netdev, jitendra.kalsaria,
bruce.w.allan, jesse.brandeburg, eilong, john.r.fastabend,
john.ronciak, sony.chacko, bhutchings, linux-kernel,
jacob.e.keller
In-Reply-To: <20130207.131420.1211188723341167971.davem@davemloft.net>
On Thu, Feb 07, 2013 at 01:14:20PM -0500, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Thu, 7 Feb 2013 16:20:46 +0000
>
> > If the consensus is still that we must preserve packets exactly (aside
> > from the usual modifications by IP routers) then LRO should be disabled
> > on all devices for which forwarding is enabled.
>
> I believe this is still undoubtedly the consensus.
But we don't need to preserve the packets when passing them to macvtap
(which discards all this info smashing the packet into a single buffer anyway),
correct?
If true LRO with macvtap might be useful and so the patchset is probably
still the right thing to do to fix the macvtap crash. Makes sense?
We might want to add code to forward LRO status from macvlan
(not macvtap) back to the lowerdev, so that setting up forwarding
from macvlan disables LRO on the lowerdev, but that seems like another
issue.
--
MST
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ 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