linux-kernel - Re: 2.6.20-rt8 patch tweaked for 2.6.20.5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <461B53CD.1030603@free.fr>
Date:	Tue, 10 Apr 2007 11:07:25 +0200
From:	John <linux.kernel@...e.fr>
To:	Ingo Molnar <mingo@...e.hu>
CC:	linux-kernel@...r.kernel.org, tglx@...esys.com,
	John <linux.kernel@...e.fr>
Subject: Re: 2.6.20-rt8 patch tweaked for 2.6.20.5

Ingo Molnar wrote:

> John wrote:
> 
>> I've tweaked patch-2.6.20-rt8 so that it applies to 2.6.20.5
>>
>> The unified diff is attached to this message.
> 
> thanks - this is useful to those who are not that much on the bleeding
> edge.
> 
>> I'd be happy to hear comments on what I've done wrong.
>>
>> 78 hunks had to be offset and 3 hunks had to be fuzzed.
>>
>> $ grep -B1 fuzz patch.log
>> patching file arch/ia64/kernel/iosapic.c
>> Hunk #3 succeeded at 469 with fuzz 2.
>> --
>> patching file kernel/fork.c
>> Hunk #9 succeeded at 975 with fuzz 1.
>> --
>> patching file kernel/sched.c
>> Hunk #46 succeeded at 3996 with fuzz 1.
>>
>> What is the fuzz value, exactly?
> 
> it's harmless: when the 'patch' utility didn't find the 'context' of the 
> patch chunk at its claimed position (because all patch chunks have 
> precise coordinates of source code embedded), but finds them 'nearby' 
> (or at least, somewhere in the file), it emits this reminder that the 
> underlying code did change since the patch was generated. Generating a 
> 'clean' patch will get rid of these messages.

Ingo,

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/

What options did you run diff with to generate the original patch?

diff -upr ? How do you prevent diff from printing timestamps?

Could you, or Thomas, or someone else, take a look at my patch,
and tell me if everything looks right before I go ahead?


I've documented all the changes below:


1. linux/Makefile (trivial)
Tweak EXTRAVERSION to change .5 into .5-rt8


2. linux/drivers/kvm/kvm.h
Remove a patch that was already applied to 2.6.20.2
cf. patch-2.6.20.2

--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -558,7 +558,7 @@ static inline void load_gs(u16 sel)
  #ifndef load_ldt
  static inline void load_ldt(u16 sel)
  {
-	asm ("lldt %0" : : "g"(sel));
+	asm ("lldt %0" : : "rm"(sel));
  }
  #endif


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?


4. linux/kernel/time/clocksource.c
Provide an #include directive added by patch-2.6.20.2
Remove the first line to keep patch happy.

--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -28,6 +28,7 @@
  #include <linux/sysdev.h>
  #include <linux/init.h>
  #include <linux/module.h>
+#include <linux/sched.h> /* for spin_unlock_irq() using preempt_count() 
m68k */

  /* XXX - Would like a better way for initializing curr_clocksource */
  extern struct clocksource clocksource_jiffies;


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 ?

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