From: Bart Van Assche <bvanassche@acm.org>
To: ZhangHui <zhanghui31@xiaomi.com>, ebiggers@kernel.org
Cc: James.Bottomley@hansenpartnership.com, alim.akhtar@samsung.com,
avri.altman@wdc.com, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
peter.griffin@linaro.org
Subject: Re: [PATCH] ufs: crypto: add host_sem lock in ufshcd_program_key
Date: Fri, 21 Mar 2025 09:53:31 -0700 [thread overview]
Message-ID: <a0da2dc5-80e5-4fd7-92a0-69c399f2a171@acm.org> (raw)
In-Reply-To: <20250321074524.126338-1-zhanghui31@xiaomi.com>
On 3/21/25 12:45 AM, ZhangHui wrote:
> I have checked the device_shutdown process and it seems only wait
> for the resume that has not been processed to be completed, and
> then continue. It does not seem to cause pm_runtime_get_sync to return
> an error.
device_shutdown() is a kernel function. File systems must be unmounted
by user space code before the device_shutdown() kernel function is
called. The sequence followed by systemd is as follows (see also the
systemd source file src/shutdown/shutdown.c):
* Call sync().
* Send SIGTERM and SIGKILL to all running processes.
* Unmount all filesystems, deactivate swap devices, detach loopback
devices, stop md devices and detach dm devices.
* Call sync() again.
* Call the reboot() system call.
From kernel/reboot.c:
SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
void __user *, arg)
{
...
case LINUX_REBOOT_CMD_POWER_OFF:
kernel_power_off();
do_exit(0);
break;
...
}
void kernel_power_off(void)
{
kernel_shutdown_prepare(SYSTEM_POWER_OFF);
if (pm_power_off_prepare)
pm_power_off_prepare();
migrate_to_reboot_cpu();
syscore_shutdown();
pr_emerg("Power down\n");
kmsg_dump(KMSG_DUMP_POWEROFF);
machine_power_off();
}
static void kernel_shutdown_prepare(enum system_states state)
{
blocking_notifier_call_chain(&reboot_notifier_list,
(state == SYSTEM_HALT) ? SYS_HALT : SYS_POWER_OFF, NULL);
system_state = state;
usermodehelper_disable();
device_shutdown();
}
>> Or does the UFS driver still need to check
>> ufshcd_is_user_access_allowed() too? If that's the case, I'm also
>> wondering whether it's okay to nest host_sem inside
>> pm_runtime_get_sync(). Elsewhere in the UFS driver they are>>
called in the opposite order.>
> I found that ufshcd_is_user_access_allowed is used in many places in
> the ufs driver code. What is the historical reason for this?
My understanding is that ufshcd_is_user_access_allowed() is only called
from sysfs and debugfs show and store callbacks. I'd like to remove that
function because my understanding is that access to sysfs and debugfs
attributes stops before the device .shutdown() callbacks are called.
Bart.
prev parent reply other threads:[~2025-03-21 16:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-17 11:01 ZhangHui
2025-03-17 22:32 ` Bart Van Assche
2025-03-19 3:17 ` ZhangHui
2025-03-21 4:44 ` Eric Biggers
2025-03-21 7:45 ` ZhangHui
2025-03-21 16:53 ` Bart Van Assche [this message]
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=a0da2dc5-80e5-4fd7-92a0-69c399f2a171@acm.org \
--to=bvanassche@acm.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=ebiggers@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=peter.griffin@linaro.org \
--cc=zhanghui31@xiaomi.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®