LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org> To: akuster@mvista.com Cc: linux-kernel@vger.kernel.org, akpm@osdl.org Subject: Re: [patch 1/1] PM: Adds remount fs ro at suspend Date: Sat, 3 Feb 2007 10:08:49 +0000 [thread overview] Message-ID: <20070203100848.GA28806@infradead.org> (raw) In-Reply-To: <20070202235132.EDBDF1C448@hermes.mvista.com> On Fri, Feb 02, 2007 at 01:50:10PM -1000, akuster@mvista.com wrote: > > > This adds the ability for the file system to remounted as read only during a > system suspend. Log the mount points so when the resume occurs, they can be > remounted back to their original states. This is so in an advent of a power > failure, we try our best to keep data from being corrupted or lost. Can you please explain why this can't be done in userspace? In fact all existing suspend solutions seem to be doing fine doing things like this in userspace. > +static struct suspremount *suspremount_list; > + > +void suspend_remount_log_fs(struct super_block *sb) > +{ > + struct suspremount *remountp; > + > + if ((remountp = (struct suspremount *) > + kmalloc(sizeof(struct suspremount), GFP_KERNEL)) != NULL) { No need to cast kmalloc return values, and please split assignments and conditionals into separate lines. > + * Remount filesystems prior to suspend, in case the > + * power source is removed (ie, battery removed) or > + * battery dies during suspend. > + */ > + > +void suspend_remount_all_fs_ro(void) > +{ > + suspremount_list = NULL; > + emergency_remount(); NACK. emergency_remount is exactly what it sais and should never ever be used for a system that you want to keep on using later on. If you look at it's implementation it's not correct and can't serve as more than a bandaid for susrq. In fact we should probably just remove it.. > +EXPORT_SYMBOL(suspend_remount_all_fs_ro); And something like this for sure should not be exported. > +EXPORT_SYMBOL(resume_remount_fs_rw); ditto.
next prev parent reply other threads:[~2007-02-03 10:08 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-02-02 23:50 [patch 1/1] PM: Adds remount fs ro at suspend akuster 2007-02-03 0:16 ` Andrew Morton 2007-02-03 0:35 ` Henrique de Moraes Holschuh 2007-02-05 21:28 ` Nigel Cunningham 2007-02-05 21:35 ` Christoph Hellwig 2007-02-06 14:32 ` Henrique de Moraes Holschuh 2007-02-06 18:07 ` Rafael J. Wysocki 2007-02-06 21:38 ` Nigel Cunningham 2007-02-07 11:25 ` Henrique de Moraes Holschuh 2007-02-07 11:43 ` Nigel Cunningham 2007-02-07 12:05 ` Henrique de Moraes Holschuh 2007-02-07 14:10 ` Rafael J. Wysocki 2007-02-09 22:24 ` Pavel Machek 2007-02-13 12:12 ` Pavel Machek 2007-02-03 0:57 ` akuster 2007-02-03 10:08 ` Christoph Hellwig [this message] 2007-02-04 1:34 ` akuster 2007-02-05 16:56 ` Christoph Hellwig 2007-02-14 11:07 ` Pavel Machek 2007-02-03 16:19 ` Pavel Machek
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=20070203100848.GA28806@infradead.org \ --to=hch@infradead.org \ --cc=akpm@osdl.org \ --cc=akuster@mvista.com \ --cc=linux-kernel@vger.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: linkBe 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; as well as URLs for NNTP newsgroup(s).