This is the start of the stable review cycle for the 2.6.17.8 release.
There are 23 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 Sunday, August 6, 05:00:00 UTC. Anything
received after that time might be too late.
I've also posted a roll-up patch with all changes in it if people want
to test it out. It can be found at:
kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz
thanks,
the -stable release team
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Patrick McHardy <[email protected]>
[NETFILTER]: H.323 helper: fix possible NULL-ptr dereference
An RCF message containing a timeout results in a NULL-ptr dereference if
no RRQ has been seen before.
Noticed by the "SATURN tool", reported by Thomas Dillig <[email protected]>
and Isil Dillig <[email protected]>.
Signed-off-by: Patrick McHardy <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/netfilter/ip_conntrack_helper_h323.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.17.7.orig/net/ipv4/netfilter/ip_conntrack_helper_h323.c
+++ linux-2.6.17.7/net/ipv4/netfilter/ip_conntrack_helper_h323.c
@@ -1092,7 +1092,7 @@ static struct ip_conntrack_expect *find_
tuple.dst.protonum = IPPROTO_TCP;
exp = __ip_conntrack_expect_find(&tuple);
- if (exp->master == ct)
+ if (exp && exp->master == ct)
return exp;
return NULL;
}
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Chuck Ebbert <[email protected]>
On 15 Jun 2006 03:45:10 +0200, Andi Kleen wrote:
> Anyways I would say that if the BIOS can't get MCFG right then
> it's likely not been validated on that board and shouldn't be used.
According to Petr Vandrovec:
... "What is important (and checked) is address of MMCONFIG reported by MCFG
table... Unfortunately code does not bother with printing that address :-(
"Another problem is that code has hardcoded that MMCONFIG area is 256MB large.
Unfortunately for the code PCI specification allows any power of two between 2MB
and 256MB if vendor knows that such amount of busses (from 2 to 128) will be
sufficient for system. With notebook it is quite possible that not full 8 bits
are implemented for MMCONFIG bus number."
So here is a patch. Unfortunately my system still fails the test because
it doesn't reserve any part of the MMCONFIG area, but this may fix others.
Booted on x86_64, only compiled on i386. x86_64 still remaps the max area
(256MB) even though only 2MB is checked... but 2.6.16 had no check at all
so it is still better.
PCI: reduce size of x86 MMCONFIG reserved area check
1. Print the address of the MMCONFIG area when the test for that area
being reserved fails.
2. Only check if the first 2MB is reserved, as that is the minimum.
Signed-off-by: Chuck Ebbert <[email protected]>
Acked-by: Arjan van de Ven <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
---
arch/i386/pci/mmconfig.c | 9 ++++++---
arch/x86_64/pci/mmconfig.c | 13 +++++++++----
2 files changed, 15 insertions(+), 7 deletions(-)
--- linux-2.6.17.7.orig/arch/i386/pci/mmconfig.c
+++ linux-2.6.17.7/arch/i386/pci/mmconfig.c
@@ -15,7 +15,9 @@
#include <asm/e820.h>
#include "pci.h"
-#define MMCONFIG_APER_SIZE (256*1024*1024)
+/* aperture is up to 256MB but BIOS may reserve less */
+#define MMCONFIG_APER_MIN (2 * 1024*1024)
+#define MMCONFIG_APER_MAX (256 * 1024*1024)
/* Assume systems with more busses have correct MCFG */
#define MAX_CHECK_BUS 16
@@ -197,9 +199,10 @@ void __init pci_mmcfg_init(void)
return;
if (!e820_all_mapped(pci_mmcfg_config[0].base_address,
- pci_mmcfg_config[0].base_address + MMCONFIG_APER_SIZE,
+ pci_mmcfg_config[0].base_address + MMCONFIG_APER_MIN,
E820_RESERVED)) {
- printk(KERN_ERR "PCI: BIOS Bug: MCFG area is not E820-reserved\n");
+ printk(KERN_ERR "PCI: BIOS Bug: MCFG area at %x is not E820-reserved\n",
+ pci_mmcfg_config[0].base_address);
printk(KERN_ERR "PCI: Not using MMCONFIG.\n");
return;
}
--- linux-2.6.17.7.orig/arch/x86_64/pci/mmconfig.c
+++ linux-2.6.17.7/arch/x86_64/pci/mmconfig.c
@@ -13,7 +13,10 @@
#include "pci.h"
-#define MMCONFIG_APER_SIZE (256*1024*1024)
+/* aperture is up to 256MB but BIOS may reserve less */
+#define MMCONFIG_APER_MIN (2 * 1024*1024)
+#define MMCONFIG_APER_MAX (256 * 1024*1024)
+
/* Verify the first 16 busses. We assume that systems with more busses
get MCFG right. */
#define MAX_CHECK_BUS 16
@@ -175,9 +178,10 @@ void __init pci_mmcfg_init(void)
return;
if (!e820_all_mapped(pci_mmcfg_config[0].base_address,
- pci_mmcfg_config[0].base_address + MMCONFIG_APER_SIZE,
+ pci_mmcfg_config[0].base_address + MMCONFIG_APER_MIN,
E820_RESERVED)) {
- printk(KERN_ERR "PCI: BIOS Bug: MCFG area is not E820-reserved\n");
+ printk(KERN_ERR "PCI: BIOS Bug: MCFG area at %x is not E820-reserved\n",
+ pci_mmcfg_config[0].base_address);
printk(KERN_ERR "PCI: Not using MMCONFIG.\n");
return;
}
@@ -190,7 +194,8 @@ void __init pci_mmcfg_init(void)
}
for (i = 0; i < pci_mmcfg_config_num; ++i) {
pci_mmcfg_virt[i].cfg = &pci_mmcfg_config[i];
- pci_mmcfg_virt[i].virt = ioremap_nocache(pci_mmcfg_config[i].base_address, MMCONFIG_APER_SIZE);
+ pci_mmcfg_virt[i].virt = ioremap_nocache(pci_mmcfg_config[i].base_address,
+ MMCONFIG_APER_MAX);
if (!pci_mmcfg_virt[i].virt) {
printk("PCI: Cannot map mmconfig aperture for segment %d\n",
pci_mmcfg_config[i].pci_segment_group_number);
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Herbert Xu <[email protected]>
[NET]: Update frag_list in pskb_trim
When pskb_trim has to defer to ___pksb_trim to trim the frag_list part of
the packet, the frag_list is not updated to reflect the trimming. This
will usually work fine until you hit something that uses the packet length
or tail from the frag_list.
Examples include esp_output and ip_fragment.
Another problem caused by this is that you can end up with a linear packet
with a frag_list attached.
It is possible to get away with this if we audit everything to make sure
that they always consult skb->len before going down onto frag_list. In
fact we can do the samething for the paged part as well to avoid copying
the data area of the skb. For now though, let's do the conservative fix
and update frag_list.
Many thanks to Marco Berizzi for helping me to track down this bug.
This 4-year old bug took 3 months to track down. Marco was very patient
indeed :)
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/skbuff.h | 24 +++++------
net/core/skbuff.c | 106 ++++++++++++++++++++++++++++++++++---------------
2 files changed, 86 insertions(+), 44 deletions(-)
--- linux-2.6.17.7.orig/include/linux/skbuff.h
+++ linux-2.6.17.7/include/linux/skbuff.h
@@ -967,15 +967,16 @@ static inline void skb_reserve(struct sk
#define NET_SKB_PAD 16
#endif
-extern int ___pskb_trim(struct sk_buff *skb, unsigned int len, int realloc);
+extern int ___pskb_trim(struct sk_buff *skb, unsigned int len);
static inline void __skb_trim(struct sk_buff *skb, unsigned int len)
{
- if (!skb->data_len) {
- skb->len = len;
- skb->tail = skb->data + len;
- } else
- ___pskb_trim(skb, len, 0);
+ if (unlikely(skb->data_len)) {
+ WARN_ON(1);
+ return;
+ }
+ skb->len = len;
+ skb->tail = skb->data + len;
}
/**
@@ -985,6 +986,7 @@ static inline void __skb_trim(struct sk_
*
* Cut the length of a buffer down by removing data from the tail. If
* the buffer is already under the length specified it is not modified.
+ * The skb must be linear.
*/
static inline void skb_trim(struct sk_buff *skb, unsigned int len)
{
@@ -995,12 +997,10 @@ static inline void skb_trim(struct sk_bu
static inline int __pskb_trim(struct sk_buff *skb, unsigned int len)
{
- if (!skb->data_len) {
- skb->len = len;
- skb->tail = skb->data+len;
- return 0;
- }
- return ___pskb_trim(skb, len, 1);
+ if (skb->data_len)
+ return ___pskb_trim(skb, len);
+ __skb_trim(skb, len);
+ return 0;
}
static inline int pskb_trim(struct sk_buff *skb, unsigned int len)
--- linux-2.6.17.7.orig/net/core/skbuff.c
+++ linux-2.6.17.7/net/core/skbuff.c
@@ -251,11 +251,11 @@ nodata:
}
-static void skb_drop_fraglist(struct sk_buff *skb)
+static void skb_drop_list(struct sk_buff **listp)
{
- struct sk_buff *list = skb_shinfo(skb)->frag_list;
+ struct sk_buff *list = *listp;
- skb_shinfo(skb)->frag_list = NULL;
+ *listp = NULL;
do {
struct sk_buff *this = list;
@@ -264,6 +264,11 @@ static void skb_drop_fraglist(struct sk_
} while (list);
}
+static inline void skb_drop_fraglist(struct sk_buff *skb)
+{
+ skb_drop_list(&skb_shinfo(skb)->frag_list);
+}
+
static void skb_clone_fraglist(struct sk_buff *skb)
{
struct sk_buff *list;
@@ -802,49 +807,86 @@ struct sk_buff *skb_pad(struct sk_buff *
return nskb;
}
-/* Trims skb to length len. It can change skb pointers, if "realloc" is 1.
- * If realloc==0 and trimming is impossible without change of data,
- * it is BUG().
+/* Trims skb to length len. It can change skb pointers.
*/
-int ___pskb_trim(struct sk_buff *skb, unsigned int len, int realloc)
+int ___pskb_trim(struct sk_buff *skb, unsigned int len)
{
+ struct sk_buff **fragp;
+ struct sk_buff *frag;
int offset = skb_headlen(skb);
int nfrags = skb_shinfo(skb)->nr_frags;
int i;
+ int err;
- for (i = 0; i < nfrags; i++) {
+ if (skb_cloned(skb) &&
+ unlikely((err = pskb_expand_head(skb, 0, 0, GFP_ATOMIC))))
+ return err;
+
+ i = 0;
+ if (offset >= len)
+ goto drop_pages;
+
+ for (; i < nfrags; i++) {
int end = offset + skb_shinfo(skb)->frags[i].size;
- if (end > len) {
- if (skb_cloned(skb)) {
- BUG_ON(!realloc);
- if (pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
- return -ENOMEM;
- }
- if (len <= offset) {
- put_page(skb_shinfo(skb)->frags[i].page);
- skb_shinfo(skb)->nr_frags--;
- } else {
- skb_shinfo(skb)->frags[i].size = len - offset;
- }
+
+ if (end < len) {
+ offset = end;
+ continue;
+ }
+
+ skb_shinfo(skb)->frags[i++].size = len - offset;
+
+drop_pages:
+ skb_shinfo(skb)->nr_frags = i;
+
+ for (; i < nfrags; i++)
+ put_page(skb_shinfo(skb)->frags[i].page);
+
+ if (skb_shinfo(skb)->frag_list)
+ skb_drop_fraglist(skb);
+ goto done;
+ }
+
+ for (fragp = &skb_shinfo(skb)->frag_list; (frag = *fragp);
+ fragp = &frag->next) {
+ int end = offset + frag->len;
+
+ if (skb_shared(frag)) {
+ struct sk_buff *nfrag;
+
+ nfrag = skb_clone(frag, GFP_ATOMIC);
+ if (unlikely(!nfrag))
+ return -ENOMEM;
+
+ nfrag->next = frag->next;
+ kfree_skb(frag);
+ frag = nfrag;
+ *fragp = frag;
}
- offset = end;
+
+ if (end < len) {
+ offset = end;
+ continue;
+ }
+
+ if (end > len &&
+ unlikely((err = pskb_trim(frag, len - offset))))
+ return err;
+
+ if (frag->next)
+ skb_drop_list(&frag->next);
+ break;
}
- if (offset < len) {
+done:
+ if (len > skb_headlen(skb)) {
skb->data_len -= skb->len - len;
skb->len = len;
} else {
- if (len <= skb_headlen(skb)) {
- skb->len = len;
- skb->data_len = 0;
- skb->tail = skb->data + len;
- if (skb_shinfo(skb)->frag_list && !skb_cloned(skb))
- skb_drop_fraglist(skb);
- } else {
- skb->data_len -= skb->len - len;
- skb->len = len;
- }
+ skb->len = len;
+ skb->data_len = 0;
+ skb->tail = skb->data + len;
}
return 0;
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Thomas Andrews <[email protected]>
Fix the scx200_acb state machine:
* Nack was sent one byte too late on reads >= 2 bytes.
* Stop bit was set one byte too late on reads.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/i2c/busses/scx200_acb.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- linux-2.6.17.7.orig/drivers/i2c/busses/scx200_acb.c
+++ linux-2.6.17.7/drivers/i2c/busses/scx200_acb.c
@@ -181,21 +181,21 @@ static void scx200_acb_machine(struct sc
break;
case state_read:
- /* Set ACK if receiving the last byte */
- if (iface->len == 1)
+ /* Set ACK if _next_ byte will be the last one */
+ if (iface->len == 2)
outb(inb(ACBCTL1) | ACBCTL1_ACK, ACBCTL1);
else
outb(inb(ACBCTL1) & ~ACBCTL1_ACK, ACBCTL1);
- *iface->ptr++ = inb(ACBSDA);
- --iface->len;
-
- if (iface->len == 0) {
+ if (iface->len == 1) {
iface->result = 0;
iface->state = state_idle;
outb(inb(ACBCTL1) | ACBCTL1_STOP, ACBCTL1);
}
+ *iface->ptr++ = inb(ACBSDA);
+ --iface->len;
+
break;
case state_write:
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Stephen Hemminger <[email protected]>
If the sky2 driver decides to defer processing because it's NAPI
packet quota is done, then it won't correctly handle the rest
when it is rescheduled.
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/sky2.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- linux-2.6.17.7.orig/drivers/net/sky2.c
+++ linux-2.6.17.7/drivers/net/sky2.c
@@ -2187,9 +2187,6 @@ static int sky2_poll(struct net_device *
int work_done = 0;
u32 status = sky2_read32(hw, B0_Y2_SP_EISR);
- if (!~status)
- goto out;
-
if (status & Y2_IS_HW_ERR)
sky2_hw_intr(hw);
@@ -2226,7 +2223,7 @@ static int sky2_poll(struct net_device *
if (sky2_more_work(hw))
return 1;
-out:
+
netif_rx_complete(dev0);
sky2_read32(hw, B0_Y2_SP_LISR);
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Stefan Richter <[email protected]>
At least Maxtor OneTouch III require a "start stop unit" command after
auto spin-down before the next access can proceed. This patch activates
the responsible code in scsi_mod for all Maxtor SBP-2 disks.
https://bugzilla.novell.com/show_bug.cgi?id=183011
Maybe that should be done for all SBP-2 disks, but better be cautious.
Signed-off-by: Stefan Richter <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/ieee1394/sbp2.c | 3 +++
1 file changed, 3 insertions(+)
--- linux-2.6.17.7.orig/drivers/ieee1394/sbp2.c
+++ linux-2.6.17.7/drivers/ieee1394/sbp2.c
@@ -2541,6 +2541,9 @@ static int sbp2scsi_slave_configure(stru
sdev->skip_ms_page_8 = 1;
if (scsi_id->workarounds & SBP2_WORKAROUND_FIX_CAPACITY)
sdev->fix_capacity = 1;
+ if (scsi_id->ne->guid_vendor_id == 0x0010b9 && /* Maxtor's OUI */
+ (sdev->type == TYPE_DISK || sdev->type == TYPE_RBC))
+ sdev->allow_restart = 1;
return 0;
}
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Neil Brown <[email protected]>
Fix race related problem when adding items to and svcrpc auth cache.
If we don't find the item we are lookng for, we allocate a new one,
and then grab the lock again and search to see if it has been added
while we did the alloc.
If it had been added we need to 'cache_put' the newly created item
that we are never going to use. But as it hasn't been initialised
properly, putting it can cause an oops.
So move the ->init call earlier to that it will always be fully
initilised if we have to put it.
Thanks to Philipp Matthias Hahn <[email protected]>
for reporting the problem.
Signed-off-by: Neil Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sunrpc/cache.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- linux-2.6.17.7.orig/net/sunrpc/cache.c
+++ linux-2.6.17.7/net/sunrpc/cache.c
@@ -71,7 +71,12 @@ struct cache_head *sunrpc_cache_lookup(s
new = detail->alloc();
if (!new)
return NULL;
+ /* must fully initialise 'new', else
+ * we might get lose if we need to
+ * cache_put it soon.
+ */
cache_init(new);
+ detail->init(new, key);
write_lock(&detail->hash_lock);
@@ -85,7 +90,6 @@ struct cache_head *sunrpc_cache_lookup(s
return tmp;
}
}
- detail->init(new, key);
new->next = *head;
*head = new;
detail->entries++;
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Andrew Morton <[email protected]>
[PATCH] cond_resched() fix
Fix a bug identified by Zou Nan hai <[email protected]>:
If the system is in state SYSTEM_BOOTING, and need_resched() is true,
cond_resched() returns true even though it didn't reschedule. Consequently
need_resched() remains true and JBD locks up.
Fix that by teaching cond_resched() to only return true if it really did call
schedule().
cond_resched_lock() and cond_resched_softirq() have a problem too. If we're
in SYSTEM_BOOTING state and need_resched() is true, these functions will drop
the lock and will then try to call schedule(), but the SYSTEM_BOOTING state
will prevent schedule() from being called. So on return, need_resched() will
still be true, but cond_resched_lock() has to return 1 to tell the caller that
the lock was dropped. The caller will probably lock up.
Bottom line: if these functions dropped the lock, they _must_ call schedule()
to clear need_resched(). Make it so.
Also, uninline __cond_resched(). It's largeish, and slowpath.
Acked-by: Ingo Molnar <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/sched.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
--- linux-2.6.17.7.orig/kernel/sched.c
+++ linux-2.6.17.7/kernel/sched.c
@@ -4044,17 +4044,22 @@ asmlinkage long sys_sched_yield(void)
return 0;
}
-static inline void __cond_resched(void)
+static inline int __resched_legal(int expected_preempt_count)
+{
+ if (unlikely(preempt_count() != expected_preempt_count))
+ return 0;
+ if (unlikely(system_state != SYSTEM_RUNNING))
+ return 0;
+ return 1;
+}
+
+static void __cond_resched(void)
{
/*
* The BKS might be reacquired before we have dropped
* PREEMPT_ACTIVE, which could trigger a second
* cond_resched() call.
*/
- if (unlikely(preempt_count()))
- return;
- if (unlikely(system_state != SYSTEM_RUNNING))
- return;
do {
add_preempt_count(PREEMPT_ACTIVE);
schedule();
@@ -4064,13 +4069,12 @@ static inline void __cond_resched(void)
int __sched cond_resched(void)
{
- if (need_resched()) {
+ if (need_resched() && __resched_legal(0)) {
__cond_resched();
return 1;
}
return 0;
}
-
EXPORT_SYMBOL(cond_resched);
/*
@@ -4091,7 +4095,7 @@ int cond_resched_lock(spinlock_t *lock)
ret = 1;
spin_lock(lock);
}
- if (need_resched()) {
+ if (need_resched() && __resched_legal(1)) {
_raw_spin_unlock(lock);
preempt_enable_no_resched();
__cond_resched();
@@ -4100,14 +4104,13 @@ int cond_resched_lock(spinlock_t *lock)
}
return ret;
}
-
EXPORT_SYMBOL(cond_resched_lock);
int __sched cond_resched_softirq(void)
{
BUG_ON(!in_softirq());
- if (need_resched()) {
+ if (need_resched() && __resched_legal(0)) {
__local_bh_enable();
__cond_resched();
local_bh_disable();
@@ -4115,10 +4118,8 @@ int __sched cond_resched_softirq(void)
}
return 0;
}
-
EXPORT_SYMBOL(cond_resched_softirq);
-
/**
* yield - yield the current processor to other threads.
*
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Paul Fulghum <[email protected]>
Serialize processing of tty buffers in flush_to_ldisc
to fix (very rare) corruption of tty buffer free list
on SMP systems.
Signed-off-by: Paul Fulghum <[email protected]>
Acked-by: Alan Cox <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/tty_io.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
--- linux-2.6.17.7.orig/drivers/char/tty_io.c
+++ linux-2.6.17.7/drivers/char/tty_io.c
@@ -2776,7 +2776,7 @@ static void flush_to_ldisc(void *private
struct tty_struct *tty = (struct tty_struct *) private_;
unsigned long flags;
struct tty_ldisc *disc;
- struct tty_buffer *tbuf;
+ struct tty_buffer *tbuf, *head;
int count;
char *char_buf;
unsigned char *flag_buf;
@@ -2793,7 +2793,9 @@ static void flush_to_ldisc(void *private
goto out;
}
spin_lock_irqsave(&tty->buf.lock, flags);
- while((tbuf = tty->buf.head) != NULL) {
+ head = tty->buf.head;
+ tty->buf.head = NULL;
+ while((tbuf = head) != NULL) {
while ((count = tbuf->commit - tbuf->read) != 0) {
char_buf = tbuf->char_buf_ptr + tbuf->read;
flag_buf = tbuf->flag_buf_ptr + tbuf->read;
@@ -2802,10 +2804,12 @@ static void flush_to_ldisc(void *private
disc->receive_buf(tty, char_buf, flag_buf, count);
spin_lock_irqsave(&tty->buf.lock, flags);
}
- if (tbuf->active)
+ if (tbuf->active) {
+ tty->buf.head = head;
break;
- tty->buf.head = tbuf->next;
- if (tty->buf.head == NULL)
+ }
+ head = tbuf->next;
+ if (head == NULL)
tty->buf.tail = NULL;
tty_buffer_free(tty, tbuf);
}
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Steven Rostedt <[email protected]>
While helping someone to submit a patch to the stable branch, I noticed
that the stable branch is not listed in the MAINTAINERS file. This was
after I went there to look for the email addresses for the stable branch
list ([email protected]).
This patch adds the stable branch to the maintainers file so that people
can find where to send patches when they have a fix for the stable team.
Signed-off-by: Steven Rostedt <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
--- linux-2.6.17.7.orig/MAINTAINERS
+++ linux-2.6.17.7/MAINTAINERS
@@ -2572,6 +2572,14 @@ M: [email protected]
L: [email protected]
S: Maintained
+STABLE BRANCH:
+P: Greg Kroah-Hartman
+M: [email protected]
+P: Chris Wright
+M: [email protected]
+L: [email protected]
+S: Maintained
+
TPM DEVICE DRIVER
P: Kylene Hall
M: [email protected]
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Andrew de Quincey <[email protected]>
Currently I am doing lots of refactoring work in the dvb tree. This
bugfix became necessary to fix 2.6.17 whilst I was in the middle of this
work. Unfortunately after I tested the original code for the patch, I
generated the diff against the wrong tree (I accidentally used a tree
with part of the refactoring code in it). This resulted in the reported
compile errors because that tree (a) was incomplete, and (b) used
features which are simply not in the mainline kernel yet.
Many apologies for the error and problems this has caused. :(
Signed-off-by: Andrew de Quincey <[email protected]>
Signed-off-by: Michael Krufky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/dvb/ttpci/budget-av.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- linux-2.6.17.7.orig/drivers/media/dvb/ttpci/budget-av.c
+++ linux-2.6.17.7/drivers/media/dvb/ttpci/budget-av.c
@@ -58,6 +58,7 @@ struct budget_av {
struct tasklet_struct ciintf_irq_tasklet;
int slot_status;
struct dvb_ca_en50221 ca;
+ u8 reinitialise_demod:1;
};
/* GPIO Connections:
@@ -214,8 +215,9 @@ static int ciintf_slot_reset(struct dvb_
while (--timeout > 0 && ciintf_read_attribute_mem(ca, slot, 0) != 0x1d)
msleep(100);
- /* reinitialise the frontend */
- dvb_frontend_reinitialise(budget_av->budget.dvb_frontend);
+ /* reinitialise the frontend if necessary */
+ if (budget_av->reinitialise_demod)
+ dvb_frontend_reinitialise(budget_av->budget.dvb_frontend);
if (timeout <= 0)
{
@@ -1064,12 +1066,10 @@ static void frontend_init(struct budget_
fe = tda10021_attach(&philips_cu1216_config,
&budget_av->budget.i2c_adap,
read_pwm(budget_av));
- if (fe) {
- fe->ops.tuner_ops.set_params = philips_cu1216_tuner_set_params;
- }
break;
case SUBID_DVBC_KNC1_PLUS:
+ budget_av->reinitialise_demod = 1;
fe = tda10021_attach(&philips_cu1216_config,
&budget_av->budget.i2c_adap,
read_pwm(budget_av));
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Neil Brown <[email protected]>
This prevents bad inode numbers from triggering errors in
ext2_get_inode.
Signed-off-by: Neil Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ext2/super.c | 41 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
--- linux-2.6.17.7.orig/fs/ext2/super.c
+++ linux-2.6.17.7/fs/ext2/super.c
@@ -252,6 +252,46 @@ static struct super_operations ext2_sops
#endif
};
+static struct dentry *ext2_get_dentry(struct super_block *sb, void *vobjp)
+{
+ __u32 *objp = vobjp;
+ unsigned long ino = objp[0];
+ __u32 generation = objp[1];
+ struct inode *inode;
+ struct dentry *result;
+
+ if (ino != EXT2_ROOT_INO && ino < EXT2_FIRST_INO(sb))
+ return ERR_PTR(-ESTALE);
+ if (ino > le32_to_cpu(EXT2_SB(sb)->s_es->s_inodes_count))
+ return ERR_PTR(-ESTALE);
+
+ /* iget isn't really right if the inode is currently unallocated!!
+ * ext2_read_inode currently does appropriate checks, but
+ * it might be "neater" to call ext2_get_inode first and check
+ * if the inode is valid.....
+ */
+ inode = iget(sb, ino);
+ if (inode == NULL)
+ return ERR_PTR(-ENOMEM);
+ if (is_bad_inode(inode)
+ || (generation && inode->i_generation != generation)
+ ) {
+ /* we didn't find the right inode.. */
+ iput(inode);
+ return ERR_PTR(-ESTALE);
+ }
+ /* now to find a dentry.
+ * If possible, get a well-connected one
+ */
+ result = d_alloc_anon(inode);
+ if (!result) {
+ iput(inode);
+ return ERR_PTR(-ENOMEM);
+ }
+ return result;
+}
+
+
/* Yes, most of these are left as NULL!!
* A NULL value implies the default, which works with ext2-like file
* systems, but can be improved upon.
@@ -259,6 +299,7 @@ static struct super_operations ext2_sops
*/
static struct export_operations ext2_export_ops = {
.get_parent = ext2_get_parent,
+ .get_dentry = ext2_get_dentry,
};
static unsigned long get_sb_block(void **data)
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Badari Pulavarty <[email protected]>
For files other than IFREG, nobh option doesn't make sense. Modifications
to them are journalled and needs buffer heads to do that. Without this
patch, we get kernel oops in page_buffers().
Signed-off-by: Badari Pulavarty <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ext3/inode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.17.7.orig/fs/ext3/inode.c
+++ linux-2.6.17.7/fs/ext3/inode.c
@@ -1159,7 +1159,7 @@ retry:
ret = PTR_ERR(handle);
goto out;
}
- if (test_opt(inode->i_sb, NOBH))
+ if (test_opt(inode->i_sb, NOBH) && ext3_should_writeback_data(inode))
ret = nobh_prepare_write(page, from, to, ext3_get_block);
else
ret = block_prepare_write(page, from, to, ext3_get_block);
@@ -1245,7 +1245,7 @@ static int ext3_writeback_commit_write(s
if (new_i_size > EXT3_I(inode)->i_disksize)
EXT3_I(inode)->i_disksize = new_i_size;
- if (test_opt(inode->i_sb, NOBH))
+ if (test_opt(inode->i_sb, NOBH) && ext3_should_writeback_data(inode))
ret = nobh_commit_write(file, page, from, to);
else
ret = generic_commit_write(file, page, from, to);
@@ -1495,7 +1495,7 @@ static int ext3_writeback_writepage(stru
goto out_fail;
}
- if (test_opt(inode->i_sb, NOBH))
+ if (test_opt(inode->i_sb, NOBH) && ext3_should_writeback_data(inode))
ret = nobh_writepage(page, ext3_get_block, wbc);
else
ret = block_write_full_page(page, ext3_get_block, wbc);
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Neil Brown <[email protected]>
The inode number out of an NFS file handle gets passed eventually to
ext3_get_inode_block() without any checking. If ext3_get_inode_block()
allows it to trigger an error, then bad filehandles can have unpleasant
effect - ext3_error() will usually cause a forced read-only remount, or a
panic if `errors=panic' was used.
So remove the call to ext3_error there and put a matching check in
ext3/namei.c where inode numbers are read off storage.
[[email protected]: fix off-by-one error]
Signed-off-by: Neil Brown <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Cc: Marcel Holtmann <[email protected]>
Cc: "Stephen C. Tweedie" <[email protected]>
Cc: Eric Sandeen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ext3/inode.c | 13 +++++++------
fs/ext3/namei.c | 15 +++++++++++++--
include/linux/ext3_fs.h | 9 +++++++++
3 files changed, 29 insertions(+), 8 deletions(-)
--- linux-2.6.17.7.orig/fs/ext3/inode.c
+++ linux-2.6.17.7/fs/ext3/inode.c
@@ -2402,14 +2402,15 @@ static unsigned long ext3_get_inode_bloc
struct buffer_head *bh;
struct ext3_group_desc * gdp;
-
- if ((ino != EXT3_ROOT_INO && ino != EXT3_JOURNAL_INO &&
- ino != EXT3_RESIZE_INO && ino < EXT3_FIRST_INO(sb)) ||
- ino > le32_to_cpu(EXT3_SB(sb)->s_es->s_inodes_count)) {
- ext3_error(sb, "ext3_get_inode_block",
- "bad inode number: %lu", ino);
+ if (!ext3_valid_inum(sb, ino)) {
+ /*
+ * This error is already checked for in namei.c unless we are
+ * looking at an NFS filehandle, in which case no error
+ * report is needed
+ */
return 0;
}
+
block_group = (ino - 1) / EXT3_INODES_PER_GROUP(sb);
if (block_group >= EXT3_SB(sb)->s_groups_count) {
ext3_error(sb,"ext3_get_inode_block","group >= groups count");
--- linux-2.6.17.7.orig/fs/ext3/namei.c
+++ linux-2.6.17.7/fs/ext3/namei.c
@@ -1000,7 +1000,12 @@ static struct dentry *ext3_lookup(struct
if (bh) {
unsigned long ino = le32_to_cpu(de->inode);
brelse (bh);
- inode = iget(dir->i_sb, ino);
+ if (!ext3_valid_inum(dir->i_sb, ino)) {
+ ext3_error(dir->i_sb, "ext3_lookup",
+ "bad inode number: %lu", ino);
+ inode = NULL;
+ } else
+ inode = iget(dir->i_sb, ino);
if (!inode)
return ERR_PTR(-EACCES);
@@ -1028,7 +1033,13 @@ struct dentry *ext3_get_parent(struct de
return ERR_PTR(-ENOENT);
ino = le32_to_cpu(de->inode);
brelse(bh);
- inode = iget(child->d_inode->i_sb, ino);
+
+ if (!ext3_valid_inum(child->d_inode->i_sb, ino)) {
+ ext3_error(child->d_inode->i_sb, "ext3_get_parent",
+ "bad inode number: %lu", ino);
+ inode = NULL;
+ } else
+ inode = iget(child->d_inode->i_sb, ino);
if (!inode)
return ERR_PTR(-EACCES);
--- linux-2.6.17.7.orig/include/linux/ext3_fs.h
+++ linux-2.6.17.7/include/linux/ext3_fs.h
@@ -495,6 +495,15 @@ static inline struct ext3_inode_info *EX
{
return container_of(inode, struct ext3_inode_info, vfs_inode);
}
+
+static inline int ext3_valid_inum(struct super_block *sb, unsigned long ino)
+{
+ return ino == EXT3_ROOT_INO ||
+ ino == EXT3_JOURNAL_INO ||
+ ino == EXT3_RESIZE_INO ||
+ (ino >= EXT3_FIRST_INO(sb) &&
+ ino <= le32_to_cpu(EXT3_SB(sb)->s_es->s_inodes_count));
+}
#else
/* Assume that user mode programs are passing in an ext3fs superblock, not
* a kernel struct super_block. This will allow us to call the feature-test
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: David Miller <[email protected]>
[SPARC64]: Fix quad-float multiply emulation.
Something is wrong with the 3-multiply (vs. 4-multiply) optimized
version of _FP_MUL_MEAT_2_*(), so just use the slower version
which actually computes correct values.
Noticed by Rene Rebe
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/asm-sparc64/sfp-machine.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.17.7.orig/include/asm-sparc64/sfp-machine.h
+++ linux-2.6.17.7/include/asm-sparc64/sfp-machine.h
@@ -34,7 +34,7 @@
#define _FP_MUL_MEAT_D(R,X,Y) \
_FP_MUL_MEAT_1_wide(_FP_WFRACBITS_D,R,X,Y,umul_ppmm)
#define _FP_MUL_MEAT_Q(R,X,Y) \
- _FP_MUL_MEAT_2_wide_3mul(_FP_WFRACBITS_Q,R,X,Y,umul_ppmm)
+ _FP_MUL_MEAT_2_wide(_FP_WFRACBITS_Q,R,X,Y,umul_ppmm)
#define _FP_DIV_MEAT_S(R,X,Y) _FP_DIV_MEAT_1_imm(S,R,X,Y,_FP_DIV_HELP_imm)
#define _FP_DIV_MEAT_D(R,X,Y) _FP_DIV_MEAT_1_udiv_norm(D,R,X,Y)
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Auke Kok <[email protected]>
The Intel(R) PRO/1000 82572EI card is fully supported by 7.0.33-k2 and
onward. Add the device ID so this card works with 2.6.17.y onward. This
device ID was accidentally omitted.
Signed-off-by: Auke Kok <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/e1000/e1000_hw.c | 1 +
drivers/net/e1000/e1000_hw.h | 1 +
2 files changed, 2 insertions(+)
--- linux-2.6.17.7.orig/drivers/net/e1000/e1000_hw.c
+++ linux-2.6.17.7/drivers/net/e1000/e1000_hw.c
@@ -353,6 +353,7 @@ e1000_set_mac_type(struct e1000_hw *hw)
case E1000_DEV_ID_82572EI_COPPER:
case E1000_DEV_ID_82572EI_FIBER:
case E1000_DEV_ID_82572EI_SERDES:
+ case E1000_DEV_ID_82572EI:
hw->mac_type = e1000_82572;
break;
case E1000_DEV_ID_82573E:
--- linux-2.6.17.7.orig/drivers/net/e1000/e1000_hw.h
+++ linux-2.6.17.7/drivers/net/e1000/e1000_hw.h
@@ -462,6 +462,7 @@ int32_t e1000_check_phy_reset_block(stru
#define E1000_DEV_ID_82572EI_COPPER 0x107D
#define E1000_DEV_ID_82572EI_FIBER 0x107E
#define E1000_DEV_ID_82572EI_SERDES 0x107F
+#define E1000_DEV_ID_82572EI 0x10B9
#define E1000_DEV_ID_82573E 0x108B
#define E1000_DEV_ID_82573E_IAMT 0x108C
#define E1000_DEV_ID_82573L 0x109A
--
-stable review patch. If anyone has any objections, please let us know.
------------------
[S390] fix futex_atomic_cmpxchg_inatomic
futex_atomic_cmpxchg_inatomic has the same bug as the other
atomic futex operations: the operation needs to be done in the
user address space, not the kernel address space. Add the missing
sacf 256 & sacf 0.
Signed-off-by: Martin Schwidefsky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/asm-s390/futex.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- linux-2.6.17.7.orig/include/asm-s390/futex.h
+++ linux-2.6.17.7/include/asm-s390/futex.h
@@ -98,9 +98,10 @@ futex_atomic_cmpxchg_inatomic(int __user
if (! access_ok (VERIFY_WRITE, uaddr, sizeof(int)))
return -EFAULT;
- asm volatile(" cs %1,%4,0(%5)\n"
+ asm volatile(" sacf 256\n"
+ " cs %1,%4,0(%5)\n"
"0: lr %0,%1\n"
- "1:\n"
+ "1: sacf 0\n"
#ifndef __s390x__
".section __ex_table,\"a\"\n"
" .align 4\n"
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jean Delvare <[email protected]>
The scx200_acb i2c bus driver pretends to support SMBus block
transactions, but in fact it implements the more simple I2C block
transactions. Additionally, it lacks sanity checks on the length
of the block transactions, which could lead to a buffer overrun.
This fixes an oops reported by Alexander Atanasov:
http://marc.theaimsgroup.com/?l=linux-kernel&m=114970382125094
Thanks to Ben Gardner for fixing my bugs :)
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/i2c/busses/scx200_acb.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- linux-2.6.17.7.orig/drivers/i2c/busses/scx200_acb.c
+++ linux-2.6.17.7/drivers/i2c/busses/scx200_acb.c
@@ -304,8 +304,12 @@ static s32 scx200_acb_smbus_xfer(struct
buffer = (u8 *)&cur_word;
break;
- case I2C_SMBUS_BLOCK_DATA:
+ case I2C_SMBUS_I2C_BLOCK_DATA:
+ if (rw == I2C_SMBUS_READ)
+ data->block[0] = I2C_SMBUS_BLOCK_MAX; /* For now */
len = data->block[0];
+ if (len == 0 || len > I2C_SMBUS_BLOCK_MAX)
+ return -EINVAL;
buffer = &data->block[1];
break;
@@ -369,7 +373,7 @@ static u32 scx200_acb_func(struct i2c_ad
{
return I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE |
I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA |
- I2C_FUNC_SMBUS_BLOCK_DATA;
+ I2C_FUNC_SMBUS_I2C_BLOCK;
}
/* For now, we only handle combined mode (smbus) */
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Andrew Morton <[email protected]>
We can immediately bale from invalidate_bdev() if the blockdev has no
pagecache.
This solves the huge IPI storms which hald is causing on the big ia64
machines when it polls CDROM drives.
Acked-by: Jes Sorensen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/buffer.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- linux-2.6.17.7.orig/fs/buffer.c
+++ linux-2.6.17.7/fs/buffer.c
@@ -473,13 +473,18 @@ out:
pass does the actual I/O. */
void invalidate_bdev(struct block_device *bdev, int destroy_dirty_buffers)
{
+ struct address_space *mapping = bdev->bd_inode->i_mapping;
+
+ if (mapping->nrpages == 0)
+ return;
+
invalidate_bh_lrus();
/*
* FIXME: what about destroy_dirty_buffers?
* We really want to use invalidate_inode_pages2() for
* that, but not until that's cleaned up.
*/
- invalidate_inode_pages(bdev->bd_inode->i_mapping);
+ invalidate_inode_pages(mapping);
}
/*
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
This patch (as753) fixes the way uhci-hcd handles a short packet when it
is the last packet of an URB. Right now the driver handles short packets
the same no matter when they occur. However, the controller stops
transferring packets when the short packet is not the last one (otherwise
it would be reading beyond the end of the device's data) and needs to be
restarted, whereas no such need occurs when the short packet is the last
one.
The result of the bug is that USB endpoint queues experience intermittent
hangs, a regression in 2.6.17 with respect to earlier kernels. The bug
was raised in Bugzilla #6752 and this patch fixed it.
Signed-off-by: Alan Stern <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/uhci-q.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- linux-2.6.17.7.orig/drivers/usb/host/uhci-q.c
+++ linux-2.6.17.7/drivers/usb/host/uhci-q.c
@@ -896,12 +896,14 @@ static int uhci_result_common(struct uhc
/*
* This URB stopped short of its end. We have to
* fix up the toggles of the following URBs on the
- * queue and restart the queue.
+ * queue and restart the queue. But only if this
+ * TD isn't the last one in the URB.
*
* Do this only the first time we encounter the
* short URB.
*/
- if (!urbp->short_transfer) {
+ if (!urbp->short_transfer &&
+ &td->list != urbp->td_list.prev) {
urbp->short_transfer = 1;
urbp->qh->initial_toggle =
uhci_toggle(td_token(td)) ^ 1;
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Stefan Rompf <[email protected]>
[VLAN]: Fix link state propagation
When the queue of the underlying device is stopped at initialization time
or the device is marked "not present", the state will be propagated to the
vlan device and never change. Based on an analysis by Patrick McHardy.
Signed-off-by: Stefan Rompf <[email protected]>
ACKed-by: Patrick McHardy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/8021q/vlan.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- linux-2.6.17.7.orig/net/8021q/vlan.c
+++ linux-2.6.17.7/net/8021q/vlan.c
@@ -67,10 +67,6 @@ static struct packet_type vlan_packet_ty
.func = vlan_skb_recv, /* VLAN receive method */
};
-/* Bits of netdev state that are propagated from real device to virtual */
-#define VLAN_LINK_STATE_MASK \
- ((1<<__LINK_STATE_PRESENT)|(1<<__LINK_STATE_NOCARRIER)|(1<<__LINK_STATE_DORMANT))
-
/* End of global variables definitions. */
/*
@@ -470,7 +466,9 @@ static struct net_device *register_vlan_
new_dev->flags = real_dev->flags;
new_dev->flags &= ~IFF_UP;
- new_dev->state = real_dev->state & ~(1<<__LINK_STATE_START);
+ new_dev->state = (real_dev->state & ((1<<__LINK_STATE_NOCARRIER) |
+ (1<<__LINK_STATE_DORMANT))) |
+ (1<<__LINK_STATE_PRESENT);
/* need 4 bytes for extra VLAN header info,
* hope the underlying device can handle it.
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Marcel Holtmann <[email protected]>
Don't allow chmod() on the /proc/<pid>/ files
This just turns off chmod() on the /proc/<pid>/ files, since there is no
good reason to allow it, and had we disallowed it originally, the nasty
/proc race exploit wouldn't have been possible.
The other patches already fixed the problem chmod() could cause, so this
is really just some final mop-up..
This particular version is based off a patch by Eugene and Marcel which
had much better naming than my original equivalent one.
Signed-off-by: Eugene Teo <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/proc/base.c | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
--- linux-2.6.17.7.orig/fs/proc/base.c
+++ linux-2.6.17.7/fs/proc/base.c
@@ -596,6 +596,27 @@ static int proc_permission(struct inode
return proc_check_root(inode);
}
+static int proc_setattr(struct dentry *dentry, struct iattr *attr)
+{
+ int error;
+ struct inode *inode = dentry->d_inode;
+
+ if (attr->ia_valid & ATTR_MODE)
+ return -EPERM;
+
+ error = inode_change_ok(inode, attr);
+ if (!error) {
+ error = security_inode_setattr(dentry, attr);
+ if (!error)
+ error = inode_setattr(inode, attr);
+ }
+ return error;
+}
+
+static struct inode_operations proc_def_inode_operations = {
+ .setattr = proc_setattr,
+};
+
static int proc_task_permission(struct inode *inode, int mask, struct nameidata *nd)
{
struct dentry *root;
@@ -987,6 +1008,7 @@ static struct file_operations proc_oom_a
static struct inode_operations proc_mem_inode_operations = {
.permission = proc_permission,
+ .setattr = proc_setattr,
};
#ifdef CONFIG_AUDITSYSCALL
@@ -1184,7 +1206,8 @@ out:
static struct inode_operations proc_pid_link_inode_operations = {
.readlink = proc_pid_readlink,
- .follow_link = proc_pid_follow_link
+ .follow_link = proc_pid_follow_link,
+ .setattr = proc_setattr,
};
#define NUMBUF 10
@@ -1356,6 +1379,7 @@ static struct inode *proc_pid_make_inode
ei->task = NULL;
inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
inode->i_ino = fake_ino(task->pid, ino);
+ inode->i_op = &proc_def_inode_operations;
if (!pid_alive(task))
goto out_unlock;
@@ -1579,11 +1603,13 @@ static struct file_operations proc_task_
static struct inode_operations proc_fd_inode_operations = {
.lookup = proc_lookupfd,
.permission = proc_permission,
+ .setattr = proc_setattr,
};
static struct inode_operations proc_task_inode_operations = {
.lookup = proc_task_lookup,
.permission = proc_task_permission,
+ .setattr = proc_setattr,
};
#ifdef CONFIG_SECURITY
@@ -1873,10 +1899,12 @@ static struct file_operations proc_tid_b
static struct inode_operations proc_tgid_base_inode_operations = {
.lookup = proc_tgid_base_lookup,
+ .setattr = proc_setattr,
};
static struct inode_operations proc_tid_base_inode_operations = {
.lookup = proc_tid_base_lookup,
+ .setattr = proc_setattr,
};
#ifdef CONFIG_SECURITY
@@ -1918,10 +1946,12 @@ static struct dentry *proc_tid_attr_look
static struct inode_operations proc_tgid_attr_inode_operations = {
.lookup = proc_tgid_attr_lookup,
+ .setattr = proc_setattr,
};
static struct inode_operations proc_tid_attr_inode_operations = {
.lookup = proc_tid_attr_lookup,
+ .setattr = proc_setattr,
};
#endif
@@ -1946,6 +1976,7 @@ static void *proc_self_follow_link(struc
static struct inode_operations proc_self_inode_operations = {
.readlink = proc_self_readlink,
.follow_link = proc_self_follow_link,
+ .setattr = proc_setattr,
};
/**
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: "Mark M. Hoffman" <[email protected]>
This patch fixes a bug in the handling of 'ignore' module parameters of I2C
client drivers.
Signed-off-by: Mark M. Hoffman <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/i2c/i2c-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.17.7.orig/drivers/i2c/i2c-core.c
+++ linux-2.6.17.7/drivers/i2c/i2c-core.c
@@ -756,9 +756,9 @@ int i2c_probe(struct i2c_adapter *adapte
"parameter for adapter %d, "
"addr 0x%02x\n", adap_id,
address_data->ignore[j + 1]);
+ ignore = 1;
+ break;
}
- ignore = 1;
- break;
}
if (ignore)
continue;
--
On Thu, 3 Aug 2006 22:38:07 -0700, Greg KH <[email protected]> wrote:
>This is the start of the stable review cycle for the 2.6.17.8 release.
>There are 23 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 Sunday, August 6, 05:00:00 UTC. Anything
>received after that time might be too late.
>
>I've also posted a roll-up patch with all changes in it if people want
>to test it out. It can be found at:
>
> kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz
It wasn't clear that this is a delta 2.6.17.7 -> 2.6.17.8 patch ;)
Didn't bump version:
grant@sempro:~/linux/linux-2.6.17.8-rc1$ head -5 Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 17
EXTRAVERSION = .7
NAME=Crazed Snow-Weasel
On the bright side, it compiled and runs ;)
Grant.
On Fri, Aug 04, 2006 at 05:18:44PM +1000, Grant Coady wrote:
> On Thu, 3 Aug 2006 22:38:07 -0700, Greg KH <[email protected]> wrote:
> >I've also posted a roll-up patch with all changes in it if people want
> >to test it out. It can be found at:
> >
> > kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz
>
> It wasn't clear that this is a delta 2.6.17.7 -> 2.6.17.8 patch ;)
>
> Didn't bump version:
> grant@sempro:~/linux/linux-2.6.17.8-rc1$ head -5 Makefile
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 17
> EXTRAVERSION = .7
> NAME=Crazed Snow-Weasel
Ugh, you are right, I normally don't bump the version until I commit the
patches to the tree. Sorry about that, I'll fix that up next time.
> On the bright side, it compiled and runs ;)
Great, thanks for testing and letting us know, I really appreciate it.
greg k-h
On Thu, Aug 03, 2006 at 10:39:42PM -0700, Greg KH wrote:
> -stable review patch. If anyone has any objections, please let us know.
This is a feature. Definitly not -stable material.
On 04/08/06, Greg KH <[email protected]> wrote:
> This is the start of the stable review cycle for the 2.6.17.8 release.
> There are 23 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 Sunday, August 6, 05:00:00 UTC. Anything
> received after that time might be too late.
>
> I've also posted a roll-up patch with all changes in it if people want
> to test it out. It can be found at:
>
> kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz
>
Any chance that the fixes in the (latest) e1000 driver version
7.1.9-k4 will get backported?
I can't run 2.6.17.7 on at least one of my servers due to bugs in the
driver that are fixed in the latest e1000 version.
I looked through the -stable patches but didn't find anything that
would fix my problem.
I get messages along the lines of "kernel: Virtual device XXX asks to
queue packet!" and the device then refuses to work.
The last kernel where I know for a fact that it worked OK is 2.6.11,
so that's what the server is currently running.
Getting the fix for that problem backported to -stable would really make my day.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Fri, 4 Aug 2006 09:50:13 +0100
Christoph Hellwig <[email protected]> wrote:
> On Thu, Aug 03, 2006 at 10:39:42PM -0700, Greg KH wrote:
> > -stable review patch. If anyone has any objections, please let us know.
>
> This is a feature. Definitly not -stable material.
Apparently that regular IPI storm is causing the SGI machines some
significant problems. I assume it's the interrupt latency problem again.
Jes would know.
It's not the biggest problem we've ever had, but if this patch is wrong,
the pagecache/buffer_head layer is utterly busted. And it isn't.
Jesper Juhl wrote:
> Any chance that the fixes in the (latest) e1000 driver version
> 7.1.9-k4 will get backported?
>
> I get messages along the lines of "kernel: Virtual device XXX asks to
> queue packet!" and the device then refuses to work.
> The last kernel where I know for a fact that it worked OK is 2.6.11,
> so that's what the server is currently running.
That message should never be seen on a device with a queue. What device
exactly is "XXX"?
On Fri, 4 Aug 2006 11:04:36 +0200
"Jesper Juhl" <[email protected]> wrote:
> On 04/08/06, Greg KH <[email protected]> wrote:
> > This is the start of the stable review cycle for the 2.6.17.8 release.
> > There are 23 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 Sunday, August 6, 05:00:00 UTC. Anything
> > received after that time might be too late.
> >
> > I've also posted a roll-up patch with all changes in it if people want
> > to test it out. It can be found at:
> >
> > kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz
> >
>
> Any chance that the fixes in the (latest) e1000 driver version
> 7.1.9-k4 will get backported?
The post-2.6.17 e1000 changes are massive.
> I can't run 2.6.17.7 on at least one of my servers due to bugs in the
> driver that are fixed in the latest e1000 version.
> I looked through the -stable patches but didn't find anything that
> would fix my problem.
> I get messages along the lines of "kernel: Virtual device XXX asks to
> queue packet!" and the device then refuses to work.
> The last kernel where I know for a fact that it worked OK is 2.6.11,
> so that's what the server is currently running.
>
> Getting the fix for that problem backported to -stable would really make my day.
Perhaps the e1000 developers can help us to identify the particular fix for
this problem.
That's assuming that it is actually fixed. Does 2.6.18-current fix the bug?
On 04/08/06, Patrick McHardy <[email protected]> wrote:
> Jesper Juhl wrote:
> > Any chance that the fixes in the (latest) e1000 driver version
> > 7.1.9-k4 will get backported?
> >
> > I get messages along the lines of "kernel: Virtual device XXX asks to
> > queue packet!" and the device then refuses to work.
> > The last kernel where I know for a fact that it worked OK is 2.6.11,
> > so that's what the server is currently running.
>
> That message should never be seen on a device with a queue. What device
> exactly is "XXX"?
>
eth0.20
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On 04/08/06, Andrew Morton <[email protected]> wrote:
> On Fri, 4 Aug 2006 11:04:36 +0200
> "Jesper Juhl" <[email protected]> wrote:
>
> > On 04/08/06, Greg KH <[email protected]> wrote:
> > > This is the start of the stable review cycle for the 2.6.17.8 release.
> > > There are 23 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 Sunday, August 6, 05:00:00 UTC. Anything
> > > received after that time might be too late.
> > >
> > > I've also posted a roll-up patch with all changes in it if people want
> > > to test it out. It can be found at:
> > >
> > > kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz
> > >
> >
> > Any chance that the fixes in the (latest) e1000 driver version
> > 7.1.9-k4 will get backported?
>
> The post-2.6.17 e1000 changes are massive.
>
I know, I tried backporting the new driver but gave up.
> > I can't run 2.6.17.7 on at least one of my servers due to bugs in the
> > driver that are fixed in the latest e1000 version.
> > I looked through the -stable patches but didn't find anything that
> > would fix my problem.
> > I get messages along the lines of "kernel: Virtual device XXX asks to
> > queue packet!" and the device then refuses to work.
> > The last kernel where I know for a fact that it worked OK is 2.6.11,
> > so that's what the server is currently running.
> >
> > Getting the fix for that problem backported to -stable would really make my day.
>
>
> Perhaps the e1000 developers can help us to identify the particular fix for
> this problem.
>
That's what I was hoping for...
> That's assuming that it is actually fixed. Does 2.6.18-current fix the bug?
>
I tested 2.6.18-rc3-git3 and that did indeed fix the e1000 bug, but I
can't run that kernel since xfs crashes :-( (I've send a sepperate
bug report for that)
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Jesper Juhl wrote:
> On 04/08/06, Patrick McHardy <[email protected]> wrote:
>
>> Jesper Juhl wrote:
>> > Any chance that the fixes in the (latest) e1000 driver version
>> > 7.1.9-k4 will get backported?
>> >
>> > I get messages along the lines of "kernel: Virtual device XXX asks to
>> > queue packet!" and the device then refuses to work.
>> > The last kernel where I know for a fact that it worked OK is 2.6.11,
>> > so that's what the server is currently running.
>>
>> That message should never be seen on a device with a queue. What device
>> exactly is "XXX"?
>>
> eth0.20
This problem is fixed by "[patch 10/23] VLAN state handling fix".
On 04/08/06, Patrick McHardy <[email protected]> wrote:
> Jesper Juhl wrote:
> > On 04/08/06, Patrick McHardy <[email protected]> wrote:
> >
> >> Jesper Juhl wrote:
> >> > Any chance that the fixes in the (latest) e1000 driver version
> >> > 7.1.9-k4 will get backported?
> >> >
> >> > I get messages along the lines of "kernel: Virtual device XXX asks to
> >> > queue packet!" and the device then refuses to work.
> >> > The last kernel where I know for a fact that it worked OK is 2.6.11,
> >> > so that's what the server is currently running.
> >>
> >> That message should never be seen on a device with a queue. What device
> >> exactly is "XXX"?
> >>
> > eth0.20
>
> This problem is fixed by "[patch 10/23] VLAN state handling fix".
>
Ahh, ok, I didn't realize that. That's great news, then there's a
chance that 2.6.17.8 will work for me - I'll certainly test that and
report back. I can't test on that server until monday though, so I
won't be able to test it before 2.6.17.8 is out.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Fri, 2006-08-04 at 02:04 -0700, Andrew Morton wrote:
> On Fri, 4 Aug 2006 09:50:13 +0100
> Christoph Hellwig <[email protected]> wrote:
>
> > On Thu, Aug 03, 2006 at 10:39:42PM -0700, Greg KH wrote:
> > > -stable review patch. If anyone has any objections, please let us know.
> >
> > This is a feature. Definitly not -stable material.
>
> Apparently that regular IPI storm is causing the SGI machines some
> significant problems.
a tiny performance drop :) If that meets the stable policy.. open
question :)
> It's not the biggest problem we've ever had, but if this patch is wrong,
> the pagecache/buffer_head layer is utterly busted. And it isn't.
are you sure?
+ struct address_space *mapping = bdev->bd_inode->i_mapping;
+
+ if (mapping->nrpages == 0)
+ return;
+
invalidate_bh_lrus();
what happens if a bdev used to have pagecache and at some point stops
having that due to page reclaim... will that page reclaim call
invalidate_bh_lrus() ? If not, who will ? If the answer is "nobody", is
that really the right answer?
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Arjan van de Ven wrote:
> On Fri, 2006-08-04 at 02:04 -0700, Andrew Morton wrote:
>> Apparently that regular IPI storm is causing the SGI machines some
>> significant problems.
>
> a tiny performance drop :) If that meets the stable policy.. open
> question :)
It's visible on any SMP machine, but the more CPUs the worse it gets,
this isn't an SGI only problem. Whether the performance degredation
warrants putting it into stable is another question ....
>> It's not the biggest problem we've ever had, but if this patch is wrong,
>> the pagecache/buffer_head layer is utterly busted. And it isn't.
>
> are you sure?
>
> + struct address_space *mapping = bdev->bd_inode->i_mapping;
> +
> + if (mapping->nrpages == 0)
> + return;
> +
> invalidate_bh_lrus();
>
> what happens if a bdev used to have pagecache and at some point stops
> having that due to page reclaim... will that page reclaim call
> invalidate_bh_lrus() ? If not, who will ? If the answer is "nobody", is
> that really the right answer?
Well what happens if the pagecache doesn't remove the page from the lru
on reclaim and we do a lookup for it later? I'm not an expert in the LRU
usage or page reclaim, but it seems to me we could end up with a stable
reference if that was the case.
Cheers,
Jes
Jesper Juhl wrote:
> On 04/08/06, Andrew Morton <[email protected]> wrote:
>> On Fri, 4 Aug 2006 11:04:36 +0200
>> "Jesper Juhl" <[email protected]> wrote:
>>
>> > On 04/08/06, Greg KH <[email protected]> wrote:
>> > > This is the start of the stable review cycle for the 2.6.17.8
>> release.
>> > > There are 23 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 Sunday, August 6, 05:00:00 UTC. Anything
>> > > received after that time might be too late.
>> > >
>> > > I've also posted a roll-up patch with all changes in it if people
>> want
>> > > to test it out. It can be found at:
>> > >
>> > >
>> kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz
>> > >
>> >
>> > Any chance that the fixes in the (latest) e1000 driver version
>> > 7.1.9-k4 will get backported?
>>
>> The post-2.6.17 e1000 changes are massive.
>>
> I know, I tried backporting the new driver but gave up.
>
>
>> > I can't run 2.6.17.7 on at least one of my servers due to bugs in the
>> > driver that are fixed in the latest e1000 version.
>> > I looked through the -stable patches but didn't find anything that
>> > would fix my problem.
>> > I get messages along the lines of "kernel: Virtual device XXX asks to
>> > queue packet!" and the device then refuses to work.
>> > The last kernel where I know for a fact that it worked OK is 2.6.11,
>> > so that's what the server is currently running.
>> >
>> > Getting the fix for that problem backported to -stable would really
>> make my day.
>>
>>
>> Perhaps the e1000 developers can help us to identify the particular
>> fix for
>> this problem.
>>
> That's what I was hoping for...
I suspect that this will have fixed it, but this is a followup to a patch that
disables HW CRC stripping. perhaps commit eb0f805... might be involved as
well, allthough I doubt that.
---
diff-tree f235a2abb27b9396d2108dd2987fb8262cb508a3 (from d3d9e484b2ca502c87156b6
Author: Auke Kok <auke\[email protected]>
Date: Fri Jul 14 16:14:34 2006 -0700
e1000: remove CRC bytes from measured packet length
After removing the hardware CRC stripping which causes problems with
SOL and related issues, we need to compensate for this changed size.
Signed-off-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Auke Kok <[email protected]>
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 1c6bcad..0074a3a 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3673,6 +3673,9 @@ #endif
length = le16_to_cpu(rx_desc->length);
+ /* adjust length to remove Ethernet CRC */
+ length -= 4;
+
if (unlikely(!(status & E1000_RXD_STAT_EOP))) {
/* All receives must fit into a single buffer */
E1000_DBG("%s: Receive packet consumed multiple"
@@ -3877,8 +3880,9 @@ #endif
pci_dma_sync_single_for_device(pdev,
ps_page_dma->ps_page_dma[0],
PAGE_SIZE, PCI_DMA_FROMDEVICE);
+ /* remove the CRC */
+ l1 -= 4;
skb_put(skb, l1);
- length += l1;
goto copydone;
} /* if */
}
@@ -3896,6 +3900,10 @@ #endif
skb->data_len += length;
skb->truesize += length;
}
+
+ /* strip the ethernet crc, problem is we're using pages now so
+ * this whole operation can get a little cpu intensive */
+ pskb_trim(skb, skb->len - 4);
copydone:
e1000_rx_checksum(adapter, staterr,
---
hth,
Auke
Greg KH wrote:
> -stable review patch. If anyone has any objections, please let us know.
>
> ------------------
> From: Neil Brown <[email protected]>
>
> The inode number out of an NFS file handle gets passed eventually to
> ext3_get_inode_block() without any checking. If ext3_get_inode_block()
> allows it to trigger an error, then bad filehandles can have unpleasant
> effect - ext3_error() will usually cause a forced read-only remount, or a
> panic if `errors=panic' was used.
>
> So remove the call to ext3_error there and put a matching check in
> ext3/namei.c where inode numbers are read off storage.
This patch and the ext2 patch (23/23) are accomplishing the same thing in 2
different ways, I think, and introducing unnecessary differences between ext2
and ext3. I'd personally prefer to see both ext2 and ext3 handled with the
get_dentry op addition, and I'd be happy to quickly whip up the ext3 patch to do
this if there's agreement on this path.
(there's nothing technically wrong with either approach, it just seems
inconsistent to me).
Thanks,
-Eric
On Fri, Aug 04, 2006 at 09:45:52AM -0500, Eric Sandeen wrote:
> Greg KH wrote:
> >-stable review patch. If anyone has any objections, please let us know.
> >
> >------------------
> >From: Neil Brown <[email protected]>
> >
> >The inode number out of an NFS file handle gets passed eventually to
> >ext3_get_inode_block() without any checking. If ext3_get_inode_block()
> >allows it to trigger an error, then bad filehandles can have unpleasant
> >effect - ext3_error() will usually cause a forced read-only remount, or a
> >panic if `errors=panic' was used.
> >
> >So remove the call to ext3_error there and put a matching check in
> >ext3/namei.c where inode numbers are read off storage.
>
> This patch and the ext2 patch (23/23) are accomplishing the same thing in 2
> different ways, I think, and introducing unnecessary differences between
> ext2 and ext3. I'd personally prefer to see both ext2 and ext3 handled
> with the get_dentry op addition, and I'd be happy to quickly whip up the
> ext3 patch to do this if there's agreement on this path.
I completly agree with Eric here. Also pushing out only the fix for one
(and today probably the lesser used) filesystems to -stable seems wrong.
On Fri, 04 Aug 2006 15:08:49 +0200
Arjan van de Ven <[email protected]> wrote:
> On Fri, 2006-08-04 at 02:04 -0700, Andrew Morton wrote:
> > On Fri, 4 Aug 2006 09:50:13 +0100
> > Christoph Hellwig <[email protected]> wrote:
> >
> > > On Thu, Aug 03, 2006 at 10:39:42PM -0700, Greg KH wrote:
> > > > -stable review patch. If anyone has any objections, please let us know.
> > >
> > > This is a feature. Definitly not -stable material.
> >
> > Apparently that regular IPI storm is causing the SGI machines some
> > significant problems.
>
> a tiny performance drop :) If that meets the stable policy.. open
> question :)
The interrupt holdoff problem is one which is important to Altix users (for
reasons which I've never understood). Apparently, quite important - this
is I think the third time we've fixed problems in this area for Altix.
> > It's not the biggest problem we've ever had, but if this patch is wrong,
> > the pagecache/buffer_head layer is utterly busted. And it isn't.
>
>
> are you sure?
>
> + struct address_space *mapping = bdev->bd_inode->i_mapping;
> +
> + if (mapping->nrpages == 0)
> + return;
> +
> invalidate_bh_lrus();
>
> what happens if a bdev used to have pagecache and at some point stops
> having that due to page reclaim... will that page reclaim call
> invalidate_bh_lrus() ? If not, who will ? If the answer is "nobody", is
> that really the right answer?
invalidate_bdev() calls invalidate_bh_lrus() to release any references
which the bh lru has against the the bdev's pagecache, so that
invalidate_inode_pages() can take down the bdev's pagecache.
If the bdev has no pagecache then there's no need to call
invalidate_bh_lrus(). (or invalidate_inode_pages, or truncate_inode_pages, btw)
(In fact, even if the inode _does_ have pagecache, we still don't need to
call invalidate_bh_lrus(): both invalidate_inodes_pages() and
truncate_inode_pages() will still remove this page from the inode. The bh
lru is left holding the last reference to the now-anonymous page, and this
will later expire, finally freeing the page).
Signed-off-by: Eric Sandeen <[email protected]>
(tho blatantly ripped off from Neil Brown's ext2 patch)
Index: linux-2.6.17/fs/ext3/super.c
===================================================================
--- linux-2.6.17.orig/fs/ext3/super.c
+++ linux-2.6.17/fs/ext3/super.c
@@ -620,8 +620,48 @@ static struct super_operations ext3_sops
#endif
};
+static struct dentry *ext3_get_dentry(struct super_block *sb, void *vobjp)
+{
+ __u32 *objp = vobjp;
+ unsigned long ino = objp[0];
+ __u32 generation = objp[1];
+ struct inode *inode;
+ struct dentry *result;
+
+ if (ino != EXT3_ROOT_INO && ino < EXT3_FIRST_INO(sb))
+ return ERR_PTR(-ESTALE);
+ if (ino > le32_to_cpu(EXT3_SB(sb)->s_es->s_inodes_count))
+ return ERR_PTR(-ESTALE);
+
+ /* iget isn't really right if the inode is currently unallocated!!
+ * ext3_read_inode currently does appropriate checks, but
+ * it might be "neater" to call ext3_get_inode first and check
+ * if the inode is valid.....
+ */
+ inode = iget(sb, ino);
+ if (inode == NULL)
+ return ERR_PTR(-ENOMEM);
+ if (is_bad_inode(inode)
+ || (generation && inode->i_generation != generation)
+ ) {
+ /* we didn't find the right inode.. */
+ iput(inode);
+ return ERR_PTR(-ESTALE);
+ }
+ /* now to find a dentry.
+ * If possible, get a well-connected one
+ */
+ result = d_alloc_anon(inode);
+ if (!result) {
+ iput(inode);
+ return ERR_PTR(-ENOMEM);
+ }
+ return result;
+}
+
static struct export_operations ext3_export_ops = {
.get_parent = ext3_get_parent,
+ .get_dentry = ext3_get_dentry,
};
enum {
On Fri, Aug 04, 2006 at 10:35:34AM -0500, Eric Sandeen wrote:
> Signed-off-by: Eric Sandeen <[email protected]>
>
> (tho blatantly ripped off from Neil Brown's ext2 patch)
Looks good!
Acked-by: "Theodore Ts'o" <[email protected]>
- Ted
On Thu, 2006-08-03 at 22:40 -0700, Greg KH wrote:
> plain text document attachment
> (s390-fix-futex_atomic_cmpxchg_inatomic.patch)
> -stable review patch. If anyone has any objections, please let us know.
>
> ------------------
> [S390] fix futex_atomic_cmpxchg_inatomic
>
> futex_atomic_cmpxchg_inatomic has the same bug as the other
> atomic futex operations: the operation needs to be done in the
> user address space, not the kernel address space. Add the missing
> sacf 256 & sacf 0.
>
> Signed-off-by: Martin Schwidefsky <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
Hi Greg,
sorry for the late answer. Stable version 2.6.17.8 contains the
necessary patches to fix the futex hole and I currently do not know of
any other critical bugs that need fixing. Thanks!
--
blue skies,
Martin.
Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH
"Reality continues to ruin my life." - Calvin.
On Fri, Aug 04, 2006 at 10:35:34AM -0500, Eric Sandeen wrote:
> Christoph Hellwig wrote:
> >On Fri, Aug 04, 2006 at 09:45:52AM -0500, Eric Sandeen wrote:
> >>Greg KH wrote:
> >>>-stable review patch. If anyone has any objections, please let us know.
> >>>
> >>>------------------
> >>>From: Neil Brown <[email protected]>
> >>>
> >>>The inode number out of an NFS file handle gets passed eventually to
> >>>ext3_get_inode_block() without any checking. If ext3_get_inode_block()
> >>>allows it to trigger an error, then bad filehandles can have unpleasant
> >>>effect - ext3_error() will usually cause a forced read-only remount, or a
> >>>panic if `errors=panic' was used.
> >>>
> >>>So remove the call to ext3_error there and put a matching check in
> >>>ext3/namei.c where inode numbers are read off storage.
> >>This patch and the ext2 patch (23/23) are accomplishing the same thing in
> >>2 different ways, I think, and introducing unnecessary differences
> >>between ext2 and ext3. I'd personally prefer to see both ext2 and ext3
> >>handled with the get_dentry op addition, and I'd be happy to quickly whip
> >>up the ext3 patch to do this if there's agreement on this path.
> >
> >I completly agree with Eric here. Also pushing out only the fix for one
> >(and today probably the lesser used) filesystems to -stable seems wrong.
>
> so how's this? (compile tested)
>
> Thanks,
> -Eric
> Signed-off-by: Eric Sandeen <[email protected]>
>
> (tho blatantly ripped off from Neil Brown's ext2 patch)
Thanks, I've queued this up.
greg k-h