Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next merge of the userns tree got a conflict in:
>
> kernel/bpf/task_iter.c
>
> between commit:
>
> 91b2db27d3ff ("bpf: Simplify task_file_seq_get_next()")
>
> from the bpf-next tree and commit:
>
> edc52f17257a ("bpf/task_iter: In task_f
.301109] move
> /devices/pci:00/:00:02.0/:01:00.1/net/enp1s0f1 (net)
> KERNEL[625.301138] move
> /devices/pci:00/:00:02.0/:01:00.1/net/eth1 (net)
> KERNEL[655.333272] remove
> /devices/pci:00/:00:02.0/:01:00.1/net/eth1 (net)
Acked-by: "Er
Christian Brauner writes:
> ---
> lib/kobject_uevent.c | 140 ++-
> 1 file changed, 99 insertions(+), 41 deletions(-)
>
> diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
> index c3cb110f663b..d8ce5e6d83af 100644
> --- a/lib/kobject_uevent.c
> +++ b
Christian Brauner writes:
> This patch adds alloc_uevent_skb() in preparation for follow up patches.
>
> Signed-off-by: Christian Brauner
> ---
> lib/kobject_uevent.c | 39 ++-
> 1 file changed, 26 insertions(+), 13 deletions(-)
>
> diff --git a/lib/kobject_u
> + /* fix credentials */
> + if (owning_user_ns != &init_user_ns) {
> + struct netlink_skb_parms *parms = &NETLINK_CB(skb);
> + kuid_t root_uid;
> + kgid_t root_gid;
> +
> + /* fix uid */
> + root_uid = make_kuid(owning_user_ns,
:01:00.1/net/eth1 (net)
>
> Thanks!
> Christian
>
> [1]: https://lkml.org/lkml/2018/4/4/739
> [2]: https://lkml.org/lkml/2018/4/26/767
> [3]: https://lkml.org/lkml/2018/4/26/738
Again ovearall ack. One last nit that might be worth addressing.
Acked-by: "Eric W. Biederman"
Eric
:01:00.1/net/eth1 (net)
>
> Thanks!
> Christian
>
> [1]: https://lkml.org/lkml/2018/4/4/739
> [2]: https://lkml.org/lkml/2018/4/26/767
> [3]: https://lkml.org/lkml/2018/4/26/738
Acked-by: "Eric W. Biederman"
>
> Christian Brauner (2):
> uevent: add
Rahul Lakkireddy writes:
> v6:
> - Reworked device dump elf note name to contain vendor identifier.
> - Added vmcoredd_header that precedes actual dump in the Elf Note.
> - Device dump's name is moved inside vmcoredd_header.
> - Added "CHELSIO" string as vendor identifier in the Elf Note name
>
Rahul Lakkireddy writes:
> The sequence of actions done by device drivers to append their device
> specific hardware/firmware logs to /proc/vmcore are as follows:
Except for the missing include that the kbuild test robot caught
I am not seeing a problems.
Acked-by: "Eric W. Biede
Christoph Hellwig writes:
> The shole seq_file sequence already operates under a single RCU lock pair,
> so move the pid namespace lookup into it, and stop grabbing a reference
> and remove all kinds of boilerplate code.
This is wrong.
Move task_active_pid_ns(current) from open to seq_start act
Christoph Hellwig writes:
> Use remove_proc_subtree to remove the whole subtree on cleanup, and
> unwind the registration loop into individual calls. Switch to use
> proc_create_seq where applicable.
Can you please explain why you are removing the error handling when
you are unwinding the regis
REG|S_IRUGO so I don't think the write support was ever finished.
That cap_capable in the write method looks down right scary/buggy.
Acked-by: "Eric W. Biederman"
Eric
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/ide/ide-proc.c | 46 --
Rahul Lakkireddy writes:
> On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
>> Hi Rahul,
>> On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
>> > On production servers running variety of workloads over time, kernel
>> > panic can happen sporadically after days or even months
Christian Brauner writes:
> Now that it's possible to have a different set of uevents in different
> network namespaces, per-network namespace uevent sequence numbers are
> introduced. This increases performance as locking is now restricted to the
> network namespace affected by the uevent rather
Rahul Lakkireddy writes:
> On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave Young wrote:
>> On 04/18/18 at 06:01pm, Rahul Lakkireddy wrote:
>> > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
>> > > Hi Rahul,
>> > > On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
Rahul Lakkireddy writes:
> On Thursday, April 04/19/18, 2018 at 20:23:37 +0530, Eric W. Biederman wrote:
>> Rahul Lakkireddy writes:
>>
>> > On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave Young wrote:
>> >> On 04/18/18 at 06:01pm, Rahul Lakkiredd
Christian Brauner writes:
> Now that it's possible to have a different set of uevents in different
> network namespaces, per-network namespace uevent sequence numbers are
> introduced. This increases performance as locking is now restricted to the
> network namespace affected by the uevent rather
his
> means if the user namespace of a given task is unshared but the network
> namespace is kept and is owned by the initial user namespace a listener
> that is opening the uevent socket in that network namespace can still
> listen to uevents.
>
> [1]: https://lkml.org/lkml/2018
Bah. This code is obviously correct and probably wrong.
How do we deliver uevents for network devices that are outside of the
initial user namespace? The kernel still needs to deliver those.
The logic to figure out which network namespace a device needs to be
delivered to is is present in kobj
Christian Brauner writes:
> On Tue, Apr 24, 2018 at 04:52:20PM -0500, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > Now that it's possible to have a different set of uevents in different
>> > network namespaces, per-network namespace ueven
Christian Brauner writes:
> On Wed, Apr 25, 2018, 00:41 Eric W. Biederman wrote:
>
> Bah. This code is obviously correct and probably wrong.
>
> How do we deliver uevents for network devices that are outside of the
> initial user namespace? The kernel still needs to deliv
Christian Brauner writes:
> On Tue, Apr 24, 2018 at 06:00:35PM -0500, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > On Wed, Apr 25, 2018, 00:41 Eric W. Biederman
>> > wrote:
>> >
>> > Bah. This code is obviously corre
Christian Brauner writes:
> On Thu, Apr 26, 2018 at 11:47:19AM -0500, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > On Tue, Apr 24, 2018 at 06:00:35PM -0500, Eric W. Biederman wrote:
>> >> Christian Brauner writes:
>> >>
>&
Christian Brauner writes:
> On Thu, Apr 26, 2018 at 12:10:30PM -0500, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > On Thu, Apr 26, 2018 at 11:47:19AM -0500, Eric W. Biederman wrote:
>> >> Christian Brauner writes:
>> >>
>&g
While looking this over I found a bug in the way elf notes are being composed.
Rahul Lakkireddy writes:
> diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> index a45f0af22a60..7395462d2f86 100644
> --- a/fs/proc/vmcore.c
> +++ b/fs/proc/vmcore.c
> @@ -1145,6 +1150,132 @@ static int __init parse
Liran Alon writes:
> - shmulik.ladk...@gmail.com wrote:
>
>> On Thu, 15 Mar 2018 09:35:51 -0700 (PDT) Liran Alon
>> wrote:
>> > - shmulik.ladk...@gmail.com wrote:
>> >
>> > > On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon
>> > > wrote:
>> > > >
>> > > > I still think that defau
Ben Greear writes:
> On 03/20/2018 09:44 AM, Liran Alon wrote:
>>
>>
>> On 20/03/18 18:24, ebied...@xmission.com wrote:
>>>
>>> I don't believe the current behavior is a bug.
>>>
>>> I looked through the history. Basically skb_scrub_packet
>>> started out as the scrubbing needed for crossing net
Rahul Lakkireddy writes:
> On production servers running variety of workloads over time, kernel
> panic can happen sporadically after days or even months. It is
> important to collect as much debug logs as possible to root cause
> and fix the problem, that may not be easy to reproduce. Snapshot
Thadeu Lima de Souza Cascardo writes:
> On Sat, Mar 24, 2018 at 04:26:34PM +0530, Rahul Lakkireddy wrote:
>> Register callback to collect hardware/firmware dumps in second kernel
>> before hardware/firmware is initialized. The dumps for each device
>> will be available under /sys/kernel/crashdd/
Rahul Lakkireddy writes:
> On Saturday, March 03/24/18, 2018 at 20:50:52 +0530, Eric W. Biederman wrote:
>>
>> Rahul Lakkireddy writes:
>>
>> > On production servers running variety of workloads over time, kernel
>> > panic can happen sporad
Rahul Lakkireddy writes:
> On Tuesday, March 03/27/18, 2018 at 18:47:34 +0530, Eric W. Biederman wrote:
>> Rahul Lakkireddy writes:
>>
>> > On Saturday, March 03/24/18, 2018 at 20:50:52 +0530, Eric W. Biederman
>> > wrote:
>> >>
>> >&g
Richard Guy Briggs writes:
> A namespace cannot directly migrate from one container to another but
> could be assigned to a newly spawned container. A namespace can be
> moved from one container to another indirectly by having that namespace
> used in a second process in another container and th
Aleksa Sarai writes:
> Hi all,
>
> At the moment, cn_proc is not usable by containers or container runtimes. In
> addition, all connectors have an odd relationship with init_net (for example,
> /proc/net/connectors only exists in init_net). There are two main use-cases
> that
> would be perfect
Rahul Lakkireddy writes:
> On Friday, March 03/30/18, 2018 at 16:09:07 +0530, Jiri Pirko wrote:
>> Sat, Mar 24, 2018 at 11:56:33AM CET, rahul.lakkire...@chelsio.com wrote:
>> >Add a new module crashdd that exports the /sys/kernel/crashdd/
>> >directory in second kernel, containing collected hardw
Tetsuo Handa writes:
> syzbot wrote:
>> > On Sun, Mar 4, 2018 at 6:57 AM, Tetsuo Handa
>> > wrote:
>> >> Switching from mm to fsdevel, for this report says that put_net(net) in
>> >> rpc_kill_sb() made net->count < 0 when mount_ns() failed due to
>> >> register_shrinker() failure.
>>
>> >> Rele
Al Viro writes:
> On Mon, Apr 02, 2018 at 10:59:34PM +0100, Al Viro wrote:
>
>> FWIW, I'm going through the ->kill_sb() instances, fixing that sort
>> of bugs (most of them preexisting, but I should've checked instead
>> of assuming that everything's fine). Will push out later tonight.
>
> OK, s
Christian Brauner writes:
> On Wed, Apr 04, 2018 at 09:48:57PM +0200, Christian Brauner wrote:
>> commit 07e98962fa77 ("kobject: Send hotplug events in all network
>> namespaces")
>>
>> enabled sending hotplug events into all network namespaces back in 2010.
>> Over time the set of uevents that
Christian Brauner writes:
> On Thu, Apr 05, 2018 at 05:26:59PM +0300, Kirill Tkhai wrote:
>> On 05.04.2018 17:07, Christian Brauner wrote:
>> > On Thu, Apr 05, 2018 at 04:01:03PM +0300, Kirill Tkhai wrote:
>> >> On 04.04.2018 22:48, Christian Brauner wrote:
>> >>> commit 07e98962fa77 ("kobject: S
Christian Brauner writes:
> On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > On Thu, Apr 05, 2018 at 05:26:59PM +0300, Kirill Tkhai wrote:
>> >> On 05.04.2018 17:07, Christian Brauner wrote:
>> >
Christian Brauner writes:
>> At a practical level there should be no receivers. Plus performance
>> issues. At least my memory is that any unprivileged user on the system
>> is allowed to listen to those events.
>
> Any unprivileged user is allowed to listen to uevents if they have
> net_broadc
Christian Brauner writes:
> On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > On Thu, Apr 05, 2018 at 05:26:59PM +0300, Kirill Tkhai wrote:
>> >> On 05.04.2018 17:07, Christian Brauner wrote:
>> >
Christian Brauner writes:
> On Mon, Apr 09, 2018 at 06:21:31PM -0500, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Biederman wrote:
>> >> Christian Brauner writes:
>> >>
Christian Brauner writes:
> On Tue, Apr 10, 2018 at 10:04:46AM -0500, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > On Mon, Apr 09, 2018 at 06:21:31PM -0500, Eric W. Biederman wrote:
>> >> Christian Brauner writes:
>> >>
>&g
Christian Brauner writes:
> On Wed, Apr 11, 2018 at 01:37:18PM -0500, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > On Wed, Apr 11, 2018 at 11:40:14AM -0500, Eric W. Biederman wrote:
>> >> Christian Brauner writes:
>> >> >
Christian Brauner writes:
> On Wed, Apr 11, 2018 at 11:40:14AM -0500, Eric W. Biederman wrote:
>> Christian Brauner writes:
>> > Yeah, agreed.
>> > But I think the patch is not complete. To guarantee that no non-initial
>> > user namespace actually receives u
Rahul Lakkireddy writes:
> On production servers running variety of workloads over time, kernel
> panic can happen sporadically after days or even months. It is
> important to collect as much debug logs as possible to root cause
> and fix the problem, that may not be easy to reproduce. Snapshot o
tel
Signed-off-by: Kirill Tkhai
Fixes: 0c7aecd4bde4 "netns: add rtnl cmd to add and get peer netns ids"
Reviewed-by: Andrey Ryabinin
Reviewed-by: "Eric W. Biederman"
Signed-off-by: Eric W. Biederman
---
net/core/net_namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Kirill Tkhai writes:
> peernet2id_alloc() is racy without rtnl_lock() as atomic_read(&peer->count)
> under net->nsid_lock does not guarantee, peer is alive:
>
> rcu_read_lock()
> peernet2id_alloc()..
> spin_lock_bh(&net->nsid_lock) ..
> atomic_read(&p
ovs_vport_cmd_fill_info(), and this race can't occur. But peernet2id_alloc()
> is generic interface, and better we fix it before someone really starts
> use it in wrong context.
Nacked-by: "Eric W. Biederman"
I have already made a clear objection to the first unnecessary and
Mahesh Bandewar writes:
> From: Mahesh Bandewar
>
> TL;DR version
> -
> Creating a sandbox environment with namespaces is challenging
> considering what these sandboxed processes can engage into. e.g.
> CVE-2017-6074, CVE-2017-7184, CVE-2017-7308 etc. just to name few.
> Current form
ything, or are in any
sense correct for the problem they are trying to fix as the problem
is not clearly described.
In at least one place (mpls) you are patching a fast path. Compile out
or don't load mpls by all means. But it is not acceptable to change the
fast path without even conside
t is treated
like a pointer would seem to provide a defense against the
exfiltration technique of using the value read as an index into
a small array, that user space code can probe aliased cached
lines of, to see which value was dereferenced.
So to this patch in particular.
Nacked-by: "
Dan Williams writes:
> On Mon, Jan 8, 2018 at 7:11 PM, Eric W. Biederman
> wrote:
>> Dan Williams writes:
>>
>>> Static analysis reports that 'index' may be a user controlled value that
>>> is used as a data dependency reading 'rt'
Dan Williams writes:
> On Tue, Jan 9, 2018 at 8:17 AM, Eric W. Biederman
> wrote:
>> Dan Williams writes:
> [..]
>> The user controlled value condition of your patchset implies that you
>> assume indirect branch predictor poisoning is handled in other ways.
&g
Please let's have a description of the problem you are trying to solve.
A proposed solution without talking about the problem space is useless.
Any proposed solution could potentially work.
I know to these exist. There is motivation for your work.
What is the motivation?
What problem are you tr
ira.we...@intel.com writes:
> From: Ira Weiny
>
> This kmap() call is localized to a single thread. To avoid the over
> head of global PKRS updates use the new kmap_thread() call.
Acked-by: "Eric W. Biederman"
>
> Cc: Eric Biederman
> Signed-off-by: Ira Wein
Matt Bennett writes:
> On Thu, 2020-07-02 at 21:10 +0200, Christian Brauner wrote:
>> On Thu, Jul 02, 2020 at 08:17:38AM -0500, Eric W. Biederman wrote:
>> > Matt Bennett writes:
>> >
>> > > Previously the connector functionality could only be u
Matt Bennett writes:
> On Thu, 2020-07-02 at 13:59 -0500, Eric W. Biederman wrote:
>> Matt Bennett writes:
>>
>> > Previously the connector functionality could only be used by processes
>> > running in the
>> > default network namespace.
Wang Long writes:
> Hi，
>
> we encountered a kernel panic as following:
>
> [4394470.273792] general protection fault: [#1] SMP NOPTI
> [4394470.274038] CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Tainted: GW
> - - - 4.18.0-80.el8.x86_64 #1
> [4394470.274477] Hardware name: Sugo
zzoru writes:
> net/core: BUG in copy_net_ns() (net_namespace.c)
I don't understand this failure report at all.
I don't see the connection to copy_net_ns(). And I don't see how the
suggested patch short of covering up a memory stomp could possibly make
a difference.
What am I missing?
> Hel
ecided when the
> network
> * namespace should be
> shut down.
> */
> + refcount_t passive; /* To decided when the
> network
> +
Dmitry Vyukov writes:
> This looks superciliously similar to:
> https://groups.google.com/d/msg/syzkaller-bugs/nFeC8-UG1gg/B6GFaZFrFQAJ
>
> The crux: for the last ~half a year low memory conditions randomly
> corrupt kernel memory with stack overflows.
Does enabling virtually mapped stacks catch
zzoru writes:
> I think that it is exactly same to:
> https://groups.google.com/forum/#!searchin/linux.kernel/cleanup_net$20is$20slow%7Csort:date/linux.kernel/IMJ9OzonDSI/QH86oy1PAQAJ
> Already, patch was maded, but maybe he forgot to push it.
That patch was made to address speed, and lifetime o
Ttttabcd writes:
> IPv6 is rapidly deploying globally. NDP replaces the role of ARP in IPv6 and
> provides mapping from IP address to MAC address.
>
> However, the NDP protocol is as insecure as the ARP protocol, and can be
> easily spoofed, and then the attacker can conduct man-in-the-middle a
Andrew Lunn writes:
> On Wed, Jan 02, 2019 at 10:22:36AM -0500, Donald Sharp wrote:
>> I am only creating a network namespace, but I don't think this changes
>> my core question.
>>
>> Suppose I am running FRR/zebra in the default namespace and I startup
>> a BGP instance in namespace one. BGP
Jamal Hadi Salim writes:
> On 2019-01-05 12:03 a.m., Cong Wang wrote:
>> (Cc'ing Jamal)
>>
>> On Fri, Jan 4, 2019 at 10:11 AM Bartek Kois wrote:
>>>
>>> Basically my current scenario looks like this:
>>> - router with eth0 as WAN and eth1 as LAN with 10-20 vlans,
>>> - around 1000-2000 ip addres
Naja Melan writes:
> hi,
>
> I have been using network namespaces for a while, mostly with good results.
> Recently I ran into a problem where the cgroup mount points are missing for
> software that needs it (runc).
>
> I discovered that ip netns exec creates a mount namespace to bind mount
>
ntroduced
by the last round of changes.
>From 10,000 feet flyover design perspectie and from an ABI perspective
this patchset seems fine.
Acked-by: "Eric W. Biederman"
Eric
Christoph Hellwig writes:
> On Sat, May 05, 2018 at 07:51:18AM -0500, Eric W. Biederman wrote:
>> Christoph Hellwig writes:
>>
>> > Use remove_proc_subtree to remove the whole subtree on cleanup, and
>> > unwind the registration loop into individual calls. S
Christoph Hellwig writes:
> On Sat, May 05, 2018 at 07:37:33AM -0500, Eric W. Biederman wrote:
>> Christoph Hellwig writes:
>>
>> > The shole seq_file sequence already operates under a single RCU lock pair,
>> > so move the pid namespace lookup into it, and s
Christoph Hellwig writes:
> On Thu, May 17, 2018 at 12:28:01AM -0500, Eric W. Biederman wrote:
>> > struct pid_namespace *proc_pid_namespace(struct inode *inode)
>> > {
>> >// maybe warn on for s_magic not on procfs??
>> >return inode->i_sb-
ing merely used to debug the patches.
Only with an audit specific name.
As it is:
Nacked-by: "Eric W. Biederman"
The truth is the containerid name really stinks and is quite confusing
and does not imply that the label applies only to audit. And little
things like this make me extremely uncofortable with it.
Eric
Kees Cook writes:
> On Wed, Nov 1, 2017 at 5:48 AM, Eric W. Biederman
> wrote:
>> Eric Dumazet writes:
>>
>>> On Tue, 2017-10-31 at 09:14 -0700, Kees Cook wrote:
>>>> Some protocols do not correctly wipe the contents of the on-stack
>>>> st
ously meaningless random data was being returned.
Cc: sta...@vger.kernel.org
Fixes: 372f525b495c ("SCTP: Resync with LKSCTP tree.")
History-tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Reported-by: Alexander Potapenko
Tested-by: Alexander Potapenko
Signed-off-by: &qu
Kirill Tkhai writes:
> On 15.11.2017 19:31, Eric W. Biederman wrote:
>> Kirill Tkhai writes:
>>
>>> On 15.11.2017 12:51, Kirill Tkhai wrote:
>>>> On 15.11.2017 06:19, Eric W. Biederman wrote:
>>>>> Kirill Tkhai writes:
>>>>>
&
Kirill Tkhai writes:
> On 15.11.2017 19:29, Eric W. Biederman wrote:
>> Kirill Tkhai writes:
>>
>>> On 15.11.2017 09:25, Eric W. Biederman wrote:
>>>> Kirill Tkhai writes:
>>>>
>>>>> Curently mutex is used to protect pernet
Kirill Tkhai writes:
> Hi,
>
> this is continuation of discussion from here:
>
> https://lkml.org/lkml/2017/11/14/298
>
> The plan has changed a little bit, so I'd be happy to hear
> people's comments, before I dived into all 400+ pernet subsys
> and devices.
>
> The patch set adds pernet sys lis
David Laight writes:
> To make matters even more annoying the functions for holding and
> releasing a namespace are GPL_ONLY :-(
I am going to pick on this by itself for a moment without mentioning
anything else, so as hopefully not to derail what otherwise sounds
like a good technical conversat
"Jason A. Donenfeld" writes:
> Hi,
Adding Herbert Xu who added support for failing notifications in
fcc5a03ac425 ("[NET]: Allow netdev REGISTER/CHANGENAME events to fail").
He might have some insight but 2007 was a long time ago.
All I remember is the ability of NETDEV_CHANGENAME to fail was a
Matt Bennett writes:
> Previously the connector functionality could only be used by processes
> running in the
> default network namespace. This meant that any process that uses the
> connector functionality
> could not operate correctly when run inside a container. This is a draft
> patch ser
Matt Bennett writes:
> Previously the connector functionality could only be used by processes
> running in the
> default network namespace. This meant that any process that uses the
> connector functionality
> could not operate correctly when run inside a container. This is a draft
> patch ser
Al Viro writes:
> On Tue, Sep 10, 2019 at 10:35:09PM +, Yonghong Song wrote:
>>
>> Carlos,
>>
>> Discussed with Eric today for what is the best way to get
>> the device number for a namespace. The following patch seems
>> a reasonable start although Eric would like to see
>> how the helper
Carlos Antonio Neira Bustos writes:
> On Tue, Sep 10, 2019 at 10:35:09PM +, Yonghong Song wrote:
> Thanks a lot Yonghong.
> I'll include this patch when submitting changes for version 11 of
> this patch.
Please see my reply to Al.
Eric
Yonghong Song writes:
> On 9/11/19 9:16 AM, Eric W. Biederman wrote:
>> Al Viro writes:
>>
>>> On Tue, Sep 10, 2019 at 10:35:09PM +, Yonghong Song wrote:
>>>>
>>>> Carlos,
>>>>
>>>> Discussed with Eric today for
Carlos Neira writes:
> Currently bpf_get_current_pid_tgid(), is used to do pid filtering in bcc's
> scripts but this helper returns the pid as seen by the root namespace which is
> fine when a bcc script is not executed inside a container.
> When the process of interest is inside a container, pid
ot;proc: Implement /proc/thread-self to point at the
directory of the current thread")
Fixes: 021ada7dff22 ("procfs: switch /proc/self away from proc_dir_entry")
Fixes: 51f0885e5415 ("vfs,proc: guarantee unique inodes in /proc")
Signed-off-by: "Eric W. Biederman"
-
Cong Wang writes:
> On Tue, Jul 24, 2018 at 8:14 AM David Ahern wrote:
>>
>> On 7/19/18 11:12 AM, Cong Wang wrote:
>> > On Thu, Jul 19, 2018 at 9:16 AM David Ahern wrote:
>> >>
>> >> Chatting with Nikolay about this and he brought up a good corollary - ip
>> >> fragmentation. It really is a sim
David Ahern writes:
> On 7/25/18 6:33 AM, Eric W. Biederman wrote:
>> Cong Wang writes:
>>
>>> On Tue, Jul 24, 2018 at 8:14 AM David Ahern wrote:
>>>>
>>>> On 7/19/18 11:12 AM, Cong Wang wrote:
>>>>> On Thu, Jul 19, 2018 at 9:16 A
David Ahern writes:
> On 7/25/18 11:38 AM, Eric W. Biederman wrote:
>>
>> Absolutely NOT. Global thresholds are exactly correct given the fact
>> you are running on a single kernel.
>>
>> Memory is not free (Even though we are swimming in enough of it memor
"Mahesh Bandewar (महेश बंडेवार)" writes:
> [resend response as earlier one failed because of formatting issues]
>
> On Thu, Nov 9, 2017 at 12:21 PM, Serge E. Hallyn wrote:
>>
>> On Thu, Nov 09, 2017 at 09:55:41AM +0900, Mahesh Bandewar (महेश बंडेवार)
>> wrote:
>> > On Thu, Nov 9, 2017 at 4:02 A
Kirill Tkhai writes:
> On 14.11.2017 21:39, Cong Wang wrote:
>> On Tue, Nov 14, 2017 at 5:53 AM, Kirill Tkhai wrote:
>>> @@ -406,7 +406,7 @@ struct net *copy_net_ns(unsigned long flags,
>>>
>>> get_user_ns(user_ns);
>>>
>>> - rv = mutex_lock_killable(&net_mutex);
>>> + rv = d
Kirill Tkhai writes:
> Curently mutex is used to protect pernet operations list. It makes
> cleanup_net() to execute ->exit methods of the same operations set,
> which was used on the time of ->init, even after net namespace is
> unlinked from net_namespace_list.
>
> But the problem is it's need
Kirill Tkhai writes:
> On 15.11.2017 09:25, Eric W. Biederman wrote:
>> Kirill Tkhai writes:
>>
>>> Curently mutex is used to protect pernet operations list. It makes
>>> cleanup_net() to execute ->exit methods of the same operations set,
>>> whi
Kirill Tkhai writes:
> On 15.11.2017 12:51, Kirill Tkhai wrote:
>> On 15.11.2017 06:19, Eric W. Biederman wrote:
>>> Kirill Tkhai writes:
>>>
>>>> On 14.11.2017 21:39, Cong Wang wrote:
>>>>> On Tue, Nov 14, 2017 at 5:53 AM, Kirill Tkha
"Mahesh Bandewar (महेश बंडेवार)" writes:
> Creation of new network namespace is almost always followed up by
> bringing up the loopback device.
>
> ip netns add foo
> ip -netns foo link set lo up
>
> I'm not sure if there are any consequences of bringing the device UP
> at the cre
Mahesh Bandewar writes:
> From: Mahesh Bandewar
>
> Net stack initialization currently initializes fib-trie after the
> first call to netdevice_notifier() call. It does not cause any problem
> since there are no devices UP at this moment, but trying to bring 'lo'
> UP at initialization would mak
"Mahesh Bandewar (महेश बंडेवार)" writes:
>> I wonder if it is too late to change this since this behavior is probably
>> from the beginning of network namespace. A networkless netns is also
>> useful at least for testing purpose, we do use it as a sandbox.
>>
> Sandbox is my use case too but i'm
Andrei Vagin writes:
> I did a few experiments and found that the bug is reproduced for 6-12
> hours on the our test server. Then I reverted two patches and the server
> is working normally for more than 24 hours already, so the bug is
> probably in one of these patches.
>
> commit e3d0065ab8535c
<45> 8b 6e 14 4d
> 63 76 74 48 89 04 24 0f 1f 44 00 00 48 83 c4 08
> RIP: kmem_cache_alloc+0xcf/0x1c0 RSP: 9b1500017c28
> CR2: 0014
>
> Fixes: 7b1a74fdbb9e ("[NETNS]: Refactor fib initialization so it can handle
> multiple namespaces.")
"prakash.sangappa" writes:
> On 08/29/2017 04:02 PM, David Miller wrote:
>> From: Prakash Sangappa
>> Date: Mon, 28 Aug 2017 17:12:20 -0700
>>
>>> Currently passing tid(gettid(2)) of a thread in struct ucred in
>>> SCM_CREDENTIALS message requires CAP_SYS_ADMIN capability otherwise
>>> it fails
1 - 100 of 1164 matches
Mail list logo
