* 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 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 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
* [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
* [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 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
* 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
* 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: [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
* [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 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
* 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] 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: [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 net] bond: Check length of IFLA_BOND_ARP_IP_TARGET attributes
From: David Miller @ 2014-11-30 4:49 UTC (permalink / raw)
To: tgraf; +Cc: netdev, sfeldma
In-Reply-To: <a7c193909c30dbc19b4f279a3f7ba757107641d3.1417044113.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Thu, 27 Nov 2014 00:22:33 +0100
> 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>
Applied, and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] ipvlan: ipvlan depends on INET and IPV6
From: David Miller @ 2014-11-30 4:53 UTC (permalink / raw)
To: maheshb; +Cc: netdev, jim.epost
In-Reply-To: <1417065225-784-1-git-send-email-maheshb@google.com>
From: Mahesh Bandewar <maheshb@google.com>
Date: Wed, 26 Nov 2014 21:13:45 -0800
> This driver uses ip_out_local() and ip6_route_output() which are
> defined only if CONFIG_INET and CONFIG_IPV6 are enabled respectively.
>
> Reported-by: Jim Davis <jim.epost@gmail.com>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Applied, thanks for fixing this.
^ permalink raw reply
* Re: [PATCH net-next V3] tun/macvtap: use consume_skb() instead of kfree_skb() when needed
From: David Miller @ 2014-11-30 5:03 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, mst, eric.dumazet
In-Reply-To: <1417070166-7026-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Thu, 27 Nov 2014 14:36:06 +0800
> To be more friendly with drop monitor, we should only call kfree_skb() when
> the packets were dropped and use consume_skb() in other cases.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> Changes from V2:
> - use unlikely() when necessary
> Changes from V1:
> - check the return value of tun/macvtap_put_user()
This does not apply cleanly to net-next and will thus need to
be respun, thanks.
^ permalink raw reply
* Re: [PATCH net-next 3/6] samples: bpf: example of stateful socket filtering
From: David Miller @ 2014-11-30 5:01 UTC (permalink / raw)
To: ast-uqk4Ao+rVK5Wk0Htik3J/w
Cc: mingo-DgEjT+Ai2ygdnm+yROfE0A, luto-kltTT9wpgjJwATOyAt5JVQ,
dborkman-H+wXaHxf7aLQT0dZR+AlfA,
hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1417066951-1999-4-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Date: Wed, 26 Nov 2014 21:42:28 -0800
> this socket filter example does:
> - creates arraymap in kernel with key 4 bytes and value 8 bytes
>
> - loads eBPF program:
> r0 = skb[14 + 9]; // load one byte of ip->proto
...
> + BPF_LD_ABS(BPF_B, 14 + 9 /* R0 = ip->proto */),
I do not want anything having to do with fixed offsets from
the skb.
Nothing should know where things are in the SKB structure,
especially user facing things.
That's why we have explicit BPF operations for fetching
specific SKB members, so that the layout is completely
transparent to the entity generating BPF programs.
Besides retaining the flexibility of changing the SKB
layout arbitrarily without breaking bpf programs, there
are also security considerations from allowing bpf
programs to load arbitrary offsets.
Sorry, I do not like this patch series at all.
^ permalink raw reply
* Re: [PATCH net] rtnetlink: release net refcnt on error in do_setlink()
From: David Miller @ 2014-11-30 5:07 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, ebiederm
In-Reply-To: <1417079775-9287-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 27 Nov 2014 10:16:15 +0100
> rtnl_link_get_net() holds a reference on the 'struct net', we need to release
> it in case of error.
>
> CC: Eric W. Biederman <ebiederm@xmission.com>
> Fixes: b51642f6d77b ("net: Enable a userns root rtnl calls that are safe for unprivilged users")
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] vhost: remove unnecessary forward declarations in vhost.h
From: David Miller @ 2014-11-30 5:04 UTC (permalink / raw)
To: jasowang; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <1417070481-10331-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Thu, 27 Nov 2014 14:41:21 +0800
> Signed-off-by: Jason Wang <jasowang@redhat.com>
I don't think generic vhost patches should go via my tree.
If you disagree, let me know why, thanks :)
^ permalink raw reply
* Re: [PATCH V2] stmmac: platform: Move plat_dat checking earlier
From: David Miller @ 2014-11-30 5:12 UTC (permalink / raw)
To: chenhc; +Cc: peppe.cavallaro, vbridgers2013, netdev
In-Reply-To: <1417093534-21884-1-git-send-email-chenhc@lemote.com>
From: Huacai Chen <chenhc@lemote.com>
Date: Thu, 27 Nov 2014 21:05:34 +0800
> Original code only check/alloc plat_dat for the CONFIG_OF case, this
> patch check/alloc it earlier and unconditionally to avoid kernel build
> warnings:
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:275
> stmmac_pltfr_probe() warn: variable dereferenced before check 'plat_dat'
>
> V2: Fix coding style.
>
> Signed-off-by: Huacai Chen <chenhc@lemote.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] netpoll: delete defconfig references to obsolete NETPOLL_TRAP
From: David Miller @ 2014-11-30 5:14 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev
In-Reply-To: <1417102096-16537-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 27 Nov 2014 10:28:16 -0500
> In commit 9c62a68d13119a1ca9718381d97b0cb415ff4e9d ("netpoll:
> Remove dead packet receive code (CONFIG_NETPOLL_TRAP)") this
> Kconfig option was removed. So remove references to it from
> all defconfigs as well.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Applied, thanks Paul.
^ permalink raw reply
* Re: [PATCH v3] sh_eth: Fix skb alloc size and alignment adjust rule.
From: David Miller @ 2014-11-30 5:12 UTC (permalink / raw)
To: ykaneko0929; +Cc: netdev, horms, magnus.damm, linux-sh
In-Reply-To: <1417088040-32144-1-git-send-email-ykaneko0929@gmail.com>
From: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Date: Thu, 27 Nov 2014 20:34:00 +0900
> From: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
>
> In the current driver, allocation size of skb does not care the alignment
> adjust after allocation.
> And also, in the current implementation, buffer alignment method by
> sh_eth_set_receive_align function has a bug that this function displace
> buffer start address forcedly when the alignment is corrected.
> In the result, tail of the skb will exceed allocated area and kernel panic
> will be occurred.
> This patch fix this issue.
>
> Signed-off-by: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/6] samples: bpf: example of stateful socket filtering
From: Alexei Starovoitov @ 2014-11-30 6:24 UTC (permalink / raw)
To: David Miller
Cc: Ingo Molnar, Andy Lutomirski, Daniel Borkmann,
Hannes Frederic Sowa, Eric Dumazet, Linux API,
Network Development, LKML
In-Reply-To: <20141129.210158.2021042941461629799.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Sat, Nov 29, 2014 at 9:01 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
> Date: Wed, 26 Nov 2014 21:42:28 -0800
>
>> this socket filter example does:
>> - creates arraymap in kernel with key 4 bytes and value 8 bytes
>>
>> - loads eBPF program:
>> r0 = skb[14 + 9]; // load one byte of ip->proto
> ...
>> + BPF_LD_ABS(BPF_B, 14 + 9 /* R0 = ip->proto */),
>
> I do not want anything having to do with fixed offsets from
> the skb.
>
> Nothing should know where things are in the SKB structure,
> especially user facing things.
>
> That's why we have explicit BPF operations for fetching
> specific SKB members, so that the layout is completely
> transparent to the entity generating BPF programs.
>
> Besides retaining the flexibility of changing the SKB
> layout arbitrarily without breaking bpf programs, there
> are also security considerations from allowing bpf
> programs to load arbitrary offsets.
>
> Sorry, I do not like this patch series at all.
sigh.
You misunderstood one wrong comment in the whole series.
r0 = skb[14 + 9]; // load one byte of ip->proto
is saying
r0 = skb->data[14 + 9]; // load one byte of ip->proto
it's loading one byte of packet payload and
not one byte of skb structure.
There are plenty of other comments where I mentioned that.
Including cover letter:
"Though native eBPF programs are way more powerful than classic filters
(attachable through similar setsockopt() call), they don't have skb field
accessors yet. Like skb->pkt_type, skb->dev->ifindex are not accessible.
There are sevaral ways to achieve that. That will be in the next set of patches.
So in this set native eBPF programs can only read data from packet and
access maps"
and in patch #2:
+static bool sock_filter_is_valid_access(int off, int size, enum
bpf_access_type type)
+{
+ /* skb fields cannot be accessed yet */
+ return false;
+}
In other words, there is no way to access skb fields yet.
There are several different ways I've implemented to
access skb fields, but they all had their cons and pros, so I
dropped them all to focus on basic things first.
Which is: read packet data and access maps.
Please let me know if you want me to fix this comment
in this patch of sample code.
^ permalink raw reply
* Re: tun issue after e0b46d0ee9c: tun: Use iovec iterators
From: Herbert Xu @ 2014-11-30 8:21 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: netdev
In-Reply-To: <547954B9.2050804@redhat.com>
On Sat, Nov 29, 2014 at 03:08:09AM -0200, Marcelo Ricardo Leitner wrote:
> On 28-11-2014 21:59, Herbert Xu wrote:
> >On Fri, Nov 28, 2014 at 05:25:27PM -0200, Marcelo Ricardo Leitner wrote:
> >>
> >>I saw there are tun updates on Dave's queue but none seemed to handle this.
> >>
> >>I can't use current net-next
> >>(799d2fff1858004526ad75d66a5dd8a5cce6ad40) on a kvm hypervisor
> >>because tun got clogged somehow. Bisected down to:
> >>
> >>commit e0b46d0ee9c240c7430a47e9b0365674d4a04522
> >>Author: Herbert Xu <herbert@gondor.apana.org.au>
> >>Date: Fri Nov 7 21:22:23 2014 +0800
> >
> >Does this patch help?
>
> Yay, it does! Works for me, thanks Herbert.
> I didn't test performance, but dhcp could get through.
>
> Are you sure about the Fixes tag? Because bisect really pointed to e0b46d0ee9c.
Well according to your report you were having problems with
tun_get_user. The bug I introduced was in tun_put_user and has
already been fixed by Jason Wang.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ 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