On Mon, Oct 05, 2015 at 07:12:17PM -0700, Andrew Morton wrote:
> On Mon, 5 Oct 2015 12:29:36 -0700 Andrew Morton
> wrote:
>
> > Maybe it would be better to add the gfp_t argument to the
> > address_space_operations. At a minimum, writepage(), readpage(),
> > writepages(), readpages(). What a p
On Mon, 5 Oct 2015 12:29:36 -0700 Andrew Morton
wrote:
> Maybe it would be better to add the gfp_t argument to the
> address_space_operations. At a minimum, writepage(), readpage(),
> writepages(), readpages(). What a pickle.
I'm being dumb. All we need to do is to add a new
address
On Mon, 5 Oct 2015 15:47:13 +0200 Michal Hocko wrote:
> > The fourth best way of fixing this is a nasty short-term bodge, such a
> > the one you just sent ;) But if we're going to do this, it should be
> > the minimal bodge which fixes this deadlock. Is it possible to come up
> > with a one-line
On Fri 02-10-15 13:49:53, Andrew Morton wrote:
[...]
> There's a lot of confusion here, so let's try to do some clear
> thinking.
>
> mapping_gfp_mask() describes the mask to be used for allocating this
> mapping's pagecache pages. Nothing else. I introduced it to provide a
> clean way to ensure
On Fri, 2 Oct 2015 09:25:23 +0200 Michal Hocko wrote:
> 6afdb859b710 ("mm: do not ignore mapping_gfp_mask in page cache allocation
> paths") has caught some users of hardcoded GFP_KERNEL used in the page
> cache allocation paths. This, however, wasn't complete and there were
> others which went
On Fri 02-10-15 06:36:57, Guenter Roeck wrote:
> On 10/01/2015 01:49 PM, Andrew Morton wrote:
> >On Thu, 1 Oct 2015 09:06:15 -0700 Guenter Roeck wrote:
> >
> >>Seen with next-20151001, running qemu, simulating Opteron_G1 with a non-SMP
> >>configuration.
> >>On a re-run, I have seen it with the s
On 10/01/2015 01:49 PM, Andrew Morton wrote:
On Thu, 1 Oct 2015 09:06:15 -0700 Guenter Roeck wrote:
Seen with next-20151001, running qemu, simulating Opteron_G1 with a non-SMP
configuration.
On a re-run, I have seen it with the same image, but this time when simulating
IvyBridge,
so it is no
On Fri 02-10-15 09:25:22, Michal Hocko wrote:
> On Thu 01-10-15 13:49:04, Andrew Morton wrote:
[...]
> > Now, we could redefine mapping_gfp_mask()'s purpose (or formalize
> > stuff which has been sneaking in anyway). Treat mapping_gfp_mask() as
> > a constraint mask - instead of it being "use this
On Thu 01-10-15 13:49:04, Andrew Morton wrote:
[...]
> mpage_readpage() is getting the __GFP_HIGHMEM from mapping_gfp_mask()
> and that got passed all the way into kmem_cache_alloc() to allocate a
> bio. slab goes BUG if asked for highmem.
>
> A fix would be to mask off __GFP_HIGHMEM right there
On Thu, 1 Oct 2015 09:06:15 -0700 Guenter Roeck wrote:
> Seen with next-20151001, running qemu, simulating Opteron_G1 with a non-SMP
> configuration.
> On a re-run, I have seen it with the same image, but this time when
> simulating IvyBridge,
> so it is not CPU dependent. I did not previously
On Thu, 1 Oct 2015, Guenter Roeck wrote:
> Seen with next-20151001, running qemu, simulating Opteron_G1 with a non-SMP
> configuration.
> On a re-run, I have seen it with the same image, but this time when simulating
> IvyBridge,
> so it is not CPU dependent. I did not previously see the problem.
11 matches
Mail list logo
