3.0.94-stable review
Subsystems (9)
Greg Kroah-Hartman
maintainercover 3.0.94-stable review
This is the start of the stable review cycle for the 3.0.94 release. There are 9 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 me know.
Responses should be made by Thu Aug 29 01:02:44 UTC 2013. 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/v3.0/stable-review/patch-3.0.94-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.0.94-rc1
Martin Peschke <[email protected]>
SCSI: zfcp: fix schedule-inside-lock in scsi_device list loops
Martin Peschke <[email protected]>
SCSI: zfcp: fix lock imbalance by reworking request queue locking
Terry Suereth <[email protected]>
libata: apply behavioral quirks to sil3826 PMP
Dan Carpenter <[email protected]>
Hostap: copying wrong data prism2_ioctl_giwaplist()
Vyacheslav Dubeyko <[email protected]>
nilfs2: fix issue with counting number of bio requests for BIO_EOPNOTSUPP error detection
Vyacheslav Dubeyko <[email protected]>
nilfs2: remove double bio_put() in nilfs_end_bio_write() for BIO_EOPNOTSUPP error
Wladislav Wiebe <[email protected]>
of: fdt: fix memory initialization for expanded DT
David Vrabel <[email protected]>
xen/events: initialize local per-cpu mask for all possible events
Jussi Kivilinna <[email protected]>
zd1201: do not use stack as URB transfer_buffer
-------------
Diffstat:
Makefile | 4 +-- drivers/ata/libata-pmp.c | 12 +++---- drivers/net/wireless/hostap/hostap_ioctl.c | 4 +-- drivers/net/wireless/zd1201.c | 4 ++- drivers/of/fdt.c | 2 ++ drivers/s390/scsi/zfcp_erp.c | 29 +++++++++++---- drivers/s390/scsi/zfcp_qdio.c | 8 ++--- drivers/xen/events.c | 2 +- fs/nilfs2/segbuf.c | 5 ++- include/linux/wait.h | 57 ++++++++++++++++++++++++++++++ 10 files changed, 99 insertions(+), 28 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/9 zd1201: do not use stack as URB transfer_buffer
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jussi Kivilinna <[email protected]>
commit 1206ff4ff9d2ef7468a355328bc58ac6ebf5be44 upstream.
Patch fixes zd1201 not to use stack as URB transfer_buffer. URB buffers need to be DMA-able, which stack is not.
Patch is only compile tested.
--- drivers/net/wireless/zd1201.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/wireless/zd1201.c +3 -1
@@ -98,10 +98,12 @@ static int zd1201_fw_upload(struct usb_d goto exit; err =usb_control_msg (dev,usb_rcvctrlpipe (dev,0 ),0x4 , -USB_DIR_IN |0x40 ,0 ,0 , &ret,sizeof (ret),ZD1201_FW_TIMEOUT ); +USB_DIR_IN |0x40 ,0 ,0 , buf,sizeof (ret),ZD1201_FW_TIMEOUT );if (err <0 ) goto exit; +memcpy (&ret, buf,sizeof (ret)); +if (ret &0x80 ) { err = -EIO ; goto exit;
Greg Kroah-Hartman
maintainerPATCH 2/9 xen/events: initialize local per-cpu mask for all possible events
In reply to Greg Kroah-Hartman3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Vrabel <[email protected]>
commit 84ca7a8e45dafb49cd5ca90a343ba033e2885c17 upstream.
The sizeof() argument in init_evtchn_cpu_bindings() is incorrect resulting in only the first 64 (or 32 in 32-bit guests) ports having their bindings being initialized to VCPU 0.
In most cases this does not cause a problem as request_irq() will set the irq affinity which will set the correct local per-cpu mask. However, if the request_irq() is called on a VCPU other than 0, there is a window between the unmasking of the event and the affinity being set were an event may be lost because it is not locally unmasked on any VCPU. If request_irq() is called on VCPU 0 then local irqs are disabled during the window and the race does not occur.
Fix this by initializing all NR_EVENT_CHANNEL bits in the local per-cpu masks.
--- drivers/xen/events.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/xen/events.c +1 -1
@@ -317,7 +317,7 @@ static void init_evtchn_cpu_bindings(voifor_each_possible_cpu (i)memset (per_cpu (cpu_evtchn_mask, i), - (i ==0 ) ? ~0 :0 ,sizeof (*per_cpu (cpu_evtchn_mask, i))); + (i ==0 ) ? ~0 :0 ,NR_EVENT_CHANNELS /8 ); }static inline void clear_evtchn (int port)
Greg Kroah-Hartman
maintainerPATCH 3/9 of: fdt: fix memory initialization for expanded DT
In reply to Greg Kroah-Hartman3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wladislav Wiebe <[email protected]>
commit 9e40127526e857fa3f29d51e83277204fbdfc6ba upstream.
Already existing property flags are filled wrong for properties created from initial FDT. This could cause problems if this DYNAMIC device-tree functions are used later, i.e. properties are attached/detached/replaced. Simply dumping flags from the running system show, that some initial static (not allocated via kzmalloc()) nodes are marked as dynamic.
I putted some debug extensions to property_proc_show(..) :
..
+ if (OF_IS_DYNAMIC(pp))
+ pr_err("DEBUG: xxx : OF_IS_DYNAMIC\n");
+ if (OF_IS_DETACHED(pp))
+ pr_err("DEBUG: xxx : OF_IS_DETACHED\n");
when you operate on the nodes (e.g.: ~$ cat /proc/device-tree/*some_node*) you will see that those flags are filled wrong, basically in most cases it will dump a DYNAMIC or DETACHED status, which is in not true.
(BTW. this OF_IS_DETACHED is a own define for debug purposes which which just make a test_bit(OF_DETACHED, &x->_flags)
If nodes are dynamic kernel is allowed to kfree() them. But it will crash attempting to do so on the nodes from FDT -- they are not allocated via kzmalloc().
--- drivers/of/fdt.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/of/fdt.c +2 -0
@@ -389,6 +389,8 @@ static void __unflatten_device_tree(stru mem = (unsigned long )dt_alloc (size +4 , __alignof__(struct device_node )); +memset ((void *)mem,0 , size); + ((__be32 *)mem)[size /4 ] =cpu_to_be32 (0xdeadbeef );pr_debug (" unflattening %lx...\n" , mem);
Greg Kroah-Hartman
maintainerPATCH 4/9 nilfs2: remove double bio_put() in nilfs_end_bio_write() for BIO_EOPNOTSUPP error
In reply to Greg Kroah-Hartman3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vyacheslav Dubeyko <[email protected]>
commit 2df37a19c686c2d7c4e9b4ce1505b5141e3e5552 upstream.
Remove double call of bio_put() in nilfs_end_bio_write() for the case of BIO_EOPNOTSUPP error detection. The issue was found by Dan Carpenter and he suggests first version of the fix too.
--- fs/nilfs2/segbuf.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/nilfs2/segbuf.c +1 -2
@@ -345,8 +345,7 @@ static void nilfs_end_bio_write(struct bif (err == -EOPNOTSUPP ) {set_bit (BIO_EOPNOTSUPP , &bio->bi_flags); -bio_put (bio); -/* to be detected by submit_seg_bio() */ +/* to be detected by nilfs_segbuf_submit_bio() */ }if (!uptodate)
Greg Kroah-Hartman
maintainerPATCH 5/9 nilfs2: fix issue with counting number of bio requests for BIO_EOPNOTSUPP error detection
In reply to Greg Kroah-Hartman3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vyacheslav Dubeyko <[email protected]>
commit 4bf93b50fd04118ac7f33a3c2b8a0a1f9fa80bc9 upstream.
Fix the issue with improper counting number of flying bio requests for BIO_EOPNOTSUPP error detection case.
The sb_nbio must be incremented exactly the same number of times as complete() function was called (or will be called) because nilfs_segbuf_wait() will call wail_for_completion() for the number of times set to sb_nbio:
do {
wait_for_completion(&segbuf->sb_bio_event);
} while (--segbuf->sb_nbio > 0);Two functions complete() and wait_for_completion() must be called the same number of times for the same sb_bio_event. Otherwise, wait_for_completion() will hang or leak.
--- fs/nilfs2/segbuf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nilfs2/segbuf.c +1 -1
@@ -376,12 +376,12 @@ static int nilfs_segbuf_submit_bio(struc bio->bi_private = segbuf;bio_get (bio);submit_bio (mode, bio); + segbuf->sb_nbio++;if (bio_flagged (bio,BIO_EOPNOTSUPP )) {bio_put (bio); err = -EOPNOTSUPP ; goto failed; } - segbuf->sb_nbio++;bio_put (bio); wi->bio =NULL ;
Greg Kroah-Hartman
maintainerPATCH 6/9 Hostap: copying wrong data prism2_ioctl_giwaplist()
In reply to Greg Kroah-Hartman3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 909bd5926d474e275599094acad986af79671ac9 upstream.
We want the data stored in "addr" and "qual", but the extra ampersands mean we are copying stack data instead.
--- drivers/net/wireless/hostap/hostap_ioctl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/wireless/hostap/hostap_ioctl.c +2 -2
@@ -521,9 +521,9 @@ static int prism2_ioctl_giwaplist(struct data->length =prism2_ap_get_sta_qual (local, addr, qual,IW_MAX_AP ,1 ); -memcpy (extra, &addr,sizeof (struct sockaddr ) * data->length); +memcpy (extra, addr,sizeof (struct sockaddr ) * data->length); data->flags =1 ;/* has quality information */ -memcpy (extra +sizeof (struct sockaddr ) * data->length, &qual, +memcpy (extra +sizeof (struct sockaddr ) * data->length, qual,sizeof (struct iw_quality ) * data->length);kfree (addr);
Greg Kroah-Hartman
maintainerPATCH 7/9 libata: apply behavioral quirks to sil3826 PMP
In reply to Greg Kroah-Hartman3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Terry Suereth <[email protected]>
commit 8ffff94d20b7eb446e848e0046107d51b17a20a8 upstream.
Fixing support for the Silicon Image 3826 port multiplier, by applying to it the same quirks applied to the Silicon Image 3726. Specifically fixes the repeated timeout/reset process which previously afflicted the 3726, as described from line 290. Slightly based on notes from:
https://bugzilla.redhat.com/show_bug.cgi?id=890237
--- drivers/ata/libata-pmp.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/ata/libata-pmp.c +6 -6
@@ -288,24 +288,24 @@ static int sata_pmp_configure(struct ata/* Disable sending Early R_OK. * With "cached read" HDD testing and multiple ports busy on a SATA -* host controller, 3726 PMP will very rarely drop a deferred +* host controller, 3x26 PMP will very rarely drop a deferred * R_OK that was intended for the host. Symptom will be all * 5 drives under test will timeout, get reset, and recover. */ -if (vendor ==0x1095 && devid ==0x3726 ) { +if (vendor ==0x1095 && (devid ==0x3726 || devid ==0x3826 )) {u32 reg; err_mask =sata_pmp_read (&ap->link,PMP_GSCR_SII_POL , ®);if (err_mask) { rc = -EIO ; - reason ="failed to read Sil3726 Private Register" ; + reason ="failed to read Sil3x26 Private Register" ; goto fail; } reg &= ~0x1 ; err_mask =sata_pmp_write (&ap->link,PMP_GSCR_SII_POL , reg);if (err_mask) { rc = -EIO ; - reason ="failed to write Sil3726 Private Register" ; + reason ="failed to write Sil3x26 Private Register" ; goto fail; } }
@@ -383,8 +383,8 @@ static void sata_pmp_quirks(struct ata_pu16 devid =sata_pmp_gscr_devid (gscr);struct ata_link *link; -if (vendor ==0x1095 && devid ==0x3726 ) { -/* sil3726 quirks */ +if (vendor ==0x1095 && (devid ==0x3726 || devid ==0x3826 )) { +/* sil3x26 quirks */ ata_for_each_link (link, ap,EDGE ) {/* link reports offline after LPM */ link->flags |=ATA_LFLAG_NO_LPM ;
Greg Kroah-Hartman
maintainerPATCH 8/9 SCSI: zfcp: fix lock imbalance by reworking request queue locking
In reply to Greg Kroah-Hartman3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Peschke <[email protected]>
commit d79ff142624e1be080ad8d09101f7004d79c36e1 upstream.
This patch adds wait_event_interruptible_lock_irq_timeout(), which is a straight-forward descendant of wait_event_interruptible_timeout() and wait_event_interruptible_lock_irq().
The zfcp driver used to call wait_event_interruptible_timeout() in combination with some intricate and error-prone locking. Using wait_event_interruptible_lock_irq_timeout() as a replacement nicely cleans up that locking.
This rework removes a situation that resulted in a locking imbalance in zfcp_qdio_sbal_get():
BUG: workqueue leaked lock or atomic: events/1/0xffffff00/10
last function: zfcp_fc_wka_port_offline+0x0/0xa0 [zfcp]It was introduced by commit c2af7545aaff3495d9bf9a7608c52f0af86fb194 "[SCSI] zfcp: Do not wait for SBALs on stopped queue", which had a new code path related to ZFCP_STATUS_ADAPTER_QDIOUP that took an early exit without a required lock being held. The problem occured when a special, non-SCSI I/O request was being submitted in process context, when the adapter's queues had been torn down. In this case the bug surfaced when the Fibre Channel port connection for a well-known address was closed during a concurrent adapter shut-down procedure, which is a rare constellation.
This patch also fixes these warnings from the sparse tool (make C=1):
drivers/s390/scsi/zfcp_qdio.c:224:12: warning: context imbalance in
'zfcp_qdio_sbal_check' - wrong count at exitdrivers/s390/scsi/zfcp_qdio.c:244:5: warning: context imbalance in
'zfcp_qdio_sbal_get' - unexpected unlock
Last but not least, we get rid of that crappy lock-unlock-lock sequence at the beginning of the critical section.
It is okay to call zfcp_erp_adapter_reopen() with req_q_lock held.
--- drivers/s390/scsi/zfcp_qdio.c | 8 +---- include/linux/wait.h | 57 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 59 insertions(+), 6 deletions(-)
drivers/s390/scsi/zfcp_qdio.c +2 -6
@@ -199,11 +199,9 @@ int zfcp_qdio_sbals_from_sg(struct zfcp_static int zfcp_qdio_sbal_check (struct zfcp_qdio *qdio) { -spin_lock_irq (&qdio->req_q_lock);if (atomic_read (&qdio->req_q_free) || !(atomic_read (&qdio->adapter->status) &ZFCP_STATUS_ADAPTER_QDIOUP ))return 1 ; -spin_unlock_irq (&qdio->req_q_lock);return 0 ; }
@@ -221,9 +219,8 @@ int zfcp_qdio_sbal_get(struct zfcp_qdio {long ret; -spin_unlock_irq (&qdio->req_q_lock); - ret =wait_event_interruptible_timeout (qdio->req_q_wq, -zfcp_qdio_sbal_check (qdio),5 *HZ ); + ret =wait_event_interruptible_lock_irq_timeout (qdio->req_q_wq, +zfcp_qdio_sbal_check (qdio), qdio->req_q_lock,5 *HZ );if (!(atomic_read (&qdio->adapter->status) &ZFCP_STATUS_ADAPTER_QDIOUP ))return -EIO ;
@@ -237,7 +234,6 @@ int zfcp_qdio_sbal_get(struct zfcp_qdiozfcp_erp_adapter_reopen (qdio->adapter,0 ,"qdsbg_1" ); } -spin_lock_irq (&qdio->req_q_lock);return -EIO ; }
include/linux/wait.h +57 -0
63 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 9/9 SCSI: zfcp: fix schedule-inside-lock in scsi_device list loops
In reply to Greg Kroah-Hartman3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Peschke <[email protected]>
commit 924dd584b198a58aa7cb3efefd8a03326550ce8f upstream.
BUG: sleeping function called from invalid context at kernel/workqueue.c:2752 in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700 CPU: 1 Not tainted 3.9.3+ #69 Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30) <snip> Call Trace: ([<00000000001165de>] show_trace+0x106/0x154) [<00000000001166a0>] show_stack+0x74/0xf4 [<00000000006ff646>] dump_stack+0xc6/0xd4 [<000000000017f3a0>] __might_sleep+0x128/0x148 [<000000000015ece8>] flush_work+0x54/0x1f8 [<00000000001630de>] __cancel_work_timer+0xc6/0x128 [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c [<0000000000161816>] execute_in_process_context+0x96/0xa8 [<00000000004d33d8>] device_release+0x60/0xc0 [<000000000048af48>] kobject_release+0xa8/0x1c4 [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130 [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp] [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp] [<000000000016b75a>] kthread+0xf2/0xfc [<000000000070c9de>] kernel_thread_starter+0x6/0xc [<000000000070c9d8>] kernel_thread_starter+0x0/0xc
Apparently, the ref_count for some scsi_device drops down to zero, triggering device removal through execute_in_process_context(), while the lldd error recovery thread iterates through a scsi device list. Unfortunately, execute_in_process_context() decides to immediately execute that device removal function, instead of scheduling asynchronous execution, since it detects process context and thinks it is safe to do so. But almost all calls to shost_for_each_device() in our lldd are inside spin_lock_irq, even in thread context. Obviously, schedule() inside spin_lock_irq sections is a bad idea.
Change the lldd to use the proper iterator function, __shost_for_each_device(), in combination with required locking.
Occurences that need to be changed include all calls in zfcp_erp.c, since those might be executed in zfcp error recovery thread context with a lock held.
Other occurences of shost_for_each_device() in zfcp_fsf.c do not need to be changed (no process context, no surrounding locking).
The problem was introduced in Linux 2.6.37 by commit b62a8d9b45b971a67a0f8413338c230e3117dff5
"[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit".
--- drivers/s390/scsi/zfcp_erp.c | 29 ++++++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-)
drivers/s390/scsi/zfcp_erp.c +22 -7
@@ -102,10 +102,13 @@ static void zfcp_erp_action_dismiss_portif (atomic_read (&port->status) &ZFCP_STATUS_COMMON_ERP_INUSE )zfcp_erp_action_dismiss (&port->erp_action); -else -shost_for_each_device (sdev, port->adapter->scsi_host) +else { +spin_lock (port->adapter->scsi_host->host_lock); +__shost_for_each_device (sdev, port->adapter->scsi_host)if (sdev_to_zfcp (sdev)->port == port)zfcp_erp_action_dismiss_lun (sdev); +spin_unlock (port->adapter->scsi_host->host_lock); + } }static void zfcp_erp_action_dismiss_adapter (struct zfcp_adapter *adapter)
@@ -592,9 +595,11 @@ static void _zfcp_erp_lun_reopen_all(str {struct scsi_device *sdev; -shost_for_each_device (sdev, port->adapter->scsi_host) +spin_lock (port->adapter->scsi_host->host_lock); +__shost_for_each_device (sdev, port->adapter->scsi_host)if (sdev_to_zfcp (sdev)->port == port)_zfcp_erp_lun_reopen (sdev, clear, id,0 ); +spin_unlock (port->adapter->scsi_host->host_lock); }static void zfcp_erp_strategy_followup_failed (struct zfcp_erp_action *act)
@@ -1435,8 +1440,10 @@ void zfcp_erp_set_adapter_status(structatomic_set_mask (common_mask, &port->status);read_unlock_irqrestore (&adapter->port_list_lock, flags); -shost_for_each_device (sdev, adapter->scsi_host) +spin_lock_irqsave (adapter->scsi_host->host_lock, flags); +__shost_for_each_device (sdev, adapter->scsi_host)atomic_set_mask (common_mask, &sdev_to_zfcp (sdev)->status); +spin_unlock_irqrestore (adapter->scsi_host->host_lock, flags); }/**
@@ -1470,11 +1477,13 @@ void zfcp_erp_clear_adapter_status(struc }read_unlock_irqrestore (&adapter->port_list_lock, flags); -shost_for_each_device (sdev, adapter->scsi_host) { +spin_lock_irqsave (adapter->scsi_host->host_lock, flags); +__shost_for_each_device (sdev, adapter->scsi_host) {atomic_clear_mask (common_mask, &sdev_to_zfcp (sdev)->status);if (clear_counter)atomic_set (&sdev_to_zfcp (sdev)->erp_counter,0 ); } +spin_unlock_irqrestore (adapter->scsi_host->host_lock, flags); }/**
@@ -1488,16 +1497,19 @@ void zfcp_erp_set_port_status(struct zfc {struct scsi_device *sdev;u32 common_mask = mask &ZFCP_COMMON_FLAGS ; +unsigned long flags;atomic_set_mask (mask, &port->status);if (!common_mask)return ; -shost_for_each_device (sdev, port->adapter->scsi_host) +spin_lock_irqsave (port->adapter->scsi_host->host_lock, flags); +__shost_for_each_device (sdev, port->adapter->scsi_host)if (sdev_to_zfcp (sdev)->port == port)atomic_set_mask (common_mask, &sdev_to_zfcp (sdev)->status); +spin_unlock_irqrestore (port->adapter->scsi_host->host_lock, flags); }/**
@@ -1512,6 +1524,7 @@ void zfcp_erp_clear_port_status(struct zstruct scsi_device *sdev;u32 common_mask = mask &ZFCP_COMMON_FLAGS ;u32 clear_counter = mask &ZFCP_STATUS_COMMON_ERP_FAILED ; +unsigned long flags;atomic_clear_mask (mask, &port->status);
@@ -1521,13 +1534,15 @@ void zfcp_erp_clear_port_status(struct zif (clear_counter)atomic_set (&port->erp_counter,0 ); -shost_for_each_device (sdev, port->adapter->scsi_host) +spin_lock_irqsave (port->adapter->scsi_host->host_lock, flags); +__shost_for_each_device (sdev, port->adapter->scsi_host)if (sdev_to_zfcp (sdev)->port == port) {atomic_clear_mask (common_mask, &sdev_to_zfcp (sdev)->status);if (clear_counter)atomic_set (&sdev_to_zfcp (sdev)->erp_counter,0 ); } +spin_unlock_irqrestore (port->adapter->scsi_host->host_lock, flags); }/**
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.0.94 release. There are 9 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 me know.
Quoted 7 lines
Responses should be made by Thu Aug 29 01:02:44 UTC 2013. 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/v3.0/stable-review/patch-3.0.94-rc1.gzand the diffstat can be found below.
Cross build results:
total: 70 pass: 61 fail: 9 Compared to 3.0.92: total: 65 pass: 57 fail: 8
qemu tests:
ppc, x86, x86_64: pass (boot to login prompt) arm, mips, mips64: skipped
Additional build failure is due to added build. Results look good.
Guenter
Greg Kroah-Hartman
maintainerQuoted 14 lines · Guenter Roeck
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.0.94 release. There are 9 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 me know.
Quoted 7 lines
Responses should be made by Thu Aug 29 01:02:44 UTC 2013. 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/v3.0/stable-review/patch-3.0.94-rc1.gzand the diffstat can be found below.
Quoted 4 lines
Cross build results:
total: 70 pass: 61 fail: 9 Compared to 3.0.92: total: 65 pass: 57 fail: 8
Nice that our failing percentage is getting smaller :)
thanks for testing and letting me know.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.0.94 release. There are 9 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 me know.
Responses should be made by Thu Aug 29 01:02:44 UTC 2013. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.94-rc1.gzand the diffstat can be found below.
thanks,
greg k-h
-------------
3.0.94
------
3.0.94-rc1 applied cleanly to 3.0.93
Compiled and booted on the following systems:
Samsung Series 9 900X4C Intel Corei5
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
dmesgs look good. No regressions compared to the previous dmesgs for this release. dmesg emerg, crit, alert, err are clean. No regressions in warn.
Cross-compile testing: HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:
Cross-compile tests results:
alpha: defconfig passed
arm: defconfig passed
arm64: not applicable
blackfin: defconfig passed
c6x: not applicable
mips: defconfig passed
mipsel: defconfig passed
powerpc: wii_defconfig passed
sh: defconfig passed
sparc: defconfig passed
tile: tilegx_defconfig passed
-- Shuah
Signature · 4 lines
Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) [email protected] | (970) 672-0658
Greg Kroah-Hartman
maintainerQuoted 23 lines · Shuah Khan
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.0.94 release. There are 9 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 me know.
Responses should be made by Thu Aug 29 01:02:44 UTC 2013. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.94-rc1.gzand the diffstat can be found below.
thanks,
greg k-h
-------------
3.0.94
------
3.0.94-rc1 applied cleanly to 3.0.93
Quoted 8 lines
Compiled and booted on the following systems:
Samsung Series 9 900X4C Intel Corei5
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphicsdmesgs look good. No regressions compared to the previous dmesgs for this release. dmesg emerg, crit, alert, err are clean. No regressions in warn.
Thanks for testing and letting me know.
greg k-h