From: Pete Heist <pete@heistp.net>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] lockup with multiple cake instances on 3.16.7
Date: Fri, 1 Feb 2019 00:18:13 +0100 [thread overview]
Message-ID: <002E991C-EE0E-4288-B18A-D0FD7BF3152F@heistp.net> (raw)
In-Reply-To: <87h8doifve.fsf@toke.dk>
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
> On Feb 1, 2019, at 12:09 AM, Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> 1) Why is nla_put_u32 suddenly failing for TARGET_US after adding five
>> cake instances?
>
> Probably because it's running out of kernel memory? How much system
> memory do you have on the system you are testing this on?
Plenty of memory (used 131308, free 1911900). I’m guessing this was by design where earlier kernels allocated a smaller initial size for tail space, but that’s only a guess as I haven’t found where that’s done.
>> 2) Is calling sch_tree_unlock the right thing to do in the failure
>> case, or am I working around a kernel bug, and doing something that
>> would fail in other kernels?
>
> Yes, I think you are working around a kernel bug. See
> https://elixir.bootlin.com/linux/v3.16.7/source/net/sched/sch_api.c#L1330 <https://elixir.bootlin.com/linux/v3.16.7/source/net/sched/sch_api.c#L1330>
>
> The lock is taken in gnet_stats_start_copy_compat() and released in
> gnet_stats_finish_copy(). The latter is skipped in the failure path. It
> seems this bug is present all the way up to Eric's change to remove the
> locking entirely (which went into 4.8). So I guess you could get a patch
> accepted for the stable trees in 3.16 and 4.4; not that this would help
> you much if you are stuck on 3.16.7…
Hehe, “crossing the streams” here. :) That’s what I gathered after looking at that code for a while, but I’m glad to be sure about it.
Would you accept my workaround in cake_dump_stats, or rather not?
[-- Attachment #2: Type: text/html, Size: 10752 bytes --]
next prev parent reply other threads:[~2019-01-31 23:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-30 8:58 Pete Heist
2019-01-30 22:59 ` Toke Høiland-Jørgensen
2019-01-31 7:15 ` Pete Heist
2019-01-31 14:53 ` Toke Høiland-Jørgensen
2019-01-31 20:25 ` Pete Heist
2019-01-31 23:09 ` Toke Høiland-Jørgensen
2019-01-31 23:18 ` Pete Heist [this message]
2019-01-31 23:10 ` Pete Heist
2019-01-31 23:18 ` Toke Høiland-Jørgensen
2019-01-31 23:23 ` Pete Heist
2019-01-31 23:31 ` Toke Høiland-Jørgensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=002E991C-EE0E-4288-B18A-D0FD7BF3152F@heistp.net \
--to=pete@heistp.net \
--cc=cake@lists.bufferbloat.net \
--cc=toke@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox