commit a9dc6714276111b43349ee81db71dda9b31c8c28 Author: Greg Kroah-Hartman Date: Wed Oct 22 14:46:18 2008 -0700 Linux 2.6.26.7 commit 7afc74502277568d6f9c5a4542fb63e26e272638 Author: Arjan van de Ven Date: Fri Oct 10 21:16:12 2008 -0700 security: avoid calling a NULL function pointer in drivers/video/tvaudio.c commit 5ba2f67afb02c5302b2898949ed6fc3b3d37dcf1 upstream NULL function pointers are very bad security wise. This one got caught by kerneloops.org quite a few times, so it's happening in the field.... Fix is simple, check the function pointer for NULL, like 6 other places in the same function are already doing. Signed-off-by: Arjan van de Ven Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3a15062b0cf6ab65de38e320fe293470c2931561 Author: Michael Krufky Date: Sat Oct 18 10:35:56 2008 -0400 DVB: au0828: add support for another USB id for Hauppauge HVR950Q (cherry picked from commit a636da6bab3307fc8c6e6a22a63b0b25ba0687be) DVB: au0828: add support for another USB id for Hauppauge HVR950Q Add autodetection support for a new revision of the Hauppauge HVR950Q (2040:721e) Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b42c416b24706bd94ab7bea1569a89368adbfe7d Author: Matthias Hopf Date: Sat Oct 18 07:18:05 2008 +1000 drm/i915: fix ioremap of a user address for non-root (CVE-2008-3831) commit 4b40893918203ee1a1f6a114316c2a19c072e9bd upstream Olaf Kirch noticed that the i915_set_status_page() function of the i915 kernel driver calls ioremap with an address offset that is supplied by userspace via ioctl. The function zeroes the mapped memory via memset and tells the hardware about the address. Turns out that access to that ioctl is not restricted to root so users could probably exploit that to do nasty things. We haven't tried to write actual exploit code though. It only affects the Intel G33 series and newer. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 40e24cff25b9c5b12b7f2c8aefecb72bc9c6fd26 Author: Zhao Yakui Date: Fri Oct 17 02:16:41 2008 -0400 ACPI: Ignore _BQC object when registering backlight device upstream commmit: c2c789057f075022658b38b498755c29c1ba8055 According to acpi spec , the objectes of _BCL and _BCM are required if integrated LCD is present and supports brightness level and the _BQC is the optional object. So the _BQC object will be ignored when the backlight device is registered. At the same time when there is no _BQC object, the current brightness will be set to the maximum. http://bugzilla.kernel.org/show_bug.cgi?id=10206 Signed-off-by: Zhao Yakui Signed-off-by: Zhang Rui Signed-off-by: Andi Kleen Cc: Len Brown Signed-off-by: Greg Kroah-Hartman commit 116018950eb5201c8e74d04b01b319c8d65d5c5b Author: Jean Delvare Date: Fri Oct 10 11:04:39 2008 +0200 hwmon: (it87) Prevent power-off on Shuttle SN68PT based on commit 98dd22c3e086d76058083432d4d8fb85f04bab90 upstream On the Shuttle SN68PT, FAN_CTL2 is apparently not connected to a fan, but to something else. One user has reported instant system power-off when changing the PWM2 duty cycle, so we disable it. I use the board name string as the trigger in case the same board is ever used in other systems. This closes lm-sensors ticket #2349: pwmconfig causes a hard poweroff http://www.lm-sensors.org/ticket/2349 Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit fe2615638c671468e28b15d5e15f9b594b1fa23c Author: Linus Torvalds Date: Wed Oct 15 18:09:14 2008 -0400 Check mapped ranges on sysfs resource files commit b5ff7df3df9efab511244d5a299fce706c71af48 upstream Check mapped ranges on sysfs resource files This is loosely based on a patch by Jesse Barnes to check the user-space PCI mappings though the sysfs interfaces. Quoting Jesse's original explanation: It's fairly common for applications to map PCI resources through sysfs. However, with the current implementation, it's possible for an application to map far more than the range corresponding to the resourceN file it opened. This patch plugs that hole by checking the range at mmap time, similar to what is done on platforms like sparc64 in their lower level PCI remapping routines. It was initially put together to help debug the e1000e NVRAM corruption problem, since we initially thought an X driver might be walking past the end of one of its mappings and clobbering the NVRAM. It now looks like that's not the case, but doing the check is still important for obvious reasons. and this version of the patch differs in that it uses a helper function to clarify the code, and does all the checks in pages (instead of bytes) in order to avoid overflows when doing "<< PAGE_SHIFT" etc. [cebbert@redhat.com: backport, changing WARN() to printk()] Acked-by: Jesse Barnes Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit 76d8cb9a1e102231935e586e888b10ea6ca41101 Author: David Rientjes Date: Mon Oct 13 19:42:12 2008 -0400 x86: avoid dereferencing beyond stack + THREAD_SIZE commit 60e6258cd43f9b06884f04f0f7cefb9c40f17a32 upstream It's possible for get_wchan() to dereference past task->stack + THREAD_SIZE while iterating through instruction pointers if fp equals the upper boundary, causing a kernel panic. Signed-off-by: David Rientjes Signed-off-by: Ingo Molnar Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit 7a69c701bd95e1dc0eaf7e4008e5fd409ac7e042 Author: Shaohua Li Date: Mon Oct 13 19:39:25 2008 -0400 PCI: disable ASPM on pre-1.1 PCIe devices commit 149e16372a2066c5474d8a8db9b252afd57eb427 upstream Disable ASPM on pre-1.1 PCIe devices, as many of them don't implement it correctly. Tested-by: Jack Howarth Signed-off-by: Shaohua Li Signed-off-by: Jesse Barnes Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit 7a17866e8cc637a5ffb91266e3b551ae3c95b40a Author: Shaohua Li Date: Mon Oct 13 19:38:11 2008 -0400 PCI: disable ASPM per ACPI FADT setting commit 5fde244d39b88625ac578d83e6625138714de031 upstream The ACPI FADT table includes an ASPM control bit. If the bit is set, do not enable ASPM since it may indicate that the platform doesn't actually support the feature. Tested-by: Jack Howarth Signed-off-by: Shaohua Li Signed-off-by: Jesse Barnes Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit 1a5f1e89a9259b8447530f671f7fe70ca1049453 Author: Ralph Loader Date: Mon Oct 13 19:35:38 2008 -0400 V4L/DVB (9053): fix buffer overflow in uvc-video Commit fe6c700ff34e68e1eb7991e9c5d18986d0005ac1 upstream V4L/DVB (9053): fix buffer overflow in uvc-video There is a buffer overflow in drivers/media/video/uvc/uvc_ctrl.c: INFO: 0xf2c5ce08-0xf2c5ce0b. First byte 0xa1 instead of 0xcc INFO: Allocated in uvc_query_v4l2_ctrl+0x3c/0x239 [uvcvideo] age=13 cpu=1 pid=4975 ... A fixed size 8-byte buffer is allocated, and a variable size field is read into it; there is no particular bound on the size of the field (it is dependent on hardware and configuration) and it can overflow [also verified by inserting printk's.] The patch attempts to size the buffer to the correctly. Signed-off-by: Andrew Morton Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit 643c65d64a8755fca03ab057e6ea2c87c0cc245d Author: Laurent Pinchart Date: Mon Oct 13 19:33:49 2008 -0400 V4L/DVB (8617): uvcvideo: don't use stack-based buffers for USB transfers. commit 04793dd041bbb88a39b768b714c725de2c339b51 upstream Data buffers on the stack are not allowed for USB I/O. Use dynamically allocated buffers instead. Signed-off-by: Bruce Schmid Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit 372bd6a0bb40ecf8c3ba96fc25f556e23c0847a1 Author: Laurent Pinchart Date: Mon Oct 13 19:32:03 2008 -0400 V4L/DVB (8498): uvcvideo: Return sensible min and max values when querying a boolean control. commit 54812c77bc830e2dbcb62b4c6d8a9c7f97cfdd1b upstream [required to get the following two patches to apply] Although the V4L2 spec states that the minimum and maximum fields may not be valid for control types other than V4L2_CTRL_TYPE_INTEGER, it makes sense to set the bounds to 0 and 1 for boolean controls instead of returning uninitialized values. Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit e1a85fcf7f338097b807ccf6a34bc2a9fa5c739c Author: Linus Torvalds Date: Thu Oct 9 14:04:54 2008 -0700 Don't allow splice() to files opened with O_APPEND commit efc968d450e013049a662d22727cf132618dcb2f upstream This is debatable, but while we're debating it, let's disallow the combination of splice and an O_APPEND destination. It's not entirely clear what the semantics of O_APPEND should be, and POSIX apparently expects pwrite() to ignore O_APPEND, for example. So we could make up any semantics we want, including the old ones. But Miklos convinced me that we should at least give it some thought, and that accepting writes at arbitrary offsets is wrong at least for IS_APPEND() files (which always have O_APPEND set, even if the reverse isn't true: you can obviously have O_APPEND set on a regular file). So disallow O_APPEND entirely for now. I doubt anybody cares, and this way we have one less gray area to worry about. Reported-and-argued-for-by: Miklos Szeredi Acked-by: Jens Axboe Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e35629b6c64c0024a915a4dec7e31125f4f95c4f Author: Jean Delvare Date: Fri Oct 10 08:41:43 2008 -0400 V4L: zr36067: Fix RGBR pixel format cherry picked from commit a30ee3c747728f9151664118ffcbdeefd202c332 The zr36067 driver is improperly declaring pixel format RGBP twice, once as "16-bit RGB LE" and once as "16-bit RGB BE". The latter is actually RGBR. Fix the code to properly map both pixel formats. Signed-off-by: Jean Delvare Acked-by: Trent Piepho Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit 7da0ca5720bceb79599bc42dde1c0a27107587ee Author: Jean Delvare Date: Fri Oct 10 08:41:38 2008 -0400 V4L: bttv: Prevent NULL pointer dereference in radio_open (cherry picked from commit c37396c19403e249f12626187d51e92c915f2bc9) Fix the following crash in the bttv driver: BUG: unable to handle kernel NULL pointer dereference at 000000000000036c IP: [] radio_open+0x3a/0x170 [bttv] This happens because radio_open assumes that all present bttv devices have a radio function. If a bttv device without radio and one with radio are installed on the same system, and the one without radio is registered first, then radio_open checks for the radio device number of a bttv device that has no radio function, and this breaks. All we have to do to fix it is to skip bttv devices without a radio function. Signed-off-by: Jean Delvare Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman commit abcfbcb70bce2a534a7c036abcfa29deec44120b Author: Taisuke Yamada Date: Mon Oct 13 19:18:33 2008 -0400 libata: LBA28/LBA48 off-by-one bug in ata.h commit 97b697a11b07e2ebfa69c488132596cc5eb24119 upstream I recently bought 3 HGST P7K500-series 500GB SATA drives and had trouble accessing the block right on the LBA28-LBA48 border. Here's how it fails (same for all 3 drives): # dd if=/dev/sdc bs=512 count=1 skip=268435455 > /dev/null dd: reading `/dev/sdc': Input/output error 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.288033 seconds, 0.0 kB/s # dmesg ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata1.00: BMDMA stat 0x25 ata1.00: cmd c8/00:08:f8:ff:ff/00:00:00:00:00/ef tag 0 dma 4096 in res 51/04:08:f8:ff:ff/00:00:00:00:00/ef Emask 0x1 (device error) ata1.00: status: { DRDY ERR } ata1.00: error: { ABRT } ata1.00: configured for UDMA/33 ata1: EH complete ... After some investigations, it turned out this seems to be caused by misinterpretation of the ATA specification on LBA28 access. Following part is the code in question: === include/linux/ata.h === static inline int lba_28_ok(u64 block, u32 n_block) { /* check the ending block number */ return ((block + n_block - 1) < ((u64)1 << 28)) && (n_block <= 256); } HGST drive (sometimes) fails with LBA28 access of {block = 0xfffffff, n_block = 1}, and this behavior seems to be comformant. Other drives, including other HGST drives are not that strict, through. >From the ATA specification: (http://www.t13.org/Documents/UploadedDocuments/project/d1410r3b-ATA-ATAPI-6.pdf) 8.15.29 Word (61:60): Total number of user addressable sectors This field contains a value that is one greater than the total number of user addressable sectors (see 6.2). The maximum value that shall be placed in this field is 0FFFFFFFh. So the driver shouldn't use the value of 0xfffffff for LBA28 request as this exceeds maximum user addressable sector. The logical maximum value for LBA28 is 0xffffffe. The obvious fix is to cut "- 1" part, and the patch attached just do that. I've been using the patched kernel for about a month now, and the same fix is also floating on the net for some time. So I believe this fix works reliably. Just FYI, many Windows/Intel platform users also seems to be struck by this, and HGST has issued a note pointing to Intel ICH8/9 driver. "28-bit LBA command is being used to access LBAs 29-bits in length" http://www.hitachigst.com/hddt/knowtree.nsf/cffe836ed7c12018862565b000530c74/b531b8bce8745fb78825740f00580e23 Also, *BSDs seems to have similar fix included sometime around ~2004, through I have not checked out exact portion of the code. Signed-off-by: Taisuke Yamada Signed-off-by: Jeff Garzik Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit dcbe5f2d841ed58a102195a7ded37fd7acdb7a52 Author: Tejun Heo Date: Mon Oct 13 19:19:59 2008 -0400 libata: fix EH action overwriting in ata_eh_reset() Commit a674050e068a2919908730279f0b731ae6d2e005 upstream ehc->i.action got accidentally overwritten to ATA_EH_HARD/SOFTRESET in ata_eh_reset(). The original intention was to clear reset action which wasn't selected. This can cause unexpected behavior when other EH actions are scheduled together with reset. Fix it. Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit dd5d2d841e954134a06ea6b6e414b90b9b80b4e5 Author: Tejun Heo Date: Mon Oct 13 19:21:28 2008 -0400 libata: always do follow-up SRST if hardreset returned -EAGAIN commit 5dbfc9cb59d4ad75199949d7dd8a8c6d7bc518df upstream As an optimization, follow-up SRST used to be skipped if classification wasn't requested even when hardreset requested it via -EAGAIN. However, some hardresets can't wait for device readiness and skipping SRST can cause timeout or other failures during revalidation. Always perform follow-up SRST if hardreset returns -EAGAIN. This makes reset paths more predictable and thus less error-prone. While at it, move hardreset error checking such that it's done right after hardreset is finished. This simplifies followup SRST condition check a bit and makes the reset path easier to modify. Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit c8d4a26cf27050f22e3aa493c04982a34774780e Author: Oleg Nesterov Date: Thu Oct 16 19:05:07 2008 +0000 fbcon_set_all_vcs: fix kernel crash when switching the rotated consoles commit 232fb69a53a5ec3f22a8104d447abe4806848a8f upstream echo 3 >> /sys/class/graphics/fbcon/rotate_all, then switch to another console. Result: BUG: unable to handle kernel paging request at ffffc20005d00000 IP: [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109 PGD 7e228067 PUD 7e229067 PMD 7bc1f067 PTE 0 Oops: 0002 [1] SMP CPU 1 Modules linked in: [...a lot...] Pid: 10, comm: events/1 Not tainted 2.6.26.5-45.fc9.x86_64 #1 RIP: 0010:[bitfill_aligned+149/265] [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109 RSP: 0018:ffff81007d811bc8 EFLAGS: 00010216 RAX: ffffc20005d00000 RBX: 0000000000000000 RCX: 0000000000000400 RDX: 0000000000000000 RSI: ffffc20005d00000 RDI: ffffffffffffffff RBP: ffff81007d811be0 R08: 0000000000000400 R09: 0000000000000040 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000010000 R13: ffffffff811632f0 R14: 0000000000000006 R15: ffff81007cb85400 FS: 0000000000000000(0000) GS:ffff81007e004780(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffffc20005d00000 CR3: 0000000000201000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process events/1 (pid: 10, threadinfo ffff81007d810000, task ffff81007d808000) Stack: ffff81007c9d75a0 0000000000000000 0000000000000000 ffff81007d811c80 ffffffff81163a61 ffff810000000000 ffffffff8115f9c8 0000001000000000 0000000100aaaaaa 000000007cd0d4a0 fffffd8a00000800 0001000000000000 Call Trace: [cfb_fillrect+523/798] cfb_fillrect+0x20b/0x31e [soft_cursor+416/436] ? soft_cursor+0x1a0/0x1b4 [ccw_clear_margins+205/263] ccw_clear_margins+0xcd/0x107 [fbcon_clear_margins+59/61] fbcon_clear_margins+0x3b/0x3d [fbcon_switch+1291/1466] fbcon_switch+0x50b/0x5ba [redraw_screen+261/481] redraw_screen+0x105/0x1e1 [ccw_cursor+0/1869] ? ccw_cursor+0x0/0x74d [complete_change_console+48/190] complete_change_console+0x30/0xbe [change_console+115/120] change_console+0x73/0x78 [console_callback+0/292] ? console_callback+0x0/0x124 [console_callback+97/292] console_callback+0x61/0x124 [schedule_delayed_work+25/30] ? schedule_delayed_work+0x19/0x1e [run_workqueue+139/282] run_workqueue+0x8b/0x11a [worker_thread+221/238] worker_thread+0xdd/0xee [autoremove_wake_function+0/56] ? autoremove_wake_function+0x0/0x38 [worker_thread+0/238] ? worker_thread+0x0/0xee [kthread+73/118] kthread+0x49/0x76 [child_rip+10/18] child_rip+0xa/0x12 [kthread+0/118] ? kthread+0x0/0x76 [child_rip+0/18] ? child_rip+0x0/0x12 Because fbcon_set_all_vcs()->FBCON_SWAP() uses display->rotate == 0 instead of fbcon_ops->rotate, and vc_resize() has no effect because it is called with new_cols/rows == ->vc_cols/rows. Tested on 2.6.26.5-45.fc9.x86_64, but http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git seems to have the same problem. Signed-off-by: Oleg Nesterov Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7a67d6e81c2144ca302021b7fcde44dc0518e465 Author: Alexey Dobriyan Date: Thu Oct 16 22:05:10 2008 +0000 modules: fix module "notes" kobject leak commit e94320939f44e0cbaccc3f259a5778abced4949c upstream Fix "notes" kobject leak It happens every rmmod if KALLSYMS=y and SYSFS=y. # modprobe foo kobject: 'foo' (ffffffffa00743d0): kobject_add_internal: parent: 'module', set: 'module' kobject: 'holders' (ffff88017e7c5770): kobject_add_internal: parent: 'foo', set: '' kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo' kobject: 'notes' (ffff88017fa9b668): kobject_add_internal: parent: 'foo', set: '' ^^^^^ # rmmod foo kobject: 'holders' (ffff88017e7c5770): kobject_cleanup kobject: 'holders' (ffff88017e7c5770): auto cleanup kobject_del kobject: 'holders' (ffff88017e7c5770): calling ktype release kobject: (ffff88017e7c5770): dynamic_kobj_release kobject: 'holders': free name kobject: 'foo' (ffffffffa00743d0): kobject_cleanup kobject: 'foo' (ffffffffa00743d0): does not have a release() function, it is broken and must be fixed. kobject: 'foo' (ffffffffa00743d0): auto cleanup 'remove' event kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo' kobject: 'foo' (ffffffffa00743d0): auto cleanup kobject_del kobject: 'foo': free name [whooops] Signed-off-by: Alexey Dobriyan Signed-off-by: Greg Kroah-Hartman commit c2fa492c13555c4ebc5235c05ae00d406a5b6e61 Author: Larry Finger Date: Sat Oct 11 16:55:21 2008 +0000 b43legacy: Fix failure in rate-adjustment mechanism commit c6a2afdacccd56cc0be8e9a7977f0ed1509069f6 upstream Date: Sat, 6 Sep 2008 16:51:22 -0500 Subject: b43legacy: Fix failure in rate-adjustment mechanism A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 282333bd7f759cdd9362e793b85db08780516416 Author: Steve French Date: Sat Oct 11 16:55:11 2008 +0000 CIFS: make sure we have the right resume info before calling CIFSFindNext commit 0752f1522a9120f731232919f7ad904e9e22b8ce upstream When we do a seekdir() or equivalent, we usually end up doing a FindFirst call and then call FindNext until we get to the offset that we want. The problem is that when we call FindNext, the code usually doesn't have the proper info (mostly, the filename of the entry from the last search) to resume the search. Add a "last_entry" field to the cifs_search_info that points to the last entry in the search. We calculate this pointer by using the LastNameOffset field from the search parms that are returned. We then use that info to do a cifs_save_resume_key before we call CIFSFindNext. This patch allows CIFS to reliably pass the "telldir" connectathon test. Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 3c03d1acb2ffb8a9a415f26e093615de04cbe58d Author: Dario Faggioli Date: Fri Oct 10 20:15:02 2008 +0000 sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq commit f6121f4f8708195e88cbdf8dd8d171b226b3f858 upstream While working on the new version of the code for SCHED_SPORADIC I noticed something strange in the present throttling mechanism. More specifically in the throttling timer handler in sched_rt.c (do_sched_rt_period_timer()) and in rt_rq_enqueue(). The problem is that, when unthrottling a runqueue, rt_rq_enqueue() only asks for rescheduling if the runqueue has a sched_entity associated to it (i.e., rt_rq->rt_se != NULL). Now, if the runqueue is the root rq (which has a rt_se = NULL) rescheduling does not take place, and it is delayed to some undefined instant in the future. This imply some random bandwidth usage by the RT tasks under throttling. For instance, setting rt_runtime_us/rt_period_us = 950ms/1000ms an RT task will get less than 95%. In our tests we got something varying between 70% to 95%. Using smaller time values, e.g., 95ms/100ms, things are even worse, and I can see values also going down to 20-25%!! The tests we performed are simply running 'yes' as a SCHED_FIFO task, and checking the CPU usage with top, but we can investigate thoroughly if you think it is needed. Things go much better, for us, with the attached patch... Don't know if it is the best approach, but it solved the issue for us. Signed-off-by: Dario Faggioli Signed-off-by: Michael Trimarchi Acked-by: Peter Zijlstra Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 0c17850047e2a9ec6913b3a71d6f91ec980dc07d Author: Alan Cox Date: Mon Oct 13 10:38:46 2008 +0100 tty: Termios locking - sort out real_tty confusions and lock reads commit 8f520021837d45c47d0ab57e7271f8d88bf7f3a4 upstream (only the tty_io.c portion of this commit) This moves us towards sanity and should mean our termios locking is now complete and comprehensive. Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6cb603ed02a891b965dc2fc50a39bff131829a54 Author: Alan Cox Date: Sun Oct 12 19:40:08 2008 +0000 x86, early_ioremap: fix fencepost error commit c613ec1a7ff3714da11c7c48a13bab03beb5c376 upstream The x86 implementation of early_ioremap has an off by one error. If we get an object which ends on the first byte of a page we undermap by one page and this causes a crash on boot with the ASUS P5QL whose DMI table happens to fit this alignment. The size computation is currently last_addr = phys_addr + size - 1; npages = (PAGE_ALIGN(last_addr) - phys_addr) (Consider a request for 1 byte at alignment 0...) Closes #11693 Debugging work by Ian Campbell/Felix Geyer Signed-off-by: Alan Cox Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b50094cc2234eec81e8fdcac6e908bbfa5baeabe Author: Thomas Gleixner Date: Mon Oct 13 17:15:23 2008 +0000 x86: improve UP kernel when CPU-hotplug and SMP is enabled commit 649c6653fa94ec8f3ea32b19c97b790ec4e8e4ac upstream num_possible_cpus() can be > 1 when disabled CPUs have been accounted. Disabled CPUs are not in the cpu_present_map, so we can use num_present_cpus() as a safe indicator to switch to UP alternatives. Reported-by: Chuck Ebbert Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 4c1f10b9281efa585cb616ce25b6e7b408e47229 Author: Stefan Bader Date: Sat Sep 27 11:07:30 2008 -0400 x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap. Not in upstream above 2.6.27 due to change in the way this code works (has been fixed differently there.) Someone from the community found out, that after repeatedly unloading and loading a device driver that uses MSI IRQs, the system eventually assigned the vector initially reserved for IRQ0 to the device driver. The reason for this is, that although IRQ0 is tied to the FIRST_DEVICE_VECTOR when declaring the irq_vector table, the corresponding bit in the used_vectors map is not set. So, if vectors are released and assigned often enough, the vector will get assigned to another interrupt. This happens more often with MSI interrupts as those are exclusively using a vector. Fix this by setting the bit for the FIRST_DEVICE_VECTOR in the bitmap. Signed-off-by: Stefan Bader Acked-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman