Skip to contentSkip to conversation

2.6.20-stable review

PATCH In review Greg KH 9 participants 48 messages Mar 19, 2007 – Mar 25, 2007

Subsystems (23)
lore
Share & tools
lore

Greg KH

author
#0 lore raw

cover 2.6.20-stable review

This is the start of the stable review cycle for the 2.6.20.4 release. There are 31 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.

Responses should be made by Thursday March, 22, 15:00:00 UTC. Anything received after that time might be too late.

thanks,

the -stable release team

author
#1 lore raw

PATCH 1/31 Fix another NULL pointer deref in ipv6_sockglue.c

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Olaf Kirch <[email protected]>

[IPV6]: Fix for ipv6_setsockopt NULL dereference

I came across this bug in http://bugzilla.kernel.org/show_bug.cgi?id=8155

---
 net/ipv6/ipv6_sockglue.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv6/ipv6_sockglue.c +1 -1
@@ -414,7 +414,7 @@ static int do_ipv6_setsockopt(struct soc
 		}
 
 		/* routing header option needs extra check */
-		if (optname == IPV6_RTHDR && opt->srcrt) {
+		if (optname == IPV6_RTHDR && opt && opt->srcrt) {
 			struct ipv6_rt_hdr *rthdr = opt->srcrt;
 			switch (rthdr->type) {
 			case IPV6_SRCRT_TYPE_0:
author
#2 lore raw

PATCH 2/31 Fix rtm_to_ifaddr() error return.

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Evgeniy Polyakov <[email protected]>

[IPV4]: Fix rtm_to_ifaddr() error handling.

Return negative error value (embedded in the pointer) instead of returning NULL.

---
 net/ipv4/devinet.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
net/ipv4/devinet.c +3 -1
@@ -503,8 +503,10 @@ static struct in_ifaddr *rtm_to_ifaddr(s
 		goto errout;
 
 	ifm = nlmsg_data(nlh);
-	if (ifm->ifa_prefixlen > 32 || tb[IFA_LOCAL] == NULL)
+	if (ifm->ifa_prefixlen > 32 || tb[IFA_LOCAL] == NULL) {
+		err = -EINVAL;
 		goto errout;
+	}
 
 	dev = __dev_get_by_index(ifm->ifa_index);
 	if (dev == NULL) {
author
#3 lore raw

PATCH 3/31 Fix user copy length in ipv6_sockglue.c

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Chris Wright <[email protected]>

[IPV6] fix ipv6_getsockopt_sticky copy_to_user leak

User supplied len < 0 can cause leak of kernel memory. Use unsigned compare instead.

---
 net/ipv6/ipv6_sockglue.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv6/ipv6_sockglue.c +1 -1
@@ -805,7 +805,7 @@ static int ipv6_getsockopt_sticky(struct
 		return 0;
 	hdr = opt->hopopt;
 
-	len = min_t(int, len, ipv6_optlen(hdr));
+	len = min_t(unsigned int, len, ipv6_optlen(hdr));
 	if (copy_to_user(optval, hdr, ipv6_optlen(hdr)))
 		return -EFAULT;
 	return len;
#4 lore raw

Re: [patch 03/31] Fix user copy length in ipv6_sockglue.c

Quoted 6 lines · * Greg KH ([email protected]) wrote:

From: Chris Wright <[email protected]>

[IPV6] fix ipv6_getsockopt_sticky copy_to_user leak

User supplied len < 0 can cause leak of kernel memory. Use unsigned compare instead.

You can drop this one. It's dependent on a patch
that is not in 2.6.20.

thanks,
-chris

maintainer
#5 lore raw

Re: [patch 03/31] Fix user copy length in ipv6_sockglue.c

From: Chris Wright <[email protected]>
Date: Mon, 19 Mar 2007 15:01:25 -0700

Quoted 10 lines · * Greg KH ([email protected]) wrote:
Quoted 6 lines

From: Chris Wright <[email protected]>

[IPV6] fix ipv6_getsockopt_sticky copy_to_user leak

User supplied len < 0 can cause leak of kernel memory. Use unsigned compare instead.

You can drop this one. It's dependent on a patch
that is not in 2.6.20.

That's correct, it can be dropped.

#6 lore raw

Re: [patch 03/31] Fix user copy length in ipv6_sockglue.c

In reply to Chris Wright
Quoted 10 lines · Chris Wright
Quoted 6 lines · * Greg KH ([email protected]) wrote:

From: Chris Wright <[email protected]>

[IPV6] fix ipv6_getsockopt_sticky copy_to_user leak

User supplied len < 0 can cause leak of kernel memory. Use unsigned compare instead.

You can drop this one. It's dependent on a patch
that is not in 2.6.20.

Ok, thanks for letting me know, it is now dropped.

greg k-h

author
#7 lore raw

PATCH 4/31 gdth: fix oops in gdth_copy_cmd()

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

Recent alterations to the gdth_fill_raw_cmd() path no longer set the sg_ranz field for zero transfer commands. However, this field is used lower down in the function to initialise ha->cmd_len to the size of the firmware packet. If this uninitialised field contains a bogus value, ha->cmd_len can become much larger than the actual firmware packet and end up oopsing in gdth_copy_cmd() as it tries to copy this huge packet to the device (usually because it runs into an unallocated page).

The fix is to initialise the sg_ranz field to zero at the start of gdth_fill_raw_cmd().

---
 drivers/scsi/gdth.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/scsi/gdth.c +2 -0
@@ -3092,6 +3092,7 @@ static int gdth_fill_raw_cmd(int hanum,S
             cmdp->u.raw64.direction  = 
                 gdth_direction_tab[scp->cmnd[0]]==DOU ? GDTH_DATA_OUT:GDTH_DATA_IN;
             memcpy(cmdp->u.raw64.cmd,scp->cmnd,16);
+            cmdp->u.raw64.sg_ranz    = 0;
         } else {
             cmdp->u.raw.reserved   = 0;
             cmdp->u.raw.mdisc_time = 0;
@@ -3108,6 +3109,7 @@ static int gdth_fill_raw_cmd(int hanum,S
             cmdp->u.raw.direction  = 
                 gdth_direction_tab[scp->cmnd[0]]==DOU ? GDTH_DATA_OUT:GDTH_DATA_IN;
             memcpy(cmdp->u.raw.cmd,scp->cmnd,12);
+            cmdp->u.raw.sg_ranz    = 0;
         }
 
         if (scp->use_sg) {
author
#8 lore raw

PATCH 5/31 NetLabel: Verify sensitivity level has a valid CIPSO mapping

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

The current CIPSO engine has a problem where it does not verify that the given sensitivity level has a valid CIPSO mapping when the "std" CIPSO DOI type is used. The end result is that bad packets are sent on the wire which should have never been sent in the first place. This patch corrects this problem by verifying the sensitivity level mapping similar to what is done with the category mapping. This patch also changes the returned error code in this case to -EPERM to better match what the category mapping verification code returns.

---
 net/ipv4/cipso_ipv4.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
net/ipv4/cipso_ipv4.c +4 -3
@@ -732,11 +732,12 @@ static int cipso_v4_map_lvl_hton(const s
 		*net_lvl = host_lvl;
 		return 0;
 	case CIPSO_V4_MAP_STD:
-		if (host_lvl < doi_def->map.std->lvl.local_size) {
+		if (host_lvl < doi_def->map.std->lvl.local_size &&
+		    doi_def->map.std->lvl.local[host_lvl] < CIPSO_V4_INV_LVL) {
 			*net_lvl = doi_def->map.std->lvl.local[host_lvl];
 			return 0;
 		}
-		break;
+		return -EPERM;
 	}
 
 	return -EINVAL;
@@ -771,7 +772,7 @@ static int cipso_v4_map_lvl_ntoh(const s
 			*host_lvl = doi_def->map.std->lvl.cipso[net_lvl];
 			return 0;
 		}
-		break;
+		return -EPERM;
 	}
 
 	return -EINVAL;
author
#9 lore raw

PATCH 6/31 NETFILTER: nfnetlink_log: fix reference counting

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Michal Miroslaw <[email protected]>

[NETFILTER]: nfnetlink_log: fix reference counting

Fix reference counting (memory leak) problem in __nfulnl_send() and callers related to packet queueing.

---
 net/netfilter/nfnetlink_log.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)
net/netfilter/nfnetlink_log.c +2 -6
@@ -218,10 +218,8 @@ _instance_destroy2(struct nfulnl_instanc
 	spin_lock_bh(&inst->lock);
 	if (inst->skb) {
 		/* timer "holds" one reference (we have one more) */
-		if (timer_pending(&inst->timer)) {
-			del_timer(&inst->timer);
+		if (del_timer(&inst->timer))
 			instance_put(inst);
-		}
 		if (inst->qlen)
 			__nfulnl_send(inst);
 		if (inst->skb) {
@@ -695,10 +693,8 @@ nfulnl_log_packet(unsigned int pf,
 		UDEBUG("flushing old skb\n");
 
 		/* timer "holds" one reference (we have another one) */
-		if (timer_pending(&inst->timer)) {
-			del_timer(&inst->timer);
+		if (del_timer(&inst->timer))
 			instance_put(inst);
-		}
 		__nfulnl_send(inst);
 
 		if (!(inst->skb = nfulnl_alloc_skb(nlbufsiz, size))) {
author
#10 lore raw

PATCH 7/31 IA64: fix NULL pointer in ia64/irq_chip-mask/unmask function

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: KAMEZAWA Hiroyuki <[email protected]>

[IA64] fix NULL pointer in ia64/irq_chip-mask/unmask function

This patch fixes boot failure because irq_desc->mask() is NULL.

- Added mask/unmask functions to ia64's irq desc function table.
- rename hw_interrupt_type to irq_chip. hw_interrupt_type is old name.
- Tony: Added same change to arch/ia64/sn/kernel/irq.c as pointed out by Eric Biederman ... mask/unmask functions there can be no-op.

---
 arch/ia64/kernel/iosapic.c |    8 ++++++--
 arch/ia64/sn/kernel/irq.c  |   14 +++++++++++++-
 2 files changed, 19 insertions(+), 3 deletions(-)
arch/ia64/kernel/iosapic.c +6 -2
@@ -446,7 +446,7 @@ iosapic_end_level_irq (unsigned int irq)
 #define iosapic_disable_level_irq	mask_irq
 #define iosapic_ack_level_irq		nop
 
-struct hw_interrupt_type irq_type_iosapic_level = {
+struct irq_chip irq_type_iosapic_level = {
 	.name =		"IO-SAPIC-level",
 	.startup =	iosapic_startup_level_irq,
 	.shutdown =	iosapic_shutdown_level_irq,
@@ -454,6 +454,8 @@ struct hw_interrupt_type irq_type_iosapi
 	.disable =	iosapic_disable_level_irq,
 	.ack =		iosapic_ack_level_irq,
 	.end =		iosapic_end_level_irq,
+	.mask =		mask_irq,
+	.unmask =	unmask_irq,
 	.set_affinity =	iosapic_set_affinity
 };
 
@@ -493,7 +495,7 @@ iosapic_ack_edge_irq (unsigned int irq)
 #define iosapic_disable_edge_irq	nop
 #define iosapic_end_edge_irq		nop
 
-struct hw_interrupt_type irq_type_iosapic_edge = {
+struct irq_chip irq_type_iosapic_edge = {
 	.name =		"IO-SAPIC-edge",
 	.startup =	iosapic_startup_edge_irq,
 	.shutdown =	iosapic_disable_edge_irq,
@@ -501,6 +503,8 @@ struct hw_interrupt_type irq_type_iosapi
 	.disable =	iosapic_disable_edge_irq,
 	.ack =		iosapic_ack_edge_irq,
 	.end =		iosapic_end_edge_irq,
+	.mask =		mask_irq,
+	.unmask =	unmask_irq,
 	.set_affinity =	iosapic_set_affinity
 };
 
arch/ia64/sn/kernel/irq.c +13 -1
@@ -205,7 +205,17 @@ static void sn_set_affinity_irq(unsigned
 		(void)sn_retarget_vector(sn_irq_info, nasid, slice);
 }
 
-struct hw_interrupt_type irq_type_sn = {
+static void
+sn_mask_irq(unsigned int irq)
+{
+}
+
+static void
+sn_unmask_irq(unsigned int irq)
+{
+}
+
+struct irq_chip irq_type_sn = {
 	.name		= "SN hub",
 	.startup	= sn_startup_irq,
 	.shutdown	= sn_shutdown_irq,
@@ -213,6 +223,8 @@ struct hw_interrupt_type irq_type_sn = {
 	.disable	= sn_disable_irq,
 	.ack		= sn_ack_irq,
 	.end		= sn_end_irq,
+	.mask		= sn_mask_irq,
+	.unmask		= sn_unmask_irq,
 	.set_affinity	= sn_set_affinity_irq
 };
 
author
#11 lore raw

PATCH 8/31 adjust legacy IDE resource setting (v2)

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Jan Beulich <[email protected]>

adjust legacy IDE resource setting (v2)

The change to force legacy mode IDE channels' resources to fixed non-zero values confuses (at least some versions of) X, because the values reported by the kernel and those readable from PCI config space aren't consistent anymore. Therefore, this patch arranges for the respective BARs to also get updated if possible.

---
 drivers/pci/probe.c |   45 ++++++++++++++++++++++++++++++++-------------
 1 file changed, 32 insertions(+), 13 deletions(-)
drivers/pci/probe.c +32 -13
@@ -639,7 +639,34 @@ static void pci_read_irq(struct pci_dev 
 	dev->irq = irq;
 }
 
-#define LEGACY_IO_RESOURCE	(IORESOURCE_IO | IORESOURCE_PCI_FIXED)
+static void change_legacy_io_resource(struct pci_dev * dev, unsigned index,
+                                      unsigned start, unsigned end)
+{
+	unsigned base = start & PCI_BASE_ADDRESS_IO_MASK;
+	unsigned len = (end | ~PCI_BASE_ADDRESS_IO_MASK) - base + 1;
+
+	/*
+	 * Some X versions get confused when the BARs reported through
+	 * /sys or /proc differ from those seen in config space, thus
+	 * try to update the config space values, too.
+	 */
+	if (!(pci_resource_flags(dev, index) & IORESOURCE_IO))
+		printk(KERN_WARNING "%s: cannot adjust BAR%u (not I/O)\n",
+		       pci_name(dev), index);
+	else if (pci_resource_len(dev, index) != len)
+		printk(KERN_WARNING "%s: cannot adjust BAR%u (size %04X)\n",
+		       pci_name(dev), index, (unsigned)pci_resource_len(dev, index));
+	else {
+		printk(KERN_INFO "%s: trying to change BAR%u from %04X to %04X\n",
+		       pci_name(dev), index,
+		       (unsigned)pci_resource_start(dev, index), base);
+		pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + index * 4, base);
+	}
+	pci_resource_start(dev, index) = start;
+	pci_resource_end(dev, index)   = end;
+	pci_resource_flags(dev, index) =
+		IORESOURCE_IO | IORESOURCE_PCI_FIXED | PCI_BASE_ADDRESS_SPACE_IO;
+}
 
 /**
  * pci_setup_device - fill in class and map information of a device
@@ -692,20 +719,12 @@ static int pci_setup_device(struct pci_d
 			u8 progif;
 			pci_read_config_byte(dev, PCI_CLASS_PROG, &progif);
 			if ((progif & 1) == 0) {
-				dev->resource[0].start = 0x1F0;
-				dev->resource[0].end = 0x1F7;
-				dev->resource[0].flags = LEGACY_IO_RESOURCE;
-				dev->resource[1].start = 0x3F6;
-				dev->resource[1].end = 0x3F6;
-				dev->resource[1].flags = LEGACY_IO_RESOURCE;
+				change_legacy_io_resource(dev, 0, 0x1F0, 0x1F7);
+				change_legacy_io_resource(dev, 1, 0x3F6, 0x3F6);
 			}
 			if ((progif & 4) == 0) {
-				dev->resource[2].start = 0x170;
-				dev->resource[2].end = 0x177;
-				dev->resource[2].flags = LEGACY_IO_RESOURCE;
-				dev->resource[3].start = 0x376;
-				dev->resource[3].end = 0x376;
-				dev->resource[3].flags = LEGACY_IO_RESOURCE;
+				change_legacy_io_resource(dev, 2, 0x170, 0x177);
+				change_legacy_io_resource(dev, 3, 0x376, 0x376);
 			}
 		}
 		break;
author
#12 lore raw

PATCH 9/31 mm: fix madvise infinine loop

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Nick Piggin <[email protected]>

madvise(MADV_REMOVE) can go into an infinite loop or cause an oops if the call covers a region from the start of a vma, and extending past that vma.

---
 mm/madvise.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
mm/madvise.c +4 -1
@@ -155,11 +155,14 @@ static long madvise_dontneed(struct vm_a
  * Other filesystems return -ENOSYS.
  */
 static long madvise_remove(struct vm_area_struct *vma,
+				struct vm_area_struct **prev,
 				unsigned long start, unsigned long end)
 {
 	struct address_space *mapping;
         loff_t offset, endoff;
 
+	*prev = vma;
+
 	if (vma->vm_flags & (VM_LOCKED|VM_NONLINEAR|VM_HUGETLB))
 		return -EINVAL;
 
@@ -199,7 +202,7 @@ madvise_vma(struct vm_area_struct *vma, 
 		error = madvise_behavior(vma, prev, start, end, behavior);
 		break;
 	case MADV_REMOVE:
-		error = madvise_remove(vma, start, end);
+		error = madvise_remove(vma, prev, start, end);
 		break;
 
 	case MADV_WILLNEED:
author
#13 lore raw

PATCH 10/31 EHCI: add delay to bus_resume before accessing ports

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Alan Stern <[email protected]>

This patch (as870) adds a delay to ehci-hcd's bus_resume routine. Apparently there are controllers and/or BIOSes out there which need such a delay to get the ports back into their correct state. This fixes Bugzilla #8190.

---
 drivers/usb/host/ehci-hub.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/usb/host/ehci-hub.c +4 -0
@@ -134,6 +134,10 @@ static int ehci_bus_resume (struct usb_h
 	/* restore CMD_RUN, framelist size, and irq threshold */
 	writel (ehci->command, &ehci->regs->command);
 
+	/* Some controller/firmware combinations need a delay during which
+	 * they set up the port statuses.  See Bugzilla #8190. */
+	mdelay(8);
+
 	/* manually resume the ports we suspended during bus_suspend() */
 	i = HCS_N_PORTS (ehci->hcs_params);
 	while (i--) {
author
#14 lore raw

PATCH 11/31 initialise pi_lock if CONFIG_RT_MUTEXES=N

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Zilvinas Valinskas <[email protected]>

Fixes a bogus lockdep warning which causes lockdep to disable itself.

---
 kernel/fork.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/fork.c +1 -1
@@ -933,8 +933,8 @@ asmlinkage long sys_set_tid_address(int 
 
 static inline void rt_mutex_init_task(struct task_struct *p)
 {
-#ifdef CONFIG_RT_MUTEXES
 	spin_lock_init(&p->pi_lock);
+#ifdef CONFIG_RT_MUTEXES
 	plist_head_init(&p->pi_waiters, &p->pi_lock);
 	p->pi_blocked_on = NULL;
 #endif
author
#15 lore raw

PATCH 12/31 futex: PI state locking fix

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Ingo Molnar <[email protected]>

Testing of -rt by IBM uncovered a locking bug in wake_futex_pi(): the PI state needs to be locked before we access it.

---
 kernel/futex.c |    2 ++
 1 file changed, 2 insertions(+)
kernel/futex.c +2 -0
@@ -565,6 +565,7 @@ static int wake_futex_pi(u32 __user *uad
 	if (!pi_state)
 		return -EINVAL;
 
+	spin_lock(&pi_state->pi_mutex.wait_lock);
 	new_owner = rt_mutex_next_owner(&pi_state->pi_mutex);
 
 	/*
@@ -604,6 +605,7 @@ static int wake_futex_pi(u32 __user *uad
 	pi_state->owner = new_owner;
 	spin_unlock_irq(&new_owner->pi_lock);
 
+	spin_unlock(&pi_state->pi_mutex.wait_lock);
 	rt_mutex_unlock(&pi_state->pi_mutex);
 
 	return 0;
author
#16 lore raw

PATCH 13/31 nfs: nfs_getattr() cant call nfs_sync_mapping_range() for non-regular files

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Trond Myklebust <[email protected]>

Looks like we need a check in nfs_getattr() for a regular file. It makes no sense to call nfs_sync_mapping_range() on anything else. I think that should fix your problem: it will stop the NFS client from interfering with dirty pages on that inode's mapping.

---
 fs/nfs/inode.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
fs/nfs/inode.c +2 -1
@@ -422,7 +422,8 @@ int nfs_getattr(struct vfsmount *mnt, st
 	int err;
 
 	/* Flush out writes to the server in order to update c/mtime */
-	nfs_sync_mapping_range(inode->i_mapping, 0, 0, FLUSH_NOCOMMIT);
+	if (S_ISREG(inode->i_mode))
+		nfs_sync_mapping_range(inode->i_mapping, 0, 0, FLUSH_NOCOMMIT);
 
 	/*
 	 * We may force a getattr if the user cares about atime.
author
#17 lore raw

PATCH 14/31 hrtimer: prevent overrun DoS in hrtimer_forward()

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Thomas Gleixner <[email protected]>

hrtimer_forward() does not check for the possible overflow of timer->expires. This can happen on 64 bit machines with large interval values and results currently in an endless loop in the softirq because the expiry value becomes negative and therefor the timer is expired all the time.

Check for this condition and set the expiry value to the max. expiry time in the future. The fix should be applied to stable kernel series as well.

---
 kernel/hrtimer.c |    6 ++++++
 1 file changed, 6 insertions(+)
kernel/hrtimer.c +6 -0
@@ -332,6 +332,12 @@ hrtimer_forward(struct hrtimer *timer, k
 		orun++;
 	}
 	timer->expires = ktime_add(timer->expires, interval);
+	/*
+	 * Make sure, that the result did not wrap with a very large
+	 * interval.
+	 */
+	if (timer->expires.tv64 < 0)
+		timer->expires = ktime_set(KTIME_SEC_MAX, 0);
 
 	return orun;
 }
author
#18 lore raw

PATCH 15/31 fix MTIME_SEC_MAX on 32-bit

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Thomas Gleixner <[email protected]>

The maximum seconds value we can handle on 32bit is LONG_MAX.

---
 include/linux/ktime.h |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
include/linux/ktime.h +5 -1
@@ -57,7 +57,11 @@ typedef union {
 } ktime_t;
 
 #define KTIME_MAX			((s64)~((u64)1 << 63))
-#define KTIME_SEC_MAX			(KTIME_MAX / NSEC_PER_SEC)
+#if (BITS_PER_LONG == 64)
+# define KTIME_SEC_MAX			(KTIME_MAX / NSEC_PER_SEC)
+#else
+# define KTIME_SEC_MAX			LONG_MAX
+#endif
 
 /*
  * ktime_t definitions when using the 64-bit scalar representation:
author
#19 lore raw

PATCH 16/31 fix read past end of array in md/linear.c

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Andy Isaacson <[email protected]>

When iterating through an array, one must be careful to test one's index variable rather than another similarly-named variable.

The loop will read off the end of conf->disks[] in the following (pathological) case:

% dd bs=1 seek=840716287 if=/dev/zero of=d1 count=1
% for i in 2 3 4; do dd if=/dev/zero of=d$i bs=1k count=$(($i+150)); done % ./vmlinux ubd0=root ubd1=d1 ubd2=d2 ubd3=d3 ubd4=d4

# mdadm -C /dev/md0 --level=linear --raid-devices=4 /dev/ubd[1234]

adding some printks, I saw this:

[42949374.960000] hash_spacing = 821120
[42949374.960000] cnt          = 4
[42949374.960000] min_spacing  = 801
[42949374.960000] j=0 size=820928 sz=820928
[42949374.960000] i=0 sz=820928 hash_spacing=820928
[42949374.960000] j=1 size=64 sz=64
[42949374.960000] j=2 size=64 sz=128
[42949374.960000] j=3 size=64 sz=192
[42949374.960000] j=4 size=1515870810 sz=1515871002
---
 drivers/md/linear.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/linear.c +1 -1
@@ -188,7 +188,7 @@ static linear_conf_t *linear_conf(mddev_
 	for (i=0; i < cnt-1 ; i++) {
 		sector_t sz = 0;
 		int j;
-		for (j=i; i<cnt-1 && sz < min_spacing ; j++)
+		for (j = i; j < cnt - 1 && sz < min_spacing; j++)
 			sz += conf->disks[j].size;
 		if (sz >= min_spacing && sz < conf->hash_spacing)
 			conf->hash_spacing = sz;
author
#20 lore raw

PATCH 17/31 r8169: fix a race between PCI probe and dev_open

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

Initialize the timer with the rest of the private-struct.

---
 drivers/net/r8169.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/net/r8169.c +5 -5
@@ -1369,11 +1369,7 @@ static inline void rtl8169_request_timer
 	    (tp->phy_version >= RTL_GIGA_PHY_VER_H))
 		return;
 
-	init_timer(timer);
-	timer->expires = jiffies + RTL8169_PHY_TIMEOUT;
-	timer->data = (unsigned long)(dev);
-	timer->function = rtl8169_phy_timer;
-	add_timer(timer);
+	mod_timer(timer, jiffies + RTL8169_PHY_TIMEOUT);
 }
 
 #ifdef CONFIG_NET_POLL_CONTROLLER
@@ -1686,6 +1682,10 @@ rtl8169_init_one(struct pci_dev *pdev, c
 	tp->mmio_addr = ioaddr;
 	tp->align = rtl_cfg_info[ent->driver_data].align;
 
+	init_timer(&tp->timer);
+	tp->timer.data = (unsigned long) dev;
+	tp->timer.function = rtl8169_phy_timer;
+
 	spin_lock_init(&tp->lock);
 
 	rc = register_netdev(dev);
author
#21 lore raw

PATCH 18/31 Fix extraneous IPSEC larval SA creation

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Joy Latten <[email protected]>

[XFRM]: Fix missing protocol comparison of larval SAs.

I noticed that in xfrm_state_add we look for the larval SA in a few places without checking for protocol match. So when using both AH and ESP, whichever one gets added first, deletes the larval SA. It seems AH always gets added first and ESP is always the larval SA's protocol since the xfrm->tmpl has it first. Thus causing the additional km_query()

Adding the check eliminates accidental double SA creation.

---
 net/xfrm/xfrm_state.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
net/xfrm/xfrm_state.c +4 -2
@@ -707,7 +707,8 @@ static struct xfrm_state *__find_acq_cor
 		    x->props.mode   != mode ||
 		    x->props.family != family ||
 		    x->km.state     != XFRM_STATE_ACQ ||
-		    x->id.spi       != 0)
+		    x->id.spi       != 0 ||
+		    x->id.proto	    != proto)
 			continue;
 
 		switch (family) {
@@ -804,7 +805,8 @@ int xfrm_state_add(struct xfrm_state *x)
 
 	if (use_spi && x->km.seq) {
 		x1 = __xfrm_find_acq_byseq(x->km.seq);
-		if (x1 && xfrm_addr_cmp(&x1->id.daddr, &x->id.daddr, family)) {
+		if (x1 && ((x1->id.proto != x->id.proto) ||
+		    xfrm_addr_cmp(&x1->id.daddr, &x->id.daddr, family))) {
 			xfrm_state_put(x1);
 			x1 = NULL;
 		}
author
#22 lore raw

PATCH 19/31 : Fix GFP_KERNEL with preemption disabled in fib_trie

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Robert Olsson <[email protected]>

[IPV4]: Do not disable preemption in trie_leaf_remove().

Hello, Just discussed this Patrick...

We have two users of trie_leaf_remove, fn_trie_flush and fn_trie_delete both are holding RTNL. So there shouldn't be need for this preempt stuff. This is assumed to a leftover from an older RCU-take.

Quoted 7 lines

Mhh .. I think I just remembered something - me incorrectly suggesting to add it there while we were talking about this at OLS :) IIRC the idea was to make sure tnode_free (which at that time didn't use call_rcu) wouldn't free memory while still in use in a rcu read-side critical section. It should have been synchronize_rcu of course, but with tnode_free using call_rcu it seems to be completely unnecessary. So I guess we can simply remove it.

---
 net/ipv4/fib_trie.c |    2 --
 1 file changed, 2 deletions(-)
net/ipv4/fib_trie.c +0 -2
@@ -1528,7 +1528,6 @@ static int trie_leaf_remove(struct trie 
 	t->revision++;
 	t->size--;
 
-	preempt_disable();
 	tp = NODE_PARENT(n);
 	tnode_free((struct tnode *) n);
 
@@ -1538,7 +1537,6 @@ static int trie_leaf_remove(struct trie 
 		rcu_assign_pointer(t->trie, trie_rebalance(t, tp));
 	} else
 		rcu_assign_pointer(t->trie, NULL);
-	preempt_enable();
 
 	return 1;
 }
author
#23 lore raw

PATCH 20/31 Fix ipv6 flow label inheritance

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Masayuki Nakagawa <[email protected]>

[IPV6]: ipv6_fl_socklist is inadvertently shared.

The ipv6_fl_socklist from listening socket is inadvertently shared with new socket created for connection. This leads to a variety of interesting, but fatal, bugs. For example, removing one of the sockets may lead to the other socket's encountering a page fault when the now freed list is referenced.

The fix is to not share the flow label list with the new socket.

---
 net/ipv6/tcp_ipv6.c |    1 +
 1 file changed, 1 insertion(+)
net/ipv6/tcp_ipv6.c +1 -0
@@ -1453,6 +1453,7 @@ static struct sock * tcp_v6_syn_recv_soc
 	   First: no IPv4 options.
 	 */
 	newinet->opt = NULL;
+	newnp->ipv6_fl_list = NULL;
 
 	/* Clone RX bits */
 	newnp->rxopt.all = np->rxopt.all;
author
#24 lore raw

PATCH 21/31 Copy over mac_len when cloning an skb

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Alexey Dobriyan <[email protected]>

[NET]: Copy mac_len in skb_clone() as well

ANK says: "It is rarely used, that's wy it was not noticed. But in the places, where it is used, it should be disaster."

---
 net/core/skbuff.c |    1 +
 1 file changed, 1 insertion(+)
net/core/skbuff.c +1 -0
@@ -464,6 +464,7 @@ struct sk_buff *skb_clone(struct sk_buff
 	memcpy(n->cb, skb->cb, sizeof(skb->cb));
 	C(len);
 	C(data_len);
+	C(mac_len);
 	C(csum);
 	C(local_df);
 	n->cloned = 1;
author
#25 lore raw

PATCH 22/31 Fix sparc64 hugepage bugs

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: David Miller <[email protected]>

[SPARC64]: Add missing HPAGE_MASK masks on address parameters.

These pte loops all assume the passed in address is HPAGE aligned, make sure that is actually true.

---
 arch/sparc64/mm/hugetlbpage.c |    3 +++
 1 file changed, 3 insertions(+)
arch/sparc64/mm/hugetlbpage.c +3 -0
@@ -248,6 +248,7 @@ void set_huge_pte_at(struct mm_struct *m
 	if (!pte_present(*ptep) && pte_present(entry))
 		mm->context.huge_pte_count++;
 
+	addr &= HPAGE_MASK;
 	for (i = 0; i < (1 << HUGETLB_PAGE_ORDER); i++) {
 		set_pte_at(mm, addr, ptep, entry);
 		ptep++;
@@ -266,6 +267,8 @@ pte_t huge_ptep_get_and_clear(struct mm_
 	if (pte_present(entry))
 		mm->context.huge_pte_count--;
 
+	addr &= HPAGE_MASK;
+
 	for (i = 0; i < (1 << HUGETLB_PAGE_ORDER); i++) {
 		pte_clear(mm, addr, ptep);
 		addr += PAGE_SIZE;
author
#26 lore raw

PATCH 23/31 Fix page allocation debugging on sparc64

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: David Miller <[email protected]>

[SPARC64]: Get DEBUG_PAGEALLOC working again.

We have to make sure to use base-pagesize TLB entries even during the early transition period where we need TLB miss handling but don't have the kernel page tables setup yet for the linear region.

Also, it is necessary therefore to not use the 4MB TSB for these translations, and instead use the normal kernel TSB. This allows us to also get rid of the 4MB tsb for debug builds which shrinks the kernel a little bit.

---
 arch/sparc64/kernel/ktlb.S |    8 +++++++-
 arch/sparc64/mm/init.c     |   30 ++++++++++++++++++++++++++++--
 include/asm-sparc64/tsb.h  |    2 ++
 3 files changed, 37 insertions(+), 3 deletions(-)
arch/sparc64/kernel/ktlb.S +7 -1
@@ -138,9 +138,15 @@ kvmap_dtlb_4v:
 	brgez,pn	%g4, kvmap_dtlb_nonlinear
 	 nop
 
+#ifdef CONFIG_DEBUG_PAGEALLOC
+	/* Index through the base page size TSB even for linear
+	 * mappings when using page allocation debugging.
+	 */
+	KERN_TSB_LOOKUP_TL1(%g4, %g6, %g5, %g1, %g2, %g3, kvmap_dtlb_load)
+#else
 	/* Correct TAG_TARGET is already in %g6, check 4mb TSB.  */
 	KERN_TSB4M_LOOKUP_TL1(%g6, %g5, %g1, %g2, %g3, kvmap_dtlb_load)
-
+#endif
 	/* TSB entry address left in %g1, lookup linear PTE.
 	 * Must preserve %g1 and %g6 (TAG).
 	 */
arch/sparc64/mm/init.c +28 -2
@@ -59,8 +59,10 @@ unsigned long kern_linear_pte_xor[2] __r
  */
 unsigned long kpte_linear_bitmap[KPTE_BITMAP_BYTES / sizeof(unsigned long)];
 
+#ifndef CONFIG_DEBUG_PAGEALLOC
 /* A special kernel TSB for 4MB and 256MB linear mappings.  */
 struct tsb swapper_4m_tsb[KERNEL_TSB4M_NENTRIES];
+#endif
 
 #define MAX_BANKS	32
 
@@ -1301,7 +1303,12 @@ static void __init tsb_phys_patch(void)
 }
 
 /* Don't mark as init, we give this to the Hypervisor.  */
-static struct hv_tsb_descr ktsb_descr[2];
+#ifndef CONFIG_DEBUG_PAGEALLOC
+#define NUM_KTSB_DESCR	2
+#else
+#define NUM_KTSB_DESCR	1
+#endif
+static struct hv_tsb_descr ktsb_descr[NUM_KTSB_DESCR];
 extern struct tsb swapper_tsb[KERNEL_TSB_NENTRIES];
 
 static void __init sun4v_ktsb_init(void)
@@ -1340,6 +1347,7 @@ static void __init sun4v_ktsb_init(void)
 	ktsb_descr[0].tsb_base = ktsb_pa;
 	ktsb_descr[0].resv = 0;
 
+#ifndef CONFIG_DEBUG_PAGEALLOC
 	/* Second KTSB for 4MB/256MB mappings.  */
 	ktsb_pa = (kern_base +
 		   ((unsigned long)&swapper_4m_tsb[0] - KERNBASE));
@@ -1352,6 +1360,7 @@ static void __init sun4v_ktsb_init(void)
 	ktsb_descr[1].ctx_idx = 0;
 	ktsb_descr[1].tsb_base = ktsb_pa;
 	ktsb_descr[1].resv = 0;
+#endif
 }
 
 void __cpuinit sun4v_ktsb_register(void)
@@ -1364,7 +1373,7 @@ void __cpuinit sun4v_ktsb_register(void)
 	pa = kern_base + ((unsigned long)&ktsb_descr[0] - KERNBASE);
 
 	func = HV_FAST_MMU_TSB_CTX0;
-	arg0 = 2;
+	arg0 = NUM_KTSB_DESCR;
 	arg1 = pa;
 	__asm__ __volatile__("ta	%6"
 			     : "=&r" (func), "=&r" (arg0), "=&r" (arg1)
@@ -1393,7 +1402,9 @@ void __init paging_init(void)
 
 	/* Invalidate both kernel TSBs.  */
 	memset(swapper_tsb, 0x40, sizeof(swapper_tsb));
+#ifndef CONFIG_DEBUG_PAGEALLOC
 	memset(swapper_4m_tsb, 0x40, sizeof(swapper_4m_tsb));
+#endif
 
 	if (tlb_type == hypervisor)
 		sun4v_pgprot_init();
@@ -1725,8 +1736,13 @@ static void __init sun4u_pgprot_init(voi
 	pg_iobits = (_PAGE_VALID | _PAGE_PRESENT_4U | __DIRTY_BITS_4U |
 		     __ACCESS_BITS_4U | _PAGE_E_4U);
 
+#ifdef CONFIG_DEBUG_PAGEALLOC
+	kern_linear_pte_xor[0] = (_PAGE_VALID | _PAGE_SZBITS_4U) ^
+		0xfffff80000000000;
+#else
 	kern_linear_pte_xor[0] = (_PAGE_VALID | _PAGE_SZ4MB_4U) ^
 		0xfffff80000000000;
+#endif
 	kern_linear_pte_xor[0] |= (_PAGE_CP_4U | _PAGE_CV_4U |
 				   _PAGE_P_4U | _PAGE_W_4U);
 
@@ -1769,13 +1785,23 @@ static void __init sun4v_pgprot_init(voi
 	_PAGE_E = _PAGE_E_4V;
 	_PAGE_CACHE = _PAGE_CACHE_4V;
 
+#ifdef CONFIG_DEBUG_PAGEALLOC
+	kern_linear_pte_xor[0] = (_PAGE_VALID | _PAGE_SZBITS_4V) ^
+		0xfffff80000000000;
+#else
 	kern_linear_pte_xor[0] = (_PAGE_VALID | _PAGE_SZ4MB_4V) ^
 		0xfffff80000000000;
+#endif
 	kern_linear_pte_xor[0] |= (_PAGE_CP_4V | _PAGE_CV_4V |
 				   _PAGE_P_4V | _PAGE_W_4V);
 
+#ifdef CONFIG_DEBUG_PAGEALLOC
+	kern_linear_pte_xor[1] = (_PAGE_VALID | _PAGE_SZBITS_4V) ^
+		0xfffff80000000000;
+#else
 	kern_linear_pte_xor[1] = (_PAGE_VALID | _PAGE_SZ256MB_4V) ^
 		0xfffff80000000000;
+#endif
 	kern_linear_pte_xor[1] |= (_PAGE_CP_4V | _PAGE_CV_4V |
 				   _PAGE_P_4V | _PAGE_W_4V);
 
include/asm-sparc64/tsb.h +2 -0
@@ -264,6 +264,7 @@ extern struct tsb_phys_patch_entry __tsb
 	be,a,pt		%xcc, OK_LABEL; \
 	 mov		REG4, REG1;
 
+#ifndef CONFIG_DEBUG_PAGEALLOC
 	/* This version uses a trick, the TAG is already (VADDR >> 22) so
 	 * we can make use of that for the index computation.
 	 */
@@ -277,5 +278,6 @@ extern struct tsb_phys_patch_entry __tsb
 	cmp		REG3, TAG; \
 	be,a,pt		%xcc, OK_LABEL; \
 	 mov		REG4, REG1;
+#endif
 
 #endif /* !(_SPARC64_TSB_H) */
author
#27 lore raw

PATCH 24/31 IrDA: irttp_dup spin_lock initialisation

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Samuel Ortiz <[email protected]>

Without this initialization one gets

kernel BUG at kernel/rtmutex_common.h:80!

This patch should also be included in the -stable kernel.

---
 net/irda/irttp.c |    1 +
 1 file changed, 1 insertion(+)
net/irda/irttp.c +1 -0
@@ -1455,6 +1455,7 @@ struct tsap_cb *irttp_dup(struct tsap_cb
 
 	/* Not everything should be copied */
 	new->notify.instance = instance;
+	spin_lock_init(&new->lock);
 	init_timer(&new->todo_timer);
 
 	skb_queue_head_init(&new->rx_queue);
author
#28 lore raw

PATCH 25/31 Input: i8042 - really suppress ACK/NAK during panic blink

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Dmitry Torokhov <[email protected]>

Input: i8042 - really suppress ACK/NAK during panic blink

On some boxes panic blink procedure manages to send both bytes to keyboard contoller before getting first ACK so we need to make i8042_suppress_kbd_ack a counter instead of boolean.

---
 drivers/input/serio/i8042.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/input/serio/i8042.c +4 -3
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
 	if (unlikely(i8042_suppress_kbd_ack))
 		if (port_no == I8042_KBD_PORT_NO &&
 		    (data == 0xfa || data == 0xfe)) {
-			i8042_suppress_kbd_ack = 0;
+			i8042_suppress_kbd_ack--;
 			goto out;
 		}
 
@@ -838,13 +838,14 @@ static long i8042_panic_blink(long count
 	led ^= 0x01 | 0x04;
 	while (i8042_read_status() & I8042_STR_IBF)
 		DELAY;
-	i8042_suppress_kbd_ack = 1;
+	dbg("%02x -> i8042 (panic blink)", 0xed);
+	i8042_suppress_kbd_ack = 2;
 	i8042_write_data(0xed); /* set leds */
 	DELAY;
 	while (i8042_read_status() & I8042_STR_IBF)
 		DELAY;
 	DELAY;
-	i8042_suppress_kbd_ack = 1;
+	dbg("%02x -> i8042 (panic blink)", led);
 	i8042_write_data(led);
 	DELAY;
 	last_blink = count;
author
#29 lore raw

PATCH 26/31 hda-intel - Fix codec probe with ATI controllers

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Takashi Iwai <[email protected]>

[ALSA] hda-intel - Fix codec probe with ATI contorllers

ATI controllers may have up to 4 codecs while ICH up to 3. Thus the earlier fix to change AZX_MAX_CODECS to 3 cause a regression on some devices that have the audio codec at bit#3.
Now max codecs is defined according to the driver type, either 3 or 4. Currently 4 is set only to ATI chips. Other might need the same change, too.

---
 sound/pci/hda/hda_intel.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
sound/pci/hda/hda_intel.c +11 -2
@@ -199,7 +199,6 @@ enum { SDI0, SDI1, SDI2, SDI3, SDO0, SDO
 
 /* STATESTS int mask: SD2,SD1,SD0 */
 #define STATESTS_INT_MASK	0x07
-#define AZX_MAX_CODECS		3
 
 /* SD_CTL bits */
 #define SD_CTL_STREAM_RESET	0x01	/* stream reset bit */
@@ -966,6 +965,16 @@ static int azx_setup_controller(struct a
  * Codec initialization
  */
 
+static unsigned int azx_max_codecs[] __devinitdata = {
+	[AZX_DRIVER_ICH] = 3,
+	[AZX_DRIVER_ATI] = 4,
+	[AZX_DRIVER_ATIHDMI] = 4,
+	[AZX_DRIVER_VIA] = 3,		/* FIXME: correct? */
+	[AZX_DRIVER_SIS] = 3,		/* FIXME: correct? */
+	[AZX_DRIVER_ULI] = 3,		/* FIXME: correct? */
+	[AZX_DRIVER_NVIDIA] = 3,	/* FIXME: correct? */
+};
+
 static int __devinit azx_codec_create(struct azx *chip, const char *model)
 {
 	struct hda_bus_template bus_temp;
@@ -982,7 +991,7 @@ static int __devinit azx_codec_create(st
 		return err;
 
 	codecs = 0;
-	for (c = 0; c < AZX_MAX_CODECS; c++) {
+	for (c = 0; c < azx_max_codecs[chip->driver_type]; c++) {
 		if ((chip->codec_mask & (1 << c)) & probe_mask) {
 			err = snd_hda_codec_new(chip->bus, c, NULL);
 			if (err < 0)
author
#30 lore raw
In reply to Greg KH
Quoted 1 line · Greg KH

This is the start of the stable review cycle for the 2.6.20.4 release.

A 2.6.20.4-rc1 patch is also availble at:

	kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.20.4-rc1.gz

thanks,

greg k-h

author
#31 lore raw

PATCH 27/31 oom fix: prevent oom from killing a process with children/sibling unkillable

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Ankita Garg <[email protected]>

[PATCH] oom fix: prevent oom from killing a process with children/sibling unkillable

Looking at oom_kill.c, found that the intention to not kill the selected process if any of its children/siblings has OOM_DISABLE set, is not being met.

---
 mm/oom_kill.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
mm/oom_kill.c +1 -1
@@ -320,7 +320,7 @@ static int oom_kill_task(struct task_str
 	 * Don't kill the process if any threads are set to OOM_DISABLE
 	 */
 	do_each_thread(g, q) {
-		if (q->mm == mm && p->oomkilladj == OOM_DISABLE)
+		if (q->mm == mm && q->oomkilladj == OOM_DISABLE)
 			return 1;
 	} while_each_thread(g, q);
 
author
#32 lore raw

PATCH 28/31 dio: invalidate clean pages before dio write

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Zach Brown <[email protected]>

[PATCH] dio: invalidate clean pages before dio write

This patch fixes a user-triggerable oops that was reported by Leonid Ananiev as archived at http://lkml.org/lkml/2007/2/8/337.

dio writes invalidate clean pages that intersect the written region so that subsequent buffered reads go to disk to read the new data. If this fails the interface tries to tell the caller that the cache is inconsistent by returning EIO.

Before this patch we had the problem where this invalidation failure would clobber -EIOCBQUEUED as it made its way from fs/direct-io.c to fs/aio.c. Both fs/aio.c and bio completion call aio_complete() and we reference freed memory, usually oopsing.

This patch addresses this problem by invalidating before the write so that we can cleanly return -EIO before ->direct_IO() has had a chance to return -EIOCBQUEUED.

There is a compromise here. During the dio write we can fault in mmap()ed pages which intersect the written range with get_user_pages() if the user provided them for the source buffer. This is a crazy thing to do, but we can make it mostly work in most cases by trying the invalidation again. The compromise is that we won't return an error if this second invalidation fails if it's an AIO write and we have -EIOCBQUEUED.

This was tested by having two processes race performing large O_DIRECT and buffered ordered writes. Within minutes ext3 would see a race between ext3_releasepage() and jbd holding a reference on ordered data buffers and would cause invalidation to fail, panicing the box. The test can be found in the 'aio_dio_bugs' test group in test.kernel.org/autotest. After this patch the test passes.

---
 mm/filemap.c |   46 +++++++++++++++++++++++++++++++++++-----------
 1 file changed, 35 insertions(+), 11 deletions(-)
mm/filemap.c +35 -11
@@ -2393,7 +2393,8 @@ generic_file_direct_IO(int rw, struct ki
 	struct file *file = iocb->ki_filp;
 	struct address_space *mapping = file->f_mapping;
 	ssize_t retval;
-	size_t write_len = 0;
+	size_t write_len;
+	pgoff_t end = 0; /* silence gcc */
 
 	/*
 	 * If it's a write, unmap all mmappings of the file up-front.  This
@@ -2402,23 +2403,46 @@ generic_file_direct_IO(int rw, struct ki
 	 */
 	if (rw == WRITE) {
 		write_len = iov_length(iov, nr_segs);
+		end = (offset + write_len - 1) >> PAGE_CACHE_SHIFT;
 	       	if (mapping_mapped(mapping))
 			unmap_mapping_range(mapping, offset, write_len, 0);
 	}
 
 	retval = filemap_write_and_wait(mapping);
-	if (retval == 0) {
-		retval = mapping->a_ops->direct_IO(rw, iocb, iov,
-						offset, nr_segs);
-		if (rw == WRITE && mapping->nrpages) {
-			pgoff_t end = (offset + write_len - 1)
-						>> PAGE_CACHE_SHIFT;
-			int err = invalidate_inode_pages2_range(mapping,
+	if (retval)
+		goto out;
+
+	/*
+	 * After a write we want buffered reads to be sure to go to disk to get
+	 * the new data.  We invalidate clean cached page from the region we're
+	 * about to write.  We do this *before* the write so that we can return
+	 * -EIO without clobbering -EIOCBQUEUED from ->direct_IO().
+	 */
+	if (rw == WRITE && mapping->nrpages) {
+		retval = invalidate_inode_pages2_range(mapping,
 					offset >> PAGE_CACHE_SHIFT, end);
-			if (err)
-				retval = err;
-		}
+		if (retval)
+			goto out;
+	}
+
+	retval = mapping->a_ops->direct_IO(rw, iocb, iov, offset, nr_segs);
+	if (retval)
+		goto out;
+
+	/*
+	 * Finally, try again to invalidate clean pages which might have been
+	 * faulted in by get_user_pages() if the source of the write was an
+	 * mmap()ed region of the file we're writing.  That's a pretty crazy
+	 * thing to do, so we don't support it 100%.  If this invalidation
+	 * fails and we have -EIOCBQUEUED we ignore the failure.
+	 */
+	if (rw == WRITE && mapping->nrpages) {
+		int err = invalidate_inode_pages2_range(mapping,
+					      offset >> PAGE_CACHE_SHIFT, end);
+		if (err && retval >= 0)
+			retval = err;
 	}
+out:
 	return retval;
 }
 
author
#33 lore raw

PATCH 29/31 Input: i8042 - fix AUX IRQ delivery check

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Dmitry Torokhov <[email protected]>

Input: i8042 - fix AUX IRQ delivery check

On boxes that do not implement AUX LOOP command we can not verify AUX IRQ delivery and must assume that it is wired properly.

---
 drivers/input/serio/i8042.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/input/serio/i8042.c +4 -1
@@ -543,6 +543,7 @@ static int __devinit i8042_check_aux(voi
 {
 	int retval = -1;
 	int irq_registered = 0;
+	int aux_loop_broken = 0;
 	unsigned long flags;
 	unsigned char param;
 
@@ -572,6 +573,8 @@ static int __devinit i8042_check_aux(voi
 		if (i8042_command(&param, I8042_CMD_AUX_TEST) ||
 		    (param && param != 0xfa && param != 0xff))
 			return -1;
+
+		aux_loop_broken = 1;
 	}
 
 /*
@@ -595,7 +598,7 @@ static int __devinit i8042_check_aux(voi
  * used it for a PCI card or somethig else.
  */
 
-	if (i8042_noloop) {
+	if (i8042_noloop || aux_loop_broken) {
 /*
  * Without LOOP command we can't test AUX IRQ delivery. Assume the port
  * is working and hope we are right.
maintainer
#34 lore raw

Re: [patch 29/31] Input: i8042 - fix AUX IRQ delivery check

Quoted 4 lines · Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

Quoted 8 lines

From: Dmitry Torokhov <[email protected]>

Input: i8042 - fix AUX IRQ delivery check

On boxes that do not implement AUX LOOP command we can not verify AUX IRQ delivery and must assume that it is wired properly.

Greg,

There is another piece missing in AUX delivery test, commit

3ca5de6dd4ec5a139b2b8f00dce3e4726ca91af1

Unfortunately I can't send you a patch at the moment but if you could get it from the mainline that would be great.

Signature · 1 line
Dmitry
#35 lore raw

Re: [patch 29/31] Input: i8042 - fix AUX IRQ delivery check

Quoted 14 lines · Dmitry Torokhov
Quoted 4 lines · Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

Quoted 8 lines

From: Dmitry Torokhov <[email protected]>

Input: i8042 - fix AUX IRQ delivery check

On boxes that do not implement AUX LOOP command we can not verify AUX IRQ delivery and must assume that it is wired properly.

Quoted 9 lines

Greg,

There is another piece missing in AUX delivery test, commit

   3ca5de6dd4ec5a139b2b8f00dce3e4726ca91af1

Unfortunately I can't send you a patch at the moment but if you could get it from the mainline that would be great.

I was going to send that but wasn't really sure if I should. Next time I'll just send everything I have...

#36 lore raw

Re: [stable] [patch 29/31] Input: i8042 - fix AUX IRQ delivery check

In reply to Dmitry Torokhov
Quoted 14 lines · Dmitry Torokhov
Quoted 4 lines · Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

Quoted 8 lines

From: Dmitry Torokhov <[email protected]>

Input: i8042 - fix AUX IRQ delivery check

On boxes that do not implement AUX LOOP command we can not verify AUX IRQ delivery and must assume that it is wired properly.

Quoted 8 lines

Greg,

There is another piece missing in AUX delivery test, commit

    3ca5de6dd4ec5a139b2b8f00dce3e4726ca91af1

Unfortunately I can't send you a patch at the moment but if you could get it from the mainline that would be great.

Thanks for letting me know, I've added it to the queue now.

greg k-h

author
#37 lore raw

PATCH 30/31 fix deadlock in audit_log_task_context()

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Al Viro <[email protected]>

[PATCH] fix deadlock in audit_log_task_context()

GFP_KERNEL allocations in non-blocking context; fixed by killing an idiotic use of security_getprocattr().

---
 kernel/auditsc.c |   24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)
kernel/auditsc.c +11 -13
@@ -734,28 +734,26 @@ static inline void audit_free_context(st
 void audit_log_task_context(struct audit_buffer *ab)
 {
 	char *ctx = NULL;
-	ssize_t len = 0;
+	unsigned len;
+	int error;
+	u32 sid;
 
-	len = security_getprocattr(current, "current", NULL, 0);
-	if (len < 0) {
-		if (len != -EINVAL)
+	selinux_get_task_sid(current, &sid);
+	if (!sid)
+		return;
+
+	error = selinux_sid_to_string(sid, &ctx, &len);
+	if (error) {
+		if (error != -EINVAL)
 			goto error_path;
 		return;
 	}
 
-	ctx = kmalloc(len, GFP_KERNEL);
-	if (!ctx)
-		goto error_path;
-
-	len = security_getprocattr(current, "current", ctx, len);
-	if (len < 0 )
-		goto error_path;
-
 	audit_log_format(ab, " subj=%s", ctx);
+	kfree(ctx);
 	return;
 
 error_path:
-	kfree(ctx);
 	audit_panic("error in audit_log_task_context");
 	return;
 }
author
#38 lore raw

PATCH 31/31 UML - arch_prctl should set thread fs

In reply to Greg KH

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Jeff Dike <[email protected]>

x86_64 needs some TLS fixes. What was missing was remembering the child thread id during clone and stuffing it into the child during each context switch.

The %fs value is stored separately in the thread structure since the host controls what effect it has on the actual register file. The host also needs to store it in its own thread struct, so we need the value kept outside the register file.

arch_prctl_skas was fixed to call PTRACE_ARCH_PRCTL appropriately. There is some saving and restoring of registers in the ARCH_SET_* cases so that the correct set of registers are changed on the host and restored to the process when it runs again.

---
 arch/um/include/os.h                 |    2 
 arch/um/os-Linux/sys-x86_64/Makefile |    2 
 arch/um/os-Linux/sys-x86_64/prctl.c  |   12 +++++
 arch/um/sys-x86_64/syscalls.c        |   76 ++++++++++++++++++++++++++---------
 arch/um/sys-x86_64/tls.c             |   11 +++--
 include/asm-um/processor-x86_64.h    |    6 +-
 include/asm-um/ptrace-x86_64.h       |    6 --
 7 files changed, 86 insertions(+), 29 deletions(-)
arch/um/include/os.h +2 -0
@@ -341,4 +341,6 @@ extern void maybe_sigio_broken(int fd, i
 extern void sig_handler_common_skas(int sig, void *sc_ptr);
 extern void user_signal(int sig, union uml_pt_regs *regs, int pid);
 
+extern int os_arch_prctl(int pid, int code, unsigned long *addr);
+
 #endif
arch/um/os-Linux/sys-x86_64/Makefile +1 -1
@@ -3,7 +3,7 @@
 # Licensed under the GPL
 #
 
-obj-$(CONFIG_MODE_SKAS) = registers.o signal.o
+obj-$(CONFIG_MODE_SKAS) = registers.o prctl.o signal.o
 
 USER_OBJS := $(obj-y)
 
arch/um/os-Linux/sys-x86_64/prctl.c new file +12 -0
@@ -0,0 +1,12 @@
+/*
+ * Copyright (C) 2007 Jeff Dike (jdike@{addtoit.com,linux.intel.com})
+ * Licensed under the GPL
+ */
+
+#include <sys/ptrace.h>
+#include <linux/ptrace.h>
+
+int os_arch_prctl(int pid, int code, unsigned long *addr)
+{
+	return ptrace(PTRACE_ARCH_PRCTL, pid, (unsigned long) addr, code);
+}
arch/um/sys-x86_64/syscalls.c +58 -18

109 lines not on this page · raw message

arch/um/sys-x86_64/tls.c +7 -4
@@ -1,14 +1,17 @@
 #include "linux/sched.h"
 
-void debug_arch_force_load_TLS(void)
-{
-}
-
 void clear_flushed_tls(struct task_struct *task)
 {
 }
 
 int arch_copy_tls(struct task_struct *t)
 {
+	/*
+	 * If CLONE_SETTLS is set, we need to save the thread id
+	 * (which is argument 5, child_tid, of clone) so it can be set
+	 * during context switches.
+	 */
+	t->thread.arch.fs = t->thread.regs.regs.skas.regs[R8 / sizeof(long)];
+
         return 0;
 }
include/asm-um/processor-x86_64.h +4 -2
@@ -13,6 +13,7 @@
 struct arch_thread {
         unsigned long debugregs[8];
         int debugregs_seq;
+	unsigned long fs;
         struct faultinfo faultinfo;
 };
 
@@ -25,8 +26,9 @@ extern inline void rep_nop(void)
 #define cpu_relax()   rep_nop()
 
 #define INIT_ARCH_THREAD { .debugregs  		= { [ 0 ... 7 ] = 0 }, \
-                           .debugregs_seq	= 0, \
-                           .faultinfo		= { 0, 0, 0 } }
+			   .debugregs_seq	= 0,			       \
+			   .fs			= 0, \
+			   .faultinfo		= { 0, 0, 0 } }
 
 static inline void arch_flush_thread(struct arch_thread *thread)
 {
include/asm-um/ptrace-x86_64.h +2 -4
@@ -81,9 +81,7 @@ static inline void arch_switch_to_tt(str
 {
 }
 
-static inline void arch_switch_to_skas(struct task_struct *from,
-                                       struct task_struct *to)
-{
-}
+extern void arch_switch_to_skas(struct task_struct *from,
+				struct task_struct *to);
 
 #endif
Signature · 9 lines
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
#39 lore raw
In reply to Greg KH
Quoted 6 lines · Greg KH

This is the start of the stable review cycle for the 2.6.20.4 release. There are 31 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.

Quoted 7 lines

These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.

Responses should be made by Thursday March, 22, 15:00:00 UTC. Anything received after that time might be too late.

BINGO! One of these 31 patches may be the guilty party that's playing tricks with tar's mind. I'm running 2.6.20.4-rc1 on an older athlon xp2800 with a gig of ram.

Amanda has gotten through the estimate phase and is now doing the backup. It will fail, out of tape. Here is an amstatus output as its running right now.

coyote:/GenesAmandaHelper-0.5 3 planner: [dumps way too big, 350850 KB, must skip incremental dumps] coyote:/GenesAmandaHelper-0.6 1 planner: [dumps way too big, 184977 KB, must skip incremental dumps]

coyote:/bin                   1 planner: [dumps way too big, 1110 KB, must skip incremental dumps]
coyote:/boot                  1        3m wait for dumping
coyote:/dev                   1 planner: [dumps way too big, 290 KB, must skip incremental dumps]
coyote:/etc                   1 planner: [dumps way too big, 18291 KB, must skip incremental dumps]
coyote:/home                  0     1018m wait for dumping
coyote:/lib                   3 planner: [dumps way too big, 11705 KB, must skip incremental dumps]
coyote:/opt                   1        5m wait for dumping
coyote:/root                  3 planner: [dumps way too big, 785963 KB, must skip incremental dumps]
coyote:/sbin                  1 planner: [dumps way too big, 10 KB, must skip incremental dumps]
coyote:/tmp                   4       32m wait for dumping
coyote:/usr/X11R6             1        2m wait for dumping
coyote:/usr/bin               1 planner: [dumps way too big, 339170 KB, must skip incremental dumps]
coyote:/usr/dlds              1 planner: [dumps way too big, 2140 KB, must skip incremental dumps]
coyote:/usr/dlds-misc         3        0m wait for dumping
coyote:/usr/dlds-rpms         1 planner: [dumps way too big, 3130 KB, must skip incremental dumps]
coyote:/usr/dlds-tgzs         1 planner: [dumps way too big, 10 KB, must skip incremental dumps]
coyote:/usr/games             0        0m wait for dumping
coyote:/usr/include           1 planner: [dumps way too big, 10557 KB, must skip incremental dumps]
coyote:/usr/kerberos          1        0m wait for dumping
coyote:/usr/lib               1 planner: [dumps way too big, 474409 KB, must skip incremental dumps]
coyote:/usr/libexec           2 planner: [dumps way too big, 11285 KB, must skip incremental dumps]
coyote:/usr/local             2      279m wait for dumping
coyote:/usr/man               1        0m wait for dumping
coyote:/usr/movies            2     7271m dumping     5485m ( 75.44%) (0:12:47)
coyote:/usr/music             1 planner: [dumps way too big, 2448290 KB, must skip incremental dumps]
coyote:/usr/pix               2       17m wait for dumping
coyote:/usr/sbin              1 planner: [dumps way too big, 3254 KB, must skip incremental dumps]
coyote:/usr/share             3 planner: [dumps way too big, 40514 KB, must skip incremental dumps]
coyote:/usr/src               3     6822m wait for dumping
coyote:/var                   1      366m wait for dumping

SUMMARY part real estimated
size size

partition       :  32
estimated       :  32                31973m
flush           :   0         0m
failed          :  18                16155m           ( 50.53%)
wait for dumping:  13                 8547m           ( 26.73%)
dumping to tape :   0                    0m           (  0.00%)
dumping         :   1      5485m      7271m ( 75.44%) ( 17.16%)
dumped          :   0         0m         0m (  0.00%) (  0.00%)
wait for writing:   0         0m         0m (  0.00%) (  0.00%)
wait to flush   :   0         0m         0m (100.00%) (  0.00%)
writing to tape :   0         0m         0m (  0.00%) (  0.00%)
failed to tape  :   0         0m         0m (  0.00%) (  0.00%)
taped           :   0         0m         0m (  0.00%) (  0.00%)
  tape 1        :   0         0m         0m (  0.00%) Dailys-19
8 dumpers idle  : not-idle
taper idle
network free kps:      6800
holding space   :     71118m (100.00%)
 dumper0 busy   :  0:00:00  (  0.00%)
 0 dumpers busy :  0:00:00  (  0.00%)
 1 dumper busy  :  0:00:00  (  0.00%)

----------------
The directory shown on line one of this report actually has:
[root@coyote /]# du -h /GenesAmandaHelper-0.5/
1.6G /GenesAmandaHelper-0.5/config-bak
1.6G /GenesAmandaHelper-0.5/

But line one above says its 350850 KB. 351 MB. That directory and its contents have not been touched in at least a week, March 7th TBE and had 766MB in it the last time I looked. So a level 3 backup should be a very sparsely filled 65k directory list.

Then, looking at line 2, that tree is virtually identical and generally contains the same, or a few percentage points more data due to a change in the starting point of one of the amanda trees I'm doing external to amanda, so it may contain as much as 800MB right now. As this is an active directory, with 20 megs or so new each night, I could believe a level 1 being 21MB maybe, certainly no more. The last level 1 under a good kernel was 19MB according to the emails amanda sends me. But it wants to backup 185MB tonight?

Now we are a little closer to finding this problem. Or should I say this, because if I'm booted to either a working 2.6.20* kernel, or to one of the 4 2.6.21-rc's I've tested, the data returned by a du -h is sane. The figure I pasted in for the line 1 argument above is not, it's nearly double the actual size of that particular directory. So it's conceivable that there are 2 problems as this is the first time a du -h has been effected too.

In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC.

I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then.

But its getting sleepy out now.

Thanks all.

Signature · 6 lines
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
There is an order of things in this universe.
		-- Apollo, "Who Mourns for Adonais?" stardate 3468.1
author
#40 lore raw
Quoted 7 lines · Gene Heskett

In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC.

I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then.

I'd recommend using the quilt tree of patches to do this, it will be easier than trying to split the larger patch up into pieces by hand.

thanks,

greg k-h

#41 lore raw
Quoted 8 lines · Greg KH
Quoted 6 lines · Gene Heskett

In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC.

I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then.

Quoted 6 lines

I'd recommend using the quilt tree of patches to do this, it will be easier than trying to split the larger patch up into pieces by hand.

thanks,

greg k-h

I don't have quilt installed, and no idea how to use it if it was, Greg. Even my git is now pushing a year old.

Signature · 7 lines
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If I were a grave-digger or even a hangman, there are some people I could
work for with a great deal of enjoyment.
		-- Douglas Jerrold
#42 lore raw
Quoted 11 lines · Gene Heskett
Quoted 10 lines · Greg KH
Quoted 6 lines · Gene Heskett

In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC.

I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then.

I'd recommend using the quilt tree of patches to do this, it will be easier than trying to split the larger patch up into pieces by hand.

Quoted 7 lines
Quoted 3 lines

thanks,

greg k-h

I don't have quilt installed, and no idea how to use it if it was, Greg. Even my git is now pushing a year old.

Gene-

quilt is a very easy tool to use... Here is a quick run-down.

#1) remove the stable -rc patch from the tree

#2) install quilt

#3) go to your source tree, and create a directory called "patches"

#4) copy all of the patches from Greg's queue into that "patches" directory, including the "series" file.

#5) quilt push, to apply the first patch
quilt push, to apply the second patch (you get the idea) quilt push -a , to apply all patches in the series

#6) quilt pop, to back out the most recent patch pushed in
quilt pop -a to back out the entire series.

If a patch doesnt apply, quilt will let you know about it, and present you with the option to force the patch to apply. This is highly unlikely to occur, since Greg has already done what needs to be done to make these patches apply to the source.

For a better explanation, see "man quilt". Using quilt, when you have a list of patches and a series file containing the merge order is *much* easier that a git bisection, and can help you to find the problem patch much quicker.

I hope this helps...

Good Luck,

Michael Krufky

#43 lore raw
Quoted 24 lines · Michael Krufky
Quoted 12 lines · Gene Heskett
Quoted 11 lines · Greg KH
Quoted 6 lines · Gene Heskett

In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC.

I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then.

I'd recommend using the quilt tree of patches to do this, it will be easier than trying to split the larger patch up into pieces by hand.

Quoted 6 lines
Quoted 3 lines

thanks,

greg k-h

I don't have quilt installed, and no idea how to use it if it was, Greg. Even my git is now pushing a year old.

Gene-

quilt is a very easy tool to use... Here is a quick run-down.

Quoted 8 lines

#1) remove the stable -rc patch from the tree

#2) install quilt

#3) go to your source tree, and create a directory called "patches"

#4) copy all of the patches from Greg's queue into that "patches" directory, including the "series" file.

I hope by Greg's queue you meant:

<ftp:ftp.kernel.org:/pub/linux/kernel/people/gregkh/gregkh-2.6/patches> As that's the tree I just pulled in and put in /usr/src/patches with gftp.

Quoted 12 lines

#5) quilt push, to apply the first patch
quilt push, to apply the second patch (you get the idea) quilt push -a , to apply all patches in the series

#6) quilt pop, to back out the most recent patch pushed in
quilt pop -a to back out the entire series.

If a patch doesnt apply, quilt will let you know about it, and present you with the option to force the patch to apply. This is highly unlikely to occur, since Greg has already done what needs to be done to make these patches apply to the source.

Quoted 6 lines

For a better explanation, see "man quilt". Using quilt, when you have a list of patches and a series file containing the merge order is *much* easier that a git bisection, and can help you to find the problem patch much quicker.

I hope this helps...

I do too, but I'm now less than 2 hours from the backup run, which with this currently running kernel, should be a sane one.

? Since this will start with a patch level of a 2.6.20.3 kernel (or is that patch level a mistaken assumption on my part, but I haven't reversed the 2.6.20.4-rc1 patch yet, that's next.), and I have to edit both the Makefile and my 'makeit' script so the names all match, what makes a good naming convention while I'm doing this? This might all be clear once I read the quilt manpage, which I haven't had a chance to do yet.

That is next, after I reverse that patch.

Quoted 3 lines

Good Luck,

Michael Krufky

Signature · 6 lines
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The chief cause of problems is solutions.
		-- Eric Sevareid
#44 lore raw
In reply to Michael Krufky
Quoted 45 lines · Michael Krufky
Quoted 12 lines · Gene Heskett
Quoted 11 lines · Greg KH
Quoted 6 lines · Gene Heskett

In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC.

I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then.

I'd recommend using the quilt tree of patches to do this, it will be easier than trying to split the larger patch up into pieces by hand.

Quoted 6 lines
Quoted 3 lines

thanks,

greg k-h

I don't have quilt installed, and no idea how to use it if it was, Greg. Even my git is now pushing a year old.

Gene-

quilt is a very easy tool to use... Here is a quick run-down.

#1) remove the stable -rc patch from the tree

#2) install quilt

#3) go to your source tree, and create a directory called "patches"

#4) copy all of the patches from Greg's queue into that "patches" directory, including the "series" file.

#5) quilt push, to apply the first patch
quilt push, to apply the second patch (you get the idea) quilt push -a , to apply all patches in the series

#6) quilt pop, to back out the most recent patch pushed in
quilt pop -a to back out the entire series.

If a patch doesnt apply, quilt will let you know about it, and present you with the option to force the patch to apply. This is highly unlikely to occur, since Greg has already done what needs to be done to make these patches apply to the source.

Quoted 7 lines

For a better explanation, see "man quilt". Using quilt, when you have a list of patches and a series file containing the merge order is *much* easier that a git bisection, and can help you to find the problem patch much quicker.

I hope this helps...

It looks like, from the series files contents, that I grabbed the wrong 'queue', its all 2.6.21 stuff. url please.

Thanks.

Quoted 3 lines

Good Luck,

Michael Krufky

Signature · 6 lines
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"You show me an American who can keep his mouth shut and I'll eat him."
-- Newspaperman from Frank Capra's _Meet_John_Doe_
author
#45 lore raw
Quoted 51 lines · Gene Heskett
Quoted 50 lines · Michael Krufky
Quoted 12 lines · Gene Heskett
Quoted 11 lines · Greg KH
Quoted 6 lines · Gene Heskett

In any event, something tickled the monster, and its hungry. This is a full-stop, show-stopper AFAIAC.

I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test kernels tomorrow to start a bisect if no one has any better idea before then.

I'd recommend using the quilt tree of patches to do this, it will be easier than trying to split the larger patch up into pieces by hand.

Quoted 6 lines
Quoted 3 lines

thanks,

greg k-h

I don't have quilt installed, and no idea how to use it if it was, Greg. Even my git is now pushing a year old.

Gene-

quilt is a very easy tool to use... Here is a quick run-down.

#1) remove the stable -rc patch from the tree

#2) install quilt

#3) go to your source tree, and create a directory called "patches"

#4) copy all of the patches from Greg's queue into that "patches" directory, including the "series" file.

#5) quilt push, to apply the first patch
quilt push, to apply the second patch (you get the idea) quilt push -a , to apply all patches in the series

#6) quilt pop, to back out the most recent patch pushed in
quilt pop -a to back out the entire series.

If a patch doesnt apply, quilt will let you know about it, and present you with the option to force the patch to apply. This is highly unlikely to occur, since Greg has already done what needs to be done to make these patches apply to the source.

For a better explanation, see "man quilt". Using quilt, when you have a list of patches and a series file containing the merge order is *much* easier that a git bisection, and can help you to find the problem patch much quicker.

Quoted 4 lines
Quoted 2 lines

I hope this helps...

It looks like, from the series files contents, that I grabbed the wrong 'queue', its all 2.6.21 stuff. url please.

The patch queue can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git

All of the patches and the series file are in the review-2.6.20/ directory.

thanks,

greg k-h

#46 lore raw

On Tuesday 20 March 2007, Greg KH wrote:
[...]

Quoted 8 lines
Quoted 2 lines

It looks like, from the series files contents, that I grabbed the wrong 'queue', its all 2.6.21 stuff. url please.

The patch queue can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git

All of the patches and the series file are in the review-2.6.20/ directory.

This is not available via ftp? My git is git version 0.99.7d, veddy veddy long in the tooth by now I suspect. And, apparently no manpages. Humm, smart is still running, maybe it has a newer git that's more conversant with your syntax. Yup smart is pulling it in now. Later, thanks.

Quoted 3 lines

thanks,

greg k-h

Signature · 7 lines
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
When I works, I works hard.
When I sits, I sits easy.
And when I thinks, I goes to sleep.
Acked-by Alan Cox
#47 lore raw
Quoted 8 lines · Gene Heskett

On Tuesday 20 March 2007, Greg KH wrote:
[...]

Quoted 6 lines
Quoted 2 lines

It looks like, from the series files contents, that I grabbed the wrong 'queue', its all 2.6.21 stuff. url please.

The patch queue can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git

Quoted 7 lines
Quoted 2 lines

All of the patches and the series file are in the review-2.6.20/ directory.

This is not available via ftp? My git is git version 0.99.7d, veddy veddy long in the tooth by now I suspect. And, apparently no manpages. Humm, smart is still running, maybe it has a newer git that's more conversant with your syntax. Yup smart is pulling it in now. Later, thanks.

The attached patch was already reported as being responsible for a different regression.

Does reverting it help?

If not, and if you'll need any help with bisecting for the guilty patch, please send me a private email.

cu
Adrian

Signature · 4 lines
       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed
Quoted 1 line

From [email protected] Tue Mar 13 11:05:30 2007

From: Jan Beulich <[email protected]>
Date: Tue, 13 Mar 2007 14:04:11 -0400
Subject: adjust legacy IDE resource setting (v2)
To: linux-stable <[email protected]>
Message-ID: <[email protected]>

From: Jan Beulich <[email protected]>

adjust legacy IDE resource setting (v2)

The change to force legacy mode IDE channels' resources to fixed non-zero values confuses (at least some versions of) X, because the values reported by the kernel and those readable from PCI config space aren't consistent anymore. Therefore, this patch arranges for the respective BARs to also get updated if possible.

---
 drivers/pci/probe.c |   45 ++++++++++++++++++++++++++++++++-------------
 1 file changed, 32 insertions(+), 13 deletions(-)
drivers/pci/probe.c +32 -13
@@ -639,7 +639,34 @@ static void pci_read_irq(struct pci_dev 
 	dev->irq = irq;
 }
 
-#define LEGACY_IO_RESOURCE	(IORESOURCE_IO | IORESOURCE_PCI_FIXED)
+static void change_legacy_io_resource(struct pci_dev * dev, unsigned index,
+                                      unsigned start, unsigned end)
+{
+	unsigned base = start & PCI_BASE_ADDRESS_IO_MASK;
+	unsigned len = (end | ~PCI_BASE_ADDRESS_IO_MASK) - base + 1;
+
+	/*
+	 * Some X versions get confused when the BARs reported through
+	 * /sys or /proc differ from those seen in config space, thus
+	 * try to update the config space values, too.
+	 */
+	if (!(pci_resource_flags(dev, index) & IORESOURCE_IO))
+		printk(KERN_WARNING "%s: cannot adjust BAR%u (not I/O)\n",
+		       pci_name(dev), index);
+	else if (pci_resource_len(dev, index) != len)
+		printk(KERN_WARNING "%s: cannot adjust BAR%u (size %04X)\n",
+		       pci_name(dev), index, (unsigned)pci_resource_len(dev, index));
+	else {
+		printk(KERN_INFO "%s: trying to change BAR%u from %04X to %04X\n",
+		       pci_name(dev), index,
+		       (unsigned)pci_resource_start(dev, index), base);
+		pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + index * 4, base);
+	}
+	pci_resource_start(dev, index) = start;
+	pci_resource_end(dev, index)   = end;
+	pci_resource_flags(dev, index) =
+		IORESOURCE_IO | IORESOURCE_PCI_FIXED | PCI_BASE_ADDRESS_SPACE_IO;
+}
 
 /**
  * pci_setup_device - fill in class and map information of a device
@@ -692,20 +719,12 @@ static int pci_setup_device(struct pci_d
 			u8 progif;
 			pci_read_config_byte(dev, PCI_CLASS_PROG, &progif);
 			if ((progif & 1) == 0) {
-				dev->resource[0].start = 0x1F0;
-				dev->resource[0].end = 0x1F7;
-				dev->resource[0].flags = LEGACY_IO_RESOURCE;
-				dev->resource[1].start = 0x3F6;
-				dev->resource[1].end = 0x3F6;
-				dev->resource[1].flags = LEGACY_IO_RESOURCE;
+				change_legacy_io_resource(dev, 0, 0x1F0, 0x1F7);
+				change_legacy_io_resource(dev, 1, 0x3F6, 0x3F6);
 			}
 			if ((progif & 4) == 0) {
-				dev->resource[2].start = 0x170;
-				dev->resource[2].end = 0x177;
-				dev->resource[2].flags = LEGACY_IO_RESOURCE;
-				dev->resource[3].start = 0x376;
-				dev->resource[3].end = 0x376;
-				dev->resource[3].flags = LEGACY_IO_RESOURCE;
+				change_legacy_io_resource(dev, 2, 0x170, 0x177);
+				change_legacy_io_resource(dev, 3, 0x376, 0x376);
 			}
 		}
 		break;