From nobody Tue Jun 16 01:35:59 2026 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8A43F3939CD for ; Wed, 15 Apr 2026 08:12:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776240741; cv=none; b=lbMzm4O+RWbsIeK/sZV7CQGax9seqtNrWn6TIBqUC7YQ7zZN+dBv06OfPqHqM1cHIIhzqstxdwqTiccnxdGxkfnY72MeYr1G021fgyTCa7RDww6dlxW0wg0uPtUtJT9Rfe9CMuQhFrdqaQqofl5b/IjqwOp6CaGiNxqVMb2eEys= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776240741; c=relaxed/simple; bh=N+clSWmKldQgOxT8T5fNV4IIOVNxC8JfASo7QwlxHsc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=nTIfIUAobNNf+1ZT7veGrso8sDh88OFdwj1lQ+VcJRiB1zW1aF5A2290ZQebRs6CBdmuhw2CM+VRwDTKI2ese5pLy+wqNgwjEHBcw70k/8VabUpjOv9pwrxEEVtw22G6nsfuDPPnwOkQHewt43CmQhddrwKKJs5G6WVGnzPWEz0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=N1fNsOs+; arc=none smtp.client-ip=209.85.216.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="N1fNsOs+" Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-35daa02ea08so737148a91.2 for ; Wed, 15 Apr 2026 01:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776240739; x=1776845539; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=5fZYdbSpJsFdiEeS9AF+5M3wDWj7cMyvJAhs73ZaUoM=; b=N1fNsOs+GQacoHqfySTwy0XnK8mWeED/s0cc4B6cckbA8y82g+r1ihG1XpxbT7r8K5 DJsXVFNCCSR0yNr7kFCe57Y8vT/YeBgiIOZITYS6a57sJ09oVla7ZtTSbsthpaBqDW7z gor0b4b3IkMmPJbPUw42qT41xR5zboUn0O6ONWokHnJjmjELc6pUO7V4g0eGpK3gP8C3 cKfQksi4pucDN52ShMdB5+1H1ZH0x8qjEjRhuNbCMwYYmvhfqQ7xoQBr3OC45QjYgw7J 6kImzlLDeFqyK29DiwmLxtOFREPnnU0aJZKR6LAWHz/Fa2faFBIsZn7imCMdTwQ+529y +/Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776240739; x=1776845539; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5fZYdbSpJsFdiEeS9AF+5M3wDWj7cMyvJAhs73ZaUoM=; b=Cn2swnQbLXvMnc1BxjEUkDPCDjjmyYnCOOqfZveKPYUZbfxKIqEi0+DSfTTITDka4a I373RPQnAsv0hwBKKsESXfzlfr7O+eNEplnd97J274IGmMXI+XC3C4r0PIoM8v8qn7Pm N3qdpbQBSDU8QplxaU3zF0fQC/jZY1hciH9I2zNPrwJ5N7LpFmddxx4AJqbClBTPqKaU nuLRib6u9iJToVhbtikbySHUTuiuby9bHNV1kFsbfO5EmqPKHiJ2c1y0Xh8jMgpN9L5w krX0u9H8NzmEP/9XeCJFFy9MIoZtHuhPUjc303fvc5HwFcLfUWRzM+tdkT7FDyi7HQb/ CJew== X-Forwarded-Encrypted: i=1; AFNElJ/RMY6Zbn1FdqPjfE4UiiLCpkv9rbyAUhfR88epUWLEXTyOJCDI7gStLFVQnqfHwLw9l0XS1e7h4NbjPew=@vger.kernel.org X-Gm-Message-State: AOJu0YyNK4dHhMO5X2py+jlzSwTRD2qTmHm3O6a5i2nYsUOakN+y613U Fe0pTHLp70l1rL6RK2TJoyD1MdmQGTQSv2qrJaNFsvqAqrKAlzHodoF3 X-Gm-Gg: AeBDieuiIh01WNagmSZ1sGtDUvxjYVCCZxvEWd7TdgYqV67AOXA3yRnkOHGZoU0Mj+1 WTlRm6NVqTO/00T83hEmqKITVM9sgMknODHwpkGvdEfctCp1zA2hRw7FcEX0710bZD5R8pRjMTZ Y9rABXRfMtKLFaZEjShuoSasBvfwS7Yd8qgRQrCxf0yqcvfNBZG6OGtJxnzsqaPkcF4tR4jajgs BCiAHXqULkFZTjxn3yhUgaTV+qBtiFvlcsigZfrAiIC13HVdnO1GCC8Uj/J006TPS6OD9mkcBzc KE1mzDKLpkR5guc6I4YJq3ioDgDY6VU3N7lMdMr2HIw+XIBHMrN3bwUTuSbgbgTKb4mbpOkP5n2 MLP14MPe8xHNJsvZoOSHAKhMJlxFA7zXPY9dgp1AzDlZejOoex0um0vwEX1cANamtbOOe/azH8o IL2tVON/HNlv5GYKfL X-Received: by 2002:a05:6a21:4cca:b0:39b:b6d2:1f24 with SMTP id adf61e73a8af0-3a05cfad152mr1094977637.0.1776240738578; Wed, 15 Apr 2026 01:12:18 -0700 (PDT) Received: from ser8.. ([221.156.231.192]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c79581bad89sm898869a12.25.2026.04.15.01.12.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 01:12:18 -0700 (PDT) From: DaeMyung Kang To: "Rafael J. Wysocki" Cc: Len Brown , Pavel Machek , Youngjun Park , Andrew Morton , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, DaeMyung Kang Subject: [PATCH] PM: hibernate: align default resume swap with image-device checks Date: Wed, 15 Apr 2026 17:12:13 +0900 Message-ID: <20260415081213.1732019-1-charsyam@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" snapshot_open(O_RDONLY) pins the configured default resume swap area for hibernation image writes, but it does not fully propagate that choice to the image-device checks used by the block layer. In particular, snapshot_open() uses swsusp_resume_device without swsusp_resume_block when pinning the default resume swap area, and it leaves snapshot_state.dev unset even after the pin succeeds. As a result, the default resume swap selected at open time is not kept aligned with is_hibernate_resume_dev() and can still be rejected by the block layer in blkdev_write_iter() with -ETXTBSY until user space explicitly selects the same area via SNAPSHOT_SET_SWAP_AREA. Use swsusp_resume_block when pinning the default resume swap area and record the device immediately after a successful pin so that the hibernation image-device bookkeeping matches the configured resume area. Also clear snapshot_state.dev on the open-time error path so it never advertises a session that failed to fully open. uswsusp itself is not affected because it always calls SNAPSHOT_SET_SWAP_AREA right after open, which immediately overrides snapshot_state.dev and re-pins the swap area. The user-visible change is for minimal hibernation user space that relies on resume=3D and resume_offset=3D alone: such tools no longer have to restate the resume area via SNAPSHOT_SET_SWAP_AREA just to satisfy blkdev_write_iter()'s IS_SWAPFILE gate or to obtain SWP_HIBERNATION swapoff protection. This also matches the intent of the existing "The image device should be accessible" comment in snapshot_open(). For the configured default resume area, this gives snapshot_open() the same pin and recorded-device state that SNAPSHOT_SET_SWAP_AREA would establish for that same area, so user space relying on resume=3D and resume_offset=3D does not need a follow-up SNAPSHOT_SET_SWAP_AREA just to satisfy the IS_SWAPFILE gate and obtain swapoff protection. Signed-off-by: DaeMyung Kang --- Based on linux-next/master at commit e6efabc0afca ("Add linux-next specific files for 20260414"). Tested in QEMU: with swap on a block device pointed to by /sys/power/resume, opening /dev/snapshot O_RDONLY and then writing to the swap block device returned -ETXTBSY before this change and -ENOSPC (i.e. no longer rejected by the IS_SWAPFILE gate) after. kernel/power/user.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/kernel/power/user.c b/kernel/power/user.c index d0fcfba7ac23..c51b8185de4b 100644 --- a/kernel/power/user.c +++ b/kernel/power/user.c @@ -69,9 +69,13 @@ static int snapshot_open(struct inode *inode, struct fil= e *filp) data =3D &snapshot_state; filp->private_data =3D data; memset(&data->handle, 0, sizeof(struct snapshot_handle)); + data->dev =3D 0; if ((filp->f_flags & O_ACCMODE) =3D=3D O_RDONLY) { /* Hibernating. The image device should be accessible. */ - data->swap =3D pin_hibernation_swap_type(swsusp_resume_device, 0); + data->swap =3D pin_hibernation_swap_type(swsusp_resume_device, + swsusp_resume_block); + if (data->swap >=3D 0) + data->dev =3D swsusp_resume_device; data->mode =3D O_RDONLY; data->free_bitmaps =3D false; error =3D pm_notifier_call_chain_robust(PM_HIBERNATION_PREPARE, PM_POST_= HIBERNATION); @@ -92,13 +96,13 @@ static int snapshot_open(struct inode *inode, struct fi= le *filp) } if (error) { unpin_hibernation_swap_type(data->swap); + data->dev =3D 0; hibernate_release(); } =20 data->frozen =3D false; data->ready =3D false; data->platform_support =3D false; - data->dev =3D 0; =20 Unlock: unlock_system_sleep(sleep_flags); --=20 2.43.0