Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <91238500-61a6-1e2e-1dc2-931c0a23cca8@linux.com>
Date:   Tue, 26 Apr 2022 18:51:04 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Reply-To: alex.popov@linux.com
Subject: Re: [PATCH 0/8] stackleak: fixes and rework
Content-Language: en-US
To:     Kees Cook <keescook@chromium.org>,
        Mark Rutland <mark.rutland@arm.com>
Cc:     linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        akpm@linux-foundation.org, catalin.marinas@arm.com,
        luto@kernel.org, will@kernel.org
References: <20220425115603.781311-1-mark.rutland@arm.com>
 <202204251551.0CFE01DF4@keescook>
From:   Alexander Popov <alex.popov@linux.com>
In-Reply-To: <202204251551.0CFE01DF4@keescook>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 26.04.2022 01:54, Kees Cook wrote:
> On Mon, Apr 25, 2022 at 12:55:55PM +0100, Mark Rutland wrote:
>> This series reworks the stackleak code. The first patch fixes some
>> latent issues on arm64, and the subsequent patches improve the code to
>> improve clarity and permit better code generation.
> 
> This looks nice; thanks! I'll put this through build testing and get it
> applied shortly...
> 
>> While the improvement is small, I think the improvement to clarity and
>> code generation is a win regardless.
> 
> Agreed. I also want to manually inspect the resulting memory just to
> make sure things didn't accidentally regress. There's also an LKDTM test
> for basic functionality.

Hi Mark and Kees!

Glad to see this patch series.

I've looked at it briefly. Mark, I see your questions in the patches that I can 
answer.

Please give me some time, I'm going to work on your patch series next week. I'll 
return with review and testing.

Thanks!
Alexander