2.6.20-stable review
Subsystems (23)
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
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 :
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 ) {
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(structreturn 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;
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_stickycopy_to_userleakUser 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
David Miller
maintainerRe: [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_stickycopy_to_userleakUser 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.
Re: [patch 03/31] Fix user copy length in ipv6_sockglue.c
In reply to Chris WrightQuoted 10 lines · Chris Wright
Quoted 6 lines · * Greg KH ([email protected]) wrote:
From: Chris Wright <[email protected]>
[IPV6] fix
ipv6_getsockopt_stickycopy_to_userleakUser 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
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) {
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 ;
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_instancspin_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))) {
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 };
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_du8 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 ;
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 :
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--) {
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(intstatic 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
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 *uadif (!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 ;
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, stint 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.
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; }
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:
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;
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);
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 ; }
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 usecall_rcu) wouldn't free memory while still in use in a rcu read-side critical section. It should have beensynchronize_rcuof course, but withtnode_freeusingcall_rcuit 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 triercu_assign_pointer (t->trie,trie_rebalance (t, tp)); }else rcu_assign_pointer (t->trie,NULL ); -preempt_enable ();return 1 ; }
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_socFirst: no IPv4 options. */ newinet->opt =NULL ; + newnp->ipv6_fl_list =NULL ;/* Clone RX bits */ newnp->rxopt.all = np->rxopt.all;
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_buffmemcpy (n->cb, skb->cb,sizeof (skb->cb));C (len);C (data_len); +C (mac_len);C (csum);C (local_df); n->cloned =1 ;
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 *mif (!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 ;
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 __tsbcmp REG3 ,TAG ; \ be,a,pt %xcc,OK_LABEL ; \mov REG4 ,REG1 ; +#endif #endif /* !(_SPARC64_TSB_H) */
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);
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 iif (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;
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(streturn 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 )
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
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);
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 kistruct 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; }
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(voiif (i8042_command (¶m,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.
Dmitry Torokhov
maintainerRe: [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
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
3ca5de6dd4ec5a139b2b8f00dce3e4726ca91af1Unfortunately 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...
Re: [stable] [patch 29/31] Input: i8042 - fix AUX IRQ delivery check
In reply to Dmitry TorokhovQuoted 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
3ca5de6dd4ec5a139b2b8f00dce3e4726ca91af1Unfortunately 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
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(stvoid 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 ; }
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, iextern 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
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
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
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
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
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
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_
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
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.gitAll 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.
Adrian Bunk
Acked-by Alan CoxQuoted 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 SeedQuoted 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_du8 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 ;