Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758612AbbGQPW4 (ORCPT ); Fri, 17 Jul 2015 11:22:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60869 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752797AbbGQPWy (ORCPT ); Fri, 17 Jul 2015 11:22:54 -0400 Date: Fri, 17 Jul 2015 11:22:53 -0400 From: Mike Snitzer To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Alasdair Kergon , Neil Brown , "Rafael J. Wysocki" , Len Brown , Pavel Machek , linux-raid@vger.kernel.org, dm-devel@redhat.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: Re: [PATCH v2 2/3] dm: Export function dm_suspend_md() Message-ID: <20150717152253.GA1021@redhat.com> References: <1428254419-7334-1-git-send-email-pali.rohar@gmail.com> <1434885634-19895-1-git-send-email-pali.rohar@gmail.com> <1434885634-19895-3-git-send-email-pali.rohar@gmail.com> <20150717140438.GA29704@redhat.com> <20150717142251.GA12011@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150717142251.GA12011@pali> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3213 Lines: 80 On Fri, Jul 17 2015 at 10:22am -0400, Pali Roh?r wrote: > On Friday 17 July 2015 10:04:39 Mike Snitzer wrote: > > On Sun, Jun 21 2015 at 7:20am -0400, > > Pali Roh?r wrote: > > > > > This patch exports function dm_suspend_md() which suspend mapped device so other > > > kernel drivers can use it and could suspend mapped device when needed. > > > > > > Signed-off-by: Pali Roh?r > > > --- > > > drivers/md/dm.c | 6 ++++++ > > > drivers/md/dm.h | 5 +++++ > > > 2 files changed, 11 insertions(+) > > > > > > diff --git a/drivers/md/dm.c b/drivers/md/dm.c > > > index 2caf492..03298ff 100644 > > > --- a/drivers/md/dm.c > > > +++ b/drivers/md/dm.c > > > @@ -3343,6 +3343,12 @@ out: > > > return r; > > > } > > > > > > +int dm_suspend_md(struct mapped_device *md) > > > +{ > > > + return dm_suspend(md, DM_SUSPEND_LOCKFS_FLAG); > > > +} > > > +EXPORT_SYMBOL_GPL(dm_suspend_md); > > > + > > > /* > > > * Internal suspend/resume works like userspace-driven suspend. It waits > > > * until all bios finish and prevents issuing new bios to the target drivers. > > > > To do this properly you should be introducing a variant of > > dm_internal_suspend. We currently have two variants: > > dm_internal_suspend_fast > > dm_internal_suspend_noflush > > > > The reason to use a dm_internal_suspend variant is this suspend was > > _not_ initiated by an upper level ioctl (from userspace). It was > > done internally from within the target. > > > > You're explicitly using DM_SUSPEND_LOCKFS_FLAG above.. meaning you're > > interested in flushing all pending IO (in the FS layered on dm-crupt, if > > one exists). > > > > But see the comment in __dm_internal_suspend() about TASK_UNINTERRUPTIBLE. > > If you're OK with the dm-crypt initiated suspend being > > TASK_UNINTERRUPTIBLE then you could just introduce: > > > > void dm_internal_suspend_uninterruptible_flush(struct mapped_device *md) > > { > > mutex_lock(&md->suspend_lock); > > __dm_internal_suspend(md, DM_SUSPEND_LOCKFS_FLAG); > > mutex_unlock(&md->suspend_lock); > > } > > EXPORT_SYMBOL_GPL(dm_internal_suspend_uninterruptible_flush); > > > > Otherwise, there is much more extensive DM core changes needed to > > __dm_internal_suspend() and .presuspend to properly support > > TASK_INTERRUPTIBLE. > > Hi! I will look at dm_internal_suspend. Anyway use case for suspend is > from dm-crypt to do both operations: suspend + key wipe. It means that > without entering key again from userspace, resume is not possible. So my > question is: It is possible to do internal suspend and then using resume > from userspace via ioctl? Good question: no, userspace resume would block waiting for internal resume. Soooo... I'll have to look at your patch 3 to understand why dm-crypt is needing to initiate the suspend internally but then userspace is initiating the resume... this imbalance is concerning. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/