linux-kernel - Re: 4.5.0+ panic when setup loop device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56EB1672.7000002@kernel.dk>
Date:	Thu, 17 Mar 2016 13:41:22 -0700
From:	Jens Axboe <axboe@...nel.dk>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Xiong Zhou <jencce.kernel@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
	Andreas Herrmann <aherrmann@...e.com>
Subject: Re: 4.5.0+ panic when setup loop device

On 03/17/2016 01:30 PM, Thomas Gleixner wrote:
> On Thu, 17 Mar 2016, Jens Axboe wrote:
>> On 03/17/2016 01:20 PM, Thomas Gleixner wrote:
>>>> This might be better, we need to start at -1 to not miss the first one...
>>>> Still untested.
>>>
>>>> +static inline struct blk_mq_ctx *next_ctx(struct request_queue *q, int
>>>> *i)
>>>> +{
>>>> +	do {
>>>> +		(*i)++;
>>>> +		if (*i < q->nr_queues) {
>>>> +			if (cpu_possible(*i))
>>>> +				return per_cpu_ptr(q->queue_ctx, *i);
>>>> +			continue;
>>>> +		}
>>>> +		break;
>>>> +	} while (1);
>>>> +
>>>> +	return NULL;
>>>> +}
>>>> +
>>>> +#define queue_for_each_ctx(q, ctx, i)
>>>> \
>>>> +	for ((i) = -1; (ctx = next_ctx((q), &(i))) != NULL;)
>>>> +
>>>
>>> What's wrong with
>>>
>>>           for_each_possible_cpu(cpu) {
>>>          		ctx = per_cpu_ptr(q->queue_ctx, cpu);
>>>
>>> 		....
>>> 	}
>>>
>>> instead of hiding it behind an incomprehensible macro mess?
>>
>> We might not have mapped all of them.
>
> blk_mq_init_cpu_queues() tells a different story and q->queue_ctx is a per_cpu
> allocation.

Yeah my bad, I mistook the possible for online. So we can do the easier fix.

-- 
Jens Axboe