All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: "Alan Maguire" <alan.maguire@oracle.com>,
	"Alexis Lothoré" <alexis.lothore@bootlin.com>,
	dwarves@vger.kernel.org
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
	ebpf@linuxfoundation.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Bastien Curutchet <bastien.curutchet@bootlin.com>
Subject: Re: [PATCH] pahole: do not return an error when printing only a specific class
Date: Wed, 23 Jul 2025 08:37:17 -0700	[thread overview]
Message-ID: <83f3a344-3d7d-44cb-af3c-2029abb0ebe3@linux.dev> (raw)
In-Reply-To: <b8eee8a2-943d-4724-b9b4-f4816b8aea85@oracle.com>

On 7/23/25 3:03 AM, Alan Maguire wrote:
> On 23/07/2025 09:39, Alexis Lothoré wrote:
>> Hi Ihor,
>>
>> On Wed Jul 23, 2025 at 1:42 AM CEST, Ihor Solodrai wrote:
>>> On 7/16/25 2:04 AM, Alexis Lothoré (eBPF Foundation) wrote:
>>
>> [...]
>>
>>>>    	cu__finalize(cu, cus, conf);
>>>> -	if (cus__steal_now(cus, cu, conf) == LSK__STOP_LOADING)
>>>> +	if (cus__steal_now(cus, cu, conf) == LSK__ABORT)
>>>>    		goto out_abort;
>>>
>>> I think we should handle both LSK__STOP_LOADING and LSK__ABORT here,
>>> otherwise the worker will keep loading DWARF (which is most of the
>>> pahole's work) and passing cu-s to the stealer function.
>>>
>>> I guess in many cases it'll complete without errors, but it's just
>>> unnecessary work.
>>>
>>> Maybe add a check for LSK__STOP_LOADING here with goto_ok?
>>
>> Hmmm, I am not sure how to follow you here. Even if cus__steal_now returns
>> LSK__STOP_LOADING, I need to return DWARF_CB_OK from
>> cus__merge_and_process_cu, otherwise it will be processed as an error
>> again. Or are you suggesting just make sure to delete current cu but still
>> return DWARF_CB_OK when getting LSK__STOP_LOADING, as done below ?

LSK__STOP_LOADING signals that no more input needs to be processed.

So I was thinking we should make sure the workers terminate without
error and return DWARF_CB_OK. Whether we delete a cu or not is not
that important since we are exiting soon anyway.

>>
>> --- a/dwarf_loader.c
>> +++ b/dwarf_loader.c
>> @@ -3796,6 +3796,7 @@ static int cus__merge_and_process_cu(struct cus *cus, struct conf_load *conf,
>>          Dwarf_Off off = 0, noff;
>>          struct cu *cu = NULL;
>>          size_t cuhl;
>> +       int res;
>>
>>          while (dwarf_nextcu(dw, off, &noff, &cuhl, NULL, &pointer_size,
>>                              &offset_size) == 0) {
>> @@ -3874,7 +3875,8 @@ static int cus__merge_and_process_cu(struct cus *cus, struct conf_load *conf,
>>                  goto out_abort;
>>
>>          cu__finalize(cu, cus, conf);
>> -       if (cus__steal_now(cus, cu, conf) == LSK__ABORT)
>> +       res = cus__steal_now(cus, cu, conf);
>> +       if (res == LSK__STOP_LOADING || res == LSK__ABORT)
>>                  goto out_abort;
>>
>>          return 0;
>> @@ -3882,7 +3884,7 @@ static int cus__merge_and_process_cu(struct cus *cus, struct conf_load *conf,
>>   out_abort:
>>          dwarf_cu__delete(cu);
>>          cu__delete(cu);
>> -       return DWARF_CB_ABORT;
>> +       return res == LSK__STOP_LOADING ? DWARF_CB_OK : DWARF_CB_ABORT;
>>   }
>>
>>
>> Thanks,
>>
>> Alexis
>>
>>
> 
> Good point; I think ideally we'd like to stop processing in either case
> but still distinguish error from early exit. We could perhaps set the
> appropriate LSK_ value in dcus (dcus->lsk_status?) to make the
> distinction and use it in cus__load_module(), renaming out_error in
> dwarf_cus__process_cu()  to out_early or something to underline the fact
> that it's an early exit not necessarily a failure. So we preserve the
> return of CB_ABORT for both failure and early exit, but can still tell
> these apart using dcus->lsk_status. Would that work?

Good suggestion. Yes, I think that would work better than just return
DWARF_CB_OK from the worker.

I overlooked the fact that there are many workers, and one of them
exiting with DWARF_CB_OK would not affect the others. But
DWARF_CB_ABORT would via the cus_processing_queue.abort flag.



      reply	other threads:[~2025-07-23 15:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-16  9:04 [PATCH] pahole: do not return an error when printing only a specific class Alexis Lothoré (eBPF Foundation)
2025-07-22 23:42 ` Ihor Solodrai
2025-07-23  8:39   ` Alexis Lothoré
2025-07-23 10:03     ` Alan Maguire
2025-07-23 15:37       ` Ihor Solodrai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83f3a344-3d7d-44cb-af3c-2029abb0ebe3@linux.dev \
    --to=ihor.solodrai@linux.dev \
    --cc=acme@redhat.com \
    --cc=alan.maguire@oracle.com \
    --cc=alexis.lothore@bootlin.com \
    --cc=bastien.curutchet@bootlin.com \
    --cc=dwarves@vger.kernel.org \
    --cc=ebpf@linuxfoundation.org \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.