t; Since the patch wasn't accepted, i want to know is there another solution?
The patch should be in next-20171106
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordom
On Wed 14-12-16 11:13:11, Alan Stern wrote:
> On Wed, 14 Dec 2016, Michal Hocko wrote:
>
> > On Tue 13-12-16 08:33:34, Alan Stern wrote:
> > > On Tue, 13 Dec 2016, Michal Hocko wrote:
[...]
> > > > Well, my point was that it is not really hard to imagine to
On Tue 13-12-16 08:33:34, Alan Stern wrote:
> On Tue, 13 Dec 2016, Michal Hocko wrote:
>
> > > > That being said, what ep_write_iter does sounds quite stupit. It just
> > > > allocates a large continuous buffer which seems to be under user
> > > > cont
On Mon 12-12-16 16:12:16, Alan Stern wrote:
> On Mon, 12 Dec 2016, Michal Hocko wrote:
>
> > On Mon 12-12-16 21:32:35, Andrey Konovalov wrote:
> > > On Mon, Dec 12, 2016 at 9:31 PM, Andrey Konovalov
> > > wrote:
> > > > Hi!
> > > >
&
ep_write_iter+0x167/0xb50
> > drivers/usb/gadget/legacy/inode.c:664
> > [< inline >] new_sync_write fs/read_write.c:499
> > [] __vfs_write+0x483/0x760 fs/read_write.c:512
> > [] vfs_write+0x170/0x4e0 fs/read_write.c:560
> > [< inline >] SYSC_wr
e that no work item in the rescuer can block on an
* allocation (so no __GF_DIRECT_RECLAIM)
*/
to all work item functions.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue 02-08-16 13:44:48, Oliver Neukum wrote:
> On Tue, 2016-08-02 at 13:34 +0200, Michal Hocko wrote:
> > On Tue 02-08-16 12:03:23, Oliver Neukum wrote:
> > > On Tue, 2016-08-02 at 10:18 +0200, Michal Hocko wrote:
> > > > On Tue 02-08-16 10:06:12, Oliver Neukum wr
On Tue 02-08-16 12:03:23, Oliver Neukum wrote:
> On Tue, 2016-08-02 at 10:18 +0200, Michal Hocko wrote:
> > On Tue 02-08-16 10:06:12, Oliver Neukum wrote:
> > > On Mon, 2016-08-01 at 10:20 -0400, Tejun Heo wrote:
> > > > Hello,
> > >
> > > > >
ce. No question about that. The whole point is that
WQ_RECLAIM might be completely pointless because a rescuer wouldn't help
much if the work item would do GFP_NOIO and get stuck in the page
allocator.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon 01-08-16 14:00:57, Alan Stern wrote:
> On Mon, 1 Aug 2016, Tejun Heo wrote:
>
> > Hello,
> >
> > On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote:
> > > > All that would do is deferring the deadlock, right? I'm not sure it
> >
question is about USB stoage
> devices and memory reclaim. USB doesn't guarantee forward progress
> under memory pressure but tries a best-effort attempt with GFP_NOIO
> and ATOMIC. Is this the right thing to do?
If any real IO depends on those devices then this is not sufficien
11 matches
Mail list logo
