-stable review
Subsystems (15)
PATCH 9/23 : Update frag_list in pskb_trim
In reply to Greg KH-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 :)
--- include/linux/skbuff.h | 24 +++++------ net/core/skbuff.c | 106 ++++++++++++++++++++++++++++++++++--------------- 2 files changed, 86 insertions(+), 44 deletions(-)
include/linux/skbuff.h +12 -12
@@ -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_bustatic 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)
net/core/skbuff.c +74 -32
140 lines not on this page · raw message
--
PATCH 14/23 Fix race related problem when adding items to and svcrpc auth cache.
In reply to Greg KH-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.
--- net/sunrpc/cache.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
net/sunrpc/cache.c +5 -1
@@ -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(sreturn tmp; } } - detail->init (new, key); new->next = *head; *head = new; detail->entries++;
--
PATCH 1/23 PCI: fix issues with extended conf space when MMCONFIG disabled because of e820
In reply to Greg KH-stable review patch. If anyone has any objections, please let us know.
------------------
From: Chuck Ebbert <[email protected]>
Quoted 2 lines · Andi Kleen
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.
--- arch/i386/pci/mmconfig.c | 9 ++++++--- arch/x86_64/pci/mmconfig.c | 13 +++++++++---- 2 files changed, 15 insertions(+), 7 deletions(-)
arch/i386/pci/mmconfig.c +6 -3
@@ -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 ; }
arch/x86_64/pci/mmconfig.c +9 -4
@@ -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);
--
PATCH 2/23 Dont allow chmod() on the /proc/<pid>/ files
In reply to Greg KH-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.
--- fs/proc/base.c | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-)
fs/proc/base.c +32 -1
@@ -596,6 +596,27 @@ static int proc_permission(struct inodereturn 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_astatic 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_bstatic 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_lookstatic 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(strucstatic struct inode_operations proc_self_inode_operations = { .readlink = proc_self_readlink, .follow_link = proc_self_follow_link, + .setattr = proc_setattr, };/**
--
PATCH 3/23 : H.323 helper: fix possible NULL-ptr dereference
In reply to Greg KH-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]>.
--- net/ipv4/netfilter/ip_conntrack_helper_h323.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/netfilter/ip_conntrack_helper_h323.c +1 -1
@@ -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 ; }
--
PATCH 4/23 scx200_acb: Fix the state machine
In reply to Greg KH-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.
--- drivers/i2c/busses/scx200_acb.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/i2c/busses/scx200_acb.c +6 -6
@@ -181,21 +181,21 @@ static void scx200_acb_machine(struct scbreak ;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:
--
PATCH 7/23 sky2: NAPI bug
In reply to Greg KH-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.
--- drivers/net/sky2.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/net/sky2.c +1 -4
@@ -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 );
--
PATCH 8/23 UHCI: Fix handling of short last packet
In reply to Greg KH-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.
--- drivers/usb/host/uhci-q.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/usb/host/uhci-q.c +4 -2
@@ -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 ;
--
PATCH 5/23 scx200_acb: Fix the block transactions
In reply to Greg KH-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 :)
--- drivers/i2c/busses/scx200_acb.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/i2c/busses/scx200_acb.c +6 -2
@@ -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) */
--
PATCH 11/23 Sparc64 quad-float emulation fix
In reply to Greg KH-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
--- include/asm-sparc64/sfp-machine.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/asm-sparc64/sfp-machine.h +1 -1
@@ -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)
--
PATCH 13/23 ieee1394: sbp2: enable auto spin-up for Maxtor disks
In reply to Greg KH-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.
--- drivers/ieee1394/sbp2.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/ieee1394/sbp2.c +3 -0
@@ -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 ; }
--
PATCH 17/23 e1000: add forgotten PCI ID for supported device
In reply to Greg KH-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.
--- drivers/net/e1000/e1000_hw.c | 1 + drivers/net/e1000/e1000_hw.h | 1 + 2 files changed, 2 insertions(+)
drivers/net/e1000/e1000_hw.c +1 -0
@@ -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 :
drivers/net/e1000/e1000_hw.h +1 -0
@@ -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
--
PATCH 18/23 cond_resched() fix
In reply to Greg KH-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.
--- kernel/sched.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-)
kernel/sched.c +13 -12
@@ -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. *
--
PATCH 23/23 Have ext2 reject file handles with bad inode numbers early.
In reply to Greg KH-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.
--- fs/ext2/super.c | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+)
fs/ext2/super.c +41 -0
@@ -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)
--
PATCH 21/23 tty serialize flush_to_ldisc
In reply to Greg KH-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.
--- drivers/char/tty_io.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
drivers/char/tty_io.c +9 -5
@@ -2776,7 +2776,7 @@ static void flush_to_ldisc(void *privatestruct 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); }
--
PATCH 19/23 Fix budget-av compile failure
In reply to Greg KH-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. :(
--- drivers/media/dvb/ttpci/budget-av.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/media/dvb/ttpci/budget-av.c +5 -5
@@ -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));
--
PATCH 22/23 Add stable branch to maintainers file
In reply to Greg KH-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.
--- MAINTAINERS | 8 ++++++++ 1 file changed, 8 insertions(+)
MAINTAINERS +8 -0
@@ -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]
--
PATCH 15/23 ext3 -nobh option causes oops
In reply to Greg KH-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().
--- fs/ext3/inode.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
fs/ext3/inode.c +3 -3
@@ -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(sif (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);
--
PATCH 16/23 ext3: avoid triggering ext3_error on bad NFS file handle
In reply to Greg KH-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.
--- fs/ext3/inode.c | 13 +++++++------ fs/ext3/namei.c | 15 +++++++++++++-- include/linux/ext3_fs.h | 9 +++++++++ 3 files changed, 29 insertions(+), 8 deletions(-)
fs/ext3/inode.c +7 -6
@@ -2402,14 +2402,15 @@ static unsigned long ext3_get_inode_blocstruct 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" );
fs/ext3/namei.c +13 -2
@@ -1000,7 +1000,12 @@ static struct dentry *ext3_lookup(structif (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 dereturn 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 );
include/linux/ext3_fs.h +9 -0
@@ -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
--
PATCH 20/23 S390: fix futex_atomic_cmpxchg_inatomic
In reply to Greg KH-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.
--- include/asm-s390/futex.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
include/asm-s390/futex.h +3 -2
@@ -98,9 +98,10 @@ futex_atomic_cmpxchg_inatomic(int __userif (!access_ok (VERIFY_WRITE , uaddr,sizeof (int )))return -EFAULT ; - asmvolatile (" cs %1,%4,0(%5)\n" + asmvolatile (" 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"
--
PATCH 12/23 invalidate_bdev() speedup
In reply to Greg KH-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.
--- fs/buffer.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
fs/buffer.c +6 -1
@@ -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); }/*
--
PATCH 6/23 i2c: Fix ignore module parameter handling in i2c-core
In reply to Greg KH-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.
--- drivers/i2c/i2c-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/i2c/i2c-core.c +2 -2
@@ -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 ;
--
PATCH 10/23 VLAN state handling fix
In reply to Greg KH-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.
--- net/8021q/vlan.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
net/8021q/vlan.c +3 -5
@@ -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.
--
cover -stable review
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
Quoted 11 lines · Greg KH
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.
Quoted 7 lines
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.
Quoted 8 lines · Grant Coady
Quoted 4 lines · Greg KH
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.gzIt wasn't clear that this is a delta 2.6.17.7 -> 2.6.17.8 patch ;)
Quoted 7 lines
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.
Quoted 1 line
On the bright side, it compiled and runs ;)
Great, thanks for testing and letting us know, I really appreciate it.
greg k-h
Re: [patch 12/23] invalidate_bdev() speedup
In reply to Greg KHQuoted 1 line · Greg KH
-stable review patch. If anyone has any objections, please let us know.
This is a feature. Definitly not -stable material.
Quoted 11 lines · Greg KH
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.
Quoted 8 lines
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.
Signature · 3 lines
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
Re: [patch 12/23] invalidate_bdev() speedup
In reply to Christoph HellwigQuoted 4 lines · On Fri, 4 Aug 2006 09:50:13 +0100 Christoph Hellwig <[email protected]> wrote:
Quoted 1 line · Greg KH
-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.
Quoted 7 lines · Jesper Juhl
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"?
Quoted 4 lines · Patrick McHardy
Quoted 3 lines · Jesper Juhl
Any chance that the fixes in the (latest) e1000 driver version 7.1.9-k4 will get backported?
Quoted 8 lines
Quoted 4 lines
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
Signature · 3 lines
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
Quoted 15 lines · On Fri, 4 Aug 2006 11:04:36 +0200 "Jesper Juhl" <[email protected]> wrote:
Quoted 14 lines · Greg KH
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.
Quoted 8 lines
Quoted 5 lines
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.gzAny 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.
Quoted 10 lines
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?
Quoted 21 lines · Andrew Morton
Quoted 18 lines · On Fri, 4 Aug 2006 11:04:36 +0200 "Jesper Juhl" <[email protected]> wrote:
Quoted 17 lines · Greg KH
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:
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gzAny 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.
Quoted 9 lines
Quoted 9 lines
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.
Quoted 6 lines
Quoted 1 line
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...
Quoted 2 lines
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)
Signature · 3 lines
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
Quoted 11 lines · Jesper Juhl
Quoted 9 lines · Patrick McHardy
Quoted 7 lines · Jesper Juhl
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.
Quoted 4 lines
Quoted 3 lines
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".
Quoted 12 lines · Patrick McHardy
Quoted 11 lines · Jesper Juhl
Quoted 9 lines · Patrick McHardy
Quoted 7 lines · Jesper Juhl
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.
Quoted 7 lines
Quoted 4 lines
Quoted 3 lines
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.
Signature · 3 lines
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
Re: [patch 12/23] invalidate_bdev() speedup
In reply to Andrew MortonQuoted 10 lines · Andrew Morton
Quoted 4 lines · On Fri, 4 Aug 2006 09:50:13 +0100 Christoph Hellwig <[email protected]> wrote:
Quoted 1 line · Greg KH
-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 :)
Quoted 2 lines
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?
Signature · 1 line
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Re: [patch 12/23] invalidate_bdev() speedup
Quoted 6 lines · Arjan van de Ven
Quoted 2 lines · Andrew Morton
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 ....
Quoted 12 lines
Quoted 2 lines
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?
fs/buffer.c +5
-0+struct address_space *mapping = bdev->bd_inode->i_mapping; + +if (mapping->nrpages ==0 ) +return ; +invalidate_bh_lrus ();
Quoted 4 lines
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
Quoted 50 lines · Jesper Juhl
Quoted 29 lines · Andrew Morton
Quoted 2 lines · On Fri, 4 Aug 2006 11:04:36 +0200 "Jesper Juhl" <[email protected]> wrote:
Quoted 1 line · Greg KH
This is the start of the stable review cycle for the 2.6.17.8
release.
Quoted 1 line
Quoted 1 line
There are 23 patches in this series, all will be posted as a
response to
Quoted 1 line
Quoted 1 line
this one. If anyone has any issues with these being applied,
please let
Quoted 1 line
Quoted 1 line
us know. If anyone is a maintainer of the proper subsystem, and
wants
Quoted 3 lines
Quoted 3 lines
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:
Quoted 1 line
Quoted 1 line
line. If you wish to be a reviewer, please email
Quoted 7 lines
Quoted 7 lines
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
Quoted 3 lines
Quoted 3 lines
to test it out. It can be found at:
Quoted 8 lines
kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17.8-rc1.gz
Quoted 4 lines
Quoted 1 line
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.
Quoted 9 lines
Quoted 9 lines
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.
Quoted 8 lines
Quoted 7 lines
Quoted 1 line
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.
drivers/net/e1000/e1000_main.c +9 -1
@@ -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 @@ #endifpci_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
Re: [patch 16/23] ext3: avoid triggering ext3_error on bad NFS file handle
In reply to Greg KHQuoted 5 lines · Greg KH
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Neil Brown <[email protected]>
Quoted 8 lines
The inode number out of an NFS file handle gets passed eventually to
ext3_get_inode_block()without any checking. Ifext3_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_errorthere and put a matching check inext3/namei.cwhere 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
Re: [patch 16/23] ext3: avoid triggering ext3_error on bad NFS file handle
Quoted 12 lines · Eric Sandeen
Quoted 11 lines · Greg KH
-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. Ifext3_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.
Quoted 8 lines
Quoted 2 lines
So remove the call to
ext3_errorthere and put a matching check inext3/namei.cwhere 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_dentryop 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.
Re: [patch 12/23] invalidate_bdev() speedup
In reply to Arjan van de VenQuoted 7 lines · On Fri, 04 Aug 2006 15:08:49 +0200 Arjan van de Ven <[email protected]> wrote:
Quoted 6 lines · Andrew Morton
Quoted 3 lines · On Fri, 4 Aug 2006 09:50:13 +0100 Christoph Hellwig <[email protected]> wrote:
Quoted 1 line · Greg KH
-stable review patch. If anyone has any objections, please let us know.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
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.
Quoted 13 lines
Quoted 2 lines
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?
fs/buffer.c +5
-0+struct address_space *mapping = bdev->bd_inode->i_mapping; + +if (mapping->nrpages ==0 ) +return ; +invalidate_bh_lrus ();
Quoted 4 lines
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).
Re: [patch 16/23] ext3: avoid triggering ext3_error on bad NFS file handle
In reply to Christoph HellwigQuoted 13 lines · Christoph Hellwig
Quoted 12 lines · Eric Sandeen
Quoted 11 lines · Greg KH
-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. Ifext3_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.
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
So remove the call to
ext3_errorthere and put a matching check inext3/namei.cwhere 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_dentryop 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
(tho blatantly ripped off from Neil Brown's ext2 patch)
fs/ext3/super.c +40 -0
@@ -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 {
Theodore Tso
Acked-byRe: [patch 16/23] ext3: avoid triggering ext3_error on bad NFS file handle
Quoted 3 lines · Eric Sandeen
Signed-off-by Eric Sandeen <[email protected]>(tho blatantly ripped off from Neil Brown's ext2 patch)
Looks good!
- Ted
Re: [patch 20/23] S390: fix futex_atomic_cmpxchg_inatomic
In reply to Greg KHQuoted 7 lines · Greg KH
plain text document attachment (s390-fix-futex_atomic_cmpxchg_inatomic.patch)
-stable review patch. If anyone has any objections, please let us know.------------------
[S390] fixfutex_atomic_cmpxchg_inatomic
Quoted 8 lines
futex_atomic_cmpxchg_inatomichas 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!
Signature · 8 lines
blue skies, Martin. Martin Schwidefsky Linux for zSeries Development & Services IBM Deutschland Entwicklung GmbH "Reality continues to ruin my life." - Calvin.
Re: [stable] [patch 16/23] ext3: avoid triggering ext3_error on bad NFS file handle
In reply to Eric SandeenQuoted 25 lines · Eric Sandeen
Quoted 15 lines · Christoph Hellwig
Quoted 14 lines · Eric Sandeen
Quoted 13 lines · Greg KH
-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. Ifext3_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_errorthere and put a matching check inext3/namei.cwhere inode numbers are read off storage.Quoted 8 lines
Quoted 5 lines
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_dentryop 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.
Quoted 8 lines
so how's this? (compile tested)
Thanks,
-EricSigned-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
Re: [patch 15/23] ext3 -nobh option causes oops
In reply to Greg KHIt seems this patch that went into 2.6.17.8 should also be included in the 2.6.16.x branch, or do I miss anything?
TIA
Adrian
Quoted 47 lines · Greg KH
-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(-)fs/ext3/inode.c +3
-3@@ -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(sif (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);
Re: [patch 15/23] ext3 -nobh option causes oops
Quoted 3 lines · Adrian Bunk
It seems this patch that went into 2.6.17.8 should also be included in the 2.6.16.x branch, or do I miss anything?
Yes. This is needed for 2.6.16.x branch also.
Thanks,
Badari
Quoted 48 lines · Greg KH
Quoted 47 lines
-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(-)fs/ext3/inode.c +3
-3@@ -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(sif (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);
Re: [patch 15/23] ext3 -nobh option causes oops
Quoted 7 lines · Badari Pulavarty
Quoted 3 lines · Adrian Bunk
It seems this patch that went into 2.6.17.8 should also be included in the 2.6.16.x branch, or do I miss anything?
Yes. This is needed for 2.6.16.x branch also.
Thanks, I've applied it.
Quoted 2 lines
Thanks,
Badari
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed