On Tue, 2020-07-14 at 15:03 +1000, Aleksa Sarai wrote:
> On 2020-07-13, Eric W. Biederman wrote:
> > 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. Bie
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 used by processes
> > > running in the
>
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. This meant that any process that uses the
> > connect
Currently the entry itself appears to be being leaked.
Signed-off-by: Matt Bennett
---
drivers/connector/cn_queue.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/connector/cn_queue.c b/drivers/connector/cn_queue.c
index 49295052ba8b..a82ceeb37f26 100644
--- a
In preparation for supporting the connector outside of the default
network namespace we switch to using these helpers now. As the connector
is still only supported in the default namespace this change is a no-op.
Signed-off-by: Matt Bennett
---
drivers/connector/cn_proc.c | 48
In preparation for supporting the connector outside of the default
network namespace we switch to using this function now. As the connector
is still only supported in the default namespace this change is a no-op.
Signed-off-by: Matt Bennett
---
drivers/connector/cn_proc.c | 10 +-
1
Move to storing the connector instance per network namespace. In doing
so the ability to use the connector functionality outside the default
namespace is now available.
Signed-off-by: Matt Bennett
---
drivers/connector/cn_proc.c | 49 ++
drivers/connector/connector.c | 171
-kernel&m=150806196728365&w=2
Matt Bennett (5):
connector: Use task pid helpers
connector: Use 'current_user_ns' function
connector: Ensure callback entry is released
connector: Prepare for supporting multiple namespaces
connector: Create connector per namespace
Docume
Extend the existing function definitions / call sites to start
passing the network namespace. For now we still only pass the
default namespace.
Signed-off-by: Matt Bennett
---
Documentation/driver-api/connector.rst | 6 +++---
drivers/connector/cn_proc.c| 5 +++--
drivers
On 07/21/2016 09:13 PM, Steffen Klassert wrote:
> Hi Matt,
>
> I've did some vti tests the last days, but I was unable to
> reproduce it.
>
> On Tue, Jul 19, 2016 at 05:49:06AM +, Matt Bennett wrote:
>> On 07/05/2016 03:55 PM, Matt Bennett wrote:
>>> On
On 07/05/2016 03:55 PM, Matt Bennett wrote:
> On 07/04/2016 11:12 PM, Steffen Klassert wrote:
>> On Mon, Jul 04, 2016 at 03:52:50AM +0000, Matt Bennett wrote:
>>> *Resending as plain text so the mailing list accepts it.. Sorry Steffen and
>>> Herbert*
>>>
>
On 07/06/2016 08:37 AM, Cong Wang wrote:
> On Tue, Jul 5, 2016 at 10:59 AM, Cong Wang wrote:
>> On Mon, Jul 4, 2016 at 7:50 PM, Matt Bennett
>> wrote:
>>> Using printk I have confirmed that ppp_pernet() is called from
>>> ppp_connect_channel() when the BUG o
On 07/04/2016 11:12 PM, Steffen Klassert wrote:
> On Mon, Jul 04, 2016 at 03:52:50AM +0000, Matt Bennett wrote:
>> *Resending as plain text so the mailing list accepts it.. Sorry Steffen and
>> Herbert*
>>
>> Hi,
>>
>> During long run testing of an ipsec t
Hi,
I am producing the attached bug trace when testing PPP connections.
Specifically the steps I am doing are:
1. Configure PPP client and LAC with shared key and wait for client to
negotiate an IP address.
2. Change the shared key on the LAC.
3. Bring the PPP client interface down and up to
*Resending as plain text so the mailing list accepts it.. Sorry Steffen and
Herbert*
Hi,
During long run testing of an ipsec tunnel over a PPP link it was found that
occasionally traffic would stop flowing over the tunnel. Eventually the traffic
would start again, however using the command "i
On Tue, 2015-11-24 at 21:36 +0100, Florian Westphal wrote:
> Matt Bennett wrote:
> > I'm emailing this list for feedback on the feasibility of increasing
> > skb->mark or adding a new field for marking. Perhaps this extension
> > could be done under a new CONFIG op
Hello,
Currently we have a number of router features (firewall, QoS, etc)
making use of ip tables and connection tracking. We do this by giving
each feature a certain area of skb->mark (say 8 bits each). This allows
us to simply restore skb->mark (using connection tracking) for packets
in a flow u
On Tue, 2015-10-13 at 05:13 +0300, Denys Fedoryshchenko wrote:
> On 2015-10-07 15:12, Guillaume Nault wrote:
> > On Mon, Oct 05, 2015 at 02:08:44PM +0200, Guillaume Nault wrote:
> >>if (po) {
> >>struct sock *sk = sk_pppox(po);
> >>
> >> - bh_lock_sock(sk);
> >> -
> >> -
On Tue, 2015-10-20 at 14:00 +0300, Andrew wrote:
> Hi.
>
> After BRAS software upgrading (PPPoE daemon + kernel from 3.2.x to
> 4.1.x) I have different kernel bugs/crashes - some of them don't hurt
> system, other crashes - cause network subsystem lockup (commands like
> 'ip a' just hungs; and
On Tue, 2015-10-06 at 11:46 +0200, Guillaume Nault wrote:
> On Tue, Oct 06, 2015 at 04:46:04AM +0000, Matt Bennett wrote:
> > > > The second one seems to be trickier. It looks like a race wrt. PADT
> > > > message reception. Reproducing the bug will probably require to
> > The second one seems to be trickier. It looks like a race wrt. PADT
> > message reception. Reproducing the bug will probably require to
> > generate some PADT flooding to a host that creates and releases PPPoE
> > connections.
Ok I think I can see the potential race here, specifically the PADT
On Mon, 2015-10-05 at 14:24 +0200, Guillaume Nault wrote:
> On Mon, Oct 05, 2015 at 04:08:51AM +0000, Matt Bennett wrote:
> > Hi, I am seeing this panic occur occasionally however I am unsure how to
> > go about reproducing it. Is it enough to simply keep creating and
> >
Hi, I am seeing this panic occur occasionally however I am unsure how to
go about reproducing it. Is it enough to simply keep creating and
tearing down the PPP interface? I can also test and/or investigate this
issue if a suitable reproduction method is available.
On Sun, 2015-10-04 at 19:08 +0300
one end of the tunnel go down and have the logs fill with
pointless messages such as "Path to destination invalid or inactive!".
This patch reduces the log level of these messages to 'dbg' level to
bring the visible behaviour into line with other tunnel types.
Signed-off-by:
ng
to have one end of the tunnel go down and have the logs fill with
pointless messages such as "Path to destination invalid or inactive!".
This patch reduces the log level of these messages to 'dbg' level to
bring the visible behaviour into line with other tunnel types.
Signed-off-b
25 matches
Mail list logo
