netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: Chengchang Tang <tangchengchang@huawei.com>,
	Junxian Huang <huangjunxian6@hisilicon.com>,
	jgg@ziepe.ca, dsahern@gmail.com, netdev@vger.kernel.org,
	linux-rdma@vger.kernel.org, linuxarm@huawei.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH iproute2-rc 1/2] rdma: Fix core dump when pretty is used
Date: Tue, 2 Jan 2024 08:27:46 -0800	[thread overview]
Message-ID: <20240102082746.651ff7cf@hermes.local> (raw)
In-Reply-To: <20240102122106.GI6361@unreal>

On Tue, 2 Jan 2024 14:21:06 +0200
Leon Romanovsky <leon@kernel.org> wrote:

> On Tue, Jan 02, 2024 at 08:06:19PM +0800, Chengchang Tang wrote:
> > 
> > 
> > On 2024/1/2 16:32, Leon Romanovsky wrote:  
> > > On Tue, Jan 02, 2024 at 03:44:29PM +0800, Chengchang Tang wrote:  
> > > > 
> > > > On 2023/12/30 1:21, Stephen Hemminger wrote:  
> > > > > On Fri, 29 Dec 2023 14:52:40 +0800
> > > > > Junxian Huang <huangjunxian6@hisilicon.com> wrote:
> > > > >   
> > > > > > From: Chengchang Tang <tangchengchang@huawei.com>
> > > > > > 
> > > > > > There will be a core dump when pretty is used as the JSON object
> > > > > > hasn't been opened and closed properly.
> > > > > > 
> > > > > > Before:
> > > > > > $ rdma res show qp -jp -dd
> > > > > > [ {
> > > > > >       "ifindex": 1,
> > > > > >       "ifname": "hns_1",
> > > > > >       "port": 1,
> > > > > >       "lqpn": 1,
> > > > > >       "type": "GSI",
> > > > > >       "state": "RTS",
> > > > > >       "sq-psn": 0,
> > > > > >       "comm": "ib_core"
> > > > > > },
> > > > > > "drv_sq_wqe_cnt": 128,
> > > > > > "drv_sq_max_gs": 2,
> > > > > > "drv_rq_wqe_cnt": 512,
> > > > > > "drv_rq_max_gs": 1,
> > > > > > rdma: json_writer.c:130: jsonw_end: Assertion `self->depth > 0' failed.
> > > > > > Aborted (core dumped)
> > > > > > 
> > > > > > After:
> > > > > > $ rdma res show qp -jp -dd
> > > > > > [ {
> > > > > >           "ifindex": 2,
> > > > > >           "ifname": "hns_2",
> > > > > >           "port": 1,
> > > > > >           "lqpn": 1,
> > > > > >           "type": "GSI",
> > > > > >           "state": "RTS",
> > > > > >           "sq-psn": 0,
> > > > > >           "comm": "ib_core",{
> > > > > >               "drv_sq_wqe_cnt": 128,
> > > > > >               "drv_sq_max_gs": 2,
> > > > > >               "drv_rq_wqe_cnt": 512,
> > > > > >               "drv_rq_max_gs": 1,
> > > > > >               "drv_ext_sge_sge_cnt": 256
> > > > > >           }
> > > > > >       } ]
> > > > > > 
> > > > > > Fixes: 331152752a97 ("rdma: print driver resource attributes")
> > > > > > Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
> > > > > > Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>  
> > > > > This code in rdma seems to be miking json and newline functionality
> > > > > which creates bug traps.
> > > > > 
> > > > > Also the json should have same effective output in pretty and non-pretty mode.
> > > > > It looks like since pretty mode add extra object layer, the nesting of {} would be
> > > > > different.
> > > > > 
> > > > > The conversion to json_print() was done but it isn't using same conventions
> > > > > as ip or tc.
> > > > > 
> > > > > The correct fix needs to go deeper and hit other things.
> > > > >   
> > > > Hi, Stephen,
> > > > 
> > > > The root cause of this issue is that close_json_object() is being called in
> > > > newline_indent(), resulting in a mismatch
> > > > of {}.
> > > > 
> > > > When fixing this problem, I was unsure why a newline() is needed in pretty
> > > > mode, so I simply kept this logic and
> > > > solved the issue of open_json_object() and close_json_object() not matching.
> > > > However, If the output of pretty mode
> > > > and not-pretty mode should be the same, then this problem can be resolved by
> > > > deleting this newline_indent().  
> > > Stephen didn't say that output of pretty and not-pretty should be the
> > > same, but he said that JSON logic should be the same.
> > > 
> > > Thanks  
> > 
> > Hi, Leon,
> > 
> > Thank you for your reply. But I'm not sure what you mean by JSON logic? I
> > understand that
> > pretty and not-pretty JSON should have the same content, but just difference
> > display effects.
> > Do you mean that they only need to have the same structure?
> > 
> > Or, let's get back to this question. In the JSON format output, the
> > newline() here seems
> > unnecessary, because json_print() can solve the line break problems during
> > printing.
> > So I think the newline() here can be removed at least when outputting in
> > JSON format.  
> 
> I think that your original patch is correct way to fix the mismatch as
> it is not related to pretty/non-pretty.
> 
> Thanks

Part of the problem is the meaning of pretty mode is different in rdma
than all of the other commands. The meaning of the flags should be the
same across ip, devlink, tc, and rdma; therefore pretty should mean
nothing unless json is enabled.

I can do some of the rework here, but don't have any rdma hardware
to test on.

  reply	other threads:[~2024-01-02 16:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-29  6:52 [PATCH iproute2-rc 0/2] Bugfixes for rdmatool Junxian Huang
2023-12-29  6:52 ` [PATCH iproute2-rc 1/2] rdma: Fix core dump when pretty is used Junxian Huang
2023-12-29 17:21   ` Stephen Hemminger
2024-01-02  7:44     ` Chengchang Tang
2024-01-02  8:32       ` Leon Romanovsky
2024-01-02 12:06         ` Chengchang Tang
2024-01-02 12:21           ` Leon Romanovsky
2024-01-02 16:27             ` Stephen Hemminger [this message]
2024-01-02 19:17               ` Leon Romanovsky
2024-01-02 19:29                 ` David Ahern
2023-12-29  6:52 ` [PATCH iproute2-rc 2/2] rdma: Fix the error of accessing string variable outside the lifecycle Junxian Huang
2024-01-08  1:28   ` Junxian Huang
2024-01-08 11:09     ` Petr Machata
2024-01-08 16:10     ` Andrea Claudi
2024-01-08 17:25       ` Stephen Hemminger
2024-01-09  1:36       ` Junxian Huang

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240102082746.651ff7cf@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=dsahern@gmail.com \
    --cc=huangjunxian6@hisilicon.com \
    --cc=jgg@ziepe.ca \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=tangchengchang@huawei.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;
as well as URLs for NNTP newsgroup(s).