public inbox for passt-user@passt.top
 help / color / mirror / Atom feed
* Re: Can't pipe output of pasta --version
       [not found] ` <1378983862.3469095.1748366479602@mail.yahoo.com>
@ 2025-05-28  2:25   ` David Gibson
  2025-05-28  7:45     ` Stefano Brivio
       [not found]     ` <174841834113.3062894.7293539982980796043@maja>
  0 siblings, 2 replies; 4+ messages in thread
From: David Gibson @ 2025-05-28  2:25 UTC (permalink / raw)
  To: John Radley (jradxl2); +Cc: passt-user

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

On Tue, May 27, 2025 at 05:21:19PM +0000, John Radley (jradxl2) wrote:
> Hello,I can't pipe output like this:-
> $ pasta --version | grep pasta<blank!>
> but this works:-
> $ sudo apt install expect
> $ unbuffer pasta --version | grep pasta
> pasta 2025_05_12.8ec1341-9-g3262c9b
> 
> If this is the intended action, please can you tell me why?

Ouch.  No, that's not intended.

I initially assumed this was because we were sending the version
information to stderr instead of stdout, but that's not the case.

This is a bug introduced by d0006fa78 ("treewide: use _exit() over
exit()").  For --version we're displaying the information with
fprintf(), then immediately exiting with _exit().  When writing to a
pipe, stdout is buffered.  Normally the buffer would be flushed before
exiting, but using _exit() bypasses that.

We could fix this specific problem by adding an fflush(stdout) before
the _exit().  However, I worry that there might be other bugs we have
because we're not running libc installed exit handlers here and
elsewhere.  I was already a bit dubious about using _exit() by
default, and now I really don't think it was a good idea.

That said, I don't immediately have a better idea of how to address
the problem d0006fa78 was aiming to fix in the first place.

Well... I'm on holiday at the moment, so I won't be fixing it.
Laurent & Stefano, I hope the analysis above is helpful.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Can't pipe output of pasta --version
  2025-05-28  2:25   ` Can't pipe output of pasta --version David Gibson
@ 2025-05-28  7:45     ` Stefano Brivio
       [not found]     ` <174841834113.3062894.7293539982980796043@maja>
  1 sibling, 0 replies; 4+ messages in thread
From: Stefano Brivio @ 2025-05-28  7:45 UTC (permalink / raw)
  To: David Gibson; +Cc: John Radley (jradxl2), passt-user, Paul Holzinger

[Cc: Paul as author of d0006fa78]

On Wed, 28 May 2025 12:25:10 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Tue, May 27, 2025 at 05:21:19PM +0000, John Radley (jradxl2) wrote:
> > Hello,I can't pipe output like this:-
> > $ pasta --version | grep pasta<blank!>
> > but this works:-
> > $ sudo apt install expect
> > $ unbuffer pasta --version | grep pasta
> > pasta 2025_05_12.8ec1341-9-g3262c9b
> > 
> > If this is the intended action, please can you tell me why?  
> 
> Ouch.  No, that's not intended.
> 
> I initially assumed this was because we were sending the version
> information to stderr instead of stdout, but that's not the case.
> 
> This is a bug introduced by d0006fa78 ("treewide: use _exit() over
> exit()").  For --version we're displaying the information with
> fprintf(), then immediately exiting with _exit().  When writing to a
> pipe, stdout is buffered.  Normally the buffer would be flushed before
> exiting, but using _exit() bypasses that.
> 
> We could fix this specific problem by adding an fflush(stdout) before
> the _exit().  However, I worry that there might be other bugs we have
> because we're not running libc installed exit handlers here and
> elsewhere.  I was already a bit dubious about using _exit() by
> default, and now I really don't think it was a good idea.

Well, that's something we looked into (of course...), and (I?) concluded
that we never needed to flush stdio, which is the only otherwise useful
thing glibc handlers would do for us, and which kind of holds... except
for this case. And maybe for --help or any "early" exit.

So we could fflush() as well in those cases, and just in those
cases, with the added benefit that we don't need to add additional
system calls to the permitted seccomp set, because if we exit early, we
didn't install the seccomp filter yet.

> That said, I don't immediately have a better idea of how to address
> the problem d0006fa78 was aiming to fix in the first place.
> 
> Well... I'm on holiday at the moment, so I won't be fixing it.
> Laurent & Stefano, I hope the analysis above is helpful.

I'm on holiday too, I'll fix this later this week or next week, unless
Paul is particularly inspired (or John wants to look into the issue a
bit further and contribute a patch...?).

-- 
Stefano


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Can't pipe output of pasta --version
       [not found]     ` <174841834113.3062894.7293539982980796043@maja>
@ 2025-05-28 23:31       ` Jon Maloy
  2025-05-30  8:10         ` Stefano Brivio
  0 siblings, 1 reply; 4+ messages in thread
From: Jon Maloy @ 2025-05-28 23:31 UTC (permalink / raw)
  To: passt-user



On 2025-05-28 03:45, Stefano Brivio via user wrote:
> [Cc: Paul as author of d0006fa78]
> 
> On Wed, 28 May 2025 12:25:10 +1000
> David Gibson<david@gibson.dropbear.id.au> wrote:
> 
>> On Tue, May 27, 2025 at 05:21:19PM +0000, John Radley (jradxl2) wrote:
>>> Hello,I can't pipe output like this:-
>>> $ pasta --version | grep pasta<blank!>
>>> but this works:-
>>> $ sudo apt install expect
>>> $ unbuffer pasta --version | grep pasta
>>> pasta 2025_05_12.8ec1341-9-g3262c9b
>>>
>>> If this is the intended action, please can you tell me why?
>> Ouch.  No, that's not intended.
>>
>> I initially assumed this was because we were sending the version
>> information to stderr instead of stdout, but that's not the case.
>>
>> This is a bug introduced by d0006fa78 ("treewide: use _exit() over
>> exit()").  For --version we're displaying the information with
>> fprintf(), then immediately exiting with _exit().  When writing to a
>> pipe, stdout is buffered.  Normally the buffer would be flushed before
>> exiting, but using _exit() bypasses that.
>>
>> We could fix this specific problem by adding an fflush(stdout) before
>> the _exit().  However, I worry that there might be other bugs we have
>> because we're not running libc installed exit handlers here and
>> elsewhere.  I was already a bit dubious about using _exit() by
>> default, and now I really don't think it was a good idea.
> Well, that's something we looked into (of course...), and (I?) concluded
> that we never needed to flush stdio, which is the only otherwise useful
> thing glibc handlers would do for us, and which kind of holds... except
> for this case. And maybe for --help or any "early" exit.
> 
> So we could fflush() as well in those cases, and just in those
> cases, with the added benefit that we don't need to add additional
> system calls to the permitted seccomp set, because if we exit early, we
> didn't install the seccomp filter yet.
> 
>> That said, I don't immediately have a better idea of how to address
>> the problem d0006fa78 was aiming to fix in the first place.
>>
>> Well... I'm on holiday at the moment, so I won't be fixing it.
>> Laurent & Stefano, I hope the analysis above is helpful.
> I'm on holiday too, I'll fix this later this week or next week, unless
> Paul is particularly inspired (or John wants to look into the issue a
> bit further and contribute a patch...?).

I'll take a look tomorrow.
/jon

> 
> -- Stefano
> 
> 
> _______________________________________________
> user mailing list --passt-user@passt.top
> To unsubscribe send an email topasst-user-leave@passt.top


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Can't pipe output of pasta --version
  2025-05-28 23:31       ` Jon Maloy
@ 2025-05-30  8:10         ` Stefano Brivio
  0 siblings, 0 replies; 4+ messages in thread
From: Stefano Brivio @ 2025-05-30  8:10 UTC (permalink / raw)
  To: Jon Maloy; +Cc: passt-user, John Radley (jradxl2), Paul Holzinger

On Wed, 28 May 2025 19:31:42 -0400
Jon Maloy <jmaloy@redhat.com> wrote:

> On 2025-05-28 03:45, Stefano Brivio via user wrote:
> > [Cc: Paul as author of d0006fa78]
> > 
> > On Wed, 28 May 2025 12:25:10 +1000
> > David Gibson<david@gibson.dropbear.id.au> wrote:
> >   
> >> On Tue, May 27, 2025 at 05:21:19PM +0000, John Radley (jradxl2) wrote:  
> >>> Hello,I can't pipe output like this:-
> >>> $ pasta --version | grep pasta<blank!>
> >>> but this works:-
> >>> $ sudo apt install expect
> >>> $ unbuffer pasta --version | grep pasta
> >>> pasta 2025_05_12.8ec1341-9-g3262c9b
> >>>
> >>> If this is the intended action, please can you tell me why?  
> >> Ouch.  No, that's not intended.
> >>
> >> I initially assumed this was because we were sending the version
> >> information to stderr instead of stdout, but that's not the case.
> >>
> >> This is a bug introduced by d0006fa78 ("treewide: use _exit() over
> >> exit()").  For --version we're displaying the information with
> >> fprintf(), then immediately exiting with _exit().  When writing to a
> >> pipe, stdout is buffered.  Normally the buffer would be flushed before
> >> exiting, but using _exit() bypasses that.
> >>
> >> We could fix this specific problem by adding an fflush(stdout) before
> >> the _exit().  However, I worry that there might be other bugs we have
> >> because we're not running libc installed exit handlers here and
> >> elsewhere.  I was already a bit dubious about using _exit() by
> >> default, and now I really don't think it was a good idea.  
> > Well, that's something we looked into (of course...), and (I?) concluded
> > that we never needed to flush stdio, which is the only otherwise useful
> > thing glibc handlers would do for us, and which kind of holds... except
> > for this case. And maybe for --help or any "early" exit.
> > 
> > So we could fflush() as well in those cases, and just in those
> > cases, with the added benefit that we don't need to add additional
> > system calls to the permitted seccomp set, because if we exit early, we
> > didn't install the seccomp filter yet.
> >   
> >> That said, I don't immediately have a better idea of how to address
> >> the problem d0006fa78 was aiming to fix in the first place.
> >>
> >> Well... I'm on holiday at the moment, so I won't be fixing it.
> >> Laurent & Stefano, I hope the analysis above is helpful.  
> > I'm on holiday too, I'll fix this later this week or next week, unless
> > Paul is particularly inspired (or John wants to look into the issue a
> > bit further and contribute a patch...?).  
> 
> I'll take a look tomorrow.

Patch with review thread now at:

  https://archives.passt.top/passt-dev/20250529170858.185281-1-jmaloy@redhat.com/

-- 
Stefano


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-05-30  8:10 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1378983862.3469095.1748366479602.ref@mail.yahoo.com>
     [not found] ` <1378983862.3469095.1748366479602@mail.yahoo.com>
2025-05-28  2:25   ` Can't pipe output of pasta --version David Gibson
2025-05-28  7:45     ` Stefano Brivio
     [not found]     ` <174841834113.3062894.7293539982980796043@maja>
2025-05-28 23:31       ` Jon Maloy
2025-05-30  8:10         ` Stefano Brivio

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).