* Re: [GIT] [3.20] NFC update
From: David Miller @ 2015-01-29 6:50 UTC (permalink / raw)
To: sameo; +Cc: netdev
In-Reply-To: <20150129005216.GA1137@ribalta.ger.corp.intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
Date: Thu, 29 Jan 2015 01:52:16 +0100
> This is the first NFC pull request for 3.20.
>
> With this one we have:
>
> - Secure element support for the ST Micro st21nfca driver. This depends
> on a few HCI internal changes in order for example to support more
> than one secure element per controller.
>
> - ACPI support for NXP's pn544 HCI driver. This controller is found on
> many x86 SoCs and is typically enumerated on the ACPI bus there.
>
> - A few st21nfca and st21nfcb fixes. Since they're not critical fixes,
> I assumed it's too late for a 3.19 inclusion. Please let me know if
> you'd prefer to see them going through a net pull request instead.
Applied, thanks Samuel.
^ permalink raw reply
* Re: [GIT] [3.20] NFC update
From: David Miller @ 2015-01-29 7:02 UTC (permalink / raw)
To: sameo; +Cc: netdev
In-Reply-To: <20150129005216.GA1137@ribalta.ger.corp.intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
Date: Thu, 29 Jan 2015 01:52:16 +0100
> This is the first NFC pull request for 3.20.
>
> With this one we have:
>
> - Secure element support for the ST Micro st21nfca driver. This depends
> on a few HCI internal changes in order for example to support more
> than one secure element per controller.
>
> - ACPI support for NXP's pn544 HCI driver. This controller is found on
> many x86 SoCs and is typically enumerated on the ACPI bus there.
>
> - A few st21nfca and st21nfcb fixes. Since they're not critical fixes,
> I assumed it's too late for a 3.19 inclusion. Please let me know if
> you'd prefer to see them going through a net pull request instead.
Pulled, thanks Sam.
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: Add support for checksums on UDP tunnels.
From: David Miller @ 2015-01-29 7:04 UTC (permalink / raw)
To: jesse; +Cc: pshelar, netdev, dev
In-Reply-To: <1422491566-80453-1-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Wed, 28 Jan 2015 16:32:46 -0800
> Currently, it isn't possible to request checksums on the outer UDP
> header of tunnels - the TUNNEL_CSUM flag is ignored. This adds
> support for requesting that UDP checksums be computed on transmit
> and properly reported if they are present on receive.
>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
From: Alexei Starovoitov @ 2015-01-29 7:04 UTC (permalink / raw)
To: Namhyung Kim
Cc: Steven Rostedt, Ingo Molnar, Arnaldo Carvalho de Melo, Jiri Olsa,
Masami Hiramatsu, Linux API, Network Development, LKML
On Wed, Jan 28, 2015 at 10:41 PM, Namhyung Kim <namhyung@kernel.org> wrote:
>
> I think it's not a problem of bpf. An user process can be killed
> anytime while it enabed events without bpf. The only thing it should
> care is the auto-unload IMHO.
ok. I think it does indeed make sense to decouple the logic.
We can add 'auto_enable' file to achieve desired Ctrl-C behavior.
While the 'auto_enable' file is open the event will be enabled
and writes to 'enable' file will be ignored.
As soon as file closes, the event is auto-disabled.
Then user space will use 'bpf' file to attach/auto-unload
and 'auto_enable' file together.
Seem there would be a use for such 'auto_enable'
without bpf as well.
> I'm okay for not calling bpf program in NMI but not for disabling events.
>
> Suppose an user was collecting an event (including in NMI) and then
> [s]he also wanted to run a bpf program. So [s]he wrote a program
> always return 1. But after attaching the program, it didn't record
> the event in NMI.. Isn't that a problem?
ok, I think 'if (in_nmi()) return 1;' will work then, right?
Or you're thinking something else ?
> Right. I think bpf programs belong to a user process but events are
> global resource. Maybe you also need to consider attaching bpf
> program via perf (ioctl?) interface..
yes. I did. Please see my reply to Masami.
ioctl only works for tracepoints.
^ permalink raw reply
* Re: [patch net-next] hisilicon: add some missing curly braces
From: David Miller @ 2015-01-29 7:07 UTC (permalink / raw)
To: dingtianhong; +Cc: dan.carpenter, zhangfei.gao, arnd, netdev, kernel-janitors
In-Reply-To: <54C99FFB.2080207@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Thu, 29 Jan 2015 10:50:35 +0800
> On 2015/1/29 2:58, Dan Carpenter wrote:
>> The if block was supposed to have curly braces. In the current code we
>> complain about dropped rx packets when we shouldn't.
>>
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>
> Acked-by: Ding Tianhong <dingtianhong@huawei.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] net: remove sock_iocb
From: David Miller @ 2015-01-29 7:22 UTC (permalink / raw)
To: hch; +Cc: netdev
In-Reply-To: <1422464693-7827-1-git-send-email-hch@lst.de>
From: Christoph Hellwig <hch@lst.de>
Date: Wed, 28 Jan 2015 18:04:53 +0100
> The sock_iocb structure is allocate on stack for each read/write-like
> operation on sockets, and contains various fields of which only the
> embedded msghdr and sometimes a pointer to the scm_cookie is ever used.
> Get rid of the sock_iocb and put a msghdr directly on the stack and pass
> the scm_cookie explicitly to netlink_mmap_sendmsg.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good, applied, thanks.
^ permalink raw reply
* Re: [PATCH] act_connmark: fix dependencies better
From: David Miller @ 2015-01-29 7:23 UTC (permalink / raw)
To: arnd; +Cc: netdev, tgraf, nbd, jhs
In-Reply-To: <1806649.OoZh1UV3MM@wuerfel>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 28 Jan 2015 17:30:09 +0100
> NET_ACT_CONNMARK fails to build if NF_CONNTRACK_MARK is disabled,
> and d7924450e14ea4 ("act_connmark: Add missing dependency on
> NF_CONNTRACK_MARK") fixed that case, but missed the cased where
> NF_CONNTRACK is a loadable module.
>
> This adds the second dependency to ensure that NET_ACT_CONNMARK
> can only be built-in if NF_CONNTRACK is also part of the kernel
> rather than a loadable module.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks Arnd.
^ permalink raw reply
* Re: [PATCH net-next] pkt_sched: fq: remove useless TIME_WAIT check
From: David Miller @ 2015-01-29 7:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1422453996.29618.64.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Jan 2015 06:06:36 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> TIME_WAIT sockets are not owning any skb.
>
> ip_send_unicast_reply() and tcp_v6_send_response() both use
> regular sockets.
>
> We can safely remove a test in sch_fq and save one cache line miss,
> as sk_state is far away from sk_pacing_rate.
>
> Tested at Google for about one year.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net] tcp: ipv4: initialize unicast_sock sk_pacing_rate
From: David Miller @ 2015-01-29 7:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1422452831.29618.49.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Jan 2015 05:47:11 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> When I added sk_pacing_rate field, I forgot to initialize its value
> in the per cpu unicast_sock used in ip_send_unicast_reply()
>
> This means that for sch_fq users, RST packets, or ACK packets sent
> on behalf of TIME_WAIT sockets might be sent to slowly or even dropped
> once we reach the per flow limit.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Fixes: 95bd09eb2750 ("tcp: TSO packets automatic sizing")
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net: remove sock_iocb
From: Al Viro @ 2015-01-29 7:57 UTC (permalink / raw)
To: David Miller; +Cc: hch, netdev
In-Reply-To: <20150128.232211.1157376728217761804.davem@davemloft.net>
On Wed, Jan 28, 2015 at 11:22:11PM -0800, David Miller wrote:
> From: Christoph Hellwig <hch@lst.de>
> Date: Wed, 28 Jan 2015 18:04:53 +0100
>
> > The sock_iocb structure is allocate on stack for each read/write-like
> > operation on sockets, and contains various fields of which only the
> > embedded msghdr and sometimes a pointer to the scm_cookie is ever used.
> > Get rid of the sock_iocb and put a msghdr directly on the stack and pass
> > the scm_cookie explicitly to netlink_mmap_sendmsg.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Looks good, applied, thanks.
You know, that's getting _really_ interesting. The thing is, now
there's only one ->sendmsg() instance using iocb argument at all,
and it's a really weird one. TIPC. Which only compares it with
NULL, and that - to tell the normal calls (== done by sock_sendmsg()
et.al.) from tipc_{accept,connect}()-generated ones. And the way
it's used is
if (iocb)
lock_sock(sk);
in tipc_send_stream(). IOW, "tipc_accept() and tipc_connect() would like
to use the guts of tipc_send_stream(), but they are already holding the
socket locked; let's just pass NULL iocb (which net/socket.c never does)
to tell it to leave the fucking lock alone, thank you very much".
And no ->recvmsg() are using iocb at all now. How about we take the
guts of tipc_send_stream() into a helper function and have tipc_accept/connect
use _that_? Then we could drop iocb argument completely and for ->sendmsg()
it would be the difference between 4 and 3 arguments, which has interesting
effects on certain register-starved architectures...
While we are at it, size (both for sendmsg and recvmsg) is always equal to
iov_iter_count(&msg->msg_iter), so that's not the only redundant argument
there...
Comments?
^ permalink raw reply
* Re: [PATCH] net: remove sock_iocb
From: David Miller @ 2015-01-29 8:01 UTC (permalink / raw)
To: viro; +Cc: hch, netdev
In-Reply-To: <20150129075721.GD29656@ZenIV.linux.org.uk>
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Thu, 29 Jan 2015 07:57:21 +0000
> You know, that's getting _really_ interesting. The thing is, now
> there's only one ->sendmsg() instance using iocb argument at all,
> and it's a really weird one. TIPC. Which only compares it with
> NULL, and that - to tell the normal calls (== done by sock_sendmsg()
> et.al.) from tipc_{accept,connect}()-generated ones. And the way
> it's used is
> if (iocb)
> lock_sock(sk);
> in tipc_send_stream(). IOW, "tipc_accept() and tipc_connect() would like
> to use the guts of tipc_send_stream(), but they are already holding the
> socket locked; let's just pass NULL iocb (which net/socket.c never does)
> to tell it to leave the fucking lock alone, thank you very much".
>
> And no ->recvmsg() are using iocb at all now. How about we take the
> guts of tipc_send_stream() into a helper function and have tipc_accept/connect
> use _that_? Then we could drop iocb argument completely and for ->sendmsg()
> it would be the difference between 4 and 3 arguments, which has interesting
> effects on certain register-starved architectures...
>
> While we are at it, size (both for sendmsg and recvmsg) is always equal to
> iov_iter_count(&msg->msg_iter), so that's not the only redundant argument
> there...
No objections from me.
^ permalink raw reply
* [PATCH] ipv4: Don't increase PMTU with Datagram Too Big message.
From: Li Wei @ 2015-01-29 8:09 UTC (permalink / raw)
To: davem; +Cc: netdev, Li Wei
RFC 1191 said, "a host MUST not increase its estimate of the Path
MTU in response to the contents of a Datagram Too Big message."
Signed-off-by: Li Wei <lw@cn.fujitsu.com>
---
net/ipv4/route.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index d58dd0e..52e1f2b 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -966,6 +966,9 @@ static void __ip_rt_update_pmtu(struct rtable *rt, struct flowi4 *fl4, u32 mtu)
if (dst->dev->mtu < mtu)
return;
+ if (rt->rt_pmtu && rt->rt_pmtu < mtu)
+ return;
+
if (mtu < ip_rt_min_pmtu)
mtu = ip_rt_min_pmtu;
--
2.1.0
^ permalink raw reply related
* Re: [RESEND] ssb: Fix Sparse error in main
From: Kalle Valo @ 2015-01-29 8:18 UTC (permalink / raw)
To: Pramod Gurav
Cc: John Linville, Michael Buesch, netdev, linux-kernel,
linux-wireless, Pramod Gurav
In-Reply-To: <1422424187-19059-1-git-send-email-pramod.gurav@smartplayin.com>
> This change fixes below sparse error:
> drivers/ssb/main.c:94:16: warning: symbol 'ssb_sdio_func_to_bus'
> was not declared. Should it be static?
>
> Acked-by: Michael Buesch <m@bues.ch>
> Signed-off-by: Pramod Gurav <pramod.gurav@smartplayin.com>
Thanks, applied to wireless-drivers-next.git.
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2] lib/checksum.c: fix carry in csum_tcpudp_nofold
From: Karl Beldan @ 2015-01-29 8:55 UTC (permalink / raw)
To: David Miller
Cc: karl.beldan, viro, eric.dumazet, arnd, vapier, netdev,
linux-kernel, stable
In-Reply-To: <20150128.223249.779296549693168395.davem@davemloft.net>
On Wed, Jan 28, 2015 at 10:32:49PM -0800, David Miller wrote:
> From: Karl Beldan <karl.beldan@gmail.com>
> Date: Wed, 28 Jan 2015 10:58:11 +0100
>
> > The carry from the 64->32bits folding was dropped, e.g with:
> > saddr=0xFFFFFFFF daddr=0xFF0000FF len=0xFFFF proto=0 sum=1,
> > csum_tcpudp_nofold returned 0 instead of 1.
> >
> > Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
>
> Applied, thanks.
Fengguang's robot reported I managed to break the build, this occurs
when using non-generic do_csum and generic csum_tcpudp_nofold.
I guess a v3 is irrelevant now, should I send another patch for the
build fix only ? Sorry for that.
Karl
^ permalink raw reply
* Re: [PATCH] net, ethernet, LLVMLinux: Add missing MODULE_DEVICE_TABLE()
From: Arnd Bergmann @ 2015-01-29 9:10 UTC (permalink / raw)
To: David Miller
Cc: behanw, sathya.perla, ajit.khaparde, linux-kernel, netdev,
subbu.seetharaman
In-Reply-To: <20150128.224228.1533046356464752424.davem@davemloft.net>
On Wednesday 28 January 2015 22:42:28 David Miller wrote:
> From: Behan Webster <behanw@converseincode.com>
> Date: Wed, 28 Jan 2015 17:36:14 -0800
>
> > Missing MODULE_DEVICE_TABLE for pci ids from benet driver found by clang.
> >
> > Signed-off-by: Behan Webster <behanw@converseincode.com>
> > Suggested-by: Arnd Bergmann <arnd@arndb.de>
>
> Why are you removing the device table?
Behan took a patch that I did earlier and split it up to add descriptions.
The patch is correct, but he either misunderstood or misexpressed the
intention.
This driver has two identical lines that both say
MODULE_DEVICE_TABLE(pci, be_dev_ids);
I don't remember the exact symptom, but llvm/clang trips over this, while gcc
silently ignores the second one.
Arnd
^ permalink raw reply
* [PATCH] stmmac: DMA threshold mode or SF mode can be different among multiple device instance
From: Sonic Zhang @ 2015-01-29 8:54 UTC (permalink / raw)
To: Giuseppe Cavallaro, David S. Miller
Cc: netdev, adi-buildroot-devel, Sonic Zhang
From: Sonic Zhang <sonic.zhang@analog.com>
- In tx_hard_error_bump_tc interrupt, tc should be bumped only when current
device instance is in DMA threshold mode. Check per device xstats.threshold
other than global tc.
- Set per device xstats.threshold to SF_DMA_MODE when current device
instance is set to SF mode.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index cd6ebda..6c87850 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1287,7 +1287,7 @@ static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
* that needs to not insert csum in the TDES.
*/
priv->hw->dma->dma_mode(priv->ioaddr, SF_DMA_MODE, SF_DMA_MODE);
- tc = SF_DMA_MODE;
+ priv->xstats.threshold = SF_DMA_MODE;
} else
priv->hw->dma->dma_mode(priv->ioaddr, tc, SF_DMA_MODE);
}
@@ -1444,7 +1444,8 @@ static void stmmac_dma_interrupt(struct stmmac_priv *priv)
}
if (unlikely(status & tx_hard_error_bump_tc)) {
/* Try to bump up the dma threshold on this failure */
- if (unlikely(tc != SF_DMA_MODE) && (tc <= 256)) {
+ if (unlikely(priv->xstats.threshold != SF_DMA_MODE) &&
+ (tc <= 256)) {
tc += 64;
if (priv->plat->force_thresh_dma_mode)
priv->hw->dma->dma_mode(priv->ioaddr, tc, tc);
--
1.7.9.5
^ permalink raw reply related
* Re: Bug in netlink_bind
From: Pablo Neira Ayuso @ 2015-01-29 9:40 UTC (permalink / raw)
To: Ivan Delalande; +Cc: netdev
In-Reply-To: <20150128234646.GA23945@ycc.fr>
On Thu, Jan 29, 2015 at 12:46:46AM +0100, Ivan Delalande wrote:
> Hi,
>
> I’ve been trying to debug some of our tests that began failing when
> upgrading to 3.18. Our actual failure is caused by the condition added
> in commit 97840cb to nfnetlink_bind but the bug has probably been
> introduced by 0329274.
Will resend this patch asap:
http://patchwork.ozlabs.org/patch/426205/
It didn't apply cleanly last time I submitted it, sorry.
^ permalink raw reply
* [PATCH net] netlink: fix wrong subscription bitmask to group mapping in
From: Pablo Neira Ayuso @ 2015-01-29 9:51 UTC (permalink / raw)
To: netdev; +Cc: davem, colona, andre
The subscription bitmask passed via struct sockaddr_nl is converted to
the group number when calling the netlink_bind() and netlink_unbind()
callbacks.
The conversion is however incorrect since bitmask (1 << 0) needs to be
mapped to group number 1. Note that you cannot specify the group number 0
(usually known as _NONE) from setsockopt() using NETLINK_ADD_MEMBERSHIP
since this is rejected through -EINVAL.
This problem became noticeable since 97840cb ("netfilter: nfnetlink:
fix insufficient validation in nfnetlink_bind") when binding to bitmask
(1 << 0) in ctnetlink.
Reported-by: Andre Tomt <andre@tomt.net>
Reported-by: Ivan Delalande <colona@arista.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
v2: Rebased upon current net tree. Previous patch:
http://patchwork.ozlabs.org/patch/426205/
did not apply cleanly.
net/netlink/af_netlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 02fdde2..75532ef 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1438,7 +1438,7 @@ static void netlink_undo_bind(int group, long unsigned int groups,
for (undo = 0; undo < group; undo++)
if (test_bit(undo, &groups))
- nlk->netlink_unbind(sock_net(sk), undo);
+ nlk->netlink_unbind(sock_net(sk), undo + 1);
}
static int netlink_bind(struct socket *sock, struct sockaddr *addr,
@@ -1476,7 +1476,7 @@ static int netlink_bind(struct socket *sock, struct sockaddr *addr,
for (group = 0; group < nlk->ngroups; group++) {
if (!test_bit(group, &groups))
continue;
- err = nlk->netlink_bind(net, group);
+ err = nlk->netlink_bind(net, group + 1);
if (!err)
continue;
netlink_undo_bind(group, groups, sk);
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 3/3] lib/string_helpers.c: Change semantics of string_escape_mem
From: Rasmus Villemoes @ 2015-01-29 10:03 UTC (permalink / raw)
To: Andy Shevchenko, Andrew Morton, Trond Myklebust, J. Bruce Fields,
David S. Miller
Cc: Rasmus Villemoes, linux-kernel, linux-nfs, netdev
In-Reply-To: <1422525801-26560-1-git-send-email-linux@rasmusvillemoes.dk>
The current semantics of string_escape_mem are inadequate for one of
its two current users, vsnprintf(). If that is to honour its contract,
it must know how much space would be needed for the entire escaped
buffer, and string_escape_mem provides no way of obtaining that (short
of allocating a large enough buffer (~4 times input string) to let it
play with, and that's definitely a big no-no inside vsnprintf).
So change the semantics for string_escape_mem to be more
snprintf-like: Return the size of the output that would be generated
if the destination buffer was big enough, but of course still only
write to the part of dst it is allowed to, and don't do
'\0'-termination. It is then up to the caller to detect whether output
was truncated and to append a '\0' if desired.
This also fixes a bug in the escaped_string() helper function, which
used to unconditionally pass a length of "end-buf" to
string_escape_mem(); since the latter doesn't check osz for being
insanely large, it would happily write to dst. For example,
kasprintf(GFP_KERNEL, "something and then %pE", ...); is an easy way
to trigger an oops.
In test-string_helpers.c, I removed the now meaningless -ENOMEM test,
and replaced it with testing for getting the expected return value
even if the buffer is too small. Also ensure that nothing is written
when osz==0.
In net/sunrpc/cache.c, I think qword_add still has the same
semantics. Someone should definitely double-check this.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
include/linux/string_helpers.h | 10 +++++-----
lib/string_helpers.c | 25 ++++++++-----------------
lib/test-string_helpers.c | 37 ++++++++++++++++---------------------
lib/vsprintf.c | 2 +-
net/sunrpc/cache.c | 8 +++++---
5 files changed, 35 insertions(+), 47 deletions(-)
diff --git a/include/linux/string_helpers.h b/include/linux/string_helpers.h
index 6eb567ac56bc..7a082aa183a8 100644
--- a/include/linux/string_helpers.h
+++ b/include/linux/string_helpers.h
@@ -47,22 +47,22 @@ static inline int string_unescape_any_inplace(char *buf)
#define ESCAPE_ANY_NP (ESCAPE_ANY | ESCAPE_NP)
#define ESCAPE_HEX 0x20
-int string_escape_mem(const char *src, size_t isz, char **dst, size_t osz,
+size_t string_escape_mem(const char *src, size_t isz, char *dst, size_t osz,
unsigned int flags, const char *esc);
-static inline int string_escape_mem_any_np(const char *src, size_t isz,
- char **dst, size_t osz, const char *esc)
+static inline size_t string_escape_mem_any_np(const char *src, size_t isz,
+ char *dst, size_t osz, const char *esc)
{
return string_escape_mem(src, isz, dst, osz, ESCAPE_ANY_NP, esc);
}
-static inline int string_escape_str(const char *src, char **dst, size_t sz,
+static inline size_t string_escape_str(const char *src, char *dst, size_t sz,
unsigned int flags, const char *esc)
{
return string_escape_mem(src, strlen(src), dst, sz, flags, esc);
}
-static inline int string_escape_str_any_np(const char *src, char **dst,
+static inline size_t string_escape_str_any_np(const char *src, char *dst,
size_t sz, const char *esc)
{
return string_escape_str(src, dst, sz, ESCAPE_ANY_NP, esc);
diff --git a/lib/string_helpers.c b/lib/string_helpers.c
index e14dd8555760..05d4a583d20e 100644
--- a/lib/string_helpers.c
+++ b/lib/string_helpers.c
@@ -414,20 +414,17 @@ static bool escape_hex(unsigned char c, char **dst, char *end)
* it if needs.
*
* Return:
- * The amount of the characters processed to the destination buffer, or
- * %-ENOMEM if the size of buffer is not enough to put an escaped character is
- * returned.
- *
- * Even in the case of error @dst pointer will be updated to point to the byte
- * after the last processed character.
+ * The total size of the escaped output that would be generated for
+ * the given input and flags. To check whether the output was
+ * truncated, compare the return value to osz. There is room left in
+ * dst for a '\0' terminator if and only if ret < osz.
*/
-int string_escape_mem(const char *src, size_t isz, char **dst, size_t osz,
- unsigned int flags, const char *esc)
+size_t string_escape_mem(const char *src, size_t isz, char *dst, size_t osz,
+ unsigned int flags, const char *esc)
{
- char *p = *dst;
+ char *p = dst;
char *end = p + osz;
bool is_dict = esc && *esc;
- int ret;
while (isz--) {
unsigned char c = *src++;
@@ -466,13 +463,7 @@ int string_escape_mem(const char *src, size_t isz, char **dst, size_t osz,
escape_passthrough(c, &p, end);
}
- if (p > end) {
- *dst = end;
- return -ENOMEM;
- }
- ret = p - *dst;
- *dst = p;
- return ret;
+ return p - dst;
}
EXPORT_SYMBOL(string_escape_mem);
diff --git a/lib/test-string_helpers.c b/lib/test-string_helpers.c
index ab0d30e1e18f..5f95114a2f86 100644
--- a/lib/test-string_helpers.c
+++ b/lib/test-string_helpers.c
@@ -264,12 +264,12 @@ static __init void test_string_escape(const char *name,
const struct test_string_2 *s2,
unsigned int flags, const char *esc)
{
- int q_real = 512;
- char *out_test = kmalloc(q_real, GFP_KERNEL);
- char *out_real = kmalloc(q_real, GFP_KERNEL);
+ size_t out_size = 512;
+ char *out_test = kmalloc(out_size, GFP_KERNEL);
+ char *out_real = kmalloc(out_size, GFP_KERNEL);
char *in = kmalloc(256, GFP_KERNEL);
- char *buf = out_real;
- int p = 0, q_test = 0;
+ size_t p = 0, q_test = 0;
+ size_t q_real;
if (!out_test || !out_real || !in)
goto out;
@@ -301,29 +301,26 @@ static __init void test_string_escape(const char *name,
q_test += len;
}
- q_real = string_escape_mem(in, p, &buf, q_real, flags, esc);
+ q_real = string_escape_mem(in, p, out_real, out_size, flags, esc);
test_string_check_buf(name, flags, in, p, out_real, q_real, out_test,
q_test);
+
+ memset(out_real, 'Z', out_size);
+ q_real = string_escape_mem(in, p, out_real, 0, flags, esc);
+ if (q_real != q_test)
+ pr_warn("Test '%s' failed: flags = %u, osz = 0, expected %zu, got %zu\n",
+ name, flags, q_test, q_real);
+ if (memchr_inv(out_real, 'Z', out_size))
+ pr_warn("Test '%s' failed: osz = 0 but string_escape_mem wrote to the buffer\n",
+ name);
+
out:
kfree(in);
kfree(out_real);
kfree(out_test);
}
-static __init void test_string_escape_nomem(void)
-{
- char *in = "\eb \\C\007\"\x90\r]";
- char out[64], *buf = out;
- int rc = -ENOMEM, ret;
-
- ret = string_escape_str_any_np(in, &buf, strlen(in), NULL);
- if (ret == rc)
- return;
-
- pr_err("Test 'escape nomem' failed: got %d instead of %d\n", ret, rc);
-}
-
static int __init test_string_helpers_init(void)
{
unsigned int i;
@@ -342,8 +339,6 @@ static int __init test_string_helpers_init(void)
for (i = 0; i < (ESCAPE_ANY_NP | ESCAPE_HEX) + 1; i++)
test_string_escape("escape 1", escape1, i, TEST_STRING_2_DICT_1);
- test_string_escape_nomem();
-
return -EINVAL;
}
module_init(test_string_helpers_init);
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 3568e3906777..d02c394b5b58 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1160,7 +1160,7 @@ char *escaped_string(char *buf, char *end, u8 *addr, struct printf_spec spec,
len = spec.field_width < 0 ? 1 : spec.field_width;
/* Ignore the error. We print as many characters as we can */
- string_escape_mem(addr, len, &buf, end - buf, flags, NULL);
+ buf += string_escape_mem(addr, len, buf, buf < end ? end - buf : 0, flags, NULL);
return buf;
}
diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
index 33fb105d4352..22c4418057f4 100644
--- a/net/sunrpc/cache.c
+++ b/net/sunrpc/cache.c
@@ -1068,12 +1068,14 @@ void qword_add(char **bpp, int *lp, char *str)
{
char *bp = *bpp;
int len = *lp;
- int ret;
+ int ret, written;
if (len < 0) return;
- ret = string_escape_str(str, &bp, len, ESCAPE_OCTAL, "\\ \n\t");
- if (ret < 0 || ret == len)
+ ret = string_escape_str(str, bp, len, ESCAPE_OCTAL, "\\ \n\t");
+ written = min(ret, len);
+ bp += written;
+ if (ret >= len)
len = -1;
else {
len -= ret;
--
2.1.3
^ permalink raw reply related
* [PATCH v2 0/3] Two printf fixes
From: Rasmus Villemoes @ 2015-01-29 10:03 UTC (permalink / raw)
To: Andy Shevchenko, Andrew Morton, Trond Myklebust, J. Bruce Fields,
David S. Miller
Cc: Rasmus Villemoes, linux-kernel, linux-nfs, netdev
In-Reply-To: <1422451543-12401-1-git-send-email-linux@rasmusvillemoes.dk>
Both %pE and %ph are unusable in kasprintf(), since the occurrence of
either will trigger an oops during the first vsnprintf call where
kasprintf tries to find the correct size to allocate. These oopses
could be papered over with somewhat smaller patches than these, but
then the return value from vsnprintf would still not reflect the
actual size needed. For %pE, this requires a change of semantics of
string_escape_mem and hence an annoyingly large diffstat.
Whether this is 3.20, 3.21 and/or -stable material (or /dev/null
material, for that matter ;-)) I'll leave to others to decide.
v2: Suggestions from Andy Shevchenko:
* Simpler fix of hex_string().
* The string_escape_mem change is split in two, 2/3 updating the
internal helpers and 3/3 then changing the external interface.
Rasmus Villemoes (3):
lib/vsprintf.c: Fix potential NULL deref in hex_string
lib/string_helpers.c: Refactor string_escape_mem
lib/string_helpers.c: Change semantics of string_escape_mem
include/linux/string_helpers.h | 10 +--
lib/string_helpers.c | 191 ++++++++++++++++-------------------------
lib/test-string_helpers.c | 37 ++++----
lib/vsprintf.c | 18 ++--
net/sunrpc/cache.c | 8 +-
5 files changed, 111 insertions(+), 153 deletions(-)
--
2.1.3
^ permalink raw reply
* [PATCH net] net: sctp: fix passing wrong parameter header to param_type2af in sctp_process_param
From: Daniel Borkmann @ 2015-01-29 10:05 UTC (permalink / raw)
To: davem; +Cc: vyasevich, netdev, linux-sctp, Saran Maruti Ramanara
From: Saran Maruti Ramanara <saran.neti@telus.com>
When making use of RFC5061, section 4.2.4. for setting the primary IP
address, we're passing a wrong parameter header to param_type2af(),
resulting always in NULL being returned.
At this point, param.p points to a sctp_addip_param struct, containing
a sctp_paramhdr (type = 0xc004, length = var), and crr_id as a correlation
id. Followed by that, as also presented in RFC5061 section 4.2.4., comes
the actual sctp_addr_param, which also contains a sctp_paramhdr, but
this time with the correct type SCTP_PARAM_IPV{4,6}_ADDRESS that
param_type2af() can make use of. Since we already hold a pointer to
addr_param from previous line, just reuse it for param_type2af().
Fixes: d6de3097592b ("[SCTP]: Add the handling of "Set Primary IP Address" parameter to INIT")
Signed-off-by: Saran Maruti Ramanara <saran.neti@telus.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/sctp/sm_make_chunk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index e49e231..06320c8 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -2608,7 +2608,7 @@ do_addr_param:
addr_param = param.v + sizeof(sctp_addip_param_t);
- af = sctp_get_af_specific(param_type2af(param.p->type));
+ af = sctp_get_af_specific(param_type2af(addr_param->p.type));
if (af == NULL)
break;
--
1.7.11.7
^ permalink raw reply related
* [PATCH] lib/checksum.c: fix build for generic csum_tcpudp_nofold
From: Karl Beldan @ 2015-01-29 10:10 UTC (permalink / raw)
To: David S . Miller
Cc: Karl Beldan, Karl Beldan, netdev, linux-kernel, Eric Dumazet
Fixed commit added from64to32 under _#ifndef do_csum_ but used it
under _#ifndef csum_tcpudp_nofold_, breaking some builds (Fengguang's
robot reported TILEGX's). Move from64to32 under the latter.
Fixes: 150ae0e94634 ("lib/checksum.c: fix carry in csum_tcpudp_nofold")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: David S. Miller <davem@davemloft.net>
---
lib/checksum.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/lib/checksum.c b/lib/checksum.c
index fcf3894..8b39e86 100644
--- a/lib/checksum.c
+++ b/lib/checksum.c
@@ -47,15 +47,6 @@ static inline unsigned short from32to16(unsigned int x)
return x;
}
-static inline u32 from64to32(u64 x)
-{
- /* add up 32-bit and 32-bit for 32+c bit */
- x = (x & 0xffffffff) + (x >> 32);
- /* add up carry.. */
- x = (x & 0xffffffff) + (x >> 32);
- return (u32)x;
-}
-
static unsigned int do_csum(const unsigned char *buff, int len)
{
int odd;
@@ -190,6 +181,15 @@ csum_partial_copy(const void *src, void *dst, int len, __wsum sum)
EXPORT_SYMBOL(csum_partial_copy);
#ifndef csum_tcpudp_nofold
+static inline u32 from64to32(u64 x)
+{
+ /* add up 32-bit and 32-bit for 32+c bit */
+ x = (x & 0xffffffff) + (x >> 32);
+ /* add up carry.. */
+ x = (x & 0xffffffff) + (x >> 32);
+ return (u32)x;
+}
+
__wsum csum_tcpudp_nofold(__be32 saddr, __be32 daddr,
unsigned short len,
unsigned short proto,
--
2.0.1
^ permalink raw reply related
* Re: [PATCH RFC 1/2] ipv6: Fix after pmtu events dissapearing host routes
From: Hannes Frederic Sowa @ 2015-01-29 10:26 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Yang Yingliang, netdev, David S. Miller
In-Reply-To: <20150128121150.GN13046@secunet.com>
On Mi, 2015-01-28 at 13:11 +0100, Steffen Klassert wrote:
> We currently don't clone host routes before we use them.
> If a pmtu event is received on such a route, it gets
> an expires value. As soon as the expiration time is
> elapsed, the route is deleted. As a result, the host
> is not reachable any more.
>
> We fix this by cloning host routes if they are gatewayed,
> i.e. if pmtu events can happen.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> ---
> net/ipv6/route.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index c910831..3e864e7 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -961,7 +961,7 @@ redo_rt6_select:
>
> if (!(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_GATEWAY)))
> nrt = rt6_alloc_cow(rt, &fl6->daddr, &fl6->saddr);
> - else if (!(rt->dst.flags & DST_HOST))
> + else if (!(rt->dst.flags & DST_HOST) || (rt->rt6i_flags & RTF_GATEWAY))
> nrt = rt6_alloc_clone(rt, &fl6->daddr);
> else
> goto out2;
My approach was to suppress mtu updates on the loopback interface.
Hmm...
Bye,
Hannes
^ permalink raw reply
* Re: [PATCHv3, ipsec-next] xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host
From: Nicolas Dichtel @ 2015-01-29 10:29 UTC (permalink / raw)
To: Fan Du, steffen.klassert; +Cc: herbert, davem, netdev, fengyuleidian0615
In-Reply-To: <1422349230-17394-1-git-send-email-fan.du@intel.com>
Le 27/01/2015 10:00, Fan Du a écrit :
> structure like xfrm_usersa_info or xfrm_userpolicy_info
> has different sizeof when compiled as 32bits and 64bits
> due to not appending pack attribute in their definition.
> This will result in broken SA and SP information when user
> trying to configure them through netlink interface.
>
> Inform user land about this situation instead of keeping
> silent, the upper test scripts would behave accordingly.
>
> Quotes from: http://marc.info/?l=linux-netdev&m=142226348715503&w=2
>>
>> Before a clean solution show up, I think it's better to warn user in some way
>> like http://patchwork.ozlabs.org/patch/323842/ did. Otherwise, many people
>> who stuck there will always spend time and try to fix this issue in whatever way.
>
> Yes, this is the first thing we should do. I'm willing to accept a patch
>
> Signed-off-by: Fan Du <fan.du@intel.com>
A way to solve this problem was to provide to userland a xfrm compat header
file, which match the ABI of the kernel. Something like:
#include <linux/xfrm.h>
#define xfrm_usersa_info xfrm_usersa_info_64
#define xfrm_usersa_info_compat xfrm_usersa_info
struct xfrm_usersa_info_compat {
struct xfrm_selector sel;
struct xfrm_id id;
xfrm_address_t saddr;
struct xfrm_lifetime_cfg lft;
struct xfrm_lifetime_cur curlft;
struct xfrm_stats stats;
__u32 seq;
__u32 reqid;
__u16 family;
__u8 mode;
__u8 replay_window;
__u8 flags;
__u8 hole1;
__u32 hole2;
};
The point I try to make is that patching userland apps allows to use xfrm on a
32bits userland / 64bits kernel.
If I understand well your patch, it will not be possible anymore, all messages
will be rejected. And this may break existing apps.
Regards,
Nicolas
^ permalink raw reply
* Re: [PATCH RFC 1/2] ipv6: Fix after pmtu events dissapearing host routes
From: Steffen Klassert @ 2015-01-29 10:44 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Yang Yingliang, netdev, David S. Miller
In-Reply-To: <1422527211.2861.2.camel@redhat.com>
On Thu, Jan 29, 2015 at 11:26:51AM +0100, Hannes Frederic Sowa wrote:
> On Mi, 2015-01-28 at 13:11 +0100, Steffen Klassert wrote:
> > We currently don't clone host routes before we use them.
> > If a pmtu event is received on such a route, it gets
> > an expires value. As soon as the expiration time is
> > elapsed, the route is deleted. As a result, the host
> > is not reachable any more.
> >
> > We fix this by cloning host routes if they are gatewayed,
> > i.e. if pmtu events can happen.
> >
> > Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> > ---
> > net/ipv6/route.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> > index c910831..3e864e7 100644
> > --- a/net/ipv6/route.c
> > +++ b/net/ipv6/route.c
> > @@ -961,7 +961,7 @@ redo_rt6_select:
> >
> > if (!(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_GATEWAY)))
> > nrt = rt6_alloc_cow(rt, &fl6->daddr, &fl6->saddr);
> > - else if (!(rt->dst.flags & DST_HOST))
> > + else if (!(rt->dst.flags & DST_HOST) || (rt->rt6i_flags & RTF_GATEWAY))
> > nrt = rt6_alloc_clone(rt, &fl6->daddr);
> > else
> > goto out2;
>
> My approach was to suppress mtu updates on the loopback interface.
> Hmm...
Maybe we need to do this too. My patch fixes just the case
where we get a valid pmtu update from a remote host.
^ 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