Messages in this thread | | | From | "Rafael J. Wysocki" <> | Date | Tue, 2 Jan 2024 14:15:17 +0100 | Subject | Re: [PATCH v1 2/3] async: Introduce async_schedule_dev_nocall() |
| |
On Tue, Jan 2, 2024 at 8:10 AM Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> wrote: > > On Fri, Dec 29, 2023 at 05:36:01PM +0100, Rafael J. Wysocki wrote: > > On Fri, Dec 29, 2023 at 3:54 PM Stanislaw Gruszka > > <stanislaw.gruszka@linux.intel.com> wrote: > > > > > > On Fri, Dec 29, 2023 at 02:37:36PM +0100, Rafael J. Wysocki wrote: > > > > > > +bool async_schedule_dev_nocall(async_func_t func, struct device *dev) > > > > > > +{ > > > > > > + struct async_entry *entry; > > > > > > + > > > > > > + entry = kzalloc(sizeof(struct async_entry), GFP_KERNEL); > > > > > > > > > > Is GFP_KERNEL intended here ? > > > > > > > > Yes, it is. > > > > > > > > PM will be the only user of this, at least for now, and it all runs in > > > > process context. > > > > > > > > > I think it's not safe since will > > > > > be called from device_resume_noirq() . > > > > > > > > device_resume_noirq() runs in process context too. > > > > > > > > The name is somewhat confusing (sorry about that) and it means that > > > > hardirq handlers (for the majority of IRQs) don't run in that resume > > > > phase, but interrupts are enabled locally on all CPUs (this is > > > > required for wakeup handling, among other things). > > > > > > Then my concern would be: if among devices with disabled IRQs are > > > disk devices? Seems there are disk devices as well, and because > > > GFP_KERNEL can start reclaiming memory by doing disk IO (write > > > dirty pages for example), with disk driver interrupts disabled > > > reclaiming process can not finish. > > > > > > I do not see how such possible infinite waiting for disk IO > > > scenario is prevented here, did I miss something? > > > > Well, it is not a concern, because the suspend code already prevents > > the mm subsystem from trying too hard to find free memory. See the > > pm_restrict_gfp_mask() call in enter_state(). > > So that I missed :-) Thanks for explanations. > > Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> for the series.
Thank you!
| |