From: Wang Yugui <wangyugui@e16-tech.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: linux-rdma@vger.kernel.org, selvin.xavier@broadcom.com,
eddie.wai@broadcom.com
Subject: Re: [PATCH] infiniband: change some kmalloc to kvmalloc to support CONFIG_PROVE_LOCKING=y
Date: Tue, 19 Oct 2021 20:43:16 +0800 [thread overview]
Message-ID: <20211019204315.A760.409509F4@e16-tech.com> (raw)
In-Reply-To: <20211019113722.GG3686969@ziepe.ca>
Hi,
> On Tue, Oct 19, 2021 at 08:26:56AM +0800, wangyugui wrote:
> > When CONFIG_PROVE_LOCKING=y, one kmalloc of infiniband hit the max alloc size limitation.
> >
> > WARNING: CPU: 36 PID: 8 at mm/page_alloc.c:5350 __alloc_pages+0x27e/0x3e0
> > Call Trace:
> > kmalloc_order+0x2a/0xb0
> > kmalloc_order_trace+0x19/0xf0
> > __kmalloc+0x231/0x270
> > ib_setup_port_attrs+0xd8/0x870 [ib_core]
> > ib_register_device+0x419/0x4e0 [ib_core]
> > bnxt_re_task+0x208/0x2d0 [bnxt_re]
> >
> > change this kmalloc to kvmalloc to support CONFIG_PROVE_LOCKING=y
> >
> > Signed-off-by: wangyugui <wangyugui@e16-tech.com>
> > ---
> > drivers/infiniband/core/sysfs.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Huh? what causes ib_port to get larger than MAX_ORDER?
>
> The only array is attrs_list and I don't see something that scales
> with
The array size is not fixed. so it maybe a little big in some case.
struct ib_port {
struct kobject kobj;
struct ib_device *ibdev;
struct gid_attr_group *gid_attr_group;
struct hw_stats_port_data *hw_stats_data;
struct attribute_group groups[3];
const struct attribute_group *groups_list[5];
u32 port_num;
struct port_table_attribute attrs_list[];
};
=>
struct port_table_attribute {
struct ib_port_attribute attr;
=>
struct ib_port_attribute {
struct attribute attr;
=>
struct attribute {
const char *name;
umode_t mode;
#ifdef CONFIG_DEBUG_LOCK_ALLOC
bool ignore_lockdep:1;
struct lock_class_key *key;
struct lock_class_key skey;
#endif
};
When CONFIG_PROVE_LOCKING=y, we need CONFIG_DEBUG_LOCK_ALLOC=y too.
This problem happen when CONFIG_PROVE_LOCKING=y(CONFIG_DEBUG_LOCK_ALLOC=y),
but not happen when CONFIG_PROVE_LOCKING=n(CONFIG_DEBUG_LOCK_ALLOC=n).
Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2021/10/19
next prev parent reply other threads:[~2021-10-19 12:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-19 0:26 [PATCH] infiniband: change some kmalloc to kvmalloc to support CONFIG_PROVE_LOCKING=y wangyugui
2021-10-19 11:37 ` Jason Gunthorpe
2021-10-19 12:43 ` Wang Yugui [this message]
2021-10-20 23:03 ` Jason Gunthorpe
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=20211019204315.A760.409509F4@e16-tech.com \
--to=wangyugui@e16-tech.com \
--cc=eddie.wai@broadcom.com \
--cc=jgg@ziepe.ca \
--cc=linux-rdma@vger.kernel.org \
--cc=selvin.xavier@broadcom.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).