public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tasmiya Nalatwad <tasmiya@linux.vnet.ibm.com>
To: Waiman Long <longman@redhat.com>, linux-kernel@vger.kernel.org
Cc: peterz@infradead.org, abdhalee@linux.vnet.ibm.com,
	mingo@redhat.com, will@kernel.org, boqun.feng@gmail.com
Subject: Re: [linux-next][mainline/master] [IPR] [Function could be = "__mutex_lock_slowpath(lock)"]OOPs kernel crash while performing IPR test
Date: Tue, 29 Aug 2023 11:00:09 +0530	[thread overview]
Message-ID: <ad9167de-8d62-a2d6-b139-b02c6a35df4f@linux.vnet.ibm.com> (raw)
In-Reply-To: <731c0ca3-d9db-cbcd-ab64-876a5e689054@redhat.com>

Greetings,

Thank you Waiman Long for your analysis. The issue is seen consistently 
on every build of linux-next and mainline/master

On 8/27/23 21:39, Waiman Long wrote:
>
> On 8/27/23 04:26, Tasmiya Nalatwad wrote:
>> Greetings,
>>
>> [linux-next][mainline/master] [IPR] [Function could be = 
>> "__mutex_lock_slowpath(lock)"]OOPs kernel crash while performing IPR 
>> test
>>
>> --- Traces ---
>>
>> --- Traces ---
>> [65818.211823] Kernel attempted to read user page (380) - exploit 
>> attempt? (uid: 0)
>> [65818.211836] BUG: Kernel NULL pointer dereference on read at 
>> 0x00000380
>> [65818.211840] Faulting instruction address: 0xc000000000f5f2e4
>> [65818.211844] Oops: Kernel access of bad area, sig: 11 [#1]
>> [65818.211846] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=8192 NUMA pSeries
>> [65818.211850] Modules linked in: rpadlpar_io rpaphp nfnetlink 
>> xsk_diag bonding tls rfkill sunrpc ses enclosure scsi_transport_sas 
>> vmx_crypto pseries_rng binfmt_misc ip_tables ext4 mbcache jbd2 
>> dm_service_time sd_mod t10_pi crc64_rocksoft crc64 sg ibmvfc 
>> scsi_transport_fc ibmveth ipr dm_multipath dm_mirror dm_region_hash 
>> dm_log dm_mod fuse
>> [65818.211879] CPU: 16 PID: 613 Comm: kworker/16:3 Kdump: loaded Not 
>> tainted 6.5.0-rc7-next-20230824-auto #1
>> [65818.211883] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 
>> 0xf000006 of:IBM,FW1030.30 (NH1030_062) hv:phyp pSeries
>> [65818.211887] Workqueue: events sg_remove_sfp_usercontext [sg]
>> [65818.211894] NIP:  c000000000f5f2e4 LR: c000000000f5f2d8 CTR: 
>> c00000000032df70
>> [65818.211897] REGS: c0000000081c7a10 TRAP: 0300   Not tainted 
>> (6.5.0-rc7-next-20230824-auto)
>> [65818.211900] MSR:  800000000280b033 
>> <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 28000882  XER: 20040000
>> [65818.211909] CFAR: c000000000f5b0a4 DAR: 0000000000000380 DSISR: 
>> 40000000 IRQMASK: 0
>> [65818.211909] GPR00: c000000000f5f2d8 c0000000081c7cb0 
>> c000000001451300 0000000000000000
>> [65818.211909] GPR04: 00000000000000c0 00000000c0000000 
>> c000000006c5a298 98a2c506000000c0
>> [65818.211909] GPR08: c00000006408ab00 c0000000022a3515 
>> 0000000000000000 c008000000327d60
>> [65818.211909] GPR12: c00000000032df70 c000000c1bc93f00 
>> c000000000197cc8 c000000008797500
>> [65818.211909] GPR16: 0000000000000000 0000000000000000 
>> 0000000000000000 c000000003071ab0
>> [65818.211909] GPR20: c000000003494c05 c000000c11340040 
>> 0000000000000000 c0000000b9bb4030
>> [65818.211909] GPR24: c0000000b9bb4000 c00000005e8627c0 
>> 0000000000000000 c000000c19b91e00
>> [65818.211909] GPR28: c0000000b9bb5328 c00000005e8627c0 
>> 0000000000000380 0000000000000380
>> [65818.211946] NIP [c000000000f5f2e4] mutex_lock+0x34/0x90
>> [65818.211953] LR [c000000000f5f2d8] mutex_lock+0x28/0x90
>> [65818.211957] Call Trace:
>> [65818.211959] [c0000000081c7cb0] [c000000000f5f2d8] 
>> mutex_lock+0x28/0x90 (unreliable)
>> [65818.211966] [c0000000081c7ce0] [c00000000032df9c] 
>> blk_trace_remove+0x2c/0x80
>> [65818.211971] [c0000000081c7d10] [c0080000003205fc] 
>> sg_device_destroy+0x44/0x110 [sg]
>> [65818.211976] [c0000000081c7d90] [c008000000322988] 
>> sg_remove_sfp_usercontext+0x1d0/0x2c0 [sg]
>> [65818.211981] [c0000000081c7e40] [c000000000188010] 
>> process_scheduled_works+0x230/0x4f0
>> [65818.211987] [c0000000081c7f10] [c00000000018b044] 
>> worker_thread+0x1e4/0x500
>> [65818.211992] [c0000000081c7f90] [c000000000197df8] kthread+0x138/0x140
>> [65818.211996] [c0000000081c7fe0] [c00000000000df98] 
>> start_kernel_thread+0x14/0x18 
>
> The panic happens when a device is being removed. Maybe it is a 
> use-after-free problem. The mutex lock itself seems to be in an area 
> that is no longer accessible. It is not a problem in the locking code 
> itself.
>
> Cheers,
> Longman
>
-- 
Regards,
Tasmiya Nalatwad
IBM Linux Technology Center


  reply	other threads:[~2023-08-29  5:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-27  8:26 [linux-next][mainline/master] [IPR] [Function could be = "__mutex_lock_slowpath(lock)"]OOPs kernel crash while performing IPR test Tasmiya Nalatwad
2023-08-27 16:09 ` Waiman Long
2023-08-29  5:30   ` Tasmiya Nalatwad [this message]
2024-01-29 19:23 ` Mohamed Khalfella

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=ad9167de-8d62-a2d6-b139-b02c6a35df4f@linux.vnet.ibm.com \
    --to=tasmiya@linux.vnet.ibm.com \
    --cc=abdhalee@linux.vnet.ibm.com \
    --cc=boqun.feng@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=will@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
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