* [PATCH net 0/5] net/smc: fixes 2018-09-18
From: Ursula Braun @ 2018-09-18 13:46 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel
Dave,
here are some fixes in different areas of the smc code for the net
tree.
Thanks, Ursula
Karsten Graul (1):
net/smc: no urgent data check for listen sockets
Ursula Braun (3):
net/smc: fix non-blocking connect problem
net/smc: remove duplicate mutex_unlock
net/smc: enable fallback for connection abort in state INIT
YueHaibing (1):
net/smc: fix sizeof to int comparison
net/smc/af_smc.c | 26 ++++++++++++++++----------
net/smc/smc_clc.c | 14 ++++++--------
net/smc/smc_close.c | 14 +++++++-------
3 files changed, 29 insertions(+), 25 deletions(-)
--
2.16.4
^ permalink raw reply
* Re: pegged softirq and NAPI race (?)
From: Eric Dumazet @ 2018-09-18 13:45 UTC (permalink / raw)
To: songliubraving
Cc: netdev, Jeff Kirsher, Alexander Duyck, michael.chan, kernel-team
In-Reply-To: <A782704A-DF97-4E85-B10A-D2268A67DFD7@fb.com>
On Tue, Sep 18, 2018 at 1:41 AM Song Liu <songliubraving@fb.com> wrote:
>
> We are debugging this issue that netconsole message triggers pegged softirq
> (ksoftirqd taking 100% CPU for many seconds). We found this issue in
> production with both bnxt and ixgbe, on a 4.11 based kernel. This is easily
> reproducible with ixgbe on 4.11, and latest net/net-next (see [1] for more
> detail).
>
> After debugging for some time, we found that this issue is likely related
> to 39e6c8208d7b ("net: solve a NAPI race"). After reverting this commit,
> the steps described in [1] cannot reproduce the issue on ixgbe. Reverting
> this commit also reduces the chances we hit the issue with bnxt (it still
> happens with a lower rate).
>
> I tried to fix this issue with relaxed variant (or older version) of
> napi_schedule_prep() in netpoll, just like the one on napi_watchdog().
> However, my tests do not always go as expected.
>
> Please share your comments/suggestions on which direction shall we try
> to fix this.
>
> Thanks in advance!
> Song
>
>
> [1] https://www.spinics.net/lists/netdev/msg522328.html
You have not traced ixgbe to understand why driver hits
"clean_complete=false" all the time ?
^ permalink raw reply
* Re: [PATCH]ipv6: multicast: In mld_send_cr function moving read lock to second for loop
From: Guruswamy Basavaiah @ 2018-09-18 13:21 UTC (permalink / raw)
To: davem; +Cc: netdev, Alexey Kuznetsov, Hideaki YOSHIFUJI
In-Reply-To: <20180818.135819.1279366350823380240.davem@davemloft.net>
> This will lead to deadlocks, idev->mc_lock must be taken with _bh().
Modified the existing spin_lock to spin_lock_bh
> I have zero confidence in this change, did you do any stress testing
> with lockdep enabled? It would have caught this quickly.
With LOCKDEP enabled ran LTP multicast stress with the below new patch.
Test case is successful and LOCKDEP did not catch any dead lock issues.
---
>From 789840a6c6f783311ea7dfd832787c27d5b8359f Mon Sep 17 00:00:00 2001
From: Guruswamy Basavaiah <guru2018@gmail.com>
Date: Tue, 18 Sep 2018 18:40:21 +0530
Subject: [PATCH] ipv6: multicast: In mld_send_cr function moving read lock to
second for loop
In function mld_send_cr, the first loop is already protected by
idev->mc_lock, it dont need idev->lock read lock, hence moving it
only to second for loop. And converting the existing spin_lock to
spin_lock_bh
Signed-off-by: Guruswamy Basavaiah <guru2018@gmail.com>
---
net/ipv6/mcast.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 4ae54aaca373..751e580eb0ed 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1912,8 +1912,7 @@ static void mld_send_cr(struct inet6_dev *idev)
struct sk_buff *skb = NULL;
int type, dtype;
- read_lock_bh(&idev->lock);
- spin_lock(&idev->mc_lock);
+ spin_lock_bh(&idev->mc_lock);
/* deleted MCA's */
pmc_prev = NULL;
@@ -1947,8 +1946,9 @@ static void mld_send_cr(struct inet6_dev *idev)
} else
pmc_prev = pmc;
}
- spin_unlock(&idev->mc_lock);
+ spin_unlock_bh(&idev->mc_lock);
+ read_lock_bh(&idev->lock);
/* change recs */
for (pmc = idev->mc_list; pmc; pmc = pmc->next) {
spin_lock_bh(&pmc->mca_lock);
--
2.14.4
On Sun, 19 Aug 2018 at 02:28, David Miller <davem@davemloft.net> wrote:
>
> From: Guruswamy Basavaiah <guru2018@gmail.com>
> Date: Fri, 17 Aug 2018 18:01:41 +0530
>
> > @@ -1860,7 +1860,6 @@ static void mld_send_cr(struct inet6_dev *idev)
> > struct sk_buff *skb = NULL;
> > int type, dtype;
> >
> > - read_lock_bh(&idev->lock);
> > spin_lock(&idev->mc_lock);
> >
> > /* deleted MCA's */
>
> This will lead to deadlocks, idev->mc_lock must be taken with _bh().
>
> I have zero confidence in this change, did you do any stress testing
> with lockdep enabled? It would have caught this quickly.
--
Guruswamy Basavaiah
^ permalink raw reply related
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Ard Biesheuvel @ 2018-09-18 18:53 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Andrew Lutomirski, David Miller, Andrew Lunn, Eric Biggers,
Greg Kroah-Hartman, LKML, Netdev, Samuel Neves,
Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <CAHmME9qwRzuoo-3Hxahwu=Li2LCz06Uowaq1GFmkts6tsffM7w@mail.gmail.com>
On 17 September 2018 at 08:52, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Hi Ard,
>
> On Mon, Sep 17, 2018 at 7:26 AM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> OK, so let me summarize my remaining concerns as well. I may be a bit
>> more finicky than Andy, though.
>
> Yes, and generally hostile to this whole initiative since the
> beginning. But I am very grateful for your reviews nonetheless, and
> I'll do my best to incorporate as much as is reasonable.
>
>> I would like to urge Jason to
>> bear with us and bring this discussion to a close before resubmitting.
>
> What I fear is that either:
> - You don't like the Zinc initiative in one way or another, and the
> desire to "keep discussing" and adding more things is less out of
> their necessity and more out of a desire to stall it indefinitely.
> - You're going to bikeshed and bikeshed and waste tons of time until
> Zinc copies lots of the same design decisions from the present crypto
> API.
>
Given that you show no interest whatsoever in gaining an understanding
of the underlying requirements that we have to deal with in the crypto
API, the only way to get my point across is by repeatedly stating it
in response to your patches. Also, sending out a new series each time
with only half of the review comments addressed doesn't make me a
bikeshedder.
> I do sincerely hope these are only fears and not what actually is
> going on. I'll do my best to take into serious consideration what you
> say -- many are indeed extremely helpful -- but I certainly won't be
> wholesale accepting all the things you've mentioned.
>
I have pointed out to you numerous times (as has Eric) that the
ChaCha20 ARM code you are importing from the OpenSSL project has been
found to be slower on Cortex-A7, which represents the vast majority of
devices expected to be in the field in 1~2 years. Yet, we are at the
fifth revision now where you are replacing the existing code. Also, I
have asked you more than once to split out your changes to the
upstream OpenSSL code into separate patches so we can more easily
track them, but v5 now puts them in the commit log (again) [but in a
corrupted way - the preprocessor directives are filtered out by
git-commit], which means we cannot use git diff/blame etc to look at
them.
Upstreaming code is about taking an interest in other people's use
cases, and about choosing your battles. It is unfortunate that we have
spent all this time talking about a couple of crypto routines, while
the actual meat of your submission is in WireGuard itself, which I'm
sure you much rather talk about.
>> * simd_relax() is currently not called by the crypto routines
>> themselves. This means that the worst case scheduling latency is
>> unbounded, which is unacceptable for the -rt kernel. The worst case
>> scheduling latency should never be proportional to the input size.
>> (Apologies for not spotting that earlier)
>
> Good catch. I actually did this correct when porting the crypto API to
> use Zinc (in those later top commits in v4), but I hadn't in the Zinc
> code itself. I'll address this for v5.
>
>> maintainership
>> responsibilities
>
> Samuel and I intend to maintain Zinc in lib/zinc/ and send future
> updates to it through Greg's tree, as mentioned in the 00/ cover
> letter. The maintainership of the existing crypto API won't change.
>
>> * The current organization of the code puts all available (for the
>> arch) versions of all routines into a single module, which can only be
>> built in once we update random.c to use Zinc's chacha20 routines. This
>> bloats the core kernel (which is a huge deal for embedded systems that
>> have very strict boot requirements).
>
> I'll split each Zinc primitive into a separate module for v5, per your
> and Andy's desire. And the SIMD code is already toggle-able via a
> Kconfig menu option.
>
>> we should
>> work with Andy Polyakov (as I have done several times over the past 5+
>> years) to upstream the changes we apply to the kernel version of the
>> code.
>
> Indeed this is the intent.
>
>> The same applies to code from other sources, btw, but I am not
>> personally familiar with them.
>
> Good news on this front:
> - Rene wrote the MIPS code specifically for WireGuard, so that _is_ upstream.
> - Samuel wrote the BLAKE2 assembly, and he's the co-maintainer of Zinc with me.
> - I talk to Dan and Peter a decent amount about qhasm.
> - I'm in very close contact with the team behind HACL*, and they're
> treating Zinc as a target -- stylistically and with regards to kernel
> requirements -- which means they're looking at what's happening in
> this patchset and adjusting accordingly.
>
>
>> * If upstreaming the changes is not an option, they should be applied
>> as a separate patch and not hidden in a 5000 line patch without any
>> justification or documentation (but Jason is already working on that)
>
> Indeed this is already underway.
>
> Thanks again for your review.
>
> Jason
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] netlink: ipv4 igmp join notifications
From: Patrick Ruddy @ 2018-09-18 13:12 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev, Jiří Pírko, Stephen Hemminger,
Nikolay Aleksandrov
In-Reply-To: <CAJieiUg03p6MNkZCdO65p4uQuOCVTN4mDr0htQNeYumrpDQMeA@mail.gmail.com>
On Thu, 2018-09-13 at 10:03 -0700, Roopa Prabhu wrote:
> On Thu, Sep 6, 2018 at 8:40 PM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> > On Thu, Sep 6, 2018 at 2:10 AM, Patrick Ruddy
> > <pruddy@vyatta.att-mail.com> wrote:
> > > Some userspace applications need to know about IGMP joins from the
> > > kernel for 2 reasons:
> > > 1. To allow the programming of multicast MAC filters in hardware
> > > 2. To form a multicast FORUS list for non link-local multicast
> > > groups to be sent to the kernel and from there to the interested
> > > party.
> > > (1) can be fulfilled but simply sending the hardware multicast MAC
> > > address to be programmed but (2) requires the L3 address to be sent
> > > since this cannot be constructed from the MAC address whereas the
> > > reverse translation is a standard library function.
> > >
> > > This commit provides addition and deletion of multicast addresses
> > > using the RTM_NEWMDB and RTM_DELMDB messages with AF_INET. It also
> > > provides the RTM_GETMDB extension to allow multicast join state to
> > > be read from the kernel.
> > >
> > > Signed-off-by: Patrick Ruddy <pruddy@vyatta.att-mail.com>
> > > ---
> > > v3 rework to use RTM_***MDB messages as per review comments.
> >
> > Patrick, this version seems to be using RTM_***MDB msgs with the
> > RTM_*ADDR format.
> > We cant do that...because existing RTM_MDB users will be confused.
> >
> > My request was to evaluate RTM_***MDB msg format. see
> > nlmsg_populate_mdb_fill for details.
> >
> > If you can wait a day or two I can share some experimental code that
> > moves high level RTM_*MDB msg handling into net/core/rtnetlink.c
> > similar to RTM_*FDB
> >
>
> I was trying to get a default per interface (non bridge) RTM_*MDB
> working, but realized that the dev->mc
> entries are already getting dumped as part of RTM_*FDB msgs instead of
> RTM_*MDB. (see net/core/rtnetlink.c:ndo_dflt_fdb_dump).
> This adds another wrench.
>
> so, that puts us back to your use of RTM_NEWADDR.
> Instead of using IFA_ADDRESS, you could introduce a new one
> IFA_IGMP_MULTICAST (since IFA_MULTICAST is already taken).
>
>
> To keep existing users of RTM_NEWADDR unaffected. I think you can use
> the IPMR family with RTM_NEWADDR.
> We can introduce new notification group. (We can choose to add a new
> family too, but that seems unnecessary)
>
> since you only need dumps:
> rtnl_register(RTNL_FAMILY_IPMR, RTM_GETADDR, NULL, igmp_rtm_dumpaddrs, 0);
>
> For notifications, since we already have many variants for routes, I
> don't see a problem adding similar addr variants
> RTNLGRP_IPV4_MCADDR
>
> (Others on the list may have more feedback).
I've hit a small snag with adding the new groups. The number of defined
groups currently sits at 31 so I can only add one before hitting the
limit defined by the 32 bit groups bitmask in socakddr_nl. I can use 1
group for both v4 and v6 notifications which seems like the sensible
options since the AF is carried separately, but it breaks the precedent
where there are separate IPV4 and IPV6 groups for IFADDR.
I have the combined group patches ready and can share them if that's
the preference.
Has there been any previous discussion about extending the number of
availabel groups?
^ permalink raw reply
* Re: [PATCH 1/2] netlink: add NLA_REJECT policy type
From: Jamal Hadi Salim @ 2018-09-18 13:12 UTC (permalink / raw)
To: Johannes Berg, Marcelo Ricardo Leitner, Michal Kubecek
Cc: linux-wireless, netdev, jbenc
In-Reply-To: <1537275441.2957.26.camel@sipsolutions.net>
On 2018-09-18 8:57 a.m., Johannes Berg wrote:
> On Tue, 2018-09-18 at 08:55 -0400, Jamal Hadi Salim wrote:
>
>> Execute permission kind of thing? i.e if i understood you correctly
>> if acl is "rwx" then attribute can only be written to (or read from) if
>> the "thing executing" is complete
>
> But it's not an attribute that you're executing, it's some kind of
> command, and then you get the return value of that command in that
> attribute?
>
> Say you want to scan for wifi networks - you trigger a scan, later you
> get a notification giving you some data about the scan (let's say the
> time it took) - there's no way you can set that time attribute.
>
Not very familiar with how wifi scan gets initiated. I am guessing
you issue some GET or SET to start a scan - and you get an async
response when it is complete (and it would include the time it took)?
Or maybe you get an immediate response and event notification later
and the time spent is in that notification?
I would still see that as a read-only attribute.
And the utility of "execute" bit is only in blocking another scan
from being initiated when one is in progress, if that is a desired
goal.
Note in most net devices stats can only be read but not written to
for example.
> (NB: it doesn't work this way, we don't have that attribute now, but I
> didn't want to pick a more complicated example)
>
>>> What would the practical difference be though? Hopefully you wouldn't
>>> have write-only attributes, and then NLA_REJECT is basically equivalent?
>>>
>>
>> If ACL says "-w-" then reading should get explicit permission denied
>> code possibly with an extack which is more descriptive that reading
>> is not allowed.
>
> Perhaps. But NLA_REJECT comes with an extack string to tell you, so ...
>
> I dunno. I think we already bloated the policies too much by including
> the validation_data pointer, and would hate to add more to that :-)
Your mileage may vary. NLA_REJECT may work acls offer more fine grained
controls.
cheers,
jamal
^ permalink raw reply
* [RFC 5/5] netlink: allow NLA_NESTED to specify nested policy to validate
From: Johannes Berg @ 2018-09-18 13:12 UTC (permalink / raw)
To: netdev; +Cc: Johannes Berg
In-Reply-To: <20180918131212.20266-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 | 10 ++++++++--
lib/nlattr.c | 17 +++++++++++++++++
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index b680fe365e91..6efa25a004f5 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:
diff --git a/lib/nlattr.c b/lib/nlattr.c
index fecc7b834706..4c8c4fffb20d 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -68,6 +68,11 @@ static int validate_nla_bitfield32(const struct nlattr *nla,
return 0;
}
+static int nla_validate_parse(const struct nlattr *head, int len, int maxtype,
+ const struct nla_policy *policy,
+ struct netlink_ext_ack *extack, bool *extack_set,
+ struct nlattr **tb);
+
static int validate_nla(const struct nlattr *nla, int maxtype,
const struct nla_policy *policy,
struct netlink_ext_ack *extack, bool *extack_set)
@@ -149,6 +154,18 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
*/
if (attrlen == 0)
break;
+ if (attrlen < NLA_HDRLEN)
+ return -ERANGE;
+ if (pt->validation_data) {
+ int err;
+
+ err = nla_validate_parse(nla_data(nla), nla_len(nla),
+ pt->len, pt->validation_data,
+ extack, extack_set, NULL);
+ if (err < 0)
+ return err;
+ }
+ break;
default:
if (pt->len)
minlen = pt->len;
--
2.14.4
^ permalink raw reply related
* [RFC 4/5] netlink: prepare validate extack setting for recursion
From: Johannes Berg @ 2018-09-18 13:12 UTC (permalink / raw)
To: netdev; +Cc: Johannes Berg
In-Reply-To: <20180918131212.20266-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
In one of my previous patches in this area I introduced code
to pass out just the error message to store in the extack, for
use in NLA_REJECT.
Change this code now to set both the error message and the bad
attribute pointer, and carry around a boolean indicating that
the values have been set.
This will be used in the next patch to allow recursive validation
of nested policies, while preserving the innermost error message
rather than overwriting it with a generic out-level message.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
lib/nlattr.c | 32 ++++++++++++++++++++------------
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 46a6d79cf2d1..fecc7b834706 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -70,7 +70,7 @@ 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, bool *extack_set)
{
const struct nla_policy *pt;
int minlen = 0, attrlen = nla_len(nla), type = nla_type(nla);
@@ -95,8 +95,11 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
break;
case NLA_REJECT:
- if (pt->validation_data && error_msg)
- *error_msg = pt->validation_data;
+ if (pt->validation_data && extack && !*extack_set) {
+ *extack_set = true;
+ extack->_msg = pt->validation_data;
+ NL_SET_BAD_ATTR(extack, nla);
+ }
return -EINVAL;
case NLA_FLAG:
@@ -161,24 +164,25 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
static int nla_validate_parse(const struct nlattr *head, int len, int maxtype,
const struct nla_policy *policy,
- struct netlink_ext_ack *extack,
+ struct netlink_ext_ack *extack, bool *extack_set,
struct nlattr **tb)
{
const struct nlattr *nla;
int rem;
nla_for_each_attr(nla, head, len, rem) {
- static const char _msg[] = "Attribute failed policy validation";
- const char *msg = _msg;
u16 type = nla_type(nla);
if (policy) {
- int err = validate_nla(nla, maxtype, policy, &msg);
+ int err = validate_nla(nla, maxtype, policy,
+ extack, extack_set);
if (err < 0) {
- if (extack)
- extack->_msg = msg;
- NL_SET_BAD_ATTR(extack, nla);
+ if (!*extack_set) {
+ *extack_set = true;
+ NL_SET_ERR_MSG_ATTR(extack, nla,
+ "Attribute failed policy validation");
+ }
return err;
}
}
@@ -208,9 +212,11 @@ int nla_validate(const struct nlattr *head, int len, int maxtype,
const struct nla_policy *policy,
struct netlink_ext_ack *extack)
{
+ bool extack_set = false;
int rem;
- rem = nla_validate_parse(head, len, maxtype, policy, extack, NULL);
+ rem = nla_validate_parse(head, len, maxtype, policy,
+ extack, &extack_set, NULL);
if (rem < 0)
return rem;
@@ -267,11 +273,13 @@ int nla_parse(struct nlattr **tb, int maxtype, const struct nlattr *head,
int len, const struct nla_policy *policy,
struct netlink_ext_ack *extack)
{
+ bool extack_set = false;
int rem;
memset(tb, 0, sizeof(struct nlattr *) * (maxtype + 1));
- rem = nla_validate_parse(head, len, maxtype, policy, extack, tb);
+ rem = nla_validate_parse(head, len, maxtype, policy,
+ extack, &extack_set, tb);
if (rem < 0)
return rem;
--
2.14.4
^ permalink raw reply related
* [RFC 3/5] netlink: combine validate/parse functions
From: Johannes Berg @ 2018-09-18 13:12 UTC (permalink / raw)
To: netdev; +Cc: Johannes Berg
In-Reply-To: <20180918131212.20266-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
The parse function of course contains validate, but it's
implemented a second time, sharing just the validation
of a single attribute.
Introduce nla_validate_parse() that can be used for both
parsing/validation and only validation, to share code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
lib/nlattr.c | 76 +++++++++++++++++++++++++++++++-----------------------------
1 file changed, 39 insertions(+), 37 deletions(-)
diff --git a/lib/nlattr.c b/lib/nlattr.c
index efbd6c1aff29..46a6d79cf2d1 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -159,6 +159,37 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
return 0;
}
+static int nla_validate_parse(const struct nlattr *head, int len, int maxtype,
+ const struct nla_policy *policy,
+ struct netlink_ext_ack *extack,
+ struct nlattr **tb)
+{
+ const struct nlattr *nla;
+ int rem;
+
+ nla_for_each_attr(nla, head, len, rem) {
+ static const char _msg[] = "Attribute failed policy validation";
+ const char *msg = _msg;
+ u16 type = nla_type(nla);
+
+ if (policy) {
+ int err = validate_nla(nla, maxtype, policy, &msg);
+
+ if (err < 0) {
+ if (extack)
+ extack->_msg = msg;
+ NL_SET_BAD_ATTR(extack, nla);
+ return err;
+ }
+ }
+
+ if (tb && type > 0 && type <= maxtype)
+ tb[type] = (struct nlattr *)nla;
+ }
+
+ return rem;
+}
+
/**
* nla_validate - Validate a stream of attributes
* @head: head of attribute stream
@@ -177,21 +208,12 @@ int nla_validate(const struct nlattr *head, int len, int maxtype,
const struct nla_policy *policy,
struct netlink_ext_ack *extack)
{
- const struct nlattr *nla;
int rem;
- nla_for_each_attr(nla, head, len, rem) {
- static const char _msg[] = "Attribute failed policy validation";
- const char *msg = _msg;
- int err = validate_nla(nla, maxtype, policy, &msg);
+ rem = nla_validate_parse(head, len, maxtype, policy, extack, NULL);
- if (err < 0) {
- if (extack)
- extack->_msg = msg;
- NL_SET_BAD_ATTR(extack, nla);
- return err;
- }
- }
+ if (rem < 0)
+ return rem;
return 0;
}
@@ -245,39 +267,19 @@ int nla_parse(struct nlattr **tb, int maxtype, const struct nlattr *head,
int len, const struct nla_policy *policy,
struct netlink_ext_ack *extack)
{
- const struct nlattr *nla;
- int rem, err;
+ int rem;
memset(tb, 0, sizeof(struct nlattr *) * (maxtype + 1));
- nla_for_each_attr(nla, head, len, rem) {
- 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;
- }
- }
-
- tb[type] = (struct nlattr *)nla;
- }
- }
+ rem = nla_validate_parse(head, len, maxtype, policy, extack, tb);
+ if (rem < 0)
+ return rem;
if (unlikely(rem > 0))
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
* [RFC 2/5] netlink: set extack error message in nla_validate()
From: Johannes Berg @ 2018-09-18 13:12 UTC (permalink / raw)
To: netdev; +Cc: Johannes Berg
In-Reply-To: <20180918131212.20266-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
In nla_parse() we already set this, but it makes sense to
also do it in nla_validate() which already also sets the
bad attribute pointer.
CC: David Ahern <dsahern@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
lib/nlattr.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 120ad569e13d..efbd6c1aff29 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -181,9 +181,13 @@ 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);
+ static const char _msg[] = "Attribute failed policy validation";
+ const char *msg = _msg;
+ int err = validate_nla(nla, maxtype, policy, &msg);
if (err < 0) {
+ if (extack)
+ extack->_msg = msg;
NL_SET_BAD_ATTR(extack, nla);
return err;
}
--
2.14.4
^ permalink raw reply related
* [RFC 1/5] netlink: remove NLA_NESTED_COMPAT
From: Johannes Berg @ 2018-09-18 13:12 UTC (permalink / raw)
To: netdev; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
This isn't used anywhere, so we might as well get rid of it.
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
* Re: [PATCH v3 net-next 07/12] net: ethernet: Add helper to remove a supported link mode
From: Andrew Lunn @ 2018-09-18 13:02 UTC (permalink / raw)
To: Simon Horman; +Cc: David Miller, netdev, Florian Fainelli
In-Reply-To: <20180918105817.z2o5yybcth7diqsu@verge.net.au>
> Hi Andrew,
Hi Simon
Thanks for the dumps
> 1. net-next: cf7d97e1e54d ("net: mdio: remove duplicated include from mdio_bus.c")
>
> basic status: no link
> capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 100baseTx-FD 100baseTx-HD flow-control
> link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>
> 2. net-next with this patch reverted
>
> basic status: autonegotiation complete, link ok
> capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 100baseTx-FD 100baseTx-HD
> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
So flow-control is not present here.
> basic status: autonegotiation complete, link ok
> capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 100baseTx-FD 100baseTx-HD
> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
And here also.
Looking at the code, i see:
/* E-MAC init function */
static void ravb_emac_init(struct net_device *ndev)
{
struct ravb_private *priv = netdev_priv(ndev);
/* Receive frame limit set register */
ravb_write(ndev, ndev->mtu + ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN, RFLR);
/* EMAC Mode: PAUSE prohibition; Duplex; RX Checksum; TX; RX */
ravb_write(ndev, ECMR_ZPF | (priv->duplex ? ECMR_DM : 0) |
(ndev->features & NETIF_F_RXCSUM ? ECMR_RCSC : 0) |
ECMR_TE | ECMR_RE, ECMR);
Does this mean Pause is not supported in the hardware?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH 1/2] netlink: add NLA_REJECT policy type
From: Johannes Berg @ 2018-09-18 12:57 UTC (permalink / raw)
To: Jamal Hadi Salim, Marcelo Ricardo Leitner, Michal Kubecek
Cc: linux-wireless, netdev, jbenc
In-Reply-To: <26dd9a66-9515-93aa-e21f-51c37db6be2c@mojatatu.com>
On Tue, 2018-09-18 at 08:55 -0400, Jamal Hadi Salim wrote:
> Execute permission kind of thing? i.e if i understood you correctly
> if acl is "rwx" then attribute can only be written to (or read from) if
> the "thing executing" is complete
But it's not an attribute that you're executing, it's some kind of
command, and then you get the return value of that command in that
attribute?
Say you want to scan for wifi networks - you trigger a scan, later you
get a notification giving you some data about the scan (let's say the
time it took) - there's no way you can set that time attribute.
(NB: it doesn't work this way, we don't have that attribute now, but I
didn't want to pick a more complicated example)
> > What would the practical difference be though? Hopefully you wouldn't
> > have write-only attributes, and then NLA_REJECT is basically equivalent?
> >
>
> If ACL says "-w-" then reading should get explicit permission denied
> code possibly with an extack which is more descriptive that reading
> is not allowed.
Perhaps. But NLA_REJECT comes with an extack string to tell you, so ...
I dunno. I think we already bloated the policies too much by including
the validation_data pointer, and would hate to add more to that :-)
johannes
^ permalink raw reply
* Re: [PATCH 1/2] netlink: add NLA_REJECT policy type
From: Jamal Hadi Salim @ 2018-09-18 12:55 UTC (permalink / raw)
To: Johannes Berg, Marcelo Ricardo Leitner, Michal Kubecek
Cc: linux-wireless, netdev, jbenc
In-Reply-To: <1537274378.2957.23.camel@sipsolutions.net>
On 2018-09-18 8:39 a.m., Johannes Berg wrote:
> On Tue, 2018-09-18 at 08:34 -0400, Jamal Hadi Salim wrote:
>
>> Maybe time to introduce kernel side access-control flags?
>> Read/Write permissions for example. Attrs marked as read only
>> (in the kernel) cannot be written to.
>
> I dunno, that might work for ethtool, but I want to use it for something
> that's not even an attribute you could think about writing to, but the
> result of some operation you started.
>
Execute permission kind of thing? i.e if i understood you correctly
if acl is "rwx" then attribute can only be written to (or read from) if
the "thing executing" is complete
> What would the practical difference be though? Hopefully you wouldn't
> have write-only attributes, and then NLA_REJECT is basically equivalent?
>
If ACL says "-w-" then reading should get explicit permission denied
code possibly with an extack which is more descriptive that reading
is not allowed.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 1/2] netlink: add NLA_REJECT policy type
From: Johannes Berg @ 2018-09-18 12:39 UTC (permalink / raw)
To: Jamal Hadi Salim, Marcelo Ricardo Leitner, Michal Kubecek
Cc: linux-wireless, netdev, jbenc
In-Reply-To: <847cc635-cb90-821d-5824-07e7f941db75@mojatatu.com>
On Tue, 2018-09-18 at 08:34 -0400, Jamal Hadi Salim wrote:
> > > Maybe it would be better to have NLA_IGNORE instead? </idea>
> >
> > I don't think so, it doesn't give any feedback to the application author
> > that they're doing something wrong.
> >
>
> Maybe time to introduce kernel side access-control flags?
> Read/Write permissions for example. Attrs marked as read only
> (in the kernel) cannot be written to.
I dunno, that might work for ethtool, but I want to use it for something
that's not even an attribute you could think about writing to, but the
result of some operation you started.
What would the practical difference be though? Hopefully you wouldn't
have write-only attributes, and then NLA_REJECT is basically equivalent?
johannes
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: net: qcom: Add binding for shared mdio bus
From: Andrew Lunn @ 2018-09-18 12:35 UTC (permalink / raw)
To: Wang, Dongsheng
Cc: Florian Fainelli, timur@kernel.org, davem@davemloft.net,
Zheng, Joey, netdev@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <71ba0057c5e547c382793be899e3268a@HXTBJIDCEMVIW02.hxtcorp.net>
> > If you want to describe the MDIO controller, then you embed a mdio
> > subnode into your Ethernet MAC node:
> >
> > emac0: ethernet@feb20000 {
> > mdio {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > phy0: ethernet-phy@0 {
> > reg = <0>;
> > };
> > };
> > };
> >
> > And then each Ethernet MAC controller refers to their appropriate PHY
> > device tree node using a phy-handle property to point to either their
> > own MDIO controller, or another MAC's MDIO controller.
> Sorry, I do not understand how phy-handle point to MDIO controller,
> because phy-handle is defined to point to a phy.
The MAC driver does not care what MDIO controller a PHY is on. All you
need to do to register the PHY is:
phy_node = of_parse_phandle(np, "phy-handle", 0);
phy_interface = of_get_phy_mode(np);
phydev = of_phy_connect(dev, phy_node,
&handle_link_change, 0,
phy_interface);
Andrew
^ permalink raw reply
* [PATCH net-next] cxgb4vf: Add ethtool private flags for changing force_link_up
From: Arjun Vynipadath @ 2018-09-18 13:07 UTC (permalink / raw)
To: netdev, davem
Cc: dt, nirranjan, indranil, Arjun Vynipadath, Casey Leedom,
Ganesh Goudar
Forcing link up of virtual interfaces even when physical link is down
causes packet drops and ping failures during bonding failover. Hence
adding a ethtool private flag to toggle force_link_up whenever required.
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4vf/adapter.h | 16 +++++++
.../net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 54 +++++++++++++++++++++-
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
index 5883f09..444a5c8 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
@@ -78,6 +78,18 @@ enum {
MAX_EGRQ = MAX_ETH_QSETS*2,
};
+enum {
+ PRIV_FLAG_PORT_FORCE_LINKUP_BIT,
+};
+
+#define PRIV_FLAG_PORT_FORCE_LINKUP \
+ BIT(PRIV_FLAG_PORT_FORCE_LINKUP_BIT)
+
+#define PRIV_FLAGS_ADAP 0x0
+#define DEFAULT_PRIV_FLAGS_ADAP 0x0
+#define PRIV_FLAGS_PORT PRIV_FLAG_PORT_FORCE_LINKUP
+#define DEFAULT_PRIV_FLAGS_PORT PRIV_FLAG_PORT_FORCE_LINKUP
+
/*
* Forward structure definition references.
*/
@@ -103,6 +115,7 @@ struct port_info {
u8 port_id; /* physical port ID */
u8 nqsets; /* # of "Queue Sets" */
u8 first_qset; /* index of first "Queue Set" */
+ u32 eth_flags; /* ethtool private flags */
struct link_config link_cfg; /* physical port configuration */
};
@@ -374,6 +387,9 @@ struct adapter {
unsigned long flags;
struct adapter_params params;
+ /* ethtool private flags */
+ u32 eth_flags;
+
/* queue and interrupt resources */
struct {
unsigned short vec;
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
index ff84791..ac10b5b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
@@ -138,6 +138,7 @@ static struct dentry *cxgb4vf_debugfs_root;
void t4vf_os_link_changed(struct adapter *adapter, int pidx, int link_ok)
{
struct net_device *dev = adapter->port[pidx];
+ const struct port_info *pi = netdev_priv(dev);
/*
* If the port is disabled or the current recorded "link up"
@@ -153,7 +154,9 @@ void t4vf_os_link_changed(struct adapter *adapter, int pidx, int link_ok)
if (link_ok) {
const char *s;
const char *fc;
- const struct port_info *pi = netdev_priv(dev);
+
+ if (!(pi->eth_flags & PRIV_FLAG_PORT_FORCE_LINKUP))
+ netif_carrier_on(dev);
switch (pi->link_cfg.speed) {
case 100:
@@ -200,6 +203,8 @@ void t4vf_os_link_changed(struct adapter *adapter, int pidx, int link_ok)
netdev_info(dev, "link up, %s, full-duplex, %s PAUSE\n", s, fc);
} else {
+ if (!(pi->eth_flags & PRIV_FLAG_PORT_FORCE_LINKUP))
+ netif_carrier_off(dev);
netdev_info(dev, "link down\n");
}
}
@@ -283,7 +288,7 @@ static int link_start(struct net_device *dev)
* no errors in enabling vi.
*/
- if (ret == 0)
+ if (ret == 0 && (pi->eth_flags & PRIV_FLAG_PORT_FORCE_LINKUP))
netif_carrier_on(dev);
return ret;
@@ -1502,6 +1507,10 @@ static int cxgb4vf_get_fecparam(struct net_device *dev,
return 0;
}
+static const char cxgb4vf_priv_flags_strings[][ETH_GSTRING_LEN] = {
+ [PRIV_FLAG_PORT_FORCE_LINKUP_BIT] = "port_force_linkup",
+};
+
/*
* Return our driver information.
*/
@@ -1524,6 +1533,7 @@ static void cxgb4vf_get_drvinfo(struct net_device *dev,
FW_HDR_FW_VER_MINOR_G(adapter->params.dev.tprev),
FW_HDR_FW_VER_MICRO_G(adapter->params.dev.tprev),
FW_HDR_FW_VER_BUILD_G(adapter->params.dev.tprev));
+ drvinfo->n_priv_flags = ARRAY_SIZE(cxgb4vf_priv_flags_strings);
}
/*
@@ -1728,6 +1738,8 @@ static int cxgb4vf_get_sset_count(struct net_device *dev, int sset)
switch (sset) {
case ETH_SS_STATS:
return ARRAY_SIZE(stats_strings);
+ case ETH_SS_PRIV_FLAGS:
+ return ARRAY_SIZE(cxgb4vf_priv_flags_strings);
default:
return -EOPNOTSUPP;
}
@@ -1745,6 +1757,10 @@ static void cxgb4vf_get_strings(struct net_device *dev,
case ETH_SS_STATS:
memcpy(data, stats_strings, sizeof(stats_strings));
break;
+ case ETH_SS_PRIV_FLAGS:
+ memcpy(data, cxgb4vf_priv_flags_strings,
+ sizeof(cxgb4vf_priv_flags_strings));
+ break;
}
}
@@ -1868,6 +1884,36 @@ static void cxgb4vf_get_wol(struct net_device *dev,
memset(&wol->sopass, 0, sizeof(wol->sopass));
}
+static u32 cxgb4vf_get_priv_flags(struct net_device *netdev)
+{
+ struct port_info *pi = netdev_priv(netdev);
+ struct adapter *adapter = pi->adapter;
+
+ return (adapter->eth_flags | pi->eth_flags);
+}
+
+/**
+ * set_flags - set/unset specified flags if passed in new_flags
+ * @cur_flags: pointer to current flags
+ * @new_flags: new incoming flags
+ * @flags: set of flags to set/unset
+ */
+static inline void set_flags(u32 *cur_flags, u32 new_flags, u32 flags)
+{
+ *cur_flags = (*cur_flags & ~flags) | (new_flags & flags);
+}
+
+static int cxgb4vf_set_priv_flags(struct net_device *netdev, u32 flags)
+{
+ struct port_info *pi = netdev_priv(netdev);
+ struct adapter *adapter = pi->adapter;
+
+ set_flags(&adapter->eth_flags, flags, PRIV_FLAGS_ADAP);
+ set_flags(&pi->eth_flags, flags, PRIV_FLAGS_PORT);
+
+ return 0;
+}
+
/*
* TCP Segmentation Offload flags which we support.
*/
@@ -1892,6 +1938,8 @@ static const struct ethtool_ops cxgb4vf_ethtool_ops = {
.get_regs_len = cxgb4vf_get_regs_len,
.get_regs = cxgb4vf_get_regs,
.get_wol = cxgb4vf_get_wol,
+ .get_priv_flags = cxgb4vf_get_priv_flags,
+ .set_priv_flags = cxgb4vf_set_priv_flags,
};
/*
@@ -3138,6 +3186,7 @@ static int cxgb4vf_pci_probe(struct pci_dev *pdev,
dev_info(&pdev->dev,
"Using assigned MAC ACL: %pM\n", mac);
}
+ pi->eth_flags = DEFAULT_PRIV_FLAGS_PORT;
}
/* See what interrupts we'll be using. If we've been configured to
@@ -3168,6 +3217,7 @@ static int cxgb4vf_pci_probe(struct pci_dev *pdev,
}
adapter->flags |= USING_MSI;
}
+ adapter->eth_flags = DEFAULT_PRIV_FLAGS_ADAP;
/* Now that we know how many "ports" we have and what interrupt
* mechanism we're going to use, we can configure our queue resources.
--
2.3.5
^ permalink raw reply related
* Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
From: Jason Gunthorpe @ 2018-09-18 17:59 UTC (permalink / raw)
To: Darren Hart
Cc: Al Viro, Arnd Bergmann, linux-fsdevel, Greg Kroah-Hartman,
David S. Miller, devel, linux-kernel, qat-linux, linux-crypto,
linux-media, dri-devel, linaro-mm-sig, amd-gfx, linux-input,
linux-iio, linux-rdma, linux-nvdimm, linux-nvme, linux-pci,
platform-driver-x86, linux-remoteproc, sparclinux, linux-scsi,
linux-usb, linux-fbdev, linuxppc-d
In-Reply-To: <20180918175108.GF35251@wrath>
On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote:
> On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote:
> > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
> >
> > > Acked-by: Darren Hart (VMware) <dvhart@infradead.org>
> > >
> > > As for a longer term solution, would it be possible to init fops in such
> > > a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg
> > > so we don't have to duplicate this boilerplate for every ioctl fops
> > > structure?
> >
> > Bad idea, that... Because several years down the road somebody will add
> > an ioctl that takes an unsigned int for argument. Without so much as looking
> > at your magical mystery macro being used to initialize file_operations.
>
> Fair, being explicit in the declaration as it is currently may be
> preferable then.
It would be much cleaner and safer if you could arrange things to add
something like this to struct file_operations:
long (*ptr_ioctl) (struct file *, unsigned int, void __user *);
Where the core code automatically converts the unsigned long to the
void __user * as appropriate.
Then it just works right always and the compiler will help address
Al's concern down the road.
Cheers,
Jason
^ permalink raw reply
* Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
From: Darren Hart @ 2018-09-18 17:51 UTC (permalink / raw)
To: Al Viro
Cc: Arnd Bergmann, linux-fsdevel, Greg Kroah-Hartman, David S. Miller,
devel, linux-kernel, qat-linux, linux-crypto, linux-media,
dri-devel, linaro-mm-sig, amd-gfx, linux-input, linux-iio,
linux-rdma, linux-nvdimm, linux-nvme, linux-pci,
platform-driver-x86, linux-remoteproc, sparclinux, linux-scsi,
linux-usb, linux-fbdev, linuxppc-dev, linux-btrfs
In-Reply-To: <20180914205748.GC19965@ZenIV.linux.org.uk>
On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote:
> On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
>
> > Acked-by: Darren Hart (VMware) <dvhart@infradead.org>
> >
> > As for a longer term solution, would it be possible to init fops in such
> > a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg
> > so we don't have to duplicate this boilerplate for every ioctl fops
> > structure?
>
> Bad idea, that... Because several years down the road somebody will add
> an ioctl that takes an unsigned int for argument. Without so much as looking
> at your magical mystery macro being used to initialize file_operations.
Fair, being explicit in the declaration as it is currently may be
preferable then.
--
Darren Hart
VMware Open Source Technology Center
^ permalink raw reply
* Announcing Netdev 0x13 conference
From: Jamal Hadi Salim @ 2018-09-18 12:11 UTC (permalink / raw)
To: people; +Cc: netdev@vger.kernel.org, linux-wireless, netfilter-devel, lwn
On behalf of the NetDev Society, this is a formal announcement that
Netdev 0x13 conference will be held in Prague, Czech Republic.
Tentative dates are March 20-22, 2019.
We had a very successful 0x12 meeting. The summaries are posted here:
https://lwn.net/Articles/763627/rss
For more details, all the slides, papers and videos are now up. Visit:
https://www.netdevconf.org/0x12/accepted-sessions.html
At 0x12 we tried a new format where the first day constitutes developer
working sessions via workshops and educational sessions via tutorials.
We have received feedback which we are in the process of evaluating
and we will be notifying you of any format changes. The window for
suggestions is still open - please send email to people@netdevconf.org.
We hope to announce the CFP much earlier than usual to give folks
ample time to submit.
For more frequent announcements join the people@netdevconf mailing list.
If tweeter is your thing we also do announce @netdev01
The official 0x13 website is at: https://www.netdevconf.org/0x13
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next v5 19/20] security/keys: rewrite big_key crypto to use Zinc
From: Jason A. Donenfeld @ 2018-09-18 17:12 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, netdev, linux-crypto, davem, gregkh, Samuel Neves,
Andy Lutomirski, Jean-Philippe Aumasson, Eric Biggers
In-Reply-To: <2826.1537290107@warthog.procyon.org.uk>
Hi David,
On Tue, Sep 18, 2018 at 06:01:47PM +0100, David Howells wrote:
> Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> > A while back, I noticed that the crypto and crypto API usage in big_keys
> > were entirely broken in multiple ways, so I rewrote it. Now, I'm
> > rewriting it again, but this time using Zinc's ChaCha20Poly1305
> > function.
>
> warthog>git grep chacha20poly1305_decrypt net-next/master
> warthog1>
>
> Where do I find this?
>
> David
Previously in the patchset:
https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/linux.git/log/?h=jd/wireguard
https://lore.kernel.org/lkml/20180918161646.19105-1-Jason@zx2c4.com/
Regards,
Jason
^ permalink raw reply
* Re: KMSAN: uninit-value in pppoe_rcv
From: Eric Dumazet @ 2018-09-18 17:03 UTC (permalink / raw)
To: Guillaume Nault, Eric Dumazet
Cc: Alexander Potapenko, syzbot+f5f6080811c849739212, LKML, mostrows,
Networking, syzkaller-bugs
In-Reply-To: <20180918165254.GB1473@alphalink.fr>
On 09/18/2018 09:52 AM, Guillaume Nault wrote:
> On Thu, Sep 13, 2018 at 06:57:54AM -0700, Eric Dumazet wrote:
>>
>>
>> I guess the following patch would fix the issue
>>
>> (I will submit it more formally)
>>
> Hi Eric,
>
> Do you still plan to submit this patch? Otherwise I can take care of it.
>
Yes I will submit it. Thanks.
^ permalink raw reply
* Re: KMSAN: uninit-value in pppoe_rcv
From: Guillaume Nault @ 2018-09-18 16:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexander Potapenko, syzbot+f5f6080811c849739212, LKML, mostrows,
Networking, syzkaller-bugs
In-Reply-To: <7424e094-afda-084a-ad80-299f219ced92@gmail.com>
On Thu, Sep 13, 2018 at 06:57:54AM -0700, Eric Dumazet wrote:
>
>
> I guess the following patch would fix the issue
>
> (I will submit it more formally)
>
Hi Eric,
Do you still plan to submit this patch? Otherwise I can take care of it.
> diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
> index ce61231e96ea5fe27f512fbd0d80d4609997e508..333e967ed968ea3ff2dda25289f7f657263db2b9 100644
> --- a/drivers/net/ppp/pppoe.c
> +++ b/drivers/net/ppp/pppoe.c
> @@ -423,6 +423,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
> struct pppoe_hdr *ph;
> struct pppox_sock *po;
> struct pppoe_net *pn;
> + __be16 sid;
> int len;
>
> skb = skb_share_check(skb, GFP_ATOMIC);
> @@ -434,6 +435,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
>
> ph = pppoe_hdr(skb);
> len = ntohs(ph->length);
> + sid = ph->sid;
>
> skb_pull_rcsum(skb, sizeof(*ph));
> if (skb->len < len)
> @@ -447,7 +449,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
> /* Note that get_item does a sock_hold(), so sk_pppox(po)
> * is known to be safe.
> */
> - po = get_item(pn, ph->sid, eth_hdr(skb)->h_source, dev->ifindex);
> + po = get_item(pn, sid, eth_hdr(skb)->h_source, dev->ifindex);
> if (!po)
> goto drop;
>
>
>
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Jason A. Donenfeld @ 2018-09-18 16:45 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Andy Lutomirski, Andrew Lutomirski, David Miller, Andrew Lunn,
Eric Biggers, Greg Kroah-Hartman, LKML, Netdev, Samuel Neves,
Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <CAKv+Gu-t5HPj+Y3-7JqkaKTdt-0ewOUobQaEuikpeOaX_SF+zg@mail.gmail.com>
Hi Ard,
On Tue, Sep 18, 2018 at 6:06 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> as long as we have data that supports the claim that it
> is actually faster on hardware people care about.
Seems reasonable. I'll next be turning my attention back to ARM
performance. I'll try to gather some numbers. Expect data at some
point next week.
Regards,
Jason
^ permalink raw reply
* OK
From: Ahmed Zama @ 2018-09-18 11:11 UTC (permalink / raw)
Good Day,
I am in need of a reliable and trust worthy person to work with me in
receiving huge sum of money into his or her account. I will give you
the full details immediately you respond to this email.
Ahmed Zama
+22675844869
^ 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