[2.6.20.17 review 00/58] 2.6.20.17 -stable review

[2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Willy Tarreau]

This is the start of the review cycle for the stable 2.6.20.17
kernel release. This version catches up with 2.6.22.4, and 58
patches will be posted as a response to this message.

The following security issues are solved :
  CVE-2007-3105
  CVE-2007-3848
  CVE-2007-3851

The rolled up patch can be found here :
   ftp.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.20.17-rc1.gz

Responses should be made by August 24, 2007, 19:00:00 UTC. Anything
received after that time might be too late.

Thanks,
Willy

-- 

Re: [2.6.20.17 review 27/58] Include serial_reg.h with userspace headers

[Russell King]

On Wed, Aug 22, 2007 at 11:39:11AM +0200, Willy Tarreau wrote:
> As reported by Gustavo de Nardin <gustavodn@mandriva.com.br>, while trying to
> compile xosview (http://xosview.sourceforge.net/) with upstream kernel
> headers being used you get the following errors:
> serialmeter.cc:48:30: error: linux/serial_reg.h: No such file or directory
> serialmeter.cc: In member function 'virtual void
> SerialMeter::checkResources()':
> serialmeter.cc:71: error: 'UART_LSR' was not declared in this scope
> serialmeter.cc:71: error: 'UART_MSR' was not declared in this scope
> ..

It's probably a good thing to repeat what I said privately about this,
which is:

| It should be noted that reading the MSR or LSR of an active 8250 UART
| has side effects.  In the case of MSR, it clears the bits which indicate
| that the modem status signals have changed, and clears the associated
| interrupt.  This can result in loss of hardware flow control on the port.
| 
| For LSR, a read clears the error status reported in that register and
| clears the interrupt associated with the error status, resulting in
| errors being missed.
| 
| So, reading the LSR and MSR of an active port is Bad News(tm) and is
| something that userspace should absolutely avoid.  Instead, userspace
| should open the port in non-blocking mode and use the TIOCGICOUNT
| ioctl to retrieve the various activity counters and TIOCMGET to obtain
| the current modem status line state.
| 
| I would encourage xosview folk to switch to use these ioctls rather than
| reading the registers direct for the following reasons:
| 
| 1. It's supported by a wide variety of serial port implementations.
| 2. Avoids the mess associated with ioperm support noted in serialmeter.cc
|    revision 1.11
| 3. Avoids including kernel private kernel headers.
| 4. Avoids the buggy "autodetection" of serial IO base (which ignores the
|    IO type of the port, which may be MMIO.)
| 5. Avoids side effects associated with reading the ports registers.
| 
| For a tool which presumably is to assist diagnosing serial problems, it
| would seem to have the capability of causing further additional problems.

I leave it up to others to decide that keeping backwards compatibility
with userspace which is quite obviously broken is more important than
providing userspace with the persuasion to fix their broken code.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

[2.6.20.17 review 01/58] Fix IPCOMP crashes.

[Willy Tarreau]

[-- Attachment #1: 0001-Fix-IPCOMP-crashes.patch --]
[-- Type: text/plain, Size: 1411 bytes --]

[XFRM]: Fix crash introduced by struct dst_entry reordering

XFRM expects xfrm_dst->u.next to be same pointer as dst->next, which
was broken by the dst_entry reordering in commit 1e19e02c~, causing
an oops in xfrm_bundle_ok when walking the bundle upwards.

Kill xfrm_dst->u.next and change the only user to use dst->next instead.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 include/net/xfrm.h     |    1 -
 net/xfrm/xfrm_policy.c |    2 +-
 2 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index e476541..4fc943b 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -561,7 +561,6 @@ static inline int xfrm_sec_ctx_match(struct xfrm_sec_ctx *s1, struct xfrm_sec_ct
 struct xfrm_dst
 {
 	union {
-		struct xfrm_dst		*next;
 		struct dst_entry	dst;
 		struct rtable		rt;
 		struct rt6_info		rt6;
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 9704e05..c208a8a 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1971,7 +1971,7 @@ int xfrm_bundle_ok(struct xfrm_policy *pol, struct xfrm_dst *first,
 		if (last == first)
 			break;
 
-		last = last->u.next;
+		last = (struct xfrm_dst *)last->u.dst.next;
 		last->child_mtu_cached = mtu;
 	}
 
-- 
1.5.2.5

-- 

[2.6.20.17 review 03/58] SCTP scope_id handling fix

[Willy Tarreau]

[-- Attachment #1: 0003-SCTP-scope_id-handling-fix.patch --]
[-- Type: text/plain, Size: 962 bytes --]

SCTP: Add scope_id validation for link-local binds

SCTP currently permits users to bind to link-local addresses,
but doesn't verify that the scope id specified at bind matches
the interface that the address is configured on.  It was report
that this can hang a system.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 net/sctp/ipv6.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index ef36be0..c00c73c 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -874,6 +874,10 @@ static int sctp_inet6_send_verify(struct sctp_sock *opt, union sctp_addr *addr)
 			dev = dev_get_by_index(addr->v6.sin6_scope_id);
 			if (!dev)
 				return 0;
+			if (!ipv6_chk_addr(&addr->v6.sin6_addr, dev, 0)) {
+				dev_put(dev);
+				return 0;
+			}
 			dev_put(dev);
 		}
 		af = opt->pf->af;
-- 
1.5.2.5

-- 

[2.6.20.17 review 04/58] gen estimator timer unload race

[Willy Tarreau]

[-- Attachment #1: 0004-gen-estimator-timer-unload-race.patch --]
[-- Type: text/plain, Size: 1059 bytes --]

[NET]: Fix gen_estimator timer removal race

As noticed by Jarek Poplawski <jarkao2@o2.pl>, the timer removal in
gen_kill_estimator races with the timer function rearming the timer.

Check whether the timer list is empty before rearming the timer
in the timer function to fix this.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Acked-by: Jarek Poplawski <jarkao2@o2.pl>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 net/core/gen_estimator.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/core/gen_estimator.c b/net/core/gen_estimator.c
index 3cad026..33d82bf 100644
--- a/net/core/gen_estimator.c
+++ b/net/core/gen_estimator.c
@@ -128,7 +128,8 @@ static void est_timer(unsigned long arg)
 		spin_unlock(e->stats_lock);
 	}
 
-	mod_timer(&elist[idx].timer, jiffies + ((HZ<<idx)/4));
+	if (elist[idx].list != NULL)
+		mod_timer(&elist[idx].timer, jiffies + ((HZ<<idx)/4));
 	read_unlock(&est_lock);
 }
 
-- 
1.5.2.5

-- 

[2.6.20.17 review 05/58] gen estimator deadlock fix

[Willy Tarreau]

[-- Attachment #1: 0005-gen-estimator-deadlock-fix.patch --]
[-- Type: text/plain, Size: 5993 bytes --]

[NET]: gen_estimator deadlock fix

-Fixes ABBA deadlock noted by Patrick McHardy <kaber@trash.net>:

> There is at least one ABBA deadlock, est_timer() does:
> read_lock(&est_lock)
> spin_lock(e->stats_lock) (which is dev->queue_lock)
>
> and qdisc_destroy calls htb_destroy under dev->queue_lock, which
> calls htb_destroy_class, then gen_kill_estimator and this
> write_locks est_lock.

To fix the ABBA deadlock the rate estimators are now kept on an rcu list.

-The est_lock changes the use from protecting the list to protecting
the update to the 'bstat' pointer in order to avoid NULL dereferencing.

-The 'interval' member of the gen_estimator structure removed as it is
not needed.

Signed-off-by: Ranko Zivojnovic <ranko@spidernet.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 net/core/gen_estimator.c |   81 ++++++++++++++++++++++++++++------------------
 1 files changed, 49 insertions(+), 32 deletions(-)

diff --git a/net/core/gen_estimator.c b/net/core/gen_estimator.c
index 33d82bf..acc1ee0 100644
--- a/net/core/gen_estimator.c
+++ b/net/core/gen_estimator.c
@@ -79,27 +79,27 @@
 
 struct gen_estimator
 {
-	struct gen_estimator	*next;
+	struct list_head	list;
 	struct gnet_stats_basic	*bstats;
 	struct gnet_stats_rate_est	*rate_est;
 	spinlock_t		*stats_lock;
-	unsigned		interval;
 	int			ewma_log;
 	u64			last_bytes;
 	u32			last_packets;
 	u32			avpps;
 	u32			avbps;
+	struct rcu_head		e_rcu;
 };
 
 struct gen_estimator_head
 {
 	struct timer_list	timer;
-	struct gen_estimator	*list;
+	struct list_head	list;
 };
 
 static struct gen_estimator_head elist[EST_MAX_INTERVAL+1];
 
-/* Estimator array lock */
+/* Protects against NULL dereference */
 static DEFINE_RWLOCK(est_lock);
 
 static void est_timer(unsigned long arg)
@@ -107,13 +107,17 @@ static void est_timer(unsigned long arg)
 	int idx = (int)arg;
 	struct gen_estimator *e;
 
-	read_lock(&est_lock);
-	for (e = elist[idx].list; e; e = e->next) {
+	rcu_read_lock();
+	list_for_each_entry_rcu(e, &elist[idx].list, list) {
 		u64 nbytes;
 		u32 npackets;
 		u32 rate;
 
 		spin_lock(e->stats_lock);
+		read_lock(&est_lock);
+		if (e->bstats == NULL)
+			goto skip;
+
 		nbytes = e->bstats->bytes;
 		npackets = e->bstats->packets;
 		rate = (nbytes - e->last_bytes)<<(7 - idx);
@@ -125,12 +129,14 @@ static void est_timer(unsigned long arg)
 		e->last_packets = npackets;
 		e->avpps += ((long)rate - (long)e->avpps) >> e->ewma_log;
 		e->rate_est->pps = (e->avpps+0x1FF)>>10;
+skip:
+		read_unlock(&est_lock);
 		spin_unlock(e->stats_lock);
 	}
 
-	if (elist[idx].list != NULL)
+	if (!list_empty(&elist[idx].list))
 		mod_timer(&elist[idx].timer, jiffies + ((HZ<<idx)/4));
-	read_unlock(&est_lock);
+	rcu_read_unlock();
 }
 
 /**
@@ -147,12 +153,17 @@ static void est_timer(unsigned long arg)
  * &rate_est with the statistics lock grabed during this period.
  * 
  * Returns 0 on success or a negative error code.
+ *
+ * NOTE: Called under rtnl_mutex
  */
 int gen_new_estimator(struct gnet_stats_basic *bstats,
-	struct gnet_stats_rate_est *rate_est, spinlock_t *stats_lock, struct rtattr *opt)
+		      struct gnet_stats_rate_est *rate_est,
+		      spinlock_t *stats_lock,
+		      struct rtattr *opt)
 {
 	struct gen_estimator *est;
 	struct gnet_estimator *parm = RTA_DATA(opt);
+	int idx;
 
 	if (RTA_PAYLOAD(opt) < sizeof(*parm))
 		return -EINVAL;
@@ -164,7 +175,7 @@ int gen_new_estimator(struct gnet_stats_basic *bstats,
 	if (est == NULL)
 		return -ENOBUFS;
 
-	est->interval = parm->interval + 2;
+	idx = parm->interval + 2;
 	est->bstats = bstats;
 	est->rate_est = rate_est;
 	est->stats_lock = stats_lock;
@@ -174,20 +185,25 @@ int gen_new_estimator(struct gnet_stats_basic *bstats,
 	est->last_packets = bstats->packets;
 	est->avpps = rate_est->pps<<10;
 
-	est->next = elist[est->interval].list;
-	if (est->next == NULL) {
-		init_timer(&elist[est->interval].timer);
-		elist[est->interval].timer.data = est->interval;
-		elist[est->interval].timer.expires = jiffies + ((HZ<<est->interval)/4);
-		elist[est->interval].timer.function = est_timer;
-		add_timer(&elist[est->interval].timer);
+	if (!elist[idx].timer.function) {
+		INIT_LIST_HEAD(&elist[idx].list);
+		setup_timer(&elist[idx].timer, est_timer, idx);
 	}
-	write_lock_bh(&est_lock);
-	elist[est->interval].list = est;
-	write_unlock_bh(&est_lock);
+
+	if (list_empty(&elist[idx].list))
+		mod_timer(&elist[idx].timer, jiffies + ((HZ<<idx)/4));
+
+	list_add_rcu(&est->list, &elist[idx].list);
 	return 0;
 }
 
+static void __gen_kill_estimator(struct rcu_head *head)
+{
+	struct gen_estimator *e = container_of(head,
+					struct gen_estimator, e_rcu);
+	kfree(e);
+}
+
 /**
  * gen_kill_estimator - remove a rate estimator
  * @bstats: basic statistics
@@ -195,31 +211,32 @@ int gen_new_estimator(struct gnet_stats_basic *bstats,
  *
  * Removes the rate estimator specified by &bstats and &rate_est
  * and deletes the timer.
+ *
+ * NOTE: Called under rtnl_mutex
  */
 void gen_kill_estimator(struct gnet_stats_basic *bstats,
 	struct gnet_stats_rate_est *rate_est)
 {
 	int idx;
-	struct gen_estimator *est, **pest;
+	struct gen_estimator *e, *n;
 
 	for (idx=0; idx <= EST_MAX_INTERVAL; idx++) {
-		int killed = 0;
-		pest = &elist[idx].list;
-		while ((est=*pest) != NULL) {
-			if (est->rate_est != rate_est || est->bstats != bstats) {
-				pest = &est->next;
+
+		/* Skip non initialized indexes */
+		if (!elist[idx].timer.function)
+			continue;
+
+		list_for_each_entry_safe(e, n, &elist[idx].list, list) {
+			if (e->rate_est != rate_est || e->bstats != bstats)
 				continue;
-			}
 
 			write_lock_bh(&est_lock);
-			*pest = est->next;
+			e->bstats = NULL;
 			write_unlock_bh(&est_lock);
 
-			kfree(est);
-			killed++;
+			list_del_rcu(&e->list);
+			call_rcu(&e->e_rcu, __gen_kill_estimator);
 		}
-		if (killed && elist[idx].list == NULL)
-			del_timer(&elist[idx].timer);
 	}
 }
 
-- 
1.5.2.5

-- 

[2.6.20.17 review 07/58] Fix ipv6 link down handling.

[Willy Tarreau]

[-- Attachment #1: 0007-Fix-ipv6-link-down-handling.patch --]
[-- Type: text/plain, Size: 1006 bytes --]

[IPV6]: Call inet6addr_chain notifiers on link down

Currently if the link is brought down via ip link or ifconfig down,
the inet6addr_chain notifiers are not called even though all
the addresses are removed from the interface.  This caused SCTP
to add duplicate addresses to it's list.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 net/ipv6/addrconf.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index e383ac8..0d21d96 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2451,6 +2451,7 @@ static int addrconf_ifdown(struct net_device *dev, int how)
 		write_unlock_bh(&idev->lock);
 
 		__ipv6_ifa_notify(RTM_DELADDR, ifa);
+		atomic_notifier_call_chain(&inet6addr_chain, NETDEV_DOWN, ifa);
 		in6_ifa_put(ifa);
 
 		write_lock_bh(&idev->lock);
-- 
1.5.2.5

-- 

[2.6.20.17 review 08/58] Netpoll leak

[Willy Tarreau]

[-- Attachment #1: 0008-Netpoll-leak.patch --]
[-- Type: text/plain, Size: 1634 bytes --]

[NETPOLL]: Fix a leak-n-bug in netpoll_cleanup()

93ec2c723e3f8a216dde2899aeb85c648672bc6b applied excessive duct tape to
the netpoll beast's netpoll_cleanup(), thus substituting one leak with
another, and opening up a little buglet :-)

net_device->npinfo (netpoll_info) is a shared and refcounted object and
cannot simply be set NULL the first time netpoll_cleanup() is called.
Otherwise, further netpoll_cleanup()'s see np->dev->npinfo == NULL and
become no-ops, thus leaking. And it's a bug too: the first call to
netpoll_cleanup() would thus (annoyingly) "disable" other (still alive)
netpolls too. Maybe nobody noticed this because netconsole (only user
of netpoll) never supported multiple netpoll objects earlier.

This is a trivial and obvious one-line fixlet.

Signed-off-by: Satyam Sharma <ssatyam@cse.iitk.ac.in>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 net/core/netpoll.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 522e441..3431d48 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -776,7 +776,6 @@ void netpoll_cleanup(struct netpoll *np)
 				spin_unlock_irqrestore(&npinfo->rx_lock, flags);
 			}
 
-			np->dev->npinfo = NULL;
 			if (atomic_dec_and_test(&npinfo->refcnt)) {
 				skb_queue_purge(&npinfo->arp_tx);
  				skb_queue_purge(&npinfo->txq);
@@ -784,6 +783,7 @@ void netpoll_cleanup(struct netpoll *np)
  				flush_scheduled_work();
 
 				kfree(npinfo);
+				np->dev->npinfo = NULL;
 			}
 		}
 
-- 
1.5.2.5

-- 

[2.6.20.17 review 09/58] Sparc64 bootup assembler bug

[Willy Tarreau]

[-- Attachment #1: 0009-Sparc64-bootup-assembler-bug.patch --]
[-- Type: text/plain, Size: 855 bytes --]

[SPARC64]: Fix two year old bug in early bootup asm.

We try to fetch the CIF entry pointer from %o4, but that
can get clobbered by the early OBP calls.  It is saved
in %l7 already, so actually this "mov %o4, %l7" can just
be completely removed with no other changes.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 arch/sparc64/kernel/head.S |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/sparc64/kernel/head.S b/arch/sparc64/kernel/head.S
index 06459ae..0e19369 100644
--- a/arch/sparc64/kernel/head.S
+++ b/arch/sparc64/kernel/head.S
@@ -458,7 +458,6 @@ tlb_fixup_done:
 	or	%g6, %lo(init_thread_union), %g6
 	ldx	[%g6 + TI_TASK], %g4
 	mov	%sp, %l6
-	mov	%o4, %l7
 
 	wr	%g0, ASI_P, %asi
 	mov	1, %g1
-- 
1.5.2.5

-- 

[2.6.20.17 review 11/58] Fix sparc32 udelay() rounding errors.

[Willy Tarreau]

[-- Attachment #1: 0011-Fix-sparc32-udelay-rounding-errors.patch --]
[-- Type: text/plain, Size: 2050 bytes --]

[SPARC32]: Fix rounding errors in ndelay/udelay implementation.

__ndelay and __udelay have not been delayung >= specified time.
The problem with __ndelay has been tacked down to the rounding of the
multiplier constant. By changing this, delays > app 18us are correctly
calculated.
The problem with __udelay has also been tracked down to rounding issues.
Changing the multiplier constant (to match that used in sparc64) corrects
for large delays and adding in a rounding constant corrects for trunctaion
errors in the claculations.
Many short delays will return without looping. This is not an error as there
is the fixed delay of doing all the maths to calculate the loop count.

Signed-off-by: Mark Fortescue <mark@mtfhpc.demon.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 arch/sparc/kernel/entry.S |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/sparc/kernel/entry.S b/arch/sparc/kernel/entry.S
index 831f540..eac3838 100644
--- a/arch/sparc/kernel/entry.S
+++ b/arch/sparc/kernel/entry.S
@@ -1749,8 +1749,8 @@ fpload:
 __ndelay:
 	save	%sp, -STACKFRAME_SZ, %sp
 	mov	%i0, %o0
-	call	.umul
-	 mov	0x1ad, %o1		! 2**32 / (1 000 000 000 / HZ)
+	call	.umul			! round multiplier up so large ns ok
+	 mov	0x1ae, %o1		! 2**32 / (1 000 000 000 / HZ)
 	call	.umul
 	 mov	%i1, %o1		! udelay_val
 	ba	delay_continue
@@ -1760,11 +1760,17 @@ __ndelay:
 __udelay:
 	save	%sp, -STACKFRAME_SZ, %sp
 	mov	%i0, %o0
-	sethi	%hi(0x10c6), %o1
+	sethi	%hi(0x10c7), %o1	! round multiplier up so large us ok
 	call	.umul
-	 or	%o1, %lo(0x10c6), %o1	! 2**32 / 1 000 000
+	 or	%o1, %lo(0x10c7), %o1	! 2**32 / 1 000 000
 	call	.umul
 	 mov	%i1, %o1		! udelay_val
+	sethi	%hi(0x028f4b62), %l0	! Add in rounding constant * 2**32,
+	or	%g0, %lo(0x028f4b62), %l0
+	addcc	%o0, %l0, %o0		! 2**32 * 0.009 999
+	bcs,a	3f
+	 add	%o1, 0x01, %o1
+3:
 	call	.umul
 	 mov	HZ, %o0			! >>32 earlier for wider range
 
-- 
1.5.2.5

-- 

[2.6.20.17 review 13/58] KVM: SVM: Reliably detect if SVM was disabled by BIOS

[Willy Tarreau]

[-- Attachment #1: 0013-KVM-SVM-Reliably-detect-if-SVM-was-disabled-by-BIO.patch --]
[-- Type: text/plain, Size: 1423 bytes --]

This patch adds an implementation to the svm is_disabled function to
detect reliably if the BIOS disabled the SVM feature in the CPU. This
fixes the issues with kernel panics when loading the kvm-amd module on
machines where SVM is available but disabled.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/kvm/svm.c |    6 ++++++
 drivers/kvm/svm.h |    3 +++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index c79df79..1e90401 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -1655,6 +1655,12 @@ static void svm_inject_page_fault(struct kvm_vcpu *vcpu,
 
 static int is_disabled(void)
 {
+	u64 vm_cr;
+
+	rdmsrl(MSR_VM_CR, vm_cr);
+	if (vm_cr & (1 << SVM_VM_CR_SVM_DISABLE))
+		return 1;
+
 	return 0;
 }
 
diff --git a/drivers/kvm/svm.h b/drivers/kvm/svm.h
index df731c3..e8f0349 100644
--- a/drivers/kvm/svm.h
+++ b/drivers/kvm/svm.h
@@ -172,8 +172,11 @@ struct __attribute__ ((__packed__)) vmcb {
 #define SVM_CPUID_FUNC 0x8000000a
 
 #define MSR_EFER_SVME_MASK (1ULL << 12)
+#define MSR_VM_CR       0xc0010114
 #define MSR_VM_HSAVE_PA 0xc0010117ULL
 
+#define SVM_VM_CR_SVM_DISABLE 4
+
 #define SVM_SELECTOR_S_SHIFT 4
 #define SVM_SELECTOR_DPL_SHIFT 5
 #define SVM_SELECTOR_P_SHIFT 7
-- 
1.5.2.5

-- 

[2.6.20.17 review 14/58] USB: fix warning caused by autosuspend counter going negative

[Willy Tarreau]

[-- Attachment #1: 0014-USB-fix-warning-caused-by-autosuspend-counter-going.patch --]
[-- Type: text/plain, Size: 1602 bytes --]

This patch (as937) fixes a minor bug in the autosuspend usage-counting
code.  Each hub's usage counter keeps track of the number of
unsuspended children.  However the current driver increments the
counter after registering a new child, by which time the child may
already have been suspended and caused the counter to go negative.
The obvious solution is to increment the counter before registering
the child.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/usb/core/hub.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 8ddeed3..d5890d5 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1356,6 +1356,10 @@ static int __usb_new_device(void *void_data)
 	}
 #endif
 
+	/* Increment the parent's count of unsuspended children */
+	if (udev->parent)
+		usb_autoresume_device(udev->parent);
+
 	/* Register the device.  The device driver is responsible
 	 * for adding the device files to usbfs and sysfs and for
 	 * configuring the device.
@@ -1363,13 +1367,11 @@ static int __usb_new_device(void *void_data)
 	err = device_add (&udev->dev);
 	if (err) {
 		dev_err(&udev->dev, "can't device_add, error %d
", err);
+		if (udev->parent)
+			usb_autosuspend_device(udev->parent);
 		goto fail;
 	}
 
-	/* Increment the parent's count of unsuspended children */
-	if (udev->parent)
-		usb_autoresume_device(udev->parent);
-
 exit:
 	module_put(THIS_MODULE);
 	return err;
-- 
1.5.2.5

-- 

[2.6.20.17 review 15/58] aacraid: fix security hole

[Willy Tarreau]

[-- Attachment #1: 0015-aacraid-fix-security-hole.patch --]
[-- Type: text/plain, Size: 1403 bytes --]

On the SCSI layer ioctl path there is no implicit permissions check for
ioctls (and indeed other drivers implement unprivileged ioctls). aacraid
however allows all sorts of very admin only things to be done so should
check.

Signed-off-by: Alan Cox <alan@redhat.com>
Acked-by: Mark Salyzyn <mark_salyzyn@adaptec.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/scsi/aacraid/linit.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
index d2cf875..3d5cff7 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -539,6 +539,8 @@ static int aac_cfg_open(struct inode *inode, struct file *file)
 static int aac_cfg_ioctl(struct inode *inode,  struct file *file,
 		unsigned int cmd, unsigned long arg)
 {
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
 	return aac_do_ioctl(file->private_data, cmd, (void __user *)arg);
 }
 
@@ -592,6 +594,8 @@ static int aac_compat_ioctl(struct scsi_device *sdev, int cmd, void __user *arg)
 
 static long aac_compat_cfg_ioctl(struct file *file, unsigned cmd, unsigned long arg)
 {
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
 	return aac_compat_do_ioctl((struct aac_dev *)file->private_data, cmd, arg);
 }
 #endif
-- 
1.5.2.5

-- 

[2.6.20.17 review 16/58] V4L: Add check for valid control ID to v4l2_ctrl_next

[Willy Tarreau]

[-- Attachment #1: 0016-V4L-Add-check-for-valid-control-ID-to-v4l2_ctrl_nex.patch --]
[-- Type: text/plain, Size: 1930 bytes --]

If v4l2_ctrl_next is called without the V4L2_CTRL_FLAG_NEXT_CTRL then it
should check whether the passed control ID is valid and return 0 if it
isn't. Otherwise a for-loop over the control IDs will never end.

(cherry picked from commit a46c5fbc6912c4e34cb7ded314249b639dc244a6)

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/media/video/v4l2-common.c |   19 ++++++++++++++-----
 1 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/media/video/v4l2-common.c b/drivers/media/video/v4l2-common.c
index b87d571..31807ba 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -1499,16 +1499,25 @@ int v4l2_ctrl_query_menu(struct v4l2_querymenu *qmenu, struct v4l2_queryctrl *qc
    When no more controls are available 0 is returned. */
 u32 v4l2_ctrl_next(const u32 * const * ctrl_classes, u32 id)
 {
-	u32 ctrl_class;
+	u32 ctrl_class = V4L2_CTRL_ID2CLASS(id);
 	const u32 *pctrl;
 
-	/* if no query is desired, then just return the control ID */
-	if ((id & V4L2_CTRL_FLAG_NEXT_CTRL) == 0)
-		return id;
 	if (ctrl_classes == NULL)
 		return 0;
+
+	/* if no query is desired, then check if the ID is part of ctrl_classes */
+	if ((id & V4L2_CTRL_FLAG_NEXT_CTRL) == 0) {
+		/* find class */
+		while (*ctrl_classes && V4L2_CTRL_ID2CLASS(**ctrl_classes) != ctrl_class)
+			ctrl_classes++;
+		if (*ctrl_classes == NULL)
+			return 0;
+		pctrl = *ctrl_classes;
+		/* find control ID */
+		while (*pctrl && *pctrl != id) pctrl++;
+		return *pctrl ? id : 0;
+	}
 	id &= V4L2_CTRL_ID_MASK;
-	ctrl_class = V4L2_CTRL_ID2CLASS(id);
 	id++;	/* select next control */
 	/* find first class that matches (or is greater than) the class of
 	   the ID */
-- 
1.5.2.5

-- 

[2.6.20.17 review 17/58] V4L: wm8775/wm8739: Fix memory leak when unloading module

[Willy Tarreau]

[-- Attachment #1: 0017-V4L-wm8775-wm8739-Fix-memory-leak-when-unloading-m.patch --]
[-- Type: text/plain, Size: 1487 bytes --]

State struct was never freed.

(cherry picked from commit 1b2232ab879993fcf5b9391c3febf6ab5d78201e)

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/media/video/wm8739.c |    2 ++
 drivers/media/video/wm8775.c |    2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/wm8739.c b/drivers/media/video/wm8739.c
index a9b59c3..009941b 100644
--- a/drivers/media/video/wm8739.c
+++ b/drivers/media/video/wm8739.c
@@ -317,12 +317,14 @@ static int wm8739_probe(struct i2c_adapter *adapter)
 
 static int wm8739_detach(struct i2c_client *client)
 {
+	struct wm8739_state *state = i2c_get_clientdata(client);
 	int err;
 
 	err = i2c_detach_client(client);
 	if (err)
 		return err;
 
+	kfree(state);
 	kfree(client);
 	return 0;
 }
diff --git a/drivers/media/video/wm8775.c b/drivers/media/video/wm8775.c
index d81a88b..e555b3a 100644
--- a/drivers/media/video/wm8775.c
+++ b/drivers/media/video/wm8775.c
@@ -218,12 +218,14 @@ static int wm8775_probe(struct i2c_adapter *adapter)
 
 static int wm8775_detach(struct i2c_client *client)
 {
+	struct wm8775_state *state = i2c_get_clientdata(client);
 	int err;
 
 	err = i2c_detach_client(client);
 	if (err) {
 		return err;
 	}
+	kfree(state);
 	kfree(client);
 
 	return 0;
-- 
1.5.2.5

-- 

[2.6.20.17 review 18/58] splice: fix double page unlock

[Willy Tarreau]

[-- Attachment #1: 0018-splice-fix-double-page-unlock.patch --]
[-- Type: text/plain, Size: 1028 bytes --]

If add_to_page_cache_lru() fails, the page will not be locked. But
splice jumps to an error path that does a page release and unlock,
causing a BUG() in unlock_page().

Fix this by adding one more label that just releases the page. This bug
was actually triggered on EL5 by gurudas pai <gurudas.pai@oracle.com>
using fio.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 fs/splice.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/splice.c b/fs/splice.c
index 2fca6eb..b657217 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -614,7 +614,7 @@ find_page:
 			ret = add_to_page_cache_lru(page, mapping, index,
 						    GFP_KERNEL);
 			if (unlikely(ret))
-				goto out;
+				goto out_release;
 		}
 
 		/*
@@ -695,8 +695,9 @@ find_page:
 		goto find_page;
 	}
 out:
-	page_cache_release(page);
 	unlock_page(page);
+out_release:
+	page_cache_release(page);
 out_ret:
 	return ret;
 }
-- 
1.5.2.5

-- 

[2.6.20.17 review 19/58] drm/i915: Fix i965 secured batchbuffer usage (CVE-2007-3851)

[Willy Tarreau]

[-- Attachment #1: 0019-drm-i915-Fix-i965-secured-batchbuffer-usage-CVE-20.patch --]
[-- Type: text/plain, Size: 2564 bytes --]

This 965G and above chipsets moved the batch buffer non-secure bits to
another place. This means that previous drm's allowed in-secure batchbuffers
to be submitted to the hardware from non-privileged users who are logged
into X and and have access to direct rendering.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/char/drm/i915_dma.c |   14 +++++++++++---
 drivers/char/drm/i915_drv.h |    1 +
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/char/drm/i915_dma.c b/drivers/char/drm/i915_dma.c
index 9354ce3..ab1a1d0 100644
--- a/drivers/char/drm/i915_dma.c
+++ b/drivers/char/drm/i915_dma.c
@@ -172,6 +172,8 @@ static int i915_initialize(drm_device_t * dev,
 	 * private backbuffer/depthbuffer usage.
 	 */
 	dev_priv->use_mi_batchbuffer_start = 0;
+	if (IS_I965G(dev)) /* 965 doesn't support older method */
+		dev_priv->use_mi_batchbuffer_start = 1;
 
 	/* Allow hardware batchbuffers unless told otherwise.
 	 */
@@ -504,8 +506,13 @@ static int i915_dispatch_batchbuffer(drm_device_t * dev,
 
 		if (dev_priv->use_mi_batchbuffer_start) {
 			BEGIN_LP_RING(2);
-			OUT_RING(MI_BATCH_BUFFER_START | (2 << 6));
-			OUT_RING(batch->start | MI_BATCH_NON_SECURE);
+			if (IS_I965G(dev)) {
+				OUT_RING(MI_BATCH_BUFFER_START | (2 << 6) | MI_BATCH_NON_SECURE_I965);
+				OUT_RING(batch->start);
+			} else {
+				OUT_RING(MI_BATCH_BUFFER_START | (2 << 6));
+				OUT_RING(batch->start | MI_BATCH_NON_SECURE);
+			}
 			ADVANCE_LP_RING();
 		} else {
 			BEGIN_LP_RING(4);
@@ -722,7 +729,8 @@ static int i915_setparam(DRM_IOCTL_ARGS)
 
 	switch (param.param) {
 	case I915_SETPARAM_USE_MI_BATCHBUFFER_START:
-		dev_priv->use_mi_batchbuffer_start = param.value;
+		if (!IS_I965G(dev))
+			dev_priv->use_mi_batchbuffer_start = param.value;
 		break;
 	case I915_SETPARAM_TEX_LRU_LOG_GRANULARITY:
 		dev_priv->tex_lru_log_granularity = param.value;
diff --git a/drivers/char/drm/i915_drv.h b/drivers/char/drm/i915_drv.h
index 93cdcfe..30022c8 100644
--- a/drivers/char/drm/i915_drv.h
+++ b/drivers/char/drm/i915_drv.h
@@ -280,6 +280,7 @@ extern int i915_wait_ring(drm_device_t * dev, int n, const char *caller);
 #define MI_BATCH_BUFFER_START 	(0x31<<23)
 #define MI_BATCH_BUFFER_END 	(0xA<<23)
 #define MI_BATCH_NON_SECURE	(1)
+#define MI_BATCH_NON_SECURE_I965 (1<<8)
 
 #define MI_WAIT_FOR_EVENT       ((0x3<<23))
 #define MI_WAIT_FOR_PLANE_A_FLIP      (1<<2)
-- 
1.5.2.5

-- 

[2.6.20.17 review 20/58] Fix leak on /proc/lockdep_stats

[Willy Tarreau]

[-- Attachment #1: 0020-Fix-leak-on-proc-lockdep_stats.patch --]
[-- Type: text/plain, Size: 717 bytes --]

Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 kernel/lockdep_proc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/lockdep_proc.c b/kernel/lockdep_proc.c
index b554b40..d787db5 100644
--- a/kernel/lockdep_proc.c
+++ b/kernel/lockdep_proc.c
@@ -323,7 +323,7 @@ static const struct file_operations proc_lockdep_stats_operations = {
 	.open		= lockdep_stats_open,
 	.read		= seq_read,
 	.llseek		= seq_lseek,
-	.release	= seq_release,
+	.release	= single_release,
 };
 
 static int __init lockdep_proc_init(void)
-- 
1.5.2.5

-- 

[2.6.20.17 review 21/58] CPU online file permission

[Willy Tarreau]

[-- Attachment #1: 0021-CPU-online-file-permission.patch --]
[-- Type: text/plain, Size: 1208 bytes --]

Is there a reason why the "online" file in the subdirectories for the CPUs
in /sys/devices/system isn't world-readable?  I cannot imagine it to be
security relevant especially now that a getcpu() syscall can be used to
determine what CPUa thread runs on.

The file is useful to correctly implement the sysconf() function to return
the number of online CPUs.  In the presence of hotplug we currently cannot
provide this information.  The patch below should to it.

Signed-off-by: Ulrich Drepper <drepper@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/base/cpu.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 7fd095e..be31b43 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -53,7 +53,7 @@ static ssize_t store_online(struct sys_device *dev, const char *buf,
 		ret = count;
 	return ret;
 }
-static SYSDEV_ATTR(online, 0600, show_online, store_online);
+static SYSDEV_ATTR(online, 0644, show_online, store_online);
 
 static void __devinit register_cpu_control(struct cpu *cpu)
 {
-- 
1.5.2.5

-- 

[2.6.20.17 review 22/58] Fix user struct leakage with locked IPC shem segment

[Willy Tarreau]

[-- Attachment #1: 0022-Fix-user-struct-leakage-with-locked-IPC-shem-segment.patch --]
[-- Type: text/plain, Size: 1604 bytes --]

When user locks an ipc shmem segmant with SHM_LOCK ctl and the segment is
already locked the shmem_lock() function returns 0.  After this the
subsequent code leaks the existing user struct:

== ipc/shm.c: sys_shmctl() ==
     ...
     err = shmem_lock(shp->shm_file, 1, user);
     if (!err) {
          shp->shm_perm.mode |= SHM_LOCKED;
          shp->mlock_user = user;
     }
     ...
==

Other results of this are:
1. the new shp->mlock_user is not get-ed and will point to freed
   memory when the task dies.
2. the RLIMIT_MEMLOCK is screwed on both user structs.

The exploit looks like this:

==
    id = shmget(...);
    setresuid(uid, 0, 0);
    shmctl(id, SHM_LOCK, NULL);
    setresuid(uid + 1, 0, 0);
    shmctl(id, SHM_LOCK, NULL);
==

My solution is to return 0 to the userspace and do not change the
segment's user.

Signed-off-by: Pavel Emelianov <xemul@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 ipc/shm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/ipc/shm.c b/ipc/shm.c
index f8e10a2..10b7a2c 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -652,7 +652,7 @@ asmlinkage long sys_shmctl (int shmid, int cmd, struct shmid_ds __user *buf)
 			struct user_struct * user = current->user;
 			if (!is_file_hugepages(shp->shm_file)) {
 				err = shmem_lock(shp->shm_file, 1, user);
-				if (!err) {
+				if (!err && !(shp->shm_perm.mode & SHM_LOCKED)){
 					shp->shm_perm.mode |= SHM_LOCKED;
 					shp->mlock_user = user;
 				}
-- 
1.5.2.5

-- 

[2.6.20.17 review 23/58] md: handle writes to broken raid10 arrays gracefully

[Willy Tarreau]

[-- Attachment #1: 0023-md-handle-writes-to-broken-raid10-arrays-gracefully.patch --]
[-- Type: text/plain, Size: 1094 bytes --]

When writing to a broken array, raid10 currently happily emits empty bio
lists.  IOW, the master bio will never be completed, sending writers to
UNINTERRUPTIBLE_SLEEP forever.

Signed-off-by: Arne Redlich <agr@powerkom-dd.de>
Acked-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/md/raid10.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 9eb66c1..fb5d9c6 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -917,6 +917,13 @@ static int make_request(request_queue_t *q, struct bio * bio)
 		bio_list_add(&bl, mbio);
 	}
 
+	if (unlikely(!atomic_read(&r10_bio->remaining))) {
+		/* the array is dead */
+		md_write_end(mddev);
+		raid_end_bio_io(r10_bio);
+		return 0;
+	}
+
 	bitmap_startwrite(mddev->bitmap, bio->bi_sector, r10_bio->sectors, 0);
 	spin_lock_irqsave(&conf->device_lock, flags);
 	bio_list_merge(&conf->pending_bio_list, &bl);
-- 
1.5.2.5

-- 

[2.6.20.17 review 24/58] md: raid10: fix use-after-free of bio

[Willy Tarreau]

[-- Attachment #1: 0024-md-raid10-fix-use-after-free-of-bio.patch --]
[-- Type: text/plain, Size: 1332 bytes --]

In case of read errors raid10d tries to print a nice error message,
unfortunately using data from an already put bio.

Signed-off-by: Maik Hampel <m.hampel@gmx.de>
Acked-By: NeilBrown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/md/raid10.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index fb5d9c6..e0029ea 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1565,7 +1565,6 @@ static void raid10d(mddev_t *mddev)
 			bio = r10_bio->devs[r10_bio->read_slot].bio;
 			r10_bio->devs[r10_bio->read_slot].bio =
 				mddev->ro ? IO_BLOCKED : NULL;
-			bio_put(bio);
 			mirror = read_balance(conf, r10_bio);
 			if (mirror == -1) {
 				printk(KERN_ALERT "raid10: %s: unrecoverable I/O"
@@ -1573,8 +1572,10 @@ static void raid10d(mddev_t *mddev)
 				       bdevname(bio->bi_bdev,b),
 				       (unsigned long long)r10_bio->sector);
 				raid_end_bio_io(r10_bio);
+				bio_put(bio);
 			} else {
 				const int do_sync = bio_sync(r10_bio->master_bio);
+				bio_put(bio);
 				rdev = conf->mirrors[mirror].rdev;
 				if (printk_ratelimit())
 					printk(KERN_ERR "raid10: %s: redirecting sector %llu to"
-- 
1.5.2.5

-- 

[2.6.20.17 review 25/58] pcmcia: give socket time to power down

[Willy Tarreau]

[-- Attachment #1: 0025-pcmcia-give-socket-time-to-power-down.patch --]
[-- Type: text/plain, Size: 950 bytes --]

Give sockets up to 100ms of additional time to power down.  otherwise we
might generate false warnings with KERN_ERR priority (like in bug #8262).

Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Cc: Nils Neumann <nils.neumann@rwth-aachen.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/pcmcia/cs.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/pcmcia/cs.c b/drivers/pcmcia/cs.c
index 606a467..2785d83 100644
--- a/drivers/pcmcia/cs.c
+++ b/drivers/pcmcia/cs.c
@@ -410,6 +410,9 @@ static void socket_shutdown(struct pcmcia_socket *s)
 #endif
 	s->functions = 0;
 
+	/* give socket some time to power down */
+	msleep(100);
+
 	s->ops->get_status(s, &status);
 	if (status & SS_POWERON) {
 		printk(KERN_ERR "PCMCIA: socket %p: *** DANGER *** unable to remove socket power
", s);
-- 
1.5.2.5

-- 

[2.6.20.17 review 26/58] "ext4_ext_put_in_cache" uses __u32 to receive physical block number

[Willy Tarreau]

[-- Attachment #1: 0026-ext4_ext_put_in_cache-uses-__u32-to-receive-physic.patch --]
[-- Type: text/plain, Size: 1631 bytes --]

Yan Zheng wrote:

> I think I found a bug in ext4/extents.c, "ext4_ext_put_in_cache" uses
> "__u32" to receive physical block number.  "ext4_ext_put_in_cache" is
> used in "ext4_ext_get_blocks", it sets ext4 inode's extent cache
> according most recently tree lookup (higher 16 bits of saved physical
> block number are always zero). when serving a mapping request,
> "ext4_ext_get_blocks" first check whether the logical block is in
> inode's extent cache. if the logical block is in the cache and the
> cached region isn't a gap, "ext4_ext_get_blocks" gets physical block
> number by using cached region's physical block number and offset in
> the cached region.  as described above, "ext4_ext_get_blocks" may
> return wrong result when there are physical block numbers bigger than
> 0xffffffff.
>

You are right.  Thanks for reporting this!

Signed-off-by: Mingming Cao <cmm@us.ibm.com>
Cc: Yan Zheng <yanzheng@21cn.com>
Cc: <linux-ext4@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 fs/ext4/extents.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index dc2724f..14b0b49 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -1397,7 +1397,7 @@ int ext4_ext_walk_space(struct inode *inode, unsigned long block,
 
 static void
 ext4_ext_put_in_cache(struct inode *inode, __u32 block,
-			__u32 len, __u32 start, int type)
+			__u32 len, ext4_fsblk_t start, int type)
 {
 	struct ext4_ext_cache *cex;
 	BUG_ON(len == 0);
-- 
1.5.2.5

-- 

[2.6.20.17 review 27/58] Include serial_reg.h with userspace headers

[Willy Tarreau]

[-- Attachment #1: 0027-Include-serial_reg.h-with-userspace-headers.patch --]
[-- Type: text/plain, Size: 1280 bytes --]

As reported by Gustavo de Nardin <gustavodn@mandriva.com.br>, while trying to
compile xosview (http://xosview.sourceforge.net/) with upstream kernel
headers being used you get the following errors:
serialmeter.cc:48:30: error: linux/serial_reg.h: No such file or directory
serialmeter.cc: In member function 'virtual void
SerialMeter::checkResources()':
serialmeter.cc:71: error: 'UART_LSR' was not declared in this scope
serialmeter.cc:71: error: 'UART_MSR' was not declared in this scope
..

Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Cc: Gustavo de Nardin <gustavodn@mandriva.com.br>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 include/linux/Kbuild |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index 157db77..199fd71 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -134,6 +134,7 @@ header-y += radeonfb.h
 header-y += raw.h
 header-y += resource.h
 header-y += rose.h
+header-y += serial_reg.h
 header-y += smbno.h
 header-y += snmp.h
 header-y += sockios.h
-- 
1.5.2.5

-- 

[2.6.20.17 review 28/58] dm io: fix panic on large request

[Willy Tarreau]

[-- Attachment #1: 0028-dm-io-fix-panic-on-large-request.patch --]
[-- Type: text/plain, Size: 1339 bytes --]

Flush workqueue before releasing bioset and mopools in dm-crypt.  There can
be finished but not yet released request.

Call chain causing oops:
  run workqueue
    dec_pending
      bio_endio(...);
      	<remove device request - remove mempool>
      mempool_free(io, cc->io_pool);

This usually happens when cryptsetup create temporary
luks mapping in the beggining of crypt device activation.

When dm-core calls destructor crypt_dtr, no new request
are possible.

Signed-off-by: Milan Broz <mbroz@redhat.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Cc: Patrick McHardy <kaber@trash.net>
Acked-by: Alasdair G Kergon <agk@redhat.com>
Cc: Christophe Saout <christophe@saout.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/md/dm-crypt.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index b9ff4e3..6b50991 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -917,6 +917,8 @@ static void crypt_dtr(struct dm_target *ti)
 {
 	struct crypt_config *cc = (struct crypt_config *) ti->private;
 
+	flush_workqueue(_kcryptd_workqueue);
+
 	bioset_free(cc->bs);
 	mempool_destroy(cc->page_pool);
 	mempool_destroy(cc->io_pool);
-- 
1.5.2.5

-- 

[2.6.20.17 review 29/58] softmac: Fix ESSID problem

[Willy Tarreau]

[-- Attachment #1: 0029-softmac-Fix-ESSID-problem.patch --]
[-- Type: text/plain, Size: 1507 bytes --]

Victor Porton reported that the SoftMAC layer had random problem when setting the ESSID :
http://bugzilla.kernel.org/show_bug.cgi?id=8686 After investigation, it turned out to be
worse, the SoftMAC layer is left in an inconsistent state. The fix is pretty trivial.

Signed-off-by: Jean Tourrilhes <jt@hpl.hp.com>
Acked-by: Michael Buesch <mb@bu3sch.de>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 net/ieee80211/softmac/ieee80211softmac_assoc.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index a824852..dadb65c 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -271,8 +271,11 @@ ieee80211softmac_assoc_work(struct work_struct *work)
 			 */
 			dprintk(KERN_INFO PFX "Associate: Scanning for networks first.
");
 			ieee80211softmac_notify(mac->dev, IEEE80211SOFTMAC_EVENT_SCAN_FINISHED, ieee80211softmac_assoc_notify_scan, NULL);
-			if (ieee80211softmac_start_scan(mac))
+			if (ieee80211softmac_start_scan(mac)) {
 				dprintk(KERN_INFO PFX "Associate: failed to initiate scan. Is device up?
");
+				mac->associnfo.associating = 0;
+				mac->associnfo.associated = 0;
+			}
 			goto out;
 		} else {
 			mac->associnfo.associating = 0;
-- 
1.5.2.5

-- 

[2.6.20.17 review 30/58] nfsd: fix possible read-ahead cache and export table corruption

[Willy Tarreau]

[-- Attachment #1: 0030-nfsd-fix-possible-read-ahead-cache-and-export-table.patch --]
[-- Type: text/plain, Size: 1551 bytes --]

The value of nperbucket calculated here is too small--we should be rounding up
instead of down--with the result that the index j in the following loop can
overflow the raparm_hash array.  At least in my case, the next thing in memory
turns out to be export_table, so the symptoms I see are crashes caused by the
appearance of four zeroed-out export entries in the first bucket of the hash
table of exports (which were actually entries in the readahead cache, a
pointer to which had been written to the export table in this initialization
code).

It looks like the bug was probably introduced with commit
fce1456a19f5c08b688c29f00ef90fdfa074c79b ("knfsd: make the readahead params
cache SMP-friendly").

Cc: Greg Banks <gnb@melbourne.sgi.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Acked-by: NeilBrown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 fs/nfsd/vfs.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 8283236..d8b773a 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -1887,7 +1887,7 @@ nfsd_racache_init(int cache_size)
 		raparm_hash[i].pb_head = NULL;
 		spin_lock_init(&raparm_hash[i].pb_lock);
 	}
-	nperbucket = cache_size >> RAPARM_HASH_BITS;
+	nperbucket = DIV_ROUND_UP(cache_size, RAPARM_HASH_SIZE);
 	for (i = 0; i < cache_size - 1; i++) {
 		if (i % nperbucket == 0)
 			raparm_hash[j++].pb_head = raparml + i;
-- 
1.5.2.5

-- 

[2.6.20.17 review 31/58] readahead: MIN_RA_PAGES/MAX_RA_PAGES macros

[Willy Tarreau]

[-- Attachment #1: 0031-readahead-MIN_RA_PAGES-MAX_RA_PAGES-macros.patch --]
[-- Type: text/plain, Size: 1843 bytes --]

Define two convenient macros for read-ahead:
	- MAX_RA_PAGES: rounded down counterpart of VM_MAX_READAHEAD
	- MIN_RA_PAGES: rounded _up_ counterpart of VM_MIN_READAHEAD

Note that the rounded up MIN_RA_PAGES will work flawlessly with _large_
page sizes like 64k.

Signed-off-by: Fengguang Wu <wfg@mail.ustc.edu.cn>
Cc: Steven Pratt <slpratt@austin.ibm.com>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 mm/readahead.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/mm/readahead.c b/mm/readahead.c
index 0f539e8..f26cdea 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -21,8 +21,16 @@ void default_unplug_io_fn(struct backing_dev_info *bdi, struct page *page)
 }
 EXPORT_SYMBOL(default_unplug_io_fn);
 
+/*
+ * Convienent macros for min/max read-ahead pages.
+ * Note that MAX_RA_PAGES is rounded down, while MIN_RA_PAGES is rounded up.
+ * The latter is necessary for systems with large page size(i.e. 64k).
+ */
+#define MAX_RA_PAGES	(VM_MAX_READAHEAD*1024 / PAGE_CACHE_SIZE)
+#define MIN_RA_PAGES	DIV_ROUND_UP(VM_MIN_READAHEAD*1024, PAGE_CACHE_SIZE)
+
 struct backing_dev_info default_backing_dev_info = {
-	.ra_pages	= (VM_MAX_READAHEAD * 1024) / PAGE_CACHE_SIZE,
+	.ra_pages	= MAX_RA_PAGES,
 	.state		= 0,
 	.capabilities	= BDI_CAP_MAP_COPY,
 	.unplug_io_fn	= default_unplug_io_fn,
@@ -51,7 +59,7 @@ static inline unsigned long get_max_readahead(struct file_ra_state *ra)
 
 static inline unsigned long get_min_readahead(struct file_ra_state *ra)
 {
-	return (VM_MIN_READAHEAD * 1024) / PAGE_CACHE_SIZE;
+	return MIN_RA_PAGES;
 }
 
 static inline void reset_ahead_window(struct file_ra_state *ra)
-- 
1.5.2.5

-- 

[2.6.20.17 review 32/58] fs: 9p/conv.c error path fix

[Willy Tarreau]

[-- Attachment #1: 0032-fs-9p-conv.c-error-path-fix.patch --]
[-- Type: text/plain, Size: 700 bytes --]

When buf_check_overflow() returns != 0 we will hit kfree(ERR_PTR(err))
and it will not be happy about it.

Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 fs/9p/conv.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/9p/conv.c b/fs/9p/conv.c
index a3ed571..923d75c 100644
--- a/fs/9p/conv.c
+++ b/fs/9p/conv.c
@@ -742,6 +742,7 @@ struct v9fs_fcall *v9fs_create_twrite(u32 fid, u64 offset, u32 count,
 	if (err) {
 		kfree(fc);
 		fc = ERR_PTR(err);
+		goto error;
 	}
 
 	if (buf_check_overflow(bufp)) {
-- 
1.5.2.5

-- 

[2.6.20.17 review 33/58] forcedeth bug fix: cicada phy

[Willy Tarreau]

[-- Attachment #1: 0033-forcedeth-bug-fix-cicada-phy.patch --]
[-- Type: text/plain, Size: 2395 bytes --]

This patch contains errata fixes for the cicada phy. It only renamed the
defines to be phy specific.

Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/net/forcedeth.c |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 952a6bd..63f4c58 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -560,12 +560,12 @@ union ring_type {
 #define PHYID2_MODEL_MASK		0x03f0
 #define PHY_MODEL_MARVELL_E3016		0x220
 #define PHY_MARVELL_E3016_INITMASK	0x0300
-#define PHY_INIT1	0x0f000
-#define PHY_INIT2	0x0e00
-#define PHY_INIT3	0x01000
-#define PHY_INIT4	0x0200
-#define PHY_INIT5	0x0004
-#define PHY_INIT6	0x02000
+#define PHY_CICADA_INIT1	0x0f000
+#define PHY_CICADA_INIT2	0x0e00
+#define PHY_CICADA_INIT3	0x01000
+#define PHY_CICADA_INIT4	0x0200
+#define PHY_CICADA_INIT5	0x0004
+#define PHY_CICADA_INIT6	0x02000
 #define PHY_GIGABIT	0x0100
 
 #define PHY_TIMEOUT	0x1
@@ -1133,14 +1133,14 @@ static int phy_init(struct net_device *dev)
 	/* phy vendor specific configuration */
 	if ((np->phy_oui == PHY_OUI_CICADA) && (phyinterface & PHY_RGMII) ) {
 		phy_reserved = mii_rw(dev, np->phyaddr, MII_RESV1, MII_READ);
-		phy_reserved &= ~(PHY_INIT1 | PHY_INIT2);
-		phy_reserved |= (PHY_INIT3 | PHY_INIT4);
+		phy_reserved &= ~(PHY_CICADA_INIT1 | PHY_CICADA_INIT2);
+		phy_reserved |= (PHY_CICADA_INIT3 | PHY_CICADA_INIT4);
 		if (mii_rw(dev, np->phyaddr, MII_RESV1, phy_reserved)) {
 			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
 			return PHY_ERROR;
 		}
 		phy_reserved = mii_rw(dev, np->phyaddr, MII_NCONFIG, MII_READ);
-		phy_reserved |= PHY_INIT5;
+		phy_reserved |= PHY_CICADA_INIT5;
 		if (mii_rw(dev, np->phyaddr, MII_NCONFIG, phy_reserved)) {
 			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
 			return PHY_ERROR;
@@ -1148,7 +1148,7 @@ static int phy_init(struct net_device *dev)
 	}
 	if (np->phy_oui == PHY_OUI_CICADA) {
 		phy_reserved = mii_rw(dev, np->phyaddr, MII_SREVISION, MII_READ);
-		phy_reserved |= PHY_INIT6;
+		phy_reserved |= PHY_CICADA_INIT6;
 		if (mii_rw(dev, np->phyaddr, MII_SREVISION, phy_reserved)) {
 			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
 			return PHY_ERROR;
-- 
1.5.2.5

-- 

[2.6.20.17 review 34/58] forcedeth bug fix: vitesse phy

[Willy Tarreau]

[-- Attachment #1: 0034-forcedeth-bug-fix-vitesse-phy.patch --]
[-- Type: text/plain, Size: 4914 bytes --]

This patch contains errata fixes for the vitesse phy. It only renamed the
defines to be phy specific.

Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/net/forcedeth.c |   88 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 88 insertions(+), 0 deletions(-)

diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 63f4c58..c383dc3 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -553,6 +553,7 @@ union ring_type {
 /* PHY defines */
 #define PHY_OUI_MARVELL	0x5043
 #define PHY_OUI_CICADA	0x03f1
+#define PHY_OUI_VITESSE	0x01c1
 #define PHYID1_OUI_MASK	0x03ff
 #define PHYID1_OUI_SHFT	6
 #define PHYID2_OUI_MASK	0xfc00
@@ -566,6 +567,23 @@ union ring_type {
 #define PHY_CICADA_INIT4	0x0200
 #define PHY_CICADA_INIT5	0x0004
 #define PHY_CICADA_INIT6	0x02000
+#define PHY_VITESSE_INIT_REG1	0x1f
+#define PHY_VITESSE_INIT_REG2	0x10
+#define PHY_VITESSE_INIT_REG3	0x11
+#define PHY_VITESSE_INIT_REG4	0x12
+#define PHY_VITESSE_INIT_MSK1	0xc
+#define PHY_VITESSE_INIT_MSK2	0x0180
+#define PHY_VITESSE_INIT1	0x52b5
+#define PHY_VITESSE_INIT2	0xaf8a
+#define PHY_VITESSE_INIT3	0x8
+#define PHY_VITESSE_INIT4	0x8f8a
+#define PHY_VITESSE_INIT5	0xaf86
+#define PHY_VITESSE_INIT6	0x8f86
+#define PHY_VITESSE_INIT7	0xaf82
+#define PHY_VITESSE_INIT8	0x0100
+#define PHY_VITESSE_INIT9	0x8f82
+#define PHY_VITESSE_INIT10	0x0
+
 #define PHY_GIGABIT	0x0100
 
 #define PHY_TIMEOUT	0x1
@@ -1154,6 +1172,76 @@ static int phy_init(struct net_device *dev)
 			return PHY_ERROR;
 		}
 	}
+	if (np->phy_oui == PHY_OUI_VITESSE) {
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG1, PHY_VITESSE_INIT1)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG2, PHY_VITESSE_INIT2)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		phy_reserved = mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG4, MII_READ);
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG4, phy_reserved)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		phy_reserved = mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG3, MII_READ);
+		phy_reserved &= ~PHY_VITESSE_INIT_MSK1;
+		phy_reserved |= PHY_VITESSE_INIT3;
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG3, phy_reserved)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG2, PHY_VITESSE_INIT4)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG2, PHY_VITESSE_INIT5)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		phy_reserved = mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG4, MII_READ);
+		phy_reserved &= ~PHY_VITESSE_INIT_MSK1;
+		phy_reserved |= PHY_VITESSE_INIT3;
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG4, phy_reserved)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		phy_reserved = mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG3, MII_READ);
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG3, phy_reserved)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG2, PHY_VITESSE_INIT6)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG2, PHY_VITESSE_INIT7)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		phy_reserved = mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG4, MII_READ);
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG4, phy_reserved)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		phy_reserved = mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG3, MII_READ);
+		phy_reserved &= ~PHY_VITESSE_INIT_MSK2;
+		phy_reserved |= PHY_VITESSE_INIT8;
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG3, phy_reserved)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG2, PHY_VITESSE_INIT9)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_VITESSE_INIT_REG1, PHY_VITESSE_INIT10)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+	}
 	/* some phys clear out pause advertisment on reset, set it back */
 	mii_rw(dev, np->phyaddr, MII_ADVERTISE, reg);
 
-- 
1.5.2.5

-- 

[2.6.20.17 review 35/58] forcedeth bug fix: realtek phy

[Willy Tarreau]

[-- Attachment #1: 0035-forcedeth-bug-fix-realtek-phy.patch --]
[-- Type: text/plain, Size: 3517 bytes --]

This patch contains errata fixes for the realtek phy. It only renamed the
defines to be phy specific.

Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/net/forcedeth.c |   54 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index c383dc3..dbfdbed 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -554,6 +554,7 @@ union ring_type {
 #define PHY_OUI_MARVELL	0x5043
 #define PHY_OUI_CICADA	0x03f1
 #define PHY_OUI_VITESSE	0x01c1
+#define PHY_OUI_REALTEK	0x01c1
 #define PHYID1_OUI_MASK	0x03ff
 #define PHYID1_OUI_SHFT	6
 #define PHYID2_OUI_MASK	0xfc00
@@ -583,6 +584,13 @@ union ring_type {
 #define PHY_VITESSE_INIT8	0x0100
 #define PHY_VITESSE_INIT9	0x8f82
 #define PHY_VITESSE_INIT10	0x0
+#define PHY_REALTEK_INIT_REG1	0x1f
+#define PHY_REALTEK_INIT_REG2	0x19
+#define PHY_REALTEK_INIT_REG3	0x13
+#define PHY_REALTEK_INIT1	0x0000
+#define PHY_REALTEK_INIT2	0x8e00
+#define PHY_REALTEK_INIT3	0x0001
+#define PHY_REALTEK_INIT4	0xad17
 
 #define PHY_GIGABIT	0x0100
 
@@ -1106,6 +1114,28 @@ static int phy_init(struct net_device *dev)
 			return PHY_ERROR;
 		}
 	}
+	if (np->phy_oui == PHY_OUI_REALTEK) {
+		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT1)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG2, PHY_REALTEK_INIT2)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT3)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG3, PHY_REALTEK_INIT4)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT1)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+	}
 
 	/* set advertise register */
 	reg = mii_rw(dev, np->phyaddr, MII_ADVERTISE, MII_READ);
@@ -1242,6 +1272,30 @@ static int phy_init(struct net_device *dev)
 			return PHY_ERROR;
 		}
 	}
+	if (np->phy_oui == PHY_OUI_REALTEK) {
+		/* reset could have cleared these out, set them back */
+		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT1)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG2, PHY_REALTEK_INIT2)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT3)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG3, PHY_REALTEK_INIT4)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT1)) {
+			printk(KERN_INFO "%s: phy init failed.
", pci_name(np->pci_dev));
+			return PHY_ERROR;
+		}
+	}
+
 	/* some phys clear out pause advertisment on reset, set it back */
 	mii_rw(dev, np->phyaddr, MII_ADVERTISE, reg);
 
-- 
1.5.2.5

-- 

[2.6.20.17 review 36/58] acpi-cpufreq: Proper ReadModifyWrite of PERF_CTL MSR

[Willy Tarreau]

[-- Attachment #1: 0036-acpi-cpufreq-Proper-ReadModifyWrite-of-PERF_CTL-MSR.patch --]
[-- Type: text/plain, Size: 2176 bytes --]

[CPUFREQ] acpi-cpufreq: Proper ReadModifyWrite of PERF_CTL MSR

During recent acpi-cpufreq changes, writing to PERF_CTL msr
changed from RMW of entire 64 bit to RMW of low 32 bit and clearing of
upper 32 bit. Fix it back to do a proper RMW of the MSR.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c |   13 +++++--------
 1 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
index 10baa35..18c8b67 100644
--- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -167,11 +167,13 @@ static void do_drv_read(struct drv_cmd *cmd)
 
 static void do_drv_write(struct drv_cmd *cmd)
 {
-	u32 h = 0;
+	u32 lo, hi;
 
 	switch (cmd->type) {
 	case SYSTEM_INTEL_MSR_CAPABLE:
-		wrmsr(cmd->addr.msr.reg, cmd->val, h);
+		rdmsr(cmd->addr.msr.reg, lo, hi);
+		lo = (lo & ~INTEL_MSR_RANGE) | (cmd->val & INTEL_MSR_RANGE);
+		wrmsr(cmd->addr.msr.reg, lo, hi);
 		break;
 	case SYSTEM_IO_CAPABLE:
 		acpi_os_write_port((acpi_io_address)cmd->addr.io.port,
@@ -372,7 +374,6 @@ static int acpi_cpufreq_target(struct cpufreq_policy *policy,
 	struct cpufreq_freqs freqs;
 	cpumask_t online_policy_cpus;
 	struct drv_cmd cmd;
-	unsigned int msr;
 	unsigned int next_state = 0; /* Index into freq_table */
 	unsigned int next_perf_state = 0; /* Index into perf table */
 	unsigned int i;
@@ -417,11 +418,7 @@ static int acpi_cpufreq_target(struct cpufreq_policy *policy,
 	case SYSTEM_INTEL_MSR_CAPABLE:
 		cmd.type = SYSTEM_INTEL_MSR_CAPABLE;
 		cmd.addr.msr.reg = MSR_IA32_PERF_CTL;
-		msr =
-		    (u32) perf->states[next_perf_state].
-		    control & INTEL_MSR_RANGE;
-		cmd.val = get_cur_val(online_policy_cpus);
-		cmd.val = (cmd.val & ~INTEL_MSR_RANGE) | msr;
+		cmd.val = (u32) perf->states[next_perf_state].control;
 		break;
 	case SYSTEM_IO_CAPABLE:
 		cmd.type = SYSTEM_IO_CAPABLE;
-- 
1.5.2.5

-- 

[2.6.20.17 review 38/58] jbd2 commit: fix transaction dropping

[Willy Tarreau]

[-- Attachment #1: 0038-jbd2-commit-fix-transaction-dropping.patch --]
[-- Type: text/plain, Size: 1038 bytes --]

We have to check that also the second checkpoint list is non-empty before
dropping the transaction.

Signed-off-by: Jan Kara <jack@suse.cz>
Cc: Chuck Ebbert <cebbert@redhat.com>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: <linux-ext4@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 fs/jbd2/commit.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
index 6bd8005..7d29549 100644
--- a/fs/jbd2/commit.c
+++ b/fs/jbd2/commit.c
@@ -897,7 +897,8 @@ restart_loop:
 	journal->j_committing_transaction = NULL;
 	spin_unlock(&journal->j_state_lock);
 
-	if (commit_transaction->t_checkpoint_list == NULL) {
+	if (commit_transaction->t_checkpoint_list == NULL &&
+	    commit_transaction->t_checkpoint_io_list == NULL) {
 		__jbd2_journal_drop_transaction(journal, commit_transaction);
 	} else {
 		if (journal->j_checkpoint_transactions == NULL) {
-- 
1.5.2.5

-- 

[2.6.20.17 review 39/58] hugetlb: fix race in alloc_fresh_huge_page()

[Willy Tarreau]

[-- Attachment #1: 0039-hugetlb-fix-race-in-alloc_fresh_huge_page.patch --]
[-- Type: text/plain, Size: 1289 bytes --]

That static `nid' index needs locking.  Without it we can end up calling
alloc_pages_node() with an illegal node ID and the kernel crashes.

Acked-by: Gurudas Pai <gurudas.pai@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 mm/hugetlb.c |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 36db012..7c07eb2 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -101,13 +101,20 @@ static void free_huge_page(struct page *page)
 
 static int alloc_fresh_huge_page(void)
 {
-	static int nid = 0;
+	static int prev_nid;
 	struct page *page;
-	page = alloc_pages_node(nid, GFP_HIGHUSER|__GFP_COMP|__GFP_NOWARN,
-					HUGETLB_PAGE_ORDER);
-	nid = next_node(nid, node_online_map);
+	static DEFINE_SPINLOCK(nid_lock);
+	int nid;
+
+	spin_lock(&nid_lock);
+	nid = next_node(prev_nid, node_online_map);
 	if (nid == MAX_NUMNODES)
 		nid = first_node(node_online_map);
+	prev_nid = nid;
+	spin_unlock(&nid_lock);
+
+	page = alloc_pages_node(nid, GFP_HIGHUSER|__GFP_COMP|__GFP_NOWARN,
+					HUGETLB_PAGE_ORDER);
 	if (page) {
 		set_compound_page_dtor(page, free_huge_page);
 		spin_lock(&hugetlb_lock);
-- 
1.5.2.5

-- 

[2.6.20.17 review 40/58] do not limit locked memory when RLIMIT_MEMLOCK is RLIM_INFINITY

[Willy Tarreau]

[-- Attachment #1: 0040-do-not-limit-locked-memory-when-RLIMIT_MEMLOCK-is-RL.patch --]
[-- Type: text/plain, Size: 1217 bytes --]

Fix a bug in mm/mlock.c on 32-bit architectures that prevents a user from
locking more than 4GB of shared memory, or allocating more than 4GB of
shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is set to
RLIM_INFINITY.

Signed-off-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
Acked-by: Chris Mason <chris.mason@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 mm/mlock.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/mm/mlock.c b/mm/mlock.c
index 3446b7e..ef8fc94 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -233,9 +233,12 @@ int user_shm_lock(size_t size, struct user_struct *user)
 
 	locked = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
 	lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
+	if (lock_limit == RLIM_INFINITY)
+		allowed = 1;
 	lock_limit >>= PAGE_SHIFT;
 	spin_lock(&shmlock_user_lock);
-	if (locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
+	if (!allowed &&
+	    locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
 		goto out;
 	get_uid(user);
 	user->locked_shm += locked;
-- 
1.5.2.5

-- 

[2.6.20.17 review 41/58] drivers/video/macmodes.c:mac_find_mode() mustnt be __devinit

[Willy Tarreau]

[-- Attachment #1: 0041-drivers-video-macmodes.c-mac_find_mode-mustn-t-be.patch --]
[-- Type: text/plain, Size: 1799 bytes --]

If it's EXPORT_SYMBOL'ed it can't be __devinit.

Reported by Mikael Pettersson.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/video/macmodes.c |    5 ++---
 drivers/video/macmodes.h |    8 ++++----
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/video/macmodes.c b/drivers/video/macmodes.c
index ab21495..083f603 100644
--- a/drivers/video/macmodes.c
+++ b/drivers/video/macmodes.c
@@ -369,9 +369,8 @@ EXPORT_SYMBOL(mac_map_monitor_sense);
  *
  */
 
-int __devinit mac_find_mode(struct fb_var_screeninfo *var,
-			    struct fb_info *info, const char *mode_option,
-			    unsigned int default_bpp)
+int mac_find_mode(struct fb_var_screeninfo *var, struct fb_info *info,
+		  const char *mode_option, unsigned int default_bpp)
 {
     const struct fb_videomode *db = NULL;
     unsigned int dbsize = 0;
diff --git a/drivers/video/macmodes.h b/drivers/video/macmodes.h
index babeb81..b86ba08 100644
--- a/drivers/video/macmodes.h
+++ b/drivers/video/macmodes.h
@@ -55,10 +55,10 @@ extern int mac_vmode_to_var(int vmode, int cmode,
 extern int mac_var_to_vmode(const struct fb_var_screeninfo *var, int *vmode,
 			    int *cmode);
 extern int mac_map_monitor_sense(int sense);
-extern int __devinit mac_find_mode(struct fb_var_screeninfo *var,
-				   struct fb_info *info,
-				   const char *mode_option,
-				   unsigned int default_bpp);
+extern int mac_find_mode(struct fb_var_screeninfo *var,
+			 struct fb_info *info,
+			 const char *mode_option,
+			 unsigned int default_bpp);
 
 
     /*
-- 
1.5.2.5

-- 

[2.6.20.17 review 42/58] nfsd: fix possible oops on re-insertion of rpcsec_gss modules

[Willy Tarreau]

[-- Attachment #1: 0042-nfsd-fix-possible-oops-on-re-insertion-of-rpcsec_gs.patch --]
[-- Type: text/plain, Size: 1474 bytes --]

The handling of the re-registration case is wrong here; the "test" that was
returned from auth_domain_lookup will not be used again, so that reference
should be put.  And auth_domain_lookup never did anything with "new" in
this case, so we should just clean it up ourself.

Thanks to Akinobu Mita for bug report, analysis, and testing.

Cc: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Cc: Neil Brown <neilb@suse.de>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 net/sunrpc/auth_gss/svcauth_gss.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c
index 066c64a..6179767 100644
--- a/net/sunrpc/auth_gss/svcauth_gss.c
+++ b/net/sunrpc/auth_gss/svcauth_gss.c
@@ -760,11 +760,12 @@ svcauth_gss_register_pseudoflavor(u32 pseudoflavor, char * name)
 	new->h.flavour = &svcauthops_gss;
 	new->pseudoflavor = pseudoflavor;
 
+	stat = 0;
 	test = auth_domain_lookup(name, &new->h);
-	if (test != &new->h) { /* XXX Duplicate registration? */
-		auth_domain_put(&new->h);
-		/* dangling ref-count... */
-		goto out;
+	if (test != &new->h) { /* Duplicate registration */
+		auth_domain_put(test);
+		kfree(new->h.name);
+		goto out_free_dom;
 	}
 	return 0;
 
-- 
1.5.2.5

-- 

[2.6.20.17 review 43/58] dm snapshot: permit invalid activation

[Willy Tarreau]

[-- Attachment #1: 0043-dm-snapshot-permit-invalid-activation.patch --]
[-- Type: text/plain, Size: 1916 bytes --]

Allow invalid snapshots to be activated instead of failing.

This allows userspace to reinstate any given snapshot state - for
example after an unscheduled reboot - and clean up the invalid snapshot
at its leisure.

Signed-off-by: Milan Broz <mbroz@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/md/dm-exception-store.c |   11 ++++++-----
 drivers/md/dm-snap.c            |    5 ++++-
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/md/dm-exception-store.c b/drivers/md/dm-exception-store.c
index 99cdffa..fc496fc 100644
--- a/drivers/md/dm-exception-store.c
+++ b/drivers/md/dm-exception-store.c
@@ -453,11 +453,6 @@ static int persistent_read_metadata(struct exception_store *store)
 		/*
 		 * Sanity checks.
 		 */
-		if (!ps->valid) {
-			DMWARN("snapshot is marked invalid");
-			return -EINVAL;
-		}
-
 		if (ps->version != SNAPSHOT_DISK_VERSION) {
 			DMWARN("unable to handle snapshot disk version %d",
 			       ps->version);
@@ -465,6 +460,12 @@ static int persistent_read_metadata(struct exception_store *store)
 		}
 
 		/*
+		 * Metadata are valid, but snapshot is invalidated
+		 */
+		if (!ps->valid)
+			return 1;
+
+		/*
 		 * Read the metadata.
 		 */
 		r = read_exceptions(ps);
diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index 0821a2b..9227ba4 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -522,9 +522,12 @@ static int snapshot_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 
 	/* Metadata must only be loaded into one table at once */
 	r = s->store.read_metadata(&s->store);
-	if (r) {
+	if (r < 0) {
 		ti->error = "Failed to read snapshot metadata";
 		goto bad6;
+	} else if (r > 0) {
+		s->valid = 0;
+		DMWARN("Snapshot is marked invalid.");
 	}
 
 	bio_list_init(&s->queued_bios);
-- 
1.5.2.5

-- 

[2.6.20.17 review 45/58] Hangup TTY before releasing rfcomm_dev

[Willy Tarreau]

[-- Attachment #1: 0045-Hangup-TTY-before-releasing-rfcomm_dev.patch --]
[-- Type: text/plain, Size: 1069 bytes --]

The core problem is that RFCOMM socket layer ioctl can release
rfcomm_dev struct while RFCOMM TTY layer is still actively using
it. Calling tty_vhangup() is needed for a synchronous hangup before
rfcomm_dev is freed.

Addresses the oops at http://bugzilla.kernel.org/show_bug.cgi?id=7509

Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 net/bluetooth/rfcomm/tty.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index eb2b524..e1b8663 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -381,6 +381,10 @@ static int rfcomm_release_dev(void __user *arg)
 	if (req.flags & (1 << RFCOMM_HANGUP_NOW))
 		rfcomm_dlc_close(dev->dlc, 0);
 
+	/* Shut down TTY synchronously before freeing rfcomm_dev */
+	if (dev->tty)
+		tty_vhangup(dev->tty);
+
 	rfcomm_dev_del(dev);
 	rfcomm_dev_put(dev);
 	return 0;
-- 
1.5.2.5

-- 

[2.6.20.17 review 46/58] Keep rfcomm_dev on the list until it is freed

[Willy Tarreau]

[-- Attachment #1: 0046-Keep-rfcomm_dev-on-the-list-until-it-is-freed.patch --]
[-- Type: text/plain, Size: 3364 bytes --]

This patch changes the RFCOMM TTY release process so that the TTY is kept
on the list until it is really freed. A new device flag is used to keep
track of released TTYs.

Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 include/net/bluetooth/rfcomm.h |    1 +
 net/bluetooth/rfcomm/tty.c     |   30 ++++++++++++++++++++++--------
 2 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h
index 3c563f0..25aa575 100644
--- a/include/net/bluetooth/rfcomm.h
+++ b/include/net/bluetooth/rfcomm.h
@@ -323,6 +323,7 @@ int  rfcomm_connect_ind(struct rfcomm_session *s, u8 channel, struct rfcomm_dlc
 #define RFCOMM_RELEASE_ONHUP  1
 #define RFCOMM_HANGUP_NOW     2
 #define RFCOMM_TTY_ATTACHED   3
+#define RFCOMM_TTY_RELEASED   4
 
 struct rfcomm_dev_req {
 	s16      dev_id;
diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index e1b8663..26e8c02 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -93,6 +93,10 @@ static void rfcomm_dev_destruct(struct rfcomm_dev *dev)
 
 	BT_DBG("dev %p dlc %p", dev, dlc);
 
+	write_lock_bh(&rfcomm_dev_lock);
+	list_del_init(&dev->list);
+	write_unlock_bh(&rfcomm_dev_lock);
+
 	rfcomm_dlc_lock(dlc);
 	/* Detach DLC if it's owned by this dev */
 	if (dlc->owner == dev)
@@ -154,8 +158,13 @@ static inline struct rfcomm_dev *rfcomm_dev_get(int id)
 	read_lock(&rfcomm_dev_lock);
 
 	dev = __rfcomm_dev_get(id);
-	if (dev)
-		rfcomm_dev_hold(dev);
+
+	if (dev) {
+		if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
+			dev = NULL;
+		else
+			rfcomm_dev_hold(dev);
+	}
 
 	read_unlock(&rfcomm_dev_lock);
 
@@ -263,6 +272,12 @@ out:
 
 	tty_register_device(rfcomm_tty_driver, dev->id, rfcomm_get_device(dev));
 
+	if (IS_ERR(dev->tty_dev)) {
+		list_del(&dev->list);
+		kfree(dev);
+		return PTR_ERR(dev->tty_dev);
+	}
+
 	return dev->id;
 }
 
@@ -270,10 +285,7 @@ static void rfcomm_dev_del(struct rfcomm_dev *dev)
 {
 	BT_DBG("dev %p", dev);
 
-	write_lock_bh(&rfcomm_dev_lock);
-	list_del_init(&dev->list);
-	write_unlock_bh(&rfcomm_dev_lock);
-
+	set_bit(RFCOMM_TTY_RELEASED, &dev->flags);
 	rfcomm_dev_put(dev);
 }
 
@@ -327,7 +339,7 @@ static int rfcomm_create_dev(struct sock *sk, void __user *arg)
 	if (copy_from_user(&req, arg, sizeof(req)))
 		return -EFAULT;
 
-	BT_DBG("sk %p dev_id %id flags 0x%x", sk, req.dev_id, req.flags);
+	BT_DBG("sk %p dev_id %d flags 0x%x", sk, req.dev_id, req.flags);
 
 	if (req.flags != NOCAP_FLAGS && !capable(CAP_NET_ADMIN))
 		return -EPERM;
@@ -368,7 +380,7 @@ static int rfcomm_release_dev(void __user *arg)
 	if (copy_from_user(&req, arg, sizeof(req)))
 		return -EFAULT;
 
-	BT_DBG("dev_id %id flags 0x%x", req.dev_id, req.flags);
+	BT_DBG("dev_id %d flags 0x%x", req.dev_id, req.flags);
 
 	if (!(dev = rfcomm_dev_get(req.dev_id)))
 		return -ENODEV;
@@ -417,6 +429,8 @@ static int rfcomm_get_dev_list(void __user *arg)
 
 	list_for_each(p, &rfcomm_dev_list) {
 		struct rfcomm_dev *dev = list_entry(p, struct rfcomm_dev, list);
+		if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
+			continue;
 		(di + n)->id      = dev->id;
 		(di + n)->flags   = dev->flags;
 		(di + n)->state   = dev->dlc->state;
-- 
1.5.2.5

-- 

[2.6.20.17 review 47/58] IPV6: /proc/net/anycast6 unbalanced inet6_dev refcnt

[Willy Tarreau]

[-- Attachment #1: 0047-IPV6-proc-net-anycast6-unbalanced-inet6_dev-refcnt.patch --]
[-- Type: text/plain, Size: 802 bytes --]

Reading /proc/net/anycast6 when there is no anycast address
on an interface results in an ever-increasing inet6_dev reference
count, as well as a reference to the netdevice you can't get rid of.

Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Marcus Meissner <meissner@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 net/ipv6/anycast.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index fe0c895..7cf5248 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -67,6 +67,7 @@ ip6_onlink(struct in6_addr *addr, struct net_device *dev)
 				break;
 		}
 		read_unlock_bh(&idev->lock);
+		in6_dev_put(idev);
 	}
 	rcu_read_unlock();
 	return onlink;
-- 
1.5.2.5

-- 

[2.6.20.17 review 48/58] sx: switch subven and subid values

[Willy Tarreau]

[-- Attachment #1: 0048-sx-switch-subven-and-subid-values.patch --]
[-- Type: text/plain, Size: 1058 bytes --]

sx.c is failing to locate Graham's card.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Graham Murray <gmurray@webwayone.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/char/sx.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/sx.c b/drivers/char/sx.c
index 1da92a6..85a2328 100644
--- a/drivers/char/sx.c
+++ b/drivers/char/sx.c
@@ -2721,9 +2721,9 @@ static void __devexit sx_pci_remove(struct pci_dev *pdev)
    its because the standard requires it. So check for SUBVENDOR_ID. */
 static struct pci_device_id sx_pci_tbl[] = {
 	{ PCI_VENDOR_ID_SPECIALIX, PCI_DEVICE_ID_SPECIALIX_SX_XIO_IO8,
-		.subvendor = 0x0200,.subdevice = PCI_ANY_ID },
+		.subvendor = PCI_ANY_ID, .subdevice = 0x0200 },
 	{ PCI_VENDOR_ID_SPECIALIX, PCI_DEVICE_ID_SPECIALIX_SX_XIO_IO8,
-		.subvendor = 0x0300,.subdevice = PCI_ANY_ID },
+		.subvendor = PCI_ANY_ID, .subdevice = 0x0300 },
 	{ 0 }
 };
 
-- 
1.5.2.5

-- 

[2.6.20.17 review 49/58] UML: exports for hostfs

[Willy Tarreau]

[-- Attachment #1: 0049-UML-exports-for-hostfs.patch --]
[-- Type: text/plain, Size: 2030 bytes --]

Add some exports for hostfs that are required after Alberto Bertogli's
fixes for accessing unlinked host files.

Also did some style cleanups while I was here.

Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 arch/um/os-Linux/user_syms.c |   20 ++++++++------------
 1 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/arch/um/os-Linux/user_syms.c b/arch/um/os-Linux/user_syms.c
index 3f33165..419b2d5 100644
--- a/arch/um/os-Linux/user_syms.c
+++ b/arch/um/os-Linux/user_syms.c
@@ -5,7 +5,8 @@
  * so I *must* declare good prototypes for them and then EXPORT them.
  * The kernel code uses the macro defined by include/linux/string.h,
  * so I undef macros; the userspace code does not include that and I
- * add an EXPORT for the glibc one.*/
+ * add an EXPORT for the glibc one.
+ */
 
 #undef strlen
 #undef strstr
@@ -61,12 +62,18 @@ EXPORT_SYMBOL_PROTO(dup2);
 EXPORT_SYMBOL_PROTO(__xstat);
 EXPORT_SYMBOL_PROTO(__lxstat);
 EXPORT_SYMBOL_PROTO(__lxstat64);
+EXPORT_SYMBOL_PROTO(__fxstat64);
 EXPORT_SYMBOL_PROTO(lseek);
 EXPORT_SYMBOL_PROTO(lseek64);
 EXPORT_SYMBOL_PROTO(chown);
+EXPORT_SYMBOL_PROTO(fchown);
 EXPORT_SYMBOL_PROTO(truncate);
+EXPORT_SYMBOL_PROTO(ftruncate64);
 EXPORT_SYMBOL_PROTO(utime);
+EXPORT_SYMBOL_PROTO(utimes);
+EXPORT_SYMBOL_PROTO(futimes);
 EXPORT_SYMBOL_PROTO(chmod);
+EXPORT_SYMBOL_PROTO(fchmod);
 EXPORT_SYMBOL_PROTO(rename);
 EXPORT_SYMBOL_PROTO(__xmknod);
 
@@ -102,14 +109,3 @@ EXPORT_SYMBOL(__stack_smash_handler);
 
 extern long __guard __attribute__((weak));
 EXPORT_SYMBOL(__guard);
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---------------------------------------------------------------------------
- * Local variables:
- * c-file-style: "linux"
- * End:
- */
-- 
1.5.2.5

-- 

[2.6.20.17 review 50/58] random: fix bound check ordering (CVE-2007-3105)

[Willy Tarreau]

[-- Attachment #1: 0050-random-fix-bound-check-ordering-CVE-2007-3105.patch --]
[-- Type: text/plain, Size: 1480 bytes --]

If root raised the default wakeup threshold over the size of the
output pool, the pool transfer function could overflow the stack with
RNG bytes, causing a DoS or potential privilege escalation.

(Bug reported by the PaX Team <pageexec@freemail.hu>)

Cc: Theodore Tso <tytso@mit.edu>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Matt Mackall <mpm@selenic.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/char/random.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 263e5e5..96561c8 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -693,9 +693,14 @@ static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes)
 
 	if (r->pull && r->entropy_count < nbytes * 8 &&
 	    r->entropy_count < r->poolinfo->POOLBITS) {
-		int bytes = max_t(int, random_read_wakeup_thresh / 8,
-				min_t(int, nbytes, sizeof(tmp)));
+		/* If we're limited, always leave two wakeup worth's BITS */
 		int rsvd = r->limit ? 0 : random_read_wakeup_thresh/4;
+		int bytes = nbytes;
+
+		/* pull at least as many as BYTES as wakeup BITS */
+		bytes = max_t(int, bytes, random_read_wakeup_thresh / 8);
+		/* but never more than the buffer size */
+		bytes = min_t(int, bytes, sizeof(tmp));
 
 		DEBUG_ENT("going to reseed %s with %d bits "
 			  "(%d of %d requested)
",
-- 
1.5.2.5

-- 

[2.6.20.17 review 51/58] softmac: Fix deadlock of wx_set_essid with assoc work

[Willy Tarreau]

[-- Attachment #1: 0051-softmac-Fix-deadlock-of-wx_set_essid-with-assoc-wor.patch --]
[-- Type: text/plain, Size: 1747 bytes --]

The essid wireless extension does deadlock against the assoc mutex,
as we don't unlock the assoc mutex when flushing the workqueue, which
also holds the lock.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 net/ieee80211/softmac/ieee80211softmac_wx.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
index fb58e03..c3c39ed 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -74,8 +74,8 @@ ieee80211softmac_wx_set_essid(struct net_device *net_dev,
 	struct ieee80211softmac_auth_queue_item *authptr;
 	int length = 0;
 
+check_assoc_again:
 	mutex_lock(&sm->associnfo.mutex);
-
 	/* Check if we're already associating to this or another network
 	 * If it's another network, cancel and start over with our new network
 	 * If it's our network, ignore the change, we're already doing it!
@@ -98,13 +98,18 @@ ieee80211softmac_wx_set_essid(struct net_device *net_dev,
 				cancel_delayed_work(&authptr->work);
 			sm->associnfo.bssvalid = 0;
 			sm->associnfo.bssfixed = 0;
-			flush_scheduled_work();
 			sm->associnfo.associating = 0;
 			sm->associnfo.associated = 0;
+			/* We must unlock to avoid deadlocks with the assoc workqueue
+			 * on the associnfo.mutex */
+			mutex_unlock(&sm->associnfo.mutex);
+			flush_scheduled_work();
+			/* Avoid race! Check assoc status again. Maybe someone started an
+			 * association while we flushed. */
+			goto check_assoc_again;
 		}
 	}
 
-
 	sm->associnfo.static_essid = 0;
 	sm->associnfo.assoc_wait = 0;
 
-- 
1.5.2.5

-- 

[2.6.20.17 review 52/58] ata_piix: update map 10b for ich8m

[Willy Tarreau]

[-- Attachment #1: 0052-ata_piix-update-map-10b-for-ich8m.patch --]
[-- Type: text/plain, Size: 886 bytes --]

Fix map entry 10b for ich8.  It's [P0 P2 IDE IDE] like ich6 / ich6m.

Signed-off-by: Tejun Heo <htejun@gmail.com>
Acked-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/ata/ata_piix.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 57c0db3..0c646dc 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -431,7 +431,7 @@ static const struct piix_map_db ich8_map_db = {
 		/* PM   PS   SM   SS       MAP */
 		{  P0,  P2,  P1,  P3 }, /* 00b (hardwired when in AHCI) */
 		{  RV,  RV,  RV,  RV },
-		{  IDE,  IDE,  NA,  NA }, /* 10b (IDE mode) */
+		{  P0,  P2, IDE, IDE }, /* 10b (IDE mode) */
 		{  RV,  RV,  RV,  RV },
 	},
 };
-- 
1.5.2.5

-- 

[2.6.20.17 review 53/58] direct-io: fix error-path crashes

[Willy Tarreau]

[-- Attachment #1: 0053-direct-io-fix-error-path-crashes.patch --]
[-- Type: text/plain, Size: 1191 bytes --]

Need to initialize map_bh.b_state to zero.  Otherwise, in case of a faulty
user-buffer its possible to go into dio_zero_block() and submit a page by
mistake - since it checks for buffer_new().

http://marc.info/?l=linux-kernel&m=118551339032528&w=2

akpm: Linus had a (better) patch to just do a kzalloc() in there, but it got
lost.  Probably this version is better for -stable anwyay.

Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
Acked-by: Joe Jin <joe.jin@oracle.com>
Acked-by: Zach Brown <zach.brown@oracle.com>
Cc: gurudas pai <gurudas.pai@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 fs/direct-io.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/direct-io.c b/fs/direct-io.c
index d9d0833..0286993 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -978,6 +978,7 @@ direct_io_worker(int rw, struct kiocb *iocb, struct inode *inode,
 	dio->get_block = get_block;
 	dio->end_io = end_io;
 	dio->map_bh.b_private = NULL;
+	dio->map_bh.b_state = 0;
 	dio->final_block_in_bio = -1;
 	dio->next_block_for_io = -1;
 
-- 
1.5.2.5

-- 

[2.6.20.17 review 54/58] stifb: detect cards in double buffer mode more reliably

[Willy Tarreau]

[-- Attachment #1: 0054-stifb-detect-cards-in-double-buffer-mode-more-relia.patch --]
[-- Type: text/plain, Size: 2660 bytes --]

Visualize-EG, Graffiti and A4450A graphics cards on PARISC can
be configured in double-buffer and standard mode, but the stifb
driver supports standard mode only.
This patch detects double-buffered cards more reliable.

It is a real bugfix for a very nasty problem for all parisc users which have
wrongly configured their graphic card.  The problem: The stifb graphics driver
will not detect that the card is wrongly configured and then nevertheless just
enables the graphics mode, which it shouldn't.  In the end, the user will see
no further updates / boot messages on the screen.

We had documented this problem already on our FAQ
(http://parisc-linux.org/faq/index.html#viseg "Why do I get corrupted graphics
with my Vis-EG/Graffiti/A4450A card?") but people still run into this problem.
 So having this fix in as early as possible can help us.

Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Antonino Daplas <adaplas@gmail.com>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/video/stifb.c |   19 ++++++++++++-------
 1 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/video/stifb.c b/drivers/video/stifb.c
index 69f3b26..6074ae9 100644
--- a/drivers/video/stifb.c
+++ b/drivers/video/stifb.c
@@ -1101,13 +1101,18 @@ stifb_init_fb(struct sti_struct *sti, int bpp_pref)
 	/* only supported cards are allowed */
 	switch (fb->id) {
 	case CRT_ID_VISUALIZE_EG:
-		/* look for a double buffering device like e.g. the 
-		   "INTERNAL_EG_DX1024" in the RDI precisionbook laptop
-		   which won't work. The same device in non-double 
-		   buffering mode returns "INTERNAL_EG_X1024". */
-		if (strstr(sti->outptr.dev_name, "EG_DX")) {
-		   printk(KERN_WARNING 
-			"stifb: ignoring '%s'. Disable double buffering in IPL menu.
",
+		/* Visualize cards can run either in "double buffer" or
+ 		  "standard" mode. Depending on the mode, the card reports
+		  a different device name, e.g. "INTERNAL_EG_DX1024" in double
+		  buffer mode and "INTERNAL_EG_X1024" in standard mode.
+		  Since this driver only supports standard mode, we check
+		  if the device name contains the string "DX" and tell the
+		  user how to reconfigure the card. */
+		if (strstr(sti->outptr.dev_name, "DX")) {
+		   printk(KERN_WARNING "WARNING: stifb framebuffer driver does not "
+			"support '%s' in double-buffer mode.
"
+			KERN_WARNING "WARNING: Please disable the double-buffer mode "
+			"in IPL menu (the PARISC-BIOS).
",
 			sti->outptr.dev_name);
 		   goto out_err0;
 		}
-- 
1.5.2.5

-- 

[2.6.20.17 review 55/58] pata_atiixp: add SB700 PCI ID

[Willy Tarreau]

[-- Attachment #1: 0055-pata_atiixp-add-SB700-PCI-ID.patch --]
[-- Type: text/plain, Size: 795 bytes --]

[libata] pata_atiixp: add SB700 PCI ID

>From AMD.

Signed-off-by: Jeff Garzik <jeff@garzik.org>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/ata/pata_atiixp.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
index b50ebb6..17d75ec 100644
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -283,6 +283,7 @@ static const struct pci_device_id atiixp[] = {
 	{ PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP300_IDE), },
 	{ PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP400_IDE), },
 	{ PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP600_IDE), },
+	{ PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP700_IDE), },
 
 	{ },
 };
-- 
1.5.2.5

-- 

[2.6.20.17 review 57/58] CPUFREQ: ondemand: add a check to avoid negative load calculation

[Willy Tarreau]

[-- Attachment #1: 0057-CPUFREQ-ondemand-add-a-check-to-avoid-negative-loa.patch --]
[-- Type: text/plain, Size: 1358 bytes --]

Due to rounding and inexact jiffy accounting, idle_ticks can sometimes
be higher than total_ticks. Make sure those cases are handled as
zero load case.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 drivers/cpufreq/cpufreq_ondemand.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
index 3bfaeb5..1d11d13 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -334,7 +334,7 @@ static struct attribute_group dbs_attr_group = {
 static void dbs_check_cpu(struct cpu_dbs_info_s *this_dbs_info)
 {
 	unsigned int idle_ticks, total_ticks;
-	unsigned int load;
+	unsigned int load = 0;
 	cputime64_t cur_jiffies;
 
 	struct cpufreq_policy *policy;
@@ -380,7 +380,8 @@ static void dbs_check_cpu(struct cpu_dbs_info_s *this_dbs_info)
 		if (tmp_idle_ticks < idle_ticks)
 			idle_ticks = tmp_idle_ticks;
 	}
-	load = (100 * (total_ticks - idle_ticks)) / total_ticks;
+	if (likely(total_ticks > idle_ticks))
+		load = (100 * (total_ticks - idle_ticks)) / total_ticks;
 
 	/* Check for frequency increase */
 	if (load > dbs_tuners_ins.up_threshold) {
-- 
1.5.2.5

-- 

[2.6.20.17 review 58/58] Reset current->pdeath_signal on SUID binary execution (CVE-2007-3848)

[Willy Tarreau]

[-- Attachment #1: 0058-Reset-current-pdeath_signal-on-SUID-binary-executio.patch --]
[-- Type: text/plain, Size: 1522 bytes --]

This fixes a vulnerability in the "parent process death signal"
implementation discoverd by Wojciech Purczynski of COSEINC PTE Ltd.
and iSEC Security Research.

http://marc.info/?l=bugtraq&m=118711306802632&w=2

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 fs/exec.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 0f8573a..bd1ab3f 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -881,9 +881,12 @@ int flush_old_exec(struct linux_binprm * bprm)
 	 */
 	current->mm->task_size = TASK_SIZE;
 
-	if (bprm->e_uid != current->euid || bprm->e_gid != current->egid || 
-	    file_permission(bprm->file, MAY_READ) ||
-	    (bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP)) {
+	if (bprm->e_uid != current->euid || bprm->e_gid != current->egid) {
+		suid_keys(current);
+		current->mm->dumpable = suid_dumpable;
+		current->pdeath_signal = 0;
+	} else if (file_permission(bprm->file, MAY_READ) ||
+			(bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP)) {
 		suid_keys(current);
 		current->mm->dumpable = suid_dumpable;
 	}
@@ -974,8 +977,10 @@ void compute_creds(struct linux_binprm *bprm)
 {
 	int unsafe;
 
-	if (bprm->e_uid != current->uid)
+	if (bprm->e_uid != current->uid) {
 		suid_keys(current);
+		current->pdeath_signal = 0;
+	}
 	exec_keys(current);
 
 	task_lock(current);
-- 
1.5.2.5

-- 

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Michal Piotrowski]

Hi Willy,

On 22/08/07, Willy Tarreau <w@1wt.eu> wrote:
> This is the start of the review cycle for the stable 2.6.20.17
> kernel release. This version catches up with 2.6.22.4, and 58
> patches will be posted as a response to this message.
>
> The following security issues are solved :
>   CVE-2007-3105
>   CVE-2007-3848
>   CVE-2007-3851
>
> The rolled up patch can be found here :
>    ftp.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.20.17-rc1.gz
>
> Responses should be made by August 24, 2007, 19:00:00 UTC. Anything
> received after that time might be too late.

I got a problem with SELinux
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config

rpm -qa selinux-policy*
selinux-policy-devel-2.6.4-33.fc7
selinux-policy-2.6.4-33.fc7
selinux-policy-targeted-2.6.4-33.fc7

I didn't tested 2.6.20.* since 2.6.20 release so it might take some
time to figure out.

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Willy Tarreau]

Hi Michal,

On Wed, Aug 22, 2007 at 01:10:44PM +0200, Michal Piotrowski wrote:
> Hi Willy,
> 
> On 22/08/07, Willy Tarreau <w@1wt.eu> wrote:
> > This is the start of the review cycle for the stable 2.6.20.17
> > kernel release. This version catches up with 2.6.22.4, and 58
> > patches will be posted as a response to this message.
> >
> > The following security issues are solved :
> >   CVE-2007-3105
> >   CVE-2007-3848
> >   CVE-2007-3851
> >
> > The rolled up patch can be found here :
> >    ftp.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.20.17-rc1.gz
> >
> > Responses should be made by August 24, 2007, 19:00:00 UTC. Anything
> > received after that time might be too late.
> 
> I got a problem with SELinux
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config
> 
> rpm -qa selinux-policy*
> selinux-policy-devel-2.6.4-33.fc7
> selinux-policy-2.6.4-33.fc7
> selinux-policy-targeted-2.6.4-33.fc7
> 
> I didn't tested 2.6.20.* since 2.6.20 release so it might take some
> time to figure out.

I'm a total looser in selinux, so I'll not be able to help here. Could you
please test if 2.6.20.16 works ? It would at least tell us if it's one of
the patches in 17-rc1.

Thanks,
Willy

Re: [2.6.20.17 review 27/58] Include serial_reg.h with userspace headers

[Willy Tarreau]

Hi Russell,

On Wed, Aug 22, 2007 at 10:23:32AM +0100, Russell King wrote:
> On Wed, Aug 22, 2007 at 11:39:11AM +0200, Willy Tarreau wrote:
> > As reported by Gustavo de Nardin <gustavodn@mandriva.com.br>, while trying to
> > compile xosview (http://xosview.sourceforge.net/) with upstream kernel
> > headers being used you get the following errors:
> > serialmeter.cc:48:30: error: linux/serial_reg.h: No such file or directory
> > serialmeter.cc: In member function 'virtual void
> > SerialMeter::checkResources()':
> > serialmeter.cc:71: error: 'UART_LSR' was not declared in this scope
> > serialmeter.cc:71: error: 'UART_MSR' was not declared in this scope
> > ..
> 
> It's probably a good thing to repeat what I said privately about this,
> which is:
> 
> | It should be noted that reading the MSR or LSR of an active 8250 UART
> | has side effects.  In the case of MSR, it clears the bits which indicate
> | that the modem status signals have changed, and clears the associated
> | interrupt.  This can result in loss of hardware flow control on the port.
(...)
> | For a tool which presumably is to assist diagnosing serial problems, it
> | would seem to have the capability of causing further additional problems.
> 
> I leave it up to others to decide that keeping backwards compatibility
> with userspace which is quite obviously broken is more important than
> providing userspace with the persuasion to fix their broken code.

While I agree with you that side effects may be undesirable, I still think
it's important to ensure backwards compatibility in -stable branch, for the
following reasons :

  - people who use -stable want to ensure that they can upgrade in order to
    fix security issues or other bugs without risking (much) regression

  - you do not prevent buggy programs from doing wrong things by removing
    headers. What you will end up with is xosview using the quite common
    #ifndef UART_LSR / #define UART_LSR / #endif. In fact, there *may* be
    some legitimate uses of those defines, eventhough this program abuses
    its capabilities.

Eventhough it's not a good practise to rely on kernel headers for userspace,
at least we should limit build regressions on the user side, as it does not
help the end user understand that the program he builds is wrong.

Thanks,
Willy

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[James Morris]

On Wed, 22 Aug 2007, Michal Piotrowski wrote:

> I got a problem with SELinux
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config

Please set
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=n

You don't have complete policy for the new network controls, which are not 
enabled by default and not integreated fully into distros yet.


-- 
James Morris
<jmorris@namei.org>

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Stephen Smalley]

On Wed, 2007-08-22 at 06:23 -0700, James Morris wrote:
> On Wed, 22 Aug 2007, Michal Piotrowski wrote:
> 
> > I got a problem with SELinux
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config
> 
> Please set
> CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=n
> 
> You don't have complete policy for the new network controls, which are not 
> enabled by default and not integreated fully into distros yet.

Still, that denial shouldn't be against kernel_t unless he has iptables
SECMARK rules that assign that value.

It's the change to the skb allocator - no longer clears up through
truesize and thus secmark is garbage initially.  That would apply to
mainline too.

-- 
Stephen Smalley
National Security Agency

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[James Morris]

On Wed, 22 Aug 2007, James Morris wrote:

> On Wed, 22 Aug 2007, Michal Piotrowski wrote:
> 
> > I got a problem with SELinux
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config
> 
> Please set
> CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=n
> 
> You don't have complete policy for the new network controls, which are not 
> enabled by default and not integreated fully into distros yet.

Actually, this looks to be a bug where the secmark field of the skb is not 
being initialized correctly.  Patch coming soon...


-- 
James Morris
<jmorris@namei.org>

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Stephen Smalley]

On Wed, 2007-08-22 at 09:36 -0400, Stephen Smalley wrote:
> On Wed, 2007-08-22 at 06:23 -0700, James Morris wrote:
> > On Wed, 22 Aug 2007, Michal Piotrowski wrote:
> > 
> > > I got a problem with SELinux
> > > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
> > > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config
> > 
> > Please set
> > CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=n
> > 
> > You don't have complete policy for the new network controls, which are not 
> > enabled by default and not integreated fully into distros yet.
> 
> Still, that denial shouldn't be against kernel_t unless he has iptables
> SECMARK rules that assign that value.
> 
> It's the change to the skb allocator - no longer clears up through
> truesize and thus secmark is garbage initially.  That would apply to
> mainline too.

Oops, never mind - tail still follows secmark, so that shouldn't matter.
So I'm not sure why we are getting a bad value for secmark here - should
be initialized to zero and never modified unless there is an iptables
secmark rule.

-- 
Stephen Smalley
National Security Agency

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[James Morris]

On Wed, 22 Aug 2007, Stephen Smalley wrote:

> Oops, never mind - tail still follows secmark, so that shouldn't matter.
> So I'm not sure why we are getting a bad value for secmark here - should
> be initialized to zero and never modified unless there is an iptables
> secmark rule.

Michal, do you see this in current git?


-- 
James Morris
<jmorris@namei.org>

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Michal Piotrowski]

On 22/08/07, James Morris <jmorris@namei.org> wrote:
> On Wed, 22 Aug 2007, Stephen Smalley wrote:
>
> > Oops, never mind - tail still follows secmark, so that shouldn't matter.
> > So I'm not sure why we are getting a bad value for secmark here - should
> > be initialized to zero and never modified unless there is an iptables
> > secmark rule.
>
> Michal, do you see this in current git?

No, I do not see this problem in 2.6.23. I had similar problem last
month, but it is fixed now.

http://lkml.org/lkml/2007/7/12/362

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Stephen Smalley]

On Wed, 2007-08-22 at 16:29 +0200, Michal Piotrowski wrote:
> On 22/08/07, James Morris <jmorris@namei.org> wrote:
> > On Wed, 22 Aug 2007, Stephen Smalley wrote:
> >
> > > Oops, never mind - tail still follows secmark, so that shouldn't matter.
> > > So I'm not sure why we are getting a bad value for secmark here - should
> > > be initialized to zero and never modified unless there is an iptables
> > > secmark rule.
> >
> > Michal, do you see this in current git?
> 
> No, I do not see this problem in 2.6.23. I had similar problem last
> month, but it is fixed now.
> 
> http://lkml.org/lkml/2007/7/12/362

The difference being that there the denials were against unlabeled_t
(the expected default in the presence of no iptables SECMARK rules, and
allowed by current policies), while the denials against 2.6.20.17 were
against kernel_t.  Which shouldn't ever happen unless you have an
iptables SECMARK rule that assigns that value to a packet.  So this is a
different issue.  BTW, the fact that it is showing up as kernel_t means
that skb->secmark == SECINITSID_KERNEL == 1, FWIW.  Whereas it should be
zero in the absence of iptables rules that set it.

-- 
Stephen Smalley
National Security Agency

Re: [2.6.20.17 review 32/58] fs: 9p/conv.c error path fix

[Eric Van Hensbergen]

On 8/22/07, Willy Tarreau <w@1wt.eu> wrote:
> When buf_check_overflow() returns != 0 we will hit kfree(ERR_PTR(err))
> and it will not be happy about it.
>
> Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
Acked-by: Eric Van Hensbergen <ericvh@gmail.com>

This seems to be in the current code as well, I'll forward-port the patch...

                    -eric

Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy

[Chuck Ebbert]

On 08/22/2007 05:39 AM, Willy Tarreau wrote:
> This patch contains errata fixes for the realtek phy. It only renamed the
> defines to be phy specific.
> 
> Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
>  drivers/net/forcedeth.c |   54 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 54 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
> index c383dc3..dbfdbed 100644
> --- a/drivers/net/forcedeth.c
> +++ b/drivers/net/forcedeth.c
> @@ -554,6 +554,7 @@ union ring_type {
>  #define PHY_OUI_MARVELL	0x5043
>  #define PHY_OUI_CICADA	0x03f1
>  #define PHY_OUI_VITESSE	0x01c1
> +#define PHY_OUI_REALTEK	0x01c1
>  #define PHYID1_OUI_MASK	0x03ff
>  #define PHYID1_OUI_SHFT	6
>  #define PHYID2_OUI_MASK	0xfc00

Realtek is 0x0732

This is still wrong upstream -- what happened to the patch to fix it?

Re: [2.6.20.17 review 32/58] fs: 9p/conv.c error path fix

[Willy Tarreau]

On Wed, Aug 22, 2007 at 10:53:02AM -0500, Eric Van Hensbergen wrote:
> On 8/22/07, Willy Tarreau <w@1wt.eu> wrote:
> > When buf_check_overflow() returns != 0 we will hit kfree(ERR_PTR(err))
> > and it will not be happy about it.
> >
> > Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> Acked-by: Eric Van Hensbergen <ericvh@gmail.com>
> 
> This seems to be in the current code as well, I'll forward-port the patch...
 
Thanks Eric,
Willy

Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy

[Willy Tarreau]

On Wed, Aug 22, 2007 at 11:56:42AM -0400, Chuck Ebbert wrote:
> On 08/22/2007 05:39 AM, Willy Tarreau wrote:
> > This patch contains errata fixes for the realtek phy. It only renamed the
> > defines to be phy specific.
> > 
> > Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > ---
> >  drivers/net/forcedeth.c |   54 +++++++++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 54 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
> > index c383dc3..dbfdbed 100644
> > --- a/drivers/net/forcedeth.c
> > +++ b/drivers/net/forcedeth.c
> > @@ -554,6 +554,7 @@ union ring_type {
> >  #define PHY_OUI_MARVELL	0x5043
> >  #define PHY_OUI_CICADA	0x03f1
> >  #define PHY_OUI_VITESSE	0x01c1
> > +#define PHY_OUI_REALTEK	0x01c1
> >  #define PHYID1_OUI_MASK	0x03ff
> >  #define PHYID1_OUI_SHFT	6
> >  #define PHYID2_OUI_MASK	0xfc00
> 
> Realtek is 0x0732
> 
> This is still wrong upstream -- what happened to the patch to fix it?

Good catch, thanks Chuck! I've already seen the fix somewhere, I believe it
was on netdev, though I'm not sure. I'm fixing the patch in place right now.
I can add your signoff if you want.

Cheers,
Willy

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[James Morris]

On Wed, 22 Aug 2007, Michal Piotrowski wrote:

> On 22/08/07, James Morris <jmorris@namei.org> wrote:
> > On Wed, 22 Aug 2007, Stephen Smalley wrote:
> >
> > > Oops, never mind - tail still follows secmark, so that shouldn't matter.
> > > So I'm not sure why we are getting a bad value for secmark here - should
> > > be initialized to zero and never modified unless there is an iptables
> > > secmark rule.
> >
> > Michal, do you see this in current git?
> 
> No, I do not see this problem in 2.6.23. I had similar problem last
> month, but it is fixed now.
> 
> http://lkml.org/lkml/2007/7/12/362

The previous problem is theoretically unrelated.  It arose via a separate 
mechanism which can't be used at the same as the one you're seeing now in 
the logs.

So this either looks like a problem which has gone unnoticed and was 
inadvertently fixed at some point, or is unique to the 2.6.20 stable 
series.


- James
-- 
James Morris
<jmorris@namei.org>

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Michal Piotrowski]

On 22/08/07, James Morris <jmorris@namei.org> wrote:
> On Wed, 22 Aug 2007, Michal Piotrowski wrote:
>
> > On 22/08/07, James Morris <jmorris@namei.org> wrote:
> > > On Wed, 22 Aug 2007, Stephen Smalley wrote:
> > >
> > > > Oops, never mind - tail still follows secmark, so that shouldn't matter.
> > > > So I'm not sure why we are getting a bad value for secmark here - should
> > > > be initialized to zero and never modified unless there is an iptables
> > > > secmark rule.
> > >
> > > Michal, do you see this in current git?
> >
> > No, I do not see this problem in 2.6.23. I had similar problem last
> > month, but it is fixed now.
> >
> > http://lkml.org/lkml/2007/7/12/362
>
> The previous problem is theoretically unrelated.  It arose via a separate
> mechanism which can't be used at the same as the one you're seeing now in
> the logs.
>
> So this either looks like a problem which has gone unnoticed and was
> inadvertently fixed at some point, or is unique to the 2.6.20 stable
> series.

Yup, it is very interesting why no one noticed it. Binary search in progress:
good - 2.6.20.4
bad - 2.6.20.8

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[James Morris]

On Wed, 22 Aug 2007, Michal Piotrowski wrote:

> Yup, it is very interesting why no one noticed it. 

The new network controls are not enabled by default yet in distros.


- James
-- 
James Morris
<jmorris@namei.org>

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Michal Piotrowski]

On 22/08/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> On 22/08/07, James Morris <jmorris@namei.org> wrote:
[snip]
> > The previous problem is theoretically unrelated.  It arose via a separate
> > mechanism which can't be used at the same as the one you're seeing now in
> > the logs.
> >
> > So this either looks like a problem which has gone unnoticed and was
> > inadvertently fixed at some point, or is unique to the 2.6.20 stable
> > series.
>
> Yup, it is very interesting why no one noticed it. Binary search in progress:
> good - 2.6.20.4
> bad - 2.6.20.8

Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
any suggestions?

I also have seen this avc on 2.6.20.6 during reboot

[ 2333.905944] audit(1187803699.273:271): avc:  denied  { send } for
saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0
scontext=user_u:system_r:unconfined_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=packet
[ 2334.420598] audit(1187803699.789:272): avc:  denied  { send } for
saddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0
scontext=user_u:system_r:unconfined_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=packet

so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6

http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Michal Piotrowski]

On 22/08/07, James Morris <jmorris@namei.org> wrote:
> On Wed, 22 Aug 2007, Michal Piotrowski wrote:
>
> > Yup, it is very interesting why no one noticed it.
>
> The new network controls are not enabled by default yet in distros.

That's why I enable most of these unsupported features :)

Unfortunately, I don't have time to test all stable/development releases.

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy

[Prakash Punnoor]

[-- Attachment #1: Type: text/plain, Size: 4261 bytes --]

Hi,

even if Greg is waiting for some special invitation 
(http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by Ayaz on 
top:

http://lkml.org/lkml/2007/8/10/296

Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:

bye,

Prakash


On the day of Wednesday 22 August 2007 Willy Tarreau hast written:
> This patch contains errata fixes for the realtek phy. It only renamed the
> defines to be phy specific.
>
> Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
>  drivers/net/forcedeth.c |   54
> +++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 54
> insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
> index c383dc3..dbfdbed 100644
> --- a/drivers/net/forcedeth.c
> +++ b/drivers/net/forcedeth.c
> @@ -554,6 +554,7 @@ union ring_type {
>  #define PHY_OUI_MARVELL	0x5043
>  #define PHY_OUI_CICADA	0x03f1
>  #define PHY_OUI_VITESSE	0x01c1
> +#define PHY_OUI_REALTEK	0x01c1
>  #define PHYID1_OUI_MASK	0x03ff
>  #define PHYID1_OUI_SHFT	6
>  #define PHYID2_OUI_MASK	0xfc00
> @@ -583,6 +584,13 @@ union ring_type {
>  #define PHY_VITESSE_INIT8	0x0100
>  #define PHY_VITESSE_INIT9	0x8f82
>  #define PHY_VITESSE_INIT10	0x0
> +#define PHY_REALTEK_INIT_REG1	0x1f
> +#define PHY_REALTEK_INIT_REG2	0x19
> +#define PHY_REALTEK_INIT_REG3	0x13
> +#define PHY_REALTEK_INIT1	0x0000
> +#define PHY_REALTEK_INIT2	0x8e00
> +#define PHY_REALTEK_INIT3	0x0001
> +#define PHY_REALTEK_INIT4	0xad17
>
>  #define PHY_GIGABIT	0x0100
>
> @@ -1106,6 +1114,28 @@ static int phy_init(struct net_device *dev)
>  			return PHY_ERROR;
>  		}
>  	}
> +	if (np->phy_oui == PHY_OUI_REALTEK) {
> +		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT1))
> { +			printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> +			return PHY_ERROR;
> +		}
> +		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG2, PHY_REALTEK_INIT2))
> { +			printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> +			return PHY_ERROR;
> +		}
> +		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT3))
> { +			printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> +			return PHY_ERROR;
> +		}
> +		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG3, PHY_REALTEK_INIT4))
> { +			printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> +			return PHY_ERROR;
> +		}
> +		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT1))
> { +			printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> +			return PHY_ERROR;
> +		}
> +	}
>
>  	/* set advertise register */
>  	reg = mii_rw(dev, np->phyaddr, MII_ADVERTISE, MII_READ);
> @@ -1242,6 +1272,30 @@ static int phy_init(struct net_device *dev)
>  			return PHY_ERROR;
>  		}
>  	}
> +	if (np->phy_oui == PHY_OUI_REALTEK) {
> +		/* reset could have cleared these out, set them back */
> +		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT1))
> { +			printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> +			return PHY_ERROR;
> +		}
> +		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG2, PHY_REALTEK_INIT2))
> { +			printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> +			return PHY_ERROR;
> +		}
> +		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT3))
> { +			printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> +			return PHY_ERROR;
> +		}
> +		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG3, PHY_REALTEK_INIT4))
> { +			printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> +			return PHY_ERROR;
> +		}
> +		if (mii_rw(dev, np->phyaddr, PHY_REALTEK_INIT_REG1, PHY_REALTEK_INIT1))
> { +			printk(KERN_INFO "%s: phy init failed.
> ", pci_name(np->pci_dev));
> +			return PHY_ERROR;
> +		}
> +	}
> +
>  	/* some phys clear out pause advertisment on reset, set it back */
>  	mii_rw(dev, np->phyaddr, MII_ADVERTISE, reg);
>
> --
> 1.5.2.5



-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [stable] [2.6.20.17 review 32/58] fs: 9p/conv.c error path fix

[Greg KH]

On Wed, Aug 22, 2007 at 10:53:02AM -0500, Eric Van Hensbergen wrote:
> On 8/22/07, Willy Tarreau <w@1wt.eu> wrote:
> > When buf_check_overflow() returns != 0 we will hit kfree(ERR_PTR(err))
> > and it will not be happy about it.
> >
> > Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> Acked-by: Eric Van Hensbergen <ericvh@gmail.com>
> 
> This seems to be in the current code as well, I'll forward-port the patch...

Huh?  It's not already in mainline?  Then how did it ever get into the
stable queue?

Ugh.

greg k-h

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Stephen Smalley]

On Wed, 2007-08-22 at 19:50 +0200, Michal Piotrowski wrote:
> On 22/08/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > On 22/08/07, James Morris <jmorris@namei.org> wrote:
> [snip]
> > > The previous problem is theoretically unrelated.  It arose via a separate
> > > mechanism which can't be used at the same as the one you're seeing now in
> > > the logs.
> > >
> > > So this either looks like a problem which has gone unnoticed and was
> > > inadvertently fixed at some point, or is unique to the 2.6.20 stable
> > > series.
> >
> > Yup, it is very interesting why no one noticed it. Binary search in progress:
> > good - 2.6.20.4
> > bad - 2.6.20.8
> 
> Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
> http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
> any suggestions?
> 
> I also have seen this avc on 2.6.20.6 during reboot
> 
> [ 2333.905944] audit(1187803699.273:271): avc:  denied  { send } for
> saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0
> scontext=user_u:system_r:unconfined_t:s0
> tcontext=system_u:system_r:kernel_t:s0 tclass=packet
> [ 2334.420598] audit(1187803699.789:272): avc:  denied  { send } for
> saddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0
> scontext=user_u:system_r:unconfined_t:s0
> tcontext=system_u:system_r:kernel_t:s0 tclass=packet
> 
> so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
> 
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log

Might be related to this:
http://marc.info/?l=git-commits-head&m=118271540932264&w=2

-- 
Stephen Smalley
National Security Agency

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Willy Tarreau]

On Wed, Aug 22, 2007 at 03:15:14PM -0400, Stephen Smalley wrote:
> On Wed, 2007-08-22 at 19:50 +0200, Michal Piotrowski wrote:
> > On 22/08/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > On 22/08/07, James Morris <jmorris@namei.org> wrote:
> > [snip]
> > > > The previous problem is theoretically unrelated.  It arose via a separate
> > > > mechanism which can't be used at the same as the one you're seeing now in
> > > > the logs.
> > > >
> > > > So this either looks like a problem which has gone unnoticed and was
> > > > inadvertently fixed at some point, or is unique to the 2.6.20 stable
> > > > series.
> > >
> > > Yup, it is very interesting why no one noticed it. Binary search in progress:
> > > good - 2.6.20.4
> > > bad - 2.6.20.8
> > 
> > Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
> > http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
> > any suggestions?
> > 
> > I also have seen this avc on 2.6.20.6 during reboot
> > 
> > [ 2333.905944] audit(1187803699.273:271): avc:  denied  { send } for
> > saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0
> > scontext=user_u:system_r:unconfined_t:s0
> > tcontext=system_u:system_r:kernel_t:s0 tclass=packet
> > [ 2334.420598] audit(1187803699.789:272): avc:  denied  { send } for
> > saddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0
> > scontext=user_u:system_r:unconfined_t:s0
> > tcontext=system_u:system_r:kernel_t:s0 tclass=packet
> > 
> > so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
> > 
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
> 
> Might be related to this:
> http://marc.info/?l=git-commits-head&m=118271540932264&w=2

Interesting, this one was fixed in 2.6.22-rc6, but is neither in 2.6.20
nor in 2.6.21. Michal, could you please try to apply the patch ? I include
it here for your convenience. If it fixes your problem, I can queue it for
next 2.6.20-stable, and forward it to the -stable team for 2.6.21 in case
Greg and Chris plan to release another one.


From: Patrick McHardy <kaber@trash.net>
Date: Sun, 24 Jun 2007 05:58:34 +0000 (-0700)
Subject: [SKBUFF]: Fix incorrect config #ifdef around skb_copy_secmark
X-Git-Tag: v2.6.22~103^2~6
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=dbbeb2f9917792b989b6269ebfe24257f9aa1618

[SKBUFF]: Fix incorrect config #ifdef around skb_copy_secmark

secmark doesn't depend on CONFIG_NET_SCHED.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
---

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7c6a34e..8d43ae6 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -434,8 +434,8 @@ struct sk_buff *skb_clone(struct sk_buff *skb, gfp_t gfp_mask)
 	n->tc_verd = CLR_TC_MUNGED(n->tc_verd);
 	C(iif);
 #endif
-	skb_copy_secmark(n, skb);
 #endif
+	skb_copy_secmark(n, skb);
 	C(truesize);
 	atomic_set(&n->users, 1);
 	C(head);

Thanks,
Willy

Re: [stable] [2.6.20.17 review 32/58] fs: 9p/conv.c error path fix

[Willy Tarreau]

Hi Greg,

On Wed, Aug 22, 2007 at 11:59:41AM -0700, Greg KH wrote:
> On Wed, Aug 22, 2007 at 10:53:02AM -0500, Eric Van Hensbergen wrote:
> > On 8/22/07, Willy Tarreau <w@1wt.eu> wrote:
> > > When buf_check_overflow() returns != 0 we will hit kfree(ERR_PTR(err))
> > > and it will not be happy about it.
> > >
> > > Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
> > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > Acked-by: Eric Van Hensbergen <ericvh@gmail.com>
> > 
> > This seems to be in the current code as well, I'll forward-port the patch...
> 
> Huh?  It's not already in mainline?  Then how did it ever get into the
> stable queue?
> 
> Ugh.

Maybe someone sent it to stable@ and lkml at the same time and it got lost
on the second (noisy) path ? Judging from the patch, it got merged about
one month ago :

willy@pcw:2.6$ git log v2.6.20..2.6.22.x -- fs/9p/conv.c|cat
commit b3b590287ca3c36e0a3fa28d626f126dd5226fc4
Author: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Date:   Thu Jul 19 17:27:22 2007 -0700

    fs: 9p/conv.c error path fix
    
    When buf_check_overflow() returns != 0 we will hit kfree(ERR_PTR(err))
    and it will not be happy about it.
    
    Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

willy@pcw:2.6$ git describe  b3b590287ca3c36e0a3fa28d626f126dd5226fc4
v2.6.22.1-53-gb3b5902

But yes, I agree that it's very annoying when -stable contains patches
that are not in mainline. Fortunately, we have careful reviewers to
catch this when it happens !

Regards,
Willy

Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy

[Willy Tarreau]

On Wed, Aug 22, 2007 at 08:15:03PM +0200, Prakash Punnoor wrote:
> Hi,
> 
> even if Greg is waiting for some special invitation 
> (http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by Ayaz on 
> top:
> 
> http://lkml.org/lkml/2007/8/10/296

That's what I prepare first, but then noticed it's not in mainline.

> Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:

He should, as the fix is not in mainline either :-(
I don't think Greg asks for specific clarification, just a plain patch
with a short commit log on its own which does not include remains of
older mails.

I'm holding up the patch until I get confirmation that it is *at least*
queued for mainline, otherwise it will definitely be missing from
mainline.

Thanks Prakash for the pointers above.
Willy

Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy

[Greg KH]

On Wed, Aug 22, 2007 at 10:42:25PM +0200, Willy Tarreau wrote:
> On Wed, Aug 22, 2007 at 08:15:03PM +0200, Prakash Punnoor wrote:
> > Hi,
> > 
> > even if Greg is waiting for some special invitation 
> > (http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by Ayaz on 
> > top:
> > 
> > http://lkml.org/lkml/2007/8/10/296
> 
> That's what I prepare first, but then noticed it's not in mainline.
> 
> > Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:
> 
> He should, as the fix is not in mainline either :-(
> I don't think Greg asks for specific clarification, just a plain patch
> with a short commit log on its own which does not include remains of
> older mails.

Exactly, that is what I am waiting for.

And also I need the change to go into mainline first, as we can not
diverge with the -stable releases.

thanks,

greg k-h

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Michal Piotrowski]

Willy Tarreau pisze:
> On Wed, Aug 22, 2007 at 03:15:14PM -0400, Stephen Smalley wrote:
>> On Wed, 2007-08-22 at 19:50 +0200, Michal Piotrowski wrote:
>>> On 22/08/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
>>>> On 22/08/07, James Morris <jmorris@namei.org> wrote:
>>> [snip]
>>>>> The previous problem is theoretically unrelated.  It arose via a separate
>>>>> mechanism which can't be used at the same as the one you're seeing now in
>>>>> the logs.
>>>>>
>>>>> So this either looks like a problem which has gone unnoticed and was
>>>>> inadvertently fixed at some point, or is unique to the 2.6.20 stable
>>>>> series.
>>>> Yup, it is very interesting why no one noticed it. Binary search in progress:
>>>> good - 2.6.20.4
>>>> bad - 2.6.20.8
>>> Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
>>> http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
>>> any suggestions?
>>>
>>> I also have seen this avc on 2.6.20.6 during reboot
>>>
>>> [ 2333.905944] audit(1187803699.273:271): avc:  denied  { send } for
>>> saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0
>>> scontext=user_u:system_r:unconfined_t:s0
>>> tcontext=system_u:system_r:kernel_t:s0 tclass=packet
>>> [ 2334.420598] audit(1187803699.789:272): avc:  denied  { send } for
>>> saddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0
>>> scontext=user_u:system_r:unconfined_t:s0
>>> tcontext=system_u:system_r:kernel_t:s0 tclass=packet
>>>
>>> so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
>>>
>>> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
>> Might be related to this:
>> http://marc.info/?l=git-commits-head&m=118271540932264&w=2
> 
> Interesting, this one was fixed in 2.6.22-rc6, but is neither in 2.6.20
> nor in 2.6.21. Michal, could you please try to apply the patch ? I include
> it here for your convenience. If it fixes your problem, I can queue it for
> next 2.6.20-stable, and forward it to the -stable team for 2.6.21 in case
> Greg and Chris plan to release another one.
> 

I confirm that this patch fixes the problem.

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [2.6.20.17 review 00/58] 2.6.20.17 -stable review

[Willy Tarreau]

On Thu, Aug 23, 2007 at 01:13:56PM +0200, Michal Piotrowski wrote:
> Willy Tarreau pisze:
> > On Wed, Aug 22, 2007 at 03:15:14PM -0400, Stephen Smalley wrote:
> >> On Wed, 2007-08-22 at 19:50 +0200, Michal Piotrowski wrote:
> >>> On 22/08/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> >>>> On 22/08/07, James Morris <jmorris@namei.org> wrote:
> >>> [snip]
> >>>>> The previous problem is theoretically unrelated.  It arose via a separate
> >>>>> mechanism which can't be used at the same as the one you're seeing now in
> >>>>> the logs.
> >>>>>
> >>>>> So this either looks like a problem which has gone unnoticed and was
> >>>>> inadvertently fixed at some point, or is unique to the 2.6.20 stable
> >>>>> series.
> >>>> Yup, it is very interesting why no one noticed it. Binary search in progress:
> >>>> good - 2.6.20.4
> >>>> bad - 2.6.20.8
> >>> Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
> >>> http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
> >>> any suggestions?
> >>>
> >>> I also have seen this avc on 2.6.20.6 during reboot
> >>>
> >>> [ 2333.905944] audit(1187803699.273:271): avc:  denied  { send } for
> >>> saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0
> >>> scontext=user_u:system_r:unconfined_t:s0
> >>> tcontext=system_u:system_r:kernel_t:s0 tclass=packet
> >>> [ 2334.420598] audit(1187803699.789:272): avc:  denied  { send } for
> >>> saddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0
> >>> scontext=user_u:system_r:unconfined_t:s0
> >>> tcontext=system_u:system_r:kernel_t:s0 tclass=packet
> >>>
> >>> so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
> >>>
> >>> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
> >> Might be related to this:
> >> http://marc.info/?l=git-commits-head&m=118271540932264&w=2
> > 
> > Interesting, this one was fixed in 2.6.22-rc6, but is neither in 2.6.20
> > nor in 2.6.21. Michal, could you please try to apply the patch ? I include
> > it here for your convenience. If it fixes your problem, I can queue it for
> > next 2.6.20-stable, and forward it to the -stable team for 2.6.21 in case
> > Greg and Chris plan to release another one.
> > 
> 
> I confirm that this patch fixes the problem.

Perfect, thanks for your fast feedback, it is really appreciated !
I'm queuing it for 2.6.20.18.

Regards,
Willy

Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy

[Prakash Punnoor]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

On the day of Thursday 23 August 2007 Greg KH hast written:
> On Wed, Aug 22, 2007 at 10:42:25PM +0200, Willy Tarreau wrote:
> > On Wed, Aug 22, 2007 at 08:15:03PM +0200, Prakash Punnoor wrote:
> > > Hi,
> > >
> > > even if Greg is waiting for some special invitation
> > > (http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by
> > > Ayaz on top:
> > >
> > > http://lkml.org/lkml/2007/8/10/296
> >
> > That's what I prepare first, but then noticed it's not in mainline.
> >
> > > Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:
> >
> > He should, as the fix is not in mainline either :-(
> > I don't think Greg asks for specific clarification, just a plain patch
> > with a short commit log on its own which does not include remains of
> > older mails.
>
> Exactly, that is what I am waiting for.
>
> And also I need the change to go into mainline first, as we can not
> diverge with the -stable releases.

Can we get that into mainline then? I haven't seen forcedeth in MAINTAINERS, 
so I added netdev to the cc list.

bye,
-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [stable] [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy

[Greg KH]

On Thu, Aug 23, 2007 at 05:50:41PM +0200, Prakash Punnoor wrote:
> On the day of Thursday 23 August 2007 Greg KH hast written:
> > On Wed, Aug 22, 2007 at 10:42:25PM +0200, Willy Tarreau wrote:
> > > On Wed, Aug 22, 2007 at 08:15:03PM +0200, Prakash Punnoor wrote:
> > > > Hi,
> > > >
> > > > even if Greg is waiting for some special invitation
> > > > (http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by
> > > > Ayaz on top:
> > > >
> > > > http://lkml.org/lkml/2007/8/10/296
> > >
> > > That's what I prepare first, but then noticed it's not in mainline.
> > >
> > > > Perhaps Ayaz wants to give Greg the clarification he needs... :sigh:
> > >
> > > He should, as the fix is not in mainline either :-(
> > > I don't think Greg asks for specific clarification, just a plain patch
> > > with a short commit log on its own which does not include remains of
> > > older mails.
> >
> > Exactly, that is what I am waiting for.
> >
> > And also I need the change to go into mainline first, as we can not
> > diverge with the -stable releases.
> 
> Can we get that into mainline then? I haven't seen forcedeth in MAINTAINERS, 
> so I added netdev to the cc list.

It might help if someone sends a real patch that can be applied :)

thanks,

greg k-h

[PATCH] fix realtek phy id in forcedeth

[Willy Tarreau]

Hi Greg,

On Thu, Aug 23, 2007 at 09:55:13AM -0700, Greg KH wrote:
> It might help if someone sends a real patch that can be applied :)

This is getting really silly now :-) We're all wasting more time
wondering who will send the patch than posting it. I've lost, I got
fed up first, so here it is. Please apply to mainline then stable.

Thanks,
Willy

--

>From a0e2922b99eedd9863232368ea2afe072c52783e Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w@1wt.eu>
Date: Thu, 23 Aug 2007 21:35:41 +0200
Subject: [PATCH] fix realtek phy id in forcedeth

As noticed by Chuck Ebbert, commit c5e3ae8823693b260ce1f217adca8add1bc0b3de
introduced a copy-paste typo, as realtek phy is 0x732 and not 0x1c1. Obvious
fix below suggested by Ayaz Abdulla.

Signed-off-by: Willy Tarreau <w@1wt.eu>
Cc: Ayaz Abdulla <aabdulla@nvidia.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
---
 drivers/net/forcedeth.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 10f4e3b..1938d6d 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -552,7 +552,7 @@ union ring_type {
 #define PHY_OUI_MARVELL	0x5043
 #define PHY_OUI_CICADA	0x03f1
 #define PHY_OUI_VITESSE	0x01c1
-#define PHY_OUI_REALTEK	0x01c1
+#define PHY_OUI_REALTEK	0x0732
 #define PHYID1_OUI_MASK	0x03ff
 #define PHYID1_OUI_SHFT	6
 #define PHYID2_OUI_MASK	0xfc00
-- 
1.5.2.5

Re: [PATCH] fix realtek phy id in forcedeth

[Jeff Garzik]

Willy Tarreau wrote:
> Hi Greg,
> 
> On Thu, Aug 23, 2007 at 09:55:13AM -0700, Greg KH wrote:
>> It might help if someone sends a real patch that can be applied :)
> 
> This is getting really silly now :-) We're all wasting more time
> wondering who will send the patch than posting it. I've lost, I got
> fed up first, so here it is. Please apply to mainline then stable.
> 
> Thanks,
> Willy
> 
> --
> 
>>From a0e2922b99eedd9863232368ea2afe072c52783e Mon Sep 17 00:00:00 2001
> From: Willy Tarreau <w@1wt.eu>
> Date: Thu, 23 Aug 2007 21:35:41 +0200
> Subject: [PATCH] fix realtek phy id in forcedeth
> 
> As noticed by Chuck Ebbert, commit c5e3ae8823693b260ce1f217adca8add1bc0b3de
> introduced a copy-paste typo, as realtek phy is 0x732 and not 0x1c1. Obvious
> fix below suggested by Ayaz Abdulla.
> 
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> Cc: Ayaz Abdulla <aabdulla@nvidia.com>
> Cc: Chuck Ebbert <cebbert@redhat.com>
> ---
>  drivers/net/forcedeth.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

applied