mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: hejunhao <hejunhao3@huawei.com>
To: Jonathan Cameron <Jonathan.Cameron@Huawei.com>, <linuxarm@huawei.com>
Cc: <suzuki.poulose@arm.com>, <james.clark@arm.com>,
	<coresight@lists.linaro.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <yangyicong@huawei.com>,
	<prime.zeng@hisilicon.com>
Subject: Re: [PATCH 1/3] coresight: ultrasoc-smb: fix sleep while close preempt in enable_smb
Date: Sat, 21 Oct 2023 15:25:09 +0800	[thread overview]
Message-ID: <2f6c2af0-b867-5be5-ed37-c5d71b1ed1ce@huawei.com> (raw)
In-Reply-To: <20231019142956.00005a3b@huawei.com>

Hi Jonathan,


On 2023/10/19 21:30, Jonathan Cameron wrote:
> On Thu, 12 Oct 2023 17:47:04 +0800
> Junhao He <hejunhao3@huawei.com> wrote:
>
>> When we to enable the SMB by perf, the perf sched will call perf_ctx_lock()
>> to close system preempt in event_function_call(). But SMB::enable_smb() use
>> mutex to lock the critical section, which may sleep.
>>
>>   BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
>>   in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 153023, name: perf
>>   preempt_count: 2, expected: 0
>>   RCU nest depth: 0, expected: 0
>>   INFO: lockdep is turned off.
>>   irq event stamp: 0
>>   hardirqs last  enabled at (0): [<0000000000000000>] 0x0
>>   hardirqs last disabled at (0): [<ffffa2983f5c5f40>] copy_process+0xae8/0x2b48
>>   softirqs last  enabled at (0): [<ffffa2983f5c5f40>] copy_process+0xae8/0x2b48
>>   softirqs last disabled at (0): [<0000000000000000>] 0x0
>>   CPU: 2 PID: 153023 Comm: perf Kdump: loaded Tainted: G   W  O   6.5.0-rc4+ #1
>>
>>   Call trace:
>>   ...
>>    __mutex_lock+0xbc/0xa70
>>    mutex_lock_nested+0x34/0x48
>>    smb_update_buffer+0x58/0x360 [ultrasoc_smb]
>>    etm_event_stop+0x204/0x2d8 [coresight]
>>    etm_event_del+0x1c/0x30 [coresight]
>>    event_sched_out+0x17c/0x3b8
>>    group_sched_out.part.0+0x5c/0x208
>>    __perf_event_disable+0x15c/0x210
>>    event_function+0xe0/0x230
>>    remote_function+0xb4/0xe8
>>    generic_exec_single+0x160/0x268
>>    smp_call_function_single+0x20c/0x2a0
>>    event_function_call+0x20c/0x220
>>    _perf_event_disable+0x5c/0x90
>>    perf_event_for_each_child+0x58/0xc0
>>    _perf_ioctl+0x34c/0x1250
>>    perf_ioctl+0x64/0x98
>> ...
>>
>> Use spinlock replace mutex to control driver data access to one at a
>> time. But the function copy_to_user() may sleep so spinlock do not to
>> lock it.
> I'd like to see a comment on why we no longer need to lock over the copy_to_user
> rather than simply that we can't.

Yes, I will do that.

>> Fixes: 06f5c2926aaa ("drivers/coresight: Add UltraSoc System Memory Buffer driver")
>> Signed-off-by: Junhao He <hejunhao3@huawei.com>
> A follow up patch could change a lot of this to use the new cleanup.h (don't want that
> in the fix though as will make back porting trickier.).
> That should let you do
> guard(spin_lock)(&drvdata->spinlock);
> and then use direct returns instead of goto complexity.
>
>
>
> Jonathan

Thanks for sharing.
I will append up a new patch to use guards to reduce gotos.

>
>> @@ -132,10 +132,8 @@ static ssize_t smb_read(struct file *file, char __user *data, size_t len,
>>   	if (!len)
>>   		return 0;
>>   
>> -	mutex_lock(&drvdata->mutex);
>> -
>>   	if (!sdb->data_size)
>> -		goto out;
>> +		return 0;
>>   
>>   	to_copy = min(sdb->data_size, len);
>>   
>> @@ -145,20 +143,18 @@ static ssize_t smb_read(struct file *file, char __user *data, size_t len,
>>   
>>   	if (copy_to_user(data, sdb->buf_base + sdb->buf_rdptr, to_copy)) {
>>   		dev_dbg(dev, "Failed to copy data to user\n");
>> -		to_copy = -EFAULT;
>> -		goto out;
>> +		return -EFAULT;
>>   	}
>>   
>> +	spin_lock(&drvdata->spinlock);
>>   	*ppos += to_copy;
>> -
> Unrelated white space change that shouldn't be here.

Ok, i will drop this white space



Thanks for the comments!

Best regards,
Junhao.

>
>>   	smb_update_read_ptr(drvdata, to_copy);
>>   
>> -	dev_dbg(dev, "%zu bytes copied\n", to_copy);
>> -out:
>>   	if (!sdb->data_size)
>>   		smb_reset_buffer(drvdata);
>> -	mutex_unlock(&drvdata->mutex);
>> +	spin_unlock(&drvdata->spinlock);
>>   
>> +	dev_dbg(dev, "%zu bytes copied\n", to_copy);
>>   	return to_copy;
>>   }
>
> .
>


  reply	other threads:[~2023-10-21  7:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-12  9:47 [PATCH 0/3] Fixed some issues and cleanup of ultrasoc-smb Junhao He
2023-10-12  9:47 ` [PATCH 1/3] coresight: ultrasoc-smb: fix sleep while close preempt in enable_smb Junhao He
2023-10-19  3:05   ` Yicong Yang
2023-10-19 12:45     ` hejunhao
2023-10-19 13:30   ` Jonathan Cameron
2023-10-21  7:25     ` hejunhao [this message]
2023-10-12  9:47 ` [PATCH 2/3] coresight: ultrasoc-smb: simplify the code for check to_copy valid Junhao He
2023-10-19 13:35   ` Jonathan Cameron
2023-10-20  2:33     ` hejunhao
2023-10-12  9:47 ` [PATCH 3/3] coresight: ultrasoc-smb: fix uninitialized before use buf_hw_base Junhao He
2023-10-19  2:34   ` Yicong Yang
2023-10-19 13:08     ` hejunhao

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=2f6c2af0-b867-5be5-ed37-c5d71b1ed1ce@huawei.com \
    --to=hejunhao3@huawei.com \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=coresight@lists.linaro.org \
    --cc=james.clark@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=prime.zeng@hisilicon.com \
    --cc=suzuki.poulose@arm.com \
    --cc=yangyicong@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

all inboxes | Powered by JetHome®