2.6.32.53-longterm review
Subsystems (12)
cover 2.6.32.53-longterm review
This is the start of the longterm review cycle for the 2.6.32.@rel@ release. There are 7 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.
Responses should be made by Friday, January 6, 2012, 20:00:00 UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.53-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
Makefile | 2 +- arch/arm/plat-mxc/pwm.c | 16 +++++++++++++++- block/cfq-iosched.c | 11 +++++++++-- drivers/mmc/host/mmci.c | 6 +++++- drivers/scsi/mpt2sas/mpt2sas_scsih.c | 2 +- drivers/watchdog/hpwdt.c | 5 ++++- mm/filemap.c | 7 ++----- 7 files changed, 37 insertions(+), 12 deletions(-)
PATCH 1/7 cfq-iosched: fix cfq_cic_link() race confition
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Yasuaki Ishimatsu <[email protected]>
commit 5eb46851de3904cd1be9192fdacb8d34deadc1fc upstream.
cfq_cic_link() has race condition. When some processes which shared ioc issue I/O to same block device simultaneously, cfq_cic_link() returns -EEXIST sometimes. The race condition might stop I/O by following steps:
step 1: Process A: Issue an I/O to /dev/sda
step 2: Process A: Get an ioc (iocA here) in get_io_context() which does not
linked with a cic for the device
step 3: Process A: Get a new cic for the device (cicA here) in
cfq_alloc_io_context()
step 4: Process B: Issue an I/O to /dev/sda
step 5: Process B: Get iocA in get_io_context() since process A and B share the
same ioc
step 6: Process B: Get a new cic for the device (cicB here) in
cfq_alloc_io_context() since iocA has not been linked with a cic for the device yet
step 7: Process A: Link cicA to iocA in cfq_cic_link() step 8: Process A: Dispatch I/O to driver and finish it
step 9: Process B: Try to link cicB to iocA in cfq_cic_link()
But it fails with showing "cfq: cic link failed!" kernel message, since iocA has already linked with cicA at step 7.
step 10: Process B: Wait for finishig I/O in get_request_wait()
The function does not wake up, when there is no I/O to the device.
When cfq_cic_link() returns -EEXIST, it means ioc has already linked with cic. So when cfq_cic_link() return -EEXIST, retry cfq_cic_lookup().
--- block/cfq-iosched.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
block/cfq-iosched.c +9 -2
@@ -1981,7 +1981,7 @@ static int cfq_cic_link(struct cfq_data } } -if (ret) +if (ret && ret != -EEXIST )printk (KERN_ERR "cfq: cic link failed!\n" );return ret;
@@ -1997,6 +1997,7 @@ cfq_get_io_context(struct cfq_data *cfqd {struct io_context *ioc =NULL ;struct cfq_io_context *cic; +int ret;might_sleep_if (gfp_mask & __GFP_WAIT);
@@ -2004,6 +2005,7 @@ cfq_get_io_context(struct cfq_data *cfqdif (!ioc)return NULL ; +retry: cic =cfq_cic_lookup (cfqd, ioc);if (cic) goto out;
@@ -2012,7 +2014,12 @@ cfq_get_io_context(struct cfq_data *cfqdif (cic ==NULL ) goto err; -if (cfq_cic_link (cfqd, ioc, cic, gfp_mask)) + ret =cfq_cic_link (cfqd, ioc, cic, gfp_mask); +if (ret == -EEXIST ) { +/* someone has linked cic to ioc already */ +cfq_cic_free (cic); + goto retry; + }else if (ret) goto err_free; out:
PATCH 2/7 SCSI: mpt2sas: _scsih_smart_predicted_fault uses GFP_KERNEL in interrupt context
In reply to Greg KH2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Anton Blanchard <[email protected]>
commit f6a290b419a2675c4b77a6b0731cd2a64332365e upstream.
_scsih_smart_predicted_fault is called in an interrupt and therefore must allocate memory using GFP_ATOMIC.
--- drivers/scsi/mpt2sas/mpt2sas_scsih.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/mpt2sas/mpt2sas_scsih.c +1 -1
@@ -3145,7 +3145,7 @@ _scsih_smart_predicted_fault(struct MPT2/* insert into event log */ sz = offsetof(Mpi2EventNotificationReply_t , EventData) +sizeof (Mpi2EventDataSasDeviceStatusChange_t); - event_reply =kzalloc (sz,GFP_KERNEL ); + event_reply =kzalloc (sz,GFP_ATOMIC );if (!event_reply) {printk (MPT2SAS_ERR_FMT "failure at %s:%d/%s()!\n" , ioc->name, __FILE__, __LINE__, __func__);
PATCH 3/7 MXC PWM: should active during DOZE/WAIT/DBG mode
In reply to Greg KH2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jason Chen <[email protected]>
commit c0d96aed8c6dd925afe9ea35491a0cd458642a86 upstream.
--- arch/arm/plat-mxc/pwm.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
arch/arm/plat-mxc/pwm.c +6 -1
@@ -31,6 +31,9 @@#define MX3_PWMSAR 0x0C/* PWM Sample Register */ #define MX3_PWMPR 0x10/* PWM Period Register */ #define MX3_PWMCR_PRESCALER (x) (((x - 1) & 0xFFF) << 4) +#define MX3_PWMCR_DOZEEN (1 << 24) +#define MX3_PWMCR_WAITEN (1 << 23) +#define MX3_PWMCR_DBGEN (1 << 22)#define MX3_PWMCR_CLKSRC_IPG_HIGH (2 << 16)#define MX3_PWMCR_CLKSRC_IPG (1 << 16)#define MX3_PWMCR_EN (1 << 0)
@@ -76,7 +79,9 @@ int pwm_config(struct pwm_device *pwm, iwritel (duty_cycles, pwm->mmio_base +MX3_PWMSAR );writel (period_cycles, pwm->mmio_base +MX3_PWMPR ); - cr =MX3_PWMCR_PRESCALER (prescale) |MX3_PWMCR_EN ; + cr =MX3_PWMCR_PRESCALER (prescale) | +MX3_PWMCR_DOZEEN |MX3_PWMCR_WAITEN | +MX3_PWMCR_DBGEN |MX3_PWMCR_EN ;if (cpu_is_mx25 ()) cr |=MX3_PWMCR_CLKSRC_IPG ;
PATCH 4/7 vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
In reply to Greg KH2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Dave Kleikamp <[email protected]>
commit e6f67b8c05f5e129e126f4409ddac6f25f58ffcb upstream.
lockdep reports a deadlock in jfs because a special inode's rw semaphore is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used when __read_cache_page() calls add_to_page_cache_lru().
--- mm/filemap.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
mm/filemap.c +2 -5
@@ -1675,7 +1675,7 @@ repeat: page =__page_cache_alloc (gfp | __GFP_COLD);if (!page)return ERR_PTR (-ENOMEM ); - err =add_to_page_cache_lru (page, mapping, index,GFP_KERNEL ); + err =add_to_page_cache_lru (page, mapping, index, gfp);if (unlikely (err)) {page_cache_release (page);if (err == -EEXIST )
@@ -1772,10 +1772,7 @@ static struct page *wait_on_page_read(st* @gfp: the page allocator flags to use if allocating * * This is the same as "read_mapping_page(mapping, index, NULL)", but with -* any new page allocations done using the specified allocation flags. Note -* that the Radix tree operations will still use GFP_KERNEL, so you can't -* expect to do this atomically or anything like that - but you can pass in -* other page requirements. +* any new page allocations done using the specified allocation flags. * * If the page does not get brought uptodate, return -EIO. */
PATCH 5/7 ARM:imx:fix pwm period value
In reply to Greg KH2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jason Chen <[email protected]>
commit 5776ac2eb33164c77cdb4d2b48feee15616eaba3 upstream.
According to imx pwm RM, the real period value should be PERIOD value in PWMPR plus 2.
PWMO (Hz) = PCLK(Hz) / (period +2)
--- arch/arm/plat-mxc/pwm.c | 9 +++++++++ 1 file changed, 9 insertions(+)
arch/arm/plat-mxc/pwm.c +9 -0
@@ -76,6 +76,15 @@ int pwm_config(struct pwm_device *pwm, ido_div (c, period_ns); duty_cycles = c; +/* +* according to imx pwm RM, the real period value should be +* PERIOD value in PWMPR plus 2. +*/ +if (period_cycles >2 ) + period_cycles -=2 ; +else + period_cycles =0 ; +writel (duty_cycles, pwm->mmio_base +MX3_PWMSAR );writel (period_cycles, pwm->mmio_base +MX3_PWMPR );
PATCH 6/7 ARM: 7220/1: mmc: mmci: Fixup error handling for dma
In reply to Greg KH2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Ulf Hansson <[email protected]>
commit 3b6e3c73851a9a4b0e6ed9d378206341dd65e8a5 upstream.
When getting a cmd irq during an ongoing data transfer with dma, the dma job were never terminated. This is now corrected.
--- drivers/mmc/host/mmci.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/mmc/host/mmci.c +5 -1
@@ -232,8 +232,12 @@ mmci_cmd_irq(struct mmci_host *host, str }if (!cmd->data || cmd->error) { -if (host->data) +if (host->data) { +/* Terminate the DMA transfer */ +if (dma_inprogress (host)) +mmci_dma_data_error (host);mmci_stop_data (host); + }mmci_request_end (host, cmd->mrq); }else if (!(cmd->data->flags &MMC_DATA_READ )) {mmci_start_data (host, cmd->data);
PATCH 7/7 watchdog: hpwdt: Changes to handle NX secure bit in 32bit path
In reply to Greg KH2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: "Mingarelli, Thomas" <[email protected]>
commit e67d668e147c3b4fec638c9e0ace04319f5ceccd upstream.
This patch makes use of the set_memory_x() kernel API in order to make necessary BIOS calls to source NMIs.
This is needed for SLES11 SP2 and the latest upstream kernel as it appears the NX Execute Disable has grown in its control.
Signed-off by: Thomas Mingarelli <[email protected]> Signed-off by: Wim Van Sebroeck <[email protected]>
--- drivers/watchdog/hpwdt.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/watchdog/hpwdt.c +4 -1
@@ -220,6 +220,7 @@ static int __devinit cru_detect(unsigned cmn_regs.u1.reax =CRU_BIOS_SIGNATURE_VALUE ; +set_memory_x ((unsigned long )bios32_entrypoint, (2 *PAGE_SIZE ));asminline_call (&cmn_regs, bios32_entrypoint);if (cmn_regs.u1.ral !=0 ) {
@@ -237,8 +238,10 @@ static int __devinit cru_detect(unsignedif ((physical_bios_base + physical_bios_offset)) { cru_rom_addr =ioremap (cru_physical_address, cru_length); -if (cru_rom_addr) +if (cru_rom_addr) { +set_memory_x ((unsigned long )cru_rom_addr, cru_length); retval =0 ; + } } printk(KERN_DEBUG "hpwdt: CRU Base Address: 0x%lx\n",