Re: [RFC PATCH] cgroup, netclassid: add a preemption point to write_classid

2018-10-23 Thread Tejun Heo
On Thu, Oct 18, 2018 at 10:56:17AM +0200, Michal Hocko wrote: > From: Michal Hocko > > We have seen a customer complaining about soft lockups on !PREEMPT > kernel config with 4.4 based kernel ... > If a cgroup has many tasks with many open file descriptors then we would > end up in a large loop

Re: Documentation: Add HOWTO Korean translation into BPF and XDP Reference Guide.

2018-09-24 Thread Tejun Heo
Hello, First of all, thanks a lot for the contribution. It'd be great to have a korean translation. I glanced over it and there often were areas where it was a bit challenging to understand without going back to the english version. I think this would still be helpful and a step in the right

Re: [PATCH bpf-next 1/4] bpf: Introduce bpf_skb_ancestor_cgroup_id helper

2018-08-13 Thread Tejun Heo
Hello, Andrey. On Fri, Aug 10, 2018 at 10:35:23PM -0700, Andrey Ignatov wrote: > +static inline struct cgroup *cgroup_ancestor(struct cgroup *cgrp, > + int ancestor_level) > +{ > + struct cgroup *ptr; > + > + if (cgrp->level < ancestor_level) > +

Re: [PATCH] percpu: add a schedule point in pcpu_balance_workfn()

2018-02-23 Thread Tejun Heo
On Fri, Feb 23, 2018 at 08:12:42AM -0800, Eric Dumazet wrote: > From: Eric Dumazet > > When a large BPF percpu map is destroyed, I have seen > pcpu_balance_workfn() holding cpu for hundreds of milliseconds. > > On KASAN config and 112 hyperthreads, average time to destroy a

Re: lost connection to test machine (4)

2018-02-12 Thread Tejun Heo
On Mon, Feb 12, 2018 at 09:03:25AM -0800, Tejun Heo wrote: > Hello, Daniel. > > On Mon, Feb 12, 2018 at 06:00:13PM +0100, Daniel Borkmann wrote: > > [ +Dennis, +Tejun ] > > > > Looks like we're stuck in percpu allocator with key/value size of 4 bytes > >

Re: lost connection to test machine (4)

2018-02-12 Thread Tejun Heo
Hello, Daniel. On Mon, Feb 12, 2018 at 06:00:13PM +0100, Daniel Borkmann wrote: > [ +Dennis, +Tejun ] > > Looks like we're stuck in percpu allocator with key/value size of 4 bytes > each and large number of entries (max_entries) in the reproducer in above > link. > > Could we have some

Re: [PATCH net 0/3] Fix for BPF devmap percpu allocation splat

2017-10-21 Thread Tejun Heo
Hello, On Wed, Oct 18, 2017 at 04:45:08PM -0500, Dennis Zhou wrote: > I'm not sure I see the reason we can't match the minimum allocation size > with the unit size? It seems weird to arbitrate the maximum allocation > size given a lower bound on the unit size. idk, it can be weird for the

Re: [PATCH net 0/3] Fix for BPF devmap percpu allocation splat

2017-10-18 Thread Tejun Heo
Hello, Daniel. (cc'ing Dennis) On Tue, Oct 17, 2017 at 04:55:51PM +0200, Daniel Borkmann wrote: > The set fixes a splat in devmap percpu allocation when we alloc > the flush bitmap. Patch 1 is a prerequisite for the fix in patch 2, > patch 1 is rather small, so if this could be routed via -net,

Re: [PATCH net-next] ipv6: avoid zeroing per cpu data again

2017-10-09 Thread Tejun Heo
Dumazet <eduma...@google.com> > Cc: Martin KaFai Lau <ka...@fb.com> > Cc: Tejun Heo <t...@kernel.org> Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: EBPF-triggered WARNING at mm/percpu.c:1361 in v4-14-rc2

2017-09-28 Thread Tejun Heo
Hello, On Thu, Sep 28, 2017 at 03:45:38PM +0100, Mark Rutland wrote: > > Perhaps the pr_warn() should be ratelimited; or could there be an > > option where we only return NULL, not triggering a warn at all (which > > would likely be what callers might do anyway when checking against > >

Re: EBPF-triggered WARNING at mm/percpu.c:1361 in v4-14-rc2

2017-09-28 Thread Tejun Heo
Hello, On Thu, Sep 28, 2017 at 12:27:28PM +0100, Mark Rutland wrote: > diff --git a/mm/percpu.c b/mm/percpu.c > index 59d44d6..f731c45 100644 > --- a/mm/percpu.c > +++ b/mm/percpu.c > @@ -1355,8 +1355,13 @@ static void __percpu *pcpu_alloc(size_t size, size_t > align, bool reserved, >

Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running cgroup sock filters

2017-09-01 Thread Tejun Heo
Hello, Alexei. On Thu, Aug 31, 2017 at 08:27:56PM -0700, Alexei Starovoitov wrote: > > > The 2 flags are completely independent. The existing override logic is > > > unchanged. If a program can not be overridden, then the new recursive > > > flag is irrelevant. > > > > I'm not sure all four

Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running cgroup sock filters

2017-08-31 Thread Tejun Heo
Hello, David, Alexei. Sorry about late reply. On Sun, Aug 27, 2017 at 08:49:23AM -0600, David Ahern wrote: > On 8/25/17 8:49 PM, Alexei Starovoitov wrote: > > > >> + if (prog && curr_recursive && !new_recursive) > >> + /* if a parent has recursive prog attached, only > >> +

Re: Lots of new warnings with gcc-7.1.1

2017-07-15 Thread Tejun Heo
Hello, On Wed, Jul 12, 2017 at 03:31:02PM +0200, Arnd Bergmann wrote: > > We also have about a bazillion > > > > warning: ‘*’ in boolean context, suggest ‘&&’ instead > > > > warnings in drivers/ata/libata-core.c, all due to a single macro that > > uses a pattern that gcc-7.1.1 doesn't like.

Re: [PATCH 02/11] dma-mapping: replace dmam_alloc_noncoherent with dmam_alloc_attrs

2017-06-26 Thread Tejun Heo
On Mon, Jun 26, 2017 at 12:07:30AM -0700, Christoph Hellwig wrote: > Tejun, does this look ok to you? Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [PATCH 01/11] dma-mapping: remove dmam_free_noncoherent

2017-06-26 Thread Tejun Heo
On Mon, Jun 26, 2017 at 12:07:15AM -0700, Christoph Hellwig wrote: > Tejun, does this look ok to you? Sure, Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

[PATCH v4.11] cgroup, net_cls: iterate the fds of only the tasks which are being migrated

2017-03-14 Thread Tejun Heo
d(). Reported-by: David Goode <dgo...@fb.com> Fixes: 3b13758f51de ("cgroups: Allow dynamically changing net_classid") Cc: sta...@vger.kernel.org # v4.4+ Cc: Nina Schiff <nin...@fb.com> Cc: David S. Miller <da...@davemloft.net> Signed-off-by: Tejun Heo <t...@kernel.org&

Re: Fw: [Bug 193911] New: net_prio.ifpriomap is not aware of the network namespace, and discloses all network interface

2017-02-21 Thread Tejun Heo
Hello, On Mon, Feb 13, 2017 at 08:04:57AM +1300, Eric W. Biederman wrote: > > Yeah, the whole thing never considered netns or delegation. Maybe the > > read function itself should probably filter on the namespace of the > > reader? I'm not completely sure whether trying to fix it won't cause >

Re: [PATCH v2 net] bpf: introduce BPF_F_ALLOW_OVERRIDE flag

2017-02-11 Thread Tejun Heo
s: 3007098494be ("cgroup: add support for eBPF programs") > Signed-off-by: Alexei Starovoitov <a...@kernel.org> The cgroup part looks good to me. Please feel free to add Acked-by: Tejun Heo <t...@kernel.org> One question tho. Is there a specific reason to disallow attaching !overr

Re: Fw: [Bug 193911] New: net_prio.ifpriomap is not aware of the network namespace, and discloses all network interface

2017-02-06 Thread Tejun Heo
Hello, On Sun, Feb 05, 2017 at 11:05:36PM -0800, Cong Wang wrote: > > To be more specific, the read operation of net_prio.ifpriomap is handled by > > the > > function read_priomap. Tracing from this function, we can find it invokes > > for_each_netdev_rcu and set the first parameter as the

Re: [PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

2017-01-28 Thread Tejun Heo
Hello, Eric. On Thu, Jan 26, 2017 at 01:45:07PM +1300, Eric W. Biederman wrote: > > Eric, does this sound okay to you? You're the authority on exposing > > things like namespace ids to users. > > *Boggle* Things that run across all network namespaces break any kind > of sense I have about

Re: [PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

2017-01-24 Thread Tejun Heo
Hello, Andy. On Tue, Jan 24, 2017 at 10:54:03AM -0800, Andy Lutomirski wrote: > Tejun, I can see two basic ways that cgroup+bpf delegation could work > down the road. Both depend on unprivileged users being able to load > BPF programs of the correct type, but that's mostly a matter of > auditing

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

2017-01-18 Thread Tejun Heo
Hello, Andy. On Wed, Jan 18, 2017 at 04:18:04PM -0800, Andy Lutomirski wrote: > To map cgroup -> hook, a simple array in each cgroup structure works. > To map (cgroup, netns) -> hook function, the natural approach would be > to have some kind of hash, and that would be slower. This code is >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

2017-01-18 Thread Tejun Heo
Helloo, Andy. On Mon, Jan 16, 2017 at 09:18:36PM -0800, Andy Lutomirski wrote: > Perhaps this is a net feature, though, not a cgroup feature. This > would IMO make a certain amount of sense. Iptables cgroup matches, > for example, logically are an iptables (i.e., net) feature. The Yeap. >

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

2017-01-18 Thread Tejun Heo
Hello, Michal. On Tue, Jan 17, 2017 at 02:58:30PM +0100, Michal Hocko wrote: > This would require using hierarchical cgroup iterators to iterate over It does behave hierarchically. > tasks. As per Andy's testing this doesn't seem to be the case. I haven't That's not what Andy's testing showed.

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

2017-01-15 Thread Tejun Heo
Hello, Sorry about the delay. Some fire fighthing followed the holidays. On Tue, Jan 03, 2017 at 11:25:59AM +0100, Michal Hocko wrote: > > So from what I understand the proposed cgroup is not in fact > > hierarchical at all. > > > > @TJ, I thought you were enforcing all new cgroups to be

Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups

2016-12-09 Thread Tejun Heo
Hello, John. On Thu, Dec 08, 2016 at 09:39:38PM -0800, John Stultz wrote: > So just to clarify the discussion for my purposes and make sure I > understood, per-cgroup CAP rules was not desired, and instead we > should either utilize an existing cap (are there still objections to >

Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups

2016-12-06 Thread Tejun Heo
Hello, On Tue, Dec 06, 2016 at 10:13:53AM -0800, Andy Lutomirski wrote: > > Delegation is an explicit operation and reflected in the ownership of > > the subdirectories and cgroup interface files in them. The > > subhierarchy containment is achieved by requiring the user who's > > trying to

Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups

2016-12-06 Thread Tejun Heo
Hello, On Tue, Dec 06, 2016 at 09:01:17AM -0800, Andy Lutomirski wrote: > How would one be granted the right to move processes around in one's > own subtree? Through expicit delegation - chowning of the directory and cgroup.procs file. > Are you imagining that, if you're in /a/b and you want to

Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups

2016-12-06 Thread Tejun Heo
Hello, Serge. On Mon, Dec 05, 2016 at 08:00:11PM -0600, Serge E. Hallyn wrote: > > I really don't know. The cgroupfs interface is a bit unfortunate in > > that it doesn't really express the constraints. To safely migrate a > > task, ISTM you ought to have some form of privilege over the task >

Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups

2016-12-06 Thread Tejun Heo
Hello, On Mon, Dec 05, 2016 at 04:36:51PM -0800, Andy Lutomirski wrote: > I really don't know. The cgroupfs interface is a bit unfortunate in > that it doesn't really express the constraints. To safely migrate a > task, ISTM you ought to have some form of privilege over the task > *and* some

Re: [PATCH trival -resend 2/2] lib: clean up put_cpu_var usage

2016-09-27 Thread Tejun Heo
On Tue, Sep 27, 2016 at 08:42:42AM -0700, Shaohua Li wrote: > put_cpu_var takes the percpu data, not the data returned from > get_cpu_var. > > This doesn't change the behavior. > > Cc: Tejun Heo <t...@kernel.org> > Signed-off-by: Shaohua Li <s...@fb.com> Ack

Re: [PATCH trival -resend 1/2] bpf: clean up put_cpu_var usage

2016-09-27 Thread Tejun Heo
On Tue, Sep 27, 2016 at 08:42:41AM -0700, Shaohua Li wrote: > put_cpu_var takes the percpu data, not the data returned from > get_cpu_var. > > This doesn't change the behavior. > > Cc: Tejun Heo <t...@kernel.org> > Cc: Alexei Starovoitov <a...@kernel.org> > Si

Re: net/bluetooth: workqueue destruction WARNING in hci_unregister_dev

2016-09-16 Thread Tejun Heo
Hello, On Tue, Sep 13, 2016 at 08:14:40PM +0200, Jiri Slaby wrote: > I assume Dmitry sees the same what I am still seeing, so I reported this > some time ago: > https://lkml.org/lkml/2016/3/21/492 > > This warning is trigerred there and still occurs with "HEAD": > (pwq != wq->dfl_pwq) &&

Re: [PATCH 3/3] mm: memcontrol: consolidate cgroup socket tracking

2016-09-14 Thread Tejun Heo
mory controller callbacks to > match the cgroup core callbacks, then move them to the same place. > > Signed-off-by: Johannes Weiner <han...@cmpxchg.org> For 1-3, Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: net/bluetooth: workqueue destruction WARNING in hci_unregister_dev

2016-09-13 Thread Tejun Heo
Hello, On Sat, Sep 10, 2016 at 11:33:48AM +0200, Dmitry Vyukov wrote: > Hit the WARNING with the patch. It showed "Showing busy workqueues and > worker pools:" after the WARNING, but then no queue info. Was it > already destroyed and removed from the list?... Hmm... It either means that the

Re: net/bluetooth: workqueue destruction WARNING in hci_unregister_dev

2016-09-05 Thread Tejun Heo
ff7 Mon Sep 17 00:00:00 2001 From: Tejun Heo <t...@kernel.org> Date: Mon, 5 Sep 2016 08:54:06 -0400 Subject: [PATCH] workqueue: dump workqueue state on sanity check failures in destroy_workqueue() destroy_workqueue() performs a number of sanity checks to ensure that the workqueue is empty befor

Re: [PATCH v2] cfg80211: Remove deprecated create_singlethread_workqueue

2016-08-31 Thread Tejun Heo
off-by: Bhaktipriya Shridhar <bhaktipriy...@gmail.com> Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [PATCH] net: pegasus: Remove deprecated create_singlethread_workqueue

2016-08-31 Thread Tejun Heo
Bhaktipriya Shridhar <bhaktipriy...@gmail.com> Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [PATCH] bonding: Remove deprecated create_singlethread_workqueue

2016-08-31 Thread Tejun Heo
to > ensure forward progress under memory pressure. > > Signed-off-by: Bhaktipriya Shridhar <bhaktipriy...@gmail.com> Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [net-next RFC v2 4/9] bpf, security: Add Checmate security LSM and BPF program type

2016-08-29 Thread Tejun Heo
Hello, Sargun. On Mon, Aug 29, 2016 at 11:49:07AM -0700, Sargun Dhillon wrote: > It would be a separate hook per LSM hook. Why wouldn't we want a separate bpf > hook per lsm hook? I think if one program has to handle them all, the first > program would be looking up the hook program in a bpf

Re: [net-next RFC v2 4/9] bpf, security: Add Checmate security LSM and BPF program type

2016-08-29 Thread Tejun Heo
Hello, On Mon, Aug 29, 2016 at 04:47:07AM -0700, Sargun Dhillon wrote: > This patch adds a minor LSM, Checmate. Checmate is a flexible programmable, > extensible minor LSM that's coupled with cgroups and BPF. It is designed to > enforce container-specific policies. It is also a cgroupv2

Re: [RFC v2 09/10] landlock: Handle cgroups

2016-08-26 Thread Tejun Heo
Hello, On Fri, Aug 26, 2016 at 07:20:35AM -0700, Andy Lutomirski wrote: > > This is simply the action of changing the owner of cgroup sysfs files to > > allow an unprivileged user to handle them (cf. Documentation/cgroup-v2.txt) > > As far as I can tell, Tejun and systemd both actively

Re: [RFC v2 09/10] landlock: Handle cgroups

2016-08-26 Thread Tejun Heo
Hello, On Thu, Aug 25, 2016 at 04:44:13PM +0200, Mickaël Salaün wrote: > I tested with cgroup-v2 but indeed, it seems a bit different with > cgroup-v1 :) > Does anyone know how to handle both cases? If you wanna do cgroup membership test, just do cgroup v2 membership test. No need to introduce

Re: [RFC PATCH 4/5] net: filter: run cgroup eBPF programs

2016-08-25 Thread Tejun Heo
Hello, Sargun. On Sun, Aug 21, 2016 at 01:14:22PM -0700, Sargun Dhillon wrote: > So, casually looking at this patch, it looks like you're relying on > sock_cgroup_data, which only points to the default hierarchy. If someone uses > net_prio or net_classid, cgroup_sk_alloc_disable is called, and

Re: [PATCH 0/5] Networking cgroup controller

2016-08-25 Thread Tejun Heo
On Thu, Aug 25, 2016 at 12:09:20PM -0400, Tejun Heo wrote: > ebpf approach does have its shortcomings for sure but mending them > seems a lot more manageable and future-proof than going with fixed but > constantly expanding set of operations. e.g. We can add per-cgroup > bpf pr

Re: [PATCH 0/5] Networking cgroup controller

2016-08-25 Thread Tejun Heo
Hello, Mahesh. On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote: > In short most of the associated problems are handled by the > cgroup-infra / APIs while all that need separate solution in > alternatives. Tejun, feels like I'm advocating cgroup approach to you > ;)

Re: [PATCH v2 3/6] bpf: add BPF_PROG_ATTACH and BPF_PROG_DETACH commands

2016-08-24 Thread Tejun Heo
Hello, On Wed, Aug 24, 2016 at 10:24:20PM +0200, Daniel Mack wrote: > SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, > size) > { > union bpf_attr attr = {}; > @@ -888,6 +957,16 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, > uattr, unsigned

Re: [PATCH v2 2/6] cgroup: add support for eBPF programs

2016-08-24 Thread Tejun Heo
Hello, Daniel. On Wed, Aug 24, 2016 at 10:24:19PM +0200, Daniel Mack wrote: > +void cgroup_bpf_free(struct cgroup *cgrp) > +{ > + unsigned int type; > + > + rcu_read_lock(); > + > + for (type = 0; type < __MAX_BPF_ATTACH_TYPE; type++) { > + if (!cgrp->bpf.prog[type]) > +

Re: [PATCH 0/5] Networking cgroup controller

2016-08-24 Thread Tejun Heo
Hello, Anoop. On Wed, Aug 10, 2016 at 05:53:13PM -0700, Anoop Naravaram wrote: > This patchset introduces a cgroup controller for the networking subsystem as a > whole. As of now, this controller will be used for: > > * Limiting the specific ports that a process in a cgroup is allowed to bind >

Re: [RFC PATCH 2/5] cgroup: add bpf_{e,in}gress pointers

2016-08-17 Thread Tejun Heo
Hello, On Wed, Aug 17, 2016 at 10:50:40AM -0700, Alexei Starovoitov wrote: > > +config CGROUP_BPF > > + bool "Enable eBPF programs in cgroups" > > + depends on BPF_SYSCALL > > + help > > + This options allows cgroups to accommodate eBPF programs that > > + can be used for network

Re: [RFC PATCH 3/5] bpf: add BPF_PROG_ATTACH and BPF_PROG_DETACH commands

2016-08-17 Thread Tejun Heo
Hello, again. Just one addition. On Wed, Aug 17, 2016 at 04:35:24PM +0200, Daniel Mack wrote: > created. To bring this more in line with how cgroups usually work, I > guess we should add code to copy over the bpf programs from the ancestor > once a new cgroup is instantiated. Please don't copy

Re: [RFC PATCH 3/5] bpf: add BPF_PROG_ATTACH and BPF_PROG_DETACH commands

2016-08-17 Thread Tejun Heo
Hello, On Wed, Aug 17, 2016 at 04:35:24PM +0200, Daniel Mack wrote: > > Wouldn't it make sense to update the descendants to point to the > > programs directly so that there's no need to traverse the tree on each > > packet? It's more state to maintain but I think it would make total > > sense

Re: [RFC PATCH 4/5] net: filter: run cgroup eBPF programs

2016-08-17 Thread Tejun Heo
On Wed, Aug 17, 2016 at 04:36:02PM +0200, Daniel Mack wrote: > On 08/17/2016 04:23 PM, Tejun Heo wrote: > > On Wed, Aug 17, 2016 at 04:00:47PM +0200, Daniel Mack wrote: > >> @@ -78,6 +116,12 @@ int sk_filter_trim_cap(struct sock *sk, struct sk_buff > >

Re: [RFC PATCH 4/5] net: filter: run cgroup eBPF programs

2016-08-17 Thread Tejun Heo
On Wed, Aug 17, 2016 at 04:00:47PM +0200, Daniel Mack wrote: > @@ -78,6 +116,12 @@ int sk_filter_trim_cap(struct sock *sk, struct sk_buff > *skb, unsigned int cap) > if (skb_pfmemalloc(skb) && !sock_flag(sk, SOCK_MEMALLOC)) > return -ENOMEM; > > +#ifdef CONFIG_CGROUP_BPF > +

Re: [RFC PATCH 3/5] bpf: add BPF_PROG_ATTACH and BPF_PROG_DETACH commands

2016-08-17 Thread Tejun Heo
Hello, Daniel. On Wed, Aug 17, 2016 at 04:00:46PM +0200, Daniel Mack wrote: > The current implementation walks the tree from the passed cgroup up > to the root. If there is any program of the given type installed in > any of the ancestors, the installation is rejected. This is because > programs

Re: [RFC PATCH 2/5] cgroup: add bpf_{e,in}gress pointers

2016-08-17 Thread Tejun Heo
Hello, On Wed, Aug 17, 2016 at 04:00:45PM +0200, Daniel Mack wrote: > @@ -5461,6 +5462,14 @@ static int cgroup_destroy_locked(struct cgroup *cgrp) > for_each_css(css, ssid, cgrp) > kill_css(css); > > +#ifdef CONFIG_CGROUP_BPF > + if (cgrp->bpf_ingress) > +

Re: [PATCH net-next v4 2/3] bpf: Add bpf_current_task_under_cgroup helper

2016-08-12 Thread Tejun Heo
cked-by: Alexei Starovoitov <a...@kernel.org> FWIW, Acked-by: Tejun Heo <t...@kernel.org> > All 3 patches should go via net-next and to avoid conflicts 1/3 can be > in cgroup tree as well (if you think there will be conflicts). > We did that in the past with tip and net-next

Re: [PATCH net-next v4 2/3] bpf: Add bpf_current_task_under_cgroup helper

2016-08-12 Thread Tejun Heo
On Fri, Aug 12, 2016 at 09:21:39AM -0400, Tejun Heo wrote: > On Thu, Aug 11, 2016 at 09:50:48PM -0700, Sargun Dhillon wrote: > > I realize that in_cgroup is more consistent, but under_cgroup makes > > far more sense to me. I think it's more intuitive. > > So, I think

Re: [PATCH net-next v4 2/3] bpf: Add bpf_current_task_under_cgroup helper

2016-08-12 Thread Tejun Heo
Hello, On Fri, Aug 12, 2016 at 09:40:39AM +0200, Daniel Borkmann wrote: > > I actually wish we could rename skb_in_cgroup to skb_under_cgroup. If we > > ever > > introduced a check for absolute membership versus ancestral membership, what > > would we call that? > > That option is, by the way,

Re: [PATCH net-next v4 2/3] bpf: Add bpf_current_task_under_cgroup helper

2016-08-12 Thread Tejun Heo
On Thu, Aug 11, 2016 at 09:50:48PM -0700, Sargun Dhillon wrote: > I realize that in_cgroup is more consistent, but under_cgroup makes > far more sense to me. I think it's more intuitive. So, I think in_cgroup should mean that the object is in that particular cgroup while under_cgroup in the

Re: [PATCH net-next v4 1/3] cgroup: Add task_under_cgroup_hierarchy cgroup inline function to headers

2016-08-12 Thread Tejun Heo
disabled > this always returns true. > > Signed-off-by: Sargun Dhillon <sar...@sargun.me> > Cc: Alexei Starovoitov <a...@kernel.org> > Cc: Daniel Borkmann <dan...@iogearbox.net> > Cc: Tejun Heo <t...@kernel.org> Acked-by: Tejun Heo <t...@kernel.org> Please

Re: [PATCH net-next v3 1/2] bpf: Add bpf_current_task_in_cgroup helper

2016-08-11 Thread Tejun Heo
Hello, Sargun. On Thu, Aug 11, 2016 at 11:51:42AM -0700, Sargun Dhillon wrote: > This adds a bpf helper that's similar to the skb_in_cgroup helper to check > whether the probe is currently executing in the context of a specific > subset of the cgroupsv2 hierarchy. It does this based on membership

Re: [PATCH] net/mlx5_core/pagealloc: Remove deprecated create_singlethread_workqueue

2016-08-01 Thread Tejun Heo
Hello, Leon. On Sun, Jul 31, 2016 at 09:35:13AM +0300, Leon Romanovsky wrote: > > The conversion uses WQ_MEM_RECLAIM, which is standard for all > > workqueues which can stall packet processing if stalled. The > > requirement comes from nfs or block devices over network. > > The title stays

Re: [RFC] net/mlx5_core/en_main: Remove deprecated create_workqueue

2016-07-29 Thread Tejun Heo
Hello, On Fri, Jul 29, 2016 at 01:30:05AM +0300, Saeed Mahameed wrote: > > Are the workitems being used on a memory reclaim path? > > do you mean they need to allocate memory ? It's a bit convoluted. A workqueue needs WQ_MEM_RECLAIM flag to be guaranteed forward progress under memory pressure,

Re: [PATCH] net/mlx5_core/pagealloc: Remove deprecated create_singlethread_workqueue

2016-07-29 Thread Tejun Heo
Hello, On Thu, Jul 28, 2016 at 12:37:35PM +0300, Leon Romanovsky wrote: > Did you test this patch? Did you notice the memory reclaim path nature > of this work? The conversion uses WQ_MEM_RECLAIM, which is standard for all workqueues which can stall packet processing if stalled. The requirement

Re: [PATCH] caif-hsi: Remove deprecated create_singlethread_workqueue

2016-07-25 Thread Tejun Heo
() itself calls drain_workqueue() which flushes > repeatedly till the workqueue becomes empty. > > Signed-off-by: Bhaktipriya Shridhar <bhaktipriy...@gmail.com> Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [PATCH net-next v2 2/4] cgroup: bpf: Add BPF_MAP_TYPE_CGROUP_ARRAY

2016-06-23 Thread Tejun Heo
Hello, On Thu, Jun 23, 2016 at 11:42:31AM +0200, Daniel Borkmann wrote: > I presume it's a valid use case to pin a cgroup map, put fds into it and > remove the pinned file expecting to continue to match on it, right? So > lifetime is really until last prog using a cgroup map somewhere gets

Re: [PATCH net-next v2 1/4] cgroup: Add cgroup_get_from_fd

2016-06-23 Thread Tejun Heo
.com> > Cc: Alexei Starovoitov <a...@fb.com> > Cc: Daniel Borkmann <dan...@iogearbox.net> > Cc: Tejun Heo <t...@kernel.org> Acked-by: Tejun Heo <t...@kernel.org> Please feel free to route this patch with the rest of the series. If it's preferable to apply

Re: [PATCH -next 1/4] cgroup: Add cgroup_get_from_fd

2016-06-22 Thread Tejun Heo
Hello, Martin. On Tue, Jun 21, 2016 at 05:23:19PM -0700, Martin KaFai Lau wrote: > @@ -6205,6 +6206,31 @@ struct cgroup *cgroup_get_from_path(const char *path) > } > EXPORT_SYMBOL_GPL(cgroup_get_from_path); Proper function comment would be nice. > +struct cgroup *cgroup_get_from_fd(int fd) >

Re: [PATCH net-next] nfnetlink_queue: enable PID info retrieval

2016-06-15 Thread Tejun Heo
Hello, On Fri, Jun 10, 2016 at 08:40:34AM +0200, Daniel Wagner wrote: > > [ Cc'ing John, Daniel, et al ] > > > > Btw, while I just looked at scm_detach_fds(), I think commits ... > > > > * 48a87cc26c13 ("net: netprio: fd passed in SCM_RIGHTS datagram not set > > correctly") > > * d84295067fc7

Re: [PATCH] libertas_tf: Remove create_workqueue

2016-06-11 Thread Tejun Heo
Bhaktipriya Shridhar <bhaktipriy...@gmail.com> Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [PATCH] net: wireless: marvell: libertas: Remove create_workqueue

2016-06-05 Thread Tejun Heo
e calls to flush_workqueue() before > destroy_workqueue() have been dropped. > > Signed-off-by: Bhaktipriya Shridhar <bhaktipriy...@gmail.com> Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [PATCH] net: ethernet: cavium: liquidio: response_manager: Remove create_workqueue

2016-06-05 Thread Tejun Heo
f calls > drain_workqueue() which flushes repeatedly till the workqueue > becomes empty. Hence the call to flush_workqueue() has been dropped. > > Signed-off-by: Bhaktipriya Shridhar <bhaktipriy...@gmail.com> As with the previous patch, the subject tag doesn't need to contain the fu

Re: [PATCH] net: ethernet: cavium: liquidio: request_manager: Remove create_workqueue

2016-06-05 Thread Tejun Heo
_db"); > + oct->check_db_wq[iq_no].wq = alloc_workqueue("check_iq_db", > + WQ_MEM_RECLAIM, > + 0); Why the new line between WQ_MEM_RECLAIM and 0? Except for the subj ta

Re: [PATCH] net: fjes: fjes_main: Remove create_workqueue

2016-06-02 Thread Tejun Heo
On Thu, Jun 02, 2016 at 03:00:57PM +0530, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > The workqueue adapter->txrx_wq has workitem > >raise_intr_rxdata_task per adapter. Extended Socket Network > Device is shared memory based, so someone's transmission

Re: [PATCH] net: ethernet: wiznet: Remove create_workqueue

2016-06-01 Thread Tejun Heo
atedly till the workqueue > becomes empty. Hence the call to flush_workqueue() has been dropped. > > Signed-off-by: Bhaktipriya Shridhar <bhaktipriy...@gmail.com> Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [PATCH] net: ethernet: intel: fm10k: Remove create_workqueue

2016-06-01 Thread Tejun Heo
gt; > Signed-off-by: Bhaktipriya Shridhar <bhaktipriy...@gmail.com> Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [PATCH] net: ethernet: intel: fm10k: Remove create_workqueue

2016-06-01 Thread Tejun Heo
gt; > Signed-off-by: Bhaktipriya Shridhar <bhaktipriy...@gmail.com> Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [PATCH percpu/for-4.7-fixes 1/2] percpu: fix synchronization between chunk->map_extend_work and chunk destruction

2016-05-26 Thread Tejun Heo
Hello, On Thu, May 26, 2016 at 11:19:06AM +0200, Vlastimil Babka wrote: > > if (is_atomic) { > > margin = 3; > > > > if (chunk->map_alloc < > > - chunk->map_used + PCPU_ATOMIC_MAP_MARGIN_LOW && > > - pcpu_async_enabled) > > -

[PATCH percpu/for-4.7-fixes 2/2] percpu: fix synchronization between synchronous map extension and chunk destruction

2016-05-25 Thread Tejun Heo
allocations under pcpu_alloc_mutex to synchronize against pcpu_balance_work which is responsible for async chunk management including destruction. Signed-off-by: Tejun Heo <t...@kernel.org> Reported-and-tested-by: Alexei Starovoitov <alexei.starovoi...@gmail.com> Reported-by: Vlastimi

[PATCH percpu/for-4.7-fixes 1/2] percpu: fix synchronization between chunk->map_extend_work and chunk destruction

2016-05-25 Thread Tejun Heo
flight. This patch fixes the bug by rolling async map extension operations into pcpu_balance_work. Signed-off-by: Tejun Heo <t...@kernel.org> Reported-and-tested-by: Alexei Starovoitov <alexei.starovoi...@gmail.com> Reported-by: Vlastimil Babka <vba...@suse.cz> Reported-b

Re: bpf: use-after-free in array_map_alloc

2016-05-24 Thread Tejun Heo
Hello, Alexei, can you please verify this patch? Map extension got rolled into balance work so that there's no sync issues between the two async operations. Thanks. Index: work/mm/percpu.c === --- work.orig/mm/percpu.c +++

Re: bpf: use-after-free in array_map_alloc

2016-05-24 Thread Tejun Heo
Hello, On Tue, May 24, 2016 at 10:40:54AM +0200, Vlastimil Babka wrote: > [+CC Marco who reported the CVE, forgot that earlier] > > On 05/23/2016 11:35 PM, Tejun Heo wrote: > > Hello, > > > > Can you please test whether this patch resolves the issue? While &g

Re: bpf: use-after-free in array_map_alloc

2016-05-23 Thread Tejun Heo
Hello, Can you please test whether this patch resolves the issue? While adding support for atomic allocations, I reduced alloc_mutex covered region too much. Thanks. diff --git a/mm/percpu.c b/mm/percpu.c index 0c59684..bd2df70 100644 --- a/mm/percpu.c +++ b/mm/percpu.c @@ -162,7 +162,7 @@

Re: [PATCH] qlge: Replace create_singlethread_workqueue with alloc_ordered_workqueue

2016-04-14 Thread Tejun Heo
Hello, Manish. On Thu, Apr 14, 2016 at 07:25:15AM +, Manish Chopra wrote: > Just want to confirm that __WQ_LEGACY flag is not necessary here as this is > removed > with this change ? Yeah, that should be fine. That only affects locking dependency tracking which can fire spuriously due to

Re: [PATCH] qlge: Replace create_singlethread_workqueue with alloc_ordered_workqueue

2016-04-13 Thread Tejun Heo
. > > Signed-off-by: Amitoj Kaur Chawla <amitoj1...@gmail.com> > Acked-by: Tejun Heo <t...@kernel.org> Ping? -- tejun

Re: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers

2016-03-20 Thread Tejun Heo
Hello, On Fri, Mar 18, 2016 at 05:24:05PM -0400, J. Bruce Fields wrote: > > But does that actually work? It's pointless to add WQ_MEM_RECLAIM to > > workqueues unless all other things are also guaranteed to make forward > > progress regardless of memory pressure. > > It's supposed to work. > >

Re: net/bluetooth: workqueue destruction WARNING in hci_unregister_dev

2016-03-20 Thread Tejun Heo
Hello, Jiri. On Thu, Mar 17, 2016 at 01:00:13PM +0100, Jiri Slaby wrote: > >> I have not done that yet, but today, I see: > >> destroy_workqueue: name='req_hci0' pwq=88002f590300 > >> wq->dfl_pwq=88002f591e00 pwq->refcnt=2 pwq->nr_active=0 delayed_works: > >>pwq 12: cpus=0-1 node=0

Re: [PATCH] iwlwifi: dvm: convert create_singlethread_workqueue() to alloc_workqueue()

2016-03-19 Thread Tejun Heo
Hello, On Thu, Mar 17, 2016 at 01:43:22PM +0100, Johannes Berg wrote: > On Thu, 2016-03-17 at 20:37 +0800, Eva Rachel Retuya wrote: > > Use alloc_workqueue() to allocate the workqueue instead of > > create_singlethread_workqueue() since the latter is deprecated and is > > scheduled for removal. >

[RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers

2016-03-19 Thread Tejun Heo
Hello, Years ago, workqueue got reimplemented to use common worker pools across different workqueues and a new set of more expressive workqueue creation APIs, alloc_*workqueue() were introduced. The old create_*workqueue() became simple wrappers around alloc_*workqueue() with the most

Re: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers

2016-03-19 Thread Tejun Heo
Hello, Jeff. On Thu, Mar 17, 2016 at 09:32:16PM -0400, Jeff Layton wrote: > > * Are network devices expected to be able to serve as a part of > > storage stack which is depended upon for memory reclamation? > > I think they should be. Cached NFS pages can consume a lot of memory, > and

Re: [Outreachy kernel] [PATCH v2] iwlwifi: dvm: use alloc_ordered_workqueue()

2016-03-19 Thread Tejun Heo
think "not depended during memory reclaim" probalby is a better way to describe it. > Signed-off-by: Eva Rachel Retuya <eraret...@gmail.com> But other than that, Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: net/bluetooth: workqueue destruction WARNING in hci_unregister_dev

2016-03-11 Thread Tejun Heo
Hello, Sorry about the delay. On Thu, Mar 03, 2016 at 10:12:01AM +0100, Jiri Slaby wrote: > On 03/02/2016, 04:45 PM, Tejun Heo wrote: > > On Fri, Feb 19, 2016 at 01:10:00PM +0100, Jiri Slaby wrote: > >>> 1. didn't help, the problem persists. So I haven't applied th

Re: net/bluetooth: workqueue destruction WARNING in hci_unregister_dev

2016-03-02 Thread Tejun Heo
Hello, Jiri. On Fri, Feb 19, 2016 at 01:10:00PM +0100, Jiri Slaby wrote: > > 1. didn't help, the problem persists. So I haven't applied the patch from 2. > > FWIW I dumped more info about the wq: > wq->name='hci0' pwq=8800390d7600 wq->dfl_pwq=8800390d5200 > pwq->refcnt=2 pwq->nr_active=0

Re: [RFC][PATCH] tags: Fix DEFINE_PER_CPU expansions

2016-03-01 Thread Tejun Heo
//sourceforge.net/p/ctags/feature-requests/38/ That's unfortunate. Ah well, it's only several spots and isn't a big deal one way or the other. Occasional >80 lines are fine by me. Please feel free to add Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [RFC][PATCH] tags: Fix DEFINE_PER_CPU expansions

2016-03-01 Thread Tejun Heo
Hello, Peter. On Tue, Mar 01, 2016 at 11:26:25AM +0100, Peter Zijlstra wrote: > > $ make tags > GEN tags > ctags: Warning: drivers/acpi/processor_idle.c:64: null expansion of name > pattern "\1" > ctags: Warning: drivers/xen/events/events_2l.c:41: null expansion of name > pattern "\1" >

Re: net/bluetooth: workqueue destruction WARNING in hci_unregister_dev

2016-02-18 Thread Tejun Heo
Hello, Can you please do the followings? 1. Remove WQ_MEM_RECLAIM from the affected workqueue and see whether the problem is reproducible. WQ_MEM_RECLAIM on anything bluetooth doesn't make sense btw. Why is it there? 2. If WQ_MEM_RECLAIM makes the issue go away, see whether the attached

Re: [PATCH net-next] core: remove unneded headers for net cgroup controllers.

2016-02-15 Thread Tejun Heo
ami Rosen <rami.ro...@intel.com> Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [PATCH 8/8] netfilter: implement xt_cgroup cgroup2 path match

2016-02-12 Thread Tejun Heo
Hello, On Fri, Feb 12, 2016 at 01:10:18AM +0100, Alban Crequy wrote: > Is there any plans to implement a similar cgroup2 path match in a > cgroup classifier in tc? That'd be great. I wanted to but couldn't figure out the heads and tails after staring at the code for half an hour. > I wonder if

  1   2   3   >