On Wed, Oct 31, 2012 at 11:41 PM, Alan Stern wrote:
>
> Sorry, I misread your message. You are setting the device's flag, not
> the thread's flag.
Never mind.
>
> This still doesn't help in this case where CONFIG_PM_RUNTIME is
> disabled. I think it will be simpler to set the noio flag during
On Wed, 31 Oct 2012, Alan Stern wrote:
> On Wed, 31 Oct 2012, Ming Lei wrote:
>
> > The below idea may help the problem which 'memalloc_noio' flag isn't set
> > during
> > usb_reset_device().
> >
> > - for usb mass storage device, call pm_runtime_set_memalloc_noio(true)
> > inside
On Wed, 31 Oct 2012, Ming Lei wrote:
> The below idea may help the problem which 'memalloc_noio' flag isn't set
> during
> usb_reset_device().
>
> - for usb mass storage device, call pm_runtime_set_memalloc_noio(true)
> inside usb_stor_probe2() and uas_probe(), and call
>
On Wednesday 31 October 2012 11:05:33 Ming Lei wrote:
> On Wed, Oct 31, 2012 at 10:08 AM, Ming Lei wrote:
> >> I am afraid it is, because a disk may just have been probed as the
> >> deviceis being reset.
> >
> > Yes, it is probable, and sounds like similar with 'root_wait' problem, see
> >
On Wednesday 31 October 2012 11:05:33 Ming Lei wrote:
On Wed, Oct 31, 2012 at 10:08 AM, Ming Lei ming@canonical.com wrote:
I am afraid it is, because a disk may just have been probed as the
deviceis being reset.
Yes, it is probable, and sounds like similar with 'root_wait' problem,
On Wed, 31 Oct 2012, Ming Lei wrote:
The below idea may help the problem which 'memalloc_noio' flag isn't set
during
usb_reset_device().
- for usb mass storage device, call pm_runtime_set_memalloc_noio(true)
inside usb_stor_probe2() and uas_probe(), and call
On Wed, 31 Oct 2012, Alan Stern wrote:
On Wed, 31 Oct 2012, Ming Lei wrote:
The below idea may help the problem which 'memalloc_noio' flag isn't set
during
usb_reset_device().
- for usb mass storage device, call pm_runtime_set_memalloc_noio(true)
inside usb_stor_probe2() and
On Wed, Oct 31, 2012 at 11:41 PM, Alan Stern st...@rowland.harvard.edu wrote:
Sorry, I misread your message. You are setting the device's flag, not
the thread's flag.
Never mind.
This still doesn't help in this case where CONFIG_PM_RUNTIME is
disabled. I think it will be simpler to set
On Wed, Oct 31, 2012 at 10:08 AM, Ming Lei wrote:
>> I am afraid it is, because a disk may just have been probed as the deviceis
>> being reset.
>
> Yes, it is probable, and sounds like similar with 'root_wait' problem, see
> prepare_namespace(): init/do_mounts.c, so looks no good solution
> for
On Wed, Oct 31, 2012 at 12:30 AM, Oliver Neukum wrote:
>> If the USB mass-storage device is being reseted, the flag should be set
>> already generally. If the flag is still unset, that means the disk/network
>> device isn't added into system(or removed just now), so memory allocation
>> with
On Wed, 31 Oct 2012, Ming Lei wrote:
> On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern
> wrote:
>
> >
> > Okay, I see your point. But acquiring the lock here doesn't solve the
> > problem. Suppose a thread is about to reset a USB mass-storage device.
> > It acquires the lock and sees that the
On Wednesday 31 October 2012 00:00:56 Ming Lei wrote:
> On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern
> wrote:
>
> >
> > Okay, I see your point. But acquiring the lock here doesn't solve the
> > problem. Suppose a thread is about to reset a USB mass-storage device.
> > It acquires the lock and
On Wed, Oct 31, 2012 at 12:00 AM, Ming Lei wrote:
>
> Looks the simplest approach is to handle the noio flag thing at the start and
> end of rpm_resume.
Sorry, that doesn't work, runtime_suspend need that too because memory
allocation with block I/O might deadlock when doing I/O on the same
On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern wrote:
>
> Okay, I see your point. But acquiring the lock here doesn't solve the
> problem. Suppose a thread is about to reset a USB mass-storage device.
> It acquires the lock and sees that the noio flag is clear. But before
> it can issue the
On Tue, 30 Oct 2012, Ming Lei wrote:
> >> +bool pm_runtime_get_memalloc_noio(struct device *dev)
> >> +{
> >> + bool ret;
> >> + spin_lock_irq(>power.lock);
> >> + ret = dev->power.memalloc_noio_resume;
> >> + spin_unlock_irq(>power.lock);
> >> + return ret;
> >> +}
> >
> >
Hi,
On Tue, Oct 30, 2012 at 6:57 PM, Oliver Neukum wrote:
> how is this to work with power management domains?
Could you explain it in a bit detail? Why is PM domain involved?
Suppose PM domain is involved, its domain runtime_resume callback
is still run in the context with PF_MEMALLOC_NOIO
On Tuesday 30 October 2012 11:21:33 Ming Lei wrote:
> On Mon, Oct 29, 2012 at 11:41 PM, Alan Stern
> wrote:
> > On Mon, 29 Oct 2012, Ming Lei wrote:
> >
> >> The patch introduces the flag of memalloc_noio_resume in
> >> 'struct dev_pm_info' to help PM core to teach mm not allocating
> >> memory
On Tuesday 30 October 2012 11:21:33 Ming Lei wrote:
On Mon, Oct 29, 2012 at 11:41 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On Mon, 29 Oct 2012, Ming Lei wrote:
The patch introduces the flag of memalloc_noio_resume in
'struct dev_pm_info' to help PM core to teach mm not allocating
Hi,
On Tue, Oct 30, 2012 at 6:57 PM, Oliver Neukum oneu...@suse.de wrote:
how is this to work with power management domains?
Could you explain it in a bit detail? Why is PM domain involved?
Suppose PM domain is involved, its domain runtime_resume callback
is still run in the context with
On Tue, 30 Oct 2012, Ming Lei wrote:
+bool pm_runtime_get_memalloc_noio(struct device *dev)
+{
+ bool ret;
+ spin_lock_irq(dev-power.lock);
+ ret = dev-power.memalloc_noio_resume;
+ spin_unlock_irq(dev-power.lock);
+ return ret;
+}
You don't need to acquire
On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern st...@rowland.harvard.edu wrote:
Okay, I see your point. But acquiring the lock here doesn't solve the
problem. Suppose a thread is about to reset a USB mass-storage device.
It acquires the lock and sees that the noio flag is clear. But before
On Wed, Oct 31, 2012 at 12:00 AM, Ming Lei ming@canonical.com wrote:
Looks the simplest approach is to handle the noio flag thing at the start and
end of rpm_resume.
Sorry, that doesn't work, runtime_suspend need that too because memory
allocation with block I/O might deadlock when doing
On Wednesday 31 October 2012 00:00:56 Ming Lei wrote:
On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern st...@rowland.harvard.edu
wrote:
Okay, I see your point. But acquiring the lock here doesn't solve the
problem. Suppose a thread is about to reset a USB mass-storage device.
It
On Wed, 31 Oct 2012, Ming Lei wrote:
On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern st...@rowland.harvard.edu
wrote:
Okay, I see your point. But acquiring the lock here doesn't solve the
problem. Suppose a thread is about to reset a USB mass-storage device.
It acquires the lock and
On Wed, Oct 31, 2012 at 12:30 AM, Oliver Neukum oneu...@suse.de wrote:
If the USB mass-storage device is being reseted, the flag should be set
already generally. If the flag is still unset, that means the disk/network
device isn't added into system(or removed just now), so memory allocation
On Wed, Oct 31, 2012 at 10:08 AM, Ming Lei ming@canonical.com wrote:
I am afraid it is, because a disk may just have been probed as the deviceis
being reset.
Yes, it is probable, and sounds like similar with 'root_wait' problem, see
prepare_namespace(): init/do_mounts.c, so looks no good
On Mon, Oct 29, 2012 at 11:41 PM, Alan Stern wrote:
> On Mon, 29 Oct 2012, Ming Lei wrote:
>
>> The patch introduces the flag of memalloc_noio_resume in
>> 'struct dev_pm_info' to help PM core to teach mm not allocating
>> memory with GFP_KERNEL flag for avoiding probable deadlock
>> problem.
>>
On Mon, 29 Oct 2012, Ming Lei wrote:
> The patch introduces the flag of memalloc_noio_resume in
> 'struct dev_pm_info' to help PM core to teach mm not allocating
> memory with GFP_KERNEL flag for avoiding probable deadlock
> problem.
>
> As explained in the comment, any GFP_KERNEL allocation
The patch introduces the flag of memalloc_noio_resume in
'struct dev_pm_info' to help PM core to teach mm not allocating
memory with GFP_KERNEL flag for avoiding probable deadlock
problem.
As explained in the comment, any GFP_KERNEL allocation inside
runtime_resume on any one of device in the
On Mon, Oct 29, 2012 at 11:41 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 29 Oct 2012, Ming Lei wrote:
The patch introduces the flag of memalloc_noio_resume in
'struct dev_pm_info' to help PM core to teach mm not allocating
memory with GFP_KERNEL flag for avoiding probable
The patch introduces the flag of memalloc_noio_resume in
'struct dev_pm_info' to help PM core to teach mm not allocating
memory with GFP_KERNEL flag for avoiding probable deadlock
problem.
As explained in the comment, any GFP_KERNEL allocation inside
runtime_resume on any one of device in the
On Mon, 29 Oct 2012, Ming Lei wrote:
The patch introduces the flag of memalloc_noio_resume in
'struct dev_pm_info' to help PM core to teach mm not allocating
memory with GFP_KERNEL flag for avoiding probable deadlock
problem.
As explained in the comment, any GFP_KERNEL allocation inside
32 matches
Mail list logo
