* Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()
From: Jason Wang @ 2017-11-29 1:53 UTC (permalink / raw)
To: wexu, virtualization, netdev, linux-kernel; +Cc: mst, mjrosato
In-Reply-To: <1511889436-12876-1-git-send-email-wexu@redhat.com>
On 2017年11月29日 01:17, wexu@redhat.com wrote:
> From: Wei Xu <wexu@redhat.com>
>
> Matthew found a roughly 40% tcp throughput regression with commit
> c67df11f(vhost_net: try batch dequing from skb array) as discussed
> in the following thread:
> https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
>
> Eventually we figured out that it was a skb leak in handle_rx()
> when sending packets to the VM. This usually happens when a guest
> can not drain out vq as fast as vhost fills in, afterwards it sets
> off the traffic jam and leaks skb(s) which occurs as no headcount
> to send on the vq from vhost side.
>
> This can be avoided by making sure we have got enough headcount
> before actually consuming a skb from the batched rx array while
> transmitting, which is simply done by deferring it a moment later
> in this patch.
>
> Signed-off-by: Wei Xu <wexu@redhat.com>
> ---
> drivers/vhost/net.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 8d626d7..e76535e 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -778,8 +778,6 @@ static void handle_rx(struct vhost_net *net)
> /* On error, stop handling until the next kick. */
> if (unlikely(headcount < 0))
> goto out;
> - if (nvq->rx_array)
> - msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> /* On overrun, truncate and discard */
> if (unlikely(headcount > UIO_MAXIOV)) {
You need do msg.msg_control = vhost_net_buf_consume() here too,
otherwise we may still get it leaked.
Thanks
> iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
> @@ -809,6 +807,8 @@ static void handle_rx(struct vhost_net *net)
> */
> iov_iter_advance(&msg.msg_iter, vhost_hlen);
> }
> + if (nvq->rx_array)
> + msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> err = sock->ops->recvmsg(sock, &msg,
> sock_len, MSG_DONTWAIT | MSG_TRUNC);
> /* Userspace might have consumed the packet meanwhile:
^ permalink raw reply
* Re: [PATCH v4 1/8] dt-bindings: Add Cavium Octeon Common Ethernet Interface.
From: Andrew Lunn @ 2017-11-29 2:01 UTC (permalink / raw)
To: David Daney
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA, ralf-6z/3iImG2C8G8FEW9MqTrA,
James Hogan, netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
Rob Herring, Mark Rutland, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
Greg Kroah-Hartman, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Steven J. Hill, devicetree-u79uwXL29TY76Z2rM5mHXA,
Florian Fainelli, Carlos Munoz
In-Reply-To: <20171129005540.28829-2-david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
On Tue, Nov 28, 2017 at 04:55:33PM -0800, David Daney wrote:
> From: Carlos Munoz <cmunoz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>
> Add bindings for Common Ethernet Interface (BGX) block.
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Carlos Munoz <cmunoz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Steven J. Hill <Steven.Hill-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/net/cavium-bgx.txt | 61 ++++++++++++++++++++++
> 1 file changed, 61 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/cavium-bgx.txt
>
> diff --git a/Documentation/devicetree/bindings/net/cavium-bgx.txt b/Documentation/devicetree/bindings/net/cavium-bgx.txt
> new file mode 100644
> index 000000000000..830c5f08dddd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/cavium-bgx.txt
> @@ -0,0 +1,61 @@
> +* Common Ethernet Interface (BGX) block
> +
> +Properties:
> +
> +- compatible: "cavium,octeon-7890-bgx": Compatibility with all cn7xxx SOCs.
> +
> +- reg: The base address of the BGX block.
> +
> +- #address-cells: Must be <1>.
> +
> +- #size-cells: Must be <0>. BGX addresses have no size component.
> +
> +A BGX block has several children, each representing an Ethernet
> +interface.
> +
> +
> +* Ethernet Interface (BGX port) connects to PKI/PKO
> +
> +Properties:
> +
> +- compatible: "cavium,octeon-7890-bgx-port": Compatibility with all
> + cn7xxx SOCs.
> +
> + "cavium,octeon-7360-xcv": Compatibility with cn73xx SOCs
> + for RGMII.
> +
> +- reg: The index of the interface within the BGX block.
> +
> +Optional properties:
> +
> +- local-mac-address: Mac address for the interface.
> +
> +- phy-handle: phandle to the phy node connected to the interface.
> +
> +- phy-mode: described in ethernet.txt.
> +
> +- fixed-link: described in fixed-link.txt.
> +
> +Example:
> +
> + ethernet-mac-nexus@11800e0000000 {
> + compatible = "cavium,octeon-7890-bgx";
> + reg = <0x00011800 0xe0000000 0x00000000 0x01000000>;
Hi David
In the probe function we have:
+ reg = of_get_property(pdev->dev.of_node, "reg", NULL);
+ addr = of_translate_address(pdev->dev.of_node, reg);
+ interface = (addr >> 24) & 0xf;
+ numa_node = (addr >> 36) & 0x7;
Is this documented somewhere? The numa_node is particularly
interesting. MMIO changes depends on what node this is in the cluster?
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 V11 0/5] hash addresses printed with %p
From: Tobin C. Harding @ 2017-11-29 2:05 UTC (permalink / raw)
To: kernel-hardening
Cc: Tobin C. Harding, Linus Torvalds, Jason A. Donenfeld,
Theodore Ts'o, Kees Cook, Paolo Bonzini, Tycho Andersen,
Roberts, William C, Tejun Heo, Jordan Glover, Greg KH,
Petr Mladek, Joe Perches, Ian Campbell, Sergey Senozhatsky,
Catalin Marinas, Will Deacon, Steven Rostedt, Chris Fries,
Dave Weinstein
Currently there exist approximately 14 000 places in the Kernel where
addresses are being printed using an unadorned %p. This potentially
leaks sensitive information regarding the Kernel layout in memory. Many
of these calls are stale, instead of fixing every call lets hash the
address by default before printing. This will of course break some
users, forcing code printing needed addresses to be updated. We can add
a printk specifier for this purpose (%px) to give developers a clear
upgrade path for breakages caused by applying this patch set.
The added advantage of hashing %p is that security is now opt-out, if
you _really_ want the address you have to work a little harder and use
%px.
The idea for creating the printk specifier %px to print the actual
address was suggested by Kees Cook (see below for email threads by
subject).
Newbie question: I don't know who is potentially going to want to apply
this, I've CC'd Andrew Morton. I'm guessing this should go into
linux-next so we can see what breaks? I do not know exactly how code
gets into linux-next. I've CC'd Stephen Rothwell.
Here is the behaviour that this series implements.
For kpt_restrict==0
Randomness not ready:
printed with %p: (ptrval) # NOTE: with padding
Valid pointer:
printed with %pK: deadbeefdeadbeef
printed with %p: 00000000deadbeef
malformed specifier (eg %i): 00000000deadbeef
NULL pointer:
printed with %pK: 0000000000000000
printed with %p: (null) # NOTE: with padding
malformed specifier (eg %i): (null)
For kpt_restrict==2
Valid pointer:
printed with %pK: 0000000000000000
All other output as for kptr_restrict==0
V11:
- Add patch fixing %pK documentation.
- Refactor %pK as a separate patch.
- Add patch adding printk specifier %px, which prints the actual
address (i.e replaces original %p behaviour).
- Use %px for KASAN patch.
V10:
- Add patch so KASAN uses %pK instead of %p.
- Add documentation to Documentation/printk-formats.txt
- Add tests to lib/test_printf.c
- Change "(pointer value)" -> "(ptrval)" to fit within columns on 32
bit machines.
V9:
- Drop the initial patch from V8, leaving null pointer handling as is.
- Print the hashed ID _without_ a '0x' suffix.
- Mask the first 32 bits of the hashed ID to all zeros on 64 bit
architectures.
V8:
- Add second patch cleaning up null pointer printing in pointer()
- Move %pK handling to separate function, further cleaning up pointer()
- Move ptr_to_id() call outside of switch statement making hashing
the default behaviour (including malformed specifiers).
- Remove use of static_key, replace with simple boolean.
V7:
- Use tabs instead of spaces (ouch!).
V6:
- Use __early_initcall() to fill the SipHash key.
- Use static keys to guard hashing before the key is available.
V5:
- Remove spin lock.
- Add Jason A. Donenfeld to CC list by request.
- Add Theodore Ts'o to CC list due to comment on previous version.
V4:
- Remove changes to siphash.{ch}
- Do word size check, and return value cast, directly in ptr_to_id().
- Use add_ready_random_callback() to guard call to get_random_bytes()
V3:
- Use atomic_xchg() to guard setting [random] key.
- Remove erroneous white space change.
V2:
- Use SipHash to do the hashing.
The discussion related to this patch has been fragmented. There are
three threads associated with this patch. Email threads by subject:
[PATCH 0/5] add printk specifier %px, unique identifier
[PATCH] printk: hash addresses printed with %p
[PATCH 0/3] add %pX specifier
[kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options
Tobin C. Harding (5):
docs: correct documentation for %pK
vsprintf: refactor %pK code out of pointer()
printk: hash addresses printed with %p
vsprintf: add printk specifier %px
kasan: use %px to print addresses instead of %p
Documentation/printk-formats.txt | 31 ++++++-
lib/test_printf.c | 108 ++++++++++++++--------
lib/vsprintf.c | 194 +++++++++++++++++++++++++++++----------
mm/kasan/report.c | 8 +-
scripts/checkpatch.pl | 2 +-
5 files changed, 248 insertions(+), 95 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH V11 1/5] docs: correct documentation for %pK
From: Tobin C. Harding @ 2017-11-29 2:05 UTC (permalink / raw)
To: kernel-hardening
Cc: Tobin C. Harding, Linus Torvalds, Jason A. Donenfeld,
Theodore Ts'o, Kees Cook, Paolo Bonzini, Tycho Andersen,
Roberts, William C, Tejun Heo, Jordan Glover, Greg KH,
Petr Mladek, Joe Perches, Ian Campbell, Sergey Senozhatsky,
Catalin Marinas, Will Deacon, Steven Rostedt, Chris Fries,
Dave Weinstein
In-Reply-To: <1511921105-3647-1-git-send-email-me@tobin.cc>
Current documentation indicates that %pK prints a leading '0x'. This is
not the case.
Correct documentation for printk specifier %pK.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Documentation/printk-formats.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 361789df51ec..71b62db7eca2 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -85,13 +85,12 @@ Examples::
printk("Faulted at %pS\n", (void *)regs->ip);
printk(" %s%pB\n", (reliable ? "" : "? "), (void *)*stack);
-
Kernel Pointers
===============
::
- %pK 0x01234567 or 0x0123456789abcdef
+ %pK 01234567 or 0123456789abcdef
For printing kernel pointers which should be hidden from unprivileged
users. The behaviour of ``%pK`` depends on the ``kptr_restrict sysctl`` - see
--
2.7.4
^ permalink raw reply related
* [PATCH V11 2/5] vsprintf: refactor %pK code out of pointer()
From: Tobin C. Harding @ 2017-11-29 2:05 UTC (permalink / raw)
To: kernel-hardening
Cc: Tobin C. Harding, Linus Torvalds, Jason A. Donenfeld,
Theodore Ts'o, Kees Cook, Paolo Bonzini, Tycho Andersen,
Roberts, William C, Tejun Heo, Jordan Glover, Greg KH,
Petr Mladek, Joe Perches, Ian Campbell, Sergey Senozhatsky,
Catalin Marinas, Will Deacon, Steven Rostedt, Chris Fries,
Dave Weinstein, Daniel Micay, Djalal Harouni,
Radim Krčmář
In-Reply-To: <1511921105-3647-1-git-send-email-me@tobin.cc>
Currently code to handle %pK is all within the switch statement in
pointer(). This is the wrong level of abstraction. Each of the other switch
clauses call a helper function, pK should do the same.
Refactor code out of pointer() to new function restricted_pointer().
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
lib/vsprintf.c | 97 ++++++++++++++++++++++++++++++++--------------------------
1 file changed, 54 insertions(+), 43 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 1746bae94d41..8dc5cf85cef4 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1343,6 +1343,59 @@ char *uuid_string(char *buf, char *end, const u8 *addr,
return string(buf, end, uuid, spec);
}
+int kptr_restrict __read_mostly;
+
+static noinline_for_stack
+char *restricted_pointer(char *buf, char *end, const void *ptr,
+ struct printf_spec spec)
+{
+ spec.base = 16;
+ spec.flags |= SMALL;
+ if (spec.field_width == -1) {
+ spec.field_width = 2 * sizeof(ptr);
+ spec.flags |= ZEROPAD;
+ }
+
+ switch (kptr_restrict) {
+ case 0:
+ /* Always print %pK values */
+ break;
+ case 1: {
+ const struct cred *cred;
+
+ /*
+ * kptr_restrict==1 cannot be used in IRQ context
+ * because its test for CAP_SYSLOG would be meaningless.
+ */
+ if (in_irq() || in_serving_softirq() || in_nmi())
+ return string(buf, end, "pK-error", spec);
+
+ /*
+ * Only print the real pointer value if the current
+ * process has CAP_SYSLOG and is running with the
+ * same credentials it started with. This is because
+ * access to files is checked at open() time, but %pK
+ * checks permission at read() time. We don't want to
+ * leak pointer values if a binary opens a file using
+ * %pK and then elevates privileges before reading it.
+ */
+ cred = current_cred();
+ if (!has_capability_noaudit(current, CAP_SYSLOG) ||
+ !uid_eq(cred->euid, cred->uid) ||
+ !gid_eq(cred->egid, cred->gid))
+ ptr = NULL;
+ break;
+ }
+ case 2:
+ default:
+ /* Always print 0's for %pK */
+ ptr = NULL;
+ break;
+ }
+
+ return number(buf, end, (unsigned long)ptr, spec);
+}
+
static noinline_for_stack
char *netdev_bits(char *buf, char *end, const void *addr, const char *fmt)
{
@@ -1591,8 +1644,6 @@ char *device_node_string(char *buf, char *end, struct device_node *dn,
return widen_string(buf, buf - buf_start, end, spec);
}
-int kptr_restrict __read_mostly;
-
/*
* Show a '%p' thing. A kernel extension is that the '%p' is followed
* by an extra set of alphanumeric characters that are extended format
@@ -1792,47 +1843,7 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
return buf;
}
case 'K':
- switch (kptr_restrict) {
- case 0:
- /* Always print %pK values */
- break;
- case 1: {
- const struct cred *cred;
-
- /*
- * kptr_restrict==1 cannot be used in IRQ context
- * because its test for CAP_SYSLOG would be meaningless.
- */
- if (in_irq() || in_serving_softirq() || in_nmi()) {
- if (spec.field_width == -1)
- spec.field_width = default_width;
- return string(buf, end, "pK-error", spec);
- }
-
- /*
- * Only print the real pointer value if the current
- * process has CAP_SYSLOG and is running with the
- * same credentials it started with. This is because
- * access to files is checked at open() time, but %pK
- * checks permission at read() time. We don't want to
- * leak pointer values if a binary opens a file using
- * %pK and then elevates privileges before reading it.
- */
- cred = current_cred();
- if (!has_capability_noaudit(current, CAP_SYSLOG) ||
- !uid_eq(cred->euid, cred->uid) ||
- !gid_eq(cred->egid, cred->gid))
- ptr = NULL;
- break;
- }
- case 2:
- default:
- /* Always print 0's for %pK */
- ptr = NULL;
- break;
- }
- break;
-
+ return restricted_pointer(buf, end, ptr, spec);
case 'N':
return netdev_bits(buf, end, ptr, fmt);
case 'a':
--
2.7.4
^ permalink raw reply related
* [PATCH V11 3/5] printk: hash addresses printed with %p
From: Tobin C. Harding @ 2017-11-29 2:05 UTC (permalink / raw)
To: kernel-hardening
Cc: Tobin C. Harding, Linus Torvalds, Jason A. Donenfeld,
Theodore Ts'o, Kees Cook, Paolo Bonzini, Tycho Andersen,
Roberts, William C, Tejun Heo, Jordan Glover, Greg KH,
Petr Mladek, Joe Perches, Ian Campbell, Sergey Senozhatsky,
Catalin Marinas, Will Deacon, Steven Rostedt, Chris Fries,
Dave Weinstein
In-Reply-To: <1511921105-3647-1-git-send-email-me@tobin.cc>
Currently there exist approximately 14 000 places in the kernel where
addresses are being printed using an unadorned %p. This potentially
leaks sensitive information regarding the Kernel layout in memory. Many
of these calls are stale, instead of fixing every call lets hash the
address by default before printing. This will of course break some
users, forcing code printing needed addresses to be updated.
Code that _really_ needs the address will soon be able to use the new
printk specifier %px to print the address.
For what it's worth, usage of unadorned %p can be broken down as
follows (thanks to Joe Perches).
$ git grep -E '%p[^A-Za-z0-9]' | cut -f1 -d"/" | sort | uniq -c
1084 arch
20 block
10 crypto
32 Documentation
8121 drivers
1221 fs
143 include
101 kernel
69 lib
100 mm
1510 net
40 samples
7 scripts
11 security
166 sound
152 tools
2 virt
Add function ptr_to_id() to map an address to a 32 bit unique
identifier. Hash any unadorned usage of specifier %p and any malformed
specifiers.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Documentation/printk-formats.txt | 12 ++++-
lib/test_printf.c | 108 +++++++++++++++++++++++++--------------
lib/vsprintf.c | 81 ++++++++++++++++++++++++++---
3 files changed, 155 insertions(+), 46 deletions(-)
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 71b62db7eca2..b4e668ac4fe3 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -5,7 +5,6 @@ How to get printk format specifiers right
:Author: Randy Dunlap <rdunlap@infradead.org>
:Author: Andrew Murray <amurray@mpc-data.co.uk>
-
Integer types
=============
@@ -45,6 +44,17 @@ return from vsnprintf.
Raw pointer value SHOULD be printed with %p. The kernel supports
the following extended format specifiers for pointer types:
+Pointer Types
+=============
+
+Pointers printed without a specifier extension (i.e unadorned %p) are
+hashed to give a unique identifier without leaking kernel addresses to user
+space. On 64 bit machines the first 32 bits are zeroed.
+
+::
+
+ %p abcdef12 or 00000000abcdef12
+
Symbols/Function Pointers
=========================
diff --git a/lib/test_printf.c b/lib/test_printf.c
index 563f10e6876a..71ebfa43ad05 100644
--- a/lib/test_printf.c
+++ b/lib/test_printf.c
@@ -24,24 +24,6 @@
#define PAD_SIZE 16
#define FILL_CHAR '$'
-#define PTR1 ((void*)0x01234567)
-#define PTR2 ((void*)(long)(int)0xfedcba98)
-
-#if BITS_PER_LONG == 64
-#define PTR1_ZEROES "000000000"
-#define PTR1_SPACES " "
-#define PTR1_STR "1234567"
-#define PTR2_STR "fffffffffedcba98"
-#define PTR_WIDTH 16
-#else
-#define PTR1_ZEROES "0"
-#define PTR1_SPACES " "
-#define PTR1_STR "1234567"
-#define PTR2_STR "fedcba98"
-#define PTR_WIDTH 8
-#endif
-#define PTR_WIDTH_STR stringify(PTR_WIDTH)
-
static unsigned total_tests __initdata;
static unsigned failed_tests __initdata;
static char *test_buffer __initdata;
@@ -217,30 +199,79 @@ test_string(void)
test("a | | ", "%-3.s|%-3.0s|%-3.*s", "a", "b", 0, "c");
}
+#define PLAIN_BUF_SIZE 64 /* leave some space so we don't oops */
+
+#if BITS_PER_LONG == 64
+
+#define PTR_WIDTH 16
+#define PTR ((void *)0xffff0123456789ab)
+#define PTR_STR "ffff0123456789ab"
+#define ZEROS "00000000" /* hex 32 zero bits */
+
+static int __init
+plain_format(void)
+{
+ char buf[PLAIN_BUF_SIZE];
+ int nchars;
+
+ nchars = snprintf(buf, PLAIN_BUF_SIZE, "%p", PTR);
+
+ if (nchars != PTR_WIDTH || strncmp(buf, ZEROS, strlen(ZEROS)) != 0)
+ return -1;
+
+ return 0;
+}
+
+#else
+
+#define PTR_WIDTH 8
+#define PTR ((void *)0x456789ab)
+#define PTR_STR "456789ab"
+
+static int __init
+plain_format(void)
+{
+ /* Format is implicitly tested for 32 bit machines by plain_hash() */
+ return 0;
+}
+
+#endif /* BITS_PER_LONG == 64 */
+
+static int __init
+plain_hash(void)
+{
+ char buf[PLAIN_BUF_SIZE];
+ int nchars;
+
+ nchars = snprintf(buf, PLAIN_BUF_SIZE, "%p", PTR);
+
+ if (nchars != PTR_WIDTH || strncmp(buf, PTR_STR, PTR_WIDTH) == 0)
+ return -1;
+
+ return 0;
+}
+
+/*
+ * We can't use test() to test %p because we don't know what output to expect
+ * after an address is hashed.
+ */
static void __init
plain(void)
{
- test(PTR1_ZEROES PTR1_STR " " PTR2_STR, "%p %p", PTR1, PTR2);
- /*
- * The field width is overloaded for some %p extensions to
- * pass another piece of information. For plain pointers, the
- * behaviour is slightly odd: One cannot pass either the 0
- * flag nor a precision to %p without gcc complaining, and if
- * one explicitly gives a field width, the number is no longer
- * zero-padded.
- */
- test("|" PTR1_STR PTR1_SPACES " | " PTR1_SPACES PTR1_STR "|",
- "|%-*p|%*p|", PTR_WIDTH+2, PTR1, PTR_WIDTH+2, PTR1);
- test("|" PTR2_STR " | " PTR2_STR "|",
- "|%-*p|%*p|", PTR_WIDTH+2, PTR2, PTR_WIDTH+2, PTR2);
+ int err;
- /*
- * Unrecognized %p extensions are treated as plain %p, but the
- * alphanumeric suffix is ignored (that is, does not occur in
- * the output.)
- */
- test("|"PTR1_ZEROES PTR1_STR"|", "|%p0y|", PTR1);
- test("|"PTR2_STR"|", "|%p0y|", PTR2);
+ err = plain_hash();
+ if (err) {
+ pr_warn("plain 'p' does not appear to be hashed\n");
+ failed_tests++;
+ return;
+ }
+
+ err = plain_format();
+ if (err) {
+ pr_warn("hashing plain 'p' has unexpected format\n");
+ failed_tests++;
+ }
}
static void __init
@@ -251,6 +282,7 @@ symbol_ptr(void)
static void __init
kernel_ptr(void)
{
+ /* We can't test this without access to kptr_restrict. */
}
static void __init
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 8dc5cf85cef4..d69452a0f2fa 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -33,6 +33,8 @@
#include <linux/uuid.h>
#include <linux/of.h>
#include <net/addrconf.h>
+#include <linux/siphash.h>
+#include <linux/compiler.h>
#ifdef CONFIG_BLOCK
#include <linux/blkdev.h>
#endif
@@ -1644,6 +1646,73 @@ char *device_node_string(char *buf, char *end, struct device_node *dn,
return widen_string(buf, buf - buf_start, end, spec);
}
+static bool have_filled_random_ptr_key __read_mostly;
+static siphash_key_t ptr_key __read_mostly;
+
+static void fill_random_ptr_key(struct random_ready_callback *unused)
+{
+ get_random_bytes(&ptr_key, sizeof(ptr_key));
+ /*
+ * have_filled_random_ptr_key==true is dependent on get_random_bytes().
+ * ptr_to_id() needs to see have_filled_random_ptr_key==true
+ * after get_random_bytes() returns.
+ */
+ smp_mb();
+ WRITE_ONCE(have_filled_random_ptr_key, true);
+}
+
+static struct random_ready_callback random_ready = {
+ .func = fill_random_ptr_key
+};
+
+static int __init initialize_ptr_random(void)
+{
+ int ret = add_random_ready_callback(&random_ready);
+
+ if (!ret) {
+ return 0;
+ } else if (ret == -EALREADY) {
+ fill_random_ptr_key(&random_ready);
+ return 0;
+ }
+
+ return ret;
+}
+early_initcall(initialize_ptr_random);
+
+/* Maps a pointer to a 32 bit unique identifier. */
+static char *ptr_to_id(char *buf, char *end, void *ptr, struct printf_spec spec)
+{
+ unsigned long hashval;
+ const int default_width = 2 * sizeof(ptr);
+
+ if (unlikely(!have_filled_random_ptr_key)) {
+ spec.field_width = default_width;
+ /* string length must be less than default_width */
+ return string(buf, end, "(ptrval)", spec);
+ }
+
+#ifdef CONFIG_64BIT
+ hashval = (unsigned long)siphash_1u64((u64)ptr, &ptr_key);
+ /*
+ * Mask off the first 32 bits, this makes explicit that we have
+ * modified the address (and 32 bits is plenty for a unique ID).
+ */
+ hashval = hashval & 0xffffffff;
+#else
+ hashval = (unsigned long)siphash_1u32((u32)ptr, &ptr_key);
+#endif
+
+ spec.flags |= SMALL;
+ if (spec.field_width == -1) {
+ spec.field_width = default_width;
+ spec.flags |= ZEROPAD;
+ }
+ spec.base = 16;
+
+ return number(buf, end, hashval, spec);
+}
+
/*
* Show a '%p' thing. A kernel extension is that the '%p' is followed
* by an extra set of alphanumeric characters that are extended format
@@ -1754,6 +1823,9 @@ char *device_node_string(char *buf, char *end, struct device_node *dn,
* Note: The difference between 'S' and 'F' is that on ia64 and ppc64
* function pointers are really function descriptors, which contain a
* pointer to the real address.
+ *
+ * Note: The default behaviour (unadorned %p) is to hash the address,
+ * rendering it useful as a unique identifier.
*/
static noinline_for_stack
char *pointer(const char *fmt, char *buf, char *end, void *ptr,
@@ -1869,14 +1941,9 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
return device_node_string(buf, end, ptr, spec, fmt + 1);
}
}
- spec.flags |= SMALL;
- if (spec.field_width == -1) {
- spec.field_width = default_width;
- spec.flags |= ZEROPAD;
- }
- spec.base = 16;
- return number(buf, end, (unsigned long) ptr, spec);
+ /* default is to _not_ leak addresses, hash before printing */
+ return ptr_to_id(buf, end, ptr, spec);
}
/*
--
2.7.4
^ permalink raw reply related
* [PATCH V11 4/5] vsprintf: add printk specifier %px
From: Tobin C. Harding @ 2017-11-29 2:05 UTC (permalink / raw)
To: kernel-hardening
Cc: Tobin C. Harding, Linus Torvalds, Jason A. Donenfeld,
Theodore Ts'o, Kees Cook, Paolo Bonzini, Tycho Andersen,
Roberts, William C, Tejun Heo, Jordan Glover, Greg KH,
Petr Mladek, Joe Perches, Ian Campbell, Sergey Senozhatsky,
Catalin Marinas, Will Deacon, Steven Rostedt, Chris Fries,
Dave Weinstein
In-Reply-To: <1511921105-3647-1-git-send-email-me@tobin.cc>
printk specifier %p now hashes all addresses before printing. Sometimes
we need to see the actual unmodified address. This can be achieved using
%lx but then we face the risk that if in future we want to change the
way the Kernel handles printing of pointers we will have to grep through
the already existent 50 000 %lx call sites. Let's add specifier %px as a
clear, opt-in, way to print a pointer and maintain some level of
isolation from all the other hex integer output within the Kernel.
Add printk specifier %px to print the actual unmodified address.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Documentation/printk-formats.txt | 18 +++++++++++++++++-
lib/vsprintf.c | 18 ++++++++++++++++++
scripts/checkpatch.pl | 2 +-
3 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index b4e668ac4fe3..aa0a776c817a 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -49,7 +49,8 @@ Pointer Types
Pointers printed without a specifier extension (i.e unadorned %p) are
hashed to give a unique identifier without leaking kernel addresses to user
-space. On 64 bit machines the first 32 bits are zeroed.
+space. On 64 bit machines the first 32 bits are zeroed. If you _really_
+want the address see %px below.
::
@@ -106,6 +107,21 @@ For printing kernel pointers which should be hidden from unprivileged
users. The behaviour of ``%pK`` depends on the ``kptr_restrict sysctl`` - see
Documentation/sysctl/kernel.txt for more details.
+Unmodified Addresses
+====================
+
+::
+
+ %px 01234567 or 0123456789abcdef
+
+For printing pointers when you _really_ want to print the address. Please
+consider whether or not you are leaking sensitive information about the
+Kernel layout in memory before printing pointers with %px. %px is
+functionally equivalent to %lx. %px is preferred to %lx because it is more
+uniquely grep'able. If, in the future, we need to modify the way the Kernel
+handles printing pointers it will be nice to be able to find the call
+sites.
+
Struct Resources
================
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index d69452a0f2fa..d960aead0336 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1646,6 +1646,20 @@ char *device_node_string(char *buf, char *end, struct device_node *dn,
return widen_string(buf, buf - buf_start, end, spec);
}
+static noinline_for_stack
+char *pointer_string(char *buf, char *end, const void *ptr,
+ struct printf_spec spec)
+{
+ spec.base = 16;
+ spec.flags |= SMALL;
+ if (spec.field_width == -1) {
+ spec.field_width = 2 * sizeof(ptr);
+ spec.flags |= ZEROPAD;
+ }
+
+ return number(buf, end, (unsigned long int)ptr, spec);
+}
+
static bool have_filled_random_ptr_key __read_mostly;
static siphash_key_t ptr_key __read_mostly;
@@ -1818,6 +1832,8 @@ static char *ptr_to_id(char *buf, char *end, void *ptr, struct printf_spec spec)
* c major compatible string
* C full compatible string
*
+ * - 'x' For printing the address. Equivalent to "%lx".
+ *
* ** Please update also Documentation/printk-formats.txt when making changes **
*
* Note: The difference between 'S' and 'F' is that on ia64 and ppc64
@@ -1940,6 +1956,8 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
case 'F':
return device_node_string(buf, end, ptr, spec, fmt + 1);
}
+ case 'x':
+ return pointer_string(buf, end, ptr, spec);
}
/* default is to _not_ leak addresses, hash before printing */
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 95cda3ecc66b..040aa79e1d9d 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5753,7 +5753,7 @@ sub process {
for (my $count = $linenr; $count <= $lc; $count++) {
my $fmt = get_quoted_string($lines[$count - 1], raw_line($count, 0));
$fmt =~ s/%%//g;
- if ($fmt =~ /(\%[\*\d\.]*p(?![\WFfSsBKRraEhMmIiUDdgVCbGNO]).)/) {
+ if ($fmt =~ /(\%[\*\d\.]*p(?![\WFfSsBKRraEhMmIiUDdgVCbGNOx]).)/) {
$bad_extension = $1;
last;
}
--
2.7.4
^ permalink raw reply related
* [PATCH V11 5/5] kasan: use %px to print addresses instead of %p
From: Tobin C. Harding @ 2017-11-29 2:05 UTC (permalink / raw)
To: kernel-hardening
Cc: Tobin C. Harding, Linus Torvalds, Jason A. Donenfeld,
Theodore Ts'o, Kees Cook, Paolo Bonzini, Tycho Andersen,
Roberts, William C, Tejun Heo, Jordan Glover, Greg KH,
Petr Mladek, Joe Perches, Ian Campbell, Sergey Senozhatsky,
Catalin Marinas, Will Deacon, Steven Rostedt, Chris Fries,
Dave Weinstein
In-Reply-To: <1511921105-3647-1-git-send-email-me@tobin.cc>
Pointers printed with %p are now hashed by default. Kasan needs the
actual address. We can use the new printk specifier %px for this
purpose.
Use %px instead of %p to print addresses.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
mm/kasan/report.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 6bcfb01ba038..410c8235e671 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -134,7 +134,7 @@ static void print_error_description(struct kasan_access_info *info)
pr_err("BUG: KASAN: %s in %pS\n",
bug_type, (void *)info->ip);
- pr_err("%s of size %zu at addr %p by task %s/%d\n",
+ pr_err("%s of size %zu at addr %px by task %s/%d\n",
info->is_write ? "Write" : "Read", info->access_size,
info->access_addr, current->comm, task_pid_nr(current));
}
@@ -206,7 +206,7 @@ static void describe_object_addr(struct kmem_cache *cache, void *object,
const char *rel_type;
int rel_bytes;
- pr_err("The buggy address belongs to the object at %p\n"
+ pr_err("The buggy address belongs to the object at %px\n"
" which belongs to the cache %s of size %d\n",
object, cache->name, cache->object_size);
@@ -225,7 +225,7 @@ static void describe_object_addr(struct kmem_cache *cache, void *object,
}
pr_err("The buggy address is located %d bytes %s of\n"
- " %d-byte region [%p, %p)\n",
+ " %d-byte region [%px, %px)\n",
rel_bytes, rel_type, cache->object_size, (void *)object_addr,
(void *)(object_addr + cache->object_size));
}
@@ -302,7 +302,7 @@ static void print_shadow_for_address(const void *addr)
char shadow_buf[SHADOW_BYTES_PER_ROW];
snprintf(buffer, sizeof(buffer),
- (i == 0) ? ">%p: " : " %p: ", kaddr);
+ (i == 0) ? ">%px: " : " %px: ", kaddr);
/*
* We should not pass a shadow pointer to generic
* function, because generic functions may try to
--
2.7.4
^ permalink raw reply related
* Re: [iproute2 -net-next] build broken ...
From: Stephen Hemminger @ 2017-11-29 2:15 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Jakub Kicinski, netdev
In-Reply-To: <5982488b-c6cb-71e0-356e-04d4e3485fe4@iogearbox.net>
On Wed, 29 Nov 2017 02:05:09 +0100
Daniel Borkmann <daniel@iogearbox.net> wrote:
> Hi Stephen,
>
> after merge of master into net-next branch the build is now broken
> for BPF loader as follows:
>
> # make
>
> lib
> make[1]: Entering directory '/home/darkstar/iproute2/lib'
> CC libgenl.o
> CC ll_map.o
> CC libnetlink.o
> libnetlink.c:120:2: warning: #warning "libmnl required for error support" [-Wcpp]
> #warning "libmnl required for error support"
> ^~~~~~~
> AR libnetlink.a
> CC utils.o
> CC rt_names.o
> CC ll_types.o
> CC ll_proto.o
> CC ll_addr.o
> CC inet_proto.o
> CC namespace.o
> CC json_writer.o
> CC json_print.o
> CC names.o
> CC color.o
> CC bpf.o
> bpf.c: In function ‘bpf_prog_load_dev’:
> bpf.c:1080:6: error: ‘union bpf_attr’ has no member named ‘prog_ifindex’; did you mean ‘prog_id’?
> attr.prog_ifindex = ifindex;
> ^
> ../config.mk:39: recipe for target 'bpf.o' failed
> make[1]: *** [bpf.o] Error 1
> make[1]: Leaving directory '/home/darkstar/iproute2/lib'
> Makefile:59: recipe for target 'all' failed
> make: *** [all] Error 2
>
> Can you rebase kernel headers to fix it, in net-next branch they
> are not up to date which is why the build error occurs in combination
> with below merged series?
>
> Thanks,
> Daniel
>
>
> On 11/24/2017 03:11 AM, Jakub Kicinski wrote:
> > Hi!
> >
> > This series allows us to pass ifindex automatically when we
> > set up TC cls_bpf or XDP offload. There is a fair bit of
> > refactoring to separate the parse and load stages of lib/bpf.c.
> > In case of TC the skip_sw flag may come after the program
> > arguments (e.g. "bpf obj prog.o da skip_sw"), so we can't
> > just load the program as we parse the arguments. Note that
> > this impacts only loading of the program, all other supported
> > methods of finding a program (pinned, bytecode, bytefile-file)
> > are handled as previously, the load call will do nothing for
> > them.
> >
> > To simplify the implementation f_bpf and m_bpf will no longer
> > allow specifying programs multiple times. Device ifindex is
> > also resolved before running filter-specific code.
> >
> >
> > Jakub Kicinski (11):
> > bpf: pass program type in struct bpf_cfg_in
> > bpf: keep parsed program mode in struct bpf_cfg_in
> > bpf: allocate opcode table in struct bpf_cfg_in
> > bpf: split parse from program loading
> > bpf: rename bpf_parse_common() to bpf_parse_and_load_common()
> > bpf: expose bpf_parse_common() and bpf_load_common()
> > bpf: allow loading programs for a specific ifindex
> > {f,m}_bpf: don't allow specifying multiple bpf programs
> > tc_filter: resolve device name before parsing filter
> > f_bpf: communicate ifindex for eBPF offload
> > iplink: communicate ifindex for xdp offload
> >
> > include/bpf_util.h | 25 +++++++-
> > ip/iplink.c | 4 +-
> > ip/iplink_xdp.c | 13 ++++-
> > ip/iproute_lwtunnel.c | 3 +-
> > ip/xdp.h | 4 +-
> > lib/bpf.c | 155 ++++++++++++++++++++++++++++++--------------------
> > tc/f_bpf.c | 18 +++++-
> > tc/m_bpf.c | 6 +-
> > tc/tc_filter.c | 50 ++++++++--------
> > 9 files changed, 178 insertions(+), 100 deletions(-)
> >
>
Are you using your own uapi headers?
On current master branch...
$ git grep prog_ifindex
include/uapi/linux/bpf.h: __u32 prog_ifindex; /* ifindex of netdev to prep for */
lib/bpf.c: attr.prog_ifindex = ifindex;
^ permalink raw reply
* Re: [iproute2 -net-next] build broken ...
From: Stephen Hemminger @ 2017-11-29 2:17 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Jakub Kicinski, netdev
In-Reply-To: <5982488b-c6cb-71e0-356e-04d4e3485fe4@iogearbox.net>
On Wed, 29 Nov 2017 02:05:09 +0100
Daniel Borkmann <daniel@iogearbox.net> wrote:
> Hi Stephen,
>
> after merge of master into net-next branch the build is now broken
> for BPF loader as follows:
>
> # make
>
> lib
> make[1]: Entering directory '/home/darkstar/iproute2/lib'
> CC libgenl.o
> CC ll_map.o
> CC libnetlink.o
> libnetlink.c:120:2: warning: #warning "libmnl required for error support" [-Wcpp]
> #warning "libmnl required for error support"
> ^~~~~~~
> AR libnetlink.a
> CC utils.o
> CC rt_names.o
> CC ll_types.o
> CC ll_proto.o
> CC ll_addr.o
> CC inet_proto.o
> CC namespace.o
> CC json_writer.o
> CC json_print.o
> CC names.o
> CC color.o
> CC bpf.o
> bpf.c: In function ‘bpf_prog_load_dev’:
> bpf.c:1080:6: error: ‘union bpf_attr’ has no member named ‘prog_ifindex’; did you mean ‘prog_id’?
> attr.prog_ifindex = ifindex;
> ^
> ../config.mk:39: recipe for target 'bpf.o' failed
> make[1]: *** [bpf.o] Error 1
> make[1]: Leaving directory '/home/darkstar/iproute2/lib'
> Makefile:59: recipe for target 'all' failed
> make: *** [all] Error 2
>
> Can you rebase kernel headers to fix it, in net-next branch they
> are not up to date which is why the build error occurs in combination
> with below merged series?
>
> Thanks,
> Daniel
>
>
> On 11/24/2017 03:11 AM, Jakub Kicinski wrote:
> > Hi!
> >
> > This series allows us to pass ifindex automatically when we
> > set up TC cls_bpf or XDP offload. There is a fair bit of
> > refactoring to separate the parse and load stages of lib/bpf.c.
> > In case of TC the skip_sw flag may come after the program
> > arguments (e.g. "bpf obj prog.o da skip_sw"), so we can't
> > just load the program as we parse the arguments. Note that
> > this impacts only loading of the program, all other supported
> > methods of finding a program (pinned, bytecode, bytefile-file)
> > are handled as previously, the load call will do nothing for
> > them.
> >
> > To simplify the implementation f_bpf and m_bpf will no longer
> > allow specifying programs multiple times. Device ifindex is
> > also resolved before running filter-specific code.
> >
> >
> > Jakub Kicinski (11):
> > bpf: pass program type in struct bpf_cfg_in
> > bpf: keep parsed program mode in struct bpf_cfg_in
> > bpf: allocate opcode table in struct bpf_cfg_in
> > bpf: split parse from program loading
> > bpf: rename bpf_parse_common() to bpf_parse_and_load_common()
> > bpf: expose bpf_parse_common() and bpf_load_common()
> > bpf: allow loading programs for a specific ifindex
> > {f,m}_bpf: don't allow specifying multiple bpf programs
> > tc_filter: resolve device name before parsing filter
> > f_bpf: communicate ifindex for eBPF offload
> > iplink: communicate ifindex for xdp offload
> >
> > include/bpf_util.h | 25 +++++++-
> > ip/iplink.c | 4 +-
> > ip/iplink_xdp.c | 13 ++++-
> > ip/iproute_lwtunnel.c | 3 +-
> > ip/xdp.h | 4 +-
> > lib/bpf.c | 155 ++++++++++++++++++++++++++++++--------------------
> > tc/f_bpf.c | 18 +++++-
> > tc/m_bpf.c | 6 +-
> > tc/tc_filter.c | 50 ++++++++--------
> > 9 files changed, 178 insertions(+), 100 deletions(-)
> >
>
Sorry, net-next branch had out of date headers. Now fixed.
^ permalink raw reply
* Re: [PATCH V11 4/5] vsprintf: add printk specifier %px
From: Linus Torvalds @ 2017-11-29 2:29 UTC (permalink / raw)
To: Tobin C. Harding
Cc: kernel-hardening@lists.openwall.com, Jason A. Donenfeld,
Theodore Ts'o, Kees Cook, Paolo Bonzini, Tycho Andersen,
Roberts, William C, Tejun Heo, Jordan Glover, Greg KH,
Petr Mladek, Joe Perches, Ian Campbell, Sergey Senozhatsky,
Catalin Marinas, Will Deacon, Steven Rostedt, Chris Fries,
Dave Weinstein
In-Reply-To: <1511921105-3647-5-git-send-email-me@tobin.cc>
On Tue, Nov 28, 2017 at 6:05 PM, Tobin C. Harding <me@tobin.cc> wrote:
>
> Let's add specifier %px as a
> clear, opt-in, way to print a pointer and maintain some level of
> isolation from all the other hex integer output within the Kernel.
Yes, I like this model. It's easy and it's obvious ("'x' for hex"),
and it gives people a good way to say "yes, I really want the actual
address as hex" for if/when the hashed pointer doesn't work for some
reason.
So me likey.
And as with the address leaking script, I'd like it even more if you
made it a git tree and I'll pull it.
Thanks,
Linus
^ permalink raw reply
* Re: [PATCH V11 2/5] vsprintf: refactor %pK code out of pointer()
From: Steven Rostedt @ 2017-11-29 2:39 UTC (permalink / raw)
To: Tobin C. Harding
Cc: kernel-hardening, Linus Torvalds, Jason A. Donenfeld,
Theodore Ts'o, Kees Cook, Paolo Bonzini, Tycho Andersen,
Roberts, William C, Tejun Heo, Jordan Glover, Greg KH,
Petr Mladek, Joe Perches, Ian Campbell, Sergey Senozhatsky,
Catalin Marinas, Will Deacon, Chris Fries, Dave Weinstein,
Daniel Micay
In-Reply-To: <1511921105-3647-3-git-send-email-me@tobin.cc>
On Wed, 29 Nov 2017 13:05:02 +1100
"Tobin C. Harding" <me@tobin.cc> wrote:
> + /*
> + * kptr_restrict==1 cannot be used in IRQ context
> + * because its test for CAP_SYSLOG would be meaningless.
> + */
> + if (in_irq() || in_serving_softirq() || in_nmi())
This could be replaced with:
if (!in_task())
Which is actually more efficient.
-- Steve
> + return string(buf, end, "pK-error", spec);
^ permalink raw reply
* Re: [PATCH v4 1/8] dt-bindings: Add Cavium Octeon Common Ethernet Interface.
From: David Daney @ 2017-11-29 2:54 UTC (permalink / raw)
To: Andrew Lunn, David Daney
Cc: linux-mips, ralf, James Hogan, netdev, David S. Miller,
Rob Herring, Mark Rutland, devel, Greg Kroah-Hartman,
linux-kernel, Steven J. Hill, devicetree, Florian Fainelli,
Carlos Munoz
In-Reply-To: <20171129020153.GN14512@lunn.ch>
On 11/28/2017 06:01 PM, Andrew Lunn wrote:
> On Tue, Nov 28, 2017 at 04:55:33PM -0800, David Daney wrote:
>> From: Carlos Munoz <cmunoz@cavium.com>
>>
>> Add bindings for Common Ethernet Interface (BGX) block.
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Carlos Munoz <cmunoz@cavium.com>
>> Signed-off-by: Steven J. Hill <Steven.Hill@cavium.com>
>> Signed-off-by: David Daney <david.daney@cavium.com>
>> ---
>> .../devicetree/bindings/net/cavium-bgx.txt | 61 ++++++++++++++++++++++
>> 1 file changed, 61 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/cavium-bgx.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/cavium-bgx.txt b/Documentation/devicetree/bindings/net/cavium-bgx.txt
>> new file mode 100644
>> index 000000000000..830c5f08dddd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/cavium-bgx.txt
>> @@ -0,0 +1,61 @@
>> +* Common Ethernet Interface (BGX) block
>> +
>> +Properties:
>> +
>> +- compatible: "cavium,octeon-7890-bgx": Compatibility with all cn7xxx SOCs.
>> +
>> +- reg: The base address of the BGX block.
>> +
>> +- #address-cells: Must be <1>.
>> +
>> +- #size-cells: Must be <0>. BGX addresses have no size component.
>> +
>> +A BGX block has several children, each representing an Ethernet
>> +interface.
>> +
>> +
>> +* Ethernet Interface (BGX port) connects to PKI/PKO
>> +
>> +Properties:
>> +
>> +- compatible: "cavium,octeon-7890-bgx-port": Compatibility with all
>> + cn7xxx SOCs.
>> +
>> + "cavium,octeon-7360-xcv": Compatibility with cn73xx SOCs
>> + for RGMII.
>> +
>> +- reg: The index of the interface within the BGX block.
>> +
>> +Optional properties:
>> +
>> +- local-mac-address: Mac address for the interface.
>> +
>> +- phy-handle: phandle to the phy node connected to the interface.
>> +
>> +- phy-mode: described in ethernet.txt.
>> +
>> +- fixed-link: described in fixed-link.txt.
>> +
>> +Example:
>> +
>> + ethernet-mac-nexus@11800e0000000 {
>> + compatible = "cavium,octeon-7890-bgx";
>> + reg = <0x00011800 0xe0000000 0x00000000 0x01000000>;
>
> Hi David
>
> In the probe function we have:
>
> + reg = of_get_property(pdev->dev.of_node, "reg", NULL);
> + addr = of_translate_address(pdev->dev.of_node, reg);
> + interface = (addr >> 24) & 0xf;
> + numa_node = (addr >> 36) & 0x7;
>
> Is this documented somewhere?
In the Hardware Reference Manual for the chips.
> The numa_node is particularly
> interesting. MMIO changes depends on what node this is in the cluster?
Yes. Bits 38..36 of MMIO addresses indicate which NUMA node the
corresponding hardware device resides on. Some operations can only be
performed by a CPU on the same NUMA node as the device (RX or
TX-complete interrupts for example) Other operations can cross CPU
nodes (TX packet submission for example)
>
> Andrew
>
^ permalink raw reply
* Re: [PATCH] sched/deadline: fix one-bit signed bitfields to be unsigned
From: Jakub Kicinski @ 2017-11-29 4:07 UTC (permalink / raw)
To: Jeff Kirsher
Cc: mingo, peterz, Jacob Keller, linux-kernel, netdev, nhorman,
sassmann, jogreene, luca abeni
In-Reply-To: <20171128203619.71430-1-jeffrey.t.kirsher@intel.com>
On Tue, 28 Nov 2017 12:36:19 -0800, Jeff Kirsher wrote:
> From: Jacob Keller <jacob.e.keller@intel.com>
>
> Commit 799ba82de01e ("sched/deadline: Use C bitfields for the state
> flags", 2017-10-10) introduced the use of C bitfields for these
> variables. However, sparse complains about them:
>
> ./include/linux/sched.h:476:62: error: dubious one-bit signed bitfield
> ./include/linux/sched.h:477:62: error: dubious one-bit signed bitfield
> ./include/linux/sched.h:478:62: error: dubious one-bit signed bitfield
> ./include/linux/sched.h:479:62: error: dubious one-bit signed bitfield
>
> This is because a one-bit signed bitfield can only hold the values 0 and
> -1, which can cause problems if the program expects to be able to
> represent the value positive 1.
>
> In practice, this may not cause a bug since -1 would be considered
> "true" in logical tests, however we should avoid the practice anyways.
>
> Fixes: 799ba82de01e ("sched/deadline: Use C bitfields for the state flags", 2017-10-10)
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Cc: luca abeni <luca.abeni@santannapisa.it>
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This is already in Linus's tree (I've been waiting for it to land as
well :))
commit aa5222e92f8000ed3c1c38dddf11c83222aadfb3
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri Oct 13 10:01:22 2017 +0300
sched/deadline: Don't use dubious signed bitfields
It doesn't cause a run-time bug, but these bitfields should be unsigned.
When it's signed ->dl_throttled is set to either 0 or -1, instead of
0 and 1 as expected.
The sched.h file is included into tons of places so Sparse generates
a flood of warnings like this:
./include/linux/sched.h:477:54: error: dubious one-bit signed bitfield
Reported-by: Matthew Wilcox <willy@infradead.org>
Reported-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Luca Abeni <luca.abeni@santannapisa.it>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: kernel-janitors@vger.kernel.org
Cc: luca abeni <luca.abeni@santannapisa.it>
Link: http://lkml.kernel.org/r/20171013070121.dzcncojuj2f4utij@mwanda
Signed-off-by: Ingo Molnar <mingo@kernel.org>
^ permalink raw reply
* Re: [PATCH V11 2/5] vsprintf: refactor %pK code out of pointer()
From: Tobin C. Harding @ 2017-11-29 4:27 UTC (permalink / raw)
To: Steven Rostedt
Cc: kernel-hardening, Linus Torvalds, Jason A. Donenfeld,
Theodore Ts'o, Kees Cook, Paolo Bonzini, Tycho Andersen,
Roberts, William C, Tejun Heo, Jordan Glover, Greg KH,
Petr Mladek, Joe Perches, Ian Campbell, Sergey Senozhatsky,
Catalin Marinas, Will Deacon, Chris Fries, Dave Weinstein,
Daniel Micay
In-Reply-To: <20171128213957.2edf5069@gandalf.local.home>
On Tue, Nov 28, 2017 at 09:39:57PM -0500, Steven Rostedt wrote:
> On Wed, 29 Nov 2017 13:05:02 +1100
> "Tobin C. Harding" <me@tobin.cc> wrote:
>
> > + /*
> > + * kptr_restrict==1 cannot be used in IRQ context
> > + * because its test for CAP_SYSLOG would be meaningless.
> > + */
> > + if (in_irq() || in_serving_softirq() || in_nmi())
>
> This could be replaced with:
>
> if (!in_task())
>
> Which is actually more efficient.
thanks for the comment Steve. At this late stage in the game do you mind
if I don't include this change in this set. The code line in question is
only in the series because of refactoring. I'm comfortable arguing that
improving efficiency is out of scope ;)
thanks,
Tobin.
^ permalink raw reply
* Re: [PATCH V11 4/5] vsprintf: add printk specifier %px
From: Tobin C. Harding @ 2017-11-29 4:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: kernel-hardening@lists.openwall.com, Jason A. Donenfeld,
Theodore Ts'o, Kees Cook, Paolo Bonzini, Tycho Andersen,
Roberts, William C, Tejun Heo, Jordan Glover, Greg KH,
Petr Mladek, Joe Perches, Ian Campbell, Sergey Senozhatsky,
Catalin Marinas, Will Deacon, Steven Rostedt, Chris Fries,
Dave Weinstein
In-Reply-To: <CA+55aFxgGb13hqoNQ8bzFn4ENZM25PBSdi5pkFUBa5Hk+j-s3Q@mail.gmail.com>
On Tue, Nov 28, 2017 at 06:29:02PM -0800, Linus Torvalds wrote:
> On Tue, Nov 28, 2017 at 6:05 PM, Tobin C. Harding <me@tobin.cc> wrote:
> >
> > Let's add specifier %px as a
> > clear, opt-in, way to print a pointer and maintain some level of
> > isolation from all the other hex integer output within the Kernel.
>
> Yes, I like this model. It's easy and it's obvious ("'x' for hex"),
> and it gives people a good way to say "yes, I really want the actual
> address as hex" for if/when the hashed pointer doesn't work for some
> reason.
>
> So me likey.
BOOM!
> And as with the address leaking script, I'd like it even more if you
> made it a git tree and I'll pull it.
Pull request to come.
thanks,
Tobin.
^ permalink raw reply
* [PATCH net] myri10ge: Update MAINTAINERS
From: Hyong-Youb Kim @ 2017-11-29 5:03 UTC (permalink / raw)
To: davem; +Cc: netdev, Chris Lee, Hyong-Youb Kim
Change the maintainer to Chris Lee who has access to Myricom hardware
and can test/review. Update the website URL.
Signed-off-by: Hyong-Youb Kim <hykim@myri.com>
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52f..77d819b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9331,9 +9331,9 @@ F: drivers/gpu/drm/mxsfb/
F: Documentation/devicetree/bindings/display/mxsfb-drm.txt
MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE)
-M: Hyong-Youb Kim <hykim@myri.com>
+M: Chris Lee <christopher.lee@cspi.com>
L: netdev@vger.kernel.org
-W: https://www.myricom.com/support/downloads/myri10ge.html
+W: https://www.cspi.com/ethernet-products/support/downloads/
S: Supported
F: drivers/net/ethernet/myricom/myri10ge/
--
1.9.0
^ permalink raw reply related
* Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()
From: Jason Wang @ 2017-11-29 5:06 UTC (permalink / raw)
To: wexu, virtualization, netdev, linux-kernel; +Cc: mjrosato, mst
In-Reply-To: <9b234fdd-baa3-f919-6c72-f6768265f1ca@redhat.com>
On 2017年11月29日 09:53, Jason Wang wrote:
>
>
> On 2017年11月29日 01:17, wexu@redhat.com wrote:
>> From: Wei Xu <wexu@redhat.com>
>>
>> Matthew found a roughly 40% tcp throughput regression with commit
>> c67df11f(vhost_net: try batch dequing from skb array) as discussed
>> in the following thread:
>> https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
>>
>> Eventually we figured out that it was a skb leak in handle_rx()
>> when sending packets to the VM. This usually happens when a guest
>> can not drain out vq as fast as vhost fills in, afterwards it sets
>> off the traffic jam and leaks skb(s) which occurs as no headcount
>> to send on the vq from vhost side.
>>
>> This can be avoided by making sure we have got enough headcount
>> before actually consuming a skb from the batched rx array while
>> transmitting, which is simply done by deferring it a moment later
>> in this patch.
>>
>> Signed-off-by: Wei Xu <wexu@redhat.com>
>> ---
>> drivers/vhost/net.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
>> index 8d626d7..e76535e 100644
>> --- a/drivers/vhost/net.c
>> +++ b/drivers/vhost/net.c
>> @@ -778,8 +778,6 @@ static void handle_rx(struct vhost_net *net)
>> /* On error, stop handling until the next kick. */
>> if (unlikely(headcount < 0))
>> goto out;
>> - if (nvq->rx_array)
>> - msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
>> /* On overrun, truncate and discard */
>> if (unlikely(headcount > UIO_MAXIOV)) {
>
> You need do msg.msg_control = vhost_net_buf_consume() here too,
> otherwise we may still get it leaked.
>
> Thanks
Not a leak actually, but the packet won't be consumed and we will hit
UIO_MAXIOV forever in this case.
Thanks
^ permalink raw reply
* Re: [PATCH v2 31/35] earlycon: add reg-offset to physical address before mapping
From: Greentime Hu @ 2017-11-29 5:40 UTC (permalink / raw)
To: Greg KH
Cc: Greentime, Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial
In-Reply-To: <20171128142507.GA17797@kroah.com>
2017-11-28 22:25 GMT+08:00 Greg KH <greg@kroah.com>:
> On Mon, Nov 27, 2017 at 08:28:18PM +0800, Greentime Hu wrote:
>> From: Greentime Hu <greentime@andestech.com>
>>
>> It will get the wrong virtual address because port->mapbase is not added
>> the correct reg-offset yet. We have to update it before earlycon_map()
>> is called
>> ---
>> drivers/tty/serial/earlycon.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> No signed-off-by line?
Sorry I forget it.
Signed-off-by: Greentime Hu <greentime@andestech.com>
I will add it in the next version patch.
^ permalink raw reply
* Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()
From: Wei Xu @ 2017-11-29 5:44 UTC (permalink / raw)
To: Jason Wang; +Cc: virtualization, netdev, linux-kernel, mjrosato, mst
In-Reply-To: <37f16bef-4a59-b895-c61b-e3f473617411@redhat.com>
On Wed, Nov 29, 2017 at 01:06:28PM +0800, Jason Wang wrote:
>
>
> On 2017年11月29日 09:53, Jason Wang wrote:
> >
> >
> > On 2017年11月29日 01:17, wexu@redhat.com wrote:
> > > From: Wei Xu <wexu@redhat.com>
> > >
> > > Matthew found a roughly 40% tcp throughput regression with commit
> > > c67df11f(vhost_net: try batch dequing from skb array) as discussed
> > > in the following thread:
> > > https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
> > >
> > > Eventually we figured out that it was a skb leak in handle_rx()
> > > when sending packets to the VM. This usually happens when a guest
> > > can not drain out vq as fast as vhost fills in, afterwards it sets
> > > off the traffic jam and leaks skb(s) which occurs as no headcount
> > > to send on the vq from vhost side.
> > >
> > > This can be avoided by making sure we have got enough headcount
> > > before actually consuming a skb from the batched rx array while
> > > transmitting, which is simply done by deferring it a moment later
> > > in this patch.
> > >
> > > Signed-off-by: Wei Xu <wexu@redhat.com>
> > > ---
> > > drivers/vhost/net.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> > > index 8d626d7..e76535e 100644
> > > --- a/drivers/vhost/net.c
> > > +++ b/drivers/vhost/net.c
> > > @@ -778,8 +778,6 @@ static void handle_rx(struct vhost_net *net)
> > > /* On error, stop handling until the next kick. */
> > > if (unlikely(headcount < 0))
> > > goto out;
> > > - if (nvq->rx_array)
> > > - msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> > > /* On overrun, truncate and discard */
> > > if (unlikely(headcount > UIO_MAXIOV)) {
> >
> > You need do msg.msg_control = vhost_net_buf_consume() here too,
> > otherwise we may still get it leaked.
> >
> > Thanks
>
> Not a leak actually, but the packet won't be consumed and we will hit
> UIO_MAXIOV forever in this case.
I see, thanks, will make a v2.
>
> Thanks
^ permalink raw reply
* Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()
From: Wei Xu @ 2017-11-29 6:12 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtualization, netdev, linux-kernel, jasowang, mjrosato
In-Reply-To: <20171128193713-mutt-send-email-mst@kernel.org>
On Tue, Nov 28, 2017 at 07:50:58PM +0200, Michael S. Tsirkin wrote:
> On Tue, Nov 28, 2017 at 12:17:16PM -0500, wexu@redhat.com wrote:
> > From: Wei Xu <wexu@redhat.com>
> >
> > Matthew found a roughly 40% tcp throughput regression with commit
> > c67df11f(vhost_net: try batch dequing from skb array) as discussed
> > in the following thread:
> > https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
> >
> > Eventually we figured out that it was a skb leak in handle_rx()
> > when sending packets to the VM. This usually happens when a guest
> > can not drain out vq as fast as vhost fills in, afterwards it sets
> > off the traffic jam and leaks skb(s) which occurs as no headcount
> > to send on the vq from vhost side.
> >
> > This can be avoided by making sure we have got enough headcount
> > before actually consuming a skb from the batched rx array while
> > transmitting, which is simply done by deferring it a moment later
> > in this patch.
> >
> > Signed-off-by: Wei Xu <wexu@redhat.com>
>
> Looks like a good way to fix it, but it will still leak if recvmsg
> returns a wrong length (I'm not sure this can happen in practice, but
> best to keep it simple).
Right, it is better to defend this case, will include it in v2.
>
> Also, we need to add this before each recvmsg, including overrun,
> and discard on error.
OK.
Wei
>
> > ---
> > drivers/vhost/net.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> > index 8d626d7..e76535e 100644
> > --- a/drivers/vhost/net.c
> > +++ b/drivers/vhost/net.c
> > @@ -778,8 +778,6 @@ static void handle_rx(struct vhost_net *net)
> > /* On error, stop handling until the next kick. */
> > if (unlikely(headcount < 0))
> > goto out;
> > - if (nvq->rx_array)
> > - msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> > /* On overrun, truncate and discard */
> > if (unlikely(headcount > UIO_MAXIOV)) {
> > iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
> > @@ -809,6 +807,8 @@ static void handle_rx(struct vhost_net *net)
> > */
> > iov_iter_advance(&msg.msg_iter, vhost_hlen);
> > }
> > + if (nvq->rx_array)
> > + msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> > err = sock->ops->recvmsg(sock, &msg,
> > sock_len, MSG_DONTWAIT | MSG_TRUNC);
> > /* Userspace might have consumed the packet meanwhile:
> > --
> > 1.8.3.1
^ permalink raw reply
* Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()
From: Wei Xu @ 2017-11-29 6:32 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtualization, netdev, linux-kernel, jasowang, mjrosato
In-Reply-To: <20171128195140-mutt-send-email-mst@kernel.org>
On Tue, Nov 28, 2017 at 07:53:33PM +0200, Michael S. Tsirkin wrote:
> On Tue, Nov 28, 2017 at 12:17:16PM -0500, wexu@redhat.com wrote:
> > From: Wei Xu <wexu@redhat.com>
> >
> > Matthew found a roughly 40% tcp throughput regression with commit
> > c67df11f(vhost_net: try batch dequing from skb array) as discussed
> > in the following thread:
> > https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
> >
> > Eventually we figured out that it was a skb leak in handle_rx()
> > when sending packets to the VM. This usually happens when a guest
> > can not drain out vq as fast as vhost fills in, afterwards it sets
> > off the traffic jam and leaks skb(s) which occurs as no headcount
> > to send on the vq from vhost side.
> >
> > This can be avoided by making sure we have got enough headcount
> > before actually consuming a skb from the batched rx array while
> > transmitting, which is simply done by deferring it a moment later
> > in this patch.
> >
> > Signed-off-by: Wei Xu <wexu@redhat.com>
>
> Given the amount of effort Matthew has put into this,
> you definitely want
>
> Reported-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
>
> here.
>
Absolutely we want that, sorry for missed you here, Matthew. It is more
like you have figured out this issue independently all by yourself with
a wide assortment of extremely quick tests(tools, throughput, slub leak,
etc), and I am happy that I have the opportunity to do the paperwork on
behalf of you.:) Thanks a lot Matthew.
Wei
> Let's give credit where credit is due.
>
> Thanks a lot Matthew!
>
> > ---
> > drivers/vhost/net.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> > index 8d626d7..e76535e 100644
> > --- a/drivers/vhost/net.c
> > +++ b/drivers/vhost/net.c
> > @@ -778,8 +778,6 @@ static void handle_rx(struct vhost_net *net)
> > /* On error, stop handling until the next kick. */
> > if (unlikely(headcount < 0))
> > goto out;
> > - if (nvq->rx_array)
> > - msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> > /* On overrun, truncate and discard */
> > if (unlikely(headcount > UIO_MAXIOV)) {
> > iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
> > @@ -809,6 +807,8 @@ static void handle_rx(struct vhost_net *net)
> > */
> > iov_iter_advance(&msg.msg_iter, vhost_hlen);
> > }
> > + if (nvq->rx_array)
> > + msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> > err = sock->ops->recvmsg(sock, &msg,
> > sock_len, MSG_DONTWAIT | MSG_TRUNC);
> > /* Userspace might have consumed the packet meanwhile:
> > --
> > 1.8.3.1
^ permalink raw reply
* Re: [crypto v3 1/2] cxgb4: Add support for Inline IPSec Tx
From: Herbert Xu @ 2017-11-29 6:37 UTC (permalink / raw)
To: Atul Gupta; +Cc: linux-crypto, netdev, davem, steffen.klassert, Ganesh Goudar
In-Reply-To: <1510831599-31915-1-git-send-email-atul.gupta@chelsio.com>
On Thu, Nov 16, 2017 at 04:56:39PM +0530, Atul Gupta wrote:
> Added Tx routine for ULD
> - define interface for ULD Tx.
>
> Export routines used for Tx data
> - Routines common for data transmit are used by cxgb4 and chcr
> drivers.
> - EXPORT routines enable transmit from chcr driver.
>
> Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> ---
> V2: Fixed the build warnings and created patch against cryptodev
> to avoid possible merge conflicts
> V3: Fixed a build warning and added flag for data packet
Patch applied. Thanks.
--
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
* Re: [crypto v3 2/2] chcr: Add support for Inline IPSec
From: Herbert Xu @ 2017-11-29 6:37 UTC (permalink / raw)
To: Atul Gupta
Cc: linux-crypto, netdev, davem, steffen.klassert, Harsh Jain,
Ganesh Goudar
In-Reply-To: <1510831628-31955-1-git-send-email-atul.gupta@chelsio.com>
On Thu, Nov 16, 2017 at 04:57:08PM +0530, Atul Gupta wrote:
> register xfrmdev_ops callbacks, Send IPsec tunneled data
> to HW for inline processing.
> The driver use hardware crypto accelerator to encrypt and
> generate ICV for the transmitted packet in Inline mode.
>
> Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
> Signed-off-by: Harsh Jain <harsh@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> ---
> V2: Fixed the build warnings and created patch against cryptodev
> to avoid possible merge conflicts
> V3: Fixed a build warning and added flag for data packet
Patch applied. Thanks.
--
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
* Re: [5/8] crypto: remove unused hardirq.h
From: Herbert Xu @ 2017-11-29 6:38 UTC (permalink / raw)
To: Yang Shi
Cc: linux-kernel, linux-mm, linux-fsdevel, linux-crypto, netdev,
David S. Miller
In-Reply-To: <1510959741-31109-5-git-send-email-yang.s@alibaba-inc.com>
On Sat, Nov 18, 2017 at 07:02:18AM +0800, Yang Shi wrote:
> Preempt counter APIs have been split out, currently, hardirq.h just
> includes irq_enter/exit APIs which are not used by crypto at all.
>
> So, remove the unused hardirq.h.
>
> Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux-crypto@vger.kernel.org
Patch applied. Thanks.
--
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