* Re: [PATCH 3/4] i825xx: switch to switch to dma_alloc_attrs
From: David Miller @ 2017-08-28 22:42 UTC (permalink / raw)
To: hch; +Cc: netdev, ralf, linux-mips, linux-parisc, linux-kernel
In-Reply-To: <20170826072125.9790-4-hch@lst.de>
From: Christoph Hellwig <hch@lst.de>
Date: Sat, 26 Aug 2017 09:21:24 +0200
> This way we can always pass DMA_ATTR_NON_CONSISTENT, the SNI mips version
> will simply ignore the flag.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH net] ipv6: set dst.obsolete when a cached route has expired
From: David Miller @ 2017-08-28 22:45 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, hannes
In-Reply-To: <cd3d9312a3d31ee72b9377e7200898c30f73ab8e.1503749410.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 26 Aug 2017 20:10:10 +0800
> Now it doesn't check for the cached route expiration in ipv6's
> dst_ops->check(), because it trusts dst_gc that would clean the
> cached route up when it's expired.
>
> The problem is in dst_gc, it would clean the cached route only
> when it's refcount is 1. If some other module (like xfrm) keeps
> holding it and the module only release it when dst_ops->check()
> fails.
>
> But without checking for the cached route expiration, .check()
> may always return true. Meanwhile, without releasing the cached
> route, dst_gc couldn't del it. It will cause this cached route
> never to expire.
>
> This patch is to set dst.obsolete with DST_OBSOLETE_KILL in .gc
> when it's expired, and check obsolete != DST_OBSOLETE_FORCE_CHK
> in .check.
>
> Note that this is even needed when ipv6 dst_gc timer is removed
> one day. It would set dst.obsolete in .redirect and .update_pmtu
> instead, and check for cached route expiration when getting it,
> just like what ipv4 route does.
>
> Reported-by: Jianlin Shi <jishi@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] sni_82596: Add Thomas' email address to driver.
From: David Miller @ 2017-08-28 22:51 UTC (permalink / raw)
To: ralf; +Cc: tsbogend, hch, netdev, linux-mips
In-Reply-To: <20170826131507.GA15074@linux-mips.org>
I need this reposted with a proper commit message and a signoff before
I can apply this, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] sched: sfq: drop packets after root qdisc lock is released
From: David Miller @ 2017-08-28 22:52 UTC (permalink / raw)
To: gfree.wind; +Cc: jhs, xiyou.wangcong, jiri, edumazet, netdev
In-Reply-To: <1503759538-32890-1-git-send-email-gfree.wind@vip.163.com>
From: gfree.wind@vip.163.com
Date: Sat, 26 Aug 2017 22:58:58 +0800
> From: Gao Feng <gfree.wind@vip.163.com>
>
> The commit 520ac30f4551 ("net_sched: drop packets after root qdisc lock
> is released) made a big change of tc for performance. But there are
> some points which are not changed in SFQ enqueue operation.
> 1. Fail to find the SFQ hash slot;
> 2. When the queue is full;
>
> Now use qdisc_drop instead free skb directly.
>
> Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net 0/4] xfrm_user info leaks
From: David Miller @ 2017-08-28 22:52 UTC (permalink / raw)
To: minipli; +Cc: steffen.klassert, herbert, netdev
In-Reply-To: <1503760140-9095-1-git-send-email-minipli@googlemail.com>
From: Mathias Krause <minipli@googlemail.com>
Date: Sat, 26 Aug 2017 17:08:56 +0200
> Hi David, Steffen,
>
> the following series fixes a few info leaks due to missing padding byte
> initialization in the xfrm_user netlink interface.
>
> Please apply!
Steffen please pick this up if you haven't already.
Thank you.
^ permalink raw reply
* Re: [PATCH] net: ethernet: broadcom: Remove null check before kfree
From: David Miller @ 2017-08-28 22:53 UTC (permalink / raw)
To: himanshujha199640; +Cc: jarod, netdev, linux-kernel
In-Reply-To: <1503778667-4416-1-git-send-email-himanshujha199640@gmail.com>
From: Himanshu Jha <himanshujha199640@gmail.com>
Date: Sun, 27 Aug 2017 01:47:47 +0530
> Kfree on NULL pointer is a no-op and therefore checking is redundant.
>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH iproute2 2/4] tc: m_ife: print IEEE ethertype format
From: Jamal Hadi Salim @ 2017-08-28 22:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Alexander Aring, yotamg, xiyou.wangcong, jiri, netdev
In-Reply-To: <20170828153734.4b32fa02@xeon-e3>
On 17-08-28 06:37 PM, Stephen Hemminger wrote:
> On Mon, 28 Aug 2017 18:18:04 -0400
[..]
>>> @@ -125,7 +125,7 @@ static int parse_ife(struct action_util *a, int *argc_p, char ***argv_p,
>>> NEXT_ARG();
>>> if (get_u16(&ife_type, *argv, 0))
>>> invarg("ife type is invalid", *argv);
>>> - fprintf(stderr, "IFE type 0x%x\n", ife_type);
>>> + fprintf(stderr, "IFE type 0x%04X\n", ife_type);
>>> user_type = 1;
>>> } else if (matches(*argv, "dst") == 0) {
>>> NEXT_ARG();
>>>
>>
>
>
> For iproute commands the show output is supposed to match the corresponding set inputs.
>
These were being printed at parse time ...
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] be2net: Fix some u16 fields appropriately
From: David Miller @ 2017-08-28 23:19 UTC (permalink / raw)
To: yanhaishuang
Cc: sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
netdev, linux-kernel
In-Reply-To: <1503818685-32068-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Sun, 27 Aug 2017 15:24:45 +0800
> In be_tx_compl_process, frag_index declared as u32, so it's better to
> declare last_index as u32 also.
>
> CC: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Fixes: b0fd2eb28bd4 ("be2net: Declare some u16 fields as u32 to improve
> performance")
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
That is not a legitimate reason for making this change.
> @@ -255,7 +255,7 @@ struct be_tx_stats {
> /* Structure to hold some data of interest obtained from a TX CQE */
> struct be_tx_compl_info {
> u8 status; /* Completion status */
> - u16 end_index; /* Completed TXQ Index */
> + u32 end_index; /* Completed TXQ Index */
> };
>
> struct be_tx_obj {
The ->end_index comes solely from:
txcp->end_index = GET_TX_COMPL_BITS(wrb_index, compl);
Which is precisely a 16-bit value.
I'm not applying this, sorry.
^ permalink raw reply
* RE: [PATCH v3 net-next 1/1] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)
From: Dexuan Cui @ 2017-08-28 23:30 UTC (permalink / raw)
To: David Miller
Cc: mkubecek@suse.cz, olaf@aepfle.de, Stephen Hemminger,
georgezhang@vmware.com, gregkh@linuxfoundation.org,
netdev@vger.kernel.org, jasowang@redhat.com,
dave.scott@docker.com, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, marcelo.cerri@canonical.com,
dan.carpenter@oracle.com, stefanha@redhat.com,
rolf.neugebauer@docker.com, apw@canonical.com, joe@perches.com,
vkuznets@redhat.com, Haiyang Zhang
In-Reply-To: <20170828.153852.1182668029079177666.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, August 28, 2017 15:39
> From: Dexuan Cui <decui@microsoft.com>
> Date: Sat, 26 Aug 2017 04:52:43 +0000
>
> >
> > Hyper-V Sockets (hv_sock) supplies a byte-stream based communication
> > mechanism between the host and the guest. It uses VMBus ringbuffer as
> the
> > transportation layer.
> >
> > With hv_sock, applications between the host (Windows 10, Windows
> Server
> > 2016 or newer) and the guest can talk with each other using the traditional
> > socket APIs.
> >
> > Signed-off-by: Dexuan Cui <decui@microsoft.com>
>
> Applied, thank you.
Thanks a lot!
There are some supporting patches still pending in the VMBus driver.
I'll make sure they go in through the char-misc tree.
Thanks,
-- Dexuan
^ permalink raw reply
* Re: [PATCH v4 0/7] Add RSS to DPAA 1.x Ethernet driver
From: David Miller @ 2017-08-28 23:41 UTC (permalink / raw)
To: madalin.bucur; +Cc: netdev, linuxppc-dev, linux-kernel
In-Reply-To: <1503839623-3906-1-git-send-email-madalin.bucur@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Date: Sun, 27 Aug 2017 16:13:36 +0300
> This patch set introduces Receive Side Scaling for the DPAA Ethernet
> driver. Documentation is updated with details related to the new
> feature and limitations that apply.
> Added also a small fix.
>
> v2: removed a C++ style comment
> v3: move struct fman to header file to avoid exporting a function
> v4: addressed compilation issues introduced in v3
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
From: David Miller @ 2017-08-28 23:42 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, samuel, linux-kernel
In-Reply-To: <20170827150334.32495-1-gregkh@linuxfoundation.org>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sun, 27 Aug 2017 17:03:30 +0200
> The IRDA code has long been obsolete and broken. So, to keep people
> from trying to use it, and to prevent people from having to maintain it,
> let's move it to drivers/staging/ so that we can delete it entirely from
> the kernel in a few releases.
No objection, I'll apply this to net-next, thanks Greg.
^ permalink raw reply
* Re: [PATCH V2 net-next] net-next/hinic: Fix MTU limitation
From: David Miller @ 2017-08-28 23:44 UTC (permalink / raw)
To: aviad.krawczyk; +Cc: linux-kernel, netdev, zhaochen6, andrew
In-Reply-To: <1503854426-42046-1-git-send-email-aviad.krawczyk@huawei.com>
From: Aviad Krawczyk <aviad.krawczyk@huawei.com>
Date: Mon, 28 Aug 2017 01:20:26 +0800
> Fix the hw MTU limitation by setting max_mtu
>
> Signed-off-by: Aviad Krawczyk <aviad.krawczyk@huawei.com>
> Signed-off-by: Zhao Chen <zhaochen6@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net-next/hinic: fix comparison of a uint16_t type with -1
From: David Miller @ 2017-08-28 23:44 UTC (permalink / raw)
To: aviad.krawczyk; +Cc: linux-kernel, netdev, zhaochen6, colin.king, dan.carpenter
In-Reply-To: <1503855330-84810-1-git-send-email-aviad.krawczyk@huawei.com>
From: Aviad Krawczyk <aviad.krawczyk@huawei.com>
Date: Mon, 28 Aug 2017 01:35:30 +0800
> Remove the search for index of constant buffer size
>
> Signed-off-by: Aviad Krawczyk <aviad.krawczyk@huawei.com>
> Signed-off-by: Zhao Chen <zhaochen6@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
From: Joe Perches @ 2017-08-28 23:46 UTC (permalink / raw)
To: David Miller, gregkh; +Cc: samuel, netdev, linux-kernel, devel
In-Reply-To: <20170828.164208.1908438929113102094.davem@davemloft.net>
On Mon, 2017-08-28 at 16:42 -0700, David Miller wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Date: Sun, 27 Aug 2017 17:03:30 +0200
>
> > The IRDA code has long been obsolete and broken. So, to keep people
> > from trying to use it, and to prevent people from having to maintain it,
> > let's move it to drivers/staging/ so that we can delete it entirely from
> > the kernel in a few releases.
>
> No objection, I'll apply this to net-next, thanks Greg.
Still needs an update to MAINTAINERS.
^ permalink raw reply
* Re: [net-next 00/15][pull request] 40GbE Intel Wired LAN Driver Updates 2017-08-27
From: David Miller @ 2017-08-28 23:48 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20170828001603.75876-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sun, 27 Aug 2017 17:15:48 -0700
> This series contains updates to i40e and i40evf only.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next v3 0/3] NCSI VLAN Filtering Support
From: David Miller @ 2017-08-28 23:50 UTC (permalink / raw)
To: sam; +Cc: netdev, linux-kernel, openbmc, joel, benh, gwshan, ratagupt
In-Reply-To: <20170828061843.24349-1-sam@mendozajonas.com>
From: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Date: Mon, 28 Aug 2017 16:18:40 +1000
> This series (mainly patch 2) adds VLAN filtering to the NCSI implementation.
> A fair amount of code already exists in the NCSI stack for VLAN filtering but
> none of it is actually hooked up. This goes the final mile and fixes a few
> bugs in the existing code found along the way (patch 1).
>
> Patch 3 adds the appropriate flag and callbacks to the ftgmac100 driver to
> enable filtering as it's a large consumer of NCSI (and what I've been
> testing on).
>
> v3: - Add comment describing change to ncsi_find_filter()
> - Catch NULL in clear_one_vid() from ncsi_get_filter()
> - Simplify state changes when kicking updated channel
Series applied.
^ permalink raw reply
* Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running cgroup sock filters
From: Alexei Starovoitov @ 2017-08-28 23:56 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, daniel, ast, tj, davem, luto
In-Reply-To: <bb4398e5-55a3-d63e-ac4d-3f9d7e2efc02@gmail.com>
On Sun, Aug 27, 2017 at 08:49:23AM -0600, David Ahern wrote:
>
> The override flag is independent of the recursive flag. If the override
> flag does not allow an override, the attempt to add a new program fails.
> The recursive flag brings an additional constraint: once a cgroup has a
> program with the recursive flag set it is inherited by all descendant
> groups. Attempts to insert a program that changes that flag fails EINVAL.
>
> Start with the root group at $MNT. No program is attached. By default
> override is allowed and recursive is not set.
The above explanation is the reason we need tests for this logic.
The default is the opposite! By default override is _not_ allowed.
> 1. Group $MNT/a is created.
>
> i. Default settings from $MNT are inherited; 'a' has override enabled
> and recursive disabled.
not true, but say the user attached a prog wih override on...
> ii. Program is attached. Override flag is set, recursive flag is not set.
>
> iii. Process in 'a' opens a socket, program attached to 'a' is run.
>
>
> 2. $MNT/a/b is created
>
> i. 'b' inherits the program and settings of 'a' (override enabled,
> recursive disabled).
>
> ii. Process in 'b' opens a socket. Program inherited from 'a' is run.
>
> iii. Non-interesting case for this patch set: attaching a non-recursive
> program to 'b' overrides the inherited one. process opens a socket only
> the 'b' program is run.
>
> iv. Program is attached to 'b', override flag set, recursive flag set.
>
> v. Process in 'b' opens a socket. Program attached to 'b' is run and
> then program from 'a' is run. Recursion stops here since 'a' does not
> have the recursion flag set.
isn't this the problem? Override+non_recurse was set on 'a'.
Now we attached override+recurse on 'b' and suddenly 'a'
will be run like it was 'recursive'?
imo that is counter intuitive to the owner of 'a'.
I think there can be two options:
- if recurse is not set on 'a', all of it descendents should not be allowed
to use recurse flag
- if recurse is not set on 'a', it should not be run
imo the former is cleaner and avoids issues with detach in the middle
> 3. $MNT/a/b/c is created
>
> i. 'c' inherits the settings of 'b' (override is allowed, recursive flag
> is set)
>
> ii. Process in 'c' opens a socket. No program from 'c' exists, so
> nothing is run. Recursion flag is set, so program from 'b' is run, then
> program from 'a' is run. Stop (recursive flag not set on 'a').
also doesn't make sense to me. Both 'b' and 'c' were attached as
override+recurse while 'a' as non-recurse why would it run?
The owner of 'a' attached it as override in the first place,
so it assumed that if descendent wants to override it it can
and the prog 'a' won't be running.
> iii. Attaching a non-recursive program to 'c' fails because it inherited
> the recursive flag from 'b' and that can not be reset by a descendant.
that part makes sense
> iv. Recursive program is attached to 'c'
>
> v. Process in 'c' opens a socket. Program attached to 'c' is run, then
> the program from 'b' and the program from 'a'. Stop.
>
> etc.
>
> To consider what happens on doubling back and changing programs in the
> hierarchy, start with $MNT/a/b/c from 3 above (non-recursive on 'a',
> recursive on 'b' and recursive on 'c') for each of the following cases:
>
> 1. Program attached to 'b' is detached, recursive flag is reset in the
> request. Attempt fails EINVAL because the recursion flag has to be set.
didn't get this point. you mean 'detach' will fail?
> 2. Program attached to 'b' is detached, recursive flag is set. Allowed.
meaing that detach from 'b' has to pass recurse flag to be detached?
That's also odd.
imo detach should always succeed and the process doing detach
shouldn't need to know what flags were used in attach.
> Process in 'b' opens a socket. No program attached to 'b' so no program
> is run. Recursive flag is set to program from 'a' is run. Stop.
>
> We should allow the recursive flag to be reset if the parent is not
> recursive allowing an unwind of settings applied. I'll add that change.
I don't get this part.
Anyway looking forward to the next patch set with tests and comments like above.
Also adding Andy to cc. I'd really like both Andy and Tejun to review this logic.
^ permalink raw reply
* Re: [PATCH net-next 00/11] bnxt_en: Updates.
From: David Miller @ 2017-08-28 23:57 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1503942035-24924-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Mon, 28 Aug 2017 13:40:24 -0400
> Various changes including updated firmware interface, improved TX ring
> allocation scheme, improved out-of-memory logic in NAPI loop, reduced
> default rings on multi-port devices, new PCI IDs. Of particular note,
>
> CPU affinity hints from Vasundhara Volam.
>
> TC Flower eswitch support from Sathya Perla.
Looks good, series applied, thanks!
^ permalink raw reply
* [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS without CAP_SYS_ADMIN
From: Prakash Sangappa @ 2017-08-29 0:12 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: davem, ebiederm, drepper, prakash.sangappa
Currently passing tid(gettid(2)) of a thread in struct ucred in
SCM_CREDENTIALS message requires CAP_SYS_ADMIN capability otherwise
it fails with EPERM error. Some applications deal with thread id
of a thread(tid) and so it would help to allow tid in SCM_CREDENTIALS
message. Basically, either tgid(pid of the process) or the tid of
the thread should be allowed without the need for CAP_SYS_ADMIN capability.
SCM_CREDENTIALS will be used to determine the global id of a process or
a thread running inside a pid namespace.
This patch adds necessary check to accept tid in SCM_CREDENTIALS
struct ucred.
Signed-off-by: Prakash Sangappa <prakash.sangappa@oracle.com>
---
net/core/scm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/scm.c b/net/core/scm.c
index b1ff8a4..9274197 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -55,6 +55,7 @@ static __inline__ int scm_check_creds(struct ucred *creds)
return -EINVAL;
if ((creds->pid == task_tgid_vnr(current) ||
+ creds->pid == task_pid_vnr(current) ||
ns_capable(task_active_pid_ns(current)->user_ns, CAP_SYS_ADMIN)) &&
((uid_eq(uid, cred->uid) || uid_eq(uid, cred->euid) ||
uid_eq(uid, cred->suid)) || ns_capable(cred->user_ns, CAP_SETUID)) &&
--
2.7.4
^ permalink raw reply related
* [PATCH net] net: dsa: Don't dereference dst->cpu_dp->netdev
From: Florian Fainelli @ 2017-08-29 0:10 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, dan.carpenter, Florian Fainelli
If we do not have a master network device attached dst->cpu_dp will be
NULL and accessing cpu_dp->netdev will create a trace similar to the one
below. The correct check is on dst->cpu_dp period.
[ 1.004650] DSA: switch 0 0 parsed
[ 1.008078] Unable to handle kernel NULL pointer dereference at
virtual address 00000010
[ 1.016195] pgd = c0003000
[ 1.018918] [00000010] *pgd=80000000004003, *pmd=00000000
[ 1.024349] Internal error: Oops: 206 [#1] SMP ARM
[ 1.029157] Modules linked in:
[ 1.032228] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.13.0-rc6-00071-g45b45afab9bd-dirty #7
[ 1.040772] Hardware name: Broadcom STB (Flattened Device Tree)
[ 1.046704] task: ee08f840 task.stack: ee090000
[ 1.051258] PC is at dsa_register_switch+0x5e0/0x9dc
[ 1.056234] LR is at dsa_register_switch+0x5d0/0x9dc
[ 1.061211] pc : [<c08fb28c>] lr : [<c08fb27c>] psr: 60000213
[ 1.067491] sp : ee091d88 ip : 00000000 fp : 0000000c
[ 1.072728] r10: 00000000 r9 : 00000001 r8 : ee208010
[ 1.077965] r7 : ee2b57b0 r6 : ee2b5780 r5 : 00000000 r4 :
ee208e0c
[ 1.084506] r3 : 00000000 r2 : 00040d00 r1 : 2d1b2000 r0 :
00000016
[ 1.091050] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment user
[ 1.098199] Control: 32c5387d Table: 00003000 DAC: fffffffd
[ 1.103957] Process swapper/0 (pid: 1, stack limit = 0xee090210)
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 6d3c8c0dd88a ("net: dsa: Remove master_netdev and use dst->cpu_dp->netdev")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
net/dsa/dsa2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index c442051d5a55..20bc9c56fca0 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -577,7 +577,7 @@ static int dsa_dst_parse(struct dsa_switch_tree *dst)
return err;
}
- if (!dst->cpu_dp->netdev) {
+ if (!dst->cpu_dp) {
pr_warn("Tree has no master device\n");
return -EINVAL;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running cgroup sock filters
From: David Ahern @ 2017-08-29 0:43 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: netdev, daniel, ast, tj, davem, luto
In-Reply-To: <20170828235653.jq62menrcfrh5rco@ast-mbp>
On 8/28/17 5:56 PM, Alexei Starovoitov wrote:
> On Sun, Aug 27, 2017 at 08:49:23AM -0600, David Ahern wrote:
>>
>> The override flag is independent of the recursive flag. If the override
>> flag does not allow an override, the attempt to add a new program fails.
>> The recursive flag brings an additional constraint: once a cgroup has a
>> program with the recursive flag set it is inherited by all descendant
>> groups. Attempts to insert a program that changes that flag fails EINVAL.
>>
>> Start with the root group at $MNT. No program is attached. By default
>> override is allowed and recursive is not set.
>
> The above explanation is the reason we need tests for this logic.
> The default is the opposite! By default override is _not_ allowed.
yes, I got that backwards. It's how my programs work since I always add
the OVERRIDE flag ATM.
>
>> 1. Group $MNT/a is created.
>>
>> i. Default settings from $MNT are inherited; 'a' has override enabled
>> and recursive disabled.
>
> not true, but say the user attached a prog wih override on...
exactly.
>
>> ii. Program is attached. Override flag is set, recursive flag is not set.
>>
>> iii. Process in 'a' opens a socket, program attached to 'a' is run.
>>
>>
>> 2. $MNT/a/b is created
>>
>> i. 'b' inherits the program and settings of 'a' (override enabled,
>> recursive disabled).
>>
>> ii. Process in 'b' opens a socket. Program inherited from 'a' is run.
>>
>> iii. Non-interesting case for this patch set: attaching a non-recursive
>> program to 'b' overrides the inherited one. process opens a socket only
>> the 'b' program is run.
>>
>> iv. Program is attached to 'b', override flag set, recursive flag set.
>>
>> v. Process in 'b' opens a socket. Program attached to 'b' is run and
>> then program from 'a' is run. Recursion stops here since 'a' does not
>> have the recursion flag set.
>
> isn't this the problem? Override+non_recurse was set on 'a'.
> Now we attached override+recurse on 'b' and suddenly 'a'
> will be run like it was 'recursive'?
Without 'b', 'a' is run. With 'b' and the recurse flag I am suggesting
the user is saying I want 'b' and then 'a'. ie., the first parent group
without the flag is where we stop.
> imo that is counter intuitive to the owner of 'a'.
> I think there can be two options:
> - if recurse is not set on 'a', all of it descendents should not be allowed
> to use recurse flag
> - if recurse is not set on 'a', it should not be run
If 'a' can be overridden then I don't agree with the first suggestion.
Which means you are suggesting we stop at the last group with the
recursive flag set. That is fine too.
>
> imo the former is cleaner and avoids issues with detach in the middle
>
>> 3. $MNT/a/b/c is created
>>
>> i. 'c' inherits the settings of 'b' (override is allowed, recursive flag
>> is set)
>>
>> ii. Process in 'c' opens a socket. No program from 'c' exists, so
>> nothing is run. Recursion flag is set, so program from 'b' is run, then
>> program from 'a' is run. Stop (recursive flag not set on 'a').
>
> also doesn't make sense to me. Both 'b' and 'c' were attached as
> override+recurse while 'a' as non-recurse why would it run?
> The owner of 'a' attached it as override in the first place,
> so it assumed that if descendent wants to override it it can
> and the prog 'a' won't be running.
same argument as above - the question is where do we stop. My suggestion
and implementation is stopping at the first group without the flag.
As stated all along, descendant groups inherit programs of the parent
marked recurse - not by copying them into the group but by recursion.
>
>> iii. Attaching a non-recursive program to 'c' fails because it inherited
>> the recursive flag from 'b' and that can not be reset by a descendant.
>
> that part makes sense
>
>> iv. Recursive program is attached to 'c'
>>
>> v. Process in 'c' opens a socket. Program attached to 'c' is run, then
>> the program from 'b' and the program from 'a'. Stop.
>>
>> etc.
>>
>> To consider what happens on doubling back and changing programs in the
>> hierarchy, start with $MNT/a/b/c from 3 above (non-recursive on 'a',
>> recursive on 'b' and recursive on 'c') for each of the following cases:
>>
>> 1. Program attached to 'b' is detached, recursive flag is reset in the
>> request. Attempt fails EINVAL because the recursion flag has to be set.
>
> didn't get this point. you mean 'detach' will fail?
Yes, because it tried to reset the flag in the process.
This is something we can make user friendly - the detach succeeds, but
the recurse flag is ignored and the recurse flag in the group is not
reset unless it is the base group with the recurse flag (i.e., the
parent is marked non-recurse).
>
>> 2. Program attached to 'b' is detached, recursive flag is set. Allowed.
>
> meaing that detach from 'b' has to pass recurse flag to be detached?
> That's also odd.
> imo detach should always succeed and the process doing detach
> shouldn't need to know what flags were used in attach.
Then, we agree to make it user friendly and handle resetting the recurse
flag automatically.
>
>> Process in 'b' opens a socket. No program attached to 'b' so no program
>> is run. Recursive flag is set to program from 'a' is run. Stop.
>>
>> We should allow the recursive flag to be reset if the parent is not
>> recursive allowing an unwind of settings applied. I'll add that change.
>
> I don't get this part.
> Anyway looking forward to the next patch set with tests and comments like above.
Per above discussion, you don't want 'a' run since it is not marked
recurse. My last sentence is the user friendly part in resetting the
flag in the cgroup.
^ permalink raw reply
* Re: Permissions for eBPF objects
From: Chenbo Feng @ 2017-08-29 0:47 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Borkmann, Jeffrey Vander Stoep, Stephen Smalley, netdev,
SELinux, Mickaël Salaün
In-Reply-To: <20170826010330.tuospq5h43fv3tlp@ast-mbp>
On Fri, Aug 25, 2017 at 6:03 PM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Fri, Aug 25, 2017 at 10:07:27PM +0200, Daniel Borkmann wrote:
>> On 08/25/2017 09:52 PM, Chenbo Feng wrote:
>> > On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep <jeffv@google.com> wrote:
>> > > On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> > > > On Fri, 2017-08-25 at 11:01 -0700, Jeffrey Vander Stoep via Selinux
>> > > > wrote:
>> > > > > I’d like to get your thoughts on adding LSM permission checks on BPF
>> > > > > objects.
>
> before reinventing the wheel please take a look at landlock work.
> Everything that was discussed in this thread is covered by it.
> The patches have been in development for more than a year and most of the early
> issues have been resolved.
> It will be presented again during security summit in LA in September.
>
I am not very familiar with landlock lsm, isn't this module also
depend on the lsm hooks to do
the landlock check? If so then adding lsm hooks for eBPF object seems
not conflict with the
work on progress.
^ permalink raw reply
* Re: [PATCH] be2net: Fix some u16 fields appropriately
From: 严海双 @ 2017-08-29 1:04 UTC (permalink / raw)
To: David Miller
Cc: sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
netdev, linux-kernel
In-Reply-To: <20170828.161924.1286298670313299855.davem@davemloft.net>
> On 2017年8月29日, at 上午7:19, David Miller <davem@davemloft.net> wrote:
>
> From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
> Date: Sun, 27 Aug 2017 15:24:45 +0800
>
>> In be_tx_compl_process, frag_index declared as u32, so it's better to
>> declare last_index as u32 also.
>>
>> CC: Ajit Khaparde <ajit.khaparde@broadcom.com>
>> Fixes: b0fd2eb28bd4 ("be2net: Declare some u16 fields as u32 to improve
>> performance")
>> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
>
> That is not a legitimate reason for making this change.
>
>> @@ -255,7 +255,7 @@ struct be_tx_stats {
>> /* Structure to hold some data of interest obtained from a TX CQE */
>> struct be_tx_compl_info {
>> u8 status; /* Completion status */
>> - u16 end_index; /* Completed TXQ Index */
>> + u32 end_index; /* Completed TXQ Index */
>> };
>>
>> struct be_tx_obj {
>
> The ->end_index comes solely from:
>
> txcp->end_index = GET_TX_COMPL_BITS(wrb_index, compl);
>
> Which is precisely a 16-bit value.
>
> I'm not applying this, sorry.
>
Hi David,
The GET_TX_COMPL_BITS comes from amap_get which also returns a 32-bit value:
6 static inline u32 amap_get(void *ptr, u32 dw_offset, u32 mask, u32 offset)
5 {
4 u32 *dw = (u32 *) ptr;
3 return mask & (*(dw + dw_offset) >> offset);
2 }
1
869 #define AMAP_GET_BITS(_struct, field, ptr) \
1 amap_get(ptr, \
2 offsetof(_struct, field)/32, \
3 amap_mask(sizeof(((_struct *)0)->field)), \
4 AMAP_BIT_OFFSET(_struct, field))
^ permalink raw reply
* Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running cgroup sock filters
From: Alexei Starovoitov @ 2017-08-29 1:12 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, daniel, ast, tj, davem, luto
In-Reply-To: <45102738-365f-d08b-f3cf-9a81683956c4@gmail.com>
On Mon, Aug 28, 2017 at 06:43:42PM -0600, David Ahern wrote:
> On 8/28/17 5:56 PM, Alexei Starovoitov wrote:
> > On Sun, Aug 27, 2017 at 08:49:23AM -0600, David Ahern wrote:
> >>
> >> The override flag is independent of the recursive flag. If the override
> >> flag does not allow an override, the attempt to add a new program fails.
> >> The recursive flag brings an additional constraint: once a cgroup has a
> >> program with the recursive flag set it is inherited by all descendant
> >> groups. Attempts to insert a program that changes that flag fails EINVAL.
> >>
> >> Start with the root group at $MNT. No program is attached. By default
> >> override is allowed and recursive is not set.
> >
> > The above explanation is the reason we need tests for this logic.
> > The default is the opposite! By default override is _not_ allowed.
>
> yes, I got that backwards. It's how my programs work since I always add
> the OVERRIDE flag ATM.
>
> >
> >> 1. Group $MNT/a is created.
> >>
> >> i. Default settings from $MNT are inherited; 'a' has override enabled
> >> and recursive disabled.
> >
> > not true, but say the user attached a prog wih override on...
>
> exactly.
>
> >
> >> ii. Program is attached. Override flag is set, recursive flag is not set.
> >>
> >> iii. Process in 'a' opens a socket, program attached to 'a' is run.
> >>
> >>
> >> 2. $MNT/a/b is created
> >>
> >> i. 'b' inherits the program and settings of 'a' (override enabled,
> >> recursive disabled).
> >>
> >> ii. Process in 'b' opens a socket. Program inherited from 'a' is run.
> >>
> >> iii. Non-interesting case for this patch set: attaching a non-recursive
> >> program to 'b' overrides the inherited one. process opens a socket only
> >> the 'b' program is run.
> >>
> >> iv. Program is attached to 'b', override flag set, recursive flag set.
> >>
> >> v. Process in 'b' opens a socket. Program attached to 'b' is run and
> >> then program from 'a' is run. Recursion stops here since 'a' does not
> >> have the recursion flag set.
> >
> > isn't this the problem? Override+non_recurse was set on 'a'.
> > Now we attached override+recurse on 'b' and suddenly 'a'
> > will be run like it was 'recursive'?
>
> Without 'b', 'a' is run. With 'b' and the recurse flag I am suggesting
> the user is saying I want 'b' and then 'a'. ie., the first parent group
> without the flag is where we stop.
>
> > imo that is counter intuitive to the owner of 'a'.
> > I think there can be two options:
> > - if recurse is not set on 'a', all of it descendents should not be allowed
> > to use recurse flag
> > - if recurse is not set on 'a', it should not be run
>
> If 'a' can be overridden then I don't agree with the first suggestion.
> Which means you are suggesting we stop at the last group with the
> recursive flag set. That is fine too.
>
> >
> > imo the former is cleaner and avoids issues with detach in the middle
> >
> >> 3. $MNT/a/b/c is created
> >>
> >> i. 'c' inherits the settings of 'b' (override is allowed, recursive flag
> >> is set)
> >>
> >> ii. Process in 'c' opens a socket. No program from 'c' exists, so
> >> nothing is run. Recursion flag is set, so program from 'b' is run, then
> >> program from 'a' is run. Stop (recursive flag not set on 'a').
> >
> > also doesn't make sense to me. Both 'b' and 'c' were attached as
> > override+recurse while 'a' as non-recurse why would it run?
> > The owner of 'a' attached it as override in the first place,
> > so it assumed that if descendent wants to override it it can
> > and the prog 'a' won't be running.
>
> same argument as above - the question is where do we stop. My suggestion
> and implementation is stopping at the first group without the flag.
>
> As stated all along, descendant groups inherit programs of the parent
> marked recurse - not by copying them into the group but by recursion.
>
>
> >
> >> iii. Attaching a non-recursive program to 'c' fails because it inherited
> >> the recursive flag from 'b' and that can not be reset by a descendant.
> >
> > that part makes sense
> >
> >> iv. Recursive program is attached to 'c'
> >>
> >> v. Process in 'c' opens a socket. Program attached to 'c' is run, then
> >> the program from 'b' and the program from 'a'. Stop.
> >>
> >> etc.
> >>
> >> To consider what happens on doubling back and changing programs in the
> >> hierarchy, start with $MNT/a/b/c from 3 above (non-recursive on 'a',
> >> recursive on 'b' and recursive on 'c') for each of the following cases:
> >>
> >> 1. Program attached to 'b' is detached, recursive flag is reset in the
> >> request. Attempt fails EINVAL because the recursion flag has to be set.
> >
> > didn't get this point. you mean 'detach' will fail?
>
> Yes, because it tried to reset the flag in the process.
>
> This is something we can make user friendly - the detach succeeds, but
> the recurse flag is ignored and the recurse flag in the group is not
> reset unless it is the base group with the recurse flag (i.e., the
> parent is marked non-recurse).
if we don't reset group flags to default it will be even more difficult
for users to use, since attach with recursive flag + immediate detach sets
some internal flag on the cgroup and user space has no way of
either querying this flag or deleting it.
> >
> >> 2. Program attached to 'b' is detached, recursive flag is set. Allowed.
> >
> > meaing that detach from 'b' has to pass recurse flag to be detached?
> > That's also odd.
> > imo detach should always succeed and the process doing detach
> > shouldn't need to know what flags were used in attach.
>
> Then, we agree to make it user friendly and handle resetting the recurse
> flag automatically.
in that sense yes attach/delete pair should be side-effect free.
> >> Process in 'b' opens a socket. No program attached to 'b' so no program
> >> is run. Recursive flag is set to program from 'a' is run. Stop.
> >>
> >> We should allow the recursive flag to be reset if the parent is not
> >> recursive allowing an unwind of settings applied. I'll add that change.
> >
> > I don't get this part.
> > Anyway looking forward to the next patch set with tests and comments like above.
>
> Per above discussion, you don't want 'a' run since it is not marked
> recurse. My last sentence is the user friendly part in resetting the
> flag in the cgroup.
I'm still not grasping fully the semantics of what you're proposing.
You keep saying that override and recurse flags are indepedent, but
the more we talk the more it's clear that there is a complicated
relationship between them. Like no_override overrules everything, etc.
I'm looking for the simplest to use logic. Not implementation.
Implementation can be complex, but uapi should be as simple to
explain and as simple to understand as possible.
So how about allowing recurse+overide combination only?
All descendents must be recurse+override too and
no program allowed to be set on parent unless it's recurse+override
as well. Then detach anywhere is simple, since all programs in
such chain are always recurse+override.
^ permalink raw reply
* Re: Permissions for eBPF objects
From: Alexei Starovoitov @ 2017-08-29 1:15 UTC (permalink / raw)
To: Chenbo Feng
Cc: Daniel Borkmann, Jeffrey Vander Stoep, Stephen Smalley, netdev,
SELinux, Mickaël Salaün
In-Reply-To: <CAMOXUJ=kiZDEpuBfys0Me4o8wqSymCz+Eu_qdQdOH5+Czzfj8g@mail.gmail.com>
On Mon, Aug 28, 2017 at 05:47:19PM -0700, Chenbo Feng wrote:
> On Fri, Aug 25, 2017 at 6:03 PM, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> > On Fri, Aug 25, 2017 at 10:07:27PM +0200, Daniel Borkmann wrote:
> >> On 08/25/2017 09:52 PM, Chenbo Feng wrote:
> >> > On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep <jeffv@google.com> wrote:
> >> > > On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >> > > > On Fri, 2017-08-25 at 11:01 -0700, Jeffrey Vander Stoep via Selinux
> >> > > > wrote:
> >> > > > > I’d like to get your thoughts on adding LSM permission checks on BPF
> >> > > > > objects.
> >
> > before reinventing the wheel please take a look at landlock work.
> > Everything that was discussed in this thread is covered by it.
> > The patches have been in development for more than a year and most of the early
> > issues have been resolved.
> > It will be presented again during security summit in LA in September.
> >
> I am not very familiar with landlock lsm, isn't this module also
> depend on the lsm hooks to do
> the landlock check? If so then adding lsm hooks for eBPF object seems
> not conflict with the
> work on progress.
I see. I got it the other way around. What lsm checks are you proposing?
and why unprivileged_bpf_disabled is not enough?
you want to allow unpriv only for specific user(s) ?
^ 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