Messages in this thread | | | Subject | Re: [PATCH v2 1/2] pid: Replace pid bitmap implementation with IDR API | From | Rik van Riel <> | Date | Mon, 02 Oct 2017 09:14:34 -0400 |
| |
On Sun, 2017-10-01 at 16:05 +0530, Gargi Sharma wrote: > On Sun, Oct 1, 2017 at 2:45 PM, Christoph Hellwig <hch@infradead.org> > wrote: > > > - task_active_pid_ns(current)->last_pid); > > > + task_active_pid_ns(current)->idr.idr_next-1); > > > > I think we want a well documented helper for this pattern instead > > of poking into the internals. > > idr_get_cursor() get can be used instead of idr.idr_next, so that we > do not > expose the internals. > > > > Also is last - 1 always the correct answer? Even with > > idr_alloc_cyclic > > we could wrap around, couldn't we? > > -1 will be incorrect when the pids wrap around. Should we go back to > setting up last_pid as it was done before? Or should we use > idr_get_cursor > and determine if pid was rolled over and then perform necessary > action?
Looking at it some more, it appears the value is only ever used in /proc/loadavg.
Would anyone object to the code simply calling idr_get_cursor() as is, and leaving out the -1?
Somehow I suspect nobody will care that the pid value in /proc/loadavg reflects the next PID allocated, rather than the previous one.
Any objections?
-- All Rights Reversed.[unhandled content-type:application/pgp-signature] | |