Hello, Tahsin.
On Thu, Mar 02, 2017 at 02:33:11PM -0800, Tahsin Erdogan wrote:
> > And let blkg_create() verify these conditions after releasing and
> > regrabbing the lock.
> >
> > This also means that the init path can simply pass in GFP_KERNEL.
>
> I tried that approach, but I encountered two
On Thu, Mar 2, 2017 at 11:32 AM, Tejun Heo wrote:
> Hello, Tahsin.
>
> On Wed, Mar 01, 2017 at 03:43:19PM -0800, Tahsin Erdogan wrote:
>> @@ -258,18 +258,22 @@ static struct blkcg_gq *blkg_create(struct blkcg
>> *blkcg,
>> struct blkcg_gq *blkg_lookup_create(struct blkcg *blkcg,
>> -
Hello, Tahsin.
On Wed, Mar 01, 2017 at 03:43:19PM -0800, Tahsin Erdogan wrote:
> @@ -258,18 +258,22 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg,
> struct blkcg_gq *blkg_lookup_create(struct blkcg *blkcg,
> - struct request_queue *q)
> +
Hi Tejun,
>
> Ah, indeed, but we can break out allocation of blkg and its
> initialization, right? It's a bit more work but then we'd be able to
> do something like.
>
>
> retry:
> new_blkg = alloc;
> lock;
> sanity checks;
> blkg = blkg_lookup_and_create(..., new_b
blkg_conf_prep() currently calls blkg_lookup_create() while holding
request queue spinlock. This means allocating memory for struct
blkcg_gq has to be made non-blocking. This causes occasional -ENOMEM
failures in call paths like below:
pcpu_alloc+0x68f/0x710
__alloc_percpu_gfp+0xd/0x10
__per
