* Attractive interest rate @ (2.75%) for project funding/Loan/finance from Coutts & Co U.K !!
From: COUTTS & CO @ 2018-09-26 3:38 UTC (permalink / raw)
To: Recipients
Coutts & Co Ltd
440 Strand, London, WC2R 0QS
Website: https://www.coutts.com
Telephone:+4420 3389 7785 & +4420 7753 1000
Fax:+44 872 110 3479
OUR REF: Coutts/UK/2018/LOANAPP
YOUR REF:LOANAPPT/Coutts/SEP/2018
TO WHOM IT MAY CONCERN
We give out both Local/International Loan starting from 2.75%* rate of interest annually.We offer non-collateral loans to both firms and individuals.
Our Loans can be taken over a term of 6 months to 25 years. Funds available For Most Projects Covering Real Estate, Industry And Other Forms Of Creativity In Some Major Countries.
You Might Be Interested In Submitting Your Business Proposal And Study For Evaluation.
We Do Not Promise Success Of Funding But We Shall Do Our Best To Help And Assist.
No Upfront Fees Or Payments.We Can Also Provide Bank Guarantees And SBLC's For Your Projects Including Monetization.
Please Contact Us For An Application And For More Instruction Please Email Us with the following information-FULL NAMES/COMPANY NAME,TELEPHONE NUMBER,PURPOSE OF LOAN/FINANCE AND PRESENT LOCATION At Email address:coutts.finance@mail.uk
Quick approvals | Disbursal in 72 hours* | FUND DIRECTLY DEPOSITED
© Copyright Coutts & Co 2018
^ permalink raw reply
* Re: r8169 hang on 4.18
From: Ortwin Glück @ 2018-09-26 15:17 UTC (permalink / raw)
To: Heiner Kallweit, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <9fb89abb-917a-44b6-5dff-9c4a0ed1fd6b@gmail.com>
On 25.09.18 20:44, Heiner Kallweit wrote:
> Unfortunately the lspci info doesn't allow to determine the exact chip type.
> Relevant would be the syslog info as you provided it in your first mail:
> r8169 0000:07:00.0 eth4: RTL8168h/8111h, 50:9a:4c:2e:92:be, XID 54100800, IRQ 16
> Are the chips on the extension card the same as the on-board chip?
They are different: G and H versions.
[ 1.696997] r8169 0000:03:00.0 eth0: RTL8168g/8111g at 0x (ptrval), 00:0a:cd:31:60:1f, XID
0c000800 IRQ 17
[ 1.712910] r8169 0000:04:00.0 eth1: RTL8168g/8111g at 0x (ptrval), 00:0a:cd:31:60:20, XID
0c000800 IRQ 18
[ 1.724969] r8169 0000:05:00.0 eth2: RTL8168g/8111g at 0x (ptrval), 00:0a:cd:31:60:21, XID
0c000800 IRQ 19
[ 1.736923] r8169 0000:06:00.0 eth3: RTL8168g/8111g at 0x (ptrval), 00:0a:cd:31:60:22, XID
0c000800 IRQ 16
[ 1.753031] r8169 0000:07:00.0 eth4: RTL8168h/8111h at 0x (ptrval), 50:9a:4c:2e:92:be, XID
14100800 IRQ 16
I am going to try your patch against 4.18.10 and report back!
Thanks,
Ortwin
^ permalink raw reply
* Re: [PATCH] Documentation: Add HOWTO Korean translation into BPF and XDP Reference Guide.
From: Chang-an Song @ 2018-09-26 9:11 UTC (permalink / raw)
To: Jonathan Corbet, tj; +Cc: netdev, daniel, davem
In-Reply-To: <20180924122033.16c63907@lwn.net>
Hello,
Thank you very much to Tejun and Jon for the review first.
I have summarized the my action items as below,
> I think this would still be helpful and a step in the right direction;
> however, I think it'd be helpful to explicitly note, in korean, that
> the translation is still work-in-progress and the readers are
> recommended to refer back to the english copy when there's any doubt.
1. I will add to comment in the NOTE explicitly that "the translation is still
work-in-progress and the readers are recommended to refer back to the
english copy when there's any doubt".
Thank you very much for your advice, Tejun.
> - Since you're adding a new document, could you please format it as RST
> and add it to index.rst with the other Korean translations? The
> original will have been in RST, so this should be relatively easy to
> do.
2. I need to convert the document format to rst file and
add a list of my current documents to the index.rst file, again.
> - The original document has a copyright assertion but no associated
> license. Do we know what the license is? I assume it's something
> that is free and GPL-compatible, but that would be good to know for
> sure.
3. I asked to main author Daniel that apache 2.0 license for this document.
I will need to do additional work for 1 and 2, and need to regenerate the patch.
Thank you very much for your advice, Jon.
If I have something to fix, please feel free to tell me.
BR/Leo
2018-09-25 3:20 GMT+09:00 Jonathan Corbet <corbet@lwn.net>:
> On Fri, 21 Sep 2018 13:22:38 +0900
> Changan Song <csongxdp@gmail.com> wrote:
>
>> Signed-off-by: Changan Song <csongxdp@gmail.com>
>> ---
>> Documentation/translations/ko_KR/bpf-xdp.txt | 3511 ++++++++++++++++++
>> 1 file changed, 3511 insertions(+)
>> create mode 100644 Documentation/translations/ko_KR/bpf-xdp.txt
>
> I can't judge the quality of the translation, of course, but I do have a
> couple of related questions:
>
> - Since you're adding a new document, could you please format it as RST
> and add it to index.rst with the other Korean translations? The
> original will have been in RST, so this should be relatively easy to
> do.
>
> - The original document has a copyright assertion but no associated
> license. Do we know what the license is? I assume it's something
> that is free and GPL-compatible, but that would be good to know for
> sure.
>
> Thanks for doing this work,
>
> jon
^ permalink raw reply
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Jason A. Donenfeld @ 2018-09-26 15:25 UTC (permalink / raw)
To: Andrew Lunn
Cc: Ard Biesheuvel, Jean-Philippe Aumasson, Netdev, LKML,
Russell King - ARM Linux, Samuel Neves, Linux Crypto Mailing List,
Andrew Lutomirski, Greg Kroah-Hartman, David Miller,
linux-arm-kernel
In-Reply-To: <20180926143614.GL1676@lunn.ch>
On Wed, Sep 26, 2018 at 4:36 PM Andrew Lunn <andrew@lunn.ch> wrote:
> The wireguard interface claims it is GSO capable. This means the
> network stack will pass it big chunks of data and leave it to the
> network interface to perform the segmentation into 1500 byte MTU
> frames on the wire. I've not looked at how wireguard actually handles
> these big chunks. But to get maximum performance, it should try to
> keep them whole, just add a header and/or trailer. Will wireguard pass
> these big chunks of data to the crypto code? Do we now have 64K blocks
> being worked on? Does the latency jump from 4K to 64K? That might be
> new, so the existing state of the tree does not help you here.
No, it only requests GSO superpackets so that it can group the pieces
and encrypt them on the same core. But they're each encrypted
separately (broken up immediately after ndo_start_xmit), and so they
wind up being ~1420 bytes each to encrypt. I spoke about this at
netdev2.2 if you're interested in the architecture; there's a paper:
https://www.wireguard.com/papers/wireguard-netdev22.pdf
https://www.youtube.com/watch?v=54orFwtQ1XY
https://www.wireguard.com/talks/netdev2017-slides.pdf
^ permalink raw reply
* [PATCH v3 0/5] netlink: nested policy validation
From: Johannes Berg @ 2018-09-26 9:15 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
This adds nested policy validation, which lets you specify the
nested attribute type, e.g. NLA_NESTED with sub-policy, or the
new NLA_NESTED_ARRAY with sub-sub-policy.
Changes in v2:
* move setting the bad attr pointer/message into validate_nla()
* remove the recursion patch since that's no longer needed
* simply skip the generic bad attr pointer/message setting in
case of nested nla_validate() failing since that could fail
only due to validate_nla() failing inside, which already sets
the extack information
Changes in v3:
* fix NLA_REJECT to have an error message if none is in policy
johannes
^ permalink raw reply
* [PATCH v3 1/5] netlink: remove NLA_NESTED_COMPAT
From: Johannes Berg @ 2018-09-26 9:15 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Johannes Berg
In-Reply-To: <20180926091534.22876-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
This isn't used anywhere, so we might as well get rid of it.
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/netlink.h | 2 --
lib/nlattr.c | 11 -----------
2 files changed, 13 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index 318b1ded3833..b680fe365e91 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -172,7 +172,6 @@ enum {
NLA_FLAG,
NLA_MSECS,
NLA_NESTED,
- NLA_NESTED_COMPAT,
NLA_NUL_STRING,
NLA_BINARY,
NLA_S8,
@@ -203,7 +202,6 @@ enum {
* NLA_BINARY Maximum length of attribute payload
* NLA_NESTED Don't use `len' field -- length verification is
* done by checking len of nested header (or empty)
- * NLA_NESTED_COMPAT Minimum length of structure payload
* NLA_U8, NLA_U16,
* NLA_U32, NLA_U64,
* NLA_S8, NLA_S16,
diff --git a/lib/nlattr.c b/lib/nlattr.c
index bb6fe5ed4ecf..120ad569e13d 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -140,17 +140,6 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
return -ERANGE;
break;
- case NLA_NESTED_COMPAT:
- if (attrlen < pt->len)
- return -ERANGE;
- if (attrlen < NLA_ALIGN(pt->len))
- break;
- if (attrlen < NLA_ALIGN(pt->len) + NLA_HDRLEN)
- return -ERANGE;
- nla = nla_data(nla) + NLA_ALIGN(pt->len);
- if (attrlen < NLA_ALIGN(pt->len) + NLA_HDRLEN + nla_len(nla))
- return -ERANGE;
- break;
case NLA_NESTED:
/* a nested attributes is allowed to be empty; if its not,
* it must have a size of at least NLA_HDRLEN.
--
2.14.4
^ permalink raw reply related
* [PATCH v3 3/5] netlink: move extack setting into validate_nla()
From: Johannes Berg @ 2018-09-26 9:15 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Johannes Berg
In-Reply-To: <20180926091534.22876-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
This unifies the code between nla_parse() which sets the bad
attribute pointer and an error message, and nla_validate()
which only sets the bad attribute pointer.
It also cleans up the code for NLA_REJECT and paves the way
for nested policy validation, as it will allow us to easily
skip setting the "generic" message without any extra args
like the **error_msg now, just passing the extack through is
now enough.
While at it, remove the unnecessary label in nla_parse().
Suggested-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
lib/nlattr.c | 68 ++++++++++++++++++++++++++++++++----------------------------
1 file changed, 36 insertions(+), 32 deletions(-)
diff --git a/lib/nlattr.c b/lib/nlattr.c
index e2e5b38394d5..6e03d650bec4 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -69,10 +69,11 @@ static int validate_nla_bitfield32(const struct nlattr *nla,
static int validate_nla(const struct nlattr *nla, int maxtype,
const struct nla_policy *policy,
- const char **error_msg)
+ struct netlink_ext_ack *extack)
{
const struct nla_policy *pt;
int minlen = 0, attrlen = nla_len(nla), type = nla_type(nla);
+ int err = -ERANGE;
if (type <= 0 || type > maxtype)
return 0;
@@ -90,24 +91,31 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
switch (pt->type) {
case NLA_EXACT_LEN:
if (attrlen != pt->len)
- return -ERANGE;
+ goto out_err;
break;
case NLA_REJECT:
- if (pt->validation_data && error_msg)
- *error_msg = pt->validation_data;
- return -EINVAL;
+ if (extack && pt->validation_data) {
+ NL_SET_BAD_ATTR(extack, nla);
+ extack->_msg = pt->validation_data;
+ return -EINVAL;
+ }
+ err = -EINVAL;
+ goto out_err;
case NLA_FLAG:
if (attrlen > 0)
- return -ERANGE;
+ goto out_err;
break;
case NLA_BITFIELD32:
if (attrlen != sizeof(struct nla_bitfield32))
- return -ERANGE;
+ goto out_err;
- return validate_nla_bitfield32(nla, pt->validation_data);
+ err = validate_nla_bitfield32(nla, pt->validation_data);
+ if (err)
+ goto out_err;
+ break;
case NLA_NUL_STRING:
if (pt->len)
@@ -115,13 +123,15 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
else
minlen = attrlen;
- if (!minlen || memchr(nla_data(nla), '\0', minlen) == NULL)
- return -EINVAL;
+ if (!minlen || memchr(nla_data(nla), '\0', minlen) == NULL) {
+ err = -EINVAL;
+ goto out_err;
+ }
/* fall through */
case NLA_STRING:
if (attrlen < 1)
- return -ERANGE;
+ goto out_err;
if (pt->len) {
char *buf = nla_data(nla);
@@ -130,13 +140,13 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
attrlen--;
if (attrlen > pt->len)
- return -ERANGE;
+ goto out_err;
}
break;
case NLA_BINARY:
if (pt->len && attrlen > pt->len)
- return -ERANGE;
+ goto out_err;
break;
case NLA_NESTED:
@@ -152,10 +162,13 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
minlen = nla_attr_minlen[pt->type];
if (attrlen < minlen)
- return -ERANGE;
+ goto out_err;
}
return 0;
+out_err:
+ NL_SET_ERR_MSG_ATTR(extack, nla, "Attribute failed policy validation");
+ return err;
}
/**
@@ -180,12 +193,10 @@ int nla_validate(const struct nlattr *head, int len, int maxtype,
int rem;
nla_for_each_attr(nla, head, len, rem) {
- int err = validate_nla(nla, maxtype, policy, NULL);
+ int err = validate_nla(nla, maxtype, policy, extack);
- if (err < 0) {
- NL_SET_BAD_ATTR(extack, nla);
+ if (err < 0)
return err;
- }
}
return 0;
@@ -241,7 +252,7 @@ int nla_parse(struct nlattr **tb, int maxtype, const struct nlattr *head,
struct netlink_ext_ack *extack)
{
const struct nlattr *nla;
- int rem, err;
+ int rem;
memset(tb, 0, sizeof(struct nlattr *) * (maxtype + 1));
@@ -249,17 +260,12 @@ int nla_parse(struct nlattr **tb, int maxtype, const struct nlattr *head,
u16 type = nla_type(nla);
if (type > 0 && type <= maxtype) {
- static const char _msg[] = "Attribute failed policy validation";
- const char *msg = _msg;
-
if (policy) {
- err = validate_nla(nla, maxtype, policy, &msg);
- if (err < 0) {
- NL_SET_BAD_ATTR(extack, nla);
- if (extack)
- extack->_msg = msg;
- goto errout;
- }
+ int err = validate_nla(nla, maxtype, policy,
+ extack);
+
+ if (err < 0)
+ return err;
}
tb[type] = (struct nlattr *)nla;
@@ -270,9 +276,7 @@ int nla_parse(struct nlattr **tb, int maxtype, const struct nlattr *head,
pr_warn_ratelimited("netlink: %d bytes leftover after parsing attributes in process `%s'.\n",
rem, current->comm);
- err = 0;
-errout:
- return err;
+ return 0;
}
EXPORT_SYMBOL(nla_parse);
--
2.14.4
^ permalink raw reply related
* [PATCH v3 2/5] netlink: make validation_data const
From: Johannes Berg @ 2018-09-26 9:15 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Johannes Berg
In-Reply-To: <20180926091534.22876-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
The validation data is only used within the policy that
should usually already be const, and isn't changed in any
code that uses it. Therefore, make the validation_data
pointer const.
While at it, remove the duplicate variable in the bitfield
validation that I'd otherwise have to change to const.
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/netlink.h | 2 +-
lib/nlattr.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index b680fe365e91..0d698215d4d9 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -237,7 +237,7 @@ enum {
struct nla_policy {
u16 type;
u16 len;
- void *validation_data;
+ const void *validation_data;
};
#define NLA_POLICY_EXACT_LEN(_len) { .type = NLA_EXACT_LEN, .len = _len }
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 120ad569e13d..e2e5b38394d5 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -45,12 +45,11 @@ static const u8 nla_attr_minlen[NLA_TYPE_MAX+1] = {
};
static int validate_nla_bitfield32(const struct nlattr *nla,
- u32 *valid_flags_allowed)
+ const u32 *valid_flags_mask)
{
const struct nla_bitfield32 *bf = nla_data(nla);
- u32 *valid_flags_mask = valid_flags_allowed;
- if (!valid_flags_allowed)
+ if (!valid_flags_mask)
return -EINVAL;
/*disallow invalid bit selector */
--
2.14.4
^ permalink raw reply related
* [PATCH v3 5/5] netlink: add nested array policy validation
From: Johannes Berg @ 2018-09-26 9:15 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Johannes Berg
In-Reply-To: <20180926091534.22876-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Sometimes nested netlink attributes are just used as arrays, with
the nla_type() of each not being used; we have this in nl80211 and
e.g. NFTA_SET_ELEM_LIST_ELEMENTS.
Add the ability to validate this type of message directly in the
policy, by adding the type NLA_NESTED_ARRAY which does exactly
this: require a first level of nesting but ignore the attribute
type, and then inside each require a second level of nested and
validate those attributes against a given policy (if present).
Note that some nested array types actually require that all of
the entries have the same index, this is possible to express in
a nested policy already, apart from the validation that only the
one allowed type is used.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/netlink.h | 12 +++++++++++-
lib/nlattr.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index 91907852da1c..3698ca8ff92c 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -172,6 +172,7 @@ enum {
NLA_FLAG,
NLA_MSECS,
NLA_NESTED,
+ NLA_NESTED_ARRAY,
NLA_NUL_STRING,
NLA_BINARY,
NLA_S8,
@@ -200,7 +201,8 @@ enum {
* NLA_NUL_STRING Maximum length of string (excluding NUL)
* NLA_FLAG Unused
* NLA_BINARY Maximum length of attribute payload
- * NLA_NESTED Length verification is done by checking len of
+ * NLA_NESTED,
+ * NLA_NESTED_ARRAY Length verification is done by checking len of
* nested header (or empty); len field is used if
* validation_data is also used, for the max attr
* number in the nested policy.
@@ -230,6 +232,12 @@ enum {
* `len' to the max attribute number.
* Note that nla_parse() will validate, but of course not
* parse, the nested sub-policies.
+ * NLA_NESTED_ARRAY Points to a nested policy to validate, must also set
+ * `len' to the max attribute number. The difference to
+ * NLA_NESTED is the structure - NLA_NESTED has the
+ * nested attributes directly inside, while an array has
+ * the nested attributes at another level down and the
+ * attributes directly in the nesting don't matter.
* All other Unused
*
* Example:
@@ -255,6 +263,8 @@ struct nla_policy {
#define NLA_POLICY_NESTED(maxattr, policy) \
{ .type = NLA_NESTED, .validation_data = policy, .len = maxattr }
+#define NLA_POLICY_NESTED_ARRAY(maxattr, policy) \
+ { .type = NLA_NESTED_ARRAY, .validation_data = policy, .len = maxattr }
/**
* struct nl_info - netlink source information
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 04750f88477c..2f8feff669a7 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -67,6 +67,34 @@ static int validate_nla_bitfield32(const struct nlattr *nla,
return 0;
}
+static int nla_validate_array(const struct nlattr *head, int len, int maxtype,
+ const struct nla_policy *policy,
+ struct netlink_ext_ack *extack)
+{
+ const struct nlattr *entry;
+ int rem;
+
+ nla_for_each_attr(entry, head, len, rem) {
+ int ret;
+
+ if (nla_len(entry) == 0)
+ continue;
+
+ if (nla_len(entry) < NLA_HDRLEN) {
+ NL_SET_ERR_MSG_ATTR(extack, entry,
+ "Array element too short");
+ return -ERANGE;
+ }
+
+ ret = nla_validate(nla_data(entry), nla_len(entry),
+ maxtype, policy, extack);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
static int validate_nla(const struct nlattr *nla, int maxtype,
const struct nla_policy *policy,
struct netlink_ext_ack *extack)
@@ -169,6 +197,29 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
}
}
break;
+ case NLA_NESTED_ARRAY:
+ /* a nested array attribute is allowed to be empty; if its not,
+ * it must have a size of at least NLA_HDRLEN.
+ */
+ if (attrlen == 0)
+ break;
+ if (attrlen < NLA_HDRLEN)
+ goto out_err;
+ if (pt->validation_data) {
+ int err;
+
+ err = nla_validate_array(nla_data(nla), nla_len(nla),
+ pt->len, pt->validation_data,
+ extack);
+ if (err < 0) {
+ /*
+ * return directly to preserve the inner
+ * error message/attribute pointer
+ */
+ return err;
+ }
+ }
+ break;
default:
if (pt->len)
minlen = pt->len;
--
2.14.4
^ permalink raw reply related
* [PATCH v3 4/5] netlink: allow NLA_NESTED to specify nested policy to validate
From: Johannes Berg @ 2018-09-26 9:15 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Johannes Berg
In-Reply-To: <20180926091534.22876-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Now that we have a validation_data pointer, and the len field in
the policy is unused for NLA_NESTED, we can allow using them both
to have nested validation. This can be nice in code, although we
still have to use nla_parse_nested() or similar which would also
take a policy; however, it also serves as documentation in the
policy without requiring a look at the code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/netlink.h | 13 +++++++++++--
lib/nlattr.c | 14 ++++++++++++++
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index 0d698215d4d9..91907852da1c 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -200,8 +200,10 @@ enum {
* NLA_NUL_STRING Maximum length of string (excluding NUL)
* NLA_FLAG Unused
* NLA_BINARY Maximum length of attribute payload
- * NLA_NESTED Don't use `len' field -- length verification is
- * done by checking len of nested header (or empty)
+ * NLA_NESTED Length verification is done by checking len of
+ * nested header (or empty); len field is used if
+ * validation_data is also used, for the max attr
+ * number in the nested policy.
* NLA_U8, NLA_U16,
* NLA_U32, NLA_U64,
* NLA_S8, NLA_S16,
@@ -224,6 +226,10 @@ enum {
* NLA_REJECT This attribute is always rejected and validation data
* may point to a string to report as the error instead
* of the generic one in extended ACK.
+ * NLA_NESTED Points to a nested policy to validate, must also set
+ * `len' to the max attribute number.
+ * Note that nla_parse() will validate, but of course not
+ * parse, the nested sub-policies.
* All other Unused
*
* Example:
@@ -247,6 +253,9 @@ struct nla_policy {
#define NLA_POLICY_ETH_ADDR NLA_POLICY_EXACT_LEN(ETH_ALEN)
#define NLA_POLICY_ETH_ADDR_COMPAT NLA_POLICY_EXACT_LEN_WARN(ETH_ALEN)
+#define NLA_POLICY_NESTED(maxattr, policy) \
+ { .type = NLA_NESTED, .validation_data = policy, .len = maxattr }
+
/**
* struct nl_info - netlink source information
* @nlh: Netlink message header of original request
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 6e03d650bec4..04750f88477c 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -155,6 +155,20 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
*/
if (attrlen == 0)
break;
+ if (attrlen < NLA_HDRLEN)
+ goto out_err;
+ if (pt->validation_data) {
+ err = nla_validate(nla_data(nla), nla_len(nla), pt->len,
+ pt->validation_data, extack);
+ if (err < 0) {
+ /*
+ * return directly to preserve the inner
+ * error message/attribute pointer
+ */
+ return err;
+ }
+ }
+ break;
default:
if (pt->len)
minlen = pt->len;
--
2.14.4
^ permalink raw reply related
* [PATCH net-next] net: xen-netback: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-26 9:18 UTC (permalink / raw)
To: davem, wei.liu2, paul.durrant; +Cc: linux-kernel, netdev, xen-devel, YueHaibing
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
---
drivers/net/xen-netback/interface.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 92274c2..7e3ea39 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -165,7 +165,8 @@ static u16 xenvif_select_queue(struct net_device *dev, struct sk_buff *skb,
return vif->hash.mapping[skb_get_hash_raw(skb) % size];
}
-static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct xenvif *vif = netdev_priv(dev);
struct xenvif_queue *queue = NULL;
--
1.8.3.1
^ permalink raw reply related
* Fw: [Bug 201233] New: e1000e
From: Stephen Hemminger @ 2018-09-26 9:26 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Tue, 25 Sep 2018 19:44:31 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 201233] New: e1000e
https://bugzilla.kernel.org/show_bug.cgi?id=201233
Bug ID: 201233
Summary: e1000e
Product: Networking
Version: 2.5
Kernel Version: 4.17.2
Hardware: Intel
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: pawel.ciejka@gmail.com
Regression: No
[39066.374367] ------------[ cut here ]------------
[39066.374372] NETDEV WATCHDOG: enp0s31f6 (e1000e): transmit queue 0 timed out
[39066.374399] WARNING: CPU: 5 PID: 0 at net/sched/sch_generic.c:473
dev_watchdog+0x21a/0x220
[39066.374401] Modules linked in: tun snd_hda_codec_hdmi cfg80211 rfkill 8021q
mrp xt_tcpudp xt_conntrack ip6table_filter ip6_tables iptable_filter
openvswitch nsh nf_conntrack_ipv6 nf_nat_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_defrag_ipv6 nf_nat nf_conntrack libcrc32c snd_hda_codec_realtek
snd_hda_codec_generic nls_iso8859_1 nls_cp437 vfat fat nouveau intel_rapl
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel input_leds kvm
i2c_algo_bit ttm drm_kms_helper irqbypass crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel pcbc drm aesni_intel snd_hda_intel aes_x86_64 crypto_simd
cryptd glue_helper snd_hda_codec iTCO_wdt iTCO_vendor_support intel_cstate
agpgart intel_uncore snd_hda_core syscopyarea sysfillrect sysimgblt fb_sys_fops
mxm_wmi intel_rapl_perf led_class e1000e snd_hwdep r8169
[39066.374498] snd_pcm pcspkr mii snd_timer mei_me snd hid_generic mei
i2c_i801 soundcore intel_pch_thermal shpchp wmi rtc_cmos evdev mac_hid
ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto sd_mod
usbhid hid ahci libahci xhci_pci xhci_hcd libata crc32c_intel usbcore scsi_mod
usb_common
[39066.374552] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.17.2-1-ARCH #1
[39066.374554] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./Z170 Pro4S, BIOS P7.50 01/23/2018
[39066.374559] RIP: 0010:dev_watchdog+0x21a/0x220
[39066.374562] RSP: 0018:ffff9585b6543e78 EFLAGS: 00010286
[39066.374567] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
0000000000000103
[39066.374569] RDX: 0000000080000103 RSI: ffffffff93e83166 RDI:
00000000ffffffff
[39066.374572] RBP: ffff9585a1a0845c R08: 0000000000000050 R09:
0000000000000388
[39066.374575] R10: 0000000000000000 R11: 0000000000000001 R12:
ffff9585a1a08478
[39066.374577] R13: ffff9585a1a08000 R14: 0000000000000001 R15:
ffff9585a1116680
[39066.374581] FS: 0000000000000000(0000) GS:ffff9585b6540000(0000)
knlGS:0000000000000000
[39066.374584] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[39066.374587] CR2: 00007f95007b9000 CR3: 000000033100a002 CR4:
00000000003626e0
[39066.374590] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[39066.374593] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[39066.374595] Call Trace:
[39066.374599] <IRQ>
[39066.374607] ? qdisc_reset+0xe0/0xe0
[39066.374611] ? qdisc_reset+0xe0/0xe0
[39066.374619] call_timer_fn+0x2b/0x150
[39066.374624] ? qdisc_reset+0xe0/0xe0
[39066.374630] expire_timers+0x99/0x110
[39066.374637] run_timer_softirq+0x8a/0x160
[39066.374646] ? sched_clock+0x5/0x10
[39066.374654] ? sched_clock_cpu+0xe/0xd0
[39066.374662] __do_softirq+0xf1/0x2e0
[39066.374669] irq_exit+0xc9/0xe0
[39066.374676] smp_apic_timer_interrupt+0x73/0x160
[39066.374682] apic_timer_interrupt+0xf/0x20
[39066.374685] </IRQ>
[39066.374692] RIP: 0010:cpuidle_enter_state+0xb7/0x2e0
[39066.374695] RSP: 0018:ffffb7f00196be98 EFLAGS: 00000246 ORIG_RAX:
ffffffffffffff13
[39066.374700] RAX: ffff9585b6540000 RBX: 00002387d95da598 RCX:
000000000000001f
[39066.374702] RDX: 00002387d95da598 RSI: ffffffff93e83166 RDI:
ffffffff93e833c4
[39066.374705] RBP: 0000000000000006 R08: 00009d769b1b300b R09:
0000000000000dfa
[39066.374707] R10: 00000000000050ed R11: ffff9585b6560928 R12:
ffff9585b656bb00
[39066.374710] R13: ffffffff940adc38 R14: 00002387d92f6191 R15:
0000000000000000
[39066.374720] ? cpuidle_enter_state+0x92/0x2e0
[39066.374725] do_idle+0x20a/0x240
[39066.374731] cpu_startup_entry+0x6f/0x80
[39066.374738] start_secondary+0x1aa/0x200
[39066.374745] secondary_startup_64+0xa5/0xb0
[39066.374750] Code: 00 49 63 4c 24 e8 eb 8c 4c 89 ef c6 05 97 54 ad 00 01 e8
da 18 fd ff 89 d9 4c 89 ee 48 c7 c7 40 5e ef 93 48 89 c2 e8 00 1b a5 ff <0f> 0b
eb be 66 90 0f 1f 44 00 00 48 c7 47 08 00 00 00 00 48 c7
[39066.374840] ---[ end trace 69426933339b594f ]---
[66649.036433] e1000e 0000:00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
TDH <cf>
TDT <ef>
next_to_use <ef>
next_to_clean <cf>
buffer_info[next_to_clean]:
time_stamp <1012faef5>
next_to_watch <d0>
jiffies <1012fb940>
next_to_watch.status <0>
MAC Status <40080083>
PHY Status <796d>
PHY 1000BASE-T Status <7800>
PHY Extended Status <3000>
PCI Status <10>
[66650.102864] e1000e 0000:00:1f.6 enp0s31f6: Reset adapter unexpectedly
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Jason A. Donenfeld @ 2018-09-26 15:41 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Herbert Xu, Thomas Gleixner, LKML, Netdev,
Linux Crypto Mailing List, David Miller, Greg Kroah-Hartman,
Samuel Neves, Andrew Lutomirski, Jean-Philippe Aumasson,
Russell King - ARM Linux, linux-arm-kernel
In-Reply-To: <CAKv+Gu8ih-TsASRGqK+ST_5+EQ0=Zo-zhGCadOdGyPjucMFTCg@mail.gmail.com>
On Wed, Sep 26, 2018 at 4:02 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> I don't think it makes sense to keep
> it simple now and add the complexity later (and the same concern
> applies to async support btw).
Ugh, no. I don't want to add needless complexity, period. Zinc is
synchronous, not asynchronous. It provides software implementations.
That's what it does. While many of your reviews have been useful, many
of your comments indicate some desire to change and mold the purpose
and focus of Zinc away from Zinc's intents. Stop that. It's not going
to become a bloated mess of "things Ard wanted and quipped about on
LKML." Things like these only serve to filibuster the patchset
indefinitely. But maybe that's what you'd like all along? Hard to
tell, honestly. So, no, sorry, Zinc isn't gaining an async interface
right now.
^ permalink raw reply
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Ard Biesheuvel @ 2018-09-26 15:41 UTC (permalink / raw)
To: Jason A. Donenfeld, Herbert Xu, Thomas Gleixner
Cc: Linux Kernel Mailing List, <netdev@vger.kernel.org>,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, David S. Miller,
Greg Kroah-Hartman, Samuel Neves, Andy Lutomirski,
Jean-Philippe Aumasson, Russell King, linux-arm-kernel
In-Reply-To: <CAKv+Gu8ih-TsASRGqK+ST_5+EQ0=Zo-zhGCadOdGyPjucMFTCg@mail.gmail.com>
On Wed, 26 Sep 2018 at 16:02, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> (+ Herbert, Thomas)
>
> On Wed, 26 Sep 2018 at 15:33, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > Hi Ard,
> >
> > On Wed, Sep 26, 2018 at 10:59 AM Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> > > > +static inline bool chacha20_arch(struct chacha20_ctx *state, u8 *dst,
> > > > + const u8 *src, size_t len,
> > > > + simd_context_t *simd_context)
> > > > +{
> > > > +#if defined(CONFIG_KERNEL_MODE_NEON)
> > > > + if (chacha20_use_neon && len >= CHACHA20_BLOCK_SIZE * 3 &&
> > > > + simd_use(simd_context))
> > > > + chacha20_neon(dst, src, len, state->key, state->counter);
> > > > + else
> > > > +#endif
> > >
> > > Better to use IS_ENABLED() here:
> > >
> > > > + if (IS_ENABLED(CONFIG_KERNEL_MODE_NEON)) &&
> > > > + chacha20_use_neon && len >= CHACHA20_BLOCK_SIZE * 3 &&
> > > > + simd_use(simd_context))
> >
> > Good idea. I'll fix that up.
> >
> > >
> > > Also, this still has unbounded worst case scheduling latency, given
> > > that the outer library function passes its entire input straight into
> > > the NEON routine.
> >
> > The vast majority of crypto routines in arch/*/crypto/ follow this
> > same exact pattern, actually. I realize a few don't -- probably the
> > ones you had a hand in :) -- but I think this is up to the caller to
> > handle.
>
> Anything that uses the scatterwalk API (AEADs and skciphers) will
> handle at most a page at a time. Hashes are different, which is why
> some of them have to handle it explicitly.
>
> > I made a change so that in chacha20poly1305.c, it calls
> > simd_relax after handling each scatter-gather element, so a
> > "construction" will handle this gracefully. But I believe it's up to
> > the caller to decide on what sizes of information it wants to pass to
> > primitives. Put differently, this also hasn't ever been an issue
> > before -- the existing state of the tree indicates this -- and so I
> > don't anticipate this will be a real issue now.
>
> The state of the tree does not capture all relevant context or
> history. The scheduling latency issue was brought up very recently by
> the -rt folks on the mailing lists.
>
> > And if it becomes one,
> > this is something we can address *later*, but certainly there's no use
> > of adding additional complexity to the initial patchset to do this
> > now.
> >
>
> You are introducing a very useful SIMD abstraction, but it lets code
> run with preemption disabled for unbounded amounts of time, and so now
> is the time to ensure we get it right.
>
Actually, looking at the code again, the abstraction does appear to be
fine, it is just the chacha20 code that does not make use of it.
^ permalink raw reply
* Re: [PATCH] mt76: fix building without CONFIG_MT76x0U
From: Arnd Bergmann @ 2018-09-26 15:43 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Kalle Valo, Felix Fietkau, Lorenzo Bianconi, David Miller,
linux-wireless, Networking, Linux Kernel Mailing List
In-Reply-To: <20180926140627.GA9265@redhat.com>
On Wed, Sep 26, 2018 at 4:06 PM Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>
> On Wed, Sep 26, 2018 at 02:51:59PM +0200, Arnd Bergmann wrote:
> > The recent rework of the mt76 driver caused build failures in
> > configurations that leave the mt76x0u support disabled:
> >
> > ERROR: "mt76u_mcu_deinit" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
> > ERROR: "mt76x02u_set_txinfo" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
> > ERROR: "mt76u_queues_deinit" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
> > ERROR: "mt76u_stop_stat_wk" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
> >
> > The mt76x0_push_txwi()/mt76x0_tx_prepare_skb()/mt76x0_cleanup() functions
> > that cause some of these are only called from the usb portion, and can
> > be hidden in an #ifdef in this case.
> >
> > mt76u_stop_stat_wk() is called mt76x0_mac_stop(), which is in turn
> > shared between multiple callers. Calling it only when the USB driver
> > is enabled avoids the link error but it is not clear to me whether this
> > can be called from a context where it would not do the right thing.
>
> I think there not yet posted Lorenzo patches that fix this build
> problem.
Ok, good. I assume that is a better fix than mine then. I also noticed
another problem that my patch does not address, but won't send a follow
up patch for that.
Please just ignore this version.
Arnd
^ permalink raw reply
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Jason A. Donenfeld @ 2018-09-26 15:45 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Herbert Xu, Thomas Gleixner, LKML, Netdev,
Linux Crypto Mailing List, David Miller, Greg Kroah-Hartman,
Samuel Neves, Andrew Lutomirski, Jean-Philippe Aumasson,
Russell King - ARM Linux, linux-arm-kernel
In-Reply-To: <CAKv+Gu8w74dUSEAGxxh=C6To6F=bSm8DjiExUPmh_LUyhoDLhg@mail.gmail.com>
On Wed, Sep 26, 2018 at 5:42 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> On Wed, 26 Sep 2018 at 16:02, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> Actually, looking at the code again, the abstraction does appear to be
> fine, it is just the chacha20 code that does not make use of it.
So what you have in mind is something like calling simd_relax() every
4096 bytes or so?
^ permalink raw reply
* RE: [PATCH resend] can: rcar_can: convert to SPDX identifiers
From: Ramesh Shanmugasundaram @ 2018-09-26 9:34 UTC (permalink / raw)
To: Kuninori Morimoto, Wolfgang Grandegger, Marc Kleine-Budde
Cc: Linux-Renesas, Linux-Net, linux-can@vger.kernel.org
In-Reply-To: <874ledyrc6.wl-kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
Thank you for the patch.
> Subject: [PATCH resend] can: rcar_can: convert to SPDX identifiers
>
>
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> This patch updates license to use SPDX-License-Identifier
> instead of verbose license text.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
Thanks,
Ramesh
> ---
> Wolfgang, Marc
>
> 2 weeks past, resend patch
>
> drivers/net/can/rcar/Kconfig | 1 +
> drivers/net/can/rcar/Makefile | 1 +
> drivers/net/can/rcar/rcar_can.c | 6 +-----
> drivers/net/can/rcar/rcar_canfd.c | 6 +-----
> 4 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/can/rcar/Kconfig b/drivers/net/can/rcar/Kconfig
> index 7b03a3a..bd5a8fc 100644
> --- a/drivers/net/can/rcar/Kconfig
> +++ b/drivers/net/can/rcar/Kconfig
> @@ -1,3 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> config CAN_RCAR
> tristate "Renesas R-Car CAN controller"
> depends on ARCH_RENESAS || ARM
> diff --git a/drivers/net/can/rcar/Makefile b/drivers/net/can/rcar/Makefile
> index 08de36a..c9185b0 100644
> --- a/drivers/net/can/rcar/Makefile
> +++ b/drivers/net/can/rcar/Makefile
> @@ -1,3 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> #
> # Makefile for the Renesas R-Car CAN & CAN FD controller drivers
> #
> diff --git a/drivers/net/can/rcar/rcar_can.c
> b/drivers/net/can/rcar/rcar_can.c
> index 11662f4..06f90a0 100644
> --- a/drivers/net/can/rcar/rcar_can.c
> +++ b/drivers/net/can/rcar/rcar_can.c
> @@ -1,12 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0+
> /* Renesas R-Car CAN device driver
> *
> * Copyright (C) 2013 Cogent Embedded, Inc. <source@cogentembedded.com>
> * Copyright (C) 2013 Renesas Solutions Corp.
> - *
> - * This program is free software; you can redistribute it and/or modify
> it
> - * under the terms of the GNU General Public License as published by
> the
> - * Free Software Foundation; either version 2 of the License, or (at
> your
> - * option) any later version.
> */
>
> #include <linux/module.h>
> diff --git a/drivers/net/can/rcar/rcar_canfd.c
> b/drivers/net/can/rcar/rcar_canfd.c
> index 602c19e..0541000 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c
> @@ -1,11 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0+
> /* Renesas R-Car CAN FD device driver
> *
> * Copyright (C) 2015 Renesas Electronics Corp.
> - *
> - * This program is free software; you can redistribute it and/or modify
> it
> - * under the terms of the GNU General Public License as published by
> the
> - * Free Software Foundation; either version 2 of the License, or (at
> your
> - * option) any later version.
> */
>
> /* The R-Car CAN FD controller can operate in either one of the below two
> modes
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH] mt76: fix building without CONFIG_MT76x0U
From: Lorenzo Bianconi @ 2018-09-26 15:48 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Arnd Bergmann, Kalle Valo, Felix Fietkau, David S. Miller,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180926140627.GA9265-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> On Wed, Sep 26, 2018 at 02:51:59PM +0200, Arnd Bergmann wrote:
> > The recent rework of the mt76 driver caused build failures in
> > configurations that leave the mt76x0u support disabled:
> >
> > ERROR: "mt76u_mcu_deinit" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
> > ERROR: "mt76x02u_set_txinfo" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
> > ERROR: "mt76u_queues_deinit" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
> > ERROR: "mt76u_stop_stat_wk" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
> >
>
> I think there not yet posted Lorenzo patches that fix this build
> problem.
Hi Arnd,
adding mt76x0e hw initialization I have already fixed
mt76u_mcu_deinit, mt76u_queues_deinit and mt76u_stop_stat_wk
(I have not posted the patchset yet, I will send it later today
or tomorrow). mt76x02u_set_txinfo needs to be fixed since
I have not worked on mt76x0e tx path yet, but it is on my
ToDo list.
Regards,
Lorenzo
>
> Regards
> Stanislaw
>
^ permalink raw reply
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Jason A. Donenfeld @ 2018-09-26 15:49 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Herbert Xu, Thomas Gleixner, LKML, Netdev,
Linux Crypto Mailing List, David Miller, Greg Kroah-Hartman,
Samuel Neves, Andrew Lutomirski, Jean-Philippe Aumasson,
Russell King - ARM Linux, linux-arm-kernel
In-Reply-To: <CAHmME9pbRabkGjNh-65S9qBNNS1GLJSwZ_tTM507S_Ezr1=QLg@mail.gmail.com>
On Wed, Sep 26, 2018 at 5:45 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> So what you have in mind is something like calling simd_relax() every
> 4096 bytes or so?
That was actually pretty easy, putting together both of your suggestions:
static inline bool chacha20_arch(struct chacha20_ctx *state, u8 *dst,
u8 *src, size_t len,
simd_context_t *simd_context)
{
while (len > PAGE_SIZE) {
chacha20_arch(state, dst, src, PAGE_SIZE, simd_context);
len -= PAGE_SIZE;
src += PAGE_SIZE;
dst += PAGE_SIZE;
simd_relax(simd_context);
}
if (IS_ENABLED(CONFIG_KERNEL_MODE_NEON) && chacha20_use_neon &&
len >= CHACHA20_BLOCK_SIZE * 3 && simd_use(simd_context))
chacha20_neon(dst, src, len, state->key, state->counter);
else
chacha20_arm(dst, src, len, state->key, state->counter);
state->counter[0] += (len + 63) / 64;
return true;
}
^ permalink raw reply
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Jason A. Donenfeld @ 2018-09-26 15:58 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Herbert Xu, Thomas Gleixner, LKML, Netdev,
Linux Crypto Mailing List, David Miller, Greg Kroah-Hartman,
Samuel Neves, Andrew Lutomirski, Jean-Philippe Aumasson,
Russell King - ARM Linux, linux-arm-kernel
In-Reply-To: <CAKv+Gu-WDt8f9qVjLDRPHL7THS0BjtKHThw2RMfHbWBT8Hs8aQ@mail.gmail.com>
On Wed, Sep 26, 2018 at 5:52 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> Nice one :-)
>
> This works for me (but perhaps add a comment as well)
Sure. Just a prototype; it'll be clean for v7.
^ permalink raw reply
* Re: netlink: 16 bytes leftover after parsing attributes in process `ip'.
From: Christian Brauner @ 2018-09-26 9:49 UTC (permalink / raw)
To: David Ahern; +Cc: Jiri Benc, netdev@vger.kernel.org, David Miller
In-Reply-To: <02fbfcb8-537c-dc5c-52dc-0f53d7fd0482@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4411 bytes --]
On Tue, Sep 25, 2018 at 09:37:41AM -0600, David Ahern wrote:
> On 9/25/18 8:47 AM, Jiri Benc wrote:
> > On Tue, 25 Sep 2018 11:49:10 +0200, Christian Brauner wrote:
> >> So if people really want to hide this issue as much as we can then we
> >> can play the guessing game. I could send a patch that roughly does the
> >> following:
> >>
> >> if (nlmsg_len(cb->nlh) < sizeof(struct ifinfomsg))
> >> guessed_header_len = sizeof(struct ifaddrmsg);
> >> else
> >> guessed_header_len = sizeof(struct ifinfomsg);
> >>
> >> This will work since sizeof(ifaddrmsg) == 8 and sizeof(ifinfomsg) == 16.
> >> The only valid property for RTM_GETADDR requests is IFA_TARGET_NETNSID.
> >> This propert is a __s32 which should bring the message up to 12 bytes
> >> (not sure about alignment requiremnts and where we might wend up ten)
> >> which is still less than the 16 bytes without that property from
> >> ifinfomsg. That's a hacky hacky hack-hack and will likely work but will
> >> break when ifaddrmsg grows a new member or we introduce another property
> >> that is valid in RTM_GETADDR requests. It also will not work cleanly
> >> when users stuff additional properties in there that are vaif (nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX,lid for the
> >> address family but are not used int RTM_GETADDR requests.
> >
> > I'd expect that any potential existing code that makes use of other
> > attributes already assumes ifaddrmsg. Hence, if the nlmsg_len is >
> > sizeof(ifinfomsg), you can be sure that there are attributes and thus
> > the struct used was ifaddrmsg.
> >
> > So, in order for RTM_GETADDR to work reliably with attributes, you have
> > to ensure that the length is > sizeof(ifinfomsg).
>
> One of the many on-going efforts I have in progress is kernel side
> filtering of route dumps. It has this same problem. For it I am
> proposing a new flag:
>
> #define RTM_F_PROPER_HEADER 0x4000
>
> ifinfomsg is 16 bytes which is > rtmsg at 12. If the message length is >
> 16, then rtm_flags can be checked to know if the proper header is sent.
>
> For ifaddrmsg things do not line up as well. Worst all of the flag bits
> are used. But, perhaps one can be overloaded with the limit that you can
> never filter on its presence. Since you are adding the first filter to
> address dumps such a limitation should be ok.
>
> For example something like this (whitespace damaged on paste) to remove
> the guess work:
>
> diff --git a/include/uapi/linux/if_addr.h b/include/uapi/linux/if_addr.h
> index dfcf3ce0097f..8e3e9d475db5 100644
> --- a/include/uapi/linux/if_addr.h
> +++ b/include/uapi/linux/if_addr.h
> @@ -41,6 +41,11 @@ enum {
> #define IFA_MAX (__IFA_MAX - 1)
>
> /* ifa_flags */
> +/* IFA_F_PROPER_HEADER is only set in ifa_flags for dumps
> + * to indicate the ancillary header is the expected ifaddrmsg
> + * vs ifinfomsg from legacy userspace
> + */
> +#define IFA_F_PROPER_HEADER 0x01
> #define IFA_F_SECONDARY 0x01
> #define IFA_F_TEMPORARY IFA_F_SECONDARY
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index bfe3ec7ecb14..256b9f88db8f 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -5022,8 +5022,13 @@ static int inet6_dump_addr(struct sk_buff *skb,
> struct netlink_callback *cb,
> s_idx = idx = cb->args[1];
> s_ip_idx = ip_idx = cb->args[2];
>
> - if (nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX,
> - ifa_ipv6_policy, NULL) >= 0) {
> + if (nlmsg_len(cb->nlh) >= sizeof(struct ifaddrmsg) &&
> + ((struct ifaddrmsg *) nlmsg_data(cb->nlh))->ifa_flags &
> IFA_F_PROPER_HEADER) {
> +
> + if (nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb,
> IFA_MAX,
> + ifa_ipv6_policy, NULL) >= 0) {
> + ...
> +
> if (tb[IFA_TARGET_NETNSID]) {
> netnsid = nla_get_s32(tb[IFA_TARGET_NETNSID]);
>
>
> For ifaddrmsg ifa_flags aligns with ifi_type which is set by kernel side
> so this should be ok.
I like this idea way more than forcing userspace to create a nested
attribute. If Jiri's question is answered can we get this patch on the
road soon?
Are you happy to send it on-top of net-next or do you want me to do it?
Christian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] net: nixge: fix warnings on 32-bit platforms
From: Moritz Fischer @ 2018-09-26 16:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: David S. Miller, Moritz Fischer, netdev, linux-kernel
In-Reply-To: <20180926124808.1867468-1-arnd@arndb.de>
Hi Arnd,
On Wed, Sep 26, 2018 at 02:47:24PM +0200, Arnd Bergmann wrote:
> Making it work on 64-bit caused 32-bit builds to regress:
>
> drivers/net/ethernet/ni/nixge.c: In function 'nixge_hw_dma_bd_release':
> drivers/net/ethernet/ni/nixge.c:254:9: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
> skb = (struct sk_buff *)
> ^
> In file included from include/linux/skbuff.h:17,
> from include/linux/if_ether.h:23,
> from include/linux/etherdevice.h:25,
> from drivers/net/ethernet/ni/nixge.c:7:
> drivers/net/ethernet/ni/nixge.c: In function 'nixge_hw_dma_bd_init':
> drivers/net/ethernet/ni/nixge.c:130:37: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
> (bd)->field##_lo = lower_32_bits(((u64)addr)); \
> ^
> include/linux/kernel.h:234:33: note: in definition of macro 'lower_32_bits'
> #define lower_32_bits(n) ((u32)(n))
> ^
>
> Casting to a uintptr_t avoids all these warnings.
>
> Fixes: 7e8d5755be0e ("net: nixge: Add support for 64-bit platforms")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/ethernet/ni/nixge.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/ni/nixge.c b/drivers/net/ethernet/ni/nixge.c
> index 74cf52e3fb09..2e132f6a7c36 100644
> --- a/drivers/net/ethernet/ni/nixge.c
> +++ b/drivers/net/ethernet/ni/nixge.c
> @@ -127,8 +127,8 @@ struct nixge_hw_dma_bd {
> #ifdef CONFIG_PHYS_ADDR_T_64BIT
> #define nixge_hw_dma_bd_set_addr(bd, field, addr) \
> do { \
> - (bd)->field##_lo = lower_32_bits(((u64)addr)); \
> - (bd)->field##_hi = upper_32_bits(((u64)addr)); \
> + (bd)->field##_lo = lower_32_bits(((uintptr_t)addr)); \
> + (bd)->field##_hi = upper_32_bits(((uintptr_t)addr)); \
> } while (0)
> #else
> #define nixge_hw_dma_bd_set_addr(bd, field, addr) \
> @@ -251,7 +251,7 @@ static void nixge_hw_dma_bd_release(struct net_device *ndev)
> NIXGE_MAX_JUMBO_FRAME_SIZE,
> DMA_FROM_DEVICE);
>
> - skb = (struct sk_buff *)
> + skb = (struct sk_buff *)(uintptr_t)
> nixge_hw_dma_bd_get_addr(&priv->rx_bd_v[i],
> sw_id_offset);
> dev_kfree_skb(skb);
> @@ -601,8 +601,8 @@ static int nixge_recv(struct net_device *ndev, int budget)
> tail_p = priv->rx_bd_p + sizeof(*priv->rx_bd_v) *
> priv->rx_bd_ci;
>
> - skb = (struct sk_buff *)nixge_hw_dma_bd_get_addr(cur_p,
> - sw_id_offset);
> + skb = (struct sk_buff *)(uintptr_t)
> + nixge_hw_dma_bd_get_addr(cur_p, sw_id_offset);
>
> length = cur_p->status & XAXIDMA_BD_STS_ACTUAL_LEN_MASK;
> if (length > NIXGE_MAX_JUMBO_FRAME_SIZE)
> --
> 2.18.0
>
I had submitted a similar patch https://lkml.org/lkml/2018/9/24/1719
here. I should probably add the Fixes tag yours has but other than that
they look largely equivalent. Comments?
Thanks,
Moritz
^ permalink raw reply
* Re: [PATCH net-next v6 23/23] net: WireGuard secure network tunnel
From: Jason A. Donenfeld @ 2018-09-26 16:04 UTC (permalink / raw)
To: labokml, Dave Taht
Cc: LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman
In-Reply-To: <7830522a-968e-0880-beb7-44904466cf14@labo.rs>
Hi Ivan,
On Wed, Sep 26, 2018 at 6:00 PM Ivan Labáth <labokml@labo.rs> wrote:
>
> On 25.09.2018 16:56, Jason A. Donenfeld wrote:
> > Extensive documentation and description of the protocol and
> > considerations, along with formal proofs of the cryptography, are> available at:
> >
> > * https://www.wireguard.com/
> > * https://www.wireguard.com/papers/wireguard.pdf
> []
> > +enum { HANDSHAKE_DSCP = 0x88 /* AF41, plus 00 ECN */ };
> []
> > + if (skb->protocol == htons(ETH_P_IP)) {
> > + len = ntohs(ip_hdr(skb)->tot_len);
> > + if (unlikely(len < sizeof(struct iphdr)))
> > + goto dishonest_packet_size;
> > + if (INET_ECN_is_ce(PACKET_CB(skb)->ds))
> > + IP_ECN_set_ce(ip_hdr(skb));
> > + } else if (skb->protocol == htons(ETH_P_IPV6)) {
> > + len = ntohs(ipv6_hdr(skb)->payload_len) +
> > + sizeof(struct ipv6hdr);
> > + if (INET_ECN_is_ce(PACKET_CB(skb)->ds))
> > + IP6_ECN_set_ce(skb, ipv6_hdr(skb));
> > + } else
> []
> > + skb_queue_walk (&packets, skb) {
> > + /* 0 for no outer TOS: no leak. TODO: should we use flowi->tos
> > + * as outer? */
> > + PACKET_CB(skb)->ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb);
> > + PACKET_CB(skb)->nonce =
> > + atomic64_inc_return(&key->counter.counter) - 1;
> > + if (unlikely(PACKET_CB(skb)->nonce >= REJECT_AFTER_MESSAGES))
> > + goto out_invalid;
> > + }
> Hi,
>
> is there documentation and/or rationale for ecn handling?
> Quick search for ecn and dscp didn't reveal any.
ECN support was developed with Dave Taht so that it does the right
thing with CAKE and such. He's CC'd, so that he can fill in details,
and sure, we can write these up. As well, I can add the rationale for
the handshake-packet-specific DSCP value to the paper in the next few
days; thanks for pointing out these documentation oversights.
Jason
^ permalink raw reply
* Re: [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in per-port round-robin order
From: Stefano Brivio @ 2018-09-26 9:58 UTC (permalink / raw)
To: Pravin Shelar
Cc: Matteo Croce, Justin Pettit, Greg Rose, Ben Pfaff, netdev,
ovs dev, Jiri Benc, Aaron Conole, William Tu
In-Reply-To: <CAOrHB_DaA-+J=jzNOdQiUYrA7RJi30HmRESjsmGs7_z1ffpVOA@mail.gmail.com>
Hi Pravin,
On Wed, 15 Aug 2018 00:19:39 -0700
Pravin Shelar <pshelar@ovn.org> wrote:
> I understand fairness has cost, but we need to find right balance
> between performance and fairness. Current fairness scheme is a
> lockless algorithm without much computational overhead, did you try to
> improve current algorithm so that it uses less number of ports.
In the end, we tried harder as you suggested, and found out a way to
avoid the need for per-thread sets of per-vport sockets: with a few
changes, a process-wide set of per-vport sockets is actually enough to
maintain the current fairness behaviour.
Further, we can get rid of duplicate fd events if the EPOLLEXCLUSIVE
epoll() flag is available, which improves performance noticeably. This
is explained in more detail in the commit message of the ovs-vswitchd
patch Matteo wrote [1], now merged.
This approach solves the biggest issue (i.e. huge amount of netlink
sockets) in ovs-vswitchd itself, without the need for kernel changes.
It doesn't address some proposed improvements though, that is, it does
nothing to improve the current fairness scheme, it won't allow neither
the configurable fairness criteria proposed by Ben, nor usage of BPF
maps for extensibility as suggested by William.
I would however say that those topics bear definitely lower priority,
and perhaps addressing them at all becomes overkill now that we don't
any longer have a serious issue.
[1] https://patchwork.ozlabs.org/patch/974304/
--
Stefano
^ permalink raw reply
* Re: [PATCH v3 bpf-next 03/10] bpf: introduce per-cpu cgroup local storage
From: Song Liu @ 2018-09-26 16:13 UTC (permalink / raw)
To: Roman Gushchin
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Kernel Team,
Daniel Borkmann, Alexei Starovoitov
In-Reply-To: <20180926113326.29069-4-guro@fb.com>
> On Sep 26, 2018, at 4:33 AM, Roman Gushchin <guro@fb.com> wrote:
>
> This commit introduced per-cpu cgroup local storage.
>
> Per-cpu cgroup local storage is very similar to simple cgroup storage
> (let's call it shared), except all the data is per-cpu.
>
> The main goal of per-cpu variant is to implement super fast
> counters (e.g. packet counters), which don't require neither
> lookups, neither atomic operations.
>
> From userspace's point of view, accessing a per-cpu cgroup storage
> is similar to other per-cpu map types (e.g. per-cpu hashmaps and
> arrays).
>
> Writing to a per-cpu cgroup storage is not atomic, but is performed
> by copying longs, so some minimal atomicity is here, exactly
> as with other per-cpu maps.
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Alexei Starovoitov <ast@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> include/linux/bpf-cgroup.h | 20 ++++-
> include/linux/bpf.h | 1 +
> include/linux/bpf_types.h | 1 +
> include/uapi/linux/bpf.h | 1 +
> kernel/bpf/helpers.c | 8 +-
> kernel/bpf/local_storage.c | 148 ++++++++++++++++++++++++++++++++-----
> kernel/bpf/syscall.c | 11 ++-
> kernel/bpf/verifier.c | 15 +++-
> 8 files changed, 177 insertions(+), 28 deletions(-)
>
> diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
> index 7e0c9a1d48b7..588dd5f0bd85 100644
> --- a/include/linux/bpf-cgroup.h
> +++ b/include/linux/bpf-cgroup.h
> @@ -37,7 +37,10 @@ struct bpf_storage_buffer {
> };
>
> struct bpf_cgroup_storage {
> - struct bpf_storage_buffer *buf;
> + union {
> + struct bpf_storage_buffer *buf;
> + void __percpu *percpu_buf;
> + };
> struct bpf_cgroup_storage_map *map;
> struct bpf_cgroup_storage_key key;
> struct list_head list;
> @@ -109,6 +112,9 @@ int __cgroup_bpf_check_dev_permission(short dev_type, u32 major, u32 minor,
> static inline enum bpf_cgroup_storage_type cgroup_storage_type(
> struct bpf_map *map)
> {
> + if (map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE)
> + return BPF_CGROUP_STORAGE_PERCPU;
> +
> return BPF_CGROUP_STORAGE_SHARED;
> }
>
> @@ -131,6 +137,10 @@ void bpf_cgroup_storage_unlink(struct bpf_cgroup_storage *storage);
> int bpf_cgroup_storage_assign(struct bpf_prog *prog, struct bpf_map *map);
> void bpf_cgroup_storage_release(struct bpf_prog *prog, struct bpf_map *map);
>
> +int bpf_percpu_cgroup_storage_copy(struct bpf_map *map, void *key, void *value);
> +int bpf_percpu_cgroup_storage_update(struct bpf_map *map, void *key,
> + void *value, u64 flags);
> +
> /* Wrappers for __cgroup_bpf_run_filter_skb() guarded by cgroup_bpf_enabled. */
> #define BPF_CGROUP_RUN_PROG_INET_INGRESS(sk, skb) \
> ({ \
> @@ -285,6 +295,14 @@ static inline struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(
> struct bpf_prog *prog, enum bpf_cgroup_storage_type stype) { return 0; }
> static inline void bpf_cgroup_storage_free(
> struct bpf_cgroup_storage *storage) {}
> +static inline int bpf_percpu_cgroup_storage_copy(struct bpf_map *map, void *key,
> + void *value) {
> + return 0;
> +}
> +static inline int bpf_percpu_cgroup_storage_update(struct bpf_map *map,
> + void *key, void *value, u64 flags) {
> + return 0;
> +}
>
> #define cgroup_bpf_enabled (0)
> #define BPF_CGROUP_PRE_CONNECT_ENABLED(sk) (0)
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index b457fbe7b70b..018299a595c8 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -274,6 +274,7 @@ struct bpf_prog_offload {
>
> enum bpf_cgroup_storage_type {
> BPF_CGROUP_STORAGE_SHARED,
> + BPF_CGROUP_STORAGE_PERCPU,
> __BPF_CGROUP_STORAGE_MAX
> };
>
> diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
> index c9bd6fb765b0..5432f4c9f50e 100644
> --- a/include/linux/bpf_types.h
> +++ b/include/linux/bpf_types.h
> @@ -43,6 +43,7 @@ BPF_MAP_TYPE(BPF_MAP_TYPE_CGROUP_ARRAY, cgroup_array_map_ops)
> #endif
> #ifdef CONFIG_CGROUP_BPF
> BPF_MAP_TYPE(BPF_MAP_TYPE_CGROUP_STORAGE, cgroup_storage_map_ops)
> +BPF_MAP_TYPE(BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE, cgroup_storage_map_ops)
> #endif
> BPF_MAP_TYPE(BPF_MAP_TYPE_HASH, htab_map_ops)
> BPF_MAP_TYPE(BPF_MAP_TYPE_PERCPU_HASH, htab_percpu_map_ops)
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index aa5ccd2385ed..e2070d819e04 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -127,6 +127,7 @@ enum bpf_map_type {
> BPF_MAP_TYPE_SOCKHASH,
> BPF_MAP_TYPE_CGROUP_STORAGE,
> BPF_MAP_TYPE_REUSEPORT_SOCKARRAY,
> + BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE,
> };
>
> enum bpf_prog_type {
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index e42f8789b7ea..6502115e8f55 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -206,10 +206,16 @@ BPF_CALL_2(bpf_get_local_storage, struct bpf_map *, map, u64, flags)
> */
> enum bpf_cgroup_storage_type stype = cgroup_storage_type(map);
> struct bpf_cgroup_storage *storage;
> + void *ptr;
>
> storage = this_cpu_read(bpf_cgroup_storage[stype]);
>
> - return (unsigned long)&READ_ONCE(storage->buf)->data[0];
> + if (stype == BPF_CGROUP_STORAGE_SHARED)
> + ptr = &READ_ONCE(storage->buf)->data[0];
> + else
> + ptr = this_cpu_ptr(storage->percpu_buf);
> +
> + return (unsigned long)ptr;
> }
>
> const struct bpf_func_proto bpf_get_local_storage_proto = {
> diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
> index 6742292fb39e..c739f6dcc3c2 100644
> --- a/kernel/bpf/local_storage.c
> +++ b/kernel/bpf/local_storage.c
> @@ -152,6 +152,71 @@ static int cgroup_storage_update_elem(struct bpf_map *map, void *_key,
> return 0;
> }
>
> +int bpf_percpu_cgroup_storage_copy(struct bpf_map *_map, void *_key,
> + void *value)
> +{
> + struct bpf_cgroup_storage_map *map = map_to_storage(_map);
> + struct bpf_cgroup_storage_key *key = _key;
> + struct bpf_cgroup_storage *storage;
> + int cpu, off = 0;
> + u32 size;
> +
> + rcu_read_lock();
> + storage = cgroup_storage_lookup(map, key, false);
> + if (!storage) {
> + rcu_read_unlock();
> + return -ENOENT;
> + }
> +
> + /* per_cpu areas are zero-filled and bpf programs can only
> + * access 'value_size' of them, so copying rounded areas
> + * will not leak any kernel data
> + */
> + size = round_up(_map->value_size, 8);
> + for_each_possible_cpu(cpu) {
> + bpf_long_memcpy(value + off,
> + per_cpu_ptr(storage->percpu_buf, cpu), size);
> + off += size;
> + }
> + rcu_read_unlock();
> + return 0;
> +}
> +
> +int bpf_percpu_cgroup_storage_update(struct bpf_map *_map, void *_key,
> + void *value, u64 map_flags)
> +{
> + struct bpf_cgroup_storage_map *map = map_to_storage(_map);
> + struct bpf_cgroup_storage_key *key = _key;
> + struct bpf_cgroup_storage *storage;
> + int cpu, off = 0;
> + u32 size;
> +
> + if (unlikely(map_flags & BPF_EXIST))
> + return -EINVAL;
> +
> + rcu_read_lock();
> + storage = cgroup_storage_lookup(map, key, false);
> + if (!storage) {
> + rcu_read_unlock();
> + return -ENOENT;
> + }
> +
> + /* the user space will provide round_up(value_size, 8) bytes that
> + * will be copied into per-cpu area. bpf programs can only access
> + * value_size of it. During lookup the same extra bytes will be
> + * returned or zeros which were zero-filled by percpu_alloc,
> + * so no kernel data leaks possible
> + */
> + size = round_up(_map->value_size, 8);
> + for_each_possible_cpu(cpu) {
> + bpf_long_memcpy(per_cpu_ptr(storage->percpu_buf, cpu),
> + value + off, size);
> + off += size;
> + }
> + rcu_read_unlock();
> + return 0;
> +}
> +
> static int cgroup_storage_get_next_key(struct bpf_map *_map, void *_key,
> void *_next_key)
> {
> @@ -292,55 +357,98 @@ struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(struct bpf_prog *prog,
> {
> struct bpf_cgroup_storage *storage;
> struct bpf_map *map;
> + gfp_t flags;
> + size_t size;
> u32 pages;
>
> map = prog->aux->cgroup_storage[stype];
> if (!map)
> return NULL;
>
> - pages = round_up(sizeof(struct bpf_cgroup_storage) +
> - sizeof(struct bpf_storage_buffer) +
> - map->value_size, PAGE_SIZE) >> PAGE_SHIFT;
> + if (stype == BPF_CGROUP_STORAGE_SHARED) {
> + size = sizeof(struct bpf_storage_buffer) + map->value_size;
> + pages = round_up(sizeof(struct bpf_cgroup_storage) + size,
> + PAGE_SIZE) >> PAGE_SHIFT;
> + } else {
> + size = map->value_size;
> + pages = round_up(round_up(size, 8) * num_possible_cpus(),
> + PAGE_SIZE) >> PAGE_SHIFT;
> + }
> +
> if (bpf_map_charge_memlock(map, pages))
> return ERR_PTR(-EPERM);
>
> storage = kmalloc_node(sizeof(struct bpf_cgroup_storage),
> __GFP_ZERO | GFP_USER, map->numa_node);
> - if (!storage) {
> - bpf_map_uncharge_memlock(map, pages);
> - return ERR_PTR(-ENOMEM);
> - }
> + if (!storage)
> + goto enomem;
>
> - storage->buf = kmalloc_node(sizeof(struct bpf_storage_buffer) +
> - map->value_size, __GFP_ZERO | GFP_USER,
> - map->numa_node);
> - if (!storage->buf) {
> - bpf_map_uncharge_memlock(map, pages);
> - kfree(storage);
> - return ERR_PTR(-ENOMEM);
> + flags = __GFP_ZERO | GFP_USER;
> +
> + if (stype == BPF_CGROUP_STORAGE_SHARED) {
> + storage->buf = kmalloc_node(size, flags, map->numa_node);
> + if (!storage->buf)
> + goto enomem;
> + } else {
> + storage->percpu_buf = __alloc_percpu_gfp(size, 8, flags);
> + if (!storage->percpu_buf)
> + goto enomem;
> }
>
> storage->map = (struct bpf_cgroup_storage_map *)map;
>
> return storage;
> +
> +enomem:
> + bpf_map_uncharge_memlock(map, pages);
> + kfree(storage);
> + return ERR_PTR(-ENOMEM);
> +}
> +
> +static void free_shared_cgroup_storage_rcu(struct rcu_head *rcu)
> +{
> + struct bpf_cgroup_storage *storage =
> + container_of(rcu, struct bpf_cgroup_storage, rcu);
> +
> + kfree(storage->buf);
> + kfree(storage);
> +}
> +
> +static void free_percpu_cgroup_storage_rcu(struct rcu_head *rcu)
> +{
> + struct bpf_cgroup_storage *storage =
> + container_of(rcu, struct bpf_cgroup_storage, rcu);
> +
> + free_percpu(storage->percpu_buf);
> + kfree(storage);
> }
>
> void bpf_cgroup_storage_free(struct bpf_cgroup_storage *storage)
> {
> - u32 pages;
> + enum bpf_cgroup_storage_type stype;
> struct bpf_map *map;
> + u32 pages;
>
> if (!storage)
> return;
>
> map = &storage->map->map;
> - pages = round_up(sizeof(struct bpf_cgroup_storage) +
> - sizeof(struct bpf_storage_buffer) +
> - map->value_size, PAGE_SIZE) >> PAGE_SHIFT;
> + stype = cgroup_storage_type(map);
> + if (stype == BPF_CGROUP_STORAGE_SHARED)
> + pages = round_up(sizeof(struct bpf_cgroup_storage) +
> + sizeof(struct bpf_storage_buffer) +
> + map->value_size, PAGE_SIZE) >> PAGE_SHIFT;
> + else
> + pages = round_up(round_up(map->value_size, 8) *
> + num_possible_cpus(),
> + PAGE_SIZE) >> PAGE_SHIFT;
> +
> bpf_map_uncharge_memlock(map, pages);
>
> - kfree_rcu(storage->buf, rcu);
> - kfree_rcu(storage, rcu);
> + if (stype == BPF_CGROUP_STORAGE_SHARED)
> + call_rcu(&storage->rcu, free_shared_cgroup_storage_rcu);
> + else
> + call_rcu(&storage->rcu, free_percpu_cgroup_storage_rcu);
> }
>
> void bpf_cgroup_storage_link(struct bpf_cgroup_storage *storage,
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 8c91d2b41b1e..5742df21598c 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -686,7 +686,8 @@ static int map_lookup_elem(union bpf_attr *attr)
>
> if (map->map_type == BPF_MAP_TYPE_PERCPU_HASH ||
> map->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH ||
> - map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY)
> + map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY ||
> + map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE)
> value_size = round_up(map->value_size, 8) * num_possible_cpus();
> else if (IS_FD_MAP(map))
> value_size = sizeof(u32);
> @@ -705,6 +706,8 @@ static int map_lookup_elem(union bpf_attr *attr)
> err = bpf_percpu_hash_copy(map, key, value);
> } else if (map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY) {
> err = bpf_percpu_array_copy(map, key, value);
> + } else if (map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE) {
> + err = bpf_percpu_cgroup_storage_copy(map, key, value);
> } else if (map->map_type == BPF_MAP_TYPE_STACK_TRACE) {
> err = bpf_stackmap_copy(map, key, value);
> } else if (IS_FD_ARRAY(map)) {
> @@ -774,7 +777,8 @@ static int map_update_elem(union bpf_attr *attr)
>
> if (map->map_type == BPF_MAP_TYPE_PERCPU_HASH ||
> map->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH ||
> - map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY)
> + map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY ||
> + map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE)
> value_size = round_up(map->value_size, 8) * num_possible_cpus();
> else
> value_size = map->value_size;
> @@ -809,6 +813,9 @@ static int map_update_elem(union bpf_attr *attr)
> err = bpf_percpu_hash_update(map, key, value, attr->flags);
> } else if (map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY) {
> err = bpf_percpu_array_update(map, key, value, attr->flags);
> + } else if (map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE) {
> + err = bpf_percpu_cgroup_storage_update(map, key, value,
> + attr->flags);
> } else if (IS_FD_ARRAY(map)) {
> rcu_read_lock();
> err = bpf_fd_array_map_update_elem(map, f.file, key, value,
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index e90899df585d..a8cc83a970d1 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -2074,6 +2074,7 @@ static int check_map_func_compatibility(struct bpf_verifier_env *env,
> goto error;
> break;
> case BPF_MAP_TYPE_CGROUP_STORAGE:
> + case BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE:
> if (func_id != BPF_FUNC_get_local_storage)
> goto error;
> break;
> @@ -2164,7 +2165,8 @@ static int check_map_func_compatibility(struct bpf_verifier_env *env,
> goto error;
> break;
> case BPF_FUNC_get_local_storage:
> - if (map->map_type != BPF_MAP_TYPE_CGROUP_STORAGE)
> + if (map->map_type != BPF_MAP_TYPE_CGROUP_STORAGE &&
> + map->map_type != BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE)
> goto error;
> break;
> case BPF_FUNC_sk_select_reuseport:
> @@ -5049,6 +5051,12 @@ static int check_map_prog_compatibility(struct bpf_verifier_env *env,
> return 0;
> }
>
> +static bool bpf_map_is_cgroup_storage(struct bpf_map *map)
> +{
> + return (map->map_type == BPF_MAP_TYPE_CGROUP_STORAGE ||
> + map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE);
> +}
> +
> /* look for pseudo eBPF instructions that access map FDs and
> * replace them with actual map pointers
> */
> @@ -5139,10 +5147,9 @@ static int replace_map_fd_with_map_ptr(struct bpf_verifier_env *env)
> }
> env->used_maps[env->used_map_cnt++] = map;
>
> - if (map->map_type == BPF_MAP_TYPE_CGROUP_STORAGE &&
> + if (bpf_map_is_cgroup_storage(map) &&
> bpf_cgroup_storage_assign(env->prog, map)) {
> - verbose(env,
> - "only one cgroup storage is allowed\n");
> + verbose(env, "only one cgroup storage of each type is allowed\n");
> fdput(f);
> return -EBUSY;
> }
> --
> 2.17.1
>
^ 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