Linux-RDMA Archive on lore.kernel.org
 help / color / Atom feed
From: Jason Gunthorpe <jgg@mellanox.com>
To: Dennis Dalessandro <dennis.dalessandro@intel.com>
Cc: "dledford@redhat.com" <dledford@redhat.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	Mike Marciniszyn <mike.marciniszyn@intel.com>,
	Ira Weiny <ira.weiny@intel.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Kaike Wan <kaike.wan@intel.com>
Subject: Re: [PATCH for-next 3/3] IB/hfi1: Define variables as unsigned long to fix KASAN warning
Date: Fri, 13 Sep 2019 12:05:00 +0000
Message-ID: <20190912161219.GA15092@mellanox.com> (raw)
In-Reply-To: <20190911113053.126040.47327.stgit@awfm-01.aw.intel.com>

On Wed, Sep 11, 2019 at 07:30:53AM -0400, Dennis Dalessandro wrote:
> From: Ira Weiny <ira.weiny@intel.com>
> 
> Define the working variables to be unsigned long to be compatible with
> for_each_set_bit and change types as needed.
> 
> While we are at it remove unused variables from a couple of functions.
> 
> This was found because of the following KASAN warning:
> [ 1383.018461] ==================================================================
> [ 1383.029116] BUG: KASAN: stack-out-of-bounds in find_first_bit+0x19/0x70
> [ 1383.038646] Read of size 8 at addr ffff888362d778d0 by task kworker/u308:2/1889
> [ 1383.049006]
> [ 1383.052766] CPU: 21 PID: 1889 Comm: kworker/u308:2 Tainted: G W         5.3.0-rc2-mm1+ #2
> [ 1383.064765] Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.02.04.0003.102320141138 10/23/2014
> [ 1383.078498] Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
> [ 1383.087314] Call Trace:
> [ 1383.092211]  dump_stack+0x9a/0xf0
> [ 1383.098074]  ? find_first_bit+0x19/0x70
> [ 1383.104546]  print_address_description+0x6c/0x332
> [ 1383.111986]  ? find_first_bit+0x19/0x70
> [ 1383.118443]  ? find_first_bit+0x19/0x70
> [ 1383.124882]  __kasan_report.cold.6+0x1a/0x3b
> [ 1383.131808]  ? find_first_bit+0x19/0x70
> [ 1383.138244]  kasan_report+0xe/0x12
> [ 1383.144169]  find_first_bit+0x19/0x70
> [ 1383.150413]  pma_get_opa_portstatus+0x5cc/0xa80 [hfi1]
> [ 1383.158275]  ? ret_from_fork+0x3a/0x50
> [ 1383.164583]  ? pma_get_opa_port_ectrs+0x200/0x200 [hfi1]
> [ 1383.172629]  ? stack_trace_consume_entry+0x80/0x80
> [ 1383.180097]  hfi1_process_mad+0x39b/0x26c0 [hfi1]
> [ 1383.187420]  ? __lock_acquire+0x65e/0x21b0
> [ 1383.194081]  ? clear_linkup_counters+0xb0/0xb0 [hfi1]
> [ 1383.201788]  ? check_chain_key+0x1d7/0x2e0
> [ 1383.208391]  ? lock_downgrade+0x3a0/0x3a0
> [ 1383.214906]  ? match_held_lock+0x2e/0x250
> [ 1383.221479]  ib_mad_recv_done+0x698/0x15e0 [ib_core]
> [ 1383.229187]  ? clear_linkup_counters+0xb0/0xb0 [hfi1]
> [ 1383.236977]  ? ib_mad_send_done+0xc80/0xc80 [ib_core]
> [ 1383.244778]  ? mark_held_locks+0x79/0xa0
> [ 1383.251341]  ? _raw_spin_unlock_irqrestore+0x44/0x60
> [ 1383.259086]  ? rvt_poll_cq+0x1e1/0x340 [rdmavt]
> [ 1383.266362]  __ib_process_cq+0x97/0x100 [ib_core]
> [ 1383.273822]  ib_cq_poll_work+0x31/0xb0 [ib_core]
> [ 1383.281169]  process_one_work+0x4ee/0xa00
> [ 1383.287822]  ? pwq_dec_nr_in_flight+0x110/0x110
> [ 1383.295047]  ? do_raw_spin_lock+0x113/0x1d0
> [ 1383.301880]  worker_thread+0x57/0x5a0
> [ 1383.308138]  ? process_one_work+0xa00/0xa00
> [ 1383.314937]  kthread+0x1bb/0x1e0
> [ 1383.320643]  ? kthread_create_on_node+0xc0/0xc0
> [ 1383.327822]  ret_from_fork+0x3a/0x50
> [ 1383.333928]
> [ 1383.337640] The buggy address belongs to the page:
> [ 1383.345080] page:ffffea000d8b5dc0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0
> [ 1383.356490] flags: 0x17ffffc0000000()
> [ 1383.362705] raw: 0017ffffc0000000 0000000000000000 ffffea000d8b5dc8 0000000000000000
> [ 1383.373530] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
> [ 1383.384321] page dumped because: kasan: bad access detected
> [ 1383.392659]
> [ 1383.396350] addr ffff888362d778d0 is located in stack of task kworker/u308:2/1889 at offset 32 in frame:
> [ 1383.409191]  pma_get_opa_portstatus+0x0/0xa80 [hfi1]
> [ 1383.416843]
> [ 1383.420497] this frame has 1 object:
> [ 1383.426494]  [32, 36) 'vl_select_mask'
> [ 1383.426495]
> [ 1383.436313] Memory state around the buggy address:
> [ 1383.443706]  ffff888362d77780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 1383.453865]  ffff888362d77800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 1383.464033] >ffff888362d77880: 00 00 00 00 00 00 f1 f1 f1 f1 04 f2 f2 f2 00 00
> [ 1383.474199]                                                  ^
> [ 1383.482828]  ffff888362d77900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 1383.493071]  ffff888362d77980: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f2 f2 f2
> [ 1383.503314]
> ==================================================================
> 
> Cc: <stable@vger.kernel.org>
> Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>

This needs a fixes line, can you tell me what it is?

> -		for_each_set_bit(vl, (unsigned long *)&(vl_all_mask),
> -				 8 * sizeof(vl_all_mask)) {

Well, that was obviously wrong!

Jason

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-11 11:30 [PATCH for-next 0/3] hfi1 and rdmavt fixes for next cycle Dennis Dalessandro
2019-09-11 11:30 ` [PATCH for-next 1/3] IB/hfi1: Add traces for TID RDMA READ Dennis Dalessandro
2019-09-11 11:30 ` [PATCH for-next 2/3] IB/{rdmavt, hfi1, qib}: Add a counter for credit waits Dennis Dalessandro
2019-09-11 11:30 ` [PATCH for-next 3/3] IB/hfi1: Define variables as unsigned long to fix KASAN warning Dennis Dalessandro
2019-09-13 12:05   ` Jason Gunthorpe [this message]
2019-09-13 12:43     ` Marciniszyn, Mike
2019-09-16 13:58 ` [PATCH for-next 0/3] hfi1 and rdmavt fixes for next cycle Jason Gunthorpe

Reply instructions:

You may reply publically 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=20190912161219.GA15092@mellanox.com \
    --to=jgg@mellanox.com \
    --cc=dennis.dalessandro@intel.com \
    --cc=dledford@redhat.com \
    --cc=ira.weiny@intel.com \
    --cc=kaike.wan@intel.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mike.marciniszyn@intel.com \
    --cc=stable@vger.kernel.org \
    /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

Linux-RDMA Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-rdma/0 linux-rdma/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-rdma linux-rdma/ https://lore.kernel.org/linux-rdma \
		linux-rdma@vger.kernel.org linux-rdma@archiver.kernel.org
	public-inbox-index linux-rdma


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-rdma


AGPL code for this site: git clone https://public-inbox.org/ public-inbox