2.6.27-stable review
Subsystems (17)
cover 2.6.27-stable review
This is the start of the stable review cycle for the 2.6.27.3 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.
Responses should be made by Wed, October 22, 2008 19:00:00 UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.27.3-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
PATCH 1/17 fbcon_set_all_vcs: fix kernel crash when switching the rotated consoles
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Oleg Nesterov <[email protected]>
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.
--- drivers/video/console/fbcon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/video/console/fbcon.c +2 -2
@@ -2996,8 +2996,8 @@ static void fbcon_set_all_vcs(struct fb_ p = &fb_display[vc->vc_num];set_blitting_type (vc, info);var_to_display (p, &info->var, info); - cols =FBCON_SWAP (p->rotate, info->var.xres, info->var.yres); - rows =FBCON_SWAP (p->rotate, info->var.yres, info->var.xres); + cols =FBCON_SWAP (ops->rotate, info->var.xres, info->var.yres); + rows =FBCON_SWAP (ops->rotate, info->var.yres, info->var.xres); cols /= vc->vc_font.width; rows /= vc->vc_font.height;vc_resize (vc, cols, rows);
PATCH 2/17 modules: fix module "notes" kobject leak
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alexey Dobriyan <[email protected]>
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: '<NULL>'
kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env
kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo'
kobject: 'notes' (ffff88017fa9b668): kobject_add_internal: parent: 'foo', set: '<NULL>'
^^^^^ # 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]
--- kernel/module.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/module.c +1 -1
@@ -1173,7 +1173,7 @@ static void free_notes_attrs(struct moduwhile (i-- >0 )sysfs_remove_bin_file (notes_attrs->dir, ¬es_attrs->attrs[i]); -kobject_del (notes_attrs->dir); +kobject_put (notes_attrs->dir); }kfree (notes_attrs); }
PATCH 3/17 Driver core: Fix cleanup in device_create_vargs().
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Cornelia Huck <[email protected]>
commit 286661b3777897220ecfcd774bccc68a34667f39 upstream
If device_register() in device_create_vargs() fails, the device must be cleaned up with put_device() (which is also fine on NULL) instead of kfree().
--- drivers/base/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/base/core.c +1 -1
@@ -1243,7 +1243,7 @@ struct device *device_create_vargs(strucreturn dev; error: -kfree (dev); +put_device (dev);return ERR_PTR (retval); }EXPORT_SYMBOL_GPL (device_create_vargs);
PATCH 4/17 Driver core: Clarify device cleanup.
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Cornelia Huck <[email protected]>
commit 5739411acbaa63a6c22c91e340fdcdbcc7d82a51 upstream
Make the comments on how to use device_initialize(), device_add() and device_register() a bit clearer - in particular, explicitly note that put_device() must be used once we tried to add the device to the hierarchy.
--- drivers/base/core.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-)
drivers/base/core.c +18 -5
@@ -523,11 +523,16 @@ static void klist_children_put(struct kl* device_initialize - init device structure. * @dev: device. * -* This prepares the device for use by other layers, -* including adding it to the device hierarchy. +* This prepares the device for use by other layers by initializing +* its fields. * It is the first half of device_register(), if called by -* that, though it can also be called separately, so one -* may use @dev's fields (e.g. the refcount). +* that function, though it can also be called separately, so one +* may use @dev's fields. In particular, get_device()/put_device() +* may be used for reference counting of @dev after calling this +* function. +* +* NOTE: Use put_device() to give up your reference instead of freeing +* @dev directly once you have called this function. */ void device_initialize (struct device *dev) {
@@ -836,9 +841,13 @@ static void device_remove_sys_dev_entry(* This is part 2 of device_register(), though may be called * separately _iff_ device_initialize() has been called separately. * -* This adds it to the kobject hierarchy via kobject_add(), adds it +* This adds @dev to the kobject hierarchy via kobject_add(), adds it * to the global and sibling lists for the device, then * adds it to the other relevant subsystems of the driver model. +* +* NOTE: _Never_ directly free @dev after calling this function, even +* if it returned an error! Always use put_device() to give up your +* reference instead. */ int device_add (struct device *dev) {
@@ -965,6 +974,10 @@ done:* I.e. you should only call the two helpers separately if * have a clearly defined need to use and refcount the device * before it is added to the hierarchy. +* +* NOTE: _Never_ directly free @dev after calling this function, even +* if it returned an error! Always use put_device() to give up the +* reference initialized in this function instead. */ int device_register (struct device *dev) {
PATCH 5/17 ath9k/mac80211: disallow fragmentation in ath9k, report to userspace
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Johannes Berg <[email protected]>
commit 4233df6b748193d45f79fb7448991a473061a65d upstream
As I've reported, ath9k currently fails utterly when fragmentation is enabled. This makes ath9k "support" hardware fragmentation by not supporting fragmentation at all to avoid the double-free issue. The patch also changes mac80211 to report errors from the driver operation to userspace.
That hack in ath9k should be removed once the rate control algorithm it has is fixed, and we can at that time consider removing the hw fragmentation support entirely since it's not used by any driver.
--- drivers/net/wireless/ath9k/main.c | 8 +++++++- net/mac80211/wext.c | 2 +- 2 files changed, 8 insertions(+), 2 deletions(-)
drivers/net/wireless/ath9k/main.c +7 -1
@@ -1007,6 +1007,11 @@ static int ath9k_ampdu_action(struct ieereturn ret; } +static int ath9k_no_fragmentation (struct ieee80211_hw *hw,u32 value) +{ +return -EOPNOTSUPP ; +} +static struct ieee80211_ops ath9k_ops = { .tx = ath9k_tx, .start = ath9k_start,
@@ -1031,7 +1036,8 @@ static struct ieee80211_ops ath9k_ops = .get_tsf = ath9k_get_tsf, .reset_tsf = ath9k_reset_tsf, .tx_last_beacon = NULL, - .ampdu_action = ath9k_ampdu_action + .ampdu_action = ath9k_ampdu_action, + .set_frag_threshold = ath9k_no_fragmentation, }; void ath_get_beaconconfig(struct ath_softc *sc,
net/mac80211/wext.c +1 -1
@@ -804,7 +804,7 @@ static int ieee80211_ioctl_siwfrag(struc* configure it here */ if (local->ops->set_frag_threshold) - local->ops->set_frag_threshold ( +return local->ops->set_frag_threshold (local_to_hw (local), local->fragmentation_threshold);
PATCH 6/17 md: Fix rdev_size_store with size == 0
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Chris Webb <[email protected]>
commit 7d3c6f8717ee6c2bf6cba5fa0bda3b28fbda6015 upstream
Fix rdev_size_store with size == 0.
size == 0 means to use the largest size allowed by the underlying device and is used when modifying an active array.
This fixes a regression introduced by
commit d7027458d68b2f1752a28016dcf2ffd0a7e8f567
--- drivers/md/md.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/md/md.c +2 -4
@@ -2109,8 +2109,6 @@ rdev_size_store(mdk_rdev_t *rdev, constif (strict_strtoull (buf,10 , &size) <0 )return -EINVAL ; -if (size < my_mddev->size) -return -EINVAL ;if (my_mddev->pers && rdev->raid_disk >=0 ) {if (my_mddev->persistent) { size = super_types[my_mddev->major_version].
@@ -2121,9 +2119,9 @@ rdev_size_store(mdk_rdev_t *rdev, const size = (rdev->bdev->bd_inode->i_size >>10 ); size -= rdev->data_offset/2 ; } -if (size < my_mddev->size) -return -EINVAL ;/* component must fit device */ } +if (size < my_mddev->size) +return -EINVAL ;/* component must fit device */ rdev->size = size;if (size > oldsize && my_mddev->external) {
PATCH 7/17 xfs: fix remount rw with unrecognized options
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Christoph Hellwig <[email protected]>
commit 6c5e51dae2c37127e00be392f40842e08077e96a upstream
When we skip unrecognized options in xfs_fs_remount we should just break out of the switch and not return because otherwise we may skip clearing the xfs-internal read-only flag. This will only show up on some operations like touch because most read-only checks are done by the VFS which thinks this filesystem is r/w. Eventually we should replace the XFS read-only flag with a helper that always checks the VFS flag to make sure they can never get out of sync.
Bug reported and fix verified by Marcel Beister on #xfs. Bug fix verified by updated xfstests/189.
--- fs/xfs/linux-2.6/xfs_super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/xfs/linux-2.6/xfs_super.c +1 -1
@@ -1323,7 +1323,7 @@ xfs_fs_remount( "XFS: mount option \"%s\" not supported for remount\n", p);return -EINVAL ;#else -return 0 ; +break ;#endif } }
PATCH 8/17 ath9k: fix oops on trying to hold the wrong spinlock
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Luis R. Rodriguez <[email protected]>
commit a477e4e6d48d3ac7c7a75bad40585cb391e5c237 upstream
We were trying to hold the wrong spinlock due to a typo on IEEE80211_BAR_CTL_TID_S's definition. We use this to compute the tid number and then hold this this tid number's spinlock.
--- drivers/net/wireless/ath9k/core.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/ath9k/core.h +1 -1
@@ -316,7 +316,7 @@ void ath_descdma_cleanup(struct ath_soft#define ATH_RX_TIMEOUT 40/* 40 milliseconds */ #define WME_NUM_TID 16#define IEEE80211_BAR_CTL_TID_M 0xF000/* tid mask */ -#define IEEE80211_BAR_CTL_TID_S 2/* tid shift */ +#define IEEE80211_BAR_CTL_TID_S 12/* tid shift */ enum ATH_RX_TYPE {ATH_RX_NON_CONSUMED =0 ,
PATCH 9/17 OHCI: Allow broken controllers to auto-stop
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
commit 4a511bc3f5829bc18428bcf11c25417a79d09396 upstream
This patch (as1134) attempts to improve the way we handle OHCI controllers with broken Root Hub Status Change interrupt support. In these controllers the RHSC interrupt bit essentially never turns off, making RHSC interrupts useless -- they have to remain permanently disabled.
Such controllers should still be allowed to turn off their root hubs when no devices are attached. Polling for new connections can continue while the root hub is suspended. The patch implements this feature. (It won't have much effect unless CONFIG_PM is enabled and CONFIG_USB_SUSPEND is disabled, but since the overhead is very small we may as well do it.)
--- drivers/usb/host/ohci-hub.c | 60 +++++++++++++++++++++++--------------------- 1 file changed, 32 insertions(+), 28 deletions(-)
drivers/usb/host/ohci-hub.c +32 -28
@@ -362,18 +362,23 @@ static int ohci_root_hub_state_changes(s int any_connected) {int poll_rh =1 ; -int rhsc; +int rhsc_status, rhsc_enable; - rhsc =ohci_readl (ohci, &ohci->regs->intrenable) &OHCI_INTR_RHSC ; -switch (ohci->hc_control &OHCI_CTRL_HCFS ) { +/* Some broken controllers never turn off RHCS in the interrupt +* status register. For their sake we won't re-enable RHSC +* interrupts if the interrupt bit is already active. +*/ + rhsc_status =ohci_readl (ohci, &ohci->regs->intrstatus) & +OHCI_INTR_RHSC ; + rhsc_enable =ohci_readl (ohci, &ohci->regs->intrenable) & +OHCI_INTR_RHSC ; +switch (ohci->hc_control &OHCI_CTRL_HCFS ) {case OHCI_USB_OPER : -/* If no status changes are pending, enable status-change -* interrupts. -*/ -if (!rhsc && !changed) { - rhsc =OHCI_INTR_RHSC ; -ohci_writel (ohci, rhsc, &ohci->regs->intrenable); +/* If no status changes are pending, enable RHSC interrupts. */ +if (!rhsc_enable && !rhsc_status && !changed) { + rhsc_enable =OHCI_INTR_RHSC ; +ohci_writel (ohci, rhsc_enable, &ohci->regs->intrenable); }/* Keep on polling until we know a device is connected
@@ -383,7 +388,7 @@ static int ohci_root_hub_state_changes(sif (any_connected || !device_may_wakeup (&ohci_to_hcd (ohci) ->self.root_hub->dev)) { -if (rhsc) +if (rhsc_enable) poll_rh =0 ; }else { ohci->autostop =1 ;
@@ -396,34 +401,36 @@ static int ohci_root_hub_state_changes(s ohci->autostop =0 ; ohci->next_statechange = jiffies +STATECHANGE_DELAY ; - }else if (rhsc &&time_after_eq (jiffies, + }else if (time_after_eq (jiffies, ohci->next_statechange) && !ohci->ed_rm_list && !(ohci->hc_control &OHCI_SCHED_ENABLES )) {ohci_rh_suspend (ohci,1 ); - poll_rh =0 ; +if (rhsc_enable) + poll_rh =0 ; } }break ; -/* if there is a port change, autostart or ask to be resumed */ case OHCI_USB_SUSPEND :case OHCI_USB_RESUME : +/* if there is a port change, autostart or ask to be resumed */ if (changed) {if (ohci->autostop)ohci_rh_resume (ohci);else usb_hcd_resume_root_hub (ohci_to_hcd (ohci)); }else { -if (!rhsc && (ohci->autostop || +if (!rhsc_enable && !rhsc_status && (ohci->autostop ||ohci_to_hcd (ohci)->self.root_hub-> - do_remote_wakeup)) -ohci_writel (ohci,OHCI_INTR_RHSC , + do_remote_wakeup)) { + rhsc_enable =OHCI_INTR_RHSC ; +ohci_writel (ohci, rhsc_enable, &ohci->regs->intrenable); - -/* everything is idle, no need for polling */ - poll_rh =0 ; + } +if (rhsc_enable) + poll_rh =0 ; }break ; }
@@ -443,12 +450,16 @@ static inline int ohci_rh_resume(structstatic int ohci_root_hub_state_changes (struct ohci_hcd *ohci,int changed,int any_connected) { +int rhsc_status; +/* If RHSC is enabled, don't poll */ if (ohci_readl (ohci, &ohci->regs->intrenable) &OHCI_INTR_RHSC )return 0 ; -/* If no status changes are pending, enable status-change interrupts */ -if (!changed) { +/* If no status changes are pending, enable RHSC interrupts */ + rhsc_status =ohci_readl (ohci, &ohci->regs->intrstatus) & +OHCI_INTR_RHSC ; +if (!changed && !rhsc_status) {ohci_writel (ohci,OHCI_INTR_RHSC , &ohci->regs->intrenable);return 0 ; }
@@ -492,13 +503,6 @@ ohci_hub_status_data (struct usb_hcd *hc length++; } -/* Some broken controllers never turn off RHCS in the interrupt -* status register. For their sake we won't re-enable RHSC -* interrupts if the flag is already set. -*/ -if (ohci_readl (ohci, &ohci->regs->intrstatus) &OHCI_INTR_RHSC ) - changed =1 ; -/* look at each port */ for (i =0 ; i < ohci->num_ports; i++) {u32 status =roothub_portstatus (ohci, i);
PATCH 10/17 USB: OHCI: fix endless polling behavior
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
commit 71b7497c078a97e2afb774ad7c1f8ff5bdda8a60 upstream
This patch (as1149) fixes an obscure problem in OHCI polling. In the current code, if the RHSC interrupt status flag turns on at a time when RHSC interrupts are disabled, it will remain on forever:
The interrupt handler is the only place where RHSC status gets turned back off;
The interrupt handler won't turn RHSC status off because it doesn't turn off status flags if the corresponding interrupt isn't enabled;
RHSC interrupts will never get enabled because ohci_root_hub_state_changes() doesn't reenable RHSC if RHSC status is on!
As a result we will continue polling indefinitely instead of reverting to interrupt-driven operation, and the root hub will not autosuspend. This particular sequence of events is not at all unusual; in fact plugging a USB device into an OHCI controller will usually cause it to occur.
Of course, this is a bug. The proper thing to do is to turn off RHSC status just before reading the actual port status values. That way either a port status change will be detected (if it occurs before the status read) or it will turn RHSC back on. Possibly both, but that won't hurt anything.
We can still check for systems in which RHSC is totally broken, by re-reading RHSC after clearing it and before reading the port statuses. (This re-read has to be done anyway, to post the earlier write.) If RHSC is on but no port-change statuses are set, then we know that RHSC is broken and we can avoid re-enabling it.
--- drivers/usb/host/ohci-hub.c | 51 +++++++++++++++++++++++++++----------------- 1 file changed, 32 insertions(+), 19 deletions(-)
drivers/usb/host/ohci-hub.c +32 -19
@@ -359,17 +359,15 @@ static void ohci_finish_controller_resum/* Carry out polling-, autostop-, and autoresume-related state changes */ static int ohci_root_hub_state_changes (struct ohci_hcd *ohci,int changed, -int any_connected) +int any_connected,int rhsc_status) {int poll_rh =1 ; -int rhsc_status, rhsc_enable; +int rhsc_enable;/* Some broken controllers never turn off RHCS in the interrupt * status register. For their sake we won't re-enable RHSC * interrupts if the interrupt bit is already active. */ - rhsc_status =ohci_readl (ohci, &ohci->regs->intrstatus) & -OHCI_INTR_RHSC ; rhsc_enable =ohci_readl (ohci, &ohci->regs->intrenable) &OHCI_INTR_RHSC ;
@@ -421,14 +419,23 @@ static int ohci_root_hub_state_changes(sohci_rh_resume (ohci); elseusb_hcd_resume_root_hub (ohci_to_hcd (ohci )); + +/* If remote wakeup is disabled, stop polling */ + }else if (!ohci->autostop && + !ohci_to_hcd (ohci)->self.root_hub-> + do_remote_wakeup) { + poll_rh =0 ; + }else { -if (!rhsc_enable && !rhsc_status && (ohci->autostop || -ohci_to_hcd (ohci)->self.root_hub-> - do_remote_wakeup)) { +/* If no status changes are pending, +* enable RHSC interrupts +*/ +if (!rhsc_enable && !rhsc_status) { rhsc_enable =OHCI_INTR_RHSC ;ohci_writel (ohci, rhsc_enable, &ohci->regs->intrenable); } +/* Keep polling until RHSC is enabled */ if (rhsc_enable) poll_rh =0 ; }
@@ -448,22 +455,22 @@ static inline int ohci_rh_resume(struct* autostop isn't used when CONFIG_PM is turned off. */ static int ohci_root_hub_state_changes (struct ohci_hcd *ohci,int changed, -int any_connected) +int any_connected,int rhsc_status) { -int rhsc_status; -/* If RHSC is enabled, don't poll */ if (ohci_readl (ohci, &ohci->regs->intrenable) &OHCI_INTR_RHSC )return 0 ; -/* If no status changes are pending, enable RHSC interrupts */ - rhsc_status =ohci_readl (ohci, &ohci->regs->intrstatus) & -OHCI_INTR_RHSC ; -if (!changed && !rhsc_status) { -ohci_writel (ohci,OHCI_INTR_RHSC , &ohci->regs->intrenable); -return 0 ; - } -return 1 ; +/* If status changes are pending, continue polling. +* Conversely, if no status changes are pending but the RHSC +* status bit was set, then RHSC may be broken so continue polling. +*/ +if (changed || rhsc_status) +return 1 ; + +/* It's safe to re-enable RHSC interrupts */ +ohci_writel (ohci,OHCI_INTR_RHSC , &ohci->regs->intrenable); +return 0 ; }#endif /* CONFIG_PM */
@@ -478,6 +485,7 @@ ohci_hub_status_data (struct usb_hcd *hcstruct ohci_hcd *ohci =hcd_to_ohci (hcd);int i, changed =0 , length =1 ;int any_connected =0 ; +int rhsc_status;unsigned long flags;spin_lock_irqsave (&ohci->lock, flags);
@@ -503,6 +511,11 @@ ohci_hub_status_data (struct usb_hcd *hc length++; } +/* Clear the RHSC status flag before reading the port statuses */ +ohci_writel (ohci,OHCI_INTR_RHSC , &ohci->regs->intrstatus); + rhsc_status =ohci_readl (ohci, &ohci->regs->intrstatus) & +OHCI_INTR_RHSC ; +/* look at each port */ for (i =0 ; i < ohci->num_ports; i++) {u32 status =roothub_portstatus (ohci, i);
@@ -521,7 +534,7 @@ ohci_hub_status_data (struct usb_hcd *hc } hcd->poll_rh =ohci_root_hub_state_changes (ohci, changed, - any_connected); + any_connected, rhsc_status); done:spin_unlock_irqrestore (&ohci->lock, flags);
PATCH 11/17 USB: Fix s3c2410_udc usb speed handling
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Yauhen Kharuzhy <[email protected]>
commit f9e9cff613b8239ce9159735aa662c9c85b478bf upstream
The new composite framework revealed a weakness in the s3c2410_udc driver gadget register function. Instead of checking if speed asked for was USB_LOW_SPEED upon usb_gadget_register() to deny service, it checked only for USB_FULL_SPEED, thus denying service to usb high speed capable gadgets (like g_ether).
--- drivers/usb/gadget/s3c2410_udc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/s3c2410_udc.c +1 -1
@@ -1651,7 +1651,7 @@ int usb_gadget_register_driver(struct usreturn -EBUSY ;if (!driver->bind || !driver->setup - || driver->speed !=USB_SPEED_FULL ) { + || driver->speed <USB_SPEED_FULL ) {printk (KERN_ERR "Invalid driver: bind %p setup %p speed %d\n" , driver->bind, driver->setup, driver->speed);return -EINVAL ;
PATCH 12/17 USB: EHCI: log a warning if ehci-hcd is not loaded first
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
commit 9beeee6584b9aa4f9192055512411484a2a624df upstream
This patch (as1139) adds a warning to the system log whenever ehci-hcd is loaded after ohci-hcd or uhci-hcd. Nowadays most distributions are pretty good about not doing this; maybe the warning will help convince anyone still doing it wrong.
--- drivers/usb/core/hcd.c | 4 ++++ drivers/usb/core/hcd.h | 6 ++++++ drivers/usb/host/ehci-hcd.c | 15 +++++++++++++-- drivers/usb/host/ohci-hcd.c | 3 +++ drivers/usb/host/uhci-hcd.c | 3 +++ 5 files changed, 29 insertions(+), 2 deletions(-)
drivers/usb/core/hcd.c +4 -0
@@ -81,6 +81,10 @@/*-------------------------------------------------------------------------*/ +/* Keep track of which host controller drivers are loaded */ +unsigned long usb_hcds_loaded; +EXPORT_SYMBOL_GPL (usb_hcds_loaded); +/* host controllers we manage */ LIST_HEAD (usb_bus_list);EXPORT_SYMBOL_GPL (usb_bus_list);
drivers/usb/core/hcd.h +6 -0
@@ -482,4 +482,10 @@ static inline void usbmon_urb_complete(s*/ extern struct rw_semaphore ehci_cf_port_reset_rwsem; +/* Keep track of which host controller drivers are loaded */ +#define USB_UHCI_LOADED 0 +#define USB_OHCI_LOADED 1 +#define USB_EHCI_LOADED 2 +extern unsigned long usb_hcds_loaded; +#endif /* __KERNEL__ */
drivers/usb/host/ehci-hcd.c +13 -2
@@ -1049,6 +1049,12 @@ static int __init ehci_hcd_init(void) {int retval =0 ; +set_bit (USB_EHCI_LOADED , &usb_hcds_loaded); +if (test_bit (USB_UHCI_LOADED , &usb_hcds_loaded) || +test_bit (USB_OHCI_LOADED , &usb_hcds_loaded)) +printk (KERN_WARNING "Warning! ehci_hcd should always be loaded" +" before uhci_hcd and ohci_hcd, not after\n" ); + pr_debug("%s: block sizes: qh %Zd qtd %Zd itd %Zd sitd %Zd\n", hcd_name, sizeof(struct ehci_qh), sizeof(struct ehci_qtd),
@@ -1056,8 +1062,10 @@ static int __init ehci_hcd_init(void)#ifdef DEBUG ehci_debug_root =debugfs_create_dir ("ehci" ,NULL ); -if (!ehci_debug_root) -return -ENOENT ; +if (!ehci_debug_root) { + retval = -ENOENT ; + goto err_debug; + }#endif #ifdef PLATFORM_DRIVER
@@ -1104,7 +1112,9 @@ clean0:#ifdef DEBUG debugfs_remove (ehci_debug_root); ehci_debug_root =NULL ; +err_debug:#endif +clear_bit (USB_EHCI_LOADED , &usb_hcds_loaded);return retval; }module_init (ehci_hcd_init);
@@ -1126,6 +1136,7 @@ static void __exit ehci_hcd_cleanup(void#ifdef DEBUG debugfs_remove (ehci_debug_root);#endif +clear_bit (USB_EHCI_LOADED , &usb_hcds_loaded); }module_exit (ehci_hcd_cleanup);
drivers/usb/host/ohci-hcd.c +3 -0
@@ -1098,6 +1098,7 @@ static int __init ohci_hcd_mod_init(voidprintk (KERN_DEBUG "%s: " DRIVER_INFO "\n" , hcd_name);pr_debug ("%s: block sizes: ed %Zd td %Zd\n" , hcd_name,sizeof (struct ed ),sizeof (struct td )); +set_bit (USB_OHCI_LOADED , &usb_hcds_loaded);#ifdef DEBUG ohci_debug_root =debugfs_create_dir ("ohci" ,NULL );
@@ -1184,6 +1185,7 @@ static int __init ohci_hcd_mod_init(void error_debug:#endif +clear_bit (USB_OHCI_LOADED , &usb_hcds_loaded);return retval; }module_init (ohci_hcd_mod_init);
@@ -1214,6 +1216,7 @@ static void __exit ohci_hcd_mod_exit(voi#ifdef DEBUG debugfs_remove (ohci_debug_root);#endif +clear_bit (USB_OHCI_LOADED , &usb_hcds_loaded); }module_exit (ohci_hcd_mod_exit);
drivers/usb/host/uhci-hcd.c +3 -0
@@ -953,6 +953,7 @@ static int __init uhci_hcd_init(void) printk(KERN_INFO DRIVER_DESC " " DRIVER_VERSION "%s\n", ignore_oc ? ", overcurrent ignored" : ""); +set_bit (USB_UHCI_LOADED , &usb_hcds_loaded);if (usb_disabled ())return -ENODEV ;
@@ -988,6 +989,7 @@ debug_failed: errbuf_failed: +clear_bit (USB_UHCI_LOADED , &usb_hcds_loaded);return retval; }
@@ -997,6 +999,7 @@ static void __exit uhci_hcd_cleanup(voidkmem_cache_destroy (uhci_up_cachep);debugfs_remove (uhci_debugfs_root);kfree (errbuf); +clear_bit (USB_UHCI_LOADED , &usb_hcds_loaded); }module_init (uhci_hcd_init);
PATCH 13/17 usb gadget: cdc ethernet notification bugfix
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: David Brownell <[email protected]>
commit 29bac7b7661bbbdbbd32bc1e6cedca22f260da7f upstream
Bugfix for the new CDC Ethernet code: as part of activating the network interface's USB link, make sure its link management code knows whether the interface is open or not.
Without this fix, the link won't work right when it's brought up before the link is active ... because the initial notification it sends will have the wrong link state (down, not up). Makes it hard to bridge these links (on the host side), among other things.
--- drivers/usb/gadget/u_ether.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/usb/gadget/u_ether.c +7 -0
@@ -873,6 +873,13 @@ struct net_device *gether_connect(structspin_lock (&dev->lock); dev->port_usb = link; link->ioport = dev; +if (netif_running (dev->net)) { +if (link->open) + link->open (link); + }else { +if (link->close) + link->close (link); + }spin_unlock (&dev->lock);netif_carrier_on (dev->net);
PATCH 14/17 usb: musb_hdrc build fixes
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: David Brownell <[email protected]>
commit c767c1c6f1febbd1351cc152bba6e37889322d17 upstream
Minor musb_hdrc updates:
- so it'll build on DaVinci, given relevant platform updates;
* remove support for an un-shipped OTG prototype
* rely on gpiolib framework conversion for the I2C GPIOs
* the <asm/arch/hdrc_cnf.h> mechanism has been removed
- catch comments up to the recent removal of the per-SOC header
with the silicon configuration data;
- and remove two inappropriate "inline" declarations which just bloat host side code.
There are still some more <asm/arch/XYZ.h> ==> <mach/XYZ.h> changes needed in this driver, catching up to the relocation of most of the include/asm-arm/arch-* contents.
--- drivers/usb/musb/Kconfig | 4 ---- drivers/usb/musb/cppi_dma.h | 4 ++-- drivers/usb/musb/davinci.c | 20 ++++---------------- drivers/usb/musb/musb_core.c | 8 ++++---- drivers/usb/musb/musb_host.c | 6 +++--- 5 files changed, 13 insertions(+), 29 deletions(-)
drivers/usb/musb/cppi_dma.h +2 -2
@@ -119,8 +119,8 @@ struct cppi {void __iomem *mregs;/* Mentor regs */ void __iomem *tibase;/* TI/CPPI regs */ -struct cppi_channel tx[MUSB_C_NUM_EPT -1 ]; -struct cppi_channel rx[MUSB_C_NUM_EPR -1 ]; +struct cppi_channel tx[4 ]; +struct cppi_channel rx[4 ];struct dma_pool *pool;
drivers/usb/musb/davinci.c +4 -16
@@ -30,6 +30,7 @@#include <linux/delay.h> #include <linux/clk.h> #include <linux/io.h> +#include <linux/gpio.h> #include <asm/arch/hardware.h> #include <asm/arch/memory.h>
@@ -39,7 +40,7 @@#include "musb_core.h" #ifdef CONFIG_MACH_DAVINCI_EVM -#include <asm/arch/i2c-client.h> +#define GPIO_nVBUS_DRV 87#endif #include "davinci.h"
@@ -138,7 +139,6 @@ static int vbus_state = -1;/* VBUS SWITCHING IS BOARD-SPECIFIC */ #ifdef CONFIG_MACH_DAVINCI_EVM -#ifndef CONFIG_MACH_DAVINCI_EVM_OTG /* I2C operations are always synchronous, and require a task context. * With unloaded systems, using the shared workqueue seems to suffice
@@ -146,12 +146,11 @@ static int vbus_state = -1;*/ static void evm_deferred_drvvbus (struct work_struct *ignored) { -davinci_i2c_expander_op (0x3a ,USB_DRVVBUS , vbus_state); +gpio_set_value_cansleep (GPIO_nVBUS_DRV, vbus_state); vbus_state = !vbus_state; } static DECLARE_WORK(evm_vbus_work, evm_deferred_drvvbus); -#endif /* modified board */ #endif /* EVM */ static void davinci_source_power (struct musb *musb,int is_on,int immediate)
@@ -165,21 +164,10 @@ static void davinci_source_power(struct#ifdef CONFIG_MACH_DAVINCI_EVM if (machine_is_davinci_evm ()) { -#ifdef CONFIG_MACH_DAVINCI_EVM_OTG -/* modified EVM board switching VBUS with GPIO(6) not I2C -* NOTE: PINMUX0.RGB888 (bit23) must be clear -*/ -if (is_on) -gpio_set (GPIO (6 )); -else -gpio_clear (GPIO (6 )); - immediate =1 ; -#else if (immediate) -davinci_i2c_expander_op (0x3a ,USB_DRVVBUS , !is_on); +gpio_set_value_cansleep (GPIO_nVBUS_DRV, vbus_state);else schedule_work (&evm_vbus_work); -#endif }#endif if (immediate)
drivers/usb/musb/Kconfig +0 -4
@@ -33,10 +33,6 @@ config USB_MUSB_SOC default y if ARCH_DAVINCI default y if ARCH_OMAP2430 default y if ARCH_OMAP34XX - help - Use a static <asm/arch/hdrc_cnf.h> file to describe how the - controller is configured (endpoints, mechanisms, etc) on the - current iteration of a given system-on-chip. comment "DaVinci 644x USB support" depends on USB_MUSB_HDRC && ARCH_DAVINCI
drivers/usb/musb/musb_core.c +4 -4
@@ -82,9 +82,9 @@/* * This gets many kinds of configuration information: * - Kconfig for everything user-configurable -* - <asm/arch/hdrc_cnf.h> for SOC or family details * - platform_device for addressing, irq, and platform_data * - platform_data is mostly for board-specific informarion +* (plus recentrly, SOC or family details) * * Most of the conditional compilation will (someday) vanish. */
@@ -974,9 +974,9 @@ static void musb_shutdown(struct platfor/* * The silicon either has hard-wired endpoint configurations, or else * "dynamic fifo" sizing. The driver has support for both, though at this -* writing only the dynamic sizing is very well tested. We use normal -* idioms to so both modes are compile-tested, but dead code elimination -* leaves only the relevant one in the object file. +* writing only the dynamic sizing is very well tested. Since we switched +* away from compile-time hardware parameters, we can no longer rely on +* dead code elimination to leave only the relevant one in the object file. * * We don't currently use dynamic fifo setup capability to do anything * more than selecting one of a bunch of predefined configurations.
drivers/usb/musb/musb_host.c +3 -3
@@ -108,7 +108,7 @@ static void musb_ep_program(struct musb/* * Clear TX fifo. Needed to avoid BABBLE errors. */ -static inline void musb_h_tx_flush_fifo (struct musb_hw_ep *ep) +static void musb_h_tx_flush_fifo (struct musb_hw_ep *ep) {void __iomem *epio = ep->regs;u16 csr;
@@ -436,7 +436,7 @@ musb_advance_schedule(struct musb *musb, } } -static inline u16 musb_h_flush_rxfifo (struct musb_hw_ep *hw_ep,u16 csr) +static u16 musb_h_flush_rxfifo (struct musb_hw_ep *hw_ep,u16 csr) {/* we don't want fifo to fill itself again; * ignore dma (various models),
@@ -1005,7 +1005,7 @@ static bool musb_h_ep0_continue(struct m/* * Handle default endpoint interrupt as host. Only called in IRQ time -* from the LinuxIsr() interrupt service routine. +* from musb_interrupt(). * * called with controller irqlocked */
PATCH 15/17 drm/i915: fix ioremap of a user address for non-root (CVE-2008-3831)
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Matthias Hopf <[email protected]>
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.
--- drivers/gpu/drm/i915/i915_dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/i915_dma.c +1 -1
@@ -836,7 +836,7 @@ struct drm_ioctl_desc i915_ioctls[] = {DRM_IOCTL_DEF (DRM_I915_SET_VBLANK_PIPE , i915_vblank_pipe_set,DRM_AUTH |DRM_MASTER |DRM_ROOT_ONLY ),DRM_IOCTL_DEF (DRM_I915_GET_VBLANK_PIPE , i915_vblank_pipe_get,DRM_AUTH ),DRM_IOCTL_DEF (DRM_I915_VBLANK_SWAP , i915_vblank_swap,DRM_AUTH ), - DRM_IOCTL_DEF(DRM_I915_HWS_ADDR, i915_set_status_page, DRM_AUTH), + DRM_IOCTL_DEF(DRM_I915_HWS_ADDR, i915_set_status_page, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY), };int i915_max_ioctl =DRM_ARRAY_SIZE (i915_ioctls);
PATCH 16/17 DVB: au0828: add support for another USB id for Hauppauge HVR950Q
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Michael Krufky <[email protected]>
(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)
--- Documentation/video4linux/CARDLIST.au0828 | 2 +- drivers/media/video/au0828/au0828-cards.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-)
Documentation/video4linux/CARDLIST.au0828 +1 -1
@@ -1,5 +1,5 @@ 0 -> Unknown board (au0828) - 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721f,2040:7280,0fd9:0008] + 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721e,2040:721f,2040:7280,0fd9:0008] 2 -> Hauppauge HVR850 (au0828) [2040:7240] 3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620] 4 -> Hauppauge HVR950Q rev xxF8 (au0828) [2040:7201,2040:7211,2040:7281]
drivers/media/video/au0828/au0828-cards.c +3 -0
@@ -90,6 +90,7 @@ static void hauppauge_eeprom(struct au08case 72221 :/* WinTV-HVR950q (OEM, IR, ATSC/QAM and basic analog video */ case 72231 :/* WinTV-HVR950q (OEM, IR, ATSC/QAM and basic analog video */ case 72241 :/* WinTV-HVR950q (OEM, No IR, ATSC/QAM and basic analog video */ +case 72251 :/* WinTV-HVR950q (Retail, IR, ATSC/QAM and basic analog video */ case 72301 :/* WinTV-HVR850 (Retail, IR, ATSC and basic analog video */ case 72500 :/* WinTV-HVR950q (OEM, No IR, ATSC/QAM */ break ;
@@ -198,6 +199,8 @@ struct usb_device_id au0828_usb_id_table .driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q }, { USB_DEVICE(0x2040, 0x721b), .driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q }, + { USB_DEVICE(0x2040, 0x721e), + .driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q }, { USB_DEVICE(0x2040, 0x721f), .driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q }, { USB_DEVICE(0x2040, 0x7280),
PATCH 17/17 DVB: sms1xxx: support two new revisions of the Hauppauge WinTV MiniStick
In reply to Greg KH2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Michael Krufky <[email protected]>
(cherry picked from commit 3dfbe31f09fb1da5f17437fd384cdfb6114765d9)
DVB: sms1xxx: support two new revisions of the Hauppauge WinTV MiniStick
Autodetect 2040:5520 and 2040:5530 as Hauppauge WinTV MiniStick
--- drivers/media/dvb/siano/sms-cards.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/media/dvb/siano/sms-cards.c +4 -0
@@ -42,6 +42,10 @@ struct usb_device_id smsusb_id_table[] = .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM }, { USB_DEVICE(0x2040, 0x5510), .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM }, + { USB_DEVICE(0x2040, 0x5520), + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM }, + { USB_DEVICE(0x2040, 0x5530), + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM }, { USB_DEVICE(0x2040, 0x5580), .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM }, { USB_DEVICE(0x2040, 0x5590),
Quoted 3 lines · Greg KH
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.27.3-rc1.gzand the diffstat can be found below.
Oops, forgot it, here it is.
Documentation/video4linux/CARDLIST.au0828 | 2 Makefile | 2 drivers/base/core.c | 25 ++++++-- drivers/gpu/drm/i915/i915_dma.c | 2 drivers/md/md.c | 6 -- drivers/media/dvb/siano/sms-cards.c | 4 + drivers/media/video/au0828/au0828-cards.c | 3 + drivers/net/wireless/ath9k/core.h | 2 drivers/net/wireless/ath9k/main.c | 8 ++ drivers/usb/core/hcd.c | 4 + drivers/usb/core/hcd.h | 6 ++ drivers/usb/gadget/s3c2410_udc.c | 2 drivers/usb/gadget/u_ether.c | 7 ++ drivers/usb/host/ehci-hcd.c | 15 ++++- drivers/usb/host/ohci-hcd.c | 3 + drivers/usb/host/ohci-hub.c | 87 +++++++++++++++++------------- drivers/usb/host/uhci-hcd.c | 3 + drivers/usb/musb/Kconfig | 4 - drivers/usb/musb/cppi_dma.h | 4 - drivers/usb/musb/davinci.c | 20 +----- drivers/usb/musb/musb_core.c | 8 +- drivers/usb/musb/musb_host.c | 6 +- drivers/video/console/fbcon.c | 4 - fs/xfs/linux-2.6/xfs_super.c | 2 kernel/module.c | 2 net/mac80211/wext.c | 2 26 files changed, 146 insertions(+), 87 deletions(-)
Quoted 6 lines · Greg KH
This is the start of the stable review cycle for the 2.6.27.3 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Quoted 7 lines
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.Responses should be made by Wed, October 22, 2008 19:00:00 UTC. Anything received after that time might be too late.
OK, I realize I'm late. Apologies in advance for that.
I don't see how patches 3, 16, and 17 really fit into the "stable" rules. None of them:
"... fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical."
So, are we being a bit more lax on the requirements for the -stable kernels and I missed the memo, or?
josh
Quoted 20 lines · Josh Boyer
Quoted 6 lines · Greg KH
This is the start of the stable review cycle for the 2.6.27.3 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Quoted 7 lines
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.Responses should be made by Wed, October 22, 2008 19:00:00 UTC. Anything received after that time might be too late.
OK, I realize I'm late. Apologies in advance for that.
I don't see how patches 3, 16, and 17 really fit into the "stable" rules. None of them:
Quoted 7 lines
"... fix a problem that causes a build error (but not for things
markedCONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical."So, are we being a bit more lax on the requirements for the -stable kernels and I missed the memo, or?
3 definitely is "oh that's not good", and 16&17 are just support for a few new IDs. It's not the first time this happens, and as long as there are not too many or they don't change the driver's code, I don't see the problem. It increases the ability for people to test the kernel and report bugs too BTW.
I think it's better to have strict rules and be lax sometimes than having no rules at all or being too strict and annoy users.
Willy
Quoted 20 lines · Josh Boyer
Quoted 6 lines · Greg KH
This is the start of the stable review cycle for the 2.6.27.3 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Quoted 7 lines
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.Responses should be made by Wed, October 22, 2008 19:00:00 UTC. Anything received after that time might be too late.
OK, I realize I'm late. Apologies in advance for that.
I don't see how patches 3, 16, and 17 really fit into the "stable" rules. None of them:
Quoted 7 lines
"... fix a problem that causes a build error (but not for things
markedCONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical."So, are we being a bit more lax on the requirements for the -stable kernels and I missed the memo, or?
Huh?
Patch 3:
Driver core: Fix cleanup in device_create_vargs().
solves a memory leak on an error path that has every opportunity to happen in the driver core. Do you think this is not a real bug?
Patch 16 and 17 add new device ids, something that we started allowing in -stable trees a number of major releases ago. You missed the memo for that one :)
Perhaps we need to add it to the file Documentation/stable_kernel_rules.txt, anyone care to send a patch?
thanks,
greg k-h
Quoted 29 lines · On Wed, 22 Oct 2008 21:53:45 -0700 Greg KH <[email protected]> wrote:
Quoted 20 lines · Josh Boyer
Quoted 6 lines · Greg KH
This is the start of the stable review cycle for the 2.6.27.3 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Quoted 7 lines
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.Responses should be made by Wed, October 22, 2008 19:00:00 UTC. Anything received after that time might be too late.
OK, I realize I'm late. Apologies in advance for that.
I don't see how patches 3, 16, and 17 really fit into the "stable" rules. None of them:
Quoted 7 lines
"... fix a problem that causes a build error (but not for things
markedCONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical."So, are we being a bit more lax on the requirements for the -stable kernels and I missed the memo, or?
Quoted 6 lines
Huh?
Patch 3:
Driver core: Fix cleanup indevice_create_vargs().
solves a memory leak on an error path that has every opportunity to happen in the driver core. Do you think this is not a real bug?
Grr.. Typo on my part. Patch 4 is the one I originally meant:
"Driver Core: Clarify device cleanup." It changes nothing but comments. I don't think it's a big deal at all, but are documentation changes also allowed now?
Quoted 6 lines
Patch 16 and 17 add new device ids, something that we started allowing in -stable trees a number of major releases ago. You missed the memo for that one :)
Perhaps we need to add it to the file
Documentation/stable_kernel_rules.txt, anyone care to send a patch?
Will do as soon as I get an answer to the question above.
josh
Quoted 39 lines · Josh Boyer
Quoted 29 lines · On Wed, 22 Oct 2008 21:53:45 -0700 Greg KH <[email protected]> wrote:
Quoted 20 lines · Josh Boyer
Quoted 6 lines · Greg KH
This is the start of the stable review cycle for the 2.6.27.3 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Quoted 7 lines
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.Responses should be made by Wed, October 22, 2008 19:00:00 UTC. Anything received after that time might be too late.
OK, I realize I'm late. Apologies in advance for that.
I don't see how patches 3, 16, and 17 really fit into the "stable" rules. None of them:
Quoted 7 lines
"... fix a problem that causes a build error (but not for things
markedCONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical."So, are we being a bit more lax on the requirements for the -stable kernels and I missed the memo, or?
Quoted 6 lines
Huh?
Patch 3:
Driver core: Fix cleanup indevice_create_vargs().
solves a memory leak on an error path that has every opportunity to happen in the driver core. Do you think this is not a real bug?
Quoted 4 lines
Grr.. Typo on my part. Patch 4 is the one I originally meant:
"Driver Core: Clarify device cleanup." It changes nothing but comments. I don't think it's a big deal at all, but are documentation changes also allowed now?
It was a documentation change, fixing the information for a core API call to be correct and match what the code really does.
It also carried no risk of a regression, and as such, I decided to take it. If you note, we have also taken other patches that fix up documentation issues like this in the past, so it was not the first time.
Was this that big of a deal?
thanks,
greg k-h
Quoted 48 lines · On Thu, 23 Oct 2008 08:33:48 -0700 Greg KH <[email protected]> wrote:
Quoted 39 lines · Josh Boyer
Quoted 29 lines · On Wed, 22 Oct 2008 21:53:45 -0700 Greg KH <[email protected]> wrote:
Quoted 20 lines · Josh Boyer
Quoted 6 lines · Greg KH
This is the start of the stable review cycle for the 2.6.27.3 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Quoted 7 lines
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.Responses should be made by Wed, October 22, 2008 19:00:00 UTC. Anything received after that time might be too late.
OK, I realize I'm late. Apologies in advance for that.
I don't see how patches 3, 16, and 17 really fit into the "stable" rules. None of them:
Quoted 7 lines
"... fix a problem that causes a build error (but not for things
markedCONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical."So, are we being a bit more lax on the requirements for the -stable kernels and I missed the memo, or?
Quoted 6 lines
Huh?
Patch 3:
Driver core: Fix cleanup indevice_create_vargs().
solves a memory leak on an error path that has every opportunity to happen in the driver core. Do you think this is not a real bug?Quoted 4 lines
Grr.. Typo on my part. Patch 4 is the one I originally meant:
"Driver Core: Clarify device cleanup." It changes nothing but comments. I don't think it's a big deal at all, but are documentation changes also allowed now?It was a documentation change, fixing the information for a core API call to be correct and match what the code really does.
Quoted 6 lines
It also carried no risk of a regression, and as such, I decided to take it. If you note, we have also taken other patches that fix up documentation issues like this in the past, so it was not the first time.
Was this that big of a deal?
No. I said that already. I'm just trying to clarify what the expectations are for -stable because when it first started stuff liek that wasn't taken. Also, it seems nobody has updated the documentation file as -stable has evolved. I'd be more than happy to correct that, but I just need to get a feel for where -stable is at before I can do that.
Not trying to be a stick in the mud, just trying to help. If you'd rather I don't, that's fine too.
josh
Quoted 7 lines · Josh Boyer
No. I said that already. I'm just trying to clarify what the expectations are for -stable because when it first started stuff liek that wasn't taken. Also, it seems nobody has updated the documentation file as -stable has evolved. I'd be more than happy to correct that, but I just need to get a feel for where -stable is at before I can do that.
Adding the "we accept new device ids and quirks" would be good to have added to the file, I have no problem with that.
thanks,
greg k-h