Re: 2.6.20-rt8 patch tweaked for 2.6.20.5

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

 



Ingo Molnar wrote:

John wrote:

I'd be happy to generate a clean patch!
(Would you agree to host it in your directory?)
http://people.redhat.com/mingo/realtime-preempt/older/

sure, i can put it there.

Great! Can you tell me how you generate the original -rt patch, so I can provide an updated version when a new 2.6.20 kernel is released?

3. linux/kernel/futex.c
[ I'm not sure I've made the appropriate changes here ]

Basically, we want to replace
  spin_lock(&pi_state->pi_mutex.wait_lock);
with
  spin_lock_irqsave(&pi_state->pi_mutex.wait_lock, flags);

and we want to replace
  spin_unlock(&pi_state->pi_mutex.wait_lock);
with
  spin_unlock_irqrestore(&pi_state->pi_mutex.wait_lock, flags);

Is that correct?

yes.

OK.

5. linux/net/xfrm/xfrm_user.c
[ I'm not sure I've made the appropriate changes here ]

Remove a patch that was already applied to 2.6.20.2
cf. patch-2.6.20.2

--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1273,10 +1273,6 @@ static int xfrm_get_policy(struct sk_buff *skb, struct nlmsghdr *nlh, xp = xfrm_policy_bysel_ctx(type, p->dir, &p->sel, tmp.security, delete);
 		security_xfrm_policy_free(&tmp);
 	}
-	if (delete)
-		xfrm_audit_log(NETLINK_CB(skb).loginuid, NETLINK_CB(skb).sid,
- AUDIT_MAC_IPSEC_DELSPD, (xp) ? 1 : 0, xp, NULL);
-
 	if (xp == NULL)
 		return -ENOENT;

@@ -1292,8 +1288,14 @@ static int xfrm_get_policy(struct sk_buff *skb, struct nlmsghdr *nlh,
 					      MSG_DONTWAIT);
 		}
 	} else {
-		if ((err = security_xfrm_policy_delete(xp)) != 0)
+		err = security_xfrm_policy_delete(xp);
+
+		xfrm_audit_log(NETLINK_CB(skb).loginuid, NETLINK_CB(skb).sid,
+ AUDIT_MAC_IPSEC_DELSPD, err ? 0 : 1, xp, NULL);
+
+		if (err != 0)
 			goto out;
+
 		c.data.byid = p->index;
 		c.event = nlh->nlmsg_type;
 		c.seq = nlh->nlmsg_seq;


As a side note, I find the expression
  err ? 0 : 1
suspect. Why not write !err ?

it was in the original code and i didn't want to change that. I've attached the original patch below - the bug is probably fixed upstream meanwhile (in a different way) so no need to do any change there.

If I understand correctly, removing that specific patch from patch-2.6.20-rt8 is the appropriate course of action then?

Regards.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux