4.6.5-stable review
Subsystems (3)
Greg Kroah-Hartman
maintainerPATCH 180/203 ALSA: hda: add AMD Stoney PCI ID with proper driver caps
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Awais Belal <[email protected]>
commit d716fb03f76411fc7e138692e33b749cada5c094 upstream.
This allows the device to correctly show up as ATI HDMI rather than a generic one and allows the driver to use the available caps.
--- sound/pci/hda/hda_intel.c | 2 ++ 1 file changed, 2 insertions(+)
sound/pci/hda/hda_intel.c +2 -0
@@ -2269,6 +2269,8 @@ static const struct pci_device_id azx_id .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI_NS }, { PCI_DEVICE(0x1002, 0x157a), .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI_NS }, + { PCI_DEVICE(0x1002, 0x15b3), + .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI_NS }, { PCI_DEVICE(0x1002, 0x793b), .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI }, { PCI_DEVICE(0x1002, 0x7919),
Greg Kroah-Hartman
maintainerPATCH 181/203 ARM: sunxi/dt: make the CHIP inherit from allwinner,sun5i-a13
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Brezillon <[email protected]>
commit 5fc39d347267bd029fcc9099c70e2fe2d53130e9 upstream.
The sun4i-timer driver registers its sched_clock only if the machine is compatible with "allwinner,sun5i-a13", "allwinner,sun5i-a10s" or "allwinner,sun4i-a10".
Add the missing "allwinner,sun5i-a13" string to the machine compatible.
--- arch/arm/boot/dts/sun5i-r8-chip.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/sun5i-r8-chip.dts +1 -1
@@ -52,7 +52,7 @@ / { model = "NextThing C.H.I.P."; - compatible = "nextthing,chip", "allwinner,sun5i-r8"; + compatible = "nextthing,chip", "allwinner,sun5i-r8", "allwinner,sun5i-a13"; aliases { i2c0 = &i2c0;
Greg Kroah-Hartman
maintainerPATCH 182/203 ARM: dts: armada-38x: fix MBUS_ID for crypto SRAM on Armada 385 Linksys
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Petazzoni <[email protected]>
commit 929e604efa3dc0522214e0dc18984be23993e9f0 upstream.
When the support for the Marvell crypto engine was added in the Device Tree of the various Armada 385 Device Tree files in commit d716f2e837ac6 ("ARM: mvebu: define crypto SRAM ranges for all armada-38x boards"), a typo was made in the MBus window attributes for the Armada 385 Linksys board: 0x09/0x05 are used instead of 0x19/0x15. This commit fixes this typo, which makes the CESA engines operational on Armada 385 Linksys boards.
--- arch/arm/boot/dts/armada-385-linksys.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/armada-385-linksys.dtsi +2 -2
@@ -58,8 +58,8 @@ soc { ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000 MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000 - MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000 - MBUS_ID(0x09, 0x05) 0 0xf1110000 0x10000>; + MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000 + MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>; internal-regs {
Greg Kroah-Hartman
maintainerPATCH 183/203 ARM: mvebu: fix HW I/O coherency related deadlocks
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Petazzoni <[email protected]>
commit c5379ba8fccd99d5f99632c789f0393d84a57805 upstream.
Until now, our understanding for HW I/O coherency to work on the Cortex-A9 based Marvell SoC was that only the PCIe regions should be mapped strongly-ordered. However, we were still encountering some deadlocks, especially when testing the CESA crypto engine. After checking with the HW designers, it was concluded that all the MMIO registers should be mapped as strongly ordered for the HW I/O coherency mechanism to work properly.
This fixes some easy to reproduce deadlocks with the CESA crypto engine driver (dmcrypt on a sufficiently large disk partition).
--- arch/arm/mach-mvebu/coherency.c | 22 ++++++++-------------- 1 file changed, 8 insertions(+), 14 deletions(-)
arch/arm/mach-mvebu/coherency.c +8 -14
@@ -162,22 +162,16 @@ exit: }/* -* This ioremap hook is used on Armada 375/38x to ensure that PCIe -* memory areas are mapped as MT_UNCACHED instead of MT_DEVICE. This -* is needed as a workaround for a deadlock issue between the PCIe -* interface and the cache controller. +* This ioremap hook is used on Armada 375/38x to ensure that all MMIO +* areas are mapped as MT_UNCACHED instead of MT_DEVICE. This is +* needed for the HW I/O coherency mechanism to work properly without +* deadlock. */ static void __iomem * -armada_pcie_wa_ioremap_caller (phys_addr_t phys_addr,size_t size, -unsigned int mtype,void *caller) +armada_wa_ioremap_caller (phys_addr_t phys_addr,size_t size, +unsigned int mtype,void *caller) { -struct resource pcie_mem; - -mvebu_mbus_get_pcie_mem_aperture (&pcie_mem); - -if (pcie_mem.start <= phys_addr && (phys_addr + size) <= pcie_mem.end) - mtype =MT_UNCACHED ; - + mtype =MT_UNCACHED ;return __arm_ioremap_caller (phys_addr, size, mtype, caller); }
@@ -186,7 +180,7 @@ static void __init armada_375_380_coherestruct device_node *cache_dn; coherency_cpu_base =of_iomap (np,0 ); - arch_ioremap_caller = armada_pcie_wa_ioremap_caller; + arch_ioremap_caller = armada_wa_ioremap_caller;/* * We should switch the PL310 to I/O coherency mode only if
Greg Kroah-Hartman
maintainerPATCH 184/203 ovl: fix dentry leak for default_permissions
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miklos Szeredi <[email protected]>
commit a4859d75944a726533ab86d24bb5ffd1b2b7d6cc upstream.
When using the 'default_permissions' mount option, ovl_permission() on non-directories was missing a dput(alias), resulting in "BUG Dentry still in use".
--- fs/overlayfs/inode.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
fs/overlayfs/inode.c +5 -3
@@ -121,16 +121,18 @@ int ovl_permission(struct inode *inode, err =vfs_getattr (&realpath, &stat);if (err) -return err; + goto out_dput; + err = -ESTALE ;if ((stat.mode ^ inode->i_mode) &S_IFMT ) -return -ESTALE ; + goto out_dput; inode->i_mode = stat.mode; inode->i_uid = stat.uid; inode->i_gid = stat.gid; -return generic_permission (inode, mask); + err =generic_permission (inode, mask); + goto out_dput; }/* Careful in RCU walk mode */
Greg Kroah-Hartman
maintainerPATCH 185/203 ovl: get_write_access() in truncate
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miklos Szeredi <[email protected]>
commit 03bea60409328de54e4ff7ec41672e12a9cb0908 upstream.
When truncating a file we should check write access on the underlying inode. And we should do so on the lower file as well (before copy-up) for consistency.
Original patch and test case by Aihua Zhang.
- - >o >o - - test.c - - >o >o - -
#include <stdio.h>
#include <errno.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
int ret;
ret = truncate(argv[0], 4096);
if (ret != -1) {
fprintf(stderr, "truncate(argv[0]) should have failed\n");
return 1;
}
if (errno != ETXTBSY) {
perror("truncate(argv[0])");
return 1;
}
return 0;
}- - >o >o - - >o >o - - >o >o - -
--- fs/overlayfs/inode.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
fs/overlayfs/inode.c +21 -0
@@ -59,16 +59,37 @@ int ovl_setattr(struct dentry *dentry, sif (err) goto out; +if (attr->ia_valid &ATTR_SIZE ) { +struct inode *realinode =d_inode (ovl_dentry_real (dentry)); + + err = -ETXTBSY ; +if (atomic_read (&realinode->i_writecount) <0 ) + goto out_drop_write; + } + err =ovl_copy_up (dentry);if (!err) { +struct inode *winode =NULL ; + upperdentry =ovl_dentry_upper (dentry); +if (attr->ia_valid &ATTR_SIZE ) { + winode =d_inode (upperdentry); + err =get_write_access (winode); +if (err) + goto out_drop_write; + } +inode_lock (upperdentry->d_inode); err =notify_change (upperdentry, attr,NULL );if (!err)ovl_copyattr (upperdentry->d_inode, dentry->d_inode);inode_unlock (upperdentry->d_inode); + +if (winode) +put_write_access (winode); } +out_drop_write:ovl_drop_write (dentry); out:return err;
Greg Kroah-Hartman
maintainerPATCH 186/203 ovl: Copy up underlying inodes ->i_mode to overlay inode
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vivek Goyal <[email protected]>
commit 07a2daab49c549a37b5b744cbebb6e3f445f12bc upstream.
Right now when a new overlay inode is created, we initialize overlay inode's ->i_mode from underlying inode ->i_mode but we retain only file type bits (S_IFMT) and discard permission bits.
This patch changes it and retains permission bits too. This should allow overlay to do permission checks on overlay inode itself in task context.
[SzM] It also fixes clearing suid/sgid bits on write.
--- fs/overlayfs/inode.c | 3 +-- fs/overlayfs/overlayfs.h | 1 + 2 files changed, 2 insertions(+), 2 deletions(-)
fs/overlayfs/inode.c +1 -2
@@ -423,12 +423,11 @@ struct inode *ovl_new_inode(struct superif (!inode)return NULL ; - mode &=S_IFMT ; - inode->i_ino =get_next_ino (); inode->i_mode = mode; inode->i_flags |=S_NOATIME |S_NOCMTIME ; + mode &=S_IFMT ;switch (mode) {case S_IFDIR : inode->i_private = oe;
fs/overlayfs/overlayfs.h +1 -0
@@ -185,6 +185,7 @@ static inline void ovl_copyattr(struct i { to->i_uid = from->i_uid; to->i_gid = from->i_gid; + to->i_mode = from->i_mode; }/* dir.c */
Greg Kroah-Hartman
maintainerPATCH 187/203 ovl: handle ATTR_KILL*
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miklos Szeredi <[email protected]>
commit b99c2d913810e56682a538c9f2394d76fca808f8 upstream.
Before 4bacc9c9234c ("overlayfs: Make f_path...") file->f_path pointed to the underlying file, hence suid/sgid removal on write worked fine.
After that patch file->f_path pointed to the overlay file, and the file mode bits weren't copied to overlay_inode->i_mode. So the suid/sgid removal simply stopped working.
The fix is to copy the mode bits, but then ovl_setattr() needs to clear ATTR_MODE to avoid the BUG() in notify_change(). So do this first, then in the next patch copy the mode.
--- fs/overlayfs/inode.c | 3 +++ 1 file changed, 3 insertions(+)
fs/overlayfs/inode.c +3 -0
@@ -80,6 +80,9 @@ int ovl_setattr(struct dentry *dentry, s goto out_drop_write; } +if (attr->ia_valid & (ATTR_KILL_SUID |ATTR_KILL_SGID )) + attr->ia_valid &= ~ATTR_MODE ; +inode_lock (upperdentry->d_inode); err =notify_change (upperdentry, attr,NULL );if (!err)
Greg Kroah-Hartman
maintainerPATCH 188/203 ovl: verify upper dentry in ovl_remove_and_whiteout()
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maxim Patlasov <[email protected]>
commit cfc9fde0b07c3b44b570057c5f93dda59dca1c94 upstream.
The upper dentry may become stale before we call ovl_lock_rename_workdir. For example, someone could (mistakenly or maliciously) manually unlink(2) it directly from upperdir.
To ensure it is not stale, let's lookup it after ovl_lock_rename_workdir and and check if it matches the upper dentry.
Essentially, it is the same problem and similar solution as in commit 11f3710417d0 ("ovl: verify upper dentry before unlink and rename").
--- fs/overlayfs/dir.c | 56 +++++++++++++++++++++++------------------------------ 1 file changed, 25 insertions(+), 31 deletions(-)
fs/overlayfs/dir.c +25 -31
@@ -511,6 +511,7 @@ static int ovl_remove_and_whiteout(strucstruct dentry *upper;struct dentry *opaquedir =NULL ;int err; +int flags =0 ;if (WARN_ON (!workdir))return -EROFS ;
@@ -540,46 +541,39 @@ static int ovl_remove_and_whiteout(strucif (err) goto out_dput; + upper =lookup_one_len (dentry->d_name.name, upperdir, + dentry->d_name.len); + err =PTR_ERR (upper); +if (IS_ERR (upper)) + goto out_unlock; + + err = -ESTALE ; +if ((opaquedir && upper != opaquedir) || + (!opaquedir &&ovl_dentry_upper (dentry) && + upper !=ovl_dentry_upper (dentry))) { + goto out_dput_upper; + } + whiteout =ovl_whiteout (workdir, dentry); err =PTR_ERR (whiteout);if (IS_ERR (whiteout)) - goto out_unlock; + goto out_dput_upper; - upper =ovl_dentry_upper (dentry); -if (!upper) { - upper =lookup_one_len (dentry->d_name.name, upperdir, - dentry->d_name.len); - err =PTR_ERR (upper); -if (IS_ERR (upper)) - goto kill_whiteout; - - err =ovl_do_rename (wdir, whiteout, udir, upper,0 ); -dput (upper); -if (err) - goto kill_whiteout; - }else { -int flags =0 ; - -if (opaquedir) - upper = opaquedir; - err = -ESTALE ; -if (upper->d_parent != upperdir) - goto kill_whiteout; - -if (is_dir) - flags |=RENAME_EXCHANGE ; - - err =ovl_do_rename (wdir, whiteout, udir, upper, flags); -if (err) - goto kill_whiteout; +if (d_is_dir (upper)) + flags =RENAME_EXCHANGE ; + + err =ovl_do_rename (wdir, whiteout, udir, upper, flags); +if (err) + goto kill_whiteout; +if (flags) +ovl_cleanup (wdir, upper); -if (is_dir) -ovl_cleanup (wdir, upper); - }ovl_dentry_version_inc (dentry->d_parent); out_d_drop:d_drop (dentry);dput (whiteout); +out_dput_upper: +dput (upper); out_unlock:unlock_rename (workdir, upperdir); out_dput:
Greg Kroah-Hartman
maintainerPATCH 189/203 scsi: fix race between simultaneous decrements of ->host_failed
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Fang <[email protected]>
commit 72d8c36ec364c82bf1bf0c64dfa1041cfaf139f7 upstream.
sas_ata_strategy_handler() adds the works of the ata error handler to system_unbound_wq. This workqueue asynchronously runs work items, so the ata error handler will be performed concurrently on different CPUs. In this case, ->host_failed will be decreased simultaneously in scsi_eh_finish_cmd() on different CPUs, and become abnormal.
It will lead to permanently inequality between ->host_failed and ->host_busy, and scsi error handler thread won't start running. IO errors after that won't be handled.
Since all scmds must have been handled in the strategy handler, just remove the decrement in scsi_eh_finish_cmd() and zero ->host_busy after the strategy handler to fix this race.
--- Documentation/scsi/scsi_eh.txt | 8 ++++++-- drivers/ata/libata-eh.c | 2 +- drivers/scsi/scsi_error.c | 4 +++- 3 files changed, 10 insertions(+), 4 deletions(-)
Documentation/scsi/scsi_eh.txt +6 -2
@@ -263,19 +263,23 @@ scmd->allowed. 3. scmd recovered ACTION: scsi_eh_finish_cmd() is invoked to EH-finish scmd - - shost->host_failed-- - clear scmd->eh_eflags - scsi_setup_cmd_retry() - move from local eh_work_q to local eh_done_q LOCKING: none + CONCURRENCY: at most one thread per separate eh_work_q to + keep queue manipulation lockless 4. EH completes ACTION: scsi_eh_flush_done_q() retries scmds or notifies upper - layer of failure. + layer of failure. May be called concurrently but must have + a no more than one thread per separate eh_work_q to + manipulate the queue locklessly - scmd is removed from eh_done_q and scmd->eh_entry is cleared - if retry is necessary, scmd is requeued using scsi_queue_insert() - otherwise, scsi_finish_command() is invoked for scmd + - zero shost->host_failed LOCKING: queue or finish function performs appropriate locking
drivers/ata/libata-eh.c +1 -1
@@ -606,7 +606,7 @@ void ata_scsi_error(struct Scsi_Host *hoata_scsi_port_error_handler (host, ap);/* finish or retry handled scmd's and clean up */ -WARN_ON (host->host_failed || !list_empty (&eh_work_q)); +WARN_ON (!list_empty (&eh_work_q));DPRINTK ("EXIT\n" ); }
drivers/scsi/scsi_error.c +3 -1
@@ -1127,7 +1127,6 @@ static int scsi_eh_action(struct scsi_cm*/ void scsi_eh_finish_cmd (struct scsi_cmnd *scmd,struct list_head *done_q) { - scmd->device->host->host_failed--; scmd->eh_eflags =0 ;list_move_tail (&scmd->eh_entry, done_q); }
@@ -2226,6 +2225,9 @@ int scsi_error_handler(void *data)else scsi_unjam_host (shost); +/* All scmds have been handled */ + shost->host_failed =0 ; +/* * Note - if the above fails completely, the action is to take * individual devices offline and flush the queue of any
Greg Kroah-Hartman
maintainerPATCH 190/203 s390: fix test_fp_ctl inline assembly contraints
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Schwidefsky <[email protected]>
commit bcf4dd5f9ee096bd1510f838dd4750c35df4e38b upstream.
The test_fp_ctl function is used to test if a given value is a valid floating-point control. The inline assembly in test_fp_ctl uses an incorrect constraint for the 'orig_fpc' variable. If the compiler chooses the same register for 'fpc' and 'orig_fpc' the test_fp_ctl() function always returns true. This allows user space to trigger kernel oopses with invalid floating-point control values on the signal stack.
This problem has been introduced with git commit 4725c86055f5bbdcdf "s390: fix save and restore of the floating-point-control register"
--- arch/s390/include/asm/fpu/api.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/s390/include/asm/fpu/api.h +1 -1
@@ -22,7 +22,7 @@ static inline int test_fp_ctl(u32 fpc)" la %0,0\n" "1:\n" EX_TABLE (0b ,1b ) - : "=d" (rc), "=d" (orig_fpc) + : "=d" (rc), "=&d" (orig_fpc) : "d" (fpc), "0" (-EINVAL)); return rc; }
Greg Kroah-Hartman
maintainerPATCH 191/203 Revert "s390/kdump: Clear subchannel ID to signal non-CCW/SCSI IPL"
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Holzheu <[email protected]>
commit 5419447e2142d6ed68c9f5c1a28630b3a290a845 upstream.
This reverts commit 852ffd0f4e23248b47531058e531066a988434b5.
There are use cases where an intermediate boot kernel (1) uses kexec to boot the final production kernel (2). For this scenario we should provide the original boot information to the production kernel (2). Therefore clearing the boot information during kexec() should not be done.
--- arch/s390/kernel/ipl.c | 7 ------- 1 file changed, 7 deletions(-)
arch/s390/kernel/ipl.c +0 -7
@@ -2064,12 +2064,5 @@ void s390_reset_system(void) S390_lowcore.program_new_psw.addr = (unsigned long ) s390_base_pgm_handler; -/* -* Clear subchannel ID and number to signal new kernel that no CCW or -* SCSI IPL has been done (for kexec and kdump) -*/ - S390_lowcore.subchannel_id =0 ; - S390_lowcore.subchannel_nr =0 ; -do_reset_calls (); }
Greg Kroah-Hartman
maintainerPATCH 192/203 53c700: fix BUG on untagged commands
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Bottomley <[email protected]>
commit 8beb330044d0d1878c7b92290e91c0b889e92633 upstream.
The untagged command case in the 53c700 driver has been broken since host wide tags were enabled because the replaced scsi_find_tag() function had a special case for the tag value SCSI_NO_TAG to retrieve sdev->current_cmnd. The replacement function scsi_host_find_tag() has no such special case and returns NULL causing untagged commands to trigger a BUG() in the driver. Inspection shows that the 53c700 is the only driver using this SCSI_NO_TAG case, so a local fix in the driver suffices to fix this problem globally.
--- drivers/scsi/53c700.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/53c700.c +2 -2
@@ -1122,7 +1122,7 @@ process_script_interrupt(__u32 dsps, __u }else {struct scsi_cmnd *SCp; - SCp =scsi_host_find_tag (SDp->host,SCSI_NO_TAG ); + SCp = SDp->current_cmnd;if (unlikely (SCp ==NULL )) {sdev_printk (KERN_ERR , SDp,"no saved request for untagged cmd\n" );
@@ -1826,7 +1826,7 @@ NCR_700_queuecommand_lck(struct scsi_cmn slot->tag, slot); }else { slot->tag =SCSI_NO_TAG ; -/* must populate current_cmnd for scsi_host_find_tag to work */ +/* save current command for reselection */ SCp->device->current_cmnd = SCp; }/* sanity check: some of the commands generated by the mid-layer
Greg Kroah-Hartman
maintainerPATCH 193/203 Fix reconnect to not defer smb3 session reconnect long after socket reconnect
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steve French <[email protected]>
commit 4fcd1813e6404dd4420c7d12fb483f9320f0bf93 upstream.
Azure server blocks clients that open a socket and don't do anything on it. In our reconnect scenarios, we can reconnect the tcp session and detect the socket is available but we defer the negprot and SMB3 session setup and tree connect reconnection until the next i/o is requested, but this looks suspicous to some servers who expect SMB3 negprog and session setup soon after a socket is created.
In the echo thread, reconnect SMB3 sessions and tree connections that are disconnected. A later patch will replay persistent (and resilient) handle opens.
--- fs/cifs/connect.c | 4 +++- fs/cifs/smb2pdu.c | 27 +++++++++++++++++++++++++++ 2 files changed, 30 insertions(+), 1 deletion(-)
fs/cifs/connect.c +3 -1
@@ -428,7 +428,9 @@ cifs_echo_request(struct work_struct *wo* server->ops->need_neg() == true. Also, no need to ping if * we got a response recently. */ -if (!server->ops->need_neg || server->ops->need_neg (server) || + +if (server->tcpStatus == CifsNeedReconnect || + server->tcpStatus == CifsExiting || server->tcpStatus == CifsNew || (server->ops->can_echo && !server->ops->can_echo (server)) ||time_before (jiffies, server->lstrp + echo_interval -HZ )) goto requeue_echo;
fs/cifs/smb2pdu.c +27 -0
@@ -1818,6 +1818,33 @@ SMB2_echo(struct TCP_Server_Info *servercifs_dbg (FYI ,"In echo request\n" ); +if (server->tcpStatus == CifsNeedNegotiate) { +struct list_head *tmp, *tmp2; +struct cifs_ses *ses; +struct cifs_tcon *tcon; + +cifs_dbg (FYI ,"Need negotiate, reconnecting tcons\n" ); +spin_lock (&cifs_tcp_ses_lock); +list_for_each (tmp, &server->smb_ses_list) { + ses = list_entry(tmp, struct cifs_ses, smb_ses_list); +list_for_each (tmp2, &ses->tcon_list) { + tcon = list_entry(tmp2, struct cifs_tcon, + tcon_list); +/* add check for persistent handle reconnect */ +if (tcon && tcon->need_reconnect) { +spin_unlock (&cifs_tcp_ses_lock); + rc =smb2_reconnect (SMB2_ECHO , tcon); +spin_lock (&cifs_tcp_ses_lock); + } + } + } +spin_unlock (&cifs_tcp_ses_lock); + } + +/* if no session, renegotiate failed above */ +if (server->tcpStatus == CifsNeedNegotiate) +return -EIO ; + rc =small_smb2_init (SMB2_ECHO ,NULL , (void **)&req);if (rc)return rc;
Greg Kroah-Hartman
maintainerPATCH 194/203 cifs: dynamic allocation of ntlmssp blob
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jerome Marchand <[email protected]>
commit b8da344b74c822e966c6d19d6b2321efe82c5d97 upstream.
In sess_auth_rawntlmssp_authenticate(), the ntlmssp blob is allocated statically and its size is an "empirical" 5*sizeof(struct _AUTHENTICATE_MESSAGE) (320B on x86_64). I don't know where this value comes from or if it was ever appropriate, but it is currently
insufficient: the user and domain name in UTF16 could take 1kB by themselves. Because of that, build_ntlmssp_auth_blob() might corrupt memory (out-of-bounds write). The size of ntlmssp_blob in SMB2_sess_setup() is too small too (sizeof(struct _NEGOTIATE_MESSAGE)
+ 500).
This patch allocates the blob dynamically inbuild_ntlmssp_auth_blob().
--- fs/cifs/ntlmssp.h | 2 - fs/cifs/sess.c | 76 +++++++++++++++++++++++++++++------------------------- fs/cifs/smb2pdu.c | 10 +------ 3 files changed, 45 insertions(+), 43 deletions(-)
fs/cifs/ntlmssp.h +1 -1
@@ -133,6 +133,6 @@ typedef struct _AUTHENTICATE_MESSAGE {int decode_ntlmssp_challenge (char *bcc_ptr,int blob_len,struct cifs_ses *ses);void build_ntlmssp_negotiate_blob (unsigned char *pbuffer,struct cifs_ses *ses); -int build_ntlmssp_auth_blob (unsigned char *pbuffer,u16 *buflen, +int build_ntlmssp_auth_blob (unsigned char **pbuffer,u16 *buflen,struct cifs_ses *ses,const struct nls_table *nls_cp);
fs/cifs/sess.c +42 -34
160 lines not on this page · raw message
fs/cifs/smb2pdu.c +2 -8
@@ -588,7 +588,7 @@ SMB2_sess_setup(const unsigned int xid,u16 blob_length =0 ;struct key *spnego_key =NULL ;char *security_blob =NULL ; -char *ntlmssp_blob =NULL ; +unsigned char *ntlmssp_blob =NULL ;bool use_spnego = false;/* else use raw ntlmssp */ cifs_dbg (FYI ,"Session Setup\n" );
@@ -713,13 +713,7 @@ ssetup_ntlmssp_authenticate: iov[1 ].iov_len = blob_length; }else if (phase == NtLmAuthenticate) { req->hdr.SessionId = ses->Suid; - ntlmssp_blob =kzalloc (sizeof (struct _NEGOTIATE_MESSAGE ) +500 , -GFP_KERNEL ); -if (ntlmssp_blob ==NULL ) { - rc = -ENOMEM ; - goto ssetup_exit; - } - rc =build_ntlmssp_auth_blob (ntlmssp_blob, &blob_length, ses, + rc =build_ntlmssp_auth_blob (&ntlmssp_blob, &blob_length, ses, nls_cp);if (rc) { cifs_dbg(FYI, "build_ntlmssp_auth_blob failed %d\n",
Greg Kroah-Hartman
maintainerPATCH 195/203 File names with trailing period or space need special case conversion
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steve French <[email protected]>
commit 45e8a2583d97ca758a55c608f78c4cef562644d1 upstream.
POSIX allows files with trailing spaces or a trailing period but SMB3 does not, so convert these using the normal Services For Mac mapping as we do for other reserved characters such as
: < > | ? *
This is similar to what Macs do for the same problem over SMB3.
--- fs/cifs/cifs_unicode.c | 33 +++++++++++++++++++++++++++++---- fs/cifs/cifs_unicode.h | 2 ++ 2 files changed, 31 insertions(+), 4 deletions(-)
fs/cifs/cifs_unicode.c +29 -4
@@ -101,6 +101,12 @@ convert_sfm_char(const __u16 src_char, ccase SFM_SLASH : *target ='\\' ;break ; +case SFM_SPACE : + *target =' ' ; +break ; +case SFM_PERIOD : + *target ='.' ; +break ;default :return false; }
@@ -404,7 +410,7 @@ static __le16 convert_to_sfu_char(char sreturn dest_char; } -static __le16 convert_to_sfm_char (char src_char) +static __le16 convert_to_sfm_char (char src_char,bool end_of_string) {__le16 dest_char;
@@ -427,6 +433,18 @@ static __le16 convert_to_sfm_char(char scase '|' : dest_char =cpu_to_le16 (SFM_PIPE );break ; +case '.' : +if (end_of_string) + dest_char =cpu_to_le16 (SFM_PERIOD ); +else + dest_char =0 ; +break ; +case ' ' : +if (end_of_string) + dest_char =cpu_to_le16 (SFM_SPACE ); +else + dest_char =0 ; +break ;default : dest_char =0 ; }
@@ -469,9 +487,16 @@ cifsConvertToUTF16(__le16 *target, const/* see if we must remap this char */ if (map_chars ==SFU_MAP_UNI_RSVD ) dst_char =convert_to_sfu_char (src_char); -else if (map_chars ==SFM_MAP_UNI_RSVD ) - dst_char =convert_to_sfm_char (src_char); -else +else if (map_chars ==SFM_MAP_UNI_RSVD ) { +bool end_of_string; + +if (i == srclen -1 ) + end_of_string = true; +else + end_of_string = false; + + dst_char =convert_to_sfm_char (src_char, end_of_string); + }else dst_char =0 ;/* * FIXME: We can not handle remapping backslash (UNI_SLASH)
fs/cifs/cifs_unicode.h +2 -0
@@ -64,6 +64,8 @@#define SFM_LESSTHAN ((__u16) 0xF023)#define SFM_PIPE ((__u16) 0xF027)#define SFM_SLASH ((__u16) 0xF026) +#define SFM_PERIOD ((__u16) 0xF028) +#define SFM_SPACE ((__u16) 0xF029)/* * Mapping mechanism to use when one of the seven reserved characters is
Greg Kroah-Hartman
maintainerPATCH 196/203 xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Beulich <[email protected]>
commit 6f2d9d99213514360034c6d52d2c3919290b3504 upstream.
As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on both Intel and AMD systems. Doing any kind of hardware capability checks in the driver as a prerequisite was wrong anyway: With the hypervisor being in charge, all such checking should be done by it. If ACPI data gets uploaded despite some missing capability, the hypervisor is free to ignore part or all of that data.
Ditch the entire check_prereq() function, and do the only valid check (xen_initial_domain()) in the caller in its place.
--- drivers/xen/xen-acpi-processor.c | 35 +++-------------------------------- 1 file changed, 3 insertions(+), 32 deletions(-)
drivers/xen/xen-acpi-processor.c +3 -32
@@ -423,36 +423,7 @@ upload:return 0 ; } -static int __init check_prereq (void ) -{ -struct cpuinfo_x86 *c = &cpu_data (0 ); - -if (!xen_initial_domain ()) -return -ENODEV ; - -if (!acpi_gbl_FADT.smi_command) -return -ENODEV ; -if (c->x86_vendor ==X86_VENDOR_INTEL ) { -if (!cpu_has (c,X86_FEATURE_EST )) -return -ENODEV ; - -return 0 ; - } -if (c->x86_vendor ==X86_VENDOR_AMD ) { -/* Copied from powernow-k8.h, can't include ../cpufreq/powernow -* as we get compile warnings for the static functions. -*/ -#define CPUID_FREQ_VOLT_CAPABILITIES 0x80000007 -#define USE_HW_PSTATE 0x00000080 -u32 eax, ebx, ecx, edx; -cpuid (CPUID_FREQ_VOLT_CAPABILITIES , &eax, &ebx, &ecx, &edx); -if ((edx &USE_HW_PSTATE ) !=USE_HW_PSTATE ) -return -ENODEV ; -return 0 ; - } -return -ENODEV ; -}/* acpi_perf_data is a pointer to percpu data. */ static struct acpi_processor_performance __percpu *acpi_perf_data;
@@ -509,10 +480,10 @@ struct notifier_block xen_acpi_processorstatic int __init xen_acpi_processor_init (void ) {unsigned int i; -int rc =check_prereq (); +int rc; -if (rc) -return rc; +if (!xen_initial_domain ()) +return -ENODEV ; nr_acpi_bits =get_max_acpi_id () +1 ; acpi_ids_done =kcalloc (BITS_TO_LONGS (nr_acpi_bits),sizeof (unsigned long ),GFP_KERNEL );
Greg Kroah-Hartman
maintainerPATCH 197/203 tmpfs: dont undo fallocate past its last page
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anthony Romano <[email protected]>
commit b9b4bb26af017dbe930cd4df7f9b2fc3a0497bfe upstream.
When fallocate is interrupted it will undo a range that extends one byte past its range of allocated pages. This can corrupt an in-use page by zeroing out its first byte. Instead, undo using the inclusive byte range.
--- mm/shmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/shmem.c +1 -1
@@ -2238,7 +2238,7 @@ static long shmem_fallocate(struct file/* Remove the !PageUptodate pages we added */ shmem_undo_range (inode, (loff_t )start <<PAGE_SHIFT , - (loff_t )index <<PAGE_SHIFT , true); + ((loff_t )index <<PAGE_SHIFT ) -1 , true); goto undone; }
Greg Kroah-Hartman
maintainerPATCH 198/203 tmpfs: fix regression hang in fallocate undo
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hugh Dickins <[email protected]>
commit 7f556567036cb7f89aabe2f0954b08566b4efb53 upstream.
The well-spotted fallocate undo fix is good in most cases, but not when fallocate failed on the very first page. index 0 then passes lend -1 to shmem_undo_range(), and that has two bad effects: (a) that it will undo every fallocation throughout the file, unrestricted by the current range; but more importantly (b) it can cause the undo to hang, because lend -1 is treated as truncation, which makes it keep on retrying until every page has gone, but those already fully instantiated will never go away. Big thank you to xfstests generic/269 which demonstrates this.
--- mm/shmem.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
mm/shmem.c +5 -3
@@ -2236,9 +2236,11 @@ static long shmem_fallocate(struct file NULL);if (error) {/* Remove the !PageUptodate pages we added */ -shmem_undo_range (inode, - (loff_t )start <<PAGE_SHIFT , - ((loff_t )index <<PAGE_SHIFT ) -1 , true); +if (index > start) { +shmem_undo_range (inode, + (loff_t )start <<PAGE_SHIFT , + ((loff_t )index <<PAGE_SHIFT ) -1 , true); + } goto undone; }
Greg Kroah-Hartman
maintainerPATCH 199/203 crypto: rsa-pkcs1pad - fix rsa-pkcs1pad request struct
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herbert Xu <[email protected]>
commit 87dcdebd6beb54f183ae874664ba47bf071ebf95 upstream.
To allow for child request context the struct akcipher_request child_req needs to be at the end of the structure.
--- crypto/rsa-pkcs1pad.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
crypto/rsa-pkcs1pad.c +2 -2
@@ -102,10 +102,10 @@ struct pkcs1pad_inst_ctx { };struct pkcs1pad_request { -struct akcipher_request child_req; -struct scatterlist in_sg[3 ], out_sg[2 ];uint8_t *in_buf, *out_buf; + +struct akcipher_request child_req; }; static int pkcs1pad_set_pub_key(struct crypto_akcipher *tfm, const void *key,
Greg Kroah-Hartman
maintainerPATCH 200/203 crypto: qat - make qat_asym_algs.o depend on asn1 headers
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Stancek <[email protected]>
commit 81dc0365cfa7bc7c08a0e44d9ee04964df782e19 upstream.
Parallel build can sporadically fail because asn1 headers may
not be built yet by the time qat_asym_algs.o is compiled:
drivers/crypto/qat/qat_common/qat_asym_algs.c:55:32: fatal error: qat_rsapubkey-asn1.h: No such file or directory
#include "qat_rsapubkey-asn1.h"
--- drivers/crypto/qat/qat_common/Makefile | 1 + 1 file changed, 1 insertion(+)
drivers/crypto/qat/qat_common/Makefile +1 -0
@@ -2,6 +2,7 @@ $(obj)/qat_rsapubkey-asn1.o: $(obj)/qat_ $(obj)/qat_rsapubkey-asn1.h $(obj)/qat_rsaprivkey-asn1.o: $(obj)/qat_rsaprivkey-asn1.c \ $(obj)/qat_rsaprivkey-asn1.h +$(obj)/qat_asym_algs.o: $(obj)/qat_rsapubkey-asn1.h $(obj)/qat_rsaprivkey-asn1.h clean-files += qat_rsapubkey-asn1.c qat_rsapubkey-asn1.h clean-files += qat_rsaprivkey-asn1.c qat_rsaprivkey-asn1.h
Greg Kroah-Hartman
maintainerPATCH 201/203 drm/i915: Revert DisplayPort fast link training feature
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mika Kahola <[email protected]>
commit 34511dce4b35685d3988d5c8b100d11a068db5bd upstream.
It has been found out that in some HW combination the DisplayPort fast link training feature caused screen flickering. Let's revert this feature for now until we can ensure that the feature works for all platforms.
This is a manual revert of commits 5fa836a9d859 ("drm/i915: DP link training optimization") and 4e96c97742f4 ("drm/i915: eDP link training optimization").
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393
--- drivers/gpu/drm/i915/intel_dp.c | 3 --- drivers/gpu/drm/i915/intel_dp_link_training.c | 25 ++----------------------- drivers/gpu/drm/i915/intel_drv.h | 2 -- 3 files changed, 2 insertions(+), 28 deletions(-)
drivers/gpu/drm/i915/intel_dp.c +0 -3
@@ -5022,9 +5022,6 @@ intel_dp_hpd_pulse(struct intel_digital_intel_display_power_get (dev_priv, power_domain);if (long_hpd) { -/* indicate that we need to restart link training */ - intel_dp->train_set_valid = false; -if (!intel_digital_port_connected (dev_priv, intel_dig_port)) goto mst_fail;
drivers/gpu/drm/i915/intel_dp_link_training.c +2 -23
@@ -85,8 +85,7 @@ static bool intel_dp_reset_link_train(struct intel_dp *intel_dp, uint8_t dp_train_pat) { -if (!intel_dp->train_set_valid) -memset (intel_dp->train_set,0 ,sizeof (intel_dp->train_set)); + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));intel_dp_set_signal_levels (intel_dp);return intel_dp_set_link_train (intel_dp, dp_train_pat); }
@@ -161,22 +160,6 @@ intel_dp_link_training_clock_recovery(stbreak ; } -/* -* if we used previously trained voltage and pre-emphasis values -* and we don't get clock recovery, reset link training values -*/ -if (intel_dp->train_set_valid) { -DRM_DEBUG_KMS ("clock recovery not ok, reset" ); -/* clear the flag as we are not reusing train set */ - intel_dp->train_set_valid = false; -if (!intel_dp_reset_link_train (intel_dp, -DP_TRAINING_PATTERN_1 | -DP_LINK_SCRAMBLING_DISABLE )) { -DRM_ERROR ("failed to enable link training\n" ); -return ; - } -continue ; - }/* Check to see if we've tried the max voltage */ for (i =0 ; i < intel_dp->lane_count; i++)
@@ -284,7 +267,6 @@ intel_dp_link_training_channel_equalizat/* Make sure clock is still ok */ if (!drm_dp_clock_recovery_ok (link_status, intel_dp->lane_count)) { - intel_dp->train_set_valid = false;intel_dp_link_training_clock_recovery (intel_dp); intel_dp_set_link_train(intel_dp, training_pattern |
@@ -301,7 +283,6 @@ intel_dp_link_training_channel_equalizat/* Try 5 times, then try clock recovery if that fails */ if (tries >5 ) { - intel_dp->train_set_valid = false;intel_dp_link_training_clock_recovery (intel_dp); intel_dp_set_link_train(intel_dp, training_pattern |
@@ -322,10 +303,8 @@ intel_dp_link_training_channel_equalizatintel_dp_set_idle_link_train (intel_dp); -if (channel_eq) { - intel_dp->train_set_valid = true; +if (channel_eq)DRM_DEBUG_KMS ("Channel EQ done. DP Training successful\n" ); - } }void intel_dp_stop_link_train (struct intel_dp *intel_dp)
drivers/gpu/drm/i915/intel_drv.h +0 -2
@@ -811,8 +811,6 @@ struct intel_dp {/* This is called before a link training is starterd */ void (*prepare_link_retrain)(struct intel_dp *intel_dp); -bool train_set_valid; -/* Displayport compliance testing */ unsigned long compliance_test_type;unsigned long compliance_test_data;
Greg Kroah-Hartman
maintainerPATCH 202/203 ovl: Do d_type check only if work dir creation was successful
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vivek Goyal <[email protected]>
commit 21765194cecf2e4514ad75244df459f188140a0f upstream.
d_type check requires successful creation of workdir as iterates through work dir and expects work dir to be present in it. If that's not the case, this check will always return d_type not supported even if underlying filesystem might be supporting it.
So don't do this check if work dir creation failed in previous step.
--- fs/overlayfs/super.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-)
fs/overlayfs/super.c +11 -8
@@ -1064,16 +1064,19 @@ static int ovl_fill_super(struct super_b/* * Upper should support d_type, else whiteouts are visible. * Given workdir and upper are on same fs, we can do -* iterate_dir() on workdir. +* iterate_dir() on workdir. This check requires successful +* creation of workdir in previous step. */ - err =ovl_check_d_type_supported (&workpath); -if (err <0 ) - goto out_put_workdir; +if (ufs->workdir) { + err =ovl_check_d_type_supported (&workpath); +if (err <0 ) + goto out_put_workdir; -if (!err) { -pr_err ("overlayfs: upper fs needs to support d_type.\n" ); - err = -EINVAL ; - goto out_put_workdir; +if (!err) { +pr_err ("overlayfs: upper fs needs to support d_type.\n" ); + err = -EINVAL ; + goto out_put_workdir; + } } }
Greg Kroah-Hartman
maintainerPATCH 203/203 ovl: warn instead of error if d_type is not supported
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vivek Goyal <[email protected]>
commit e7c0b5991dd1be7b6f6dc2b54a15a0f47b64b007 upstream.
overlay needs underlying fs to support d_type. Recently I put in a patch in to detect this condition and started failing mount if underlying fs did not support d_type.
But this breaks existing configurations over kernel upgrade. Those who are running docker (partially broken configuration) with xfs not supporting d_type, are surprised that after kernel upgrade docker does not run anymore.
https://github.com/docker/docker/issues/22937#issuecomment-229881315
So instead of erroring out, detect broken configuration and warn about it. This should allow existing docker setups to continue working after kernel upgrade.
--- fs/overlayfs/super.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
fs/overlayfs/super.c +7 -5
@@ -1072,11 +1072,13 @@ static int ovl_fill_super(struct super_bif (err <0 ) goto out_put_workdir; -if (!err) { -pr_err ("overlayfs: upper fs needs to support d_type.\n" ); - err = -EINVAL ; - goto out_put_workdir; - } +/* +* We allowed this configuration and don't want to +* break users over kernel upgrade. So warn instead +* of erroring out. +*/ +if (!err) +pr_warn ("overlayfs: upper fs needs to support d_type.\n" ); } }
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.6.5 release. There are 203 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 9 lines
Responses should be made by Wed Jul 27 20:33:38 UTC 2016. 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/v4.x/stable-review/patch-4.6.5-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.6.y
and the diffstat can be found below.
Compiled and booted on my test system. No dmesg regressions,
thanks,
-- Shuah
Greg Kroah-Hartman
maintainerQuoted 9 lines · Shuah Khan
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.6.5 release. There are 203 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 Wed Jul 27 20:33:38 UTC 2016. Anything received after that time might be too late.
Quoted 7 lines
Quoted 6 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.6.5-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.6.y
and the diffstat can be found below.Compiled and booted on my test system. No dmesg regressions,
Great, thanks for testing all of these and letting me know.
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.6.5 release. There are 203 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 Wed Jul 27 20:33:38 UTC 2016. Anything received after that time might be too late.
Build results:
total: 148 pass: 146 fail: 2
Failed builds:
unicore32:defconfig
unicore32:allnoconfig
Qemu test results:
total: 107 pass: 107 fail: 0
unicore32 is still not fixed in mainline.
Details are available at http://kerneltests.org/builders.
Guenter
Greg Kroah-Hartman
maintainerQuoted 12 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.6.5 release. There are 203 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 Wed Jul 27 20:33:38 UTC 2016. Anything received after that time might be too late.
Build results:
total: 148 pass: 146 fail: 2
Quoted 8 lines
Failed builds:
unicore32:defconfig
unicore32:allnoconfigQemu test results:
total: 107 pass: 107 fail: 0unicore32 is still not fixed in mainline.
Does no one care about it?
Anyway, thanks for all of the testing results, much appreciated.
greg k-h
Quoted 17 lines · Greg Kroah-Hartman
Quoted 16 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.6.5 release. There are 203 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 Wed Jul 27 20:33:38 UTC 2016. Anything received after that time might be too late.
Build results:
total: 148 pass: 146 fail: 2Failed builds:
unicore32:defconfig
unicore32:allnoconfig
Quoted 7 lines
Quoted 4 lines
Qemu test results:
total: 107 pass: 107 fail: 0unicore32 is still not fixed in mainline.
Does no one care about it?
Good question. The fix has been in -next for a while.
Guenter
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Greg Kroah-Hartman
maintainerQuoted 26 lines · Kevin Hilman
Quoted 12 lines · kernelci.org bot
stable-rc boot: 670 boots: 4 failed, 662 passed with 3 offline, 1 conflict (v4.6.4-204-g02256e5f7d73)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.6.4-204-g02256e5f7d73/
Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.6.4-204-g02256e5f7d73/Tree: stable-rc
Branch: local/linux-4.6.y
Git Describe: v4.6.4-204-g02256e5f7d73
Git Commit:02256e5f7d734c5aa48de4310ca72f1887aea3d4
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 106 unique boards, 25 SoC families, 36 builds out of 140Quoted 9 lines
Boot Failures Detected: https://kernelci.org/boot/?v4.6.4-204-g02256e5f7d73&fail
arm64:
defconfig:
apm-mustang-kvm-guest: 1 failed lab
apm-mustang-kvm-uefi-guest: 1 failed lab
juno-kvm-uefi-guest: 1 failed labCan be ignored: ongoing KVM issues with qemu on the rootfs here.
Quoted 8 lines
Quoted 4 lines
arm:
multi_v7_defconfig+CONFIG_EFI=y:
am335x-bone: 1 failed labAfter retry: PASS
I re-ran this one a few times and it's OK, not sure what happend.
Thanks for letting me know.
greg k-h