On Tue, Feb 9, 2021 at 11:06 AM Ido Schimmel wrote:
>
> On Tue, Feb 09, 2021 at 10:49:23AM -0800, Mahesh Bandewar (महेश बंडेवार)
> wrote:
> > On Tue, Feb 9, 2021 at 8:23 AM Jakub Kicinski wrote:
> > >
> > > On Tue, 9 Feb 2021 12:54:59 +0100 Petr Machata
On Tue, Feb 9, 2021 at 11:04 AM Jakub Kicinski wrote:
>
> On Tue, 9 Feb 2021 10:49:23 -0800 Mahesh Bandewar (महेश बंडेवार) wrote:
> > On Tue, Feb 9, 2021 at 8:23 AM Jakub Kicinski wrote:
> > > On Tue, 9 Feb 2021 12:54:59 +0100 Petr Machata wrote:
> > > > This wil
On Tue, Feb 9, 2021 at 8:23 AM Jakub Kicinski wrote:
>
> On Tue, 9 Feb 2021 12:54:59 +0100 Petr Machata wrote:
> > Jian Yang writes:
> >
> > > From: Jian Yang
> > >
> > > Traditionally loopback devices come up with initial state as DOWN for
> > > any new network-namespace. This would mean that a
On Tue, Dec 1, 2020 at 6:38 PM Jakub Kicinski wrote:
>
> On Tue, 1 Dec 2020 12:24:38 -0800 Mahesh Bandewar (महेश बंडेवार) wrote:
> > On Thu, Nov 19, 2020 at 8:56 PM Jakub Kicinski wrote:
> > > Do you have more details on what the use cases are that expect no
> > >
On Thu, Nov 19, 2020 at 8:56 PM Jakub Kicinski wrote:
>
> On Thu, 19 Nov 2020 19:55:08 -0800 Mahesh Bandewar (महेश बंडेवार) wrote:
> > On Thu, Nov 19, 2020 at 12:03 AM Nicolas Dichtel
> > > Le 18/11/2020 à 18:39, Mahesh Bandewar (महेश बंडेवार) a écrit :
> > > > ne
On Thu, Nov 19, 2020 at 12:03 AM Nicolas Dichtel
wrote:
>
> Le 18/11/2020 à 18:39, Mahesh Bandewar (महेश बंडेवार) a écrit :
> > On Wed, Nov 18, 2020 at 8:58 AM Nicolas Dichtel
> > wrote:
> >>
> >> Le 18/11/2020 à 02:12, David Ahern a écrit :
> >> [sni
On Wed, Nov 18, 2020 at 10:04 AM David Ahern wrote:
>
> On 11/18/20 10:39 AM, Mahesh Bandewar (महेश बंडेवार) wrote:
> > On Wed, Nov 18, 2020 at 8:58 AM Nicolas Dichtel
> > wrote:
> >>
> >> Le 18/11/2020 à 02:12, David Ahern a écrit :
> >> [snip]
>
On Wed, Nov 18, 2020 at 8:58 AM Nicolas Dichtel
wrote:
>
> Le 18/11/2020 à 02:12, David Ahern a écrit :
> [snip]
> > If there is no harm in just creating lo in the up state, why not just do
> > it vs relying on a sysctl? It only affects 'local' networking so no real
> > impact to containers that d
On Tue, Nov 17, 2020 at 9:18 AM Ido Schimmel wrote:
>
> On Mon, Nov 16, 2020 at 01:03:32PM -0800, Mahesh Bandewar (महेश बंडेवार)
> wrote:
> > On Mon, Nov 16, 2020 at 12:34 PM Jakub Kicinski wrote:
> > >
> > > On Mon, 16 Nov 2020 12:02:48 -0800 Mah
On Mon, Nov 16, 2020 at 1:20 PM Jakub Kicinski wrote:
>
> On Mon, 16 Nov 2020 12:50:22 -0800 Mahesh Bandewar (महेश बंडेवार) wrote:
> > On Mon, Nov 16, 2020 at 12:17 PM Jakub Kicinski wrote:
> > > On Mon, 16 Nov 2020 12:02:48 -0800 Mahesh Bandewar (महेश बंडेवार) wrote:
&
On Mon, Nov 16, 2020 at 12:34 PM Jakub Kicinski wrote:
>
> On Mon, 16 Nov 2020 12:02:48 -0800 Mahesh Bandewar (महेश बंडेवार) wrote:
> > > > diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
> > > > index a1c77cc00416..76dc92ac65a2 100644
> &
On Mon, Nov 16, 2020 at 12:17 PM Jakub Kicinski wrote:
>
> On Mon, 16 Nov 2020 12:02:48 -0800 Mahesh Bandewar (महेश बंडेवार) wrote:
> > On Sat, Nov 14, 2020 at 10:17 AM Jakub Kicinski wrote:
> > > On Wed, 11 Nov 2020 12:43:08 -0800 Jian Yang wrote:
> >
On Sat, Nov 14, 2020 at 10:17 AM Jakub Kicinski wrote:
>
> On Wed, 11 Nov 2020 12:43:08 -0800 Jian Yang wrote:
> > From: Mahesh Bandewar
> >
> > Traditionally loopback devices comes up with initial state as DOWN for
> > any new network-namespace. This would mean that anyone needing this
> > devic
On Tue, Aug 25, 2020 at 5:42 PM Maciej Żenczykowski wrote:
>
> On Tue, Aug 25, 2020 at 4:00 PM Mahesh Bandewar (महेश बंडेवार)
> wrote:
> >
> > On Tue, Aug 25, 2020 at 3:47 PM Randy Dunlap wrote:
> > >
> > > On 8/25/20 3:42 PM, Mahesh Bandewar wrote:
> &
On Tue, Aug 25, 2020 at 3:47 PM Randy Dunlap wrote:
>
> On 8/25/20 3:42 PM, Mahesh Bandewar wrote:
> > The sysctl that was added earlier by commit 79134e6ce2c ("net: do
> > not create fallback tunnels for non-default namespaces") to create
> > fall-back only in root-ns. This patch enhances that b
On Fri, Aug 21, 2020 at 2:35 PM David Miller wrote:
>
> From: Maciej Żenczykowski
> Date: Fri, 21 Aug 2020 14:25:20 -0700
>
> > If no kernel command line option is specified, should the default
> > be to maintain compatibility, or do you think it's okay to make
> > the default be no extra interfa
On Tue, Oct 15, 2019 at 10:36 AM David Miller wrote:
>
> From: Mahesh Bandewar
> Date: Fri, 11 Oct 2019 18:14:55 -0700
>
> > While invalidating the dst, we assign backhole_netdev instead of
> > loopback device. However, this device does not have idev pointer
> > and hence no ip6_ptr even if IPv6
On Thu, Oct 10, 2019 at 5:37 PM Wei Wang wrote:
>
> On Thu, Oct 10, 2019 at 9:48 AM Mahesh Bandewar wrote:
> >
> > While invalidating the dst, we assign backhole_netdev instead of
> > loopback device. However, this device does not have idev pointer
> > and hence no ip6_ptr even if IPv6 is enabled
On Wed, Oct 9, 2019 at 4:15 PM Mahesh Bandewar wrote:
>
> While invalidating the dst, we assign backhole_netdev instead of
> loopback device. However, this device does not have idev pointer
> and hence no ip6_ptr even if IPv6 is enabled. Possibly this has
> triggered the syzbot reported crash.
>
>
On Tue, Jul 9, 2019 at 6:16 AM Andrea Claudi wrote:
>
> Tunnel change fails if a tunnel name is not specified while using
> 'ip -6 tunnel change'. However, no warning message is printed and
> no error code is returned.
>
> $ ip -6 tunnel add ip6tnl1 mode ip6gre local fd::1 remote fd::2 tos inherit
On Tue, Jul 9, 2019 at 6:16 AM Andrea Claudi wrote:
>
> This reverts commit ba126dcad20e6d0e472586541d78bdd1ac4f1123.
> It breaks tunnel creation when using 'dev' parameter:
>
> $ ip link add type dummy
> $ ip -6 tunnel add ip6tnl1 mode ip6ip6 remote 2001:db8::100::2 local
> 2001:db8::100
On Sat, Jun 29, 2019 at 12:28 PM David Miller wrote:
>
> From: Mahesh Bandewar
> Date: Thu, 27 Jun 2019 12:43:09 -0700
>
> > +config TEST_BLACKHOLE_DEV
> > + tristate "Test BPF filter functionality"
>
> I think the tristate string needs to be changed :-)
side effects of copy-paste :(
sending
On Fri, Jun 28, 2019 at 11:22 AM Michael Chan wrote:
>
> On Thu, Jun 27, 2019 at 12:42 PM Mahesh Bandewar wrote:
>
> > However, Michael Chan had a setup
> > where these fixes helped him mitigate the issue and not cause
> > the crash.
> >
>
> Our lab has finished testing these patches. The patch
On Thu, Jun 27, 2019 at 11:08 AM David Miller wrote:
>
> From: Mahesh Bandewar
> Date: Fri, 21 Jun 2019 17:45:39 -0700
>
> > --- a/tools/testing/selftests/net/Makefile
> > +++ b/tools/testing/selftests/net/Makefile
> > @@ -4,8 +4,9 @@
> > CFLAGS = -Wall -Wl,--no-as-needed -O2 -g
> > CFLAGS +=
On Mon, Jun 24, 2019 at 9:00 PM Michael Chan wrote:
>
> On Fri, Jun 21, 2019 at 5:45 PM Mahesh Bandewar wrote:
>
> > Well, I'm not a TCP expert and though we have experienced
> > these corner cases in our environment, I could not reproduce
> > this case reliably in my test setup to try this fix m
On Sat, Jun 22, 2019 at 8:35 AM David Ahern wrote:
>
> On 6/21/19 6:45 PM, Mahesh Bandewar wrote:
> > When we invalidate dst or mark it "dead", we assign 'lo' to
> > dst->dev. First of all this assignment is racy and more over,
> > it has MTU implications.
> >
> > The standard dev MTU is 1500 whil
On Tue, Feb 19, 2019 at 3:38 PM Daniel Borkmann wrote:
>
> When running Docker with userns isolation e.g. --userns-remap="default"
> and spawning up some containers with CAP_NET_ADMIN under this realm, I
> noticed that link changes on ipvlan slave device inside that container
> can affect all devi
On Wed, Feb 6, 2019 at 8:51 PM Mahesh Bandewar (महेश बंडेवार)
wrote:
>
> On Tue, Feb 5, 2019 at 11:36 AM Michael Chan
> wrote:
> >
> > On Wed, Jan 30, 2019 at 5:00 PM Mahesh Bandewar (महेश बंडेवार)
> > wrote:
> > >
> > > On Wed, Jan 3
On Tue, Feb 5, 2019 at 11:36 AM Michael Chan wrote:
>
> On Wed, Jan 30, 2019 at 5:00 PM Mahesh Bandewar (महेश बंडेवार)
> wrote:
> >
> > On Wed, Jan 30, 2019 at 1:07 AM Michael Chan
> > wrote:
> > >
> > > On Tue, Jan 22, 2019 at 10:29 A
On Wed, Jan 30, 2019 at 1:07 AM Michael Chan wrote:
>
> On Tue, Jan 22, 2019 at 10:29 AM Mahesh Bandewar (महेश बंडेवार)
> wrote:
>
> >
> > The idea behind the fix is very simple and it is to create a dst-only
> > (unregistered) device with a very low MTU and us
On Mon, Jan 21, 2019 at 4:59 PM Michael Chan wrote:
>
> On Mon, Jan 21, 2019 at 4:36 PM Daniel Axtens wrote:
>
> > I hit a similar sounding issue on a bnx2x - see commit
> > 8914a595110a6eca69a5e275b323f5d09e18f4f9
> >
> > In that case, a GSO packet with gso_size too large for the firmware was
>
On Mon, Jan 14, 2019 at 12:00 AM Vincent Bernat wrote:
>
> ❦ 13 janvier 2019 18:01 -08, Maciej Żenczykowski :
>
> > But I seem to recall that the core problem we were trying to solve was
> > that a daemon listening
> > on an AF_PACKET ethertype 88CC [LLDP] socket not bound to any device
> > would
On Thu, Sep 13, 2018 at 12:33 PM, Stephen Hemminger
wrote:
> If an error happens in multi-segment message (tc only)
> then report the error and stop processing further responses.
> This also fixes refering to the buffer after free.
>
> The sequence check is not necessary here because the
> respons
On Thu, Sep 13, 2018 at 4:00 PM, Michal Soltys wrote:
> On 2018-07-19 18:20, Michal Soltys wrote:
>> On 07/19/2018 01:41 AM, Mahesh Bandewar wrote:
>>> From: Mahesh Bandewar
>>>
>>> Commit b89f04c61efe ("bonding: deliver link-local packets with
>>> skb->dev set to link that packets arrived on") c
On Thu, Sep 13, 2018 at 8:19 AM, Stephen Hemminger
wrote:
>
> On Wed, 12 Sep 2018 23:07:20 -0700
> Mahesh Bandewar (महेश बंडेवार) wrote:
>
> > On Wed, Sep 12, 2018 at 5:33 PM, Stephen Hemminger
> > wrote:
> > >
> > > On Wed, 12 Sep 2018 1
On Wed, Sep 12, 2018 at 5:33 PM, Stephen Hemminger
wrote:
>
> On Wed, 12 Sep 2018 16:29:28 -0700
> Mahesh Bandewar wrote:
>
> > From: Mahesh Bandewar
> >
> > A local program using iproute2 lib pointed out the issue and looking
> > at the code it is pretty obvious -
> >
> > a = (struct nlmsgh
On Tue, Aug 21, 2018 at 11:19 AM, Stephen Hemminger
wrote:
> On Tue, 21 Aug 2018 10:48:54 -0700
> Mahesh Bandewar wrote:
>
>> From: Mahesh Bandewar
>>
>> Signed-off-by: Mahesh Bandewar
>
> I already did this yesterday. Patch was on mailing list.
Hmm, I thought I did mention that I would take ca
On Mon, Aug 20, 2018 at 5:52 PM, Stephen Hemminger
wrote:
> On Mon, 20 Aug 2018 16:44:28 -0700
> Mahesh Bandewar (महेश बंडेवार) wrote:
>
>> On Mon, Aug 20, 2018 at 4:38 PM, Mahesh Bandewar (महेश बंडेवार)
>> wrote:
>> > On Mon, Aug 20, 2018 at 3:52 PM, Stephen Hemmi
On Mon, Aug 20, 2018 at 4:44 PM, Mahesh Bandewar (महेश बंडेवार)
wrote:
> On Mon, Aug 20, 2018 at 4:38 PM, Mahesh Bandewar (महेश बंडेवार)
> wrote:
>> On Mon, Aug 20, 2018 at 3:52 PM, Stephen Hemminger
>> wrote:
>>> On Mon, 20 Aug 2018 14:42:15 -0700
>>> M
On Mon, Aug 20, 2018 at 3:50 PM, Stephen Hemminger
wrote:
> On Mon, 20 Aug 2018 14:42:15 -0700
> Mahesh Bandewar wrote:
>
>>
>> if (is_json_context()) {
>> + json_writer_t *jw;
>> +
>> open_json_object("bittiming");
>>
On Mon, Aug 20, 2018 at 4:38 PM, Mahesh Bandewar (महेश बंडेवार)
wrote:
> On Mon, Aug 20, 2018 at 3:52 PM, Stephen Hemminger
> wrote:
>> On Mon, 20 Aug 2018 14:42:15 -0700
>> Mahesh Bandewar wrote:
>>
>>> diff --git a/tc/m_ematch.c b/tc/m_ematch.c
>>&g
On Mon, Aug 20, 2018 at 3:52 PM, Stephen Hemminger
wrote:
> On Mon, 20 Aug 2018 14:42:15 -0700
> Mahesh Bandewar wrote:
>
>> diff --git a/tc/m_ematch.c b/tc/m_ematch.c
>> index ace4b3dd738b..a524b520b276 100644
>> --- a/tc/m_ematch.c
>> +++ b/tc/m_ematch.c
>> @@ -277,6 +277,7 @@ static int flatte
On Fri, Aug 17, 2018 at 9:29 AM, Stephen Hemminger
wrote:
> On Wed, 15 Aug 2018 16:08:55 -0700
> Mahesh Bandewar wrote:
>
>> From: Mahesh Bandewar
>>
>> When creating socket() AF_INET is used irrespective of the family
>> that is given at the command-line (with -4, -6, or -0). This change
>> wil
On Wed, Jul 18, 2018 at 4:33 PM, David Miller wrote:
> From: Mahesh Bandewar (महेश बंडेवार)
> Date: Wed, 18 Jul 2018 16:19:17 -0700
>
>> On Wed, Jul 18, 2018 at 1:18 PM, David Miller wrote:
>>> From: Mahesh Bandewar
>>> Date: Wed, 18 Jul 2018 12:55:42 -07
On Wed, Jul 18, 2018 at 1:18 PM, David Miller wrote:
> From: Mahesh Bandewar
> Date: Wed, 18 Jul 2018 12:55:42 -0700
>
>> From: Mahesh Bandewar
>>
>> Commit b89f04c61efe ("bonding: deliver link-local packets with
>> skb->dev set to link that packets arrived on") changed the behavior
>> of how li
On Mon, Jul 16, 2018 at 4:33 PM, Stephen Hemminger
wrote:
> On Sun, 15 Jul 2018 18:12:46 -0700
> Mahesh Bandewar wrote:
>
>> From: Mahesh Bandewar
>>
>> Commit b89f04c61efe ("bonding: deliver link-local packets with
>> skb->dev set to link that packets arrived on") changed the behavior
>> of how
On Mon, Jul 16, 2018 at 2:24 PM, Jay Vosburgh
wrote:
> Mahesh Bandewar wrote:
>
>>From: Mahesh Bandewar
>>
>>Commit b89f04c61efe ("bonding: deliver link-local packets with
>>skb->dev set to link that packets arrived on") changed the behavior
>>of how link-local-multicast packets are processed. T
On Thu, Jul 12, 2018 at 4:14 PM, Michal Soltys wrote:
> On 2018-07-13 00:03, Jay Vosburgh wrote:
>> Mahesh Bandewar (महेश बंडेवार) wrote:
>>
>>>On Thu, Jul 12, 2018 at 11:03 AM, Jay Vosburgh
>>> wrote:
>>>> Michal Soltys wrote:
>>>>
>&
On Thu, Jul 12, 2018 at 11:03 AM, Jay Vosburgh
wrote:
> Michal Soltys wrote:
>
>>On 07/12/2018 04:51 PM, Jay Vosburgh wrote:
>>> Mahesh Bandewar (महेश बंडेवार) wrote:
>>>
>>>> On Wed, Jul 11, 2018 at 3:23 PM, Michal Soltys wrote:
>>>>>
&g
On Wed, Jul 11, 2018 at 3:23 PM, Michal Soltys wrote:
>
> Hi,
>
> As weird as that sounds, this is what I observed today after bumping
> kernel version. I have a setup where 2 bonds are attached to linux
> bridge and physically are connected to two switches doing MSTP (and
> linux bridge is just p
On Wed, Mar 14, 2018 at 8:37 PM, Alexei Starovoitov
wrote:
> On Wed, Mar 14, 2018 at 05:17:54PM -0700, Eric Dumazet wrote:
>>
>>
>> On 03/14/2018 11:41 AM, Alexei Starovoitov wrote:
>> > On Wed, Mar 14, 2018 at 11:00 AM, Alexei Starovoitov
>> > wrote:
>> >>
>> >>> It seems this is exactly the cas
On Tue, Mar 13, 2018 at 8:39 PM, Alexei Starovoitov wrote:
> For our container management we've been using complicated and fragile setup
> consisting of LD_PRELOAD wrapper intercepting bind and connect calls from
> all containerized applications.
> The setup involves per-container IPs, policy, etc
On Fri, Jan 12, 2018 at 12:48 AM, Jiri Benc wrote:
> On Fri, 12 Jan 2018 09:34:13 +0100, Jiri Benc wrote:
>> I don't think this works currently. When someone (does not have to be
>> you, it can be a management software running in background) sets the
>> MTU to the current value, the magic behavior
On Thu, Jan 11, 2018 at 8:59 AM, Mahesh Bandewar (महेश बंडेवार)
wrote:
> On Thu, Jan 11, 2018 at 3:25 AM, Jiri Benc wrote:
>> On Wed, 10 Jan 2018 18:09:50 -0800, Mahesh Bandewar (महेश बंडेवार) wrote:
>>> I still prefer the approach I had mentioned that uses 'mtu_adj
On Thu, Jan 11, 2018 at 3:25 AM, Jiri Benc wrote:
> On Wed, 10 Jan 2018 18:09:50 -0800, Mahesh Bandewar (महेश बंडेवार) wrote:
>> I still prefer the approach I had mentioned that uses 'mtu_adj'. In
>> that approach you can leave those slaves which have changed their mtu
&g
On Tue, Jan 9, 2018 at 11:21 PM, wrote:
> From: Keefe Liu
>
> The MTU of ipvlan interface should not bigger than the phy device, When we
> run following scripts, we will find there are some problems.
> Step1:
> ip link add link eth0 name ipv1 type ipvlan mode l2
> ip netns add ne
On Tue, Jan 9, 2018 at 7:12 PM, liuqifa wrote:
>
>> On Mon, Jan 8, 2018 at 10:48 PM, wrote:
>> > From: Keefe Liu
>> >
>> > The MTU of ipvlan interface should not bigger than the phy device,
>> > When we run following scripts, we will find there are some problems.
>> > Step1:
>> > ip lin
On Tue, Jan 9, 2018 at 2:28 PM, Serge E. Hallyn wrote:
> Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
>> On Mon, Jan 8, 2018 at 10:36 AM, Serge E. Hallyn wrote:
>> > Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
>> >> On Mon, Ja
On Mon, Jan 8, 2018 at 10:48 PM, wrote:
> From: Keefe Liu
>
> The MTU of ipvlan interface should not bigger than the phy device, When we
> run following scripts, we will find there are some problems.
> Step1:
> ip link add link eth0 name ipv1 type ipvlan mode l2
> ip netns add ne
On Mon, Jan 8, 2018 at 10:36 AM, Serge E. Hallyn wrote:
> Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
>> On Mon, Jan 8, 2018 at 10:11 AM, Serge E. Hallyn wrote:
>> > Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
>> >> On Mon, J
On Mon, Jan 8, 2018 at 10:11 AM, Serge E. Hallyn wrote:
> Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
>> On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn wrote:
>> > Quoting James Morris (james.l.mor...@oracle.com):
>> >> On Mon, 8 Jan 2018, Serge
On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn wrote:
> Quoting James Morris (james.l.mor...@oracle.com):
>> On Mon, 8 Jan 2018, Serge E. Hallyn wrote:
>>
>> > > Also, why do we need the concept of a controlled user-ns at all, if the
>> > > default whitelist maintains existing behavior?
>> >
>> >
On Thu, Jan 4, 2018 at 12:19 AM, SF Markus Elfring
wrote:
>> If you see 8 out of 9 call sites in this file ignore the return value.
>
> How do you think about to fix error detection and corresponding
> exception handling then?
>
If I understand your question correctly - not having memory is not a
On Wed, Jan 3, 2018 at 8:44 AM, Eric W. Biederman wrote:
> 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
On Wed, Jan 3, 2018 at 12:45 AM, SF Markus Elfring
wrote:
>>> Omit an extra message for a memory allocation failure in this function.
>>>
>>> This issue was detected by using the Coccinelle software.
>>>
>> What is the issue with this message?
>
> * Is it redundant?
>
> * Would a Linux allocation
On Mon, Jan 1, 2018 at 8:07 AM, SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Mon, 1 Jan 2018 17:00:04 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
What is the issue with this message?
On Sat, Dec 30, 2017 at 12:50 AM, Michael Kerrisk (man-pages)
wrote:
> Hello Mahesh,
>
> On 12/05/2017 11:31 PM, Mahesh Bandewar wrote:
>> From: Mahesh Bandewar
>>
>> Add a sysctl variable kernel.controlled_userns_caps_whitelist. This
>> takes input as capability mask expressed as two comma separ
:45 AM, Mahesh Bandewar (महेश बंडेवार) wrote:
>> On Wed, Dec 27, 2017 at 12:23 PM, Michael Kerrisk (man-pages)
>> wrote:
>>> Hello Mahesh,
>>>
>>> On 27 December 2017 at 18:09, Mahesh Bandewar (महेश बंडेवार)
>>> wrote:
>>>> Hello James,
&
On Sat, Dec 30, 2017 at 12:31 AM, James Morris
wrote:
> On Wed, 27 Dec 2017, Mahesh Bandewar (महेश बंडेवार) wrote:
>
>> Hello James,
>>
>> Seems like I missed your name to be added into the review of this
>> patch series. Would you be willing be pull this into the
On Wed, Dec 27, 2017 at 12:23 PM, Michael Kerrisk (man-pages)
wrote:
> Hello Mahesh,
>
> On 27 December 2017 at 18:09, Mahesh Bandewar (महेश बंडेवार)
> wrote:
>> Hello James,
>>
>> Seems like I missed your name to be added into the review of this
>> patch
Hello James,
Seems like I missed your name to be added into the review of this
patch series. Would you be willing be pull this into the security
tree? Serge Hallyn has already ACKed it.
Thanks,
--mahesh..
On Tue, Dec 5, 2017 at 2:30 PM, Mahesh Bandewar wrote:
> From: Mahesh Bandewar
>
> TL;DR
On Mon, Dec 11, 2017 at 8:15 AM, David Miller wrote:
> From: Mahesh Bandewar
> Date: Thu, 7 Dec 2017 15:15:43 -0800
>
>> From: Mahesh Bandewar
>>
>> Packets that don't have dest mac as the mac of the master device should
>> not be entertained by the IPvlan rx-handler. This is mostly true as the
On Wed, Nov 29, 2017 at 9:57 AM, Serge E. Hallyn wrote:
> Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
>> On Tue, Nov 28, 2017 at 3:04 PM, Serge E. Hallyn wrote:
>> > Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
>> > ...
>> >&g
On Tue, Nov 28, 2017 at 3:04 PM, Serge E. Hallyn wrote:
> Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> ...
>> >> diff --git a/security/commoncap.c b/security/commoncap.c
>> >> index fc46f5b85251..89103f16ac37 100644
>> >> --- a
On Sat, Nov 25, 2017 at 10:40 PM, Serge E. Hallyn wrote:
> Quoting Mahesh Bandewar (mah...@bandewar.net):
>> From: Mahesh Bandewar
>>
>> With this new notion of "controlled" user-namespaces, the controlled
>> user-namespaces are marked at the time of their creation while the
>> capabilities of pr
On Fri, Nov 10, 2017 at 1:46 PM, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>> single sandbox. I am not at all certain that the capabilities is the
>> proper place to limit code reachability.
>
> Right, I keep having this gut feeling that there is another way we
>
On Fri, Nov 10, 2017 at 1:30 PM, Serge E. Hallyn wrote:
> Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> ...
>> >>
>> >> ==
>> >>
>> >> +controlled_userns_caps_whitel
On Fri, Nov 10, 2017 at 6:58 AM, Eric W. Biederman
wrote:
> "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 Fri, Nov 10, 2017 at 2:30 AM, Serge E. Hallyn wrote:
> Quoting Mahesh Bandewar (mah...@bandewar.net):
>> From: Mahesh Bandewar
>>
>> Add a sysctl variable kernel.controlled_userns_caps_whitelist. This
>
> I understand the arguments in favor of whitelists in most cases for
> security purposes.
On Fri, Nov 10, 2017 at 2:22 AM, Serge E. Hallyn wrote:
> Quoting Mahesh Bandewar (mah...@bandewar.net):
>> From: Mahesh Bandewar
>>
>> Add a sysctl variable kernel.controlled_userns_caps_whitelist. This
>> takes input as capability mask expressed as two comma separated hex
>> u32 words. The mask
On Fri, Nov 10, 2017 at 2:25 AM, Serge E. Hallyn wrote:
> Quoting Mahesh Bandewar (mah...@bandewar.net):
>> From: Mahesh Bandewar
>>
>> With this new notion of "controlled" user-namespaces, the controlled
>> user-namespaces are marked at the time of their creation while the
>> capabilities of pro
On Thu, Nov 9, 2017 at 9:09 PM, wrote:
> From: Keefe Liu
>
> When process the outbound packet of ipv6, we should assign the master
> device to output device other than input device.
>
curious to know, how you discovered this?
> Signed-off-by: Keefe Liu
Acked-by: Mahesh Bandewar
> ---
> drive
[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 AM, Christian Brauner
> > wro
On Thu, Nov 9, 2017 at 4:02 AM, Christian Brauner
wrote:
> On Wed, Nov 08, 2017 at 03:09:59AM -0800, Mahesh Bandewar (महेश बंडेवार)
> wrote:
>> Sorry folks I was traveling and seems like lot happened on this thread. :p
>>
>> I will try to response few of these comments s
Sorry folks I was traveling and seems like lot happened on this thread. :p
I will try to response few of these comments selectively -
> The thing that makes me hesitate with this set is that it is a
> permanent new feature to address what (I hope) is a temporary
> problem.
I agree this is permane
On Tue, Nov 7, 2017 at 2:50 AM, Jay Vosburgh wrote:
> The bonding miimon logic has a flaw, in that a failure of the
> rtnl_trylock can cause a slave to become permanently stuck in
> BOND_LINK_FAIL state.
>
> The sequence of events to cause this is as follows:
>
> 1) bond_mi
On Sat, Nov 4, 2017 at 4:53 PM, Serge E. Hallyn wrote:
>
> Quoting Mahesh Bandewar (mah...@bandewar.net):
> > Init-user-ns is always uncontrolled and a process that has SYS_ADMIN
> > that belongs to uncontrolled user-ns can create another (child) user-
> > namespace that is uncontrolled. Any other
On Mon, Oct 2, 2017 at 11:12 AM, Mahesh Bandewar (महेश बंडेवार)
wrote:
> On Mon, Oct 2, 2017 at 10:14 AM, Serge E. Hallyn wrote:
>> Quoting Mahesh Bandewar (mah...@bandewar.net):
>>> From: Mahesh Bandewar
>>>
>>> [Same as the previous RFC series
On Thu, Oct 12, 2017 at 4:06 PM, Girish Moodalbail
wrote:
> Hello Eric,
>
> The basic idea is to mark the ARP entry either FAILED or STALE as soon as we
> can so that the subsequent packets that depend on that ARP entry will take
> the slow path (neigh_resolve_output()).
>
> Say, if base_reachable
On Mon, Oct 2, 2017 at 10:14 AM, Serge E. Hallyn wrote:
> Quoting Mahesh Bandewar (mah...@bandewar.net):
>> From: Mahesh Bandewar
>>
>> [Same as the previous RFC series sent on 9/21]
>>
>> TL;DR version
>> -
>> Creating a sandbox environment with namespaces is challenging
>> consideri
On Fri, Sep 29, 2017 at 1:08 PM, Stephen Hemminger
wrote:
> On Wed, 27 Sep 2017 18:03:49 -0700
> Mahesh Bandewar wrote:
>
>> From: Mahesh Bandewar
>>
>> Some NIC drivers don't have correct speed/duplex settings at the
>> time they send NETDEV_UP notification and that messes up the
>> bonding sta
On Fri, Sep 22, 2017 at 1:49 PM, Petar Penkov wrote:
> Add a TUN/TAP receive mode that exercises the napi_gro_frags()
> interface. This mode is available only in TAP mode, as the interface
> expects packets with Ethernet headers.
>
> Furthermore, packets follow the layout of the iovec_iter that wa
On Fri, Sep 22, 2017 at 1:49 PM, Petar Penkov wrote:
> Changes TUN driver to use napi_gro_receive() upon receiving packets
> rather than netif_rx_ni(). Adds flag IFF_NAPI that enables these
> changes and operation is not affected if the flag is disabled. SKBs
> are constructed upon packet arrival
On Fri, Sep 22, 2017 at 11:03 AM, Willem de Bruijn
wrote:
> On Fri, Sep 22, 2017 at 1:11 PM, Mahesh Bandewar (महेश बंडेवार)
> wrote:
>>> #ifdef CONFIG_TUN_VNET_CROSS_LE
>>> static inline bool tun_legacy_is_little_endian(struct tun_struct *tun)
>>> {
>
> #ifdef CONFIG_TUN_VNET_CROSS_LE
> static inline bool tun_legacy_is_little_endian(struct tun_struct *tun)
> {
> @@ -541,6 +604,11 @@ static void __tun_detach(struct tun_file *tfile, bool
> clean)
>
> tun = rtnl_dereference(tfile->tun);
>
> + if (tun && clean) {
> +
On Fri, Sep 22, 2017 at 7:06 AM, Willem de Bruijn
wrote:
>> @@ -2061,6 +2174,9 @@ static int tun_set_iff(struct net *net, struct file
>> *file, struct ifreq *ifr)
>> if (tfile->detached)
>> return -EINVAL;
>>
>> + if ((ifr->ifr_flags & IFF_NAPI_FRAGS) && !capable(CAP
On Tue, Sep 12, 2017 at 5:10 AM, Nikolay Aleksandrov
wrote:
> Commit 8b426dc54cf4 ("bonding: remove hardcoded value") changed the
> default value for tlb_dynamic_lb which lead to either broken ALB mode
> (since tlb_dynamic_lb can be changed only in TLB) or setting TLB mode
> with tlb_dynamic_lb eq
On Sat, Sep 9, 2017 at 4:28 AM, Nikolay Aleksandrov
wrote:
> On 07/09/17 01:47, Kosuke Tatsukawa wrote:
>> Commit cbf5ecb30560 ("net: bonding: Fix transmit load balancing in
>> balance-alb mode") tried to fix transmit dynamic load balancing in
>> balance-alb mode, which wasn't working after commit
On Fri, Sep 8, 2017 at 7:30 AM, Nikolay Aleksandrov
wrote:
> On 08/09/17 17:17, Kosuke Tatsukawa wrote:
>> Hi,
>>
>>> On 08/09/17 13:10, Nikolay Aleksandrov wrote:
On 08/09/17 05:06, Kosuke Tatsukawa wrote:
> Hi,
>
>> On 7.09.2017 01:47, Kosuke Tatsukawa wrote:
>>> Commit cbf
On Thu, Sep 7, 2017 at 5:47 PM, Mahesh Bandewar (महेश बंडेवार)
wrote:
> On Thu, Sep 7, 2017 at 5:39 PM, Mahesh Bandewar (महेश बंडेवार)
> wrote:
>> On Thu, Sep 7, 2017 at 4:09 PM, Nikolay Aleksandrov
>> wrote:
>>> On 7.09.2017 01:47, Kosuke Tatsukawa wrote:
>
1 - 100 of 149 matches
Mail list logo
