* Re: [PATCH net-next] macvlan: delay the header check for dodgy packets into lower device
From: David Miller @ 2014-11-30 4:45 UTC (permalink / raw)
To: jasowang; +Cc: kaber, netdev, linux-kernel, mst, vyasevic
In-Reply-To: <1416993674-11177-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Wed, 26 Nov 2014 17:21:14 +0800
> We do header check twice for a dodgy packet. One is done before
> macvlan_start_xmit(), another is done before lower device's
> ndo_start_xmit(). The first one seems redundant so this patch tries to
> delay header check until a packet reaches its lower device (or macvtap)
> through always enabling NETIF_F_GSO_ROBUST for macvlan device.
>
> Cc: Patrick McHardy <kaber@trash.net>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] xen-netfront: Remove BUGs on paged skb data which crosses a page boundary
From: David Miller @ 2014-11-30 4:43 UTC (permalink / raw)
To: seth.forshee
Cc: konrad.wilk, boris.ostrovsky, david.vrabel, zoltan.kiss,
eric.dumazet, stefan.bader, xen-devel, netdev, linux-kernel
In-Reply-To: <20141127035350.GA10833@ubuntu-mba51>
From: Seth Forshee <seth.forshee@canonical.com>
Date: Wed, 26 Nov 2014 21:53:50 -0600
> On Wed, Nov 26, 2014 at 12:28:12PM -0500, David Miller wrote:
>> From: Seth Forshee <seth.forshee@canonical.com>
>> Date: Tue, 25 Nov 2014 20:28:24 -0600
>>
>> > These BUGs can be erroneously triggered by frags which refer to
>> > tail pages within a compound page. The data in these pages may
>> > overrun the hardware page while still being contained within the
>> > compound page, but since compound_order() evaluates to 0 for tail
>> > pages the assertion fails. The code already iterates through
>> > subsequent pages correctly in this scenario, so the BUGs are
>> > unnecessary and can be removed.
>> >
>> > Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
>> > Cc: <stable@vger.kernel.org> # 3.7+
>> > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
>>
>> Can I get some Xen developer reviews?
>
> Fwiw this issue was discussed previously and this was the recommended
> fix.
>
> http://article.gmane.org/gmane.linux.kernel/1825381
>
> Since then I got some feedback from a tester that he didn't see any
> problems with the BUGs removed (actually replaced with a WARN so I know
> that he actually saw the condition which triggered the BUG).
That's fine, but I still want a xen-netfront developer to review and
ACK this.
^ permalink raw reply
* Re: Non Explained TODOs in halbtcoutsrc.c
From: Larry Finger @ 2014-11-30 4:31 UTC (permalink / raw)
To: nick; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <547A581A.7040609@gmail.com>
On 11/29/2014 05:34 PM, nick wrote:
> Greetings Larry,
> After reading the code around the TODOS, I can't understand you reasoning for them in this file as they seem to
> unneeded as the logic for the switch statement with them seems to be fine. If there are reasons for them in this
> file, it would be nice to hear from you on why they are needed as TODO as a comment is rather unclear for anybody
> reading this file.
> Nick
I did not write that code. I merely make it available through the git repo, and
modify it so that it will build on all kernel versions. I do not understand the
TODOs any more than you do.
Larry
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: Wei Yang @ 2014-11-30 2:52 UTC (permalink / raw)
To: Wei Yang; +Cc: netdev, davem, gideonn, Eric Dumazet, Amir Vadai
In-Reply-To: <1417315431-16761-1-git-send-email-weiyang@linux.vnet.ibm.com>
BTW, I have one confusion in commit 6a4e812,
if (ring->bf_enabled && desc_size <= MAX_BF && !bounce &&
!vlan_tx_tag_present(skb) && send_doorbell) {
- tx_desc->ctrl.bf_qpn |= cpu_to_be32(ring->doorbell_qpn);
+ tx_desc->ctrl.bf_qpn = ring->doorbell_qpn |
+ cpu_to_be32(real_size);
I am curious about why it adds an | with the real_size?
I see this code pass is invoked in vlan network. I am not farmiliar with
the vlan test. I guess it needs some router with vlan configuration. If you
have some suggestion or link on how to test it, I am happy to have a try.
On Sun, Nov 30, 2014 at 10:43:51AM +0800, Wei Yang wrote:
>In commit 6a4e812 (net/mlx4_en: Avoid calling bswap in tx fast path), we store
>doorbell_qpn in big endian to avoid bswap(). Then we try to write it directly
>by iowrite32() instead of iowrite32be().
>
>This works fine on little endian platform, while has some problem on big
>endian platform. Here is the definition in general:
>
> #define iowrite32(v, addr) writel((v), (addr))
> #define writel(b,addr) __raw_writel(__cpu_to_le32(b),addr)
>
>On little endian platform, the value is not swapped before write. While on big
>endian platform, the value is swapped. This is not expected to happen.
>
>This patch does the swap on big endian platform before it is written.
>
>Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>CC: Eric Dumazet <edumazet@google.com>
>CC: Amir Vadai <amirv@mellanox.com>
>---
> drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>index 454d9fe..76f028b 100644
>--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>@@ -954,7 +954,7 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
> tx_desc->ctrl.owner_opcode = op_own;
> if (send_doorbell) {
> wmb();
>- iowrite32(ring->doorbell_qpn,
>+ iowrite32(__cpu_to_le32(ring->doorbell_qpn),
> ring->bf.uar->map + MLX4_SEND_DOORBELL);
> } else {
> ring->xmit_more++;
>--
>1.7.9.5
--
Richard Yang
Help you, Help me
^ permalink raw reply
* [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: Wei Yang @ 2014-11-30 2:43 UTC (permalink / raw)
To: netdev; +Cc: davem, gideonn, Wei Yang, Eric Dumazet, Amir Vadai
In commit 6a4e812 (net/mlx4_en: Avoid calling bswap in tx fast path), we store
doorbell_qpn in big endian to avoid bswap(). Then we try to write it directly
by iowrite32() instead of iowrite32be().
This works fine on little endian platform, while has some problem on big
endian platform. Here is the definition in general:
#define iowrite32(v, addr) writel((v), (addr))
#define writel(b,addr) __raw_writel(__cpu_to_le32(b),addr)
On little endian platform, the value is not swapped before write. While on big
endian platform, the value is swapped. This is not expected to happen.
This patch does the swap on big endian platform before it is written.
Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
CC: Eric Dumazet <edumazet@google.com>
CC: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index 454d9fe..76f028b 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -954,7 +954,7 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
tx_desc->ctrl.owner_opcode = op_own;
if (send_doorbell) {
wmb();
- iowrite32(ring->doorbell_qpn,
+ iowrite32(__cpu_to_le32(ring->doorbell_qpn),
ring->bf.uar->map + MLX4_SEND_DOORBELL);
} else {
ring->xmit_more++;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] e1000: remove unused variables
From: Ben Hutchings @ 2014-11-30 1:45 UTC (permalink / raw)
To: Hisashi T Fujinaka
Cc: Linux NICS, e1000-devel, Bruce Allan, Jesse Brandeburg,
linux-kernel, John Ronciak, netdev, Sudip Mukherjee
In-Reply-To: <alpine.NEB.2.11.1411262157110.1481@chris.i8u.org>
[-- Attachment #1.1: Type: text/plain, Size: 515 bytes --]
On Wed, 2014-11-26 at 21:59 -0800, Hisashi T Fujinaka wrote:
> I'm pretty sure those double reads are there for a reason, so most of
> this I'm going to have to check on Monday. We have a long holiday
> weekend here in the US.
[...]
If there were double register reads being replaced with single register
reads, I'd agree this was likely to introduce a regression. But all I
see is var = er32(REG) being changed to er32(REG).
Ben.
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
[-- Attachment #2: Type: text/plain, Size: 441 bytes --]
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
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
* Re: [PATCH iproute2] ip xfrm: support 64bit kernel and 32bit userspace
From: Ben Hutchings @ 2014-11-30 1:33 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1417157936-5522-1-git-send-email-roy.qing.li@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]
On Fri, 2014-11-28 at 14:58 +0800, roy.qing.li@gmail.com wrote:
> From: Li RongQing <roy.qing.li@gmail.com>
>
> The size of struct xfrm_userpolicy_info is 168 bytes for 64bit kernel, and
> 164 bytes for 32bit userspace because of the different alignment.
I think it's specific to x86 as other architectures have the same type
alignments for 32- and 64-bit variants.
> and lead to "ip xfrm" be unable to work.
>
> add a pad in struct xfrm_userpolicy_info, and enable it by set
> KERNEL_64_USERSPACE_32 to y
[...]
This doesn't make sense. 32-bit compat needs to work like 32-bit native
- no exceptions, no workarounds in userland. And if you really want to
work around this in userland you'll need a run-time, not compile-time,
check.
Ben.
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-11-30 1:13 UTC (permalink / raw)
To: Kevin Zhu
Cc: Alex Strizhevsky, Bjørn Mork, Midge Shaojun Tan,
youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Eli Britstein
In-Reply-To: <54783F84.20105-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
Hi guys.
Sorry for the late our but ... I was trying to figure out something new about
this dongle.
I also searched for it in my city shops without finding it actually.
But then I came back and ... tried to look at some things.
Alex, Kevin: in the Windows USB captures you sent me (and that I sent on the
List), I can notiche something very strange.
with a shell on a computer connected to a test device I can see the following:
at+gmr
21.286.03.01.209
OK
and so why in the Windows sniff the dongle answers to the same question
something like
23.128.00.00.00
?
Alex - was it the same dongle?
Kevin or anyone: can you use putty to interact with the dongle under Windows
and type some commands, like:
at+gmr
and other similar commands?
If the dongle reports different firmware versions under Linux and Windows, then
guys... we need to figure out the Windows switch message.
Overmore - in the device installation sh*t, you can see there is a firmware
updater... Why?
Alex: I used the
at^reset
command to get the modem back to normal state once; and so it restored the
nvram to default or something.
If you reconnect it to windows ... i hope it gets re-setup as before.
But - nothing harmful to the device, only to it's settings, sorry.
I restored the relevant settings and it connects again, but no dhcp. But - be
peaceful: other modems out there seems to not get dhcp anyway.
this is the state the modem arrives when you buy it, so windows should know
Wwhat To Say To The Modem (TM).
Another thing - note that:
[14170.048693] cdc_ncm 1-2:1.2: GET_MAX_DATAGRAM_SIZE failed
Any ideas, comments, suggestions are highly appreciated guys.
Of any type.
Bjorn - unfortunately it seems this problem is related to E3727 and E3276
sticks; they can get IP from DHCP but not go ahead.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [PATCH v2 net] bpf: x86: fix epilogue generation for eBPF programs
From: Alexei Starovoitov @ 2014-11-29 22:46 UTC (permalink / raw)
To: David S. Miller
Cc: Zi Shen Lim, Eric Dumazet, Daniel Borkmann, H. Peter Anvin,
Thomas Gleixner, Ingo Molnar, netdev, linux-kernel
classic BPF has a restriction that last insn is always BPF_RET.
eBPF doesn't have BPF_RET instruction and this restriction.
It has BPF_EXIT insn which can appear anywhere in the program
one or more times and it doesn't have to be last insn.
Fix eBPF JIT to emit epilogue when first BPF_EXIT is seen
and all other BPF_EXIT instructions will be emitted as jump.
Since jump offset to epilogue is computed as:
jmp_offset = ctx->cleanup_addr - addrs[i]
we need to change type of cleanup_addr to signed to compute the offset as:
(long long) ((int)20 - (int)30)
instead of:
(long long) ((unsigned int)20 - (int)30)
Fixes: 622582786c9e ("net: filter: x86: internal BPF JIT")
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
Note, this bug is applicable only to native eBPF programs
which first were introduced in 3.18, so no need for stable.
arm64 JIT has the same problem, but the fix is not as trivial,
so will be done as separate patch.
Since 3.18 can only load eBPF programs and cannot execute them,
this patch can even be done in net-next only, but I think it's worth
to apply it to 3.18(net), so that JITed output for native eBPF
programs is correct when bpf syscall loads it with net.core.bpf_jit_enable=2
arch/x86/net/bpf_jit_comp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 3f62734..7e90244 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -178,7 +178,7 @@ static void jit_fill_hole(void *area, unsigned int size)
}
struct jit_context {
- unsigned int cleanup_addr; /* epilogue code offset */
+ int cleanup_addr; /* epilogue code offset */
bool seen_ld_abs;
};
@@ -192,6 +192,7 @@ static int do_jit(struct bpf_prog *bpf_prog, int *addrs, u8 *image,
struct bpf_insn *insn = bpf_prog->insnsi;
int insn_cnt = bpf_prog->len;
bool seen_ld_abs = ctx->seen_ld_abs | (oldproglen == 0);
+ bool seen_exit = false;
u8 temp[BPF_MAX_INSN_SIZE + BPF_INSN_SAFETY];
int i;
int proglen = 0;
@@ -854,10 +855,11 @@ common_load:
goto common_load;
case BPF_JMP | BPF_EXIT:
- if (i != insn_cnt - 1) {
+ if (seen_exit) {
jmp_offset = ctx->cleanup_addr - addrs[i];
goto emit_jmp;
}
+ seen_exit = true;
/* update cleanup_addr */
ctx->cleanup_addr = proglen;
/* mov rbx, qword ptr [rbp-X] */
--
1.7.9.5
^ permalink raw reply related
* [PATCH iproute2] ss: Use generic handle_netlink_request for packet
From: Vadim Kochan @ 2014-11-29 21:44 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
Get rid of self-handling and creating of Netlink socket for show packet
socket stats.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
misc/ss.c | 77 ++-------------------------------------------------------------
1 file changed, 2 insertions(+), 75 deletions(-)
diff --git a/misc/ss.c b/misc/ss.c
index 0526205..a99294d 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -2788,86 +2788,13 @@ static int packet_show_sock(struct nlmsghdr *nlh, struct filter *f)
static int packet_show_netlink(struct filter *f, FILE *dump_fp)
{
- int fd;
DIAG_REQUEST(req, struct packet_diag_req r);
- char buf[16384];
-
- if ((fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_INET_DIAG)) < 0)
- return -1;
req.r.sdiag_family = AF_PACKET;
req.r.pdiag_show = PACKET_SHOW_INFO | PACKET_SHOW_MEMINFO | PACKET_SHOW_FILTER;
- if (send(fd, &req, sizeof(req), 0) < 0) {
- close(fd);
- return -1;
- }
-
- while (1) {
- ssize_t status;
- struct nlmsghdr *h;
- struct sockaddr_nl nladdr;
- socklen_t slen = sizeof(nladdr);
-
- status = recvfrom(fd, buf, sizeof(buf), 0,
- (struct sockaddr *) &nladdr, &slen);
- if (status < 0) {
- if (errno == EINTR)
- continue;
- perror("OVERRUN");
- continue;
- }
- if (status == 0) {
- fprintf(stderr, "EOF on netlink\n");
- goto close_it;
- }
-
- if (dump_fp)
- fwrite(buf, 1, NLMSG_ALIGN(status), dump_fp);
-
- h = (struct nlmsghdr*)buf;
- while (NLMSG_OK(h, status)) {
- int err;
-
- if (h->nlmsg_seq != 123456)
- goto skip_it;
-
- if (h->nlmsg_type == NLMSG_DONE)
- goto close_it;
-
- if (h->nlmsg_type == NLMSG_ERROR) {
- struct nlmsgerr *err = (struct nlmsgerr*)NLMSG_DATA(h);
- if (h->nlmsg_len < NLMSG_LENGTH(sizeof(struct nlmsgerr))) {
- fprintf(stderr, "ERROR truncated\n");
- } else {
- errno = -err->error;
- if (errno != ENOENT)
- fprintf(stderr, "UDIAG answers %d\n", errno);
- }
- close(fd);
- return -1;
- }
- if (!dump_fp) {
- err = packet_show_sock(h, f);
- if (err < 0) {
- close(fd);
- return err;
- }
- }
-
-skip_it:
- h = NLMSG_NEXT(h, status);
- }
-
- if (status) {
- fprintf(stderr, "!!!Remnant of size %zd\n", status);
- exit(1);
- }
- }
-
-close_it:
- close(fd);
- return 0;
+ return handle_netlink_request(f, dump_fp, &req.nlh, sizeof(req),
+ packet_show_sock);
}
--
2.1.3
^ permalink raw reply related
* [PATCH iproute2] man ip-link: Add description for 'help' command
From: Vadim Kochan @ 2014-11-29 19:49 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
man/man8/ip-link.8.in | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index ea23a72..9d4e3da 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -150,6 +150,10 @@ ip-link \- network device configuration
.B master
.IR DEVICE " ]"
+.ti -8
+.B ip link help
+.RI "[ " TYPE " ]"
+
.SH "DESCRIPTION"
.SS ip link add - add virtual link
@@ -702,6 +706,12 @@ output statistics with human readable values number followed by suffix
.BR "\-iec"
print human readable rates in IEC units (ie. 1K = 1024).
+.SS ip link help - display help
+
+.PP
+.I "TYPE"
+specifies which help of link type to dislpay.
+
.SH "EXAMPLES"
.PP
ip link show
@@ -724,6 +734,11 @@ ip link delete dev eth0.10
Removes vlan device.
.RE
+ip link help gre
+.RS 4
+Display help for the gre link type.
+.RE
+
.SH SEE ALSO
.br
.BR ip (8)
--
2.1.3
^ permalink raw reply related
* Re: [PATCH iproute2] ip netns: Identify netns for the current process
From: Stephen Hemminger @ 2014-11-29 19:18 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1415377530-25568-1-git-send-email-vadim4j@gmail.com>
On Fri, 7 Nov 2014 18:25:30 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:
> As 'ip' util will share the same netns from the caller
> process then we can just look at /proc/self/.. to show
> the netns of the current process by:
>
> ip netns id
>
> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Useful, applied.
^ permalink raw reply
* Re: [PATCH iproute2] vxlan: Add support for enabling UDP checksums
From: Stephen Hemminger @ 2014-11-29 19:08 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <1415376334-29292-1-git-send-email-therbert@google.com>
On Fri, 7 Nov 2014 08:05:34 -0800
Tom Herbert <therbert@google.com> wrote:
> Add udpcsum option to enable transmitting UDP checksums when doing
> VXLAN/IPv4. Add udp6zerocsumtx, and udp6zerocsumrx options to enable
> sending zero checksums and receiving zero checksums in VXLAN/IPv6.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied.
You probably want to update man page as well.
^ permalink raw reply
* Re: [PATCH] drivers:net:wireless: Add mutex locking for function, b43_op_beacon_set_time in main.c
From: Larry Finger @ 2014-11-29 18:54 UTC (permalink / raw)
To: nick, Rafał Miłecki, Michael Büsch
Cc: Network Development,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List, Stefano Brivio, b43-dev
In-Reply-To: <547A0BC5.2080005-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 11/29/2014 12:09 PM, nick wrote:
> Sorry about that, next time I will be more careful.
One other thing would be to change the initial part of the subject. Yes, the
device is in drivers/net/wireless/, but it is much more common to not include
those in patches that are sent to Linville. I would have used "b43: Add ...".
That catches the eye more quickly. As they say in the newspaper business, "Don't
bury the lead."
Larry
--
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
* Re: [PATCH] drivers:net:wireless: Add mutex locking for function, b43_op_beacon_set_time in main.c
From: nick @ 2014-11-29 18:09 UTC (permalink / raw)
To: Rafał Miłecki, Michael Büsch
Cc: Network Development,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List, Stefano Brivio, b43-dev
In-Reply-To: <CACna6ryjZ-LY06wAMzoL77Wca3McUUT+VYsO4EPO87NqjBnaNw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Sorry about that, next time I will be more careful.
Nick
On 2014-11-29 04:04 AM, Rafał Miłecki wrote:
> On 29 November 2014 at 09:56, Michael Büsch <m@bues.ch> wrote:
>> On Fri, 28 Nov 2014 22:32:30 -0500
>> nick <xerofoify@gmail.com> wrote:
>>
>>> I don't have hardware for this driver on me, so I didn't test it. However this seems to
>>> be correct from my reading of the code around this function and other locking related
>>> to this driver.
>>
>> From the current docs:
>>
>>> * @set_tim: Set TIM bit. mac80211 calls this function when a TIM bit
>>> * must be set or cleared for a given STA. Must be atomic.
>>
>> So it is not allowed to lock a mutex here.
>
> Nicholas please be more careful with your patches. It seems your patch
> is wrong, you didn't check the docs and you didn't even say in the
> first place that it wasn't tested. You could at least submit with with
> RFT tag or sth.
>
_______________________________________________
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev
^ permalink raw reply
* [PATCH net] gre: Set inner mac header in gro complete
From: Tom Herbert @ 2014-11-29 17:59 UTC (permalink / raw)
To: davem, linux, netdev
Set the inner mac header to point to the GRE payload when
doing GRO. This is needed if we proceed to send the packet
through GRE GSO which now uses the inner mac header instead
of inner network header to determine the length of encapsulation
headers.
Fixes: 14051f0452a2 ("gre: Use inner mac length when computing tunnel length")
Reported-by: Wolfgang Walter <linux@stwm.de>
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv4/gre_offload.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
index bb5947b..51973dd 100644
--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -247,6 +247,9 @@ static int gre_gro_complete(struct sk_buff *skb, int nhoff)
err = ptype->callbacks.gro_complete(skb, nhoff + grehlen);
rcu_read_unlock();
+
+ skb_set_inner_mac_header(skb, nhoff + grehlen);
+
return err;
}
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH 1/1] net-PA Semi: Deletion of unnecessary checks before the function call "pci_dev_put"
From: SF Markus Elfring @ 2014-11-29 18:00 UTC (permalink / raw)
To: Olof Johansson, netdev; +Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <5317A59D.4@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 29 Nov 2014 18:55:40 +0100
The pci_dev_put() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call
is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/pasemi/pasemi_mac.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c b/drivers/net/ethernet/pasemi/pasemi_mac.c
index 30d934d..44e8d7d 100644
--- a/drivers/net/ethernet/pasemi/pasemi_mac.c
+++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
@@ -1837,10 +1837,8 @@ pasemi_mac_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
return err;
out:
- if (mac->iob_pdev)
- pci_dev_put(mac->iob_pdev);
- if (mac->dma_pdev)
- pci_dev_put(mac->dma_pdev);
+ pci_dev_put(mac->iob_pdev);
+ pci_dev_put(mac->dma_pdev);
free_netdev(dev);
out_disable_device:
--
2.1.3
^ permalink raw reply related
* Re: [PATCH net] bond: Check length of IFLA_BOND_ARP_IP_TARGET attributes
From: John Fastabend @ 2014-11-29 17:53 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, netdev, Scott Feldman
In-Reply-To: <a7c193909c30dbc19b4f279a3f7ba757107641d3.1417044113.git.tgraf@suug.ch>
On 11/26/2014 03:22 PM, Thomas Graf wrote:
> Fixes: 7f28fa10 ("bonding: add arp_ip_target netlink support")
> Reported-by: John Fastabend <john.fastabend@gmail.com>
> Cc: Scott Feldman <sfeldma@cumulusnetworks.com>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> ---
> drivers/net/bonding/bond_netlink.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
Looks good thanks! For what its worth...
Acked-by: John Fastabend <john.r.fastabend@intel.com>
> diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c
> index c13d83e..45f09a6 100644
> --- a/drivers/net/bonding/bond_netlink.c
> +++ b/drivers/net/bonding/bond_netlink.c
> @@ -225,7 +225,12 @@ static int bond_changelink(struct net_device *bond_dev,
>
> bond_option_arp_ip_targets_clear(bond);
> nla_for_each_nested(attr, data[IFLA_BOND_ARP_IP_TARGET], rem) {
> - __be32 target = nla_get_be32(attr);
> + __be32 target;
> +
> + if (nla_len(attr) < sizeof(target))
> + return -EINVAL;
> +
> + target = nla_get_be32(attr);
>
> bond_opt_initval(&newval, (__force u64)target);
> err = __bond_opt_set(bond, BOND_OPT_ARP_TARGETS,
>
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH 0/5 net] bridge: Fix missing Netlink message validations
From: John Fastabend @ 2014-11-29 17:51 UTC (permalink / raw)
To: Thomas Graf; +Cc: Jiri Pirko, davem, stephen, netdev
In-Reply-To: <20141126231436.GF32174@casper.infradead.org>
On 11/26/2014 03:14 PM, Thomas Graf wrote:
> On 11/26/14 at 09:25am, John Fastabend wrote:
>>> --- a/net/ipv4/devinet.c
>>> +++ b/net/ipv4/devinet.c
>>> @@ -1687,8 +1687,11 @@ static int inet_set_link_af(struct net_device *dev, const struct nlattr *nla)
>>> BUG();
>>>
>>> if (tb[IFLA_INET_CONF]) {
>>> - nla_for_each_nested(a, tb[IFLA_INET_CONF], rem)
>>> + nla_for_each_nested(a, tb[IFLA_INET_CONF], rem) {
>>> + if (nla_len(a) < sizeof(u32))
>>> + return -EINVAL;
>>> ipv4_devconf_set(in_dev, nla_type(a), nla_get_u32(a));
>>> + }
>
> Looked into this and found a validation function
> inet_validate_link_af(). It's split to keep the updates atomic.
>
Ah great thanks.
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH v6 34/46] virtio_net: disable mac write for virtio 1.0
From: Michael S. Tsirkin @ 2014-11-29 17:28 UTC (permalink / raw)
To: Jason Wang
Cc: thuth, rusty, netdev, linux-kernel, virtualization, dahi,
pbonzini, David Miller
In-Reply-To: <1417164024.5822.11@smtp.corp.redhat.com>
On Fri, Nov 28, 2014 at 08:48:24AM +0008, Jason Wang wrote:
>
>
> On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >The spec states that mac in config space is only driver-writable in the
> >legacy case. Fence writing it in virtnet_set_mac_address() in the
> >virtio 1.0 case.
> >
> >Suggested-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> >Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >---
> > drivers/net/virtio_net.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> >index c6a72d3..9ab3c50 100644
> >--- a/drivers/net/virtio_net.c
> >+++ b/drivers/net/virtio_net.c
> >@@ -1030,7 +1030,8 @@ static int virtnet_set_mac_address(struct net_device
> >*dev, void *p)
> > "Failed to set mac address by vq command.\n");
> > return -EINVAL;
> > }
> >- } else if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC)) {
> >+ } else if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC) &&
> >+ !virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> > unsigned int i;
> > /* Naturally, this has an atomicity problem. */
> >--
> >MST
>
> Does this mean there's no way to setting mac addres
> if ctrl mac addr is disabled in virtio-1?
More exactly: no way for host to know the guest mac address.
> If yes, we'd better keep this compatibility somehow.
If host wants to be notified about guest mac updates,
it must enable the appropriate ctrl command.
Or if it's an old host, it just doesn't enable virtio-1.
There's no way around this - it's in the spec.
--
MST
^ permalink raw reply
* Re: [PATCH v6 38/46] tun: drop most type defines
From: Michael S. Tsirkin @ 2014-11-29 17:23 UTC (permalink / raw)
To: Jason Wang
Cc: linux-kernel, David Miller, cornelia.huck, rusty, nab, pbonzini,
thuth, dahi, Zhi Yong Wu, Tom Herbert, Ben Hutchings,
Masatake YAMATO, Herbert Xu, Xi Wang, netdev
In-Reply-To: <1417162188.5822.1@smtp.corp.redhat.com>
On Fri, Nov 28, 2014 at 08:17:48AM +0008, Jason Wang wrote:
>
>
> On Fri, Nov 28, 2014 at 4:11 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >It's just as easy to use IFF_ flags directly,
> >there's no point in adding our own defines.
> >
> >Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >---
> > drivers/net/tun.c | 62
> >+++++++++++++++++++++++++------------------------------
> > 1 file changed, 28 insertions(+), 34 deletions(-)
> >
> >diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>
> Patch looks fine, but I don't see the reason that why not squash patch 37
> into this.
>
> [..]
squashing is always easy, I thought review is easier if at each step
identity to original code can be verified directly.
^ permalink raw reply
* Re: [PATCH v6 37/46] tun: move internal flag defines out of uapi
From: Michael S. Tsirkin @ 2014-11-29 17:17 UTC (permalink / raw)
To: Jason Wang
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Miller,
cornelia.huck-tA70FqPdS9bQT0dZR+AlfA,
rusty-8fk3Idey6ehBDgjK7y7TUQ, nab-IzHhD5pYlfBP7FQvKIMDCQ,
pbonzini-H+wXaHxf7aLQT0dZR+AlfA,
thuth-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
dahi-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, Zhi Yong Wu, Ben Hutchings,
Herbert Xu, Tom Herbert, Masatake YAMATO, Xi Wang,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1417162052.5822.0-LLcwxoN42L4NLKR9yMNcA1aTQe2KTcn/@public.gmane.org>
On Fri, Nov 28, 2014 at 08:15:32AM +0008, Jason Wang wrote:
>
>
> On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >TUN_ flags are internal and never exposed
> >to userspace. Any application using it is almost
> >certainly buggy.
> >
> >Move them out to tun.c, we'll remove them in follow-up patches.
> >
> >Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >---
> > include/uapi/linux/if_tun.h | 16 ++--------
> > drivers/net/tun.c | 74
> >++++++++++++++-------------------------------
> > 2 files changed, 26 insertions(+), 64 deletions(-)
> >
> >diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> >index e9502dd..277a260 100644
> >--- a/include/uapi/linux/if_tun.h
> >+++ b/include/uapi/linux/if_tun.h
> >@@ -22,21 +22,11 @@
> > /* Read queue size */
> > #define TUN_READQ_SIZE 500
> >-
> >-/* TUN device flags */
> >-#define TUN_TUN_DEV 0x0001
> >-#define TUN_TAP_DEV 0x0002
> >+/* TUN device type flags: deprecated. Use IFF_TUN/IFF_TAP instead. */
> >+#define TUN_TUN_DEV IFF_TUN
> >+#define TUN_TAP_DEV IFF_TAP
> > #define TUN_TYPE_MASK 0x000f
> >-#define TUN_FASYNC 0x0010
> >-#define TUN_NOCHECKSUM 0x0020
> >-#define TUN_NO_PI 0x0040
> >-/* This flag has no real effect */
> >-#define TUN_ONE_QUEUE 0x0080
> >-#define TUN_PERSIST 0x0100
> >-#define TUN_VNET_HDR 0x0200
> >-#define TUN_TAP_MQ 0x0400
> >-
> > /* Ioctl defines */
> > #define TUNSETNOCSUM _IOW('T', 200, int) #define TUNSETDEBUG
> >_IOW('T', 201, int) diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >index 9dd3746..bc89d07 100644
> >--- a/drivers/net/tun.c
> >+++ b/drivers/net/tun.c
> >@@ -103,6 +103,21 @@ do { \
> > } while (0)
> > #endif
> >+/* TUN device flags */
> >+
> >+/* IFF_ATTACH_QUEUE is never stored in device flags,
> >+ * overload it to mean fasync when stored there.
> >+ */
> >+#define TUN_FASYNC IFF_ATTACH_QUEUE
> >+#define TUN_NO_PI IFF_NO_PI
> >+/* This flag has no real effect */
> >+#define TUN_ONE_QUEUE IFF_ONE_QUEUE
> >+#define TUN_PERSIST IFF_PERSIST
> >+#define TUN_VNET_HDR IFF_VNET_HDR
> >+#define TUN_TAP_MQ IFF_MULTI_QUEUE
> >+
> >+#define TUN_FEATURES (IFF_NO_PI | IFF_ONE_QUEUE | IFF_VNET_HDR | \
> >+ IFF_MULTI_QUEUE)
> > #define GOODCOPY_LEN 128
> > #define FLT_EXACT_COUNT 8
> >@@ -1521,32 +1536,7 @@ static struct proto tun_proto = {
> > static int tun_flags(struct tun_struct *tun)
> > {
> >- int flags = 0;
> >-
> >- if (tun->flags & TUN_TUN_DEV)
> >- flags |= IFF_TUN;
> >- else
> >- flags |= IFF_TAP;
> >-
> >- if (tun->flags & TUN_NO_PI)
> >- flags |= IFF_NO_PI;
> >-
> >- /* This flag has no real effect. We track the value for backwards
> >- * compatibility.
> >- */
> >- if (tun->flags & TUN_ONE_QUEUE)
> >- flags |= IFF_ONE_QUEUE;
> >-
> >- if (tun->flags & TUN_VNET_HDR)
> >- flags |= IFF_VNET_HDR;
> >-
> >- if (tun->flags & TUN_TAP_MQ)
> >- flags |= IFF_MULTI_QUEUE;
> >-
> >- if (tun->flags & TUN_PERSIST)
> >- flags |= IFF_PERSIST;
> >-
> >- return flags;
> >+ return tun->flags & (TUN_FEATURES | IFF_PERSIST | IFF_TUN | IFF_TAP);
> > }
> > static ssize_t tun_show_flags(struct device *dev, struct
> >device_attribute *attr,
> >@@ -1706,28 +1696,8 @@ static int tun_set_iff(struct net *net, struct file
> >*file, struct ifreq *ifr)
> > tun_debug(KERN_INFO, tun, "tun_set_iff\n");
> >- if (ifr->ifr_flags & IFF_NO_PI)
> >- tun->flags |= TUN_NO_PI;
> >- else
> >- tun->flags &= ~TUN_NO_PI;
> >-
> >- /* This flag has no real effect. We track the value for backwards
> >- * compatibility.
> >- */
> >- if (ifr->ifr_flags & IFF_ONE_QUEUE)
> >- tun->flags |= TUN_ONE_QUEUE;
> >- else
> >- tun->flags &= ~TUN_ONE_QUEUE;
> >-
> >- if (ifr->ifr_flags & IFF_VNET_HDR)
> >- tun->flags |= TUN_VNET_HDR;
> >- else
> >- tun->flags &= ~TUN_VNET_HDR;
> >-
> >- if (ifr->ifr_flags & IFF_MULTI_QUEUE)
> >- tun->flags |= TUN_TAP_MQ;
> >- else
> >- tun->flags &= ~TUN_TAP_MQ;
> >+ tun->flags = (tun->flags & ~TUN_FEATURES) |
> >+ (ifr->ifr_flags & TUN_FEATURES);
> > /* Make sure persistent devices do not get stuck in
> > * xoff state.
> >@@ -1890,9 +1860,11 @@ static long __tun_chr_ioctl(struct file *file,
> >unsigned int cmd,
> > if (cmd == TUNGETFEATURES) {
> > /* Currently this just means: "what IFF flags are valid?".
> > * This is needed because we never checked for invalid flags on
> >- * TUNSETIFF. */
> >- return put_user(IFF_TUN | IFF_TAP | IFF_NO_PI | IFF_ONE_QUEUE |
> >- IFF_VNET_HDR | IFF_MULTI_QUEUE,
> >+ * TUNSETIFF. Why do we report IFF_TUN and IFF_TAP which are
> >+ * not legal for TUNSETIFF here? It's probably a bug, but it
> >+ * doesn't seem to be worth fixing.
> >+ */
>
> The question is not very clear. IFF_TUN and IFF_TAP are legal for
> ifr.ifr_flags during TUNSETIFF. No?
Absolutely. I'm not sure what I meant anymore. I will drop this chunk -
either by replacing this patch if I have to post another version, or
by a separate patch if I don't.
> >
> >+ return put_user(IFF_TUN | IFF_TAP | TUN_FEATURES,
> > (unsigned int __user*)argp);
> > } else if (cmd == TUNSETQUEUE)
> > return tun_set_queue(file, &ifr);
> >--
> >MST
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe netdev" 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
* Re: [PATCH, regression against -rc6] net/stmmac: fix one more regression from filter bins setting
From: Arnd Bergmann @ 2014-11-29 16:29 UTC (permalink / raw)
To: David Miller
Cc: netdev, khilman, Huacai Chen, Giuseppe Cavallaro, olof,
linux-arm-kernel
In-Reply-To: <5388366.Y15J6TLmlA@wuerfel>
On Saturday 29 November 2014 13:03:19 Arnd Bergmann wrote:
> I've sent this off to the build bots, but it will probably take some more
> time before it's been tested on all the ARM machines and I might not be
> there to see the results, so I'm sending it out now for review. I will
> reply once I am sure the problem is fixed.
With this patch applied, both boot bots are back to 100% success now,
all eight failing machines are working again.
Arnd
^ permalink raw reply
* Re: [PATCH, regression against -rc6] net/stmmac: fix one more regression from filter bins setting
From: Arnd Bergmann @ 2014-11-29 16:26 UTC (permalink / raw)
To: 陈华才
Cc: David Miller, netdev, khilman, Giuseppe Cavallaro, olof,
linux-arm-kernel
In-Reply-To: <tencent_0FE25D6968E3D939662D9E00@qq.com>
On Saturday 29 November 2014 23:44:23 陈华才 wrote:
> Hi, Arnd,
>
> Maybe this patch is better?
> http://www.spinics.net/lists/netdev/msg306413.html
Yes, that would work too. I also checked that my version works now.
I'm fine with either one, as long as a fix makes it into 3.18.
Arnd
> ------------------ Original ------------------
> From: "Arnd Bergmann"<arnd@arndb.de>;
> Date: Sat, Nov 29, 2014 08:03 PM
> To: "David Miller"<davem@davemloft.net>;
> Cc: "netdev"<netdev@vger.kernel.org>; "khilman"<khilman@kernel.org>; "Huacai Chen"<chenhc@lemote.com>; "Giuseppe Cavallaro"<peppe.cavallaro@st.com>; "olof"<olof@lixom.net>; "linux-arm-kernel"<linux-arm-kernel@lists.infradead.org>;
> Subject: [PATCH, regression against -rc6] net/stmmac: fix one more regression from filter bins setting
>
> Commit 571dcfde2371 ("stmmac: platform: fix default values of the filter
> bins setting") tries to fix a regression in the stmmac driver, but instead
> it also causes a new regression and makes all DT-based users of this
> driver fail, as found by the automated ARM boot testing:
>
> [ 0.881667] Unable to handle kernel NULL pointer dereference at virtual address 00000048
> [ 0.889784] pgd = c0204000
> [ 0.892502] [00000048] *pgd=00000000
> [ 0.896090] Internal error: Oops: 805 [#1] SMP ARM
> [ 0.900874] Modules linked in:
> [ 0.903943] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-00150-g8891063 #1
> [ 0.911502] task: ee06c000 ti: ee070000 task.ti: ee070000
> [ 0.916899] PC is at stmmac_pltfr_probe+0x40/0x5d0
> [ 0.921689] LR is at devm_ioremap_nocache+0x54/0x74
> [ 0.926561] pc : [<c0642df8>] lr : [<c0430508>] psr: 80000153
> [ 0.926561] sp : ee071e50 ip : 00000000 fp : 00000000
> [ 0.938020] r10: c0c14f74 r9 : ee3ca2c0 r8 : ee101c10
> [ 0.943237] r7 : f00c0000 r6 : ee101c00 r5 : ee101c10 r4 : 00000000
> [ 0.949755] r3 : 00000001 r2 : 00000040 r1 : a0000153 r0 : f00c0000
> [ 0.956274] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel
> [ 0.963658] Control: 10c5387d Table: 4020406a DAC: 00000015
> [ 0.969395] Process swapper/0 (pid: 1, stack limit = 0xee070248)
> [ 0.975384] Stack: (0xee071e50 to 0xee072000)
> [ 0.979738] 1e40: c0d83aa0 ee101c10 c0cfc030 fffffdfb
> [ 0.987906] 1e60: 00000000 ee3ca2c0 c0c14f74 c056c6d0 c056c68c c0d83aa0 ee101c10 00000000
> [ 0.996075] 1e80: c0cfc030 c056af54 ee101c10 c0cfc030 ee101c44 c0cf15f8 c0c616a0 c056b158
> [ 1.004243] 1ea0: 00000000 c0cfc030 c056b0cc c0569514 ee01675c ee0d86b4 c0cfc030 ee3c9300
> [ 1.012412] 1ec0: 00000000 c056a77c c0ad7be0 ee071ef8 c0cfc030 c0cfc030 ee070000 c0be0ca8
> [ 1.020580] 1ee0: 00000000 c056b77c 00000000 c0c616a0 ee070000 c0be0cbc c0c616a0 c0208cb0
> [ 1.028750] 1f00: ee011900 c0d6c324 ee0b6600 c08a6748 00000000 00000000 00006a40 c034782c
> [ 1.036918] 1f20: 00000000 c0ca1aac 60000153 00000001 c0b9f598 ef7fcd9c ef7fcd99 c025ffa0
> [ 1.045087] 1f40: c0ae650c ef7fcda0 00000006 00000006 c0ca1a94 c0c50d44 00000006 c0c14f6c
> [ 1.053255] 1f60: c0d46a40 c0d46a40 000000ff c0c14f74 00000000 c0b9fda4 00000006 00000006
> [ 1.061423] 1f80: c0b9f598 9c041042 00000000 c089460c 00000000 00000000 00000000 00000000
> [ 1.069591] 1fa0: 00000000 c0894614 00000000 c020e878 00000000 00000000 00000000 00000000
> [ 1.077759] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 1.085926] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 18044434 8a444414
> [ 1.094113] [<c0642df8>] (stmmac_pltfr_probe) from [<c056c6d0>] (platform_drv_probe+0x44/0xa4)
> [ 1.102719] [<c056c6d0>] (platform_drv_probe) from [<c056af54>] (driver_probe_device+0x108/0x23c)
> [ 1.111582] [<c056af54>] (driver_probe_device) from [<c056b158>] (__driver_attach+0x8c/0x90)
> [ 1.120011] [<c056b158>] (__driver_attach) from [<c0569514>] (bus_for_each_dev+0x6c/0xa0)
> [ 1.128182] [<c0569514>] (bus_for_each_dev) from [<c056a77c>] (bus_add_driver+0x148/0x1f0)
> [ 1.136438] [<c056a77c>] (bus_add_driver) from [<c056b77c>] (driver_register+0x78/0xf8)
> [ 1.144434] [<c056b77c>] (driver_register) from [<c0be0cbc>] (stmmac_init+0x14/0x3c)
> [ 1.152176] [<c0be0cbc>] (stmmac_init) from [<c0208cb0>] (do_one_initcall+0x8c/0x1c4)
> [ 1.160004] [<c0208cb0>] (do_one_initcall) from [<c0b9fda4>] (kernel_init_freeable+0x13c/0x1dc)
> [ 1.168699] [<c0b9fda4>] (kernel_init_freeable) from [<c0894614>] (kernel_init+0x8/0xe8)
> [ 1.176785] [<c0894614>] (kernel_init) from [<c020e878>] (ret_from_fork+0x14/0x3c)
> [ 1.184348] Code: 8a0000fe e5964064 e3a02040 e3a03001 (e5842048)
> [ 1.190501] ---[ end trace 724411f6ae142767 ]---
> [ 1.195158] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> Where the original patch left out the non-DT probe method, the fix that
> was merged for -rc7 instead broke the DT path by dereferencing a NULL
> pointer.
>
> This patch reverts the broken fix and tries to put the initialization
> for multicast_filter_bins/unicast_filter_entries in the right place,
> which prevents non-DT users from overriding the defaults as a side
> effect, as before. Alternatively, one could change all instances of
> the platform_data definition to set the values themselves, but it's
> probably safer to do that as a follow-up.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 571dcfde2371 ("stmmac: platform: fix default values of the filter bins setting")
> Link: http://arm-soc.lixom.net/bootlogs/mainline/v3.18-rc6-150-g8891063/cubie2-arm-multi_v7_defconfig.html
> ---
> I've sent this off to the build bots, but it will probably take some more
> time before it's been tested on all the ARM machines and I might not be
> there to see the results, so I'm sending it out now for review. I will
> reply once I am sure the problem is fixed.
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 5b0da3986216..94c3cefaa2c3 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -177,6 +177,12 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
> */
> plat->maxmtu = JUMBO_LEN;
>
> + /* Set default value for multicast hash bins */
> + plat->multicast_filter_bins = HASH_TABLE_SIZE;
> +
> + /* Set default value for unicast filter entries */
> + plat->unicast_filter_entries = 1;
> +
> /*
> * Currently only the properties needed on SPEAr600
> * are provided. All other properties should be added
> @@ -264,13 +270,6 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
> return PTR_ERR(addr);
>
> plat_dat = dev_get_platdata(&pdev->dev);
> -
> - /* Set default value for multicast hash bins */
> - plat_dat->multicast_filter_bins = HASH_TABLE_SIZE;
> -
> - /* Set default value for unicast filter entries */
> - plat_dat->unicast_filter_entries = 1;
> -
> if (pdev->dev.of_node) {
> if (!plat_dat)
> plat_dat = devm_kzalloc(&pdev->dev,
> @@ -286,6 +285,12 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
> pr_err("%s: main dt probe failed", __func__);
> return ret;
> }
> + } else {
> + /* Set default value for multicast hash bins */
> + plat_dat->multicast_filter_bins = HASH_TABLE_SIZE;
> +
> + /* Set default value for unicast filter entries */
> + plat_dat->unicast_filter_entries = 1;
> }
>
> /* Custom setup (if needed) */
^ permalink raw reply
* Re:[PATCH, regression against -rc6] net/stmmac: fix one more regression from filter bins setting
From: 陈华才 @ 2014-11-29 15:44 UTC (permalink / raw)
To: Arnd Bergmann, David Miller
Cc: olof, netdev, Giuseppe Cavallaro, linux-arm-kernel, khilman
In-Reply-To: <5388366.Y15J6TLmlA@wuerfel>
Hi, Arnd,
Maybe this patch is better?
http://www.spinics.net/lists/netdev/msg306413.html
Huacai
------------------ Original ------------------
From: "Arnd Bergmann"<arnd@arndb.de>;
Date: Sat, Nov 29, 2014 08:03 PM
To: "David Miller"<davem@davemloft.net>;
Cc: "netdev"<netdev@vger.kernel.org>; "khilman"<khilman@kernel.org>; "Huacai Chen"<chenhc@lemote.com>; "Giuseppe Cavallaro"<peppe.cavallaro@st.com>; "olof"<olof@lixom.net>; "linux-arm-kernel"<linux-arm-kernel@lists.infradead.org>;
Subject: [PATCH, regression against -rc6] net/stmmac: fix one more regression from filter bins setting
Commit 571dcfde2371 ("stmmac: platform: fix default values of the filter
bins setting") tries to fix a regression in the stmmac driver, but instead
it also causes a new regression and makes all DT-based users of this
driver fail, as found by the automated ARM boot testing:
[ 0.881667] Unable to handle kernel NULL pointer dereference at virtual address 00000048
[ 0.889784] pgd = c0204000
[ 0.892502] [00000048] *pgd=00000000
[ 0.896090] Internal error: Oops: 805 [#1] SMP ARM
[ 0.900874] Modules linked in:
[ 0.903943] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-00150-g8891063 #1
[ 0.911502] task: ee06c000 ti: ee070000 task.ti: ee070000
[ 0.916899] PC is at stmmac_pltfr_probe+0x40/0x5d0
[ 0.921689] LR is at devm_ioremap_nocache+0x54/0x74
[ 0.926561] pc : [<c0642df8>] lr : [<c0430508>] psr: 80000153
[ 0.926561] sp : ee071e50 ip : 00000000 fp : 00000000
[ 0.938020] r10: c0c14f74 r9 : ee3ca2c0 r8 : ee101c10
[ 0.943237] r7 : f00c0000 r6 : ee101c00 r5 : ee101c10 r4 : 00000000
[ 0.949755] r3 : 00000001 r2 : 00000040 r1 : a0000153 r0 : f00c0000
[ 0.956274] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel
[ 0.963658] Control: 10c5387d Table: 4020406a DAC: 00000015
[ 0.969395] Process swapper/0 (pid: 1, stack limit = 0xee070248)
[ 0.975384] Stack: (0xee071e50 to 0xee072000)
[ 0.979738] 1e40: c0d83aa0 ee101c10 c0cfc030 fffffdfb
[ 0.987906] 1e60: 00000000 ee3ca2c0 c0c14f74 c056c6d0 c056c68c c0d83aa0 ee101c10 00000000
[ 0.996075] 1e80: c0cfc030 c056af54 ee101c10 c0cfc030 ee101c44 c0cf15f8 c0c616a0 c056b158
[ 1.004243] 1ea0: 00000000 c0cfc030 c056b0cc c0569514 ee01675c ee0d86b4 c0cfc030 ee3c9300
[ 1.012412] 1ec0: 00000000 c056a77c c0ad7be0 ee071ef8 c0cfc030 c0cfc030 ee070000 c0be0ca8
[ 1.020580] 1ee0: 00000000 c056b77c 00000000 c0c616a0 ee070000 c0be0cbc c0c616a0 c0208cb0
[ 1.028750] 1f00: ee011900 c0d6c324 ee0b6600 c08a6748 00000000 00000000 00006a40 c034782c
[ 1.036918] 1f20: 00000000 c0ca1aac 60000153 00000001 c0b9f598 ef7fcd9c ef7fcd99 c025ffa0
[ 1.045087] 1f40: c0ae650c ef7fcda0 00000006 00000006 c0ca1a94 c0c50d44 00000006 c0c14f6c
[ 1.053255] 1f60: c0d46a40 c0d46a40 000000ff c0c14f74 00000000 c0b9fda4 00000006 00000006
[ 1.061423] 1f80: c0b9f598 9c041042 00000000 c089460c 00000000 00000000 00000000 00000000
[ 1.069591] 1fa0: 00000000 c0894614 00000000 c020e878 00000000 00000000 00000000 00000000
[ 1.077759] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1.085926] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 18044434 8a444414
[ 1.094113] [<c0642df8>] (stmmac_pltfr_probe) from [<c056c6d0>] (platform_drv_probe+0x44/0xa4)
[ 1.102719] [<c056c6d0>] (platform_drv_probe) from [<c056af54>] (driver_probe_device+0x108/0x23c)
[ 1.111582] [<c056af54>] (driver_probe_device) from [<c056b158>] (__driver_attach+0x8c/0x90)
[ 1.120011] [<c056b158>] (__driver_attach) from [<c0569514>] (bus_for_each_dev+0x6c/0xa0)
[ 1.128182] [<c0569514>] (bus_for_each_dev) from [<c056a77c>] (bus_add_driver+0x148/0x1f0)
[ 1.136438] [<c056a77c>] (bus_add_driver) from [<c056b77c>] (driver_register+0x78/0xf8)
[ 1.144434] [<c056b77c>] (driver_register) from [<c0be0cbc>] (stmmac_init+0x14/0x3c)
[ 1.152176] [<c0be0cbc>] (stmmac_init) from [<c0208cb0>] (do_one_initcall+0x8c/0x1c4)
[ 1.160004] [<c0208cb0>] (do_one_initcall) from [<c0b9fda4>] (kernel_init_freeable+0x13c/0x1dc)
[ 1.168699] [<c0b9fda4>] (kernel_init_freeable) from [<c0894614>] (kernel_init+0x8/0xe8)
[ 1.176785] [<c0894614>] (kernel_init) from [<c020e878>] (ret_from_fork+0x14/0x3c)
[ 1.184348] Code: 8a0000fe e5964064 e3a02040 e3a03001 (e5842048)
[ 1.190501] ---[ end trace 724411f6ae142767 ]---
[ 1.195158] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Where the original patch left out the non-DT probe method, the fix that
was merged for -rc7 instead broke the DT path by dereferencing a NULL
pointer.
This patch reverts the broken fix and tries to put the initialization
for multicast_filter_bins/unicast_filter_entries in the right place,
which prevents non-DT users from overriding the defaults as a side
effect, as before. Alternatively, one could change all instances of
the platform_data definition to set the values themselves, but it's
probably safer to do that as a follow-up.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 571dcfde2371 ("stmmac: platform: fix default values of the filter bins setting")
Link: http://arm-soc.lixom.net/bootlogs/mainline/v3.18-rc6-150-g8891063/cubie2-arm-multi_v7_defconfig.html
---
I've sent this off to the build bots, but it will probably take some more
time before it's been tested on all the ARM machines and I might not be
there to see the results, so I'm sending it out now for review. I will
reply once I am sure the problem is fixed.
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 5b0da3986216..94c3cefaa2c3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -177,6 +177,12 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
*/
plat->maxmtu = JUMBO_LEN;
+ /* Set default value for multicast hash bins */
+ plat->multicast_filter_bins = HASH_TABLE_SIZE;
+
+ /* Set default value for unicast filter entries */
+ plat->unicast_filter_entries = 1;
+
/*
* Currently only the properties needed on SPEAr600
* are provided. All other properties should be added
@@ -264,13 +270,6 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
return PTR_ERR(addr);
plat_dat = dev_get_platdata(&pdev->dev);
-
- /* Set default value for multicast hash bins */
- plat_dat->multicast_filter_bins = HASH_TABLE_SIZE;
-
- /* Set default value for unicast filter entries */
- plat_dat->unicast_filter_entries = 1;
-
if (pdev->dev.of_node) {
if (!plat_dat)
plat_dat = devm_kzalloc(&pdev->dev,
@@ -286,6 +285,12 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
pr_err("%s: main dt probe failed", __func__);
return ret;
}
+ } else {
+ /* Set default value for multicast hash bins */
+ plat_dat->multicast_filter_bins = HASH_TABLE_SIZE;
+
+ /* Set default value for unicast filter entries */
+ plat_dat->unicast_filter_entries = 1;
}
/* Custom setup (if needed) */
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox