| Message ID | 20180105171909.11839-2-bart.vanassche@wdc.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Fri, Jan 5, 2018 at 6:19 PM, Bart Van Assche <bart.vanassche@wdc.com> wrote: > Since pm_mutex is not exported using lock/unlock_system_sleep() from > inside a kernel module causes a "pm_mutex undefined" linker error. > Hence move lock/unlock_system_sleep() into kernel/power/main.c and > export these. > > Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com> > Cc: Rafael J. Wysocki <rjw@rjwysocki.net> > --- > include/linux/suspend.h | 28 ++-------------------------- > kernel/power/main.c | 29 +++++++++++++++++++++++++++++ > 2 files changed, 31 insertions(+), 26 deletions(-) > > diff --git a/include/linux/suspend.h b/include/linux/suspend.h > index d60b0f5c38d5..cc22a24516d6 100644 > --- a/include/linux/suspend.h > +++ b/include/linux/suspend.h > @@ -443,32 +443,8 @@ extern bool pm_save_wakeup_count(unsigned int count); > extern void pm_wakep_autosleep_enabled(bool set); > extern void pm_print_active_wakeup_sources(void); > > -static inline void lock_system_sleep(void) > -{ > - current->flags |= PF_FREEZER_SKIP; > - mutex_lock(&pm_mutex); > -} > - > -static inline void unlock_system_sleep(void) > -{ > - /* > - * Don't use freezer_count() because we don't want the call to > - * try_to_freeze() here. > - * > - * Reason: > - * Fundamentally, we just don't need it, because freezing condition > - * doesn't come into effect until we release the pm_mutex lock, > - * since the freezer always works with pm_mutex held. > - * > - * More importantly, in the case of hibernation, > - * unlock_system_sleep() gets called in snapshot_read() and > - * snapshot_write() when the freezing condition is still in effect. > - * Which means, if we use try_to_freeze() here, it would make them > - * enter the refrigerator, thus causing hibernation to lockup. > - */ > - current->flags &= ~PF_FREEZER_SKIP; > - mutex_unlock(&pm_mutex); > -} > +extern void lock_system_sleep(void); > +extern void unlock_system_sleep(void); > > #else /* !CONFIG_PM_SLEEP */ Don't you need to add stubs for this case too? > diff --git a/kernel/power/main.c b/kernel/power/main.c > index 3a2ca9066583..705c2366dafe 100644 > --- a/kernel/power/main.c > +++ b/kernel/power/main.c > @@ -22,6 +22,35 @@ DEFINE_MUTEX(pm_mutex); > > #ifdef CONFIG_PM_SLEEP > > +void lock_system_sleep(void) > +{ > + current->flags |= PF_FREEZER_SKIP; > + mutex_lock(&pm_mutex); > +} > +EXPORT_SYMBOL_GPL(lock_system_sleep); > + > +void unlock_system_sleep(void) > +{ > + /* > + * Don't use freezer_count() because we don't want the call to > + * try_to_freeze() here. > + * > + * Reason: > + * Fundamentally, we just don't need it, because freezing condition > + * doesn't come into effect until we release the pm_mutex lock, > + * since the freezer always works with pm_mutex held. > + * > + * More importantly, in the case of hibernation, > + * unlock_system_sleep() gets called in snapshot_read() and > + * snapshot_write() when the freezing condition is still in effect. > + * Which means, if we use try_to_freeze() here, it would make them > + * enter the refrigerator, thus causing hibernation to lockup. > + */ > + current->flags &= ~PF_FREEZER_SKIP; > + mutex_unlock(&pm_mutex); > +} > +EXPORT_SYMBOL_GPL(unlock_system_sleep); > + > /* Routines for PM-transition notifications */ > > static BLOCKING_NOTIFIER_HEAD(pm_chain_head); > -- The changes are fine by me, but I really would prefer them to go in via the PM tree which I guess means that the second patch would need to go in this way too. Thanks, Rafael
On Sat, 2018-01-06 at 00:00 +0100, Rafael J. Wysocki wrote: > The changes are fine by me, but I really would prefer them to go in > via the PM tree which I guess means that the second patch would need > to go in this way too. Hello Rafael, If I can get a Tested-by from Woody and an Acked-by from Martin then I can do that. Thanks, Bart.
On Sat, Jan 6, 2018 at 12:32 AM, Bart Van Assche <Bart.VanAssche@wdc.com> wrote: > On Sat, 2018-01-06 at 00:00 +0100, Rafael J. Wysocki wrote: >> The changes are fine by me, but I really would prefer them to go in >> via the PM tree which I guess means that the second patch would need >> to go in this way too. > > Hello Rafael, > > If I can get a Tested-by from Woody and an Acked-by from Martin then I can > do that. That would be an ACK from Marting for the second patch. OK
diff --git a/include/linux/suspend.h b/include/linux/suspend.h index d60b0f5c38d5..cc22a24516d6 100644 --- a/include/linux/suspend.h +++ b/include/linux/suspend.h @@ -443,32 +443,8 @@ extern bool pm_save_wakeup_count(unsigned int count); extern void pm_wakep_autosleep_enabled(bool set); extern void pm_print_active_wakeup_sources(void); -static inline void lock_system_sleep(void) -{ - current->flags |= PF_FREEZER_SKIP; - mutex_lock(&pm_mutex); -} - -static inline void unlock_system_sleep(void) -{ - /* - * Don't use freezer_count() because we don't want the call to - * try_to_freeze() here. - * - * Reason: - * Fundamentally, we just don't need it, because freezing condition - * doesn't come into effect until we release the pm_mutex lock, - * since the freezer always works with pm_mutex held. - * - * More importantly, in the case of hibernation, - * unlock_system_sleep() gets called in snapshot_read() and - * snapshot_write() when the freezing condition is still in effect. - * Which means, if we use try_to_freeze() here, it would make them - * enter the refrigerator, thus causing hibernation to lockup. - */ - current->flags &= ~PF_FREEZER_SKIP; - mutex_unlock(&pm_mutex); -} +extern void lock_system_sleep(void); +extern void unlock_system_sleep(void); #else /* !CONFIG_PM_SLEEP */ diff --git a/kernel/power/main.c b/kernel/power/main.c index 3a2ca9066583..705c2366dafe 100644 --- a/kernel/power/main.c +++ b/kernel/power/main.c @@ -22,6 +22,35 @@ DEFINE_MUTEX(pm_mutex); #ifdef CONFIG_PM_SLEEP +void lock_system_sleep(void) +{ + current->flags |= PF_FREEZER_SKIP; + mutex_lock(&pm_mutex); +} +EXPORT_SYMBOL_GPL(lock_system_sleep); + +void unlock_system_sleep(void) +{ + /* + * Don't use freezer_count() because we don't want the call to + * try_to_freeze() here. + * + * Reason: + * Fundamentally, we just don't need it, because freezing condition + * doesn't come into effect until we release the pm_mutex lock, + * since the freezer always works with pm_mutex held. + * + * More importantly, in the case of hibernation, + * unlock_system_sleep() gets called in snapshot_read() and + * snapshot_write() when the freezing condition is still in effect. + * Which means, if we use try_to_freeze() here, it would make them + * enter the refrigerator, thus causing hibernation to lockup. + */ + current->flags &= ~PF_FREEZER_SKIP; + mutex_unlock(&pm_mutex); +} +EXPORT_SYMBOL_GPL(unlock_system_sleep); + /* Routines for PM-transition notifications */ static BLOCKING_NOTIFIER_HEAD(pm_chain_head);
Since pm_mutex is not exported using lock/unlock_system_sleep() from inside a kernel module causes a "pm_mutex undefined" linker error. Hence move lock/unlock_system_sleep() into kernel/power/main.c and export these. Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> --- include/linux/suspend.h | 28 ++-------------------------- kernel/power/main.c | 29 +++++++++++++++++++++++++++++ 2 files changed, 31 insertions(+), 26 deletions(-)