Nicolas Williams wrote:
> On Tue, Jun 16, 2009 at 12:34:19AM +0200, Darren Reed wrote:
>> If we have a list of 3 resources, A, B and C, lets
>> assume that all 3 are not RCPRIV_SYSTEM resources.
>>
>> The first call to pr_getrctl() will return "A".
>>
>> Using the modified code, if the RCTL_DELETE on "A"
>> fails then which becomes RCTL_NEXT and the next call
>> to pr_getrctl() will return "B". We delete this
>> successfully and start over because 'which' is set
>> back to RCTL_FIRST. The basis for me doing this is
>> I'm assuming that the RCTL_DELETE on "B" could
> ^^^^^^^^
>> cause unexpected things to happen if I do another
>> pr_getrcl() with RCTL_NEXT - the thing I want to go
>> "next" from is now gone.
>
> I'll admit that I don't understand the interfaces involved, so either I
> must study them in order to further my review, or stop here. At the
> moment I must stop here. I'll simply point out that you're making an
> assumption that was far from clear to me.
This is pretty standard list data structure manipulation.
The list looks like:
A --> B -- C --> |
If you are pointing at "B" and then delete "B", you
cannot then ask for the next one after "B" because
"B" no longer exists and thus the "next one after B"
has no meaning.
The assumption I'm making is the safe one. Maybe if I
looked inside I'd see that I can do RCTL_NEXT while "B"
is current and I've deleted "B" but to do that is risky
because it depends on the inner implementation (and that
could change), not the general data structure/algorithm
being used.
You asked about "is there a list of resource limits?".
The answer should be clear in the output of prctl, eg:
project.max-crypto-memory
privileged 510MB -
deny -
system 16.0EB max
deny -
Darren
