[Rpm-maint] Plugin findings

Panu Matilainen pmatilai at laiskiainen.org
Thu Mar 28 11:16:24 UTC 2013


On 03/28/2013 12:52 PM, Reshetova, Elena wrote:
> Hi,
>
>> There's really nothing like field-testing when it comes to finding
> issues... Now that I simply have to run with the selinux plugin enabled
> (otherwise I'd have a very broken system real fast), hacking on new plugins
> revealed a some fairly nasty issues in the plugin system (and caused a fair
> bit of head-scratching >early in the morning :) that's gone merrily
> unnoticed so far:
>
> I have actually only tested and use the hooks with one plugin (msm), so I
> guess some issues could have slipped though, indeed :(

Same here, only tested with one plugin at a time until today :)

>
>> When there are more than one plugins present, an unsupported hook (or
> errors like not finding the hook) in one plugin will cause all the remaining
> plugins to be skipped on that hook. This is because
>> RPMPLUGINS_SET_HOOK_FUNC() does 'return <rc>' on several conditions, which
> doesn't go very well with for-loops...
>
> Oh, yes, I see this... One way would be to change it to a normal function
> that would return the state, but won't break the loop. The question is how
> to differentiate between "hook returned RPMRC_FAILED" and "hook isn't
> supported", which are indeed very very different things.

I suppose it could return RPMRC_NOTFOUND for non-supported hooks, but 
changing it to a function might not be entirely straightforward as it 
plays macro tricks to get the symbol names etc.

>> Another related thing is that RPMPLUGINS_SET_HOOK_FUNC() is executed
> several times per each file in the transaction, times number of plugins
> loaded. It didn't matter for the collection plugins as they are so different
> in nature, but now with several hooks per each file its just terribly
> wasteful if nothing >else.
>
> Hm.. How do you plan to avoid this? If you have let's say a security
> (selinux or msm) plugin and a log plugin, or two different security plugins
> (future LSM stacking), each plugin would need to get a hook called.

Oh, we can't avoid calling a million hooks and that doesn't bother me, 
it's the wholly redundant work of locating the plugin by its name, 
whether it supports a given hook and discovering the actual symbol via 
dlsym() over and over and over again on every single hook-call that is 
just ugly :)

>> So... I'm planning on doing some fairly major surgery on the whole thing.
> Just checking whether you have some work-in-progress in this area, IIRC you
> were planning to look into changing the plugin initialization (move it much
> earlier etc) and I dont want to clash with that work if you've already
> started it.
>
> I have put aside the initialization work so far, since we were concentrating
> on fsm hooks, so there is nothing to clash with for sure!

Ok. I'll go ahead with it then.

>> FWIW the kind of thing I have in mind is make plugins into "objects"
>> that hold their own data (like name, symbol handle etc) and hooks are
> function pointers in the struct that are initialized when the plugin is
> first loaded so we dont have to rediscover the hook functions on each and
> every round, etc.
>
> This sounds good, would make it easier indeed!

Yup, besides making some things easier and new things possible, it'll 
probably simplify the whole thing as well. Lets see how it goes :)

	- Panu -


More information about the Rpm-maint mailing list