> On Fri, Jul 14, 2006 at 09:54:59AM -0400, James Morris wrote:
> >
> > Herbert, any review from you on this would be greatly appreciated.
>
> Looks good to me.
>
Thanks to all that have reviewed the patchset and for your
comments/suggestions.
Will try to get an updated patchset out before the
From: Venkat Yekkirala <[EMAIL PROTECTED]>
Date: Thu, 13 Jul 2006 10:54:14 -0400
> > > +static inline void security_xfrm_skb_secid(struct sk_buff
> > *skb, u32 *secid)
> > > {
> > > - return security_ops->xfrm_decode_session(skb, fl);
> > > + BUG_ON(security_ops->xfrm_decode_session(skb, secid, 0
From: James Morris <[EMAIL PROTECTED]>
Date: Thu, 13 Jul 2006 11:18:32 -0400 (EDT)
> I'd suggest assigning the return value to a variable and asserting that,
> in case defines BUG_ON to nothing and the function won't be called. Not
> sure what kernel policy is on this (ISTR people used to worry
> > This seems problematic in that it's not a general solution
> and depends
> > always on hooking in at all of the right places in every protocol.
> > Adding a bunch of hooks to protocol-specific code is what
> got us in trouble
> > with the initial LSM submission.
> >
> > What about using s
On Thu, 13 Jul 2006, Venkat Yekkirala wrote:
> > > +static inline void security_xfrm_skb_secid(struct sk_buff
> > *skb, u32 *secid)
> > > {
> > > - return security_ops->xfrm_decode_session(skb, fl);
> > > + BUG_ON(security_ops->xfrm_decode_session(skb, secid, 0));
> > >
> >
> > BUG_ON looks wro
> > +static inline void security_xfrm_skb_secid(struct sk_buff
> *skb, u32 *secid)
> > {
> > - return security_ops->xfrm_decode_session(skb, fl);
> > + BUG_ON(security_ops->xfrm_decode_session(skb, secid, 0));
> >
>
> BUG_ON looks wrong here, in that you don't know why the LSM
> returned an
