linux-kernel - Re: [PATCH v3 1/6] remoteproc: Introduce custom dump function for each remoteproc segment

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: <002930d1f2515a5988f98a3bb1a5ceed@codeaurora.org>
Date:   Tue, 09 Oct 2018 21:38:46 +0530
From:   Sibi Sankar <sibis@...eaurora.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
        ohad@...ery.com, kyan@...eaurora.org, sricharan@...eaurora.org,
        akdwived@...eaurora.org, linux-arm-msm@...r.kernel.org,
        tsoni@...eaurora.org, linux-remoteproc-owner@...r.kernel.org
Subject: Re: [PATCH v3 1/6] remoteproc: Introduce custom dump function for
 each remoteproc segment

Hi Bjorn,
Thanks for the review :)

On 2018-10-08 11:53, Bjorn Andersson wrote:
> On Fri 27 Jul 08:19 PDT 2018, Sibi Sankar wrote:
> 
>> Introduce custom dump function per remoteproc segment. It is 
>> responsible
>> for filling the device memory segment associated with coredump
>> 
>> Signed-off-by: Sibi Sankar <sibis@...eaurora.org>
>> ---
>>  drivers/remoteproc/remoteproc_core.c | 15 ++++++++++-----
>>  include/linux/remoteproc.h           |  3 +++
>>  2 files changed, 13 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/remoteproc/remoteproc_core.c 
>> b/drivers/remoteproc/remoteproc_core.c
>> index 283b258f5e0f..ec56cd822b26 100644
>> --- a/drivers/remoteproc/remoteproc_core.c
>> +++ b/drivers/remoteproc/remoteproc_core.c
>> @@ -1183,13 +1183,18 @@ static void rproc_coredump(struct rproc 
>> *rproc)
>>  		phdr->p_align = 0;
>> 
>>  		ptr = rproc_da_to_va(rproc, segment->da, segment->size);
>> -		if (!ptr) {
>> -			dev_err(&rproc->dev,
>> +
>> +		if (segment->dump) {
>> +			segment->dump(rproc, ptr, segment->size, data + offset);
> 
> rproc_da_to_va() is an exported symbol, so if you pass segment to the
> dump function the driver can, if it needs to, call the function itself.
> 
> A typical use case, that I see, is to use the custom dump function to
> write out CPU or hardware state to the dump file, in which case the 
> "da"
> won't be valid.
> 
> 
> So please make this call dump(rproc, segment, data + offset) and move
> the rproc_da_to_va() into the else block.
> 

yup will redefine it.

>> +		} else {
>> +			if (!ptr) {
>> +				dev_err(&rproc->dev,
>>  				"invalid coredump segment (%pad, %zu)\n",
>>  				&segment->da, segment->size);
>> -			memset(data + offset, 0xff, segment->size);
>> -		} else {
>> -			memcpy(data + offset, ptr, segment->size);
>> +				memset(data + offset, 0xff, segment->size);
>> +			} else {
>> +				memcpy(data + offset, ptr, segment->size);
>> +			}
>>  		}
>> 
>>  		offset += phdr->p_filesz;
>> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>> index e3c5d856b6da..0fbb01a9955c 100644
>> --- a/include/linux/remoteproc.h
>> +++ b/include/linux/remoteproc.h
>> @@ -399,6 +399,8 @@ enum rproc_crash_type {
>>   * @node:	list node related to the rproc segment list
>>   * @da:		device address of the segment
>>   * @size:	size of the segment
>> + * @dump:	custom dump function to fill device memory segment 
>> associated
>> + *		with coredump
>>   */
>>  struct rproc_dump_segment {
>>  	struct list_head node;
>> @@ -406,6 +408,7 @@ struct rproc_dump_segment {
>>  	dma_addr_t da;
>>  	size_t size;
>> 
>> +	void (*dump)(struct rproc *rproc, void *ptr, size_t len, void 
>> *priv);
> 
> "priv" isn't the best name to represent the memory to which you expect
> dump to write to. Please call it "dest".
> 

will rename it

>>  	loff_t offset;
>>  };
> 
> Regards,
> Bjorn

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.