On Fri, 2017-01-13 at 16:30 -0800, Cong Wang wrote:
> On Fri, Jan 13, 2017 at 3:54 PM, Chas Williams <3ch...@gmail.com> wrote:
> > On Fri, 2017-01-13 at 10:20 -0800, Cong Wang wrote:
> >> On Fri, Jan 13, 2017 at 9:10 AM, David Miller wrote:
> >> > From: Francois Romieu
> >> > Date: Fri, 13 Jan 20
On Fri, Jan 13, 2017 at 4:15 PM, Francois Romieu wrote:
> Cong Wang :
>> On Fri, Jan 13, 2017 at 5:23 AM, Francois Romieu
>> wrote:
> [...]
>> > alloc_skb() does not need to be in the "while" loop.
>>
>> This is exactly what I describe in my changelog, don't know
>> why you want to repeat it...
On Fri, Jan 13, 2017 at 4:14 PM, Francois Romieu wrote:
> Cong Wang :
> [...]
>> If you can justify API is not broken by doing that, I am more than happy
>> to do it, as I already stated in the latter patch:
>>
>> "Of course, the logic itself is suspicious, other sendmsg()
>> could handle skb all
On Fri, Jan 13, 2017 at 3:54 PM, Chas Williams <3ch...@gmail.com> wrote:
> On Fri, 2017-01-13 at 10:20 -0800, Cong Wang wrote:
>> On Fri, Jan 13, 2017 at 9:10 AM, David Miller wrote:
>> > From: Francois Romieu
>> > Date: Fri, 13 Jan 2017 01:07:00 +0100
>> >
>> >> Were alloc_skb moved one level up
Francois Romieu :
[...]
Now with a proper error code. Have a nice night.
diff --git a/net/atm/common.c b/net/atm/common.c
index a3ca922..e20d040 100644
--- a/net/atm/common.c
+++ b/net/atm/common.c
@@ -62,21 +62,16 @@ static void vcc_remove_socket(struct sock *sk)
write_unlock_irq(&vcc_s
Cong Wang :
> On Fri, Jan 13, 2017 at 5:23 AM, Francois Romieu wrote:
[...]
> > alloc_skb() does not need to be in the "while" loop.
>
> This is exactly what I describe in my changelog, don't know
> why you want to repeat it...
Because it is still hidden in a while loop.
You turned the alloc
Cong Wang :
[...]
> If you can justify API is not broken by doing that, I am more than happy
> to do it, as I already stated in the latter patch:
>
> "Of course, the logic itself is suspicious, other sendmsg()
> could handle skb allocation failure very well, not sure
> why ATM has to wait for a s
On Fri, 2017-01-13 at 10:20 -0800, Cong Wang wrote:
> On Fri, Jan 13, 2017 at 9:10 AM, David Miller wrote:
> > From: Francois Romieu
> > Date: Fri, 13 Jan 2017 01:07:00 +0100
> >
> >> Were alloc_skb moved one level up in the call stack, there would be
> >> no need to use the new wait api in the s
On Fri, Jan 13, 2017 at 9:10 AM, David Miller wrote:
> From: Francois Romieu
> Date: Fri, 13 Jan 2017 01:07:00 +0100
>
>> Were alloc_skb moved one level up in the call stack, there would be
>> no need to use the new wait api in the subsequent page, thus easing
>> pre 3.19 longterm kernel maintena
On Fri, Jan 13, 2017 at 5:23 AM, Francois Romieu wrote:
> Cong Wang :
> [...]
>> alloc_skb(GFP_KERNEL) itself is sleeping, so the new wait api is still
>> needed.
>
> The task state change warning is the symptom.
>
> The deeply nested alloc_skb is the problem.
>
> Diagnosis: nesting is wrong. It
From: Francois Romieu
Date: Fri, 13 Jan 2017 01:07:00 +0100
> Were alloc_skb moved one level up in the call stack, there would be
> no need to use the new wait api in the subsequent page, thus easing
> pre 3.19 longterm kernel maintenance (at least those on korg page).
>
> But it tastes a tad bi
Cong Wang :
[...]
> alloc_skb(GFP_KERNEL) itself is sleeping, so the new wait api is still
> needed.
The task state change warning is the symptom.
The deeply nested alloc_skb is the problem.
Diagnosis: nesting is wrong. It makes zero sense. Fix it and the
implicit task state change problem auto
On Thu, Jan 12, 2017 at 4:07 PM, Francois Romieu wrote:
> Cong Wang :
> [...]
>> diff --git a/net/atm/common.c b/net/atm/common.c
>> index a3ca922..7ec3bbc 100644
>> --- a/net/atm/common.c
>> +++ b/net/atm/common.c
>> @@ -72,10 +72,11 @@ static struct sk_buff *alloc_tx(struct atm_vcc *vcc,
>> un
Cong Wang :
[...]
> diff --git a/net/atm/common.c b/net/atm/common.c
> index a3ca922..7ec3bbc 100644
> --- a/net/atm/common.c
> +++ b/net/atm/common.c
> @@ -72,10 +72,11 @@ static struct sk_buff *alloc_tx(struct atm_vcc *vcc,
> unsigned int size)
>sk_wmem_alloc_get(sk), si
On Wed 11-01-17 21:02:01, Cong Wang wrote:
> alloc_tx() is already inside a wait loop for a successful skb
> allocation, this loop inside alloc_tx() is quite unnecessary
> and actually problematic.
I am not familiar with this code at all but vcc_sendmsg seems to be one
of those cases where open co
alloc_tx() is already inside a wait loop for a successful skb
allocation, this loop inside alloc_tx() is quite unnecessary
and actually problematic.
Signed-off-by: Cong Wang
---
net/atm/common.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/atm/common.c b/net/a
16 matches
Mail list logo
