2.6.35.14 longterm review
Subsystems (40)
cover 2.6.35.14 longterm review
This is the start of the longterm review cycle for the 2.6.35.14 release. There are a large number of patches in this series, which will be posted as a response to this one. If anyone has any issues with these being applied, please let me 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.
I'm posting the patches in 100 patch chunks to not overload the mailing list. The next chunk will come tomorrow.
The full quilt queue can be found atgit://git.kernel.org/pub/scm/linux/kernel/git/longterm/longterm-queue-2.6.35
Responses should be made within 48 hours.
-Andi
PATCH 1/50 x86: Make Dell Latitude E6420 use reboot=pci
2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: H. Peter Anvin <[email protected]>
[ upstream commit a536877e77f73ea22d12d94a019fedd9671b6acd ]
Yet another variant of the Dell Latitude series which requires reboot=pci.
Quoted 6 lines
From the E5420 bug report by Daniel J Blueman:
The E6420 is affected also (same platform, different casing and features), which provides an external confirmation of the issue; I can submit a patch for that later or include it if you prefer:
http://linux.koolsolutions.com/2009/08/04/howto-fix-linux-hangfreeze-during-reboots-and-restarts/
arch/x86/kernel/reboot.c +8 -0
@@ -485,6 +485,14 @@ static struct dmi_system_id __initdata p DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E5420"), }, }, + { /* Handle problems with rebooting on the Latitude E6420. */ + .callback = set_pci_reboot, + .ident = "Dell Latitude E6420", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E6420"), + }, + }, { } };
PATCH 2/50 mm/futex: fix futex writes on archs with SW tracking of
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Herrenschmidt <[email protected]>
[ upstream commit 2efaca927f5cd7ecd0f1554b8f9b6a9a2c329c03 ]
dirty & young
I haven't reproduced it myself but the fail scenario is that on such machines (notably ARM and some embedded powerpc), if you manage to hit that futex path on a writable page whose dirty bit has gone from the PTE, you'll livelock inside the kernel from what I can tell.
It will go in a loop of trying the atomic access, failing, trying gup to "fix it up", getting succcess from gup, go back to the atomic access, failing again because dirty wasn't fixed etc...
So I think you essentially hang in the kernel.
The scenario is probably rare'ish because affected architecture are embedded and tend to not swap much (if at all) so we probably rarely hit the case where dirty is missing or young is missing, but I think Shan has a piece of SW that can reliably reproduce it using a shared writable mapping & fork or something like that.
On archs who use SW tracking of dirty & young, a page without dirty is effectively mapped read-only and a page without young unaccessible in the PTE.
Additionally, some architectures might lazily flush the TLB when relaxing write protection (by doing only a local flush), and expect a fault to invalidate the stale entry if it's still present on another processor.
The futex code assumes that if the "in_atomic()" access -EFAULT's, it can "fix it up" by causing get_user_pages() which would then be equivalent to taking the fault.
However that isn't the case. get_user_pages() will not call handle_mm_fault() in the case where the PTE seems to have the right permissions, regardless of the dirty and young state. It will eventually update those bits ... in the struct page, but not in the PTE.
Additionally, it will not handle the lazy TLB flushing that can be required by some architectures in the fault case.
Basically, gup is the wrong interface for the job. The patch provides a more appropriate one which boils down to just calling handle_mm_fault() since what we are trying to do is simulate a real page fault.
The futex code currently attempts to write to user memory within a pagefault disabled section, and if that fails, tries to fix it up using get_user_pages().
This doesn't work on archs where the dirty and young bits are maintained by software, since they will gate access permission in the TLB, and will not be updated by gup().
In addition, there's an expectation on some archs that a spurious write fault triggers a local TLB flush, and that is missing from the picture as well.
I decided that adding those "features" to gup() would be too much for this already too complex function, and instead added a new simpler fixup_user_fault() which is essentially a wrapper around handle_mm_fault() which the futex code can call.
include/linux/mm.h +2 -0
@@ -850,6 +850,8 @@ int get_user_pages(struct task_struct *tint get_user_pages_fast (unsigned long start,int nr_pages,int write,struct page **pages);struct page *get_dump_page (unsigned long addr); +extern int fixup_user_fault (struct task_struct *tsk,struct mm_struct *mm, +unsigned long address,unsigned int fault_flags);extern int try_to_release_page (struct page * page,gfp_t gfp_mask);extern void do_invalidatepage (struct page *page,unsigned long offset);
kernel/futex.c +2 -2
@@ -306,8 +306,8 @@ static int fault_in_user_writeable(u32 _int ret;down_read (&mm->mmap_sem); - ret =get_user_pages (current, mm, (unsigned long )uaddr, -1 ,1 ,0 ,NULL ,NULL ); + ret =fixup_user_fault (current, mm, (unsigned long )uaddr, +FAULT_FLAG_WRITE );up_read (&mm->mmap_sem);return ret <0 ? ret :0 ;
mm/memory.c +57 -1
64 lines not on this page · raw message
PATCH 3/50 mm/backing-dev.c: reset bdi min_ratio in bdi_unregister()
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
[ upstream commit ccb6108f5b0b541d3eb332c3a73e645c0f84278e ]
Vito said:
: The system has many usb disks coming and going day to day, with their : respective bdi's having min_ratio set to 1 when inserted. It works for : some time until eventually min_ratio can no longer be set, even when the : active set of bdi's seen in /sys/class/bdi/*/min_ratio doesn't add up to : anywhere near 100.
:
: This then leads to an unrelated starvation problem caused by write-heavy : fuse mounts being used atop the usb disks, a problem the min_ratio setting : at the underlying devices bdi effectively prevents.
Fix this leakage by resetting the bdi min_ratio when unregistering the BDI.
mm/backing-dev.c +1 -0
@@ -646,6 +646,7 @@ static void bdi_prune_sb(struct backing_void bdi_unregister (struct backing_dev_info *bdi) {if (bdi->dev) { +bdi_set_min_ratio (bdi,0 );bdi_prune_sb (bdi);if (!bdi_cap_flush_forker (bdi))
PATCH 4/50 xtensa: prevent arbitrary read in ptrace
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Dan Rosenberg <[email protected]>
[ upstream commit 0d0138ebe24b94065580bd2601f8bb7eb6152f56 ]
Prevent an arbitrary kernel read. Check the user pointer with access_ok() before copying data in.
arch/xtensa/kernel/ptrace.c +3 -0
@@ -147,6 +147,9 @@ int ptrace_setxregs(struct task_struct *elf_xtregs_t *xtregs = uregs;int ret =0 ; +if (!access_ok (VERIFY_READ , uregs,sizeof (elf_xtregs_t))) +return -EFAULT ; +#if XTENSA_HAVE_COPROCESSORS /* Flush all coprocessors before we overwrite them. */ coprocessor_flush_all (ti);
PATCH 5/50 ipc/sem.c: fix race with concurrent semtimedop() timeouts
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Manfred Spraul <[email protected]>
[ upstream commit d694ad62bf539dbb20a0899ac2a954555f9e4a83 ]
and IPC_RMID
If a semaphore array is removed and in parallel a sleeping task is woken up (signal or timeout, does not matter), then the woken up task does not wait until wake_up_sem_queue_do() is completed. This will cause crashes, because wake_up_sem_queue_do() will read from a stale pointer.
The fix is simple: Regardless of anything, always call get_queue_result(). This function waits until wake_up_sem_queue_do() has finished it's task.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=27142
ipc/sem.c +11 -2
@@ -1452,15 +1452,24 @@ SYSCALL_DEFINE4(semtimedop, int, semid, } sma =sem_lock (ns, semid); + +/* +* Wait until it's guaranteed that no wakeup_sem_queue_do() is ongoing. +*/ + error =get_queue_result (&queue); + +/* +* Array removed? If yes, leave without sem_unlock(). +*/ if (IS_ERR (sma)) { error = -EIDRM ; goto out_free; } - error =get_queue_result (&queue);/* -* If queue.status != -EINTR we are woken up by another process +* If queue.status != -EINTR we are woken up by another process. +* Leave without unlink_queue(), but with sem_unlock(). */ if (error != -EINTR ) {
PATCH 6/50 jme: Fix unmap error (Causing system freeze)
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Guo-Fu Tseng <[email protected]>
[ upstream commit 94c5b41b327e08de0ddf563237855f55080652a1 ]
This patch add the missing dma_unmap().
Which solved the critical issue of system freeze on heavy load.
Michal Miroslaw's rejected patch:
[PATCH v2 10/46] net: jme: convert to generic DMA API Pointed out the issue also, thank you Michal. But the fix was incorrect. It would unmap needed address when low memory.
Got lots of feedback from End user and Gentoo Bugzilla.
https://bugs.gentoo.org/show_bug.cgi?id=373109
Thank you all. :)
drivers/net/jme.c +14 -6
@@ -678,20 +678,28 @@ jme_make_new_rx_buf(struct jme_adapter *struct jme_ring *rxring = &(jme->rxring[0 ]);struct jme_buffer_info *rxbi = rxring->bufinf + i;struct sk_buff *skb; +dma_addr_t mapping; skb =netdev_alloc_skb (jme->dev, jme->dev->mtu +RX_EXTRA_LEN );if (unlikely (!skb))return -ENOMEM ; + mapping =pci_map_page (jme->pdev,virt_to_page (skb->data), +offset_in_page (skb->data),skb_tailroom (skb), +PCI_DMA_FROMDEVICE ); +if (unlikely (pci_dma_mapping_error (jme->pdev, mapping))) { +dev_kfree_skb (skb); +return -ENOMEM ; + } + +if (likely (rxbi->mapping)) +pci_unmap_page (jme->pdev, rxbi->mapping, + rxbi->len,PCI_DMA_FROMDEVICE ); + rxbi->skb = skb; rxbi->len =skb_tailroom (skb); - rxbi->mapping =pci_map_page (jme->pdev, -virt_to_page (skb->data), -offset_in_page (skb->data), - rxbi->len, -PCI_DMA_FROMDEVICE ); - + rxbi->mapping = mapping;return 0 ; }
PATCH 7/50 fix crash in scsi_dispatch_cmd()
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: James Bottomley <[email protected]>
[ upstream commit bfe159a51203c15d23cb3158fffdc25ec4b4dda1 ]
USB surprise removal of sr is triggering an oops in scsi_dispatch_command(). What seems to be happening is that USB is hanging on to a queue reference until the last close of the upper device, so the crash is caused by surprise remove of a mounted CD followed by attempted unmount.
The problem is that USB doesn't issue its final commands as part of the SCSI teardown path, but on last close when the block queue is long gone. The long term fix is probably to make sr do the teardown in the same way as sd (so remove all the lower bits on ejection, but keep the upper disk alive until last close of user space). However, the current oops can be simply fixed by not allowing any commands to be sent to a dead queue.
block/blk-core.c +3 -0
@@ -893,6 +893,9 @@ struct request *blk_get_request(struct r {struct request *rq; +if (unlikely (test_bit (QUEUE_FLAG_DEAD , &q->queue_flags))) +return NULL ; +BUG_ON (rw !=READ && rw !=WRITE );spin_lock_irq (q->queue_lock);
block/blk-exec.c +7 -0
@@ -50,6 +50,13 @@ void blk_execute_rq_nowait(struct reques {int where = at_head ?ELEVATOR_INSERT_FRONT :ELEVATOR_INSERT_BACK ; +if (unlikely (test_bit (QUEUE_FLAG_DEAD , &q->queue_flags))) { + rq->errors = -ENXIO ; +if (rq->end_io) + rq->end_io (rq, rq->errors); +return ; + } + rq->rq_disk = bd_disk; rq->end_io = done;WARN_ON (irqs_disabled ());
drivers/scsi/scsi_lib.c +2 -0
@@ -215,6 +215,8 @@ int scsi_execute(struct scsi_device *sdeint ret =DRIVER_ERROR <<24 ; req =blk_get_request (sdev->request_queue, write, __GFP_WAIT); +if (!req) +return ret;if (bufflen &&blk_rq_map_kern (sdev->request_queue, req, buffer, bufflen, __GFP_WAIT))
PATCH 8/50 mmc: Add PCI fixup quirks for Ricoh 1180:e823 reader
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Manoj Iyer <[email protected]>
[ upstream commit be98ca652faa6468916a9b7608befff215a8ca70 ]
drivers/pci/quirks.c +2 -0
@@ -2701,6 +2701,8 @@ static void ricoh_mmc_fixup_r5c832(struc }DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_RICOH ,PCI_DEVICE_ID_RICOH_R5C832 , ricoh_mmc_fixup_r5c832);DECLARE_PCI_FIXUP_RESUME_EARLY (PCI_VENDOR_ID_RICOH ,PCI_DEVICE_ID_RICOH_R5C832 , ricoh_mmc_fixup_r5c832); +DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_RICOH ,PCI_DEVICE_ID_RICOH_R5CE823 , ricoh_mmc_fixup_r5c832); +DECLARE_PCI_FIXUP_RESUME_EARLY (PCI_VENDOR_ID_RICOH ,PCI_DEVICE_ID_RICOH_R5CE823 , ricoh_mmc_fixup_r5c832);#endif /*CONFIG_MMC_RICOH_MMC*/ #if defined(CONFIG_DMAR ) || defined(CONFIG_INTR_REMAP )
include/linux/pci_ids.h +1 -0
@@ -1524,6 +1524,7 @@#define PCI_DEVICE_ID_RICOH_RL5C476 0x0476#define PCI_DEVICE_ID_RICOH_RL5C478 0x0478#define PCI_DEVICE_ID_RICOH_R5C822 0x0822 +#define PCI_DEVICE_ID_RICOH_R5CE823 0xe823#define PCI_DEVICE_ID_RICOH_R5C832 0x0832#define PCI_DEVICE_ID_RICOH_R5C843 0x0843
PATCH 9/50 mmc: Added quirks for Ricoh 1180:e823 lower base clock
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Manoj Iyer <[email protected]>
[ upstream commit 15bed0f2fa8e1d7db201692532c210a7823d2d21 ]
frequency
Ricoh 1180:e823 does not recognize certain types of SD/MMC cards, as reported at http://launchpad.net/bugs/773524. Lowering the SD base clock frequency from 200Mhz to 50Mhz fixes this issue. This solution was suggest by Koji Matsumuro, Ricoh Company, Ltd.
This change has no negative performance effect on standard SD cards, though it's quite possible that there will be one on UHS-1 cards.
drivers/pci/quirks.c +23 -0
@@ -2698,6 +2698,29 @@ static void ricoh_mmc_fixup_r5c832(strucdev_notice (&dev->dev,"proprietary Ricoh MMC controller disabled (via firewire function)\n" );dev_notice (&dev->dev,"MMC cards are now supported by standard SDHCI controller\n" ); + +/* +* RICOH 0xe823 SD/MMC card reader fails to recognize +* certain types of SD/MMC cards. Lowering the SD base +* clock frequency from 200Mhz to 50Mhz fixes this issue. +* +* 0x150 - SD2.0 mode enable for changing base clock +* frequency to 50Mhz +* 0xe1 - Base clock frequency +* 0x32 - 50Mhz new clock frequency +* 0xf9 - Key register for 0x150 +* 0xfc - key register for 0xe1 +*/ +if (dev->device ==PCI_DEVICE_ID_RICOH_R5CE823 ) { +pci_write_config_byte (dev,0xf9 ,0xfc ); +pci_write_config_byte (dev,0x150 ,0x10 ); +pci_write_config_byte (dev,0xf9 ,0x00 ); +pci_write_config_byte (dev,0xfc ,0x01 ); +pci_write_config_byte (dev,0xe1 ,0x32 ); +pci_write_config_byte (dev,0xfc ,0x00 ); + +dev_notice (&dev->dev,"MMC controller base frequency changed to 50Mhz.\n" ); + } }DECLARE_PCI_FIXUP_EARLY (PCI_VENDOR_ID_RICOH ,PCI_DEVICE_ID_RICOH_R5C832 , ricoh_mmc_fixup_r5c832);DECLARE_PCI_FIXUP_RESUME_EARLY (PCI_VENDOR_ID_RICOH ,PCI_DEVICE_ID_RICOH_R5C832 , ricoh_mmc_fixup_r5c832);
Re: [PATCH] [9/50] mmc: Added quirks for Ricoh 1180:e823 lower base clock
Dear Sir,
Ricoh 1180:e823 device is named R5U220/R5U232 (2 devices have the same device ID ).
So, I think it should be declared to as PCI_DEVICE_ID_RICOH_R5U220.
BTW, does anyone know whether the current SDHCI-driver sets 200Mhz to SD-CLK for UHS-I cards ?
Thanks,
Koji Matsumuro
Ricoh Company,Ltd.
Andi Kleen
<andi@firstfloor.
org> 宛先
[email protected],
2011/07/29 08:44 [email protected],
Koji Matsumuro/R/RICOH@RICOH,
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected]
cc
件名
[PATCH] [9/50] mmc: Added quirks
for Ricoh 1180:e823 lower base
clock 2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Manoj Iyer <[email protected]>
[ upstream commit 15bed0f2fa8e1d7db201692532c210a7823d2d21 ]
frequency
Ricoh 1180:e823 does not recognize certain types of SD/MMC cards, as reported at http://launchpad.net/bugs/773524. Lowering the SD base clock frequency from 200Mhz to 50Mhz fixes this issue. This solution was suggest by Koji Matsumuro, Ricoh Company, Ltd.
This change has no negative performance effect on standard SD cards, though it's quite possible that there will be one on UHS-1 cards.
drivers/pci/quirks.c +22 -0
@@ -2698,6 +2698,29 @@ static void ricoh_mmc_fixup_r5c832(struc dev_notice(&dev->dev, "proprietary Ricoh MMC controller disabled (via firewire function)\n");dev_notice (&dev->dev,"MMC cards are now supported by standard SDHCI controller\n"); + +/* +* RICOH 0xe823 SD/MMC card reader fails to recognize +* certain types of SD/MMC cards. Lowering the SD base +* clock frequency from 200Mhz to 50Mhz fixes this issue. +* +* 0x150 - SD2.0 mode enable for changing base clock +* frequency to 50Mhz +* 0xe1 - Base clock frequency +* 0x32 - 50Mhz new clock frequency +* 0xf9 - Key register for 0x150 +* 0xfc - key register for 0xe1 +*/ +if (dev->device ==PCI_DEVICE_ID_RICOH_R5CE823 ) { +pci_write_config_byte (dev,0xf9 ,0xfc ); +pci_write_config_byte (dev,0x150 ,0x10 ); +pci_write_config_byte (dev,0xf9 ,0x00 ); +pci_write_config_byte (dev,0xfc ,0x01 ); +pci_write_config_byte (dev,0xe1 ,0x32 ); +pci_write_config_byte (dev,0xfc ,0x00 ); + + dev_notice(&dev->dev, "MMC controller base frequency changed to
50Mhz.\n");
+ }
}
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832); DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832);
Re: [PATCH] [9/50] mmc: Added quirks for Ricoh 1180:e823 lower base clock
Quoted 5 lines · On Fri, Jul 29, 2011 at 09:27:56AM +0900, [email protected] wrote:
Dear Sir,
Ricoh 1180:e823 device is named R5U220/R5U232 (2 devices have the same device ID ).
So, I think it should be declared to asPCI_DEVICE_ID_RICOH_R5U220.
Is that just the wrong name or will it actually cause misfunction?
I will keep it if it's just the wrong name, but the name should be probably fixed upstream.
-Andi
Re: [PATCH] [9/50] mmc: Added quirks for Ricoh 1180:e823 lower base clock
It's no misfunction. Just the wrong name.
Koji Matsumuro
Andi Kleen <[email protected]> wrote on 2011/07/29 09:37:03:
Quoted 10 lines · On Fri, Jul 29, 2011 at 09:27:56AM +0900, [email protected] wrote:
Quoted 5 lines
Dear Sir,
Ricoh 1180:e823 device is named R5U220/R5U232 (2 devices have the same device ID ).
So, I think it should be declared to asPCI_DEVICE_ID_RICOH_R5U220.Is that just the wrong name or will it actually cause misfunction?
I will keep it if it's just the wrong name, but the name should be
probably
Quoted 3 lines
fixed upstream.
-Andi
Re: [PATCH] [9/50] mmc: Added quirks for Ricoh 1180:e823 lower base clock
In reply to Andi KleenHi,
Quoted 8 lines · Andi Kleen
Quoted 5 lines · On Fri, Jul 29, 2011 at 09:27:56AM +0900, [email protected] wrote:
Dear Sir,
Ricoh 1180:e823 device is named R5U220/R5U232 (2 devices have the same device ID ).
So, I think it should be declared to asPCI_DEVICE_ID_RICOH_R5U220.Is that just the wrong name or will it actually cause misfunction?
I don't think it could possibly cause misfunction; it's just a macro name.
Quoted 2 lines
BTW, does anyone know whether the current SDHCI-driver sets 200Mhz to SD-CLK for UHS-I cards ?
The Linux 3.1 SD driver will set the SD-CLK to 50MHz for every card on an e823 device, and older kernels will do so too once the commit has been applied to the stable trees. See this commit:
Do you know of a better solution than always lowering the clock speed to 50MHz for this controller?
Thanks,
- Chris.
Signature · 2 lines
Chris Ball <[email protected]> <http://printf.net/> One Laptop Per Child
Re: [PATCH] [9/50] mmc: Added quirks for Ricoh 1180:e823 lower base clock
Hi Chris,
Quoted 2 lines
Do you know of a better solution than always lowering the clock speed to 50MHz for this controller?
Yes, it is a better solution.
As you know, SD ver.1.1 and 2.0(SDHC) cards can be applied 50MHz SD-CLK.. SD 3.0 (UHS-I) cards also can be applied 50Mhz. However UHS-I cards are available 200 or 100Mhz SD-CLK.
I would like to know if the current SD Host driver has the function of setting SD-CLK to 200Mhz for SD ver3.0 compliant Host Controller.
Thanks,
Koji Matsumuro
Ricoh Company,Ltd.
Chris Ball <[email protected]> wrote on 2011/07/29 09:47:53:
Quoted 4 lines
Hi,
Quoted 1 line · Andi Kleen
On Fri, Jul 29, 2011 at 09:27:56AM +0900, [email protected]
Quoted 9 lines · wrote:
Quoted 7 lines
Quoted 5 lines
Dear Sir,
Ricoh 1180:e823 device is named R5U220/R5U232 (2 devices have the same device ID ).
So, I think it should be declared to asPCI_DEVICE_ID_RICOH_R5U220.Is that just the wrong name or will it actually cause misfunction?
I don't think it could possibly cause misfunction; it's just a macro
name.
Quoted 19 lines
Quoted 2 lines
BTW, does anyone know whether the current SDHCI-driver sets 200Mhz to SD-CLK for UHS-I cards ?
The Linux 3.1 SD driver will set the SD-CLK to 50MHz for every card on an e823 device, and older kernels will do so too once the commit has been applied to the stable trees. See this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;
a=commitdiff;h=15bed0f2fa8e1d7db201692532c210a7823d2d21Do you know of a better solution than always lowering the clock speed to 50MHz for this controller?
Thanks,
- Chris.
--
Chris Ball <[email protected]> <http://printf.net/>
One Laptop Per Child
Re: [PATCH] [9/50] mmc: Added quirks for Ricoh 1180:e823 lower base clock
Hi,
Quoted 5 lines · On Thu, Jul 28 2011, [email protected] wrote:
As you know, SD ver.1.1 and 2.0(SDHC) cards can be applied 50MHz SD-CLK.. SD 3.0 (UHS-I) cards also can be applied 50Mhz. However UHS-I cards are available 200 or 100Mhz SD-CLK.
I would like to know if the current SD Host driver has the function of setting SD-CLK to 200Mhz for SD ver3.0 compliant Host Controller.
Yes, we normally would set the higher clock rates for SDv3 controllers. We are only restricting to 50MHz on this Ricoh 0xe823 controller.
We added support for the SDR104 UHS-1 speeds in Linux 3.0, thanks to a patchset from Arindam Nath.
Thanks,
- Chris.
Signature · 2 lines
Chris Ball <[email protected]> <http://printf.net/> One Laptop Per Child
PATCH 10/50 Drop -Werror in perf
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Andi Kleen <[email protected]>
Drop -Werror in perf Makefile. This fixes the build with gcc 4.5.x
Not in mainline.
tools/perf/Makefile +1 -1
@@ -225,7 +225,7 @@ ifndef PERF_DEBUG CFLAGS_OPTIMIZE = -O6 endif -CFLAGS = -ggdb3 -Wall -Wextra -std=gnu99 -Werror $(CFLAGS_OPTIMIZE) -D_FORTIFY_SOURCE=2 $(EXTRA_WARNINGS) $(EXTRA_CFLAGS) +CFLAGS = -ggdb3 -Wall -Wextra -std=gnu99 $(CFLAGS_OPTIMIZE) -D_FORTIFY_SOURCE=2 $(EXTRA_WARNINGS) $(EXTRA_CFLAGS) EXTLIBS = -lpthread -lrt -lelf -lm ALL_CFLAGS = $(CFLAGS) -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 ALL_LDFLAGS = $(LDFLAGS)
PATCH 11/50 kexec, x86: Fix incorrect jump back address if not
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
[ upstream commit 050438ed5a05b25cdf287f5691e56a58c2606997 ]
preserving context
In kexec jump support, jump back address passed to the kexeced kernel via function calling ABI, that is, the function call return address is the jump back entry.
Furthermore, jump back entry == 0 should be used to signal that the jump back or preserve context is not enabled in the original kernel.
But in the current implementation the stack position used for function call return address is not cleared context preservation is disabled. The patch fixes this bug.
arch/x86/kernel/relocate_kernel_32.S +2 -0
@@ -97,6 +97,8 @@ relocate_kernel: ret identity_mapped: + /* set return address to 0 if not preserving context */ + pushl $0 /* store the start address on the stack */ pushl %edx
arch/x86/kernel/relocate_kernel_64.S +2 -0
@@ -100,6 +100,8 @@ relocate_kernel: ret identity_mapped: + /* set return address to 0 if not preserving context */ + pushq $0 /* store the start address on the stack */ pushq %rdx
PATCH 12/50 USB: serial: add IDs for WinChipHead USB->RS232 adapter
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Wolfgang Denk <[email protected]>
[ upstream commit 026dfaf18973404a01f488d6aa556a8c466e06a4 ]
Add ID 4348:5523 for WinChipHead USB->RS 232 adapter with Prolifec PL2303 chipset
drivers/usb/serial/pl2303.c +1 -0
@@ -91,6 +91,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(SONY_VENDOR_ID, SONY_QN3USB_PRODUCT_ID) }, { USB_DEVICE(SANWA_VENDOR_ID, SANWA_PRODUCT_ID) }, { USB_DEVICE(ADLINK_VENDOR_ID, ADLINK_ND6530_PRODUCT_ID) }, + { USB_DEVICE(WINCHIPHEAD_VENDOR_ID, WINCHIPHEAD_USBSER_PRODUCT_ID) }, { } /* Terminating entry */ };
drivers/usb/serial/pl2303.h +4 -0
@@ -144,3 +144,7 @@/* ADLINK ND-6530 RS232,RS485 and RS422 adapter */ #define ADLINK_VENDOR_ID 0x0b63#define ADLINK_ND6530_PRODUCT_ID 0x6530 + +/* WinChipHead USB->RS 232 adapter */ +#define WINCHIPHEAD_VENDOR_ID 0x4348 +#define WINCHIPHEAD_USBSER_PRODUCT_ID 0x5523
PATCH 13/50 davinci: DM365 EVM: fix video input mux bits
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jon Povey <[email protected]>
[ upstream commit 9daedd833a38edd90cf7baa1b1fcf61c3a0721e3 ]
Video input mux settings for tvp7002 and imager inputs were swapped. Comment was correct.
Tested on EVM with tvp7002 input.
arch/arm/mach-davinci/board-dm365-evm.c +2 -2
@@ -520,7 +520,7 @@ fail:*/ if (have_imager ()) { label ="HD imager" ; - mux |=1 ; + mux |=2 ;/* externally mux MMC1/ENET/AIC33 to imager */ mux |=BIT (6 ) |BIT (5 ) |BIT (3 );
@@ -541,7 +541,7 @@ fail: resets &= ~BIT (1 );if (have_tvp7002 ()) { - mux |=2 ; + mux |=1 ; resets &= ~BIT (2 ); label ="tvp7002 HD" ; }else {
PATCH 14/50 powerpc/pseries/hvconsole: Fix dropped console output
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Anton Blanchard <[email protected]>
[ upstream commit 51d33021425e1f905beb4208823146f2fb6517da ]
Return -EAGAIN when we get H_BUSY back from the hypervisor. This makes the hvc console driver retry, avoiding dropped printks.
arch/powerpc/platforms/pseries/hvconsole.c +1 -1
@@ -73,7 +73,7 @@ int hvc_put_chars(uint32_t vtermno, consif (ret ==H_SUCCESS )return count;if (ret ==H_BUSY ) -return 0 ; +return -EAGAIN ;return -EIO ; }
PATCH 15/50 hvc_console: Improve tty/console put_chars handling
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Hendrik Brueckner <[email protected]>
[ upstream commit 8c2381af0d3ef62a681dac5a141b6dabb27bf2e1 ]
Currently, the hvc_console_print() function drops console output if the hvc backend's put_chars() returns 0. This patch changes this behavior to allow a retry through returning -EAGAIN.
This change also affects the hvc_push() function. Both functions are changed to handle -EAGAIN and to retry the put_chars() operation.
If a hvc backend returns -EAGAIN, the retry handling differs:
- hvc_console_print() spins to write the complete console output.
- hvc_push() behaves the same way as for returning 0.
Now hvc backends can indirectly control the way how console output is handled through the hvc console layer.
drivers/char/hvc_console.c +5 -3
@@ -163,8 +163,10 @@ static void hvc_console_print(struct con }else { r = cons_ops[index]->put_chars (vtermnos[index], c, i);if (r <=0 ) { -/* throw away chars on error */ - i =0 ; +/* throw away characters on error +* but spin in case of -EAGAIN */ +if (r != -EAGAIN ) + i =0 ; }else if (r >0 ) { i -= r;if (i >0 )
@@ -448,7 +450,7 @@ static int hvc_push(struct hvc_struct *h n = hp->ops->put_chars (hp->vtermno, hp->outbuf, hp->n_outbuf);if (n <=0 ) { -if (n ==0 ) { +if (n ==0 || n == -EAGAIN ) { hp->do_wakeup =1 ;return 0 ; }
PATCH 16/50 powerpc/kdump: Fix timeout in crash_kexec_wait_realmode
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Michael Neuling <[email protected]>
[ upstream commit 63f21a56f1cc0b800a4c00349c59448f82473d19 ]
The existing code it pretty ugly. How about we clean it up even more like this?
From: Anton Blanchard <[email protected]>
We check for timeout expiry in the outer loop, but we also need to check it in the inner loop or we can lock up forever waiting for a CPU to hit real mode.
arch/powerpc/kernel/crash.c +1 -5
@@ -176,12 +176,8 @@ static void crash_kexec_wait_realmode(inwhile (paca[i].kexec_state <KEXEC_STATE_REAL_MODE ) {barrier (); -if (!cpu_possible (i)) { +if (!cpu_possible (i) || !cpu_online (i) || (msecs <=0 ))break ; - } -if (!cpu_online (i)) { -break ; - } msecs--;mdelay (1 ); }
PATCH 17/50 si4713-i2c: avoid potential buffer overflow on si4713
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <[email protected]>
[ upstream commit dc6b845044ccb7e9e6f3b7e71bd179b3cf0223b6 ]
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
While compiling it with Fedora 15, I noticed this issue:
inlined from ‘si4713_write_econtrol_string’ at drivers/media/radio/si4713-i2c.c:1065:24:
arch/x86/include/asm/uaccess_32.h:211:26: error: call to ‘copy_from_user_overflow’ declared with attribute error: copy_from_user() buffer size is not provably correct
drivers/media/radio/si4713-i2c.c +2 -2
@@ -1004,7 +1004,7 @@ static int si4713_write_econtrol_string(char ps_name[MAX_RDS_PS_NAME +1 ]; len = control->size -1 ; -if (len >MAX_RDS_PS_NAME ) { +if (len <0 || len >MAX_RDS_PS_NAME ) { rval = -ERANGE ; goto exit; }
@@ -1026,7 +1026,7 @@ static int si4713_write_econtrol_string(char radio_text[MAX_RDS_RADIO_TEXT +1 ]; len = control->size -1 ; -if (len >MAX_RDS_RADIO_TEXT ) { +if (len <0 || len >MAX_RDS_RADIO_TEXT ) { rval = -ERANGE ; goto exit; }
PATCH 18/50 hwmon: (max1111) Fix race condition causing NULL pointer
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Herrmann <[email protected]>
[ upstream commit d3f684f2820a7f42acef68bea6622d9032127fb2 ]
exception
spi_sync call uses its spi_message parameter to keep completion information, using a drvdata structure is not thread-safe. Use a mutex to prevent multiple access to shared driver data.
drivers/hwmon/max1111.c +11 -0
@@ -40,6 +40,8 @@ struct max1111_data {struct spi_transfer xfer[2 ];uint8_t *tx_buf;uint8_t *rx_buf; +struct mutex drvdata_lock; +/* protect msg, xfer and buffers from multiple access */ };static int max1111_read (struct device *dev,int channel)
@@ -48,6 +50,9 @@ static int max1111_read(struct device *duint8_t v1, v2;int err; +/* writing to drvdata struct is not thread safe, wait on mutex */ +mutex_lock (&data->drvdata_lock); + data->tx_buf[0 ] = (channel <<MAX1111_CTRL_SEL_SH ) |MAX1111_CTRL_PD0 |MAX1111_CTRL_PD1 |MAX1111_CTRL_SGL |MAX1111_CTRL_UNI |MAX1111_CTRL_STR ;
@@ -55,12 +60,15 @@ static int max1111_read(struct device *d err =spi_sync (data->spi, &data->msg);if (err <0 ) {dev_err (dev,"spi_sync failed with %d\n" , err); +mutex_unlock (&data->drvdata_lock);return err; } v1 = data->rx_buf[0 ]; v2 = data->rx_buf[1 ]; +mutex_unlock (&data->drvdata_lock); +if ((v1 &0xc0 ) || (v2 &0x3f ))return -EINVAL ;
@@ -176,6 +184,8 @@ static int __devinit max1111_probe(strucif (err) goto err_free_data; +mutex_init (&data->drvdata_lock); + data->spi = spi;spi_set_drvdata (spi, data);
@@ -213,6 +223,7 @@ static int __devexit max1111_remove(struhwmon_device_unregister (data->hwmon_dev);sysfs_remove_group (&spi->dev.kobj, &max1111_attr_group); +mutex_destroy (&data->drvdata_lock);kfree (data->rx_buf);kfree (data->tx_buf);kfree (data);
PATCH 19/50 hwmon: (asus_atk0110) Fix memory leak
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Luca Tettamanti <[email protected]>
[ upstream commit 0b8e77f12cb6bfe2e5a67f2cdc8c7af23abc4ccf ]
The object returned by atk_gitm is dynamically allocated and must be freed.
drivers/hwmon/asus_atk0110.c +1 -0
@@ -655,6 +655,7 @@ static int atk_debugfs_gitm_get(void *p,else err = -EIO ; +ACPI_FREE (ret);return err; }
PATCH 20/50 USB: OHCI: fix another regression for NVIDIA controllers
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
[ upstream commit 6ea12a04d295235ed67010a09fdea58c949e3eb0 ]
The NVIDIA series of OHCI controllers continues to be troublesome. A few people using the MCP67 chipset have reported that even with the most recent kernels, the OHCI controller fails to handle new connections and spams the system log with "unable to enumerate USB port" messages. This is different from the other problems previously reported for NVIDIA OHCI controllers, although it is probably related.
It turns out that the MCP67 controller does not like to be kept in the RESET state very long. After only a few seconds, it decides not to work any more. This patch (as1479) changes the PCI initialization quirk code so that NVIDIA controllers are switched into the SUSPEND state after 50 ms of RESET. With no interrupts enabled and all the downstream devices reset, and thus unable to send wakeup requests, this should be perfectly safe (even for non-NVIDIA hardware).
The removal code in ohci-hcd hasn't been changed; it will still leave the controller in the RESET state. As a result, if someone unloads ohci-hcd and then reloads it, the controller won't work again until the system is rebooted. If anybody complains about this, the removal code can be updated similarly.
This fixes Bugzilla #22052.
drivers/usb/host/pci-quirks.c +28 -0
@@ -34,6 +34,8 @@#define OHCI_INTRSTATUS 0x0c#define OHCI_INTRENABLE 0x10#define OHCI_INTRDISABLE 0x14 +#define OHCI_FMINTERVAL 0x34 +#define OHCI_HCR (1 << 0)/* host controller reset */ #define OHCI_OCR (1 << 3)/* ownership change request */ #define OHCI_CTRL_RWC (1 << 9)/* remote wakeup connected */ #define OHCI_CTRL_IR (1 << 8)/* interrupt routing */
@@ -204,6 +206,32 @@ static void __devinit quirk_usb_handoff_/* reset controller, preserving RWC (and possibly IR) */ writel (control &OHCI_CTRL_MASK , base +OHCI_CONTROL ); +readl (base +OHCI_CONTROL ); + +/* Some NVIDIA controllers stop working if kept in RESET for too long */ +if (pdev->vendor ==PCI_VENDOR_ID_NVIDIA ) { +u32 fminterval; +int cnt; + +/* drive reset for at least 50 ms (7.1.7.5) */ +msleep (50 ); + +/* software reset of the controller, preserving HcFmInterval */ + fminterval =readl (base +OHCI_FMINTERVAL ); +writel (OHCI_HCR , base +OHCI_CMDSTATUS ); + +/* reset requires max 10 us delay */ +for (cnt =30 ; cnt >0 ; --cnt) {/* ... allow extra time */ +if ((readl (base +OHCI_CMDSTATUS ) &OHCI_HCR ) ==0 ) +break ; +udelay (1 ); + } +writel (fminterval, base +OHCI_FMINTERVAL ); + +/* Now we're in the SUSPEND state with all devices reset +* and wakeups and interrupts disabled +*/ + }/* * disable interrupts
PATCH 21/50 firewire: cdev: prevent race between first get_info ioctl
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Richter <[email protected]>
[ upstream commit 93b37905f70083d6143f5f4dba0a45cc64379a62 ]
and bus reset event queuing
Between open(2) of a /dev/fw* and the first FW_CDEV_IOC_GET_INFO ioctl(2) on it, the kernel already queues FW_CDEV_EVENT_BUS_RESET events to be read(2) by the client. The get_info ioctl is practically always issued right away after open, hence this condition only occurs if the client opens during a bus reset, especially during a rapid series of bus resets.
The problem with this condition is twofold:
- These bus reset events carry the (as yet undocumented) @closure value of 0. But it is not the kernel's place to choose closures; they are privat to the client. E.g., this 0 value forced from the kernel makes it unsafe for clients to dereference it as a pointer to a closure object without NULL pointer check.
- It is impossible for clients to determine the relative order of bus reset events from get_info ioctl(2) versus those from read(2), except in one way: By comparison of closure values. Again, such a procedure imposes complexity on clients and reduces freedom in use of the bus reset closure.
So, change the ABI to suppress queuing of bus reset events before the first FW_CDEV_IOC_GET_INFO ioctl was issued by the client.
Note, this ABI change cannot be version-controlled. The kernel cannot distinguish old from new clients before the first FW_CDEV_IOC_GET_INFO ioctl.
We will try to back-merge this change into currently maintained stable/ longterm series, and we only document the new behaviour. The old behavior is now considered a kernel bug, which it basically is.
drivers/firewire/core-cdev.c +10 -8
@@ -219,14 +219,11 @@ static int fw_device_op_open(struct inodidr_init (&client->resource_idr);INIT_LIST_HEAD (&client->event_list);init_waitqueue_head (&client->wait); +INIT_LIST_HEAD (&client->link);kref_init (&client->kref); file->private_data = client; -mutex_lock (&device->client_list_mutex); -list_add_tail (&client->link, &device->client_list); -mutex_unlock (&device->client_list_mutex); -return nonseekable_open (inode, file); }
@@ -414,15 +411,20 @@ static int ioctl_get_info(struct clientif (ret !=0 )return -EFAULT ; +mutex_lock (&client->device->client_list_mutex); + client->bus_reset_closure = a->bus_reset_closure;if (a->bus_reset !=0 ) {fill_bus_reset_event (&bus_reset, client); -if (copy_to_user (u64_to_uptr (a->bus_reset), - &bus_reset,sizeof (bus_reset))) -return -EFAULT ; + ret =copy_to_user (u64_to_uptr (a->bus_reset), + &bus_reset,sizeof (bus_reset)); } +if (ret ==0 &&list_empty (&client->link)) +list_add_tail (&client->link, &client->device->client_list); -return 0 ; +mutex_unlock (&client->device->client_list_mutex); + +return ret ? -EFAULT :0 ; } static int add_client_resource(struct client *client,
include/linux/firewire-cdev.h +3 -0
@@ -284,6 +284,9 @@ union fw_cdev_event {* of the bus. This does not cause a bus reset to happen. * @bus_reset_closure: Value of &closure in this and subsequent bus reset events * @card: The index of the card this device belongs to +* +* As a side effect, reception of %FW_CDEV_EVENT_BUS_RESET events to be read(2) +* is started by this ioctl. */ struct fw_cdev_get_info {__u32 version;
PATCH 22/50 firewire: cdev: return -ENOTTY for unimplemented ioctls, not
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Richter <[email protected]>
[ upstream commit d873d794235efa590ab3c94d5ee22bb1fab19ac4 ]
-EINVAL
Quoted 5 lines · On Jun 27 Linus Torvalds wrote:
The correct error code for "I don't understand this ioctl" is ENOTTY. The naming may be odd, but you should think of that error value as a "unrecognized ioctl number, you're feeding me random numbers that I don't understand and I assume for historical reasons that you tried to do some tty operation on me".
[...]
Quoted 13 lines
The EINVAL thing goes way back, and is a disaster. It predates Linux itself, as far as I can tell. You'll find lots of man-pages that have this line in it:
EINVAL Request or argp is not valid.
and it shows up in POSIX etc. And sadly, it generally shows up _before_ the line that says
ENOTTY The specified request does not apply to the kind of object
that the descriptor d references.so a lot of people get to the EINVAL, and never even notice the ENOTTY.
[...]
Quoted 3 lines
At least glibc (and hopefully other C libraries) use a _string_ that makes much more sense: strerror(ENOTTY) is "Inappropriate ioctl for device"
So let's correct this in the <linux/firewire-cdev.h> ABI while it is still young, relative to distributor adoption.
Side note: We return -ENOTTY not only on _IOC_TYPE or _IOC_NR mismatch, but also on _IOC_SIZE mismatch. An ioctl with an unsupported size of argument structure can be seen as an unsupported version of that ioctl.
drivers/firewire/core-cdev.c +1 -1
@@ -1361,7 +1361,7 @@ static int dispatch_ioctl(struct clientif (_IOC_TYPE (cmd) !='#' ||_IOC_NR (cmd) >=ARRAY_SIZE (ioctl_handlers) ||_IOC_SIZE (cmd) >sizeof (buffer)) -return -EINVAL ; +return -ENOTTY ;if (_IOC_DIR (cmd) == _IOC_READ)memset (&buffer,0 ,_IOC_SIZE (cmd));
PATCH 23/50 svcrpc: fix list-corrupting race on nfsd shutdown
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: J. Bruce Fields <[email protected]>
[ upstream commit ebc63e531cc6a457595dd110b07ac530eae788c3 ]
After commit 3262c816a3d7fb1eaabce633caa317887ed549ae "[PATCH] knfsd:
split svc_serv into pools", svc_delete_xprt (then svc_delete_socket) no longer removed its xpt_ready (then sk_ready) field from whatever list it was on, noting that there was no point since the whole list was about to be destroyed anyway.
That was mostly true, but forgot that a few svc_xprt_enqueue()'s might still be hanging around playing with the about-to-be-destroyed list, and could get themselves into trouble writing to freed memory if we left this xprt on the list after freeing it.
(This is actually functionally identical to a patch made first by Ben Greear, but with more comments.)
net/sunrpc/svc_xprt.c +6 -5
@@ -894,12 +894,13 @@ void svc_delete_xprt(struct svc_xprt *xpif (!test_and_set_bit (XPT_DETACHED , &xprt->xpt_flags))list_del_init (&xprt->xpt_list);/* -* We used to delete the transport from whichever list -* it's sk_xprt.xpt_ready node was on, but we don't actually -* need to. This is because the only time we're called -* while still attached to a queue, the queue itself -* is about to be destroyed (in svc_destroy). +* The only time we're called while xpt_ready is still on a list +* is while the list itself is about to be destroyed (in +* svc_destroy). BUT svc_xprt_enqueue could still be attempting +* to add new entries to the sp_sockets list, so we can't leave +* a freed xprt on it. */ +list_del_init (&xprt->xpt_ready);if (test_bit (XPT_TEMP , &xprt->xpt_flags)) serv->sv_tmpcnt--;spin_unlock_bh (&serv->sv_lock);
PATCH 24/50 x86: Look for IA32_ENERGY_PERF_BIAS support
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Venkatesh Pallipadi <[email protected]>
[ upstream commit 23016bf0 ]
The new IA32_ENERGY_PERF_BIAS MSR allows system software to give hardware a hint whether OS policy favors more power saving, or more performance. This allows the OS to have some influence on internal hardware power/performance tradeoffs where the OS has previously had no influence.
The support for this feature is indicated by CPUID.06H.ECX.bit3, as documented in the Intel Architectures Software Developer's Manual.
This patch discovers support of this feature and displays it as "epb" in /proc/cpuinfo.
LKML-Reference: <[email protected]>
arch/x86/include/asm/cpufeature.h +1 -0
@@ -162,6 +162,7 @@#define X86_FEATURE_IDA (7*32+ 0)/* Intel Dynamic Acceleration */ #define X86_FEATURE_ARAT (7*32+ 1)/* Always Running APIC Timer */ #define X86_FEATURE_CPB (7*32+ 2)/* AMD Core Performance Boost */ +#define X86_FEATURE_EPB (7*32+ 3)/* IA32_ENERGY_PERF_BIAS support */ /* Virtualization flags: Linux defined */ #define X86_FEATURE_TPR_SHADOW (8*32+ 0)/* Intel TPR Shadow */
arch/x86/include/asm/msr-index.h +2 -0
@@ -243,6 +243,8 @@#define MSR_IA32_TEMPERATURE_TARGET 0x000001a2 +#define MSR_IA32_ENERGY_PERF_BIAS 0x000001b0 +/* MISC_ENABLE bits: architectural */ #define MSR_IA32_MISC_ENABLE_FAST_STRING (1ULL << 0)#define MSR_IA32_MISC_ENABLE_TCC (1ULL << 1)
arch/x86/kernel/cpu/addon_cpuid_features.c +1 -0
@@ -33,6 +33,7 @@ void __cpuinit init_scattered_cpuid_feat { X86_FEATURE_IDA, CR_EAX, 1, 0x00000006 }, { X86_FEATURE_ARAT, CR_EAX, 2, 0x00000006 }, { X86_FEATURE_APERFMPERF, CR_ECX, 0, 0x00000006 }, + { X86_FEATURE_EPB, CR_ECX, 3, 0x00000006 }, { X86_FEATURE_CPB, CR_EDX, 9, 0x80000007 }, { X86_FEATURE_NPT, CR_EDX, 0, 0x8000000a }, { X86_FEATURE_LBRV, CR_EDX, 1, 0x8000000a },
PATCH 25/50 x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Len Brown <[email protected]>
[ upstream commit abe48b108247e9b90b4c6739662a2e5c765ed114 ]
Since 2.6.36 (23016bf0d25), Linux prints the existence of "epb" in /proc/cpuinfo, Since 2.6.38 (d5532ee7b40), the x86_energy_perf_policy(8) utility has been available in-tree to update MSR_IA32_ENERGY_PERF_BIAS.
However, the typical BIOS fails to initialize the MSR, presumably because this is handled by high-volume shrink-wrap operating systems...
Linux distros, on the other hand, do not yet invoke x86_energy_perf_policy(8). As a result, WSM-EP, SNB, and later hardware from Intel will run in its default hardware power-on state (performance), which assumes that users care for performance at all costs and not for energy efficiency. While that is fine for performance benchmarks, the hardware's intended default operating point is "normal" mode...
Initialize the MSR to the "normal" by default during kernel boot.
x86_energy_perf_policy(8) is available to change the default after boot, should the user have a different preference.
arch/x86/include/asm/msr-index.h +5 -0
@@ -231,6 +231,11 @@#define THERM_INT_LOW_ENABLE (1 << 0)#define THERM_INT_HIGH_ENABLE (1 << 1) +#define MSR_IA32_ENERGY_PERF_BIAS 0x000001b0 +#define ENERGY_PERF_BIAS_PERFORMANCE 0 +#define ENERGY_PERF_BIAS_NORMAL 6 +#define ENERGY_PERF_BIAS_POWERSWAVE 15 +#define MSR_IA32_THERM_STATUS 0x0000019c#define THERM_STATUS_PROCHOT (1 << 0)
arch/x86/kernel/cpu/intel.c +18 -0
@@ -450,6 +450,24 @@ static void __cpuinit init_intel(structif (cpu_has (c,X86_FEATURE_VMX ))detect_vmx_virtcap (c); + +/* +* Initialize MSR_IA32_ENERGY_PERF_BIAS if BIOS did not. +* x86_energy_perf_policy(8) is available to change it at run-time +*/ +if (cpu_has (c,X86_FEATURE_EPB )) { +u64 epb; + +rdmsrl (MSR_IA32_ENERGY_PERF_BIAS , epb); +if ((epb &0xF ) ==0 ) { +printk_once (KERN_WARNING ,"x86: updated energy_perf_bias" +" to 'normal' from 'performance'\n" +"You can view and update epb via utility," +" such as x86_energy_perf_policy(8)\n" ); + epb = (epb & ~0xF ) |ENERGY_PERF_BIAS_NORMAL ; +wrmsrl (MSR_IA32_ENERGY_PERF_BIAS , epb); + } + } }#ifdef CONFIG_X86_32
PATCH 26/50 SUNRPC: Fix use of static variable in rpcb_getport_async
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Ben Greear <[email protected]>
[ upstream commit ec0dd267bf7d08cb30e321e45a75fd40edd7e528 ]
Because struct rpcbind_args *map was declared static, if two threads entered this method at the same time, the values assigned to map could be sent two two differen tasks. This could cause all sorts of problems, include use-after-free and double-free of memory.
Fix this by removing the static declaration so that the map pointer is on the stack.
net/sunrpc/rpcb_clnt.c +1 -1
@@ -580,7 +580,7 @@ void rpcb_getport_async(struct rpc_tasku32 bind_version;struct rpc_xprt *xprt;struct rpc_clnt *rpcb_clnt; -static struct rpcbind_args *map; +struct rpcbind_args *map;struct rpc_task *child;struct sockaddr_storage addr;struct sockaddr *sap = (struct sockaddr *)&addr;
PATCH 27/50 ARM: pxa/cm-x300: fix V3020 RTC functionality
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Igor Grinberg <[email protected]>
[ upstream commit 6c7b3ea52e345ab614edb91d3f0e9f3bb3713871 ]
While in sleep mode the CS# and other V3020 RTC GPIOs must be driven high, otherwise V3020 RTC fails to keep the right time in sleep mode.
arch/arm/mach-pxa/cm-x300.c +4 -4
@@ -157,10 +157,10 @@ static mfp_cfg_t cm_x3xx_mfp_cfg[] __iniGPIO99_GPIO ,/* Ethernet IRQ */ /* RTC GPIOs */ -GPIO95_GPIO ,/* RTC CS */ -GPIO96_GPIO ,/* RTC WR */ -GPIO97_GPIO ,/* RTC RD */ -GPIO98_GPIO ,/* RTC IO */ +GPIO95_GPIO |MFP_LPM_DRIVE_HIGH ,/* RTC CS */ +GPIO96_GPIO |MFP_LPM_DRIVE_HIGH ,/* RTC WR */ +GPIO97_GPIO |MFP_LPM_DRIVE_HIGH ,/* RTC RD */ +GPIO98_GPIO ,/* RTC IO */ /* Standard I2C */ GPIO21_I2C_SCL,
PATCH 28/50 firewire: ohci: do not bind to Pinnacle cards, avert panic
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Richter <[email protected]>
[ upstream commit 7f7e37115a8b6724f26d0637a04e1d35e3c59717 ]
When firewire-ohci is bound to a Pinnacle MovieBoard, eventually a "Register access failure" is logged and an interrupt storm or a kernel panic happens. https://bugzilla.kernel.org/show_bug.cgi?id=36622
Until this is sorted out (if that is going to succeed at all), let's just prevent firewire-ohci from touching these devices.
drivers/firewire/ohci.c +6 -0
@@ -232,6 +232,7 @@ static inline struct fw_ohci *fw_ohci(ststatic char ohci_driver_name[] =KBUILD_MODNAME ;#define PCI_DEVICE_ID_TI_TSB12LV22 0x8009 +#define PCI_VENDOR_ID_PINNACLE_SYSTEMS 0x11bd#define QUIRK_CYCLE_TIMER 1#define QUIRK_RESET_PACKET 2
@@ -2480,6 +2481,11 @@ static int __devinit pci_probe(struct pcint i, err, n_ir, n_it;size_t size; +if (dev->vendor ==PCI_VENDOR_ID_PINNACLE_SYSTEMS ) { +dev_err (&dev->dev,"Pinnacle MovieBoard is not yet supported\n" ); +return -ENOSYS ; + } + ohci =kzalloc (sizeof (*ohci),GFP_KERNEL );if (ohci ==NULL ) { err = -ENOMEM ;
PATCH 29/50 mm/nommu.c: fix remap_pfn_range()
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Bob Liu <[email protected]>
[ upstream commit 8f3b1327aa454bc8283e96bca7669c3c88b83f79 ]
remap_pfn_range() means map physical address pfn<<PAGE_SHIFT to user addr.
For nommu arch it's implemented by vma->vm_start = pfn << PAGE_SHIFT which is wrong acroding the original meaning of this function. And some driver developer using remap_pfn_range() with correct parameter will get unexpected result because vm_start is changed. It should be implementd like addr = pfn << PAGE_SHIFT but which is meanless on nommu arch, this patch just make it simply return.
Parameter name and setting of vma->vm_flags also be fixed.
mm/nommu.c +6 -3
@@ -1747,10 +1747,13 @@ struct page *follow_page(struct vm_area_return NULL ; } -int remap_pfn_range (struct vm_area_struct *vma,unsigned long from, -unsigned long to,unsigned long size,pgprot_t prot) +int remap_pfn_range (struct vm_area_struct *vma,unsigned long addr, +unsigned long pfn,unsigned long size,pgprot_t prot) { - vma->vm_start = vma->vm_pgoff <<PAGE_SHIFT ; +if (addr != (pfn <<PAGE_SHIFT )) +return -EINVAL ; + + vma->vm_flags |=VM_IO |VM_RESERVED |VM_PFNMAP ;return 0 ; }EXPORT_SYMBOL (remap_pfn_range);
PATCH 30/50 EHCI: only power off port if over-current is active
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Sergei Shtylyov <[email protected]>
[ upstream commit 81463c1d707186adbbe534016cd1249edeab0dac ]
MAX4967 USB power supply chip we use on our boards signals over-current when power is not enabled; once it's enabled, over-current signal returns to normal. That unfortunately caused the endless stream of "over-current change on port" messages. The EHCI root hub code reacts on every over-current signal change with powering off the port -- such change event is generated the moment the port power is enabled, so once enabled the power is immediately cut off. I think we should only cut off power when we're seeing the active over-current signal, so I'm adding such check to that code. I also think that the fact that we've cut off the port power should be reflected in the result of GetPortStatus request immediately, hence I'm adding a PORTSCn register readback after write...
drivers/usb/host/ehci-hub.c +2 -1
@@ -837,10 +837,11 @@ static int ehci_hub_control (* power switching; they're allowed to just limit the * current. khubd will turn the power back on. */ -if (HCS_PPC (ehci->hcs_params)){ +if ((temp &PORT_OC ) &&HCS_PPC (ehci->hcs_params)) {ehci_writel (ehci, temp & ~(PORT_RWC_BITS |PORT_POWER ), status_reg); + temp =ehci_readl (ehci, status_reg); } }
PATCH 31/50 mac80211: Restart STA timers only on associated state
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Rajkumar Manoharan <[email protected]>
[ upstream commit 676b58c27475a9defccc025fea1cbd2b141ee539 ]
A panic was observed when the device is failed to resume properly, and there are no running interfaces. ieee80211_reconfig tries to restart STA timers on unassociated state.
net/mac80211/mlme.c +3 -0
@@ -1995,6 +1995,9 @@ void ieee80211_sta_restart(struct ieee80 {struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; +if (!ifmgd->associated) +return ; +if (test_and_clear_bit (TMR_RUNNING_TIMER , &ifmgd->timers_running))add_timer (&ifmgd->timer);if (test_and_clear_bit (TMR_RUNNING_CHANSW , &ifmgd->timers_running))
PATCH 32/50 usb: musb: restore INDEX register in resume path
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Ajay Kumar Gupta <[email protected]>
[ upstream commit 3c5fec75e121b21a2eb35e5a6b44291509abba6f ]
Restoring the missing INDEX register value in musb_restore_context(). Without this suspend resume functionality is broken with offmode enabled.
drivers/usb/musb/musb_core.c +1 -0
@@ -1697,6 +1697,7 @@ void musb_dma_completion(struct musb *mu } } } +musb_writeb (musb_base,MUSB_INDEX , musb->context.index); }#else
PATCH 33/50 SUNRPC: Fix a race between work-queue and rpc_killall_tasks
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
[ upstream commit b55c59892e1f3b6c7d4b9ccffb4263e1486fb990 ]
Since rpc_killall_tasks may modify the rpc_task's tk_action field without any locking, we need to be careful when dereferencing it.
net/sunrpc/sched.c +11 -16
@@ -623,30 +623,25 @@ static void __rpc_execute(struct rpc_tasBUG_ON (RPC_IS_QUEUED (task));for (;;) { +void (*do_action)(struct rpc_task *);/* -* Execute any pending callback. +* Execute any pending callback first. */ -if (task->tk_callback) { -void (*save_callback)(struct rpc_task *); - -/* -* We set tk_callback to NULL before calling it, -* in case it sets the tk_callback field itself: -*/ - save_callback = task->tk_callback; - task->tk_callback =NULL ; -save_callback (task); - }else { + do_action = task->tk_callback; + task->tk_callback =NULL ; +if (do_action ==NULL ) {/* * Perform the next FSM step. -* tk_action may be NULL when the task has been killed -* by someone else. +* tk_action may be NULL if the task has been killed. +* In particular, note that rpc_killall_tasks may +* do this at any time, so beware when dereferencing. */ -if (task->tk_action ==NULL ) + do_action = task->tk_action; +if (do_action ==NULL )break ; - task->tk_action (task); } +do_action (task);/* * Lockless check for whether task is sleeping or not.
PATCH 34/50 bttv: fix s_tuner for radio
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
[ upstream commit a024c1a6b274e11596d124619e43c25560f64c01 ]
Fix typo: g_tuner should have been s_tuner.
Tested with a bttv card.
drivers/media/video/bt8xx/bttv-driver.c +1 -1
@@ -3525,7 +3525,7 @@ static int radio_s_tuner(struct file *fiif (0 != t->index)return -EINVAL ; -bttv_call_all (btv, tuner, g_tuner, t); +bttv_call_all (btv, tuner, s_tuner, t);return 0 ; }
PATCH 35/50 pvrusb2: fix g/s_tuner support
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
[ upstream commit 50e9efd60b213ce43ad6979bfc18e25eec2d8413 ]
The tuner-core subdev requires that the type field of v4l2_tuner is filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't use that yet, so we have to do it manually based on whether the current input is radio or not.
Tested with my pvrusb2.
drivers/media/video/pvrusb2/pvrusb2-hdw.c +4 -0
@@ -3039,6 +3039,8 @@ static void pvr2_subdev_update(struct pvif (hdw->input_dirty || hdw->audiomode_dirty || hdw->force_dirty) {struct v4l2_tuner vt;memset (&vt,0 ,sizeof (vt)); + vt.type = (hdw->input_val ==PVR2_CVAL_INPUT_RADIO ) ? +V4L2_TUNER_RADIO :V4L2_TUNER_ANALOG_TV ; vt.audmode = hdw->audiomode_val;v4l2_device_call_all (&hdw->v4l2_dev,0 , tuner, s_tuner, &vt); }
@@ -5163,6 +5165,8 @@ void pvr2_hdw_status_poll(struct pvr2_hd {struct v4l2_tuner *vtp = &hdw->tuner_signal_info;memset (vtp,0 ,sizeof (*vtp)); + vtp->type = (hdw->input_val ==PVR2_CVAL_INPUT_RADIO ) ? +V4L2_TUNER_RADIO :V4L2_TUNER_ANALOG_TV ; hdw->tuner_signal_stale =0 ;/* Note: There apparently is no replacement for VIDIOC_CROPCAP using v4l2-subdev - therefore we can't support that AT ALL right
PATCH 36/50 v4l2-ioctl.c: prefill tuner type for g_frequency and
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
[ upstream commit 227690df75382e46a4f6ea1bbc5df855a674b47f ]
g/s_tuner
The subdevs are supposed to receive a valid tuner type for the g_frequency and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill this in v4l2-ioctl.c based on whether the device node from which this is called is a radio node or not.
The spec does not require applications to fill in the type, and if they leave it at 0 then the 'check_mode' call in tuner-core.c will return an error and the ioctl does nothing.
drivers/media/video/v4l2-ioctl.c +6 -0
@@ -1644,6 +1644,8 @@ static long __video_do_ioctl(struct fileif (!ops->vidioc_g_tuner)break ; + p->type = (vfd->vfl_type ==VFL_TYPE_RADIO ) ? +V4L2_TUNER_RADIO :V4L2_TUNER_ANALOG_TV ; ret = ops->vidioc_g_tuner (file, fh, p);if (!ret) dbgarg(cmd, "index=%d, name=%s, type=%d, "
@@ -1662,6 +1664,8 @@ static long __video_do_ioctl(struct fileif (!ops->vidioc_s_tuner)break ; + p->type = (vfd->vfl_type ==VFL_TYPE_RADIO ) ? +V4L2_TUNER_RADIO :V4L2_TUNER_ANALOG_TV ;dbgarg (cmd,"index=%d, name=%s, type=%d, " "capability=0x%x, rangelow=%d, " "rangehigh=%d, signal=%d, afc=%d, "
@@ -1680,6 +1684,8 @@ static long __video_do_ioctl(struct fileif (!ops->vidioc_g_frequency)break ; + p->type = (vfd->vfl_type ==VFL_TYPE_RADIO ) ? +V4L2_TUNER_RADIO :V4L2_TUNER_ANALOG_TV ; ret = ops->vidioc_g_frequency (file, fh, p);if (!ret) dbgarg(cmd, "tuner=%d, type=%d, frequency=%d\n",
PATCH 37/50 mac80211: fix TKIP replay vulnerability
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
[ upstream commit 34459512ffa7236c849466e3bd604801389734e1 ]
Unlike CCMP, the presence or absence of the QoS field doesn't change the encryption, only the TID is used. When no QoS field is present, zero is used as the TID value. This means that it is possible for an attacker to take a QoS packet with TID 0 and replay it as a non-QoS packet.
Unfortunately, mac80211 uses different IVs for checking the validity of the packet's TKIP IV when it checks TID 0 and when it checks non-QoS packets. This means it is vulnerable to this replay attack.
To fix this, use the same replay counter for TID 0 and non-QoS packets by overriding the rx->queue value to 0 if it is 16 (non-QoS).
This is a minimal fix for now. I caused this issue in
commit 1411f9b531f0a910cd1c85a337737c1e6ffbae6a
Author: Johannes Berg <[email protected]> Date: Thu Jul 10 10:11:02 2008 +0200
mac80211: fix RX sequence number check
while fixing a sequence number issue (there, a separate counter needs to be used).
[AK: This was a non trivial backport. Johannes, John, please double check]
net/mac80211/wpa.c +13 -3
@@ -89,6 +89,11 @@ ieee80211_rx_h_michael_mic_verify(structstruct ieee80211_rx_status *status =IEEE80211_SKB_RXCB (skb);struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;int authenticator =1 , wpa_test =0 ; +int queue = rx->queue; + +/* otherwise, TKIP is vulnerable to TID 0 vs. non-QoS replays */ +if (rx->queue ==NUM_RX_DATA_QUEUES -1 ) + queue =0 ;/* No way to verify the MIC if the hardware stripped it */ if (status->flag &RX_FLAG_MMIC_STRIPPED )
@@ -130,8 +135,8 @@ ieee80211_rx_h_michael_mic_verify(structskb_trim (skb, skb->len -MICHAEL_MIC_LEN );/* update IV in key information to be able to detect replays */ - rx->key->u.tkip.rx[rx->queue].iv32 = rx->tkip_iv32; - rx->key->u.tkip.rx[rx->queue].iv16 = rx->tkip_iv16; + rx->key->u.tkip.rx[queue].iv32 = rx->tkip_iv32; + rx->key->u.tkip.rx[queue].iv16 = rx->tkip_iv16;return RX_CONTINUE ; }
@@ -213,6 +218,11 @@ ieee80211_crypto_tkip_decrypt(struct ieestruct ieee80211_key *key = rx->key;struct sk_buff *skb = rx->skb;struct ieee80211_rx_status *status =IEEE80211_SKB_RXCB (skb); +int queue = rx->queue; + +/* otherwise, TKIP is vulnerable to TID 0 vs. non-QoS replays */ +if (rx->queue ==NUM_RX_DATA_QUEUES -1 ) + queue =0 ; hdrlen =ieee80211_hdrlen (hdr->frame_control);
@@ -239,7 +249,7 @@ ieee80211_crypto_tkip_decrypt(struct iee res =ieee80211_tkip_decrypt_data (rx->local->wep_rx_tfm, key, skb->data + hdrlen, skb->len - hdrlen, rx->sta->sta.addr, - hdr->addr1, hwaccel, rx->queue, + hdr->addr1, hwaccel, queue, &rx->tkip_iv32, &rx->tkip_iv16);if (res !=TKIP_DECRYPT_OK || wpa_test)
PATCH 38/50 ASoC: ak4642: fixup snd_soc_update_bits mask for PW_MGMT2
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Kuninori Morimoto <[email protected]>
[ upstream commit bd7fdbcaa2d06d446577fd3c9b81847b04469e01 ]
mask didn't cover update-data
sound/soc/codecs/ak4642.c +1 -1
@@ -319,7 +319,7 @@ static int ak4642_dai_set_fmt(struct snddefault :return -EINVAL ; } -snd_soc_update_bits (codec,PW_MGMT2 ,MS , data); +snd_soc_update_bits (codec,PW_MGMT2 ,MS |MCKO |PMPLL , data);snd_soc_update_bits (codec,MD_CTL1 ,BCKO_MASK , bcko);return 0 ;
PATCH 39/50 tracing: Fix bug when reading system filters on module
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
[ upstream commit e9dbfae53eeb9fc3d4bb7da3df87fa9875f5da02 ]
removal
The event system is freed when its nr_events is set to zero. This happens when a module created an event system and then later the module is removed. Modules may share systems, so the system is allocated when it is created and freed when the modules are unloaded and all the events under the system are removed (nr_events set to zero).
The problem arises when a task opened the "filter" file for the system. If the module is unloaded and it removed the last event for that system, the system structure is freed. If the task that opened the filter file accesses the "filter" file after the system has been freed, the system will access an invalid pointer.
By adding a ref_count, and using it to keep track of what is using the event system, we can free it after all users are finished with the event system.
kernel/trace/trace.h +1 -0
@@ -731,6 +731,7 @@ struct event_subsystem {struct dentry *entry;struct event_filter *filter;int nr_events; +int ref_count; };struct filter_pred ;
kernel/trace/trace_events.c +75 -11
132 lines not on this page · raw message
kernel/trace/trace_events_filter.c +6 -0
@@ -1340,6 +1340,12 @@ int apply_subsystem_event_filter(structif (err) goto out_unlock; +/* Make sure the system still has events */ +if (!system->nr_events) { + err = -ENODEV ; + goto out_unlock; + } +if (!strcmp (strstrip (filter_string),"0" )) {filter_free_subsystem_preds (system);remove_filter_string (system->filter);
PATCH 40/50 tracing: Have "enable" file use refcounts like the "filter"
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
[ upstream commit 40ee4dffff061399eb9358e0c8fcfbaf8de4c8fe ]
file
The "enable" file for the event system can be removed when a module is unloaded and the event system only has events from that module. As the event system nr_events count goes to zero, it may be freed if its ref_count is also set to zero.
Like the "filter" file, the "enable" file may be opened by a task and referenced later, after a module has been unloaded and the events for that event system have been removed.
Although the "filter" file referenced the event system structure, the "enable" file only references a pointer to the event system name. Since the name is freed when the event system is removed, it is possible that an access to the "enable" file may reference a freed pointer.
Update the "enable" file to use the subsystem_open() routine that the "filter" file uses, to keep a reference to the event system structure while the "enable" file is opened.
kernel/trace/trace_events.c +22 -9
@@ -495,7 +495,7 @@ system_enable_read(struct file *filp, ch loff_t *ppos) {const char set_to_char[4 ] = {'?' ,'0' ,'1' ,'X' }; -const char *system = filp->private_data; +struct event_subsystem *system = filp->private_data;struct ftrace_event_call *call;char buf[2 ];int set =0 ;
@@ -507,7 +507,7 @@ system_enable_read(struct file *filp, ch (!call->class->probe && !call->class->reg))continue ; -if (system &&strcmp (call->class->system, system) !=0 ) +if (system &&strcmp (call->class->system, system->name) !=0 )continue ;/*
@@ -537,7 +537,8 @@ static ssize_t system_enable_write(struct file *filp, const char __user *ubuf, size_t cnt, loff_t *ppos) { - const char *system = filp->private_data; + struct event_subsystem *system = filp->private_data; +const char *name =NULL ;unsigned long val;char buf[64 ];ssize_t ret;
@@ -561,7 +562,14 @@ system_enable_write(struct file *filp, cif (val !=0 && val !=1 )return -EINVAL ; - ret =__ftrace_set_clr_event (NULL , system,NULL , val); +/* +* Opening of "enable" adds a ref count to system, +* so the name is safe to use. +*/ +if (system) + name = system->name; + + ret =__ftrace_set_clr_event (NULL , name,NULL , val);if (ret) goto out;
@@ -740,6 +748,9 @@ static int subsystem_open(struct inode *struct event_subsystem *system =NULL ;int ret; +if (!inode->i_private) + goto skip_search; +/* Make sure the system still exists */ mutex_lock (&event_mutex);list_for_each_entry (system, &event_subsystems, list) {
@@ -758,8 +769,9 @@ static int subsystem_open(struct inode *if (system != inode->i_private)return -ENODEV ; + skip_search: ret =tracing_open_generic (inode, filp); -if (ret <0 ) +if (ret <0 && system)put_system (system);return ret;
@@ -769,7 +781,8 @@ static int subsystem_release(struct inod {struct event_subsystem *system = inode->i_private; -put_system (system); +if (system) +put_system (system);return 0 ; }
@@ -913,9 +926,10 @@ static const struct file_operations ftra };static const struct file_operations ftrace_system_enable_fops = { - .open = tracing_open_generic, + .open = subsystem_open, .read = system_enable_read, .write = system_enable_write, + .release = subsystem_release, };static const struct file_operations ftrace_show_header_fops = {
@@ -1003,8 +1017,7 @@ event_subsystem_dir(const char *name, st "'%s/filter' entry\n", name); } -trace_create_file ("enable" ,0644 , system->entry, - (void *)system->name, +trace_create_file ("enable" ,0644 , system->entry, system, &ftrace_system_enable_fops);return system->entry;
PATCH 41/50 ARM: pxa: fix PGSR register address calculation
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Paul Parsons <[email protected]>
[ upstream commit beb0c9b056b1c23d2029b46a425362e9ccbeba01 ]
The file mfp-pxa2xx.c defines a macro, PGSR(), which translates a gpio bank number to a PGSR register address. The function pxa2xx_mfp_suspend() erroneously passed in a gpio number instead of a gpio bank number.
arch/arm/mach-pxa/mfp-pxa2xx.c +2 -2
@@ -347,9 +347,9 @@ static int pxa2xx_mfp_suspend(struct sysif ((gpio_desc[i].config &MFP_LPM_KEEP_OUTPUT ) && (GPDR (i) &GPIO_bit (i))) {if (GPLR (i) &GPIO_bit (i)) -PGSR (i) |=GPIO_bit (i); +PGSR (gpio_to_bank (i)) |=GPIO_bit (i);else -PGSR (i) &= ~GPIO_bit (i); +PGSR (gpio_to_bank (i)) &= ~GPIO_bit (i); } }
PATCH 42/50 iommu/amd: Don't use MSI address range for DMA addresses
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Joerg Roedel <[email protected]>
[ upstream commit 17f5b569e09cfa3488eaa663cbf9feada2e789f5 ]
Reserve the MSI address range in the address allocator so that MSI addresses are not handed out as dma handles.
arch/x86/kernel/amd_iommu.c +15 -1
@@ -25,6 +25,7 @@#include <linux/dma-mapping.h> #include <linux/iommu-helper.h> #include <linux/iommu.h> +#include <asm/msidef.h> #include <asm/proto.h> #include <asm/iommu.h> #include <asm/gart.h>
@@ -1048,7 +1049,7 @@ static int alloc_new_range(struct dma_op {int index = dma_dom->aperture_size >>APERTURE_RANGE_SHIFT ;struct amd_iommu *iommu; -unsigned long i; +unsigned long i, old_size;#ifdef CONFIG_IOMMU_STRESS populate = false;
@@ -1084,8 +1085,21 @@ static int alloc_new_range(struct dma_op } } + old_size = dma_dom->aperture_size; dma_dom->aperture_size +=APERTURE_RANGE_SIZE ; +/* Reserve address range used for MSI messages */ +if (old_size <MSI_ADDR_BASE_LO && + dma_dom->aperture_size >MSI_ADDR_BASE_LO ) { +unsigned long spage; +int pages; + + pages =iommu_num_pages (MSI_ADDR_BASE_LO ,0x10000 ,PAGE_SIZE ); + spage =MSI_ADDR_BASE_LO >>PAGE_SHIFT ; + +dma_ops_reserve_addresses (dma_dom, spage, pages); + } +/* Intialize the exclusion range if necessary */ for_each_iommu (iommu) { if (iommu->exclusion_start &&
PATCH 43/50 staging: r8192e_pci: Handle duplicate PCI ID 0x10ec:0x8192
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <[email protected]>
[ upstream commit 1c50bf7e415cf6ce9545dbecc2ac0d89d3916c53 ]
conflict with rtl8192se
There are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and RTL8192SE. The method of distinguishing them is by the revision ID at offset 0x8 of the PCI configuration space. If the value is 0x10, then the device uses rtl8192se for a driver.
drivers/staging/rtl8192e/r8192E_core.c +6 -0
@@ -6334,6 +6334,7 @@ static int __devinit rtl8192_pci_probe(sstruct net_device *dev =NULL ;struct r8192_priv *priv=NULL ;u8 unit =0 ; +u8 revisionid;#ifdef CONFIG_RTL8192_IO_MAP unsigned long pio_start, pio_len, pio_flags;
@@ -6423,6 +6424,11 @@ static int __devinit rtl8192_pci_probe(spci_write_config_byte (pdev,0x41 ,0x00 ); +pci_read_config_byte (pdev,0x08 , &revisionid); +/* If the revisionid is 0x10, the device uses rtl8192se. */ +if (pdev->device ==0x8192 && revisionid ==0x10 ) + goto fail1; +pci_read_config_byte (pdev,0x05 , &unit);pci_write_config_byte (pdev,0x05 , unit & (~0x04 ));
PATCH 44/50 staging: comedi: fix infoleak to userspace
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Vasiliy Kulikov <[email protected]>
[ upstream commit 819cbb120eaec7e014e5abd029260db1ca8c5735 ]
driver_name and board_name are pointers to strings, not buffers of size COMEDI_NAMELEN. Copying COMEDI_NAMELEN bytes of a string containing less than COMEDI_NAMELEN-1 bytes would leak some unrelated bytes.
drivers/staging/comedi/comedi_fops.c +2 -2
@@ -383,8 +383,8 @@ static int do_devinfo_ioctl(struct comed/* fill devinfo structure */ devinfo.version_code =COMEDI_VERSION_CODE ; devinfo.n_subdevs = dev->n_subdevices; -memcpy (devinfo.driver_name, dev->driver->driver_name,COMEDI_NAMELEN ); -memcpy (devinfo.board_name, dev->board_name,COMEDI_NAMELEN ); +strlcpy (devinfo.driver_name, dev->driver->driver_name,COMEDI_NAMELEN ); +strlcpy (devinfo.board_name, dev->board_name,COMEDI_NAMELEN );if (read_subdev) devinfo.read_subdevice = read_subdev - dev->subdevices;
PATCH 45/50 Staging: hv: netvsc: Fix a bug in accounting transmit slots
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: K. Y. Srinivasan <[email protected]>
[ upstream commit 9079ce691255792009c446d8c3382507b8d38635 ]
The transmit slots were manipulated without proper locking. Fix this bug by making the variable tracking the transmit slots atomic.
This patch should be ported to prior stable kernels 2.6.32 and later.
drivers/staging/hv/netvsc_drv.c +9 -5
@@ -19,6 +19,7 @@* Hank Janssen <[email protected]> */ #include <linux/init.h> +#include <linux/atomic.h> #include <linux/module.h> #include <linux/highmem.h> #include <linux/device.h>
@@ -45,7 +46,7 @@struct net_device_context {/* point back to our device context */ struct vm_device *device_ctx; -unsigned long avail; +atomic_t avail;struct work_struct work; };
@@ -133,7 +134,9 @@ static void netvsc_xmit_completion(voiddev_kfree_skb_any (skb); -if ((net_device_ctx->avail += num_pages) >=PACKET_PAGES_HIWATER ) +atomic_add (num_pages, &net_device_ctx->avail); +if (atomic_read (&net_device_ctx->avail) >= +PACKET_PAGES_HIWATER )netif_wake_queue (net); }
@@ -159,7 +162,7 @@ static int netvsc_start_xmit(struct sk_b/* Add 1 for skb->data and additional one for RNDIS */ num_pages =skb_shinfo (skb)->nr_frags +1 +1 ; -if (num_pages > net_device_ctx->avail) +if (num_pages >atomic_read (&net_device_ctx->avail))return NETDEV_TX_BUSY ;/* Allocate a netvsc packet based on # of frags. */
@@ -218,7 +221,8 @@ static int netvsc_start_xmit(struct sk_b net->stats.tx_packets, net->stats.tx_bytes); -if ((net_device_ctx->avail -= num_pages) <PACKET_PAGES_LOWATER ) +atomic_sub (num_pages, &net_device_ctx->avail); +if (atomic_read (&net_device_ctx->avail) <PACKET_PAGES_LOWATER )netif_stop_queue (net); }else {/* we are shutting down or bus overloaded, just drop packet */
@@ -406,7 +410,7 @@ static int netvsc_probe(struct device *d net_device_ctx =netdev_priv (net); net_device_ctx->device_ctx = device_ctx; - net_device_ctx->avail = ring_size; +atomic_set (&net_device_ctx->avail, ring_size);dev_set_drvdata (device, net);INIT_WORK (&net_device_ctx->work, netvsc_send_garp);
PATCH 46/50 ARM: 6989/1: perf: do not start the PMU when no events are
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
[ upstream commit f4f38430c94c38187db73a2cf3892cc8b12a2713 ]
present
armpmu_enable can be called in situations where no events are present (for example, from the event rotation tick after a profiled task has exited). In this case, we currently start the PMU anyway which may leave it active inevitably without any events being monitored.
This patch adds a simple check to the enabling code so that we avoid starting the PMU when no events are present.
arch/arm/kernel/perf_event.c +4 -2
@@ -531,7 +531,7 @@ voidhw_perf_enable (void) {/* Enable all of the perf events on hardware. */ -int idx; +int idx, enabled =0 ;struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);if (!armpmu)
@@ -544,9 +544,11 @@ hw_perf_enable(void)continue ; armpmu->enable (&event->hw, idx); + enabled =1 ; } - armpmu->start (); +if (enabled) + armpmu->start (); }void
PATCH 47/50 ASoC: Ensure we delay long enough for WM8994 FLL to lock
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Mark Brown <[email protected]>
[ upstream commit 8e9ddf811ba021506d2316fcfe619faa0ab3f567 ]
when starting
This delay is very conservative.
sound/soc/codecs/wm8994.c +2 -0
@@ -2929,6 +2929,8 @@ static int wm8994_set_fll(struct snd_socsnd_soc_update_bits (codec,WM8994_FLL1_CONTROL_1 + reg_offset,WM8994_FLL1_ENA |WM8994_FLL1_FRAC , reg); + +msleep (5 ); } wm8994->fll[id].in = freq_in;
PATCH 48/50 SERIAL: SC26xx: Fix link error.
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Ralf Baechle <[email protected]>
[ upstream commit f2eb3cdf14457fccb14ae8c4d7d7cee088cd3957 ]
Kconfig allows enabling console support for the SC26xx driver even when it's configured as a module resulting in a:
ERROR: "uart_console_device" [drivers/tty/serial/sc26xx.ko] undefined!
modpost error since the driver was merged in eea63e0e8a60d00485b47fb6e75d9aa2566b989b [SC26XX: New serial driver for SC2681 uarts] in 2.6.25. Fixed by only allowing console support to be enabled if the driver is builtin.
drivers/serial/Kconfig +1 -1
@@ -1417,7 +1417,7 @@ config SERIAL_SC26XX config SERIAL_SC26XX_CONSOLE bool "Console on SC2681/SC2692 serial port" - depends on SERIAL_SC26XX + depends on SERIAL_SC26XX=y select SERIAL_CORE_CONSOLE help Support for Console on SC2681/SC2692 serial ports.
PATCH 49/50 x86, mtrr: lock stop machine during MTRR rendezvous sequence
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Suresh Siddha <[email protected]>
[ upstream commit 6d3321e8e2b3bf6a5892e2ef673c7bf536e3f904 ]
MTRR rendezvous sequence using stop_one_cpu_nowait() can potentially happen in parallel with another system wide rendezvous using stop_machine(). This can lead to deadlock (The order in which works are queued can be different on different cpu's. Some cpu's will be running the first rendezvous handler and others will be running the second rendezvous handler. Each set waiting for the other set to join for the system wide rendezvous, leading to a deadlock).
MTRR rendezvous sequence is not implemented using stop_machine() as this gets called both from the process context aswell as the cpu online paths (where the cpu has not come online and the interrupts are disabled etc). stop_machine() works with only online cpus.
For now, take the stop_machine mutex in the MTRR rendezvous sequence that gets called from an online cpu (here we are in the process context and can potentially sleep while taking the mutex). And the MTRR rendezvous that gets triggered during cpu online doesn't need to take this stop_machine lock (as the stop_machine() already ensures that there is no cpu hotplug going on in parallel by doing get_online_cpus())
TBD: Pursue a cleaner solution of extending the stop_machine()
infrastructure to handle the case where the calling cpu is still not online and use this for MTRR rendezvous sequence.
arch/x86/kernel/cpu/mtrr/main.c +23 -0
@@ -247,6 +247,25 @@ set_mtrr(unsigned int reg, unsigned longunsigned long flags;int cpu; +#ifdef CONFIG_SMP +/* +* If this cpu is not yet active, we are in the cpu online path. There +* can be no stop_machine() in parallel, as stop machine ensures this +* by using get_online_cpus(). We can skip taking the stop_cpus_mutex, +* as we don't need it and also we can't afford to block while waiting +* for the mutex. +* +* If this cpu is active, we need to prevent stop_machine() happening +* in parallel by taking the stop cpus mutex. +* +* Also, this is called in the context of cpu online path or in the +* context where cpu hotplug is prevented. So checking the active status +* of the raw_smp_processor_id() is safe. +*/ +if (cpu_active (raw_smp_processor_id ())) +mutex_lock (&stop_cpus_mutex); +#endif +preempt_disable (); data.smp_reg = reg;
@@ -329,6 +348,10 @@ set_mtrr(unsigned int reg, unsigned longlocal_irq_restore (flags);preempt_enable (); +#ifdef CONFIG_SMP +if (cpu_active (raw_smp_processor_id ())) +mutex_unlock (&stop_cpus_mutex); +#endif }/**
include/linux/stop_machine.h +2 -0
@@ -27,6 +27,8 @@ struct cpu_stop_work {struct cpu_stop_done *done; }; +extern struct mutex stop_cpus_mutex; +int stop_one_cpu (unsigned int cpu,cpu_stop_fn_t fn,void *arg);void stop_one_cpu_nowait (unsigned int cpu,cpu_stop_fn_t fn,void *arg,struct cpu_stop_work *work_buf);
kernel/stop_machine.c +1 -1
@@ -132,8 +132,8 @@ void stop_one_cpu_nowait(unsigned int cpcpu_stop_queue_work (&per_cpu (cpu_stopper, cpu), work_buf); } +DEFINE_MUTEX (stop_cpus_mutex);/* static data for stop_cpus */ -static DEFINE_MUTEX (stop_cpus_mutex); static DEFINE_PER_CPU(struct cpu_stop_work, stop_cpus_work);int __stop_cpus (const struct cpumask *cpumask,cpu_stop_fn_t fn,void *arg)
PATCH 50/50 ipv6: add special mode forwarding=2 to send RS while
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Graf <[email protected]>
[ upstream commit c3bccac2fa76f1619dfe4fb7b9bee69de7f066d8 ]
configured as router
Similar to accepting router advertisement, the IPv6 stack does not send router solicitations if forwarding is enabled.
This patch enables this behavior to be overruled by setting forwarding to the special value 2.
net/ipv6/addrconf.c +2 -1
@@ -2960,7 +2960,8 @@ static void addrconf_dad_completed(strucstart sending router solicitations. */ -if (ifp->idev->cnf.forwarding ==0 && +if ((ifp->idev->cnf.forwarding ==0 || + ifp->idev->cnf.forwarding ==2 ) && ifp->idev->cnf.rtr_solicits >0 && (dev->flags&IFF_LOOPBACK ) ==0 && (ipv6_addr_type (&ifp->addr) &IPV6_ADDR_LINKLOCAL )) {