bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add last processor to process stat


From: Samuel Thibault
Subject: Re: [PATCH] Add last processor to process stat
Date: Sun, 27 Oct 2019 17:46:27 +0100
User-agent: NeoMutt/20170609 (1.8.3)

Samuel Thibault, le dim. 27 oct. 2019 17:39:26 +0100, a ecrit:
> Almudena Garcia, le dim. 27 oct. 2019 17:36:55 +0100, a ecrit:
> > > And as I mentioned, cope with caller passing either the old or the new
> > > value of THREAD_SCHED_INFO_COUNT in *thread_info_count
> > 
> > > There, for backward compatibility with existing
> > > binaries, you have to handle both the case where the application
> > > passes the old count (built with the old GNU Mach header defining
> > > THREAD_SCHED_INFO_COUNT), and the case where the application passes the
> > > new count (built with the new header).
> > 
> > I don't understand very well. Where is this? In gnumach or Hurd? 
> 
> In gnumach.
> 
> Really, grep is an extremely powerful tool.

Actually you had already found the place since you patched it.

I mean: thread_info() is passed a pointer to a buffer that it fills. The
caller passes the number of items of the buffer it allocated. GNU Mach
mustn't fill more than that. And it must set into *thread_info_count the
actual amount being filled.

Think about an old program built with the old header, running with
the new GNU Mach. And then conversely a program rebuilt with the new
header, running with the old GNU Mach. The first case really needs to be
fixed.  The second case is less of a concern, it'll just require people
to make sure to upgrade mach to get procfs working correctly. That's
inconvenient so ideally it should be fixed in procfs by checking that
the *thread_info_count count includes the last_processor field, and if
not set it to 0.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]