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
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
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
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.
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:
> 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
"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
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"
-
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
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 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
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
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
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
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
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
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
ecided when the
> network
> * namespace should be
> shut down.
> */
> + refcount_t passive; /* To decided when the
> network
> +
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
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
>
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
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
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
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
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-
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 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
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
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 --
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
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
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
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
>
: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
: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
> + /* 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,
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
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
.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
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
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
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 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 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 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
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
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
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 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
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:
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 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:
> 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
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 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 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 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 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 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
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
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
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
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
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
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 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
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
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
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
Christian Brauner writes:
> On Wed, Feb 07, 2018 at 12:19:25PM +0100, Jiri Benc wrote:
>> On Tue, 6 Feb 2018 14:19:02 +0100, Christian Brauner wrote:
>> > +/* Verify that rtnetlink requests supporting network namespace ids
>> > + * do not pass additional properties potentially referring to diffe
Christian Brauner writes:
> On Tue, Feb 06, 2018 at 12:47:46AM +0300, Kirill Tkhai wrote:
>> On 05.02.2018 18:55, Christian Brauner wrote:
>> > Since we've added support for IFLA_IF_NETNSID for RTM_{DEL,GET,SET,NEW}LINK
>> > it is possible for userspace to send us requests with three different
>>
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
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
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'
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: "
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
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
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
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
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
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
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
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:
> 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:
>>>>>
&
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
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
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
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:
> 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 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
"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
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
>> struct sockaddr_storage sent down into recvmsg() (e.g. SCTP), and leak
>> kernel stack contents to userspace. This wipes it unconditionally before
>>
Rob Landley writes:
> From: Rob Landley
>
> See message from the Android "native tools and libraries team" lead
> (I.E. the maintainer of bionic, adb, toolbox, etc) at
> http://lists.landley.net/pipermail/toybox-landley.net/2017-July/009103.html
Sigh. The list has no https access so it is unre
Paul Moore writes:
> On Wed, Oct 18, 2017 at 8:43 PM, Eric W. Biederman
> wrote:
>> Aleksa Sarai writes:
>>>>> The security implications are that anything that can change the label
>>>>> could also hide itself and its doings from the audit system
Aleksa Sarai writes:
>>> The security implications are that anything that can change the label
>>> could also hide itself and its doings from the audit system and thus
>>> would be used as a means to evade detection. I actually think this
>>> means the label should be write once (once you've set
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
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
1 - 100 of 1164 matches
Mail list logo
