4.5.1-stable review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 154/238 xtensa: clear all DBREAKC registers on start
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Max Filippov <[email protected]>
commit 7de7ac785ae18a2cdc78d7560f48e3213d9ea0ab upstream.
There are XCHAL_NUM_DBREAK registers, clear them all.
This also fixes cryptic assembler error message with binutils 2.25 when XCHAL_NUM_DBREAK is 0:
as: out of memory allocating 18446744073709551575 bytes after a total of 495616 bytes
--- arch/xtensa/kernel/head.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/xtensa/kernel/head.S +1 -1
@@ -128,7 +128,7 @@ ENTRY(_startup) wsr a0, icountlevel .set _index, 0 - .rept XCHAL_NUM_DBREAK - 1 + .rept XCHAL_NUM_DBREAK wsr a0, SREG_DBREAKC + _index .set _index, _index + 1 .endr
Greg Kroah-Hartman
maintainerPATCH 155/238 ARC: [plat-axs10x] add Ethernet PHY description in .dts
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Brodkin <[email protected]>
commit 667a490bdb6e27db0887d2ca515b907d6aa87118 upstream.
Commit e34d65696d2e ("stmmac: create of compatible mdio bus for stmmac driver") broke DW GMAC functionality on ARC AXS10x boards:
That's what happens on eth0 up:
--------------------------->8------------------------
| libphy: PHY stmmac-0:ffffffff not found | eth0: Could not attach to PHY | stmmac_open: Cannot attach to PHY (error: -19)
--------------------------->8------------------------
Simplest solution is to add PHY description in board's .dts. And so we do here.
--- arch/arc/boot/dts/axs10x_mb.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+)
arch/arc/boot/dts/axs10x_mb.dtsi +8 -0
@@ -47,6 +47,14 @@ clocks = <&apbclk>; clock-names = "stmmaceth"; max-speed = <100>; + mdio0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "snps,dwmac-mdio"; + phy1: ethernet-phy@1 { + reg = <1>; + }; + }; }; ehci@0x40000 {
Greg Kroah-Hartman
maintainerPATCH 156/238 ARC: [BE] readl()/writel() to work in Big Endian CPU configuration
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lada Trimasova <[email protected]>
commit f778cc65717687a3d3f26dd21bef62cd059f1b8b upstream.
read{l,w}() write{l,w}() primitives should use le{16,32}_to_cpu() and cpu_to_le{16,32}() respectively to ensure device registers are read correctly in Big Endian CPU configuration.
Per Arnd Bergmann
| Most drivers using readl() or readl_relaxed() expect those to perform byte | swaps on big-endian architectures, as the registers tend to be fixed endian
This was needed for getting UART to work correctly on a Big Endian ARC.
The ARC accessors originally were fine, and the bug got introduced inadventently by commit b8a033023994 ("ARCv2: barriers")
--- arch/arc/include/asm/io.h | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)
arch/arc/include/asm/io.h +13 -5
@@ -129,15 +129,23 @@ static inline void __raw_writel(u32 w, v#define writel (v,c) ({ __iowmb(); writel_relaxed(v,c); })/* -* Relaxed API for drivers which can handle any ordering themselves +* Relaxed API for drivers which can handle barrier ordering themselves +* +* Also these are defined to perform little endian accesses. +* To provide the typical device register semantics of fixed endian, +* swap the byte order for Big Endian +* +* http://lkml.kernel.org/r/[email protected] */ #define readb_relaxed (c) __raw_readb(c) -#define readw_relaxed (c) __raw_readw(c) -#define readl_relaxed (c) __raw_readl(c) +#define readw_relaxed (c) ({ u16 __r = le16_to_cpu((__force __le16) \ + __raw_readw(c)); __r; }) +#define readl_relaxed (c) ({ u32 __r = le32_to_cpu((__force __le32) \ + __raw_readl(c)); __r; })#define writeb_relaxed (v,c) __raw_writeb(v,c) -#define writew_relaxed (v,c) __raw_writew(v,c) -#define writel_relaxed (v,c) __raw_writel(v,c) +#define writew_relaxed (v,c) __raw_writew((__force u16) cpu_to_le16(v),c) +#define writel_relaxed (v,c) __raw_writel((__force u32) cpu_to_le32(v),c)#include <asm-generic/io.h>
Greg Kroah-Hartman
maintainerPATCH 157/238 ARC: bitops: Remove non relevant comments
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vineet Gupta <[email protected]>
commit 2a41b6dc28dc71c1a3f1622612a26edc58f7561e upstream.
commit 80f420842ff42 removed the ARC bitops microoptimization but failed to prune the comments to same effect
--- arch/arc/include/asm/bitops.h | 15 --------------- 1 file changed, 15 deletions(-)
arch/arc/include/asm/bitops.h +0 -15
@@ -35,21 +35,6 @@ static inline void op##_bit(unsigned lon \ m += nr >>5 ; \ \ -/* \ -* ARC ISA micro-optimization: \ -* \ -* Instructions dealing with bitpos only consider lower 5 bits \ -* e.g (x << 33) is handled like (x << 1) by ASL instruction \ -* (mem pointer still needs adjustment to point to next word) \ -* \ -* Hence the masking to clamp @nr arg can be elided in general. \ -* \ -* However if @nr is a constant (above assumed in a register), \ -* and greater than 31, gcc can optimize away (x << 33) to 0, \ -* as overflow, given the 32-bit ISA. Thus masking needs to be \ -* done for const @nr, but no code is generated due to gcc \ -* const prop. \ -*/ \ nr &=0x1f ; \ \ __asm__ __volatile__( \
Greg Kroah-Hartman
maintainerPATCH 158/238 quota: Fix possible GPF due to uninitialised pointers
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikolay Borisov <[email protected]>
commit ab73ef46398e2c0159f3a71de834586422d2a44a upstream.
When dqget() in __dquot_initialize() fails e.g. due to IO error, __dquot_initialize() will pass an array of uninitialized pointers to dqput_all() and thus can lead to deference of random data. Fix the problem by properly initializing the array.
--- fs/quota/dquot.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/quota/dquot.c +1 -2
@@ -1398,7 +1398,7 @@ static int dquot_active(const struct inostatic int __dquot_initialize (struct inode *inode,int type) {int cnt, init_needed =0 ; -struct dquot **dquots, *got[MAXQUOTAS ]; +struct dquot **dquots, *got[MAXQUOTAS ] = {};struct super_block *sb = inode->i_sb;qsize_t rsv;int ret =0 ;
@@ -1415,7 +1415,6 @@ static int __dquot_initialize(struct inoint rc;struct dquot *dquot; - got[cnt] =NULL ;if (type !=-1 && cnt != type)continue ;/*
Greg Kroah-Hartman
maintainerPATCH 159/238 xfs: fix two memory leaks in xfs_attr_list.c error paths
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mateusz Guzik <[email protected]>
commit 2e83b79b2d6c78bf1b4aa227938a214dcbddc83f upstream.
This plugs 2 trivial leaks in xfs_attr_shortform_list and xfs_attr3_leaf_list_int.
--- fs/xfs/xfs_attr_list.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-)
fs/xfs/xfs_attr_list.c +10 -9
@@ -202,8 +202,10 @@ xfs_attr_shortform_list(xfs_attr_list_co sbp->namelen, sbp->valuelen, &sbp->name[sbp->namelen]); -if (error) +if (error) { +kmem_free (sbuf);return error; + }if (context->seen_enough)break ; cursor->offset++;
@@ -454,14 +456,13 @@ xfs_attr3_leaf_list_int( args.rmtblkcnt =xfs_attr3_rmt_blocks ( args.dp->i_mount, valuelen); retval =xfs_attr_rmtval_get (&args); -if (retval) -return retval; - retval = context->put_listent (context, - entry->flags, - name_rmt->name, - (int )name_rmt->namelen, - valuelen, - args.value); +if (!retval) + retval = context->put_listent (context, + entry->flags, + name_rmt->name, + (int )name_rmt->namelen, + valuelen, + args.value);kmem_free (args.value); }else { retval = context->put_listent(context,
Greg Kroah-Hartman
maintainerPATCH 160/238 raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nate Dailey <[email protected]>
commit ccfc7bf1f09d6190ef86693ddc761d5fe3fa47cb upstream.
If raid1d is handling a mix of read and write errors, handle_read_error's call to freeze_array can get stuck.
This can happen because, though the bio_end_io_list is initially drained, writes can be added to it via handle_write_finished as the retry_list is processed. These writes contribute to nr_pending but are not included in nr_queued.
If a later entry on the retry_list triggers a call to handle_read_error, freeze array hangs waiting for nr_pending == nr_queued+extra. The writes on the bio_end_io_list aren't included in nr_queued so the condition will never be satisfied.
To prevent the hang, include bio_end_io_list writes in nr_queued.
There's probably a better way to handle decrementing nr_queued, but this seemed like the safest way to avoid breaking surrounding code.
I'm happy to supply the script I used to repro this hang.
--- drivers/md/raid1.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/md/raid1.c +5 -2
@@ -2274,6 +2274,7 @@ static void handle_write_finished(structif (fail) {spin_lock_irq (&conf->device_lock);list_add (&r1_bio->retry_list, &conf->bio_end_io_list); + conf->nr_queued++;spin_unlock_irq (&conf->device_lock);md_wakeup_thread (conf->mddev->thread); }else {
@@ -2391,8 +2392,10 @@ static void raid1d(struct md_thread *thrLIST_HEAD (tmp);spin_lock_irqsave (&conf->device_lock, flags);if (!test_bit (MD_CHANGE_PENDING , &mddev->flags)) { -list_add (&tmp, &conf->bio_end_io_list); -list_del_init (&conf->bio_end_io_list); +while (!list_empty (&conf->bio_end_io_list)) { +list_move (conf->bio_end_io_list.prev, &tmp); + conf->nr_queued--; + } }spin_unlock_irqrestore (&conf->device_lock, flags);while (!list_empty (&tmp)) {
Greg Kroah-Hartman
maintainerPATCH 161/238 md/raid5: Compare apples to apples (or sectors to sectors)
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jes Sorensen <[email protected]>
commit e7597e69dec59b65c5525db1626b9d34afdfa678 upstream.
'max_discard_sectors' is in sectors, while 'stripe' is in bytes.
This fixes the problem where DISCARD would get disabled on some larger RAID5 configurations (6 or more drives in my testing), while it worked as expected with smaller configurations.
--- drivers/md/raid5.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/md/raid5.c +2 -2
@@ -7014,8 +7014,8 @@ static int raid5_run(struct mddev *mddev }if (discard_supported && - mddev->queue->limits.max_discard_sectors >= stripe && - mddev->queue->limits.discard_granularity >= stripe) + mddev->queue->limits.max_discard_sectors >= (stripe >>9 ) && + mddev->queue->limits.discard_granularity >= stripe)queue_flag_set_unlocked (QUEUE_FLAG_DISCARD , mddev->queue);else
Greg Kroah-Hartman
maintainerPATCH 162/238 RAID5: check_reshape() shouldnt call mddev_suspend
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shaohua Li <[email protected]>
commit 27a353c026a879a1001e5eac4bda75b16262c44a upstream.
check_reshape() is called from raid5d thread. raid5d thread shouldn't call mddev_suspend(), because mddev_suspend() waits for all IO finish but IO is handled in raid5d thread, we could easily deadlock here.
This issue is introduced by
738a273 ("md/raid5: fix allocation of 'scribble' array.")
--- drivers/md/raid5.c | 18 ++++++++++++++++++ drivers/md/raid5.h | 2 ++ 2 files changed, 20 insertions(+)
drivers/md/raid5.c +18 -0
@@ -2089,6 +2089,14 @@ static int resize_chunks(struct r5conf *unsigned long cpu;int err =0 ; +/* +* Never shrink. And mddev_suspend() could deadlock if this is called +* from raid5d. In that case, scribble_disks and scribble_sectors +* should equal to new_disks and new_sectors +*/ +if (conf->scribble_disks >= new_disks && + conf->scribble_sectors >= new_sectors) +return 0 ;mddev_suspend (conf->mddev);get_online_cpus ();for_each_present_cpu (cpu) {
@@ -2110,6 +2118,10 @@ static int resize_chunks(struct r5conf * }put_online_cpus ();mddev_resume (conf->mddev); +if (!err) { + conf->scribble_disks = new_disks; + conf->scribble_sectors = new_sectors; + }return err; }
@@ -6413,6 +6425,12 @@ static int raid5_alloc_percpu(struct r5c }put_online_cpus (); +if (!err) { + conf->scribble_disks =max (conf->raid_disks, + conf->previous_raid_disks); + conf->scribble_sectors =max (conf->chunk_sectors, + conf->prev_chunk_sectors); + }return err; }
drivers/md/raid5.h +2 -0
@@ -510,6 +510,8 @@ struct r5conf {* conversions */ }__percpu *percpu; +int scribble_disks; +int scribble_sectors;#ifdef CONFIG_HOTPLUG_CPU struct notifier_block cpu_notify;#endif
Greg Kroah-Hartman
maintainerPATCH 163/238 RAID5: revert e9e4c377e2f563 to fix a livelock
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shaohua Li <[email protected]>
commit 6ab2a4b806ae21b6c3e47c5ff1285ec06d505325 upstream.
Revert commite9e4c377e2f563(md/raid5: per hash value and exclusive wait_for_stripe)
The problem is raid5_get_active_stripe waits on conf->wait_for_stripe[hash]. Assume hash is 0. My test release stripes in this order:
- release all stripes with hash 0
- raid5_get_active_stripe still sleeps since active_stripes > max_nr_stripes * 3 / 4
- release all stripes with hash other than 0. active_stripes becomes 0
- raid5_get_active_stripe still sleeps, since nobody wakes up wait_for_stripe[0]
The system live locks. The problem is active_stripes isn't a per-hash count. Revert the patch makes the live lock go away.
--- drivers/md/raid5.c | 27 ++++++++------------------- drivers/md/raid5.h | 2 +- 2 files changed, 9 insertions(+), 20 deletions(-)
drivers/md/raid5.c +8 -19
@@ -340,8 +340,7 @@ static void release_inactive_stripe_list int hash) {int size; -unsigned long do_wakeup =0 ; -int i =0 ; +bool do_wakeup = false;unsigned long flags;if (hash ==NR_STRIPE_HASH_LOCKS ) {
@@ -362,19 +361,15 @@ static void release_inactive_stripe_list !list_empty(list))atomic_dec (&conf->empty_inactive_list_nr);list_splice_tail_init (list, conf->inactive_list + hash); - do_wakeup |=1 << hash; + do_wakeup = true;spin_unlock_irqrestore (conf->hash_locks + hash, flags); } size--; hash--; } -for (i =0 ; i <NR_STRIPE_HASH_LOCKS ; i++) { -if (do_wakeup & (1 << i)) -wake_up (&conf->wait_for_stripe[i]); - } -if (do_wakeup) { +wake_up (&conf->wait_for_stripe);if (atomic_read (&conf->active_stripes) ==0 )wake_up (&conf->wait_for_quiescent);if (conf->retry_read_aligned)
@@ -687,15 +682,14 @@ raid5_get_active_stripe(struct r5conf *cif (!sh) {set_bit (R5_INACTIVE_BLOCKED , &conf->cache_state); -wait_event_exclusive_cmd ( - conf->wait_for_stripe[hash], +wait_event_lock_irq ( + conf->wait_for_stripe, !list_empty (conf->inactive_list + hash) && (atomic_read (&conf->active_stripes) < (conf->max_nr_stripes *3 /4 ) || !test_bit (R5_INACTIVE_BLOCKED , &conf->cache_state)), -spin_unlock_irq (conf->hash_locks + hash), -spin_lock_irq (conf->hash_locks + hash)); + *(conf->hash_locks + hash));clear_bit (R5_INACTIVE_BLOCKED , &conf->cache_state); }else {
@@ -720,9 +714,6 @@ raid5_get_active_stripe(struct r5conf *c } }while (sh ==NULL ); -if (!list_empty (conf->inactive_list + hash)) -wake_up (&conf->wait_for_stripe[hash]); -spin_unlock_irq (conf->hash_locks + hash);return sh; }
@@ -2202,7 +2193,7 @@ static int resize_stripes(struct r5conf cnt =0 ;list_for_each_entry (nsh, &newstripes, lru) {lock_device_hash_lock (conf, hash); -wait_event_exclusive_cmd (conf->wait_for_stripe[hash], +wait_event_cmd (conf->wait_for_stripe, !list_empty (conf->inactive_list + hash),unlock_device_hash_lock (conf, hash),lock_device_hash_lock (conf, hash));
@@ -6521,9 +6512,7 @@ static struct r5conf *setup_conf(structseqcount_init (&conf->gen_lock);mutex_init (&conf->cache_size_mutex);init_waitqueue_head (&conf->wait_for_quiescent); -for (i =0 ; i <NR_STRIPE_HASH_LOCKS ; i++) { -init_waitqueue_head (&conf->wait_for_stripe[i]); - } +init_waitqueue_head (&conf->wait_for_stripe);init_waitqueue_head (&conf->wait_for_overlap);INIT_LIST_HEAD (&conf->handle_list);INIT_LIST_HEAD (&conf->hold_list);
drivers/md/raid5.h +1 -1
@@ -524,7 +524,7 @@ struct r5conf {atomic_t empty_inactive_list_nr;struct llist_head released_stripes;wait_queue_head_t wait_for_quiescent; -wait_queue_head_t wait_for_stripe[NR_STRIPE_HASH_LOCKS ]; +wait_queue_head_t wait_for_stripe;wait_queue_head_t wait_for_overlap;unsigned long cache_state;#define R5_INACTIVE_BLOCKED 1/* release of inactive stripes blocked,
Greg Kroah-Hartman
maintainerPATCH 164/238 raid10: include bio_end_io_list in nr_queued to prevent freeze_array hang
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shaohua Li <[email protected]>
commit 23ddba80ebe836476bb2fa1f5ef305dd1c63dc0b upstream.
This is the raid10 counterpart of the bug fixed by Nate (raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang)
--- drivers/md/raid10.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/md/raid10.c +5 -2
@@ -2664,6 +2664,7 @@ static void handle_write_completed(strucif (fail) {spin_lock_irq (&conf->device_lock);list_add (&r10_bio->retry_list, &conf->bio_end_io_list); + conf->nr_queued++;spin_unlock_irq (&conf->device_lock);md_wakeup_thread (conf->mddev->thread); }else {
@@ -2691,8 +2692,10 @@ static void raid10d(struct md_thread *thLIST_HEAD (tmp);spin_lock_irqsave (&conf->device_lock, flags);if (!test_bit (MD_CHANGE_PENDING , &mddev->flags)) { -list_add (&tmp, &conf->bio_end_io_list); -list_del_init (&conf->bio_end_io_list); +while (!list_empty (&conf->bio_end_io_list)) { +list_move (conf->bio_end_io_list.prev, &tmp); + conf->nr_queued--; + } }spin_unlock_irqrestore (&conf->device_lock, flags);while (!list_empty (&tmp)) {
Greg Kroah-Hartman
maintainerPATCH 165/238 md/raid5: preserve STRIPE_PREREAD_ACTIVE in break_stripe_batch_list
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit 550da24f8d62fe81f3c13e3ec27602d6e44d43dc upstream.
break_stripe_batch_list breaks up a batch and copies some flags from the batch head to the members, preserving others.
It doesn't preserve or copy STRIPE_PREREAD_ACTIVE. This is not normally a problem as STRIPE_PREREAD_ACTIVE is cleared when a stripe_head is added to a batch, and is not set on stripe_heads already in a batch.
However there is no locking to ensure one thread doesn't set the flag after it has just been cleared in another. This does occasionally happen.
md/raid5 maintains a count of the number of stripe_heads with STRIPE_PREREAD_ACTIVE set: conf->preread_active_stripes. When break_stripe_batch_list clears STRIPE_PREREAD_ACTIVE inadvertently this could becomes incorrect and will never again return to zero.
md/raid5 delays the handling of some stripe_heads until preread_active_stripes becomes zero. So when the above mention race happens, those stripe_heads become blocked and never progress, resulting is write to the array handing.
So: change break_stripe_batch_list to preserve STRIPE_PREREAD_ACTIVE in the members of a batch.
URL: https://bugzilla.kernel.org/show_bug.cgi?id=108741
URL: https://bugzilla.redhat.com/show_bug.cgi?id=1258153
URL: http://thread.gmane.org/[email protected]
--- drivers/md/raid5.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/raid5.c +1 -1
@@ -4239,7 +4239,6 @@ static void break_stripe_batch_list(stru WARN_ON_ONCE(sh->state & ((1 << STRIPE_ACTIVE) | (1 << STRIPE_SYNCING) | (1 << STRIPE_REPLACED) | - (1 << STRIPE_PREREAD_ACTIVE) | (1 << STRIPE_DELAYED) | (1 << STRIPE_BIT_DELAY) | (1 << STRIPE_FULL_WRITE) |
@@ -4254,6 +4253,7 @@ static void break_stripe_batch_list(stru (1 << STRIPE_REPLACED)));set_mask_bits (&sh->state, ~(STRIPE_EXPAND_SYNC_FLAGS | + (1 <<STRIPE_PREREAD_ACTIVE ) | (1 <<STRIPE_DEGRADED )), head_sh->state & (1 <<STRIPE_INSYNC ));
Greg Kroah-Hartman
maintainerPATCH 166/238 md: multipath: dont hardcopy bio in .make_request path
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ming Lei <[email protected]>
commit fafcde3ac1a418688a734365203a12483b83907a upstream.
Inside multipath_make_request(), multipath maps the incoming bio into low level device's bio, but it is totally wrong to copy the bio into mapped bio via '*mapped_bio = *bio'. For example, .__bi_remaining is kept in the copy, especially if the incoming bio is chained to via bio splitting, so .bi_end_io can't be called for the mapped bio at all in the completing path in this kind of situation.
This patch fixes the issue by using clone style.
--- drivers/md/multipath.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/md/multipath.c +3 -1
@@ -129,7 +129,9 @@ static void multipath_make_request(struc } multipath = conf->multipaths + mp_bh->path; - mp_bh->bio = *bio; +bio_init (&mp_bh->bio); +__bio_clone_fast (&mp_bh->bio, bio); + mp_bh->bio.bi_iter.bi_sector += multipath->rdev->data_offset; mp_bh->bio.bi_bdev = multipath->rdev->bdev; mp_bh->bio.bi_rw |=REQ_FAILFAST_TRANSPORT ;
Greg Kroah-Hartman
maintainerPATCH 167/238 fuse: do not use iocb after it may have been freed
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Robert Doebbelin <[email protected]>
commit 7cabc61e01a0a8b663bd2b4c982aa53048218734 upstream.
There's a race in fuse_direct_IO(), whereby is_sync_kiocb() is called on an iocb that could have been freed if async io has already completed. The fix in this case is simple and obvious: cache the result before starting io.
It was discovered by KASan:
kernel: ==================================================================
kernel: BUG: KASan: use after free in fuse_direct_IO+0xb1a/0xcc0 at addr ffff88036c414390
--- fs/fuse/file.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
fs/fuse/file.c +4 -3
@@ -2843,6 +2843,7 @@ fuse_direct_IO(struct kiocb *iocb, strucloff_t i_size;size_t count =iov_iter_count (iter);struct fuse_io_priv *io; +bool is_sync =is_sync_kiocb (iocb); pos = offset; inode = file->f_mapping->host;
@@ -2882,11 +2883,11 @@ fuse_direct_IO(struct kiocb *iocb, struc* to wait on real async I/O requests, so we must submit this request * synchronously. */ -if (!is_sync_kiocb (iocb) && (offset + count > i_size) && +if (!is_sync && (offset + count > i_size) &&iov_iter_rw (iter) ==WRITE ) io->async = false; -if (io->async &&is_sync_kiocb (iocb)) +if (io->async && is_sync) io->done = &wait;if (iov_iter_rw (iter) ==WRITE ) {
@@ -2900,7 +2901,7 @@ fuse_direct_IO(struct kiocb *iocb, strucfuse_aio_complete (io, ret <0 ? ret :0 ,-1 );/* we have a non-extending, async request, so return */ -if (!is_sync_kiocb (iocb)) +if (!is_sync)return -EIOCBQUEUED ;wait_for_completion (&wait);
Greg Kroah-Hartman
maintainerPATCH 168/238 fuse: Add reference counting for fuse_io_priv
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Seth Forshee <[email protected]>
commit 744742d692e37ad5c20630e57d526c8f2e2fe3c9 upstream.
The 'reqs' member of fuse_io_priv serves two purposes. First is to track the number of oustanding async requests to the server and to signal that the io request is completed. The second is to be a reference count on the structure to know when it can be freed.
For sync io requests these purposes can be at odds. fuse_direct_IO() wants to block until the request is done, and since the signal is sent when 'reqs' reaches 0 it cannot keep a reference to the object. Yet it needs to use the object after the userspace server has completed processing requests. This leads to some handshaking and special casing that it needlessly complicated and responsible for at least one race condition.
It's much cleaner and safer to maintain a separate reference count for the object lifecycle and to let 'reqs' just be a count of outstanding requests to the userspace server. Then we can know for sure when it is safe to free the object without any handshaking or special cases.
The catch here is that most of the time these objects are stack allocated and should not be freed. Initializing these objects with a single reference that is never released prevents accidental attempts to free the objects.
--- fs/fuse/cuse.c | 4 ++-- fs/fuse/file.c | 28 +++++++++++++++++++++------- fs/fuse/fuse_i.h | 9 +++++++++ 3 files changed, 32 insertions(+), 9 deletions(-)
fs/fuse/cuse.c +2 -2
@@ -90,7 +90,7 @@ static struct list_head *cuse_conntbl_hestatic ssize_t cuse_read_iter (struct kiocb *kiocb,struct iov_iter *to) { -struct fuse_io_priv io = { .async =0 , .file = kiocb->ki_filp }; +struct fuse_io_priv io =FUSE_IO_PRIV_SYNC (kiocb->ki_filp);loff_t pos =0 ;return fuse_direct_io (&io, to, &pos,FUSE_DIO_CUSE );
@@ -98,7 +98,7 @@ static ssize_t cuse_read_iter(struct kiostatic ssize_t cuse_write_iter (struct kiocb *kiocb,struct iov_iter *from) { -struct fuse_io_priv io = { .async =0 , .file = kiocb->ki_filp }; +struct fuse_io_priv io =FUSE_IO_PRIV_SYNC (kiocb->ki_filp);loff_t pos =0 ;/* * No locking or generic_write_checks(), the server is
fs/fuse/file.c +21 -7
@@ -528,6 +528,11 @@ static void fuse_release_user_pages(stru } } +static void fuse_io_release (struct kref *kref) +{ +kfree (container_of(kref ,struct fuse_io_priv ,refcnt )); +} +static ssize_t fuse_get_res_by_io (struct fuse_io_priv *io) {if (io->err)
@@ -585,8 +590,9 @@ static void fuse_aio_complete(struct fus } io->iocb->ki_complete (io->iocb, res,0 ); -kfree (io); } + +kref_put (&io->refcnt, fuse_io_release); }static void fuse_aio_complete_req (struct fuse_conn *fc,struct fuse_req *req)
@@ -613,6 +619,7 @@ static size_t fuse_async_req_send(struct size_t num_bytes, struct fuse_io_priv *io) { spin_lock(&io->lock); +kref_get (&io->refcnt); io->size += num_bytes; io->reqs++;spin_unlock (&io->lock);
@@ -691,7 +698,7 @@ static void fuse_short_read(struct fuse_static int fuse_do_readpage (struct file *file,struct page *page) { -struct fuse_io_priv io = { .async =0 , .file = file }; +struct fuse_io_priv io =FUSE_IO_PRIV_SYNC (file);struct inode *inode = page->mapping->host;struct fuse_conn *fc =get_fuse_conn (inode);struct fuse_req *req;
@@ -984,7 +991,7 @@ static size_t fuse_send_write_pages(strusize_t res;unsigned offset;unsigned i; -struct fuse_io_priv io = { .async =0 , .file = file }; +struct fuse_io_priv io =FUSE_IO_PRIV_SYNC (file);for (i =0 ; i < req->num_pages; i++)fuse_wait_on_page_writeback (inode, req->pages[i]->index);
@@ -1398,7 +1405,7 @@ static ssize_t __fuse_direct_read(structstatic ssize_t fuse_direct_read_iter (struct kiocb *iocb,struct iov_iter *to) { -struct fuse_io_priv io = { .async =0 , .file = iocb->ki_filp }; +struct fuse_io_priv io =FUSE_IO_PRIV_SYNC (iocb->ki_filp);return __fuse_direct_read (&io, to, &iocb->ki_pos); }
@@ -1406,7 +1413,7 @@ static ssize_t fuse_direct_write_iter(st {struct file *file = iocb->ki_filp;struct inode *inode =file_inode (file); -struct fuse_io_priv io = { .async =0 , .file = file }; +struct fuse_io_priv io =FUSE_IO_PRIV_SYNC (file);ssize_t res;if (is_bad_inode (inode))
@@ -2864,6 +2871,7 @@ fuse_direct_IO(struct kiocb *iocb, strucif (!io)return -ENOMEM ;spin_lock_init (&io->lock); +kref_init (&io->refcnt); io->reqs =1 ; io->bytes =-1 ; io->size =0 ;
@@ -2887,8 +2895,14 @@ fuse_direct_IO(struct kiocb *iocb, struc iov_iter_rw(iter) == WRITE) io->async = false; -if (io->async && is_sync) +if (io->async && is_sync) { +/* +* Additional reference to keep io around after +* calling fuse_aio_complete() +*/ +kref_get (&io->refcnt); io->done = &wait; + }if (iov_iter_rw (iter) ==WRITE ) { ret =fuse_direct_io (io, iter, &pos,FUSE_DIO_WRITE );
@@ -2908,7 +2922,7 @@ fuse_direct_IO(struct kiocb *iocb, struc ret =fuse_get_res_by_io (io); } -kfree (io); +kref_put (&io->refcnt, fuse_io_release);if (iov_iter_rw (iter) ==WRITE ) {if (ret >0 )
fs/fuse/fuse_i.h +9 -0
@@ -22,6 +22,7 @@#include <linux/rbtree.h> #include <linux/poll.h> #include <linux/workqueue.h> +#include <linux/kref.h> /** Max number of pages that can be used in a single read request */ #define FUSE_MAX_PAGES_PER_REQ 32
@@ -243,6 +244,7 @@ struct fuse_args {/** The request IO state (for asynchronous processing) */ struct fuse_io_priv { +struct kref refcnt;int async;spinlock_t lock;unsigned reqs;
@@ -256,6 +258,13 @@ struct fuse_io_priv {struct completion *done; }; +#define FUSE_IO_PRIV_SYNC (f) \ +{ \ + .refcnt = { ATOMIC_INIT(1) }, \ + .async = 0, \ + .file = f, \ +} +/** * Request flags *
Greg Kroah-Hartman
maintainerPATCH 169/238 scripts/gdb: account for changes in module data structure
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kiszka <[email protected]>
commit ad4db3b24a93e52a92ad8f9b0273a9416f202c23 upstream.
Commit 7523e4dc5057 ("module: use a structure to encapsulate layout.") factored out the module_layout structure. Adjust the symbol loader and the lsmod command to this.
--- scripts/gdb/linux/modules.py | 5 +++-- scripts/gdb/linux/symbols.py | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-)
scripts/gdb/linux/modules.py +3 -2
@@ -73,10 +73,11 @@ class LxLsmod(gdb.Command): " " if utils.get_long_type().sizeof == 8 else "")) for module in module_list(): + layout = module['core_layout'] gdb.write("{address} {name:<19} {size:>8} {ref}".format( - address=str(module['module_core']).split()[0], + address=str(layout['base']).split()[0], name=module['name'].string(), - size=str(module['core_size']), + size=str(layout['size']), ref=str(module['refcnt']['counter']))) source_list = module['source_list']
scripts/gdb/linux/symbols.py +1 -1
@@ -108,7 +108,7 @@ lx-symbols command.""" def load_module_symbols(self, module): module_name = module['name'].string() - module_addr = str(module['module_core']).split()[0] + module_addr = str(module['core_layout']['base']).split()[0] module_file = self._get_module_file(module_name) if not module_file and not self.module_files_updated:
Greg Kroah-Hartman
maintainerPATCH 170/238 fs/coredump: prevent fsuid=0 dumps into user-controlled directories
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <[email protected]>
commit 378c6520e7d29280f400ef2ceaf155c86f05a71a upstream.
This commit fixes the following security hole affecting systems where all of the following conditions are fulfilled:
- The fs.suid_dumpable sysctl is set to 2.
- The kernel.core_pattern sysctl's value starts with "/". (Systems where kernel.core_pattern starts with "|/" are not affected.)
- Unprivileged user namespace creation is permitted. (This is true on Linux >=3.8, but some distributions disallow it by default using a distro patch.)
Under these conditions, if a program executes under secure exec rules, causing it to run with the SUID_DUMP_ROOT flag, then unshares its user namespace, changes its root directory and crashes, the coredump will be written using fsuid=0 and a path derived from kernel.core_pattern - but this path is interpreted relative to the root directory of the process, allowing the attacker to control where a coredump will be written with root privileges.
To fix the security issue, always interpret core_pattern for dumps that are written under SUID_DUMP_ROOT relative to the root directory of init.
--- arch/um/drivers/mconsole_kern.c | 2 +- fs/coredump.c | 30 ++++++++++++++++++++++++++---- fs/fhandle.c | 2 +- fs/open.c | 6 ++---- include/linux/fs.h | 2 +- kernel/sysctl_binary.c | 2 +- 6 files changed, 32 insertions(+), 12 deletions(-)
arch/um/drivers/mconsole_kern.c +1 -1
@@ -133,7 +133,7 @@ void mconsole_proc(struct mc_request *re ptr +=strlen ("proc" ); ptr =skip_spaces (ptr); - file =file_open_root (mnt->mnt_root, mnt, ptr,O_RDONLY ); + file =file_open_root (mnt->mnt_root, mnt, ptr,O_RDONLY ,0 );if (IS_ERR (file)) {mconsole_reply (req,"Failed to open file" ,1 ,0 );printk (KERN_ERR "open /proc/%s: %ld\n" , ptr,PTR_ERR (file));
fs/coredump.c +26 -4
@@ -32,6 +32,9 @@#include <linux/pipe_fs_i.h> #include <linux/oom.h> #include <linux/compat.h> +#include <linux/sched.h> +#include <linux/fs.h> +#include <linux/path.h> #include <linux/timekeeping.h> #include <asm/uaccess.h>
@@ -649,6 +652,8 @@ void do_coredump(const siginfo_t *siginf } }else {struct inode *inode; +int open_flags =O_CREAT |O_RDWR |O_NOFOLLOW | +O_LARGEFILE |O_EXCL ;if (cprm.limit < binfmt->min_coredump) goto fail_unlock;
@@ -687,10 +692,27 @@ void do_coredump(const siginfo_t *siginf* what matters is that at least one of the two processes * writes its coredump successfully, not which one. */ - cprm.file =filp_open (cn.corename, -O_CREAT |2 |O_NOFOLLOW | -O_LARGEFILE |O_EXCL , -0600 ); +if (need_suid_safe) { +/* +* Using user namespaces, normal user tasks can change +* their current->fs->root to point to arbitrary +* directories. Since the intention of the "only dump +* with a fully qualified path" rule is to control where +* coredumps may be placed using root privileges, +* current->fs->root must not be used. Instead, use the +* root directory of init_task. +*/ +struct path root; + +task_lock (&init_task); +get_fs_root (init_task.fs, &root); +task_unlock (&init_task); + cprm.file =file_open_root (root.dentry, root.mnt, + cn.corename, open_flags,0600 ); +path_put (&root); + }else { + cprm.file =filp_open (cn.corename, open_flags,0600 ); + }if (IS_ERR (cprm.file)) goto fail_unlock;
fs/fhandle.c +1 -1
@@ -228,7 +228,7 @@ long do_handle_open(int mountdirfd,path_put (&path);return fd; } - file =file_open_root (path.dentry, path.mnt,"" , open_flag); + file =file_open_root (path.dentry, path.mnt,"" , open_flag,0 );if (IS_ERR (file)) {put_unused_fd (fd); retval =PTR_ERR (file);
fs/open.c +2 -4
@@ -992,14 +992,12 @@ struct file *filp_open(const char *filenEXPORT_SYMBOL (filp_open);struct file *file_open_root (struct dentry *dentry,struct vfsmount *mnt, -const char *filename,int flags) +const char *filename,int flags,umode_t mode) {struct open_flags op; -int err =build_open_flags (flags,0 , &op); +int err =build_open_flags (flags, mode, &op);if (err)return ERR_PTR (err); -if (flags &O_CREAT ) -return ERR_PTR (-EINVAL );return do_file_open_root (dentry, mnt, filename, &op); }EXPORT_SYMBOL (file_open_root);
include/linux/fs.h +1 -1
@@ -2259,7 +2259,7 @@ extern long do_sys_open(int dfd, const cextern struct file *file_open_name (struct filename *,int ,umode_t );extern struct file *filp_open (const char *,int ,umode_t );extern struct file *file_open_root (struct dentry *,struct vfsmount *, -const char *,int ); +const char *,int ,umode_t );extern struct file *dentry_open (const struct path *,int ,const struct cred *);extern int filp_close (struct file *,fl_owner_t id);
kernel/sysctl_binary.c +1 -1
@@ -1321,7 +1321,7 @@ static ssize_t binary_sysctl(const int * } mnt =task_active_pid_ns (current)->proc_mnt; - file =file_open_root (mnt->mnt_root, mnt, pathname, flags); + file =file_open_root (mnt->mnt_root, mnt, pathname, flags,0 ); result =PTR_ERR (file);if (IS_ERR (file)) goto out_putname;
Greg Kroah-Hartman
maintainerPATCH 171/238 rapidio/rionet: fix deadlock on SMP
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aurelien Jacquiot <[email protected]>
commit 36915976eca58f2eefa040ba8f9939672564df61 upstream.
Fix deadlocking during concurrent receive and transmit operations on SMP platforms caused by the use of incorrect lock: on transmit 'tx_lock' spinlock should be used instead of 'lock' which is used for receive operation.
This fix is applicable to kernel versions starting from v2.15.
--- drivers/net/rionet.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/rionet.c +2 -2
@@ -280,7 +280,7 @@ static void rionet_outb_msg_event(structstruct net_device *ndev = dev_id;struct rionet_private *rnet =netdev_priv (ndev); -spin_lock (&rnet->lock); +spin_lock (&rnet->tx_lock);if (netif_msg_intr (rnet)) printk(KERN_INFO
@@ -299,7 +299,7 @@ static void rionet_outb_msg_event(structif (rnet->tx_cnt <RIONET_TX_RING_SIZE )netif_wake_queue (ndev); -spin_unlock (&rnet->lock); +spin_unlock (&rnet->tx_lock); }static int rionet_open (struct net_device *ndev)
Greg Kroah-Hartman
maintainerPATCH 172/238 drm/vc4: Return -EFAULT on copy_from_user() failure
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 585cb132a48190b554aecda2ebc3e2911fcbb665 upstream.
The copy_from_user() function returns the number of bytes not copied but we want to return a negative error code.
--- drivers/gpu/drm/vc4/vc4_bo.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/gpu/drm/vc4/vc4_bo.c +4 -3
@@ -499,11 +499,12 @@ vc4_create_shader_bo_ioctl(struct drm_deif (IS_ERR (bo))return PTR_ERR (bo); - ret =copy_from_user (bo->base.vaddr, +if (copy_from_user (bo->base.vaddr, (void __user *)(uintptr_t )args->data, - args->size); -if (ret !=0 ) + args->size)) { + ret = -EFAULT ; goto fail; + }/* Clear the rest of the memory from allocating from the BO * cache. */
Greg Kroah-Hartman
maintainerPATCH 174/238 drm/radeon: Dont drop DP 2.7 Ghz link setup on some cards.
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Kleiner <[email protected]>
commit 459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 upstream.
As observed on Apple iMac10,1, DCE-3.2, RV-730, link rate of 2.7 Ghz is not selected, because the args.v1.ucConfig flag setting for 2.7 Ghz gets overwritten by a following assignment of the transmitter to use.
Move link rate setup a few lines down to fix this. In practice this didn't have any positive or negative effect on display setup on the tested iMac10,1 so i don't know if backporting to stable makes sense or not.
--- drivers/gpu/drm/radeon/atombios_encoders.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/gpu/drm/radeon/atombios_encoders.c +4 -2
@@ -892,8 +892,6 @@ atombios_dig_encoder_setup2(struct drm_eelse args.v1.ucLaneNum =4 ; -if (ENCODER_MODE_IS_DP (args.v1.ucEncoderMode) && (dp_clock ==270000 )) - args.v1.ucConfig |=ATOM_ENCODER_CONFIG_DPLINKRATE_2_70GHZ ;switch (radeon_encoder->encoder_id) {case ENCODER_OBJECT_ID_INTERNAL_UNIPHY : args.v1.ucConfig =ATOM_ENCODER_CONFIG_V2_TRANSMITTER1 ;
@@ -910,6 +908,10 @@ atombios_dig_encoder_setup2(struct drm_e args.v1.ucConfig |=ATOM_ENCODER_CONFIG_LINKB ; else args.v1.ucConfig |= ATOM_ENCODER_CONFIG_LINKA; + +if (ENCODER_MODE_IS_DP (args.v1.ucEncoderMode) && (dp_clock ==270000 )) + args.v1.ucConfig |=ATOM_ENCODER_CONFIG_DPLINKRATE_2_70GHZ ; +break ;case 2 :case 3 :
Greg Kroah-Hartman
maintainerPATCH 175/238 drm/radeon: rework fbdev handling on chips with no connectors
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit e5f243bd2edd95c6cc1d90c1878f821068e83fba upstream.
Move all the logic to radeon_fb.c and add checks to functions called frome elsewhere.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=112781
--- drivers/gpu/drm/radeon/radeon_display.c | 6 ++---- drivers/gpu/drm/radeon/radeon_fb.c | 19 +++++++++++++++---- 2 files changed, 17 insertions(+), 8 deletions(-)
drivers/gpu/drm/radeon/radeon_display.c +2 -4
@@ -1683,10 +1683,8 @@ int radeon_modeset_init(struct radeon_de/* setup afmt */ radeon_afmt_init (rdev); -if (!list_empty (&rdev->ddev->mode_config.connector_list)) { -radeon_fbdev_init (rdev); -drm_kms_helper_poll_init (rdev->ddev); - } +radeon_fbdev_init (rdev); +drm_kms_helper_poll_init (rdev->ddev);/* do pm late init */ ret =radeon_pm_late_init (rdev);
drivers/gpu/drm/radeon/radeon_fb.c +15 -4
@@ -292,7 +292,8 @@ out_unref:void radeon_fb_output_poll_changed (struct radeon_device *rdev) { -drm_fb_helper_hotplug_event (&rdev->mode_info.rfbdev->helper); +if (rdev->mode_info.rfbdev) +drm_fb_helper_hotplug_event (&rdev->mode_info.rfbdev->helper); }static int radeon_fbdev_destroy (struct drm_device *dev,struct radeon_fbdev *rfbdev)
@@ -325,6 +326,10 @@ int radeon_fbdev_init(struct radeon_deviint bpp_sel =32 ;int ret; +/* don't enable fbdev if no connectors */ +if (list_empty (&rdev->ddev->mode_config.connector_list)) +return 0 ; +/* select 8 bpp console on RN50 or 16MB cards */ if (ASIC_IS_RN50 (rdev) || rdev->mc.real_vram_size <= (32 *1024 *1024 )) bpp_sel =8 ;
@@ -377,11 +382,15 @@ void radeon_fbdev_fini(struct radeon_devvoid radeon_fbdev_set_suspend (struct radeon_device *rdev,int state) { -fb_set_suspend (rdev->mode_info.rfbdev->helper.fbdev, state); +if (rdev->mode_info.rfbdev) +fb_set_suspend (rdev->mode_info.rfbdev->helper.fbdev, state); }bool radeon_fbdev_robj_is_fb (struct radeon_device *rdev,struct radeon_bo *robj) { +if (!rdev->mode_info.rfbdev) +return false; +if (robj ==gem_to_radeon_bo (rdev->mode_info.rfbdev->rfb.obj))return true;return false;
@@ -389,12 +398,14 @@ bool radeon_fbdev_robj_is_fb(struct radevoid radeon_fb_add_connector (struct radeon_device *rdev,struct drm_connector *connector) { -drm_fb_helper_add_one_connector (&rdev->mode_info.rfbdev->helper, connector); +if (rdev->mode_info.rfbdev) +drm_fb_helper_add_one_connector (&rdev->mode_info.rfbdev->helper, connector); }void radeon_fb_remove_connector (struct radeon_device *rdev,struct drm_connector *connector) { -drm_fb_helper_remove_one_connector (&rdev->mode_info.rfbdev->helper, connector); +if (rdev->mode_info.rfbdev) +drm_fb_helper_remove_one_connector (&rdev->mode_info.rfbdev->helper, connector); }void radeon_fbdev_restore_mode (struct radeon_device *rdev)
Greg Kroah-Hartman
maintainerPATCH 176/238 drm/radeon/mst: fix regression in lane/link handling.
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Airlie <[email protected]>
commit b36f7d26a7fdc0b07b1217368ee09bb8560269f8 upstream.
The function this used changed in
092c96a8ab9d1bd60ada2ed385cc364ce084180e drm/radeon: fix dp link rate selection (v2)
However for MST we should just always train to the max link/rate. Though we probably need to limit this for future hw, in theory radeon won't support it.
This fixes my 30" monitor with MST enabled.
--- drivers/gpu/drm/radeon/radeon_dp_mst.c | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-)
drivers/gpu/drm/radeon/radeon_dp_mst.c +2 -10
@@ -525,17 +525,9 @@ static bool radeon_mst_mode_fixup(structdrm_mode_set_crtcinfo (adjusted_mode,0 ); {struct radeon_connector_atom_dig *dig_connector; -int ret; - dig_connector = mst_enc->connector->con_priv; - ret =radeon_dp_get_dp_link_config (&mst_enc->connector->base, - dig_connector->dpcd, adjusted_mode->clock, - &dig_connector->dp_lane_count, - &dig_connector->dp_clock); -if (ret) { - dig_connector->dp_lane_count =0 ; - dig_connector->dp_clock =0 ; - } + dig_connector->dp_lane_count =drm_dp_max_lane_count (dig_connector->dpcd); + dig_connector->dp_clock =drm_dp_max_link_rate (dig_connector->dpcd);DRM_DEBUG_KMS ("dig clock %p %d %d\n" , dig_connector, dig_connector->dp_lane_count, dig_connector->dp_clock); }
Greg Kroah-Hartman
maintainerPATCH 178/238 drm/amdgpu: include the right version of gmc header files for iceland
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ken Wang <[email protected]>
commit 16a8a49be1b878ef6dd5d1663d456e254e54ae3d upstream.
--- drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c +2 -2
@@ -32,8 +32,8 @@#include "oss/oss_2_4_d.h" #include "oss/oss_2_4_sh_mask.h" -#include "gmc/gmc_8_1_d.h" -#include "gmc/gmc_8_1_sh_mask.h" +#include "gmc/gmc_7_1_d.h" +#include "gmc/gmc_7_1_sh_mask.h" #include "gca/gfx_8_0_d.h" #include "gca/gfx_8_0_enum.h"
Greg Kroah-Hartman
maintainerPATCH 179/238 drm/amd/powerplay: add uvd/vce dpm enabling flag to fix the performance issue for CZ
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Huang <[email protected]>
commit 60123300db80b17251b4de5e98c63e288c6f7b46 upstream.
Set the UVD and VCE DPM flags otherwise UVD and VCE DPM won't get enabled.
--- drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c +5 -0
@@ -241,6 +241,11 @@ static int cz_initialize_dpm_defaults(stphm_cap_set (hwmgr->platform_descriptor.platformCaps, PHM_PlatformCaps_DynamicUVDState); +phm_cap_set (hwmgr->platform_descriptor.platformCaps, + PHM_PlatformCaps_UVDDPM); +phm_cap_set (hwmgr->platform_descriptor.platformCaps, + PHM_PlatformCaps_VCEDPM); + cz_hwmgr->cc6_settings.cpu_cc6_disable = false; cz_hwmgr->cc6_settings.cpu_pstate_disable = false; cz_hwmgr->cc6_settings.nb_pstate_switch_disable = false;
Greg Kroah-Hartman
maintainerPATCH 180/238 tracing: Have preempt(irqs)off trace preempt disabled functions
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt (Red Hat) <[email protected]>
commit cb86e05390debcc084cfdb0a71ed4c5dbbec517d upstream.
Joel Fernandes reported that the function tracing of preempt disabled sections was not being reported when running either the preemptirqsoff or preemptoff tracers. This was due to the fact that the function tracer callback for those tracers checked if irqs were disabled before tracing. But this fails when we want to trace preempt off locations as well.
Joel explained that he wanted to see funcitons where interrupts are enabled but preemption was disabled. The expected output he wanted:
<...>-2265 1d.h1 3419us : preempt_count_sub <-irq_exit <...>-2265 1d..1 3419us : __do_softirq <-irq_exit <...>-2265 1d..1 3419us : msecs_to_jiffies <-__do_softirq <...>-2265 1d..1 3420us : irqtime_account_irq <-__do_softirq <...>-2265 1d..1 3420us : __local_bh_disable_ip <-__do_softirq <...>-2265 1..s1 3421us : run_timer_softirq <-__do_softirq <...>-2265 1..s1 3421us : hrtimer_run_pending <-run_timer_softirq <...>-2265 1..s1 3421us : _raw_spin_lock_irq <-run_timer_softirq <...>-2265 1d.s1 3422us : preempt_count_add <-_raw_spin_lock_irq <...>-2265 1d.s2 3422us : _raw_spin_unlock_irq <-run_timer_softirq <...>-2265 1..s2 3422us : preempt_count_sub <-_raw_spin_unlock_irq <...>-2265 1..s1 3423us : rcu_bh_qs <-__do_softirq <...>-2265 1d.s1 3423us : irqtime_account_irq <-__do_softirq <...>-2265 1d.s1 3423us : __local_bh_enable <-__do_softirq
There's a comment saying that the irq disabled check is because there's a possible race that tracing_cpu may be set when the function is executed. But I don't remember that race. For now, I added a check for preemption being enabled too to not record the function, as there would be no race if that was the case. I need to re-investigate this, as I'm now thinking that the tracing_cpu will always be correct. But no harm in keeping the check for now, except for the slight performance hit.
--- kernel/trace/trace_irqsoff.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
kernel/trace/trace_irqsoff.c +6 -2
@@ -109,8 +109,12 @@ static int func_prolog_dec(struct trace_return 0 ;local_save_flags (*flags); -/* slight chance to get a false positive on tracing_cpu */ -if (!irqs_disabled_flags (*flags)) +/* +* Slight chance to get a false positive on tracing_cpu, +* although I'm starting to think there isn't a chance. +* Leave this for now just to be paranoid. +*/ +if (!irqs_disabled_flags (*flags) && !preempt_count ())return 0 ; *data =per_cpu_ptr (tr->trace_buffer.data, cpu);
Greg Kroah-Hartman
maintainerPATCH 181/238 tracing: Fix crash from reading trace_pipe with sendfile
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt (Red Hat) <[email protected]>
commit a29054d9478d0435ab01b7544da4f674ab13f533 upstream.
If tracing contains data and the trace_pipe file is read with sendfile(), then it can trigger a NULL pointer dereference and various BUG_ON within the VM code.
There's a patch to fix this in the splice_to_pipe() code, but it's also a good idea to not let that happen from trace_pipe either.
--- kernel/trace/trace.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
kernel/trace/trace.c +4 -1
@@ -4949,7 +4949,10 @@ static ssize_t tracing_splice_read_pipe( spd.nr_pages = i; - ret =splice_to_pipe (pipe, &spd); +if (i) + ret =splice_to_pipe (pipe, &spd); +else + ret =0 ; out:splice_shrink_spd (&spd);return ret;
Greg Kroah-Hartman
maintainerPATCH 182/238 tracing: Fix trace_printk() to print when not using bprintk()
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt (Red Hat) <[email protected]>
commit 3debb0a9ddb16526de8b456491b7db60114f7b5e upstream.
The trace_printk() code will allocate extra buffers if the compile detects that a trace_printk() is used. To do this, the format of the trace_printk() is saved to the __trace_printk_fmt section, and if that section is bigger than zero, the buffers are allocated (along with a message that this has happened).
If trace_printk() uses a format that is not a constant, and thus something not guaranteed to be around when the print happens, the compiler optimizes the fmt out, as it is not used, and the __trace_printk_fmt section is not filled. This means the kernel will not allocate the special buffers needed for the trace_printk() and the trace_printk() will not write anything to the tracing buffer.
Adding a "__used" to the variable in the __trace_printk_fmt section will keep it around, even though it is set to NULL. This will keep the string from being printed in the debugfs/tracing/printk_formats section as it is not needed.
--- include/linux/kernel.h | 6 +++--- kernel/trace/trace_printk.c | 3 +++ 2 files changed, 6 insertions(+), 3 deletions(-)
include/linux/kernel.h +3 -3
@@ -635,7 +635,7 @@ do { \ #define do_trace_printk(fmt, args...) \ do { \ - static const char *trace_printk_fmt \ + static const char *trace_printk_fmt __used \ __attribute__((section("__trace_printk_fmt"))) = \ __builtin_constant_p(fmt) ? fmt : NULL; \ \
@@ -679,7 +679,7 @@ int __trace_printk(unsigned long ip, con*/ #define trace_puts (str) ({ \ - static const char *trace_printk_fmt \ + static const char *trace_printk_fmt __used \ __attribute__((section("__trace_printk_fmt"))) = \ __builtin_constant_p(str) ? str : NULL; \ \
@@ -701,7 +701,7 @@ extern void trace_dump_stack(int skip);#define ftrace_vprintk (fmt, vargs) \ do { \ if (__builtin_constant_p(fmt)) { \ - static const char *trace_printk_fmt \ + static const char *trace_printk_fmt __used \ __attribute__((section("__trace_printk_fmt"))) = \ __builtin_constant_p(fmt) ? fmt : NULL; \ \
kernel/trace/trace_printk.c +3 -0
@@ -296,6 +296,9 @@ static int t_show(struct seq_file *m, voconst char *str = *fmt;int i; +if (!*fmt) +return 0 ; +seq_printf (m,"0x%lx : \"" , *(unsigned long *)fmt);/*
Greg Kroah-Hartman
maintainerPATCH 183/238 bitops: Do not default to __clear_bit() for __clear_bit_unlock()
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
commit f75d48644c56a31731d17fa693c8175328957e1d upstream.
__clear_bit_unlock() is a special little snowflake. While it carries the non-atomic '__' prefix, it is specifically documented to pair with test_and_set_bit() and therefore should be 'somewhat' atomic.
Therefore the generic implementation of __clear_bit_unlock() cannot use the fully non-atomic __clear_bit() as a default.
If an arch is able to do better; is must provide an implementation of __clear_bit_unlock() itself.
Specifically, this came up as a result of hackbench livelock'ing in slab_lock() on ARC with SMP + SLUB + !LLSC.
The issue was incorrect pairing of atomic ops.
slab_lock() -> bit_spin_lock() -> test_and_set_bit() slab_unlock() -> __bit_spin_unlock() -> __clear_bit()
The non serializing __clear_bit() was getting "lost"
80543b8e: ld_s r2,[r13,0] <--- (A) Finds PG_locked is set 80543b90: or r3,r2,1 <--- (B) other core unlocks right here 80543b94: st_s r3,[r13,0] <--- (C) sets PG_locked (overwrites unlock)
Fixes ARC STAR 9000817404 (and probably more).
--- include/asm-generic/bitops/lock.h | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
include/asm-generic/bitops/lock.h +7 -7
@@ -29,16 +29,16 @@ do { \* @nr: the bit to set * @addr: the address to start counting from * -* This operation is like clear_bit_unlock, however it is not atomic. -* It does provide release barrier semantics so it can be used to unlock -* a bit lock, however it would only be used if no other CPU can modify -* any bits in the memory until the lock is released (a good example is -* if the bit lock itself protects access to the other bits in the word). +* A weaker form of clear_bit_unlock() as used by __bit_lock_unlock(). If all +* the bits in the word are protected by this lock some archs can use weaker +* ops to safely unlock. +* +* See for example x86's implementation. */ #define __clear_bit_unlock (nr, addr) \ do { \ - smp_mb(); \ - __clear_bit(nr, addr); \ + smp_mb__before_atomic(); \ + clear_bit(nr, addr); \ } while (0)#endif /* _ASM_GENERIC_BITOPS_LOCK_H_ */
Greg Kroah-Hartman
maintainerPATCH 184/238 scripts/coccinelle: modernize &
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julia Lawall <[email protected]>
commit 1b669e713f277a4d4b3cec84e13d16544ac8286d upstream.
& is no longer allowed in column 0, since Coccinelle 1.0.4.
--- scripts/coccinelle/iterators/use_after_iter.cocci | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
scripts/coccinelle/iterators/use_after_iter.cocci +1 -1
@@ -123,7 +123,7 @@ list_remove_head(x,c,...) | sizeof(<+...c...+>) | -&c->member + &c->member | c = E |
Greg Kroah-Hartman
maintainerPATCH 185/238 scripts/kconfig: allow building with make 3.80 again
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Beulich <[email protected]>
commit 42f9d3c6888bceef6dc7ba72c77acf47347dcf05 upstream.
Documentation/Changes still lists this as the minimal required version, so it ought to remain usable for the time being.
--- scripts/kconfig/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
scripts/kconfig/Makefile +3 -1
@@ -96,13 +96,15 @@ savedefconfig: $(obj)/conf defconfig: $(obj)/conf ifeq ($(KBUILD_DEFCONFIG),) $< $(silent) --defconfig $(Kconfig) -else ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)),) +else +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)),) @$(kecho) "*** Default configuration is based on '$(KBUILD_DEFCONFIG)'" $(Q)$< $(silent) --defconfig=arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kconfig) else @$(kecho) "*** Default configuration is based on target '$(KBUILD_DEFCONFIG)'" $(Q)$(MAKE) -f $(srctree)/Makefile $(KBUILD_DEFCONFIG) endif +endif %_defconfig: $(obj)/conf $(Q)$< $(silent) --defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig)
Greg Kroah-Hartman
maintainerPATCH 186/238 kbuild/mkspec: fix grub2 installkernel issue
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Kosina <[email protected]>
commit c8b08ca558c0067bc9e15ce3f1e70af260410bb2 upstream.
mkspec is copying built kernel to temporrary location
/boot/vmlinuz-$KERNELRELEASE-rpm
and runs installkernel on it. This however directly leads to grub2 menuentry for this suffixed binary being generated as well during the run of installkernel script.
Later in the process the temporary -rpm suffixed files are removed, and therefore we end up with spurious (and non-functional) grub2 menu entries for each installed kernel RPM.
Fix that by using a different temporary name (prefixed by '.'), so that the binary is not recognized as an actual kernel binary and no menuentry is created for it.
--- scripts/package/mkspec | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
scripts/package/mkspec +4 -4
@@ -131,11 +131,11 @@ echo 'rm -rf $RPM_BUILD_ROOT' echo "" echo "%post" echo "if [ -x /sbin/installkernel -a -r /boot/vmlinuz-$KERNELRELEASE -a -r /boot/System.map-$KERNELRELEASE ]; then" -echo "cp /boot/vmlinuz-$KERNELRELEASE /boot/vmlinuz-$KERNELRELEASE-rpm" -echo "cp /boot/System.map-$KERNELRELEASE /boot/System.map-$KERNELRELEASE-rpm" +echo "cp /boot/vmlinuz-$KERNELRELEASE /boot/.vmlinuz-$KERNELRELEASE-rpm" +echo "cp /boot/System.map-$KERNELRELEASE /boot/.System.map-$KERNELRELEASE-rpm" echo "rm -f /boot/vmlinuz-$KERNELRELEASE /boot/System.map-$KERNELRELEASE" -echo "/sbin/installkernel $KERNELRELEASE /boot/vmlinuz-$KERNELRELEASE-rpm /boot/System.map-$KERNELRELEASE-rpm" -echo "rm -f /boot/vmlinuz-$KERNELRELEASE-rpm /boot/System.map-$KERNELRELEASE-rpm" +echo "/sbin/installkernel $KERNELRELEASE /boot/.vmlinuz-$KERNELRELEASE-rpm /boot/.System.map-$KERNELRELEASE-rpm" +echo "rm -f /boot/.vmlinuz-$KERNELRELEASE-rpm /boot/.System.map-$KERNELRELEASE-rpm" echo "fi" echo "" echo "%files"
Greg Kroah-Hartman
maintainerPATCH 187/238 MAINTAINERS: Update mailing list and web page for hwmon subsystem
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
commit 968ce1b1f45a7d76b5471b19bd035dbecc72f32d upstream.
The old web page for the hwmon subsystem is no longer operational, and the mailing list has become unreliable. Move both to kernel.org.
--- MAINTAINERS | 96 ++++++++++++++++++++++++++++++------------------------------ 1 file changed, 48 insertions(+), 48 deletions(-)
MAINTAINERS +48 -48
@@ -228,13 +228,13 @@ F: kernel/sys_ni.c ABIT UGURU 1,2 HARDWARE MONITOR DRIVER M: Hans de Goede <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/abituguru.c ABIT UGURU 3 HARDWARE MONITOR DRIVER M: Alistair John Strachan <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/abituguru3.c
@@ -386,14 +386,14 @@ F: Documentation/devicetree/bindings/net ADM1025 HARDWARE MONITOR DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/adm1025 F: drivers/hwmon/adm1025.c ADM1029 HARDWARE MONITOR DRIVER M: Corentin Labbe <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/adm1029.c
@@ -438,7 +438,7 @@ F: drivers/video/backlight/adp8860_bl.c ADS1015 HARDWARE MONITOR DRIVER M: Dirk Eibach <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/ads1015 F: drivers/hwmon/ads1015.c
@@ -451,7 +451,7 @@ F: drivers/macintosh/therm_adt746x.c ADT7475 HARDWARE MONITOR DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/adt7475 F: drivers/hwmon/adt7475.c
@@ -628,7 +628,7 @@ F: include/linux/ccp.h AMD FAM15H PROCESSOR POWER MONITORING DRIVER M: Huang Rui <[email protected]> -L: [email protected] +L: [email protected] S: Supported F: Documentation/hwmon/fam15h_power F: drivers/hwmon/fam15h_power.c
@@ -786,7 +786,7 @@ F: drivers/input/mouse/bcm5974.c APPLE SMC DRIVER M: Henrik Rydberg <[email protected]> -L: [email protected] +L: [email protected] S: Odd fixes F: drivers/hwmon/applesmc.c
@@ -1825,7 +1825,7 @@ F: include/media/i2c/as3645a.h ASC7621 HARDWARE MONITOR DRIVER M: George Joseph <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/asc7621 F: drivers/hwmon/asc7621.c
@@ -1918,7 +1918,7 @@ F: drivers/net/wireless/ath/carl9170/ ATK0110 HWMON DRIVER M: Luca Tettamanti <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/asus_atk0110.c
@@ -3037,7 +3037,7 @@ F: mm/swap_cgroup.c CORETEMP HARDWARE MONITORING DRIVER M: Fenghua Yu <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/coretemp F: drivers/hwmon/coretemp.c
@@ -3625,7 +3625,7 @@ T: git git://git.infradead.org/users/vko DME1737 HARDWARE MONITOR DRIVER M: Juerg Haefliger <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/dme1737 F: drivers/hwmon/dme1737.c
@@ -4322,7 +4322,7 @@ F: include/video/exynos_mipi* F71805F HARDWARE MONITORING DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/f71805f F: drivers/hwmon/f71805f.c
@@ -4401,7 +4401,7 @@ F: fs/* FINTEK F75375S HARDWARE MONITOR AND FAN CONTROLLER DRIVER M: Riku Voipio <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/f75375s.c F: include/linux/f75375s.h
@@ -4958,8 +4958,8 @@ F: drivers/media/usb/hackrf/ HARDWARE MONITORING M: Jean Delvare <[email protected]> M: Guenter Roeck <[email protected]> -L: [email protected] -W: http://www.lm-sensors.org/ +L: [email protected] +W: http://hwmon.wiki.kernel.org/ T: quilt http://jdelvare.nerim.net/devel/linux/jdelvare-hwmon/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git S: Maintained
@@ -5484,7 +5484,7 @@ F: drivers/usb/atm/ueagle-atm.c INA209 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/ina209 F: Documentation/devicetree/bindings/i2c/ina209.txt
@@ -5492,7 +5492,7 @@ F: drivers/hwmon/ina209.c INA2XX HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/ina2xx F: drivers/hwmon/ina2xx.c
@@ -5985,7 +5985,7 @@ F: drivers/isdn/hardware/eicon/ IT87 HARDWARE MONITORING DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/it87 F: drivers/hwmon/it87.c
@@ -6021,7 +6021,7 @@ F: drivers/media/dvb-frontends/ix2505v* JC42.4 TEMPERATURE SENSOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/jc42.c F: Documentation/hwmon/jc42
@@ -6071,14 +6071,14 @@ F: drivers/tty/serial/jsm/ K10TEMP HARDWARE MONITORING DRIVER M: Clemens Ladisch <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/k10temp F: drivers/hwmon/k10temp.c K8TEMP HARDWARE MONITORING DRIVER M: Rudolf Marek <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/k8temp F: drivers/hwmon/k8temp.c
@@ -6605,27 +6605,27 @@ F: net/llc/ LM73 HARDWARE MONITOR DRIVER M: Guillaume Ligneul <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/lm73.c LM78 HARDWARE MONITOR DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/lm78 F: drivers/hwmon/lm78.c LM83 HARDWARE MONITOR DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/lm83 F: drivers/hwmon/lm83.c LM90 HARDWARE MONITOR DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/lm90 F: Documentation/devicetree/bindings/hwmon/lm90.txt
@@ -6633,7 +6633,7 @@ F: drivers/hwmon/lm90.c LM95234 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/lm95234 F: drivers/hwmon/lm95234.c
@@ -6700,7 +6700,7 @@ F: drivers/scsi/sym53c8xx_2/ LTC4261 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/ltc4261 F: drivers/hwmon/ltc4261.c
@@ -6870,28 +6870,28 @@ F: include/uapi/linux/matroxfb.h MAX16065 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/max16065 F: drivers/hwmon/max16065.c MAX20751 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/max20751 F: drivers/hwmon/max20751.c MAX6650 HARDWARE MONITOR AND FAN CONTROLLER DRIVER M: "Hans J. Koch" <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/max6650 F: drivers/hwmon/max6650.c MAX6697 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/max6697 F: Documentation/devicetree/bindings/i2c/max6697.txt
@@ -7455,7 +7455,7 @@ F: drivers/scsi/NCR_D700.* NCT6775 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/nct6775 F: drivers/hwmon/nct6775.c
@@ -8235,7 +8235,7 @@ F: drivers/video/logo/logo_parisc* PC87360 HARDWARE MONITORING DRIVER M: Jim Cromie <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/pc87360 F: drivers/hwmon/pc87360.c
@@ -8247,7 +8247,7 @@ F: drivers/char/pc8736x_gpio.c PC87427 HARDWARE MONITORING DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/pc87427 F: drivers/hwmon/pc87427.c
@@ -8601,8 +8601,8 @@ F: drivers/rtc/rtc-puv3.c PMBUS HARDWARE MONITORING DRIVERS M: Guenter Roeck <[email protected]> -L: [email protected] -W: http://www.lm-sensors.org/ +L: [email protected] +W: http://hwmon.wiki.kernel.org/ W: http://www.roeck-us.net/linux/drivers/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git S: Maintained
@@ -8807,7 +8807,7 @@ F: drivers/media/usb/pwc/* PWM FAN DRIVER M: Kamil Debski <[email protected]> -L: [email protected] +L: [email protected] S: Supported F: Documentation/devicetree/bindings/hwmon/pwm-fan.txt F: Documentation/hwmon/pwm-fan
@@ -10113,28 +10113,28 @@ F: Documentation/devicetree/bindings/med SMM665 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/smm665 F: drivers/hwmon/smm665.c SMSC EMC2103 HARDWARE MONITOR DRIVER M: Steve Glendinning <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/emc2103 F: drivers/hwmon/emc2103.c SMSC SCH5627 HARDWARE MONITOR DRIVER M: Hans de Goede <[email protected]> -L: [email protected] +L: [email protected] S: Supported F: Documentation/hwmon/sch5627 F: drivers/hwmon/sch5627.c SMSC47B397 HARDWARE MONITOR DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/smsc47b397 F: drivers/hwmon/smsc47b397.c
@@ -11067,7 +11067,7 @@ F: include/linux/mmc/sh_mobile_sdhi.h TMP401 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/tmp401 F: drivers/hwmon/tmp401.c
@@ -11812,14 +11812,14 @@ F: Documentation/networking/vrf.txt VT1211 HARDWARE MONITOR DRIVER M: Juerg Haefliger <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/vt1211 F: drivers/hwmon/vt1211.c VT8231 HARDWARE MONITOR DRIVER M: Roger Lucas <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/vt8231.c
@@ -11838,21 +11838,21 @@ F: drivers/w1/ W83791D HARDWARE MONITORING DRIVER M: Marc Hulsman <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/w83791d F: drivers/hwmon/w83791d.c W83793 HARDWARE MONITORING DRIVER M: Rudolf Marek <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/w83793 F: drivers/hwmon/w83793.c W83795 HARDWARE MONITORING DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/w83795.c
Greg Kroah-Hartman
maintainerPATCH 188/238 ideapad-laptop: Add ideapad Y700 (15) to the no_hw_rfkill DMI list
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Dahlstrom <[email protected]>
commit 4db9675d927a71faa66e5ab128d2390d6329750b upstream.
Some Lenovo ideapad models lack a physical rfkill switch. On Lenovo models ideapad Y700 Touch-15ISK and ideapad Y700-15ISK, ideapad-laptop would wrongly report all radios as blocked by hardware which caused wireless network connections to fail.
Add these models without an rfkill switch to the no_hw_rfkill list.
--- drivers/platform/x86/ideapad-laptop.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/platform/x86/ideapad-laptop.c +14 -0
@@ -865,6 +865,20 @@ static const struct dmi_system_id no_hw_ }, }, { + .ident = "Lenovo ideapad Y700-15ISK", + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"LENOVO" ), + DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad Y700-15ISK"), + }, + }, + { + .ident ="Lenovo ideapad Y700 Touch-15ISK" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"LENOVO" ), + DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad Y700 Touch-15ISK"), + }, + }, + { .ident ="Lenovo ideapad Y700-17ISK" , .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
Greg Kroah-Hartman
maintainerPATCH 189/238 mmc: block: fix ABI regression of mmc_blk_ioctl
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shawn Lin <[email protected]>
commit 83c742c344c08c2bbe338d45c6ec63110e9d5e3d upstream.
If mmc_blk_ioctl returns -EINVAL, blkdev_ioctl continues to work without returning err to user-space. But now we check CAP_SYS_RAWIO firstly, so we return -EPERM to blkdev_ioctl, which make blkdev_ioctl return -EPERM to user-space directly. So this will break all the ioctl with BLKROSET. Now we find Android-adb suffer it for the following log:
remount of /system failed;
couldn't make block device writable: Operation not permitted openat(AT_FDCWD, "/dev/block/platform/ff420000.dwmmc/by-name/system", O_RDONLY) = 3 ioctl(3, BLKROSET, 0) = -1 EPERM (Operation not permitted)
--- drivers/mmc/card/block.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-)
drivers/mmc/card/block.c +16 -8
@@ -589,6 +589,14 @@ static int mmc_blk_ioctl_cmd(struct blocstruct mmc_card *card;int err =0 , ioc_err =0 ; +/* +* The caller must have CAP_SYS_RAWIO, and must be calling this on the +* whole block device, not on a partition. This prevents overspray +* between sibling partitions. +*/ +if ((!capable (CAP_SYS_RAWIO )) || (bdev != bdev->bd_contains)) +return -EPERM ; + idata =mmc_blk_ioctl_copy_from_user (ic_ptr);if (IS_ERR (idata))return PTR_ERR (idata);
@@ -631,6 +639,14 @@ static int mmc_blk_ioctl_multi_cmd(strucint i, err =0 , ioc_err =0 ;__u64 num_of_cmds; +/* +* The caller must have CAP_SYS_RAWIO, and must be calling this on the +* whole block device, not on a partition. This prevents overspray +* between sibling partitions. +*/ +if ((!capable (CAP_SYS_RAWIO )) || (bdev != bdev->bd_contains)) +return -EPERM ; +if (copy_from_user (&num_of_cmds, &user->num_of_cmds,sizeof (num_of_cmds)))return -EFAULT ;
@@ -688,14 +704,6 @@ cmd_err:static int mmc_blk_ioctl (struct block_device *bdev,fmode_t mode,unsigned int cmd,unsigned long arg) { -/* -* The caller must have CAP_SYS_RAWIO, and must be calling this on the -* whole block device, not on a partition. This prevents overspray -* between sibling partitions. -*/ -if ((!capable (CAP_SYS_RAWIO )) || (bdev != bdev->bd_contains)) -return -EPERM ; -switch (cmd) {case MMC_IOC_CMD : return mmc_blk_ioctl_cmd(bdev,
Greg Kroah-Hartman
maintainerPATCH 190/238 mmc: mmc_spi: Add Card Detect comments and fix CD GPIO case
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Magnus Damm <[email protected]>
commit bcdc9f260bdce09913db1464be9817170d51044a upstream.
This patch fixes the MMC SPI driver from doing polling card detect when a CD GPIO that supports interrupts is specified using the gpios DT property.
Without this patch the DT node below results in the following output:
spi_gpio: spi-gpio { /* SD2 @ CN12 */
compatible = "spi-gpio";
#address-cells = <1>;
#size-cells = <0>;
gpio-sck = <&gpio6 16 GPIO_ACTIVE_HIGH>;
gpio-mosi = <&gpio6 17 GPIO_ACTIVE_HIGH>;
gpio-miso = <&gpio6 18 GPIO_ACTIVE_HIGH>;
num-chipselects = <1>;
cs-gpios = <&gpio6 21 GPIO_ACTIVE_LOW>;
status = "okay";
spi@0 {
compatible = "mmc-spi-slot";
reg = <0>;
voltage-ranges = <3200 3400>;
spi-max-frequency = <25000000>;
gpios = <&gpio6 22 GPIO_ACTIVE_LOW>; /* CD */
};};
# dmesg | grep mmc mmc_spi spi32766.0: SD/MMC host mmc0, no WP, no poweroff, cd polling mmc0: host does not support reading read-only switch, assuming write-enable mmc0: new SDHC card on SPI mmcblk0: mmc0:0000 SU04G 3.69 GiB mmcblk0: p1
With this patch applied the "cd polling" portion above disappears.
--- drivers/mmc/host/mmc_spi.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/mmc/host/mmc_spi.c +6 -0
@@ -1442,6 +1442,12 @@ static int mmc_spi_probe(struct spi_devi host->pdata->cd_debounce);if (status !=0 ) goto fail_add_host; + +/* The platform has a CD GPIO signal that may support +* interrupts, so let mmc_gpiod_request_cd_irq() decide +* if polling is needed or not. +*/ + mmc->caps &= ~MMC_CAP_NEEDS_POLL ;mmc_gpiod_request_cd_irq (mmc); }
Greg Kroah-Hartman
maintainerPATCH 191/238 mmc: sdhci: move initialisation of command error member
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit 96776200898cf9c1965b9f8b9a128e94bb6dce18 upstream.
When a command is started, logically it has no error. Initialise the command's error member to zero whenever we start a command.
--- drivers/mmc/host/sdhci.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/mmc/host/sdhci.c +3 -2
@@ -1003,6 +1003,9 @@ void sdhci_send_command(struct sdhci_hosWARN_ON (host->cmd); +/* Initially, a command has no error */ + cmd->error =0 ; +/* Wait max 10 ms */ timeout =10 ;
@@ -1097,8 +1100,6 @@ static void sdhci_finish_command(struct } } - host->cmd->error =0 ; -/* Finished CMD23, now send actual command. */ if (host->cmd == host->mrq->sbc) { host->cmd =NULL ;
Greg Kroah-Hartman
maintainerPATCH 192/238 mmc: sdhci: clean up command error handling
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit ec014cbacf6229c583cb832726ca39be1ae3d8c3 upstream.
Avoid multiple tests while handling a command error; simplify the code.
--- drivers/mmc/host/sdhci.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/mmc/host/sdhci.c +6 -6
@@ -2323,13 +2323,13 @@ static void sdhci_cmd_irq(struct sdhci_hreturn ; } -if (intmask &SDHCI_INT_TIMEOUT ) - host->cmd->error = -ETIMEDOUT ; -else if (intmask & (SDHCI_INT_CRC |SDHCI_INT_END_BIT | -SDHCI_INT_INDEX )) - host->cmd->error = -EILSEQ ; +if (intmask & (SDHCI_INT_TIMEOUT |SDHCI_INT_CRC | +SDHCI_INT_END_BIT |SDHCI_INT_INDEX )) { +if (intmask &SDHCI_INT_TIMEOUT ) + host->cmd->error = -ETIMEDOUT ; +else + host->cmd->error = -EILSEQ ; -if (host->cmd->error) {tasklet_schedule (&host->finish_tasklet);return ; }
Greg Kroah-Hartman
maintainerPATCH 193/238 mmc: sdhci: fix command response CRC error handling
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit 71fcbda0fcddd0896c4982a484f6c8aa802d28b1 upstream.
When we get a response CRC error on a command, it means that the response we received back from the card was not correct. It does not mean that the card did not receive the command correctly. If the command is one which initiates a data transfer, the card can enter the data transfer state, and start sending data.
Moreover, if the request contained a data phase, we do not clean this up, and this results in the driver triggering DMA API debug warnings, and also creates a race condition in the driver, between running the finish_tasklet and the data transfer interrupts, which can trigger a "Got data interrupt" state dump.
Fix this by handing a response CRC error slightly differently: record the failure of the data initiating command, but allow the remainder of the request to be processed normally. This is safe as core MMC checks the status of all commands and data transfer phases of the request.
If the card does not initiate a data transfer, then we should time out according to the data transfer parameters.
--- drivers/mmc/host/sdhci.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
drivers/mmc/host/sdhci.c +17 -0
@@ -2330,6 +2330,23 @@ static void sdhci_cmd_irq(struct sdhci_helse host->cmd->error = -EILSEQ ; +/* +* If this command initiates a data phase and a response +* CRC error is signalled, the card can start transferring +* data - the card may have received the command without +* error. We must not terminate the mmc_request early. +* +* If the card did not receive the command or returned an +* error which prevented it sending data, the data phase +* will time out. +*/ +if (host->cmd->data && + (intmask & (SDHCI_INT_CRC |SDHCI_INT_TIMEOUT )) == +SDHCI_INT_CRC ) { + host->cmd =NULL ; +return ; + } +tasklet_schedule (&host->finish_tasklet);return ; }
Greg Kroah-Hartman
maintainerPATCH 194/238 mmc: sdhci: further fix for DMA unmapping in sdhci_post_req()
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit 771a3dc225815b7cc691c1ce703a3af8488e48df upstream.
sdhci_post_req() exists to unmap a previously mapped but already finished request, while the next request is in progress. However, the state of the SDHCI_REQ_USE_DMA flag depends on the last submitted request.
This means we can end up clearing the flag due to a quirk, which then means that sdhci_post_req() fails to unmap the DMA buffer, potentially leading to data corruption.
We can safely ignore the SDHCI_REQ_USE_DMA here, as testing data->host_cookie is entirely sufficient.
--- drivers/mmc/host/sdhci.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-)
drivers/mmc/host/sdhci.c +7 -8
@@ -2115,14 +2115,13 @@ static void sdhci_post_req(struct mmc_hostruct sdhci_host *host =mmc_priv (mmc);struct mmc_data *data = mrq->data; -if (host->flags &SDHCI_REQ_USE_DMA ) { -if (data->host_cookie ==COOKIE_GIVEN || - data->host_cookie ==COOKIE_MAPPED ) -dma_unmap_sg (mmc_dev (host->mmc), data->sg, data->sg_len, - data->flags &MMC_DATA_WRITE ? -DMA_TO_DEVICE :DMA_FROM_DEVICE ); - data->host_cookie =COOKIE_UNMAPPED ; - } +if (data->host_cookie ==COOKIE_GIVEN || + data->host_cookie ==COOKIE_MAPPED ) +dma_unmap_sg (mmc_dev (host->mmc), data->sg, data->sg_len, + data->flags &MMC_DATA_WRITE ? +DMA_TO_DEVICE :DMA_FROM_DEVICE ); + + data->host_cookie =COOKIE_UNMAPPED ; } static int sdhci_pre_dma_transfer(struct sdhci_host *host,
Greg Kroah-Hartman
maintainerPATCH 195/238 mmc: sdhci: avoid unnecessary mapping/unmapping of align buffer
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit edd63fcc97cdb53279a7c43fa1691f5913d92793 upstream.
Unnecessarily mapping and unmapping the align buffer for SD cards is
expensive: performance measurements on iMX6 show that this gives a hit of 10% on hdparm buffered disk reads.
MMC/SD card IO comes from the mm/vfs which gives us page based IO, so for this case, the align buffer is not going to be used. However, we still map and unmap this buffer.
Eliminate this by switching the align buffer to be a DMA coherent buffer, which needs no DMA maintenance to access the buffer.
--- drivers/mmc/host/sdhci.c | 54 +++++++++++++++-------------------------------- 1 file changed, 18 insertions(+), 36 deletions(-)
drivers/mmc/host/sdhci.c +18 -36
@@ -465,8 +465,6 @@ static void sdhci_adma_mark_end(void *destatic int sdhci_adma_table_pre (struct sdhci_host *host,struct mmc_data *data) { -int direction; -void *desc;void *align;dma_addr_t addr;
@@ -483,20 +481,9 @@ static int sdhci_adma_table_pre(struct s* We currently guess that it is LE. */ -if (data->flags &MMC_DATA_READ ) - direction =DMA_FROM_DEVICE ; -else - direction =DMA_TO_DEVICE ; - - host->align_addr =dma_map_single (mmc_dev (host->mmc), - host->align_buffer, host->align_buffer_sz, direction); -if (dma_mapping_error (mmc_dev (host->mmc), host->align_addr)) - goto fail; -BUG_ON (host->align_addr &SDHCI_ADMA2_MASK ); - host->sg_count =sdhci_pre_dma_transfer (host, data);if (host->sg_count <0 ) - goto unmap_align; +return -EINVAL ; desc = host->adma_table; align = host->align_buffer;
@@ -570,22 +557,7 @@ static int sdhci_adma_table_pre(struct s/* nop, end, valid */ sdhci_adma_write_desc (host, desc,0 ,0 ,ADMA2_NOP_END_VALID ); } - -/* -* Resync align buffer as we might have changed it. -*/ -if (data->flags &MMC_DATA_WRITE ) { -dma_sync_single_for_device (mmc_dev (host->mmc), - host->align_addr, host->align_buffer_sz, direction); - } -return 0 ; - -unmap_align: -dma_unmap_single (mmc_dev (host->mmc), host->align_addr, - host->align_buffer_sz, direction); -fail: -return -EINVAL ; } static void sdhci_adma_table_post(struct sdhci_host *host,
@@ -605,9 +577,6 @@ static void sdhci_adma_table_post(structelse direction =DMA_TO_DEVICE ; -dma_unmap_single (mmc_dev (host->mmc), host->align_addr, - host->align_buffer_sz, direction); -/* Do a quick scan of the SG list for any unaligned mappings */ has_unaligned = false;for_each_sg (data->sg, sg, host->sg_count, i)
@@ -2984,14 +2953,21 @@ int sdhci_add_host(struct sdhci_host *ho &host->adma_addr, GFP_KERNEL); host->align_buffer_sz =SDHCI_MAX_SEGS *SDHCI_ADMA2_ALIGN ; - host->align_buffer =kmalloc (host->align_buffer_sz,GFP_KERNEL ); + host->align_buffer =dma_alloc_coherent (mmc_dev (mmc), + host->align_buffer_sz, + &host->align_addr, +GFP_KERNEL );if (!host->adma_table || !host->align_buffer) {if (host->adma_table)dma_free_coherent (mmc_dev (mmc), host->adma_table_sz, host->adma_table, host->adma_addr); -kfree (host->align_buffer); +if (host->align_buffer) +dma_free_coherent (mmc_dev (mmc), + host->align_buffer_sz, + host->align_buffer, + host->align_addr);pr_warn ("%s: Unable to allocate ADMA buffers - falling back to standard DMA\n" ,mmc_hostname (mmc)); host->flags &= ~SDHCI_USE_ADMA ;
@@ -3003,10 +2979,14 @@ int sdhci_add_host(struct sdhci_host *ho host->flags &= ~SDHCI_USE_ADMA ;dma_free_coherent (mmc_dev (mmc), host->adma_table_sz, host->adma_table, host->adma_addr); -kfree (host->align_buffer); +dma_free_coherent (mmc_dev (mmc), host->align_buffer_sz, + host->align_buffer, host->align_addr); host->adma_table =NULL ; host->align_buffer =NULL ; } + +/* dma_alloc_coherent returns page aligned and sized buffers */ +BUG_ON (host->align_addr &SDHCI_ADMA2_MASK ); }/*
@@ -3469,7 +3449,9 @@ void sdhci_remove_host(struct sdhci_hostif (host->adma_table)dma_free_coherent (mmc_dev (mmc), host->adma_table_sz, host->adma_table, host->adma_addr); -kfree (host->align_buffer); +if (host->align_buffer) +dma_free_coherent (mmc_dev (mmc), host->align_buffer_sz, + host->align_buffer, host->align_addr); host->adma_table =NULL ; host->align_buffer =NULL ;
Greg Kroah-Hartman
maintainerPATCH 196/238 mmc: sdhci: plug DMA mapping leak on error
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit 054cedff5e025a54ceefff891c6ea42ee8b37eab upstream.
If we terminate a command early, we fail to properly clean up the DMA mappings for the data part of the request. Put this clean up to the tasklet, which is the common path for finishing a request so we always clean up after ourselves.
--- drivers/mmc/host/sdhci.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
drivers/mmc/host/sdhci.c +16 -0
@@ -2207,6 +2207,22 @@ static void sdhci_tasklet_finish(unsigne mrq = host->mrq;/* +* Always unmap the data buffers if they were mapped by +* sdhci_prepare_data() whenever we finish with a request. +* This avoids leaking DMA mappings on error. +*/ +if (host->flags &SDHCI_REQ_USE_DMA ) { +struct mmc_data *data = mrq->data; + +if (data && data->host_cookie ==COOKIE_MAPPED ) { +dma_unmap_sg (mmc_dev (host->mmc), data->sg, data->sg_len, + (data->flags &MMC_DATA_READ ) ? +DMA_FROM_DEVICE :DMA_TO_DEVICE ); + data->host_cookie =COOKIE_UNMAPPED ; + } + } + +/* * The controller needs a reset of internal state machines * upon error conditions. */
Greg Kroah-Hartman
maintainerPATCH 197/238 mmc: sdhci: fix data timeout (part 1)
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit fafcfda9e78cae8796d1799f14e6457790797555 upstream.
The data timeout gives the minimum amount of time that should be waited before timing out if no data is received from the card. Simply dividing the nanosecond part by 1000 does not give this required guarantee, since such a division rounds down. Use DIV_ROUND_UP() to give the desired timeout.
--- drivers/mmc/host/sdhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mmc/host/sdhci.c +1 -1
@@ -635,7 +635,7 @@ static u8 sdhci_calc_timeout(struct sdhcif (!data) target_timeout = cmd->busy_timeout *1000 ;else { - target_timeout = data->timeout_ns /1000 ; + target_timeout =DIV_ROUND_UP (data->timeout_ns,1000 );if (host->clock) target_timeout += data->timeout_clks / host->clock; }
Greg Kroah-Hartman
maintainerPATCH 198/238 mmc: sdhci: fix data timeout (part 2)
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit 7f05538af71c7d30b5fc821cbe9f318edc645961 upstream.
The calculation for the timeout based on the number of card clocks is incorrect. The calculation assumed:
timeout in microseconds = clock cycles / clock in Hz
which is clearly a several orders of magnitude wrong. Fix this by multiplying the clock cycles by 1000000 prior to dividing by the Hz based clock. Also, as per part 1, ensure that the division rounds up.
As this needs 64-bit math via do_div(), avoid it if the clock cycles is zero.
--- drivers/mmc/host/sdhci.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
drivers/mmc/host/sdhci.c +13 -2
@@ -636,8 +636,19 @@ static u8 sdhci_calc_timeout(struct sdhc target_timeout = cmd->busy_timeout *1000 ; else { target_timeout =DIV_ROUND_UP (data->timeout_ns,1000 ); -if (host->clock) - target_timeout += data->timeout_clks / host->clock; +if (host->clock && data->timeout_clks) { +unsigned long long val; + +/* +* data->timeout_clks is in units of clock cycles. +* host->clock is in Hz. target_timeout is in us. +* Hence, us = 1000000 * cycles / Hz. Round up. +*/ + val =1000000 * data->timeout_clks; +if (do_div (val, host->clock)) + target_timeout++; + target_timeout += val; + } }/*
Greg Kroah-Hartman
maintainerPATCH 199/238 mmc: sdhci-pxav3: fix higher speed mode capabilities
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit 0ca33b4ad9cfc133bb3d93eec1ad0eea83d6f252 upstream.
Commit 1140011ee9d9 ("mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes") broke any chance of the SDR50 or DDR50 modes being used.
The commit claims that SDR50 and DDR50 require clock adjustments in the SDIO3 Configuration register, which is located via the "conf-sdio3" resource. However, when this resource is given, we fail to read the host capabilities 1 register, resulting in host->caps1 being zero. Hence, both SDHCI_SUPPORT_SDR50 and SDHCI_SUPPORT_DDR50 bits remain zero, disabling the SDR50 and DDR50 modes.
The underlying idea in this function appears to be to read the device capabilities, modify them, and set SDHCI_QUIRK_MISSING_CAPS to cause our modified capabilities to be used. Implement exactly that.
--- drivers/mmc/host/sdhci-pxav3.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/mmc/host/sdhci-pxav3.c +4 -2
@@ -137,6 +137,10 @@ static int armada_38x_quirks(struct plat host->quirks &= ~SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN ; host->quirks |=SDHCI_QUIRK_MISSING_CAPS ; + + host->caps =sdhci_readl (host,SDHCI_CAPABILITIES ); + host->caps1 =sdhci_readl (host,SDHCI_CAPABILITIES_1 ); + res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"conf-sdio3" );if (res) {
@@ -150,7 +154,6 @@ static int armada_38x_quirks(struct plat* Configuration register, if the adjustment is not done, * remove them from the capabilities. */ - host->caps1 =sdhci_readl (host,SDHCI_CAPABILITIES_1 ); host->caps1 &= ~(SDHCI_SUPPORT_SDR50 |SDHCI_SUPPORT_DDR50 );dev_warn (&pdev->dev,"conf-sdio3 register not found: disabling SDR50 and DDR50 modes.\nConsider updating your dtb\n" );
@@ -161,7 +164,6 @@ static int armada_38x_quirks(struct plat* controller has different capabilities than the ones shown * in its registers */ - host->caps =sdhci_readl (host,SDHCI_CAPABILITIES );if (of_property_read_bool (np,"no-1-8-v" )) { host->caps &= ~SDHCI_CAN_VDD_180 ; host->mmc->caps &= ~MMC_CAP_1_8V_DDR ;
Greg Kroah-Hartman
maintainerPATCH 200/238 mmc: tegra: Disable UHS-I modes for tegra114
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jon Hunter <[email protected]>
commit 7bf037d6ac4768e228e337afd7b6c6d98f947f9f upstream.
SD card support for Tegra114 started failing after commit a8e326a911d3 ("mmc: tegra: implement module external clock change") was merged. This commit was part of a series to enable UHS-I modes for Tegra. To workaround this problem for now, disable UHS-I modes for Tegra114 by separating the soc data structures for Tegra114 and Tegra124 so that UHS-I is still enabled for Tegra124 but not Tegra114.
--- drivers/mmc/host/sdhci-tegra.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
drivers/mmc/host/sdhci-tegra.c +11 -1
@@ -147,10 +147,16 @@ static void tegra_sdhci_reset(struct sdh/* Advertise UHS modes as supported by host */ if (soc_data->nvquirks &NVQUIRK_ENABLE_SDR50 ) misc_ctrl |=SDHCI_MISC_CTRL_ENABLE_SDR50 ; +else + misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_SDR50 ;if (soc_data->nvquirks &NVQUIRK_ENABLE_DDR50 ) misc_ctrl |=SDHCI_MISC_CTRL_ENABLE_DDR50 ; +else + misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_DDR50 ;if (soc_data->nvquirks &NVQUIRK_ENABLE_SDR104 ) misc_ctrl |=SDHCI_MISC_CTRL_ENABLE_SDR104 ; +else + misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_SDR104 ;sdhci_writel (host, misc_ctrl,SDHCI_TEGRA_VENDOR_MISC_CTRL ); clk_ctrl =sdhci_readl (host,SDHCI_TEGRA_VENDOR_CLOCK_CTRL );
@@ -335,6 +341,10 @@ static const struct sdhci_pltfm_data sdhstatic const struct sdhci_tegra_soc_data soc_data_tegra114 = { .pdata = &sdhci_tegra114_pdata, +}; + +static const struct sdhci_tegra_soc_data soc_data_tegra124 = { + .pdata = &sdhci_tegra114_pdata, .nvquirks =NVQUIRK_ENABLE_SDR50 |NVQUIRK_ENABLE_DDR50 |NVQUIRK_ENABLE_SDR104 ,
@@ -357,7 +367,7 @@ static const struct sdhci_tegra_soc_datastatic const struct of_device_id sdhci_tegra_dt_match[] = { { .compatible ="nvidia,tegra210-sdhci" , .data = &soc_data_tegra210 }, - { .compatible ="nvidia,tegra124-sdhci" , .data = &soc_data_tegra114 }, + { .compatible ="nvidia,tegra124-sdhci" , .data = &soc_data_tegra124 }, { .compatible ="nvidia,tegra114-sdhci" , .data = &soc_data_tegra114 }, { .compatible ="nvidia,tegra30-sdhci" , .data = &soc_data_tegra30 }, { .compatible ="nvidia,tegra20-sdhci" , .data = &soc_data_tegra20 },
Greg Kroah-Hartman
maintainerPATCH 201/238 mmc: tegra: properly disable card clock
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lucas Stach <[email protected]>
commit 3491b69045b1926a198ba70dc1296ca253f2fbdd upstream.
The new code to do the clock rate setting externally to the SDMMC module has a shortcut to not propagate changes with a 0 rate to the CAR by simply bailing out. This breaks proper cutting of the card clock. Fix it by directly calling the correct sdhci function.
--- drivers/mmc/host/sdhci-tegra.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mmc/host/sdhci-tegra.c +1 -1
@@ -194,7 +194,7 @@ static void tegra_sdhci_set_clock(structunsigned long host_clk;if (!clock) -return ; +return sdhci_set_clock (host, clock); host_clk = tegra_host->ddr_signaling ? clock *2 : clock;clk_set_rate (pltfm_host->clk, host_clk);
Greg Kroah-Hartman
maintainerPATCH 202/238 mmc: sdhci: Fix override of timeout clk wrt max_busy_timeout
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit 995136247915c5cee633d55ba23f6eebf67aa567 upstream.
Normally the timeout clock frequency is read from the capabilities register. It is also possible to set the value prior to calling sdhci_add_host() in which case that value will override the capabilities register value. However that was being done after calculating max_busy_timeout so that max_busy_timeout was being calculated using the wrong value of timeout_clk.
Fix that by moving the override before max_busy_timeout is calculated.
The result is that the max_busy_timeout and max_discard increase for BSW devices so that, for example, the time for mkfs.ext4 on a 64GB eMMC drops from about 1 minute 40 seconds to about 20 seconds.
Note, in the future, the capabilities setting will be tidied up and this override won't be used anymore. However this fix is needed for stable.
--- drivers/mmc/host/sdhci.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/mmc/host/sdhci.c +3 -3
@@ -3096,14 +3096,14 @@ int sdhci_add_host(struct sdhci_host *hoif (caps[0 ] &SDHCI_TIMEOUT_CLK_UNIT ) host->timeout_clk *=1000 ; +if (override_timeout_clk) + host->timeout_clk = override_timeout_clk; + mmc->max_busy_timeout = host->ops->get_max_timeout_count ? host->ops->get_max_timeout_count (host) :1 <<27 ; mmc->max_busy_timeout /= host->timeout_clk; } -if (override_timeout_clk) - host->timeout_clk = override_timeout_clk; - mmc->caps |=MMC_CAP_SDIO_IRQ |MMC_CAP_ERASE |MMC_CAP_CMD23 ; mmc->caps2 |=MMC_CAP2_SDIO_IRQ_NOTHREAD ;
Greg Kroah-Hartman
maintainerPATCH 203/238 mmc: atmel-mci: Check pdata for NULL before dereferencing it at DMA config
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brent Taylor <[email protected]>
commit 93c77d2999b09f2084b033ea6489915e0104ad9c upstream.
Using an at91sam9g20ek development board with DTS configuration may trigger a kernel panic because of a NULL pointer dereference exception, while configuring DMA. Let's fix this by adding a check for pdata before dereferencing it.
--- drivers/mmc/host/atmel-mci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mmc/host/atmel-mci.c +1 -1
@@ -2443,7 +2443,7 @@ static int atmci_configure_dma(struct atstruct mci_platform_data *pdata = host->pdev->dev.platform_data;dma_cap_mask_t mask; -if (!pdata->dma_filter) +if (!pdata || !pdata->dma_filter)return -ENODEV ;dma_cap_zero (mask);
Greg Kroah-Hartman
maintainerPATCH 204/238 clk: rockchip: rk3368: fix cpuclk mux bit of big cpu-cluster
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Stuebner <[email protected]>
commit 535ebd428aeb07c3327947281306f2943f2c9faa upstream.
Both clusters have their mux bit in bit 7 of their respective register. For whatever reason the big cluster currently lists bit 15 which is definitly wrong.
--- drivers/clk/rockchip/clk-rk3368.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/rockchip/clk-rk3368.c +1 -1
@@ -165,7 +165,7 @@ static const struct rockchip_cpuclk_reg_ .core_reg = RK3368_CLKSEL_CON(0), .div_core_shift = 0, .div_core_mask = 0x1f, - .mux_core_shift = 15, + .mux_core_shift = 7, };static const struct rockchip_cpuclk_reg_data rk3368_cpuclkl_data = {
Greg Kroah-Hartman
maintainerPATCH 205/238 clk: rockchip: rk3368: fix cpuclk core dividers
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Stuebner <[email protected]>
commit c6d5fe2ca8286f35a79f7345c9378c39d48a1527 upstream.
Similar to commit 9880d4277f6a ("clk: rockchip: fix rk3288 cpuclk core dividers") it seems the cpuclk dividers are one to high on the rk3368 as well.
And again similar to the previous fix, we opt to make the divider list contain the values to be written to use the same paradigm for them on all supported socs.
--- drivers/clk/rockchip/clk-rk3368.c | 40 +++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 20 deletions(-)
drivers/clk/rockchip/clk-rk3368.c +20 -20
@@ -218,29 +218,29 @@ static const struct rockchip_cpuclk_reg_ }static struct rockchip_cpuclk_rate_table rk3368_cpuclkb_rates[]__initdata = { -RK3368_CPUCLKB_RATE (1512000000 ,2 ,6 ,6 ), -RK3368_CPUCLKB_RATE (1488000000 ,2 ,5 ,5 ), -RK3368_CPUCLKB_RATE (1416000000 ,2 ,5 ,5 ), -RK3368_CPUCLKB_RATE (1200000000 ,2 ,4 ,4 ), -RK3368_CPUCLKB_RATE (1008000000 ,2 ,4 ,4 ), -RK3368_CPUCLKB_RATE (816000000 ,2 ,3 ,3 ), -RK3368_CPUCLKB_RATE (696000000 ,2 ,3 ,3 ), -RK3368_CPUCLKB_RATE (600000000 ,2 ,2 ,2 ), -RK3368_CPUCLKB_RATE (408000000 ,2 ,2 ,2 ), -RK3368_CPUCLKB_RATE (312000000 ,2 ,2 ,2 ), +RK3368_CPUCLKB_RATE (1512000000 ,1 ,5 ,5 ), +RK3368_CPUCLKB_RATE (1488000000 ,1 ,4 ,4 ), +RK3368_CPUCLKB_RATE (1416000000 ,1 ,4 ,4 ), +RK3368_CPUCLKB_RATE (1200000000 ,1 ,3 ,3 ), +RK3368_CPUCLKB_RATE (1008000000 ,1 ,3 ,3 ), +RK3368_CPUCLKB_RATE (816000000 ,1 ,2 ,2 ), +RK3368_CPUCLKB_RATE (696000000 ,1 ,2 ,2 ), +RK3368_CPUCLKB_RATE (600000000 ,1 ,1 ,1 ), +RK3368_CPUCLKB_RATE (408000000 ,1 ,1 ,1 ), +RK3368_CPUCLKB_RATE (312000000 ,1 ,1 ,1 ), };static struct rockchip_cpuclk_rate_table rk3368_cpuclkl_rates[]__initdata = { -RK3368_CPUCLKL_RATE (1512000000 ,2 ,7 ,7 ), -RK3368_CPUCLKL_RATE (1488000000 ,2 ,6 ,6 ), -RK3368_CPUCLKL_RATE (1416000000 ,2 ,6 ,6 ), -RK3368_CPUCLKL_RATE (1200000000 ,2 ,5 ,5 ), -RK3368_CPUCLKL_RATE (1008000000 ,2 ,5 ,5 ), -RK3368_CPUCLKL_RATE (816000000 ,2 ,4 ,4 ), -RK3368_CPUCLKL_RATE (696000000 ,2 ,3 ,3 ), -RK3368_CPUCLKL_RATE (600000000 ,2 ,3 ,3 ), -RK3368_CPUCLKL_RATE (408000000 ,2 ,2 ,2 ), -RK3368_CPUCLKL_RATE (312000000 ,2 ,2 ,2 ), +RK3368_CPUCLKL_RATE (1512000000 ,1 ,6 ,6 ), +RK3368_CPUCLKL_RATE (1488000000 ,1 ,5 ,5 ), +RK3368_CPUCLKL_RATE (1416000000 ,1 ,5 ,5 ), +RK3368_CPUCLKL_RATE (1200000000 ,1 ,4 ,4 ), +RK3368_CPUCLKL_RATE (1008000000 ,1 ,4 ,4 ), +RK3368_CPUCLKL_RATE (816000000 ,1 ,3 ,3 ), +RK3368_CPUCLKL_RATE (696000000 ,1 ,2 ,2 ), +RK3368_CPUCLKL_RATE (600000000 ,1 ,2 ,2 ), +RK3368_CPUCLKL_RATE (408000000 ,1 ,1 ,1 ), +RK3368_CPUCLKL_RATE (312000000 ,1 ,1 ,1 ), };static struct rockchip_clk_branch rk3368_clk_branches[]__initdata = {
Greg Kroah-Hartman
maintainerPATCH 206/238 clk: rockchip: rk3368: fix parents of video encoder/decoder
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Stuebner <[email protected]>
commit 0f28d98463498c61c61a38aacbf9f69e92e85e9d upstream.
The vdpu and vepu clocks can also be parented to the npll and current parent list also is wrong as it would use the npll as "usbphy" source, so adapt the parent to the correct one.
--- drivers/clk/rockchip/clk-rk3368.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/clk/rockchip/clk-rk3368.c +2 -2
@@ -384,10 +384,10 @@ static struct rockchip_clk_branch rk3368* Clock-Architecture Diagram 3 */ -COMPOSITE (0 ,"aclk_vepu" , mux_pll_src_cpll_gpll_usb_p,0 , +COMPOSITE (0 ,"aclk_vepu" , mux_pll_src_cpll_gpll_npll_usb_p,0 ,RK3368_CLKSEL_CON (15 ),6 ,2 ,MFLAGS ,0 ,5 ,DFLAGS ,RK3368_CLKGATE_CON (4 ),6 ,GFLAGS ), -COMPOSITE (0 ,"aclk_vdpu" , mux_pll_src_cpll_gpll_usb_p,0 , +COMPOSITE (0 ,"aclk_vdpu" , mux_pll_src_cpll_gpll_npll_usb_p,0 ,RK3368_CLKSEL_CON (15 ),14 ,2 ,MFLAGS ,8 ,5 ,DFLAGS , RK3368_CLKGATE_CON(4), 7, GFLAGS),
Greg Kroah-Hartman
maintainerPATCH 207/238 clk: rockchip: rk3368: fix hdmi_cec gate-register
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Stuebner <[email protected]>
commit fd0c0740fac17a014704ef89d8c8b1768711ca59 upstream.
Fix a typo making the sclk_hdmi_cec access a wrong register to handle its gate.
--- drivers/clk/rockchip/clk-rk3368.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/rockchip/clk-rk3368.c +1 -1
@@ -442,7 +442,7 @@ static struct rockchip_clk_branch rk3368GATE (SCLK_HDMI_HDCP ,"sclk_hdmi_hdcp" ,"xin24m" ,0 ,RK3368_CLKGATE_CON (4 ),13 ,GFLAGS ),GATE (SCLK_HDMI_CEC ,"sclk_hdmi_cec" ,"xin32k" ,0 , -RK3368_CLKGATE_CON (5 ),12 ,GFLAGS ), +RK3368_CLKGATE_CON (4 ),12 ,GFLAGS ), COMPOSITE_NODIV(0, "vip_src", mux_pll_src_cpll_gpll_p, 0, RK3368_CLKSEL_CON(21), 15, 1, MFLAGS,
Greg Kroah-Hartman
maintainerPATCH 208/238 clk: rockchip: add hclk_cpubus to the list of rk3188 critical clocks
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Kochetkov <[email protected]>
commit e8b63288b37dbb8457b510c9d96f6006da4653f6 upstream.
hclk_cpubus needs to keep running because it is needed for devices like the rom, i2s0 or spdif to be accessible via cpu. Without that all accesses to devices (readl/writel) return wrong data. So add it to the list of critical clocks.
--- drivers/clk/rockchip/clk-rk3188.c | 1 + 1 file changed, 1 insertion(+)
drivers/clk/rockchip/clk-rk3188.c +1 -0
@@ -748,6 +748,7 @@ static const char *const rk3188_critical"hclk_peri" ,"pclk_cpu" ,"pclk_peri" , + "hclk_cpubus" };static void __init rk3188_common_clk_init (struct device_node *np)
Greg Kroah-Hartman
maintainerPATCH 209/238 clk: bcm2835: Fix setting of PLL divider clock rates
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Anholt <[email protected]>
commit 773b3966dd3cdaeb68e7f2edfe5656abac1dc411 upstream.
Our dividers weren't being set successfully because CM_PASSWORD wasn't included in the register write. It looks easier to just compute the divider to write ourselves than to update clk-divider for the ability to OR in some arbitrary bits on write.
Fixes about half of the video modes on my HDMI monitor (everything except 720x400).
--- drivers/clk/bcm/clk-bcm2835.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
drivers/clk/bcm/clk-bcm2835.c +7 -5
@@ -1107,13 +1107,15 @@ static int bcm2835_pll_divider_set_rate(struct bcm2835_pll_divider *divider =bcm2835_pll_divider_from_hw (hw);struct bcm2835_cprman *cprman = divider->cprman;const struct bcm2835_pll_divider_data *data = divider->data; -u32 cm; -int ret; +u32 cm, div, max_div =1 <<A2W_PLL_DIV_BITS ; - ret = clk_divider_ops.set_rate (hw, rate, parent_rate); -if (ret) -return ret; + div =DIV_ROUND_UP_ULL (parent_rate, rate); + div =min (div, max_div); +if (div == max_div) + div =0 ; + +cprman_write (cprman, data->a2w_reg, div); cm =cprman_read (cprman, data->cm_reg);cprman_write (cprman, data->cm_reg, cm | data->load_mask);cprman_write (cprman, data->cm_reg, cm & ~data->load_mask);
Greg Kroah-Hartman
maintainerPATCH 210/238 target: Fix target_release_cmd_kref shutdown comp leak
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Himanshu Madhani <[email protected]>
commit 5e47f1985d7107331c3f64fb3ec83d66fd73577e upstream.
This patch fixes an active I/O shutdown bug for fabric drivers using target_wait_for_sess_cmds(), where se_cmd descriptor shutdown would result in hung tasks waiting indefinitely for se_cmd->cmd_wait_comp to complete().
To address this bug, drop the incorrect list_del_init() usage in target_wait_for_sess_cmds() and always complete() during se_cmd target_release_cmd_kref() put, in order to let caller invoke the final fabric release callback into se_cmd->se_tfo->release_cmd() code.
--- drivers/target/target_core_transport.c | 2 -- 1 file changed, 2 deletions(-)
drivers/target/target_core_transport.c +0 -2
@@ -2596,8 +2596,6 @@ void target_wait_for_sess_cmds(struct selist_for_each_entry_safe (se_cmd, tmp_cmd, &se_sess->sess_wait_list, se_cmd_list) { -list_del_init (&se_cmd->se_cmd_list); -pr_debug ("Waiting for se_cmd: %p t_state: %d, fabric state:" " %d\n" , se_cmd, se_cmd->t_state, se_cmd->se_tfo->get_cmd_state (se_cmd));
Greg Kroah-Hartman
maintainerPATCH 211/238 iser-target: Fix identification of login rx descriptor type
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jenny Derzhavetz <[email protected]>
commit b89a7c25462b164db280abc3b05d4d9d888d40e9 upstream.
Once connection request is accepted, one rx descriptor is posted to receive login request. This descriptor has rx type, but is outside the main pool of rx descriptors, and thus was mistreated as tx type.
--- drivers/infiniband/ulp/isert/ib_isert.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/infiniband/ulp/isert/ib_isert.c +2 -1
@@ -2048,7 +2048,8 @@ is_isert_tx_desc(struct isert_conn *iservoid *start = isert_conn->rx_descs;int len =ISERT_QP_MAX_RECV_DTOS *sizeof (*isert_conn->rx_descs); -if (wr_id >= start && wr_id < start + len) +if ((wr_id >= start && wr_id < start + len) || + (wr_id == isert_conn->login_req_buf))return false;return true;
Greg Kroah-Hartman
maintainerPATCH 212/238 iser-target: Add new state ISER_CONN_BOUND to isert_conn
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jenny Derzhavetz <[email protected]>
commit aea92980601f7ddfcb3c54caa53a43726314fe46 upstream.
We need an indication that isert_conn->iscsi_conn binding has happened so we'll know not to invoke a connection reinstatement on an unbound connection which will lead to a bogus isert_conn->conn dereferece.
--- drivers/infiniband/ulp/isert/ib_isert.c | 7 +++++-- drivers/infiniband/ulp/isert/ib_isert.h | 1 + 2 files changed, 6 insertions(+), 2 deletions(-)
drivers/infiniband/ulp/isert/ib_isert.c +5 -2
@@ -825,7 +825,7 @@ isert_put_conn(struct isert_conn *isert_* @isert_conn: isert connection struct * * Notes: -* In case the connection state is FULL_FEATURE, move state +* In case the connection state is BOUND, move state * to TEMINATING and start teardown sequence (rdma_disconnect). * In case the connection state is UP, complete flush as well. *
@@ -841,6 +841,7 @@ isert_conn_terminate(struct isert_conn *case ISER_CONN_TERMINATING :break ;case ISER_CONN_UP : +case ISER_CONN_BOUND :case ISER_CONN_FULL_FEATURE :/* FALLTHRU */ isert_info ("Terminating conn %p state %d\n" , isert_conn, isert_conn->state);
@@ -2075,7 +2076,8 @@ isert_cq_comp_err(struct isert_conn *iseisert_completion_put (desc, isert_cmd, ib_dev, true); }else { isert_conn->post_recv_buf_count--; -if (!isert_conn->post_recv_buf_count) +if (!isert_conn->post_recv_buf_count && + isert_conn->state >=ISER_CONN_BOUND )iscsit_cause_connection_reinstatement (isert_conn->conn,0 ); } }
@@ -3215,6 +3217,7 @@ accept_wait: conn->context = isert_conn; isert_conn->conn = conn; + isert_conn->state =ISER_CONN_BOUND ;isert_set_conn_info (np, conn, isert_conn);
drivers/infiniband/ulp/isert/ib_isert.h +1 -0
@@ -84,6 +84,7 @@ enum iser_ib_op_code {enum iser_conn_state {ISER_CONN_INIT ,ISER_CONN_UP , +ISER_CONN_BOUND ,ISER_CONN_FULL_FEATURE ,ISER_CONN_TERMINATING ,ISER_CONN_DOWN ,
Greg Kroah-Hartman
maintainerPATCH 213/238 iser-target: Separate flows for np listeners and connections cma events
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jenny Derzhavetz <[email protected]>
commit f81bf458208ef6d12b2fc08091204e3859dcdba4 upstream.
No need to restrict this check to specific events.
--- drivers/infiniband/ulp/isert/ib_isert.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)
drivers/infiniband/ulp/isert/ib_isert.c +5 -6
@@ -889,14 +889,9 @@ isert_disconnected_handler(struct rdma_c enum rdma_cm_event_type event) {struct isert_np *isert_np = cma_id->context; -struct isert_conn *isert_conn; +struct isert_conn *isert_conn = cma_id->qp->qp_context;bool terminating = false; -if (isert_np->cm_id == cma_id) -return isert_np_cma_handler (cma_id->context, event); - - isert_conn = cma_id->qp->qp_context; -mutex_lock (&isert_conn->mutex); terminating = (isert_conn->state ==ISER_CONN_TERMINATING );isert_conn_terminate (isert_conn);
@@ -935,12 +930,16 @@ isert_connect_error(struct rdma_cm_id *cstatic int isert_cma_handler (struct rdma_cm_id *cma_id,struct rdma_cm_event *event) { +struct isert_np *isert_np = cma_id->context;int ret =0 ;isert_info ("%s (%d): status %d id %p np %p\n" ,rdma_event_msg (event->event), event->event, event->status, cma_id, cma_id->context); +if (isert_np->cm_id == cma_id) +return isert_np_cma_handler (cma_id->context, event->event); +switch (event->event) {case RDMA_CM_EVENT_CONNECT_REQUEST : ret =isert_connect_request (cma_id, event);
Greg Kroah-Hartman
maintainerPATCH 214/238 iser-target: Rework connection termination
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jenny Derzhavetz <[email protected]>
commit 6d1fba0c2cc7efe42fd761ecbba833ed0ea7b07e upstream.
When we receive an event that triggers connection termination,
we have a a couple of things we may want to do:
1. In case we are already terminating, bailout early
2. In case we are connected but not bound, disconnect and schedule a connection cleanup silently (don't reinstate)
3. In case we are connected and bound, disconnect and reinstate the connection
This rework fixes a bug that was detected against a mis-behaved initiator which rejected our rdma_cm accept, in this stage the isert_conn is no bound and reinstate caused a bogus dereference.
What's great about this is that we don't need thepost_recv_buf_count anymore, so get rid of it.
--- drivers/infiniband/ulp/isert/ib_isert.c | 107 +++++++++++++++----------------- drivers/infiniband/ulp/isert/ib_isert.h | 1 2 files changed, 52 insertions(+), 56 deletions(-)
drivers/infiniband/ulp/isert/ib_isert.c +52 -55
@@ -65,6 +65,7 @@ isert_rdma_accept(struct isert_conn *isestruct rdma_cm_id *isert_setup_id (struct isert_np *isert_np);static void isert_release_work (struct work_struct *work); +static void isert_wait4flush (struct isert_conn *isert_conn);static inline bool isert_prot_cmd (struct isert_conn *conn,struct se_cmd *cmd)
@@ -820,6 +821,25 @@ isert_put_conn(struct isert_conn *isert_kref_put (&isert_conn->kref, isert_release_kref); } +static void +isert_handle_unbound_conn (struct isert_conn *isert_conn) +{ +struct isert_np *isert_np = isert_conn->cm_id->context; + +mutex_lock (&isert_np->mutex); +if (!list_empty (&isert_conn->node)) { +/* +* This means iscsi doesn't know this connection +* so schedule a cleanup ourselves +*/ +list_del_init (&isert_conn->node); +isert_put_conn (isert_conn); +complete (&isert_conn->wait); +queue_work (isert_release_wq, &isert_conn->release_work); + } +mutex_unlock (&isert_np->mutex); +} +/** * isert_conn_terminate() - Initiate connection termination * @isert_conn: isert connection struct
@@ -837,24 +857,19 @@ isert_conn_terminate(struct isert_conn * {int err; -switch (isert_conn->state) { -case ISER_CONN_TERMINATING : -break ; -case ISER_CONN_UP : -case ISER_CONN_BOUND : -case ISER_CONN_FULL_FEATURE :/* FALLTHRU */ -isert_info ("Terminating conn %p state %d\n" , - isert_conn, isert_conn->state); - isert_conn->state =ISER_CONN_TERMINATING ; - err =rdma_disconnect (isert_conn->cm_id); -if (err) -isert_warn ("Failed rdma_disconnect isert_conn %p\n" , - isert_conn); -break ; -default : -isert_warn ("conn %p teminating in state %d\n" , - isert_conn, isert_conn->state); - } +if (isert_conn->state >=ISER_CONN_TERMINATING ) +return ; + +isert_info ("Terminating conn %p state %d\n" , + isert_conn, isert_conn->state); + isert_conn->state =ISER_CONN_TERMINATING ; + err =rdma_disconnect (isert_conn->cm_id); +if (err) +isert_warn ("Failed rdma_disconnect isert_conn %p\n" , + isert_conn); + +isert_info ("conn %p completing wait\n" , isert_conn); +complete (&isert_conn->wait); } static int
@@ -888,30 +903,27 @@ static int isert_disconnected_handler(struct rdma_cm_id *cma_id, enum rdma_cm_event_type event) { - struct isert_np *isert_np = cma_id->context; struct isert_conn *isert_conn = cma_id->qp->qp_context; -bool terminating = false;mutex_lock (&isert_conn->mutex); - terminating = (isert_conn->state ==ISER_CONN_TERMINATING ); -isert_conn_terminate (isert_conn); -mutex_unlock (&isert_conn->mutex); - -isert_info ("conn %p completing wait\n" , isert_conn); -complete (&isert_conn->wait); - -if (terminating) - goto out; - -mutex_lock (&isert_np->mutex); -if (!list_empty (&isert_conn->node)) { -list_del_init (&isert_conn->node); -isert_put_conn (isert_conn); -queue_work (isert_release_wq, &isert_conn->release_work); +switch (isert_conn->state) { +case ISER_CONN_TERMINATING : +break ; +case ISER_CONN_UP : +isert_conn_terminate (isert_conn); +isert_wait4flush (isert_conn); +isert_handle_unbound_conn (isert_conn); +break ; +case ISER_CONN_BOUND : +case ISER_CONN_FULL_FEATURE :/* FALLTHRU */ +iscsit_cause_connection_reinstatement (isert_conn->conn,0 ); +break ; +default : +isert_warn ("conn %p teminating in state %d\n" , + isert_conn, isert_conn->state); } -mutex_unlock (&isert_np->mutex); +mutex_unlock (&isert_conn->mutex); -out:return 0 ; }
@@ -985,13 +997,10 @@ isert_post_recvm(struct isert_conn *iser rx_wr--; rx_wr->next =NULL ;/* mark end of work requests list */ - isert_conn->post_recv_buf_count += count; ret =ib_post_recv (isert_conn->qp, isert_conn->rx_wr, &rx_wr_failed); -if (ret) { +if (ret)isert_err ("ib_post_recv() failed with ret: %d\n" , ret); - isert_conn->post_recv_buf_count -= count; - }return ret; }
@@ -1007,12 +1016,9 @@ isert_post_recv(struct isert_conn *isert rx_wr.num_sge =1 ; rx_wr.next =NULL ; - isert_conn->post_recv_buf_count++; ret =ib_post_recv (isert_conn->qp, &rx_wr, &rx_wr_failed); -if (ret) { +if (ret)isert_err ("ib_post_recv() failed with ret: %d\n" , ret); - isert_conn->post_recv_buf_count--; - }return ret; }
@@ -1132,12 +1138,9 @@ isert_rdma_post_recvl(struct isert_conn rx_wr.sg_list = &sge; rx_wr.num_sge =1 ; - isert_conn->post_recv_buf_count++; ret =ib_post_recv (isert_conn->qp, &rx_wr, &rx_wr_fail); -if (ret) { +if (ret)isert_err ("ib_post_recv() failed: %d\n" , ret); - isert_conn->post_recv_buf_count--; - }return ret; }
@@ -1633,7 +1636,6 @@ isert_rcv_completion(struct iser_rx_descib_dma_sync_single_for_device (ib_dev, rx_dma, rx_buflen,DMA_FROM_DEVICE ); - isert_conn->post_recv_buf_count--; } static int
@@ -2073,11 +2075,6 @@ isert_cq_comp_err(struct isert_conn *iseisert_unmap_tx_desc (desc, ib_dev); elseisert_completion_put (desc ,isert_cmd ,ib_dev ,true ); - }else { - isert_conn->post_recv_buf_count--; -if (!isert_conn->post_recv_buf_count && - isert_conn->state >=ISER_CONN_BOUND ) -iscsit_cause_connection_reinstatement (isert_conn->conn,0 ); } }
drivers/infiniband/ulp/isert/ib_isert.h +0 -1
@@ -180,7 +180,6 @@ struct isert_device;struct isert_conn {enum iser_conn_state state; -int post_recv_buf_count;u32 responder_resources;u32 initiator_depth;bool pi_support;
Greg Kroah-Hartman
maintainerPATCH 215/238 nfsd4: fix bad bounds checking
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: J. Bruce Fields <[email protected]>
commit 4aed9c46afb80164401143aa0fdcfe3798baa9d5 upstream.
A number of spots in the xdr decoding follow a pattern like
n = be32_to_cpup(p++); READ_BUF(n + 4);
where n is a u32. The only bounds checking is done in READ_BUF itself, but since it's checking (n + 4), it won't catch cases where n is very large, (u32)(-4) or higher. I'm not sure exactly what the consequences are, but we've seen crashes soon after.
Instead, just break these up into two READ_BUF()s.
--- fs/nfsd/nfs4xdr.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
fs/nfsd/nfs4xdr.c +8 -5
@@ -1072,8 +1072,9 @@ nfsd4_decode_rename(struct nfsd4_compounREAD_BUF (4 ); rename->rn_snamelen =be32_to_cpup (p++); -READ_BUF (rename->rn_snamelen +4 ); +READ_BUF (rename->rn_snamelen);SAVEMEM (rename->rn_sname, rename->rn_snamelen); +READ_BUF (4 ); rename->rn_tnamelen =be32_to_cpup (p++);READ_BUF (rename->rn_tnamelen);SAVEMEM (rename->rn_tname, rename->rn_tnamelen);
@@ -1155,13 +1156,14 @@ nfsd4_decode_setclientid(struct nfsd4_coREAD_BUF (8 ); setclientid->se_callback_prog =be32_to_cpup (p++); setclientid->se_callback_netid_len =be32_to_cpup (p++); - -READ_BUF (setclientid->se_callback_netid_len +4 ); +READ_BUF (setclientid->se_callback_netid_len);SAVEMEM (setclientid->se_callback_netid_val, setclientid->se_callback_netid_len); +READ_BUF (4 ); setclientid->se_callback_addr_len =be32_to_cpup (p++); -READ_BUF (setclientid->se_callback_addr_len +4 ); +READ_BUF (setclientid->se_callback_addr_len);SAVEMEM (setclientid->se_callback_addr_val, setclientid->se_callback_addr_len); +READ_BUF (4 ); setclientid->se_callback_ident =be32_to_cpup (p++);DECODE_TAIL ;
@@ -1835,8 +1837,9 @@ nfsd4_decode_compound(struct nfsd4_compoREAD_BUF (4 ); argp->taglen =be32_to_cpup (p++); -READ_BUF (argp->taglen +8 ); +READ_BUF (argp->taglen);SAVEMEM (argp->tag, argp->taglen); +READ_BUF (8 ); argp->minorversion =be32_to_cpup (p++); argp->opcnt =be32_to_cpup (p++); max_reply +=4 + (XDR_QUADLEN (argp->taglen) <<2 );
Greg Kroah-Hartman
maintainerPATCH 216/238 nfsd: fix deadlock secinfo+readdir compound
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: J. Bruce Fields <[email protected]>
commit 2f6fc056e899bd0144a08da5cacaecbe8997cd74 upstream.
nfsd_lookup_dentry exits with the parent filehandle locked. fh_put also unlocks if necessary (nfsd filehandle locking is probably too lenient), so it gets unlocked eventually, but if the following op in the compound needs to lock it again, we can deadlock.
A fuzzer ran into this; normal clients don't send a secinfo followed by a readdir in the same compound.
--- fs/nfsd/nfs4proc.c | 1 + 1 file changed, 1 insertion(+)
fs/nfsd/nfs4proc.c +1 -0
@@ -878,6 +878,7 @@ nfsd4_secinfo(struct svc_rqst *rqstp, st &exp, &dentry);if (err)return err; +fh_unlock (&cstate->current_fh);if (d_really_is_negative (dentry)) {exp_put (exp); err = nfserr_noent;
Greg Kroah-Hartman
maintainerPATCH 217/238 ARM: dts: at91: sama5d3 Xplained: dont disable hsmci regulator
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ludovic Desroches <[email protected]>
commit ae3fc8ea08e405682f1fa959f94b6e4126afbc1b upstream.
If enabling the hsmci regulator on card detection, the board can reboot on sd card insertion. Keeping the regulator always enabled fixes this issue.
--- arch/arm/boot/dts/at91-sama5d3_xplained.dts | 1 + 1 file changed, 1 insertion(+)
arch/arm/boot/dts/at91-sama5d3_xplained.dts +1 -0
@@ -303,6 +303,7 @@ regulator-name = "mmc0-card-supply"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; + regulator-always-on; }; gpio_keys {
Greg Kroah-Hartman
maintainerPATCH 218/238 ARM: dts: at91: sama5d4 Xplained: dont disable hsmci regulator
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ludovic Desroches <[email protected]>
commit b02acd4e62602a6ab307da84388a16bf60106c48 upstream.
If enabling the hsmci regulator on card detection, the board can reboot on sd card insertion. Keeping the regulator always enabled fixes this issue.
--- arch/arm/boot/dts/at91-sama5d4_xplained.dts | 1 + 1 file changed, 1 insertion(+)
arch/arm/boot/dts/at91-sama5d4_xplained.dts +1 -0
@@ -268,5 +268,6 @@ regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; vin-supply = <&vcc_3v3_reg>; + regulator-always-on; }; };
Greg Kroah-Hartman
maintainerPATCH 219/238 ACPI / PM: Runtime resume devices when waking from hibernate
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Wunner <[email protected]>
commit fbda4b38fa3995aa0777fe9cbbdcb223c6292083 upstream.
Commit 58a1fbbb2ee8 ("PM / PCI / ACPI: Kick devices that might have been reset by firmware") added a runtime resume for devices that were runtime suspended when the system entered suspend-to-RAM.
Briefly, the motivation was to ensure that devices did not remain in a reset-power-on state after resume, potentially preventing deep SoC-wide low-power states from being entered on idle.
Currently we're not doing the same when leaving suspend-to-disk and this asymmetry is a problem if drivers rely on the automatic resume triggered by pm_complete_with_resume_check(). Fix it.
--- drivers/acpi/sleep.c | 1 + 1 file changed, 1 insertion(+)
drivers/acpi/sleep.c +1 -0
@@ -714,6 +714,7 @@ static int acpi_hibernation_enter(void)static void acpi_hibernation_leave (void ) { +pm_set_resume_via_firmware ();/* * If ACPI is not enabled by the BIOS and the boot kernel, we need to * enable it here.
Greg Kroah-Hartman
maintainerPATCH 220/238 writeback, cgroup: fix premature wb_put() in locked_inode_to_wb_and_lock_list()
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit 614a4e3773148a31f58dc174bbf578ceb63510c2 upstream.
locked_inode_to_wb_and_lock_list() wb_get()'s the wb associated with the target inode, unlocks inode, locks the wb's list_lock and verifies that the inode is still associated with the wb. To prevent the wb going away between dropping inode lock and acquiring list_lock, the wb is pinned while inode lock is held. The wb reference is put right after acquiring list_lock citing that the wb won't be dereferenced anymore.
This isn't true. If the inode is still associated with the wb, the inode has reference and it's safe to return the wb; however, if inode has been switched, the wb still needs to be unlocked which is a dereference and can lead to use-after-free if it it races with wb destruction.
Fix it by putting the reference after releasing list_lock.
--- fs/fs-writeback.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
fs/fs-writeback.c +5 -3
@@ -281,13 +281,15 @@ locked_inode_to_wb_and_lock_list(structwb_get (wb);spin_unlock (&inode->i_lock);spin_lock (&wb->list_lock); -wb_put (wb);/* not gonna deref it anymore */ /* i_wb may have changed inbetween, can't use inode_to_wb() */ -if (likely (wb == inode->i_wb)) -return wb;/* @inode already has ref */ +if (likely (wb == inode->i_wb)) { +wb_put (wb);/* @inode already has ref */ +return wb; + }spin_unlock (&wb->list_lock); +wb_put (wb);cpu_relax ();spin_lock (&inode->i_lock); }
Greg Kroah-Hartman
maintainerPATCH 221/238 writeback, cgroup: fix use of the wrong bdi_writeback which mismatches the inode
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit aaf2559332ba272671bb870464a99b909b29a3a1 upstream.
When cgroup writeback is in use, there can be multiple wb's (bdi_writeback's) per bdi and an inode may switch among them dynamically. In a couple places, the wrong wb was used leading to performing operations on the wrong list under the wrong lock corrupting the io lists.
* writeback_single_inode() was taking @wb parameter and used it to remove the inode from io lists if it becomes clean after writeback. The callers of this function were always passing in the root wb regardless of the actual wb that the inode was associated with, which could also change while writeback is in progress.
Fix it by dropping the @wb parameter and using inode_to_wb_and_lock_list() to determine and lock the associated wb.
* After writeback_sb_inodes() writes out an inode, it re-locks @wb and inode to remove it from or move it to the right io list. It assumes that the inode is still associated with @wb; however, the inode may have switched to another wb while writeback was in progress.
Fix it by using inode_to_wb_and_lock_list() to determine and lock the associated wb after writeback is complete. As the function requires the original @wb->list_lock locked for the next iteration, in the unlikely case where the inode has changed association, switch the locks.
Kudos to Tahsin for pinpointing these subtle breakages.
--- fs/fs-writeback.c | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-)
fs/fs-writeback.c +19 -10
@@ -1339,10 +1339,10 @@ __writeback_single_inode(struct inode *i* we go e.g. from filesystem. Flusher thread uses __writeback_single_inode() * and does more profound writeback list handling in writeback_sb_inodes(). */ -static int -writeback_single_inode (struct inode *inode,struct bdi_writeback *wb, -struct writeback_control *wbc) +static int writeback_single_inode (struct inode *inode, +struct writeback_control *wbc) { +struct bdi_writeback *wb;int ret =0 ;spin_lock (&inode->i_lock);
@@ -1380,7 +1380,8 @@ writeback_single_inode(struct inode *ino ret =__writeback_single_inode (inode, wbc);wbc_detach_inode (wbc); -spin_lock (&wb->list_lock); + + wb =inode_to_wb_and_lock_list (inode);spin_lock (&inode->i_lock);/* * If inode is clean, remove it from writeback lists. Otherwise don't
@@ -1455,6 +1456,7 @@ static long writeback_sb_inodes(struct swhile (!list_empty (&wb->b_io)) {struct inode *inode =wb_inode (wb->b_io.prev); +struct bdi_writeback *tmp_wb;if (inode->i_sb != sb) {if (work->sb) {
@@ -1545,15 +1547,23 @@ static long writeback_sb_inodes(struct scond_resched (); } - -spin_lock (&wb->list_lock); +/* +* Requeue @inode if still dirty. Be careful as @inode may +* have been switched to another wb in the meantime. +*/ + tmp_wb =inode_to_wb_and_lock_list (inode);spin_lock (&inode->i_lock);if (!(inode->i_state &I_DIRTY_ALL )) wrote++; -requeue_inode (inode, wb, &wbc); +requeue_inode (inode, tmp_wb, &wbc);inode_sync_complete (inode);spin_unlock (&inode->i_lock); +if (unlikely (tmp_wb != wb)) { +spin_unlock (&tmp_wb->list_lock); +spin_lock (&wb->list_lock); + } +/* * bail out to wb_writeback() often enough to check * background threshold and other termination conditions.
@@ -2340,7 +2350,6 @@ EXPORT_SYMBOL(sync_inodes_sb);*/ int write_inode_now (struct inode *inode,int sync) { -struct bdi_writeback *wb = &inode_to_bdi (inode)->wb;struct writeback_control wbc = { .nr_to_write =LONG_MAX , .sync_mode = sync ?WB_SYNC_ALL :WB_SYNC_NONE ,
@@ -2352,7 +2361,7 @@ int write_inode_now(struct inode *inode, wbc.nr_to_write =0 ;might_sleep (); -return writeback_single_inode (inode, wb, &wbc); +return writeback_single_inode (inode, &wbc); }EXPORT_SYMBOL (write_inode_now);
@@ -2369,7 +2378,7 @@ EXPORT_SYMBOL(write_inode_now);*/ int sync_inode (struct inode *inode,struct writeback_control *wbc) { -return writeback_single_inode (inode, &inode_to_bdi (inode)->wb, wbc); +return writeback_single_inode (inode, wbc); }EXPORT_SYMBOL (sync_inode);
Greg Kroah-Hartman
maintainerPATCH 222/238 Input: synaptics - handle spurious release of trackstick buttons, again
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Tissoires <[email protected]>
commit 82be788c96ed5978d3cb4a00079e26b981a3df3f upstream.
Looks like the fimware 8.2 still has the extra buttons spurious release bug.
--- drivers/input/mouse/synaptics.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/input/mouse/synaptics.c +3 -2
@@ -862,8 +862,9 @@ static void synaptics_report_ext_buttonsif (!SYN_CAP_MULTI_BUTTON_NO (priv->ext_cap))return ; -/* Bug in FW 8.1, buttons are reported only when ExtBit is 1 */ -if (SYN_ID_FULL (priv->identity) ==0x801 && +/* Bug in FW 8.1 & 8.2, buttons are reported only when ExtBit is 1 */ +if ((SYN_ID_FULL (priv->identity) ==0x801 || +SYN_ID_FULL (priv->identity) ==0x802 ) && !((psmouse->packet[0 ] ^ psmouse->packet[3 ]) &0x02 ))return ;
Greg Kroah-Hartman
maintainerPATCH 223/238 Input: ims-pcu - sanity check against missing interfaces
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <[email protected]>
commit a0ad220c96692eda76b2e3fd7279f3dcd1d8a8ff upstream.
A malicious device missing interface can make the driver oops. Add sanity checking.
--- drivers/input/misc/ims-pcu.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/input/misc/ims-pcu.c +4 -0
@@ -1663,6 +1663,8 @@ static int ims_pcu_parse_cdc_data(struct pcu->ctrl_intf =usb_ifnum_to_if (pcu->udev, union_desc->bMasterInterface0); +if (!pcu->ctrl_intf) +return -EINVAL ; alt = pcu->ctrl_intf->cur_altsetting; pcu->ep_ctrl = &alt->endpoint[0 ].desc;
@@ -1670,6 +1672,8 @@ static int ims_pcu_parse_cdc_data(struct pcu->data_intf =usb_ifnum_to_if (pcu->udev, union_desc->bSlaveInterface0); +if (!pcu->data_intf) +return -EINVAL ; alt = pcu->data_intf->cur_altsetting;if (alt->desc.bNumEndpoints !=2 ) {
Greg Kroah-Hartman
maintainerPATCH 224/238 Input: ati_remote2 - fix crashes on detecting device with invalid descriptor
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladis Dronov <[email protected]>
commit 950336ba3e4a1ffd2ca60d29f6ef386dd2c7351d upstream.
The ati_remote2 driver expects at least two interfaces with one endpoint each. If given malicious descriptor that specify one interface or no endpoints, it will crash in the probe function. Ensure there is at least two interfaces and one endpoint for each interface before using it.
The full disclosure: http://seclists.org/bugtraq/2016/Mar/90
--- drivers/input/misc/ati_remote2.c | 36 ++++++++++++++++++++++++++++++------ 1 file changed, 30 insertions(+), 6 deletions(-)
drivers/input/misc/ati_remote2.c +30 -6
@@ -817,26 +817,49 @@ static int ati_remote2_probe(struct usb_ ar2->udev = udev; +/* Sanity check, first interface must have an endpoint */ +if (alt->desc.bNumEndpoints <1 || !alt->endpoint) { +dev_err (&interface->dev, +"%s(): interface 0 must have an endpoint\n" , __func__); + r = -ENODEV ; + goto fail1; + } ar2->intf[0 ] = interface; ar2->ep[0 ] = &alt->endpoint[0 ].desc; +/* Sanity check, the device must have two interfaces */ ar2->intf[1 ] =usb_ifnum_to_if (udev,1 ); +if ((udev->actconfig->desc.bNumInterfaces <2 ) || !ar2->intf[1 ]) { +dev_err (&interface->dev,"%s(): need 2 interfaces, found %d\n" , + __func__, udev->actconfig->desc.bNumInterfaces); + r = -ENODEV ; + goto fail1; + } + r =usb_driver_claim_interface (&ati_remote2_driver, ar2->intf[1 ], ar2);if (r) goto fail1; + +/* Sanity check, second interface must have an endpoint */ alt = ar2->intf[1 ]->cur_altsetting; +if (alt->desc.bNumEndpoints <1 || !alt->endpoint) { +dev_err (&interface->dev, +"%s(): interface 1 must have an endpoint\n" , __func__); + r = -ENODEV ; + goto fail2; + } ar2->ep[1 ] = &alt->endpoint[0 ].desc; r =ati_remote2_urb_init (ar2);if (r) - goto fail2; + goto fail3; ar2->channel_mask = channel_mask; ar2->mode_mask = mode_mask; r =ati_remote2_setup (ar2, ar2->channel_mask);if (r) - goto fail2; + goto fail3;usb_make_path (udev, ar2->phys,sizeof (ar2->phys));strlcat (ar2->phys,"/input0" ,sizeof (ar2->phys));
@@ -845,11 +868,11 @@ static int ati_remote2_probe(struct usb_ r =sysfs_create_group (&udev->dev.kobj, &ati_remote2_attr_group);if (r) - goto fail2; + goto fail3; r =ati_remote2_input_init (ar2);if (r) - goto fail3; + goto fail4;usb_set_intfdata (interface, ar2);
@@ -857,10 +880,11 @@ static int ati_remote2_probe(struct usb_return 0 ; - fail3: + fail4:sysfs_remove_group (&udev->dev.kobj, &ati_remote2_attr_group); - fail2: + fail3:ati_remote2_urb_cleanup (ar2); + fail2:usb_driver_release_interface (&ati_remote2_driver, ar2->intf[1 ]); fail1:kfree (ar2);
Greg Kroah-Hartman
maintainerPATCH 225/238 ocfs2: o2hb: fix double free bug
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junxiao Bi <[email protected]>
commit 9e13f1f9de1cb143fbae6f1170f26c8544b64cff upstream.
This is a regression issue and caused the following kernel panic when do ocfs2 multiple test.
BUG: unable to handle kernel paging request at 00000002000800c0
IP: [<ffffffff81192978>] kmem_cache_alloc+0x78/0x160
PGD 7bbe5067 PUD 0
Oops: 0000 [#1] SMP
Modules linked in: ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi xen_kbdfront xen_netfront xen_fbfront xen_blkfront
CPU: 2 PID: 4044 Comm: mpirun Not tainted 4.5.0-rc5-next-20160225 #1
Hardware name: Xen HVM domU, BIOS 4.3.1OVM 05/14/2014
task: ffff88007a521a80 ti: ffff88007aed0000 task.ti: ffff88007aed0000
RIP: 0010:[<ffffffff81192978>] [<ffffffff81192978>] kmem_cache_alloc+0x78/0x160
RSP: 0018:ffff88007aed3a48 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000001991
RDX: 0000000000001990 RSI: 00000000024000c0 RDI: 000000000001b330
RBP: ffff88007aed3a98 R08: ffff88007d29b330 R09: 00000002000800c0
R10: 0000000c51376d87 R11: ffff8800792cac38 R12: ffff88007cc30f00
R13: 00000000024000c0 R14: ffffffff811b053f R15: ffff88007aed3ce7
FS: 0000000000000000(0000) GS:ffff88007d280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000002000800c0 CR3: 000000007aeb2000 CR4: 00000000000406e0
Call Trace:
__d_alloc+0x2f/0x1a0
d_alloc+0x17/0x80
lookup_dcache+0x8a/0xc0
path_openat+0x3c3/0x1210
do_filp_open+0x80/0xe0
do_sys_open+0x110/0x200
SyS_open+0x19/0x20
do_syscall_64+0x72/0x230
entry_SYSCALL64_slow_path+0x25/0x25
Code: 05 e6 77 e7 7e 4d 8b 08 49 8b 40 10 4d 85 c9 0f 84 dd 00 00 00 48 85 c0 0f 84 d4 00 00 00 49 63 44 24 20 49 8b 3c 24 48 8d 4a 01 <49> 8b 1c 01 4c 89 c8 65 48 0f c7 0f 0f 94 c0 3c 01 75 b6 49 63
RIP kmem_cache_alloc+0x78/0x160
CR2: 00000002000800c0
---[ end trace 823969e602e4aaac ]------ fs/ocfs2/cluster/heartbeat.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/ocfs2/cluster/heartbeat.c +2 -2
@@ -1445,8 +1445,8 @@ static void o2hb_region_release(struct cdebugfs_remove (reg->hr_debug_dir);kfree (reg->hr_db_livenodes);kfree (reg->hr_db_regnum); -kfree (reg->hr_debug_elapsed_time); -kfree (reg->hr_debug_pinned); +kfree (reg->hr_db_elapsed_time); +kfree (reg->hr_db_pinned);spin_lock (&o2hb_live_lock);list_del (®->hr_all_item);
Greg Kroah-Hartman
maintainerPATCH 226/238 ocfs2/dlm: fix race between convert and recovery
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joseph Qi <[email protected]>
commit ac7cf246dfdbec3d8fed296c7bf30e16f5099dac upstream.
There is a race window between dlmconvert_remote and dlm_move_lockres_to_recovery_list, which will cause a lock with OCFS2_LOCK_BUSY in grant list, thus system hangs.
dlmconvert_remote
{
spin_lock(&res->spinlock);
list_move_tail(&lock->list, &res->converting);
lock->convert_pending = 1;
spin_unlock(&res->spinlock);
status = dlm_send_remote_convert_request();
>>>>>> race window, master has queued ast and return DLM_NORMAL,
and then down before sending ast.
this node detects master down and calls
dlm_move_lockres_to_recovery_list, which will revert the
lock to grant list.
Then OCFS2_LOCK_BUSY won't be cleared as new master won't
send ast any more because it thinks already be authorized.
spin_lock(&res->spinlock);
lock->convert_pending = 0;
if (status != DLM_NORMAL)
dlm_revert_pending_convert(res, lock);
spin_unlock(&res->spinlock);
}In this case, check if res->state has DLM_LOCK_RES_RECOVERING bit set (res is still in recovering) or res master changed (new master has finished recovery), reset the status to DLM_RECOVERING, then it will retry convert.
--- fs/ocfs2/dlm/dlmconvert.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
fs/ocfs2/dlm/dlmconvert.c +10 -1
@@ -262,6 +262,7 @@ enum dlm_status dlmconvert_remote(struct struct dlm_lock *lock, int flags, int type) { enum dlm_status status; +u8 old_owner = res->owner;mlog (0 ,"type=%d, convert_type=%d, busy=%d\n" , lock->ml.type, lock->ml.convert_type, res->state &DLM_LOCK_RES_IN_PROGRESS );
@@ -316,11 +317,19 @@ enum dlm_status dlmconvert_remote(structspin_lock (&res->spinlock); res->state &= ~DLM_LOCK_RES_IN_PROGRESS ; lock->convert_pending =0 ; -/* if it failed, move it back to granted queue */ +/* if it failed, move it back to granted queue. +* if master returns DLM_NORMAL and then down before sending ast, +* it may have already been moved to granted queue, reset to +* DLM_RECOVERING and retry convert */ if (status !=DLM_NORMAL ) {if (status !=DLM_NOTQUEUED )dlm_error (status);dlm_revert_pending_convert (res, lock); + }else if ((res->state &DLM_LOCK_RES_RECOVERING ) || + (old_owner != res->owner)) { +mlog (0 ,"res %.*s is in recovering or has been recovered.\n" , + res->lockname.len, res->lockname.name); + status =DLM_RECOVERING ; } bail:spin_unlock (&res->spinlock);
Greg Kroah-Hartman
maintainerPATCH 227/238 ocfs2/dlm: fix BUG in dlm_move_lockres_to_recovery_list
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joseph Qi <[email protected]>
commit be12b299a83fc807bbaccd2bcb8ec50cbb0cb55c upstream.
When master handles convert request, it queues ast first and then returns status. This may happen that the ast is sent before the request status because the above two messages are sent by two threads. And right after the ast is sent, if master down, it may trigger BUG in dlm_move_lockres_to_recovery_list in the requested node because ast handler moves it to grant list without clear lock->convert_pending. So remove BUG_ON statement and check if the ast is processed in dlmconvert_remote.
--- fs/ocfs2/dlm/dlmconvert.c | 13 +++++++++++++ fs/ocfs2/dlm/dlmrecovery.c | 1 - 2 files changed, 13 insertions(+), 1 deletion(-)
fs/ocfs2/dlm/dlmconvert.c +13 -0
@@ -288,6 +288,19 @@ enum dlm_status dlmconvert_remote(struct status =DLM_DENIED ; goto bail; } + +if (lock->ml.type == type && lock->ml.convert_type ==LKM_IVMODE ) { +mlog (0 ,"last convert request returned DLM_RECOVERING, but " +"owner has already queued and sent ast to me. res %.*s, " +"(cookie=%u:%llu, type=%d, conv=%d)\n" , + res->lockname.len, res->lockname.name, +dlm_get_lock_cookie_node (be64_to_cpu (lock->ml.cookie)), +dlm_get_lock_cookie_seq (be64_to_cpu (lock->ml.cookie)), + lock->ml.type, lock->ml.convert_type); + status =DLM_NORMAL ; + goto bail; + } + res->state |=DLM_LOCK_RES_IN_PROGRESS ;/* move lock to local convert queue */ /* do not alter lock refcount. switching lists. */
fs/ocfs2/dlm/dlmrecovery.c +0 -1
@@ -2071,7 +2071,6 @@ void dlm_move_lockres_to_recovery_list(sdlm_lock_get (lock);if (lock->convert_pending) {/* move converting lock back to granted */ -BUG_ON (i !=DLM_CONVERTING_LIST );mlog (0 ,"node died with convert pending " "on %.*s. move back to granted list.\n" , res->lockname.len, res->lockname.name);
Greg Kroah-Hartman
maintainerPATCH 228/238 mm/page_alloc: prevent merging between isolated and other pageblocks
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vlastimil Babka <[email protected]>
commit d9dddbf556674bf125ecd925b24e43a5cf2a568a upstream.
Hanjun Guo has reported that a CMA stress test causes broken accounting of CMA and free pages:
Quoted 11 lines
Before the test, I got:
-bash-4.3# cat/proc/meminfo| grep CmaCmaTotal: 204800 kB CmaFree: 195044 kBAfter running the test:
-bash-4.3# cat/proc/meminfo| grep CmaCmaTotal: 204800 kB CmaFree: 6602584 kB
Quoted 8 lines
So the freed CMA memory is more than total..
Also the the MemFree is more than mem total:
-bash-4.3# cat
/proc/meminfoMemTotal: 16342016 kB MemFree: 22367268 kB MemAvailable: 22370528 kB
Laura Abbott has confirmed the issue and suspected the freepage accounting rewrite around 3.18/4.0 by Joonsoo Kim. Joonsoo had a theory that this is caused by unexpected merging between MIGRATE_ISOLATE and MIGRATE_CMA pageblocks:
Quoted 9 lines
CMA isolates
MAX_ORDERaligned blocks, but, during the process, partialy isolated block exists. IfMAX_ORDERis 11 andpageblock_orderis 9, two pageblocks make upMAX_ORDERaligned block and I can think following scenario because pageblock (un)isolation would be done one by one.(each character means one pageblock. 'C', 'I' means
MIGRATE_CMA,MIGRATE_ISOLATE, respectively.
Quoted 6 lines
CC -> IC -> II (Isolation)
II -> CI -> CC (Un-isolation)If some pages are freed at this intermediate state such as IC or CI, that page could be merged to the other page that is resident on different type of pageblock and it will cause wrong freepage count.
This was supposed to be prevented by CMA operating on MAX_ORDER blocks, but since it doesn't hold the zone->lock between pageblocks, a race window does exist.
It's also likely that unexpected merging can occur between MIGRATE_ISOLATE and non-CMA pageblocks. This should be prevented in __free_one_page() since commit 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated pageblock"). However, we only check the migratetype of the pageblock where buddy merging has been initiated, not the migratetype of the buddy pageblock (or group of pageblocks) which can be MIGRATE_ISOLATE.
Joonsoo has suggested checking for buddy migratetype as part of page_is_buddy(), but that would add extra checks in allocator hotpath and bloat-o-meter has shown significant code bloat (the function is inline).
This patch reduces the bloat at some expense of more complicated code. The buddy-merging while-loop in __free_one_page() is initially bounded to pageblock_border and without any migratetype checks. The checks are placed outside, bumping the max_order if merging is allowed, and returning to the while-loop with a statement which can't be possibly considered harmful.
This fixes the accounting bug and also removes the arguably weird state in the original commit 3c605096d315 where buddies could be left unmerged.
--- mm/page_alloc.c | 46 +++++++++++++++++++++++++++++++++------------- 1 file changed, 33 insertions(+), 13 deletions(-)
mm/page_alloc.c +33 -13
@@ -660,34 +660,28 @@ static inline void __free_one_page(strucunsigned long combined_idx;unsigned long uninitialized_var (buddy_idx );struct page *buddy; -unsigned int max_order =MAX_ORDER ; +unsigned int max_order; + + max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);VM_BUG_ON (!zone_is_initialized (zone));VM_BUG_ON_PAGE (page->flags &PAGE_FLAGS_CHECK_AT_PREP , page);VM_BUG_ON (migratetype ==-1 ); -if (is_migrate_isolate (migratetype)) { -/* -* We restrict max order of merging to prevent merge -* between freepages on isolate pageblock and normal -* pageblock. Without this, pageblock isolation -* could cause incorrect freepage accounting. -*/ - max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1); - }else { +if (likely (!is_migrate_isolate (migratetype)))__mod_zone_freepage_state (zone,1 << order, migratetype); - } - page_idx = pfn & ((1 << max_order) -1 ); + page_idx = pfn & ((1 <<MAX_ORDER ) -1 );VM_BUG_ON_PAGE (page_idx & ((1 << order) -1 ), page);VM_BUG_ON_PAGE (bad_range (zone, page), page); +continue_merging:while (order < max_order -1 ) { buddy_idx =__find_buddy_index (page_idx, order); buddy = page + (buddy_idx - page_idx);if (!page_is_buddy (page, buddy, order)) -break ; + goto done_merging;/* * Our buddy is free or it is CONFIG_DEBUG_PAGEALLOC guard page, * merge with it and move up one order.
@@ -704,6 +698,32 @@ static inline void __free_one_page(struc page_idx = combined_idx; order++; } +if (max_order <MAX_ORDER ) { +/* If we are here, it means order is >= pageblock_order. +* We want to prevent merge between freepages on isolate +* pageblock and normal pageblock. Without this, pageblock +* isolation could cause incorrect freepage or CMA accounting. +* +* We don't want to hit this code for the more frequent +* low-order merging. +*/ +if (unlikely (has_isolate_pageblock (zone))) { +int buddy_mt; + + buddy_idx =__find_buddy_index (page_idx, order); + buddy = page + (buddy_idx - page_idx); + buddy_mt =get_pageblock_migratetype (buddy); + +if (migratetype != buddy_mt + && (is_migrate_isolate (migratetype) || +is_migrate_isolate (buddy_mt))) + goto done_merging; + } + max_order++; + goto continue_merging; + } + +done_merging:set_page_order (page, order);/*
Greg Kroah-Hartman
maintainerPATCH 229/238 mtd: onenand: fix deadlock in onenand_block_markbad
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aaro Koskinen <[email protected]>
commit 5e64c29e98bfbba1b527b0a164f9493f3db9e8cb upstream.
Commit 5942ddbc500d ("mtd: introduce mtd_block_markbad interface") incorrectly changed onenand_block_markbad() to call mtd_block_markbad instead of onenand_chip's block_markbad function. As a result the function will now recurse and deadlock. Fix by reverting the change.
--- drivers/mtd/onenand/onenand_base.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/mtd/onenand/onenand_base.c +2 -1
@@ -2599,6 +2599,7 @@ static int onenand_default_block_markbad*/ static int onenand_block_markbad (struct mtd_info *mtd,loff_t ofs) { +struct onenand_chip *this = mtd->priv;int ret; ret =onenand_block_isbad (mtd, ofs);
@@ -2610,7 +2611,7 @@ static int onenand_block_markbad(struct }onenand_get_device (mtd,FL_WRITING ); - ret =mtd_block_markbad (mtd, ofs); + ret = this->block_markbad (mtd, ofs);onenand_release_device (mtd);return ret; }
Greg Kroah-Hartman
maintainerPATCH 230/238 intel_idle: prevent SKL-H boot failure when C8+C9+C10 enabled
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Len Brown <[email protected]>
commit d70e28f57e14a481977436695b0c9ba165472431 upstream.
Some SKL-H configurations require "intel_idle.max_cstate=7" to boot. While that is an effective workaround, it disables C10.
This patch detects the problematic configuration,
and disables C8 and C9, keeping C10 enabled.
Note that enabling SGX in BIOS SETUP can also prevent this issue, if the system BIOS provides that option.
https://bugzilla.kernel.org/show_bug.cgi?id=109081
"Freezes with Intel i7 6700HQ (Skylake), unless intel_idle.max_cstate=7"
--- drivers/idle/intel_idle.c | 106 ++++++++++++++++++++++++++++++++++++---------- 1 file changed, 85 insertions(+), 21 deletions(-)
drivers/idle/intel_idle.c +85 -21
@@ -65,7 +65,7 @@#include <asm/mwait.h> #include <asm/msr.h> -#define INTEL_IDLE_VERSION "0.4" +#define INTEL_IDLE_VERSION "0.4.1"#define PREFIX "intel_idle: "static struct cpuidle_driver intel_idle_driver = {
@@ -994,36 +994,92 @@ static void intel_idle_cpuidle_devices_u }/* -* intel_idle_state_table_update() -* -* Update the default state_table for this CPU-id +* ivt_idle_state_table_update(void) * -* Currently used to access tuned IVT multi-socket targets +* Tune IVT multi-socket targets * Assumption: num_sockets == (max_package_num + 1) */ -void intel_idle_state_table_update (void ) +static void ivt_idle_state_table_update (void ) {/* IVT uses a different table for 1-2, 3-4, and > 4 sockets */ -if (boot_cpu_data.x86_model ==0x3e ) {/* IVT */ -int cpu, package_num, num_sockets =1 ; +int cpu, package_num, num_sockets =1 ; -for_each_online_cpu (cpu) { - package_num =topology_physical_package_id (cpu); -if (package_num +1 > num_sockets) { - num_sockets = package_num +1 ; - -if (num_sockets >4 ) { - cpuidle_state_table = ivt_cstates_8s; -return ; - } +for_each_online_cpu (cpu) { + package_num =topology_physical_package_id (cpu); +if (package_num +1 > num_sockets) { + num_sockets = package_num +1 ; + +if (num_sockets >4 ) { + cpuidle_state_table = ivt_cstates_8s; +return ; } } + } + +if (num_sockets >2 ) + cpuidle_state_table = ivt_cstates_4s; + +/* else, 1 and 2 socket systems use default ivt_cstates */ +} +/* +* sklh_idle_state_table_update(void) +* +* On SKL-H (model 0x5e) disable C8 and C9 if: +* C10 is enabled and SGX disabled +*/ +static void sklh_idle_state_table_update (void ) +{ +unsigned long long msr; +unsigned int eax, ebx, ecx, edx; + + +/* if PC10 disabled via cmdline intel_idle.max_cstate=7 or shallower */ +if (max_cstate <=7 ) +return ; + +/* if PC10 not present in CPUID.MWAIT.EDX */ +if ((mwait_substates & (0xF <<28 )) ==0 ) +return ; + +rdmsrl (MSR_NHM_SNB_PKG_CST_CFG_CTL , msr); + +/* PC10 is not enabled in PKG C-state limit */ +if ((msr &0xF ) !=8 ) +return ; + + ecx =0 ; +cpuid (7 , &eax, &ebx, &ecx, &edx); + +/* if SGX is present */ +if (ebx & (1 <<2 )) { + +rdmsrl (MSR_IA32_FEATURE_CONTROL , msr); -if (num_sockets >2 ) - cpuidle_state_table = ivt_cstates_4s; -/* else, 1 and 2 socket systems use default ivt_cstates */ +/* if SGX is enabled */ +if (msr & (1 <<18 )) +return ; + } + + skl_cstates[5 ].disabled =1 ;/* C8-SKL */ + skl_cstates[6 ].disabled =1 ;/* C9-SKL */ +} +/* +* intel_idle_state_table_update() +* +* Update the default state_table for this CPU-id +*/ + +static void intel_idle_state_table_update (void ) +{ +switch (boot_cpu_data.x86_model) { + +case 0x3e :/* IVT */ +ivt_idle_state_table_update (); +break ; +case 0x5e :/* SKL-H */ +sklh_idle_state_table_update (); +break ; } -return ; }/*
@@ -1063,6 +1119,14 @@ static int __init intel_idle_cpuidle_driif (num_substates ==0 )continue ; +/* if state marked as disabled, skip it */ +if (cpuidle_state_table[cstate].disabled !=0 ) { +pr_debug (PREFIX "state %s is disabled" , + cpuidle_state_table[cstate].name); +continue ; + } + +if (((mwait_cstate +1 ) >2 ) && !boot_cpu_has (X86_FEATURE_NONSTOP_TSC )) mark_tsc_unstable("TSC halts in idle"
Greg Kroah-Hartman
maintainerPATCH 231/238 PM / sleep: Clear pm_suspend_global_flags upon hibernate
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Wunner <[email protected]>
commit 276142730c39c9839465a36a90e5674a8c34e839 upstream.
When suspending to RAM, waking up and later suspending to disk, we gratuitously runtime resume devices after the thaw phase. This does not occur if we always suspend to RAM or always to disk.
pm_complete_with_resume_check(), which gets called from pci_pm_complete() among others, schedules a runtime resume if PM_SUSPEND_FLAG_FW_RESUME is set. The flag is set during a suspend-to-RAM cycle. It is cleared at the beginning of the suspend-to-RAM cycle but not afterwards and it is not cleared during a suspend-to-disk cycle at all. Fix it.
--- kernel/power/hibernate.c | 1 + 1 file changed, 1 insertion(+)
kernel/power/hibernate.c +1 -0
@@ -339,6 +339,7 @@ int hibernation_snapshot(int platform_mopm_message_t msg;int error; +pm_suspend_clear_flags (); error =platform_begin (platform_mode);if (error) goto Close;
Greg Kroah-Hartman
maintainerPATCH 232/238 scsi_common: do not clobber fixed sense information
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hannes Reinecke <[email protected]>
commit ba08311647892cc7912de74525fd78416caf544a upstream.
For fixed sense the information field is 32 bits, to we need to truncate the information field to avoid clobbering the sense code.
--- drivers/scsi/scsi_common.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/scsi/scsi_common.c +10 -2
@@ -278,8 +278,16 @@ int scsi_set_sense_information(u8 *buf, ucp[3 ] =0 ;put_unaligned_be64 (info, &ucp[4 ]); }else if ((buf[0 ] &0x7f ) ==0x70 ) { - buf[0 ] |=0x80 ; -put_unaligned_be64 (info, &buf[3 ]); +/* +* Only set the 'VALID' bit if we can represent the value +* correctly; otherwise just fill out the lower bytes and +* clear the 'VALID' flag. +*/ +if (info <=0xffffffffUL ) + buf[0 ] |=0x80 ; +else + buf[0 ] &=0x7f ; +put_unaligned_be32 ((u32 )info, &buf[3 ]); }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 233/238 sched/cputime: Fix steal time accounting vs. CPU hotplug
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit e9532e69b8d1d1284e8ecf8d2586de34aec61244 upstream.
On CPU hotplug the steal time accounting can keep a stale rq->prev_steal_time value over CPU down and up. So after the CPU comes up again the delta calculation in steal_account_process_tick() wreckages itself due to the unsigned math:
u64 steal = paravirt_steal_clock(smp_processor_id()); steal -= this_rq()->prev_steal_time;
So if steal is smaller than rq->prev_steal_time we end up with an insane large value which then gets added to rq->prev_steal_time, resulting in a permanent wreckage of the accounting. As a consequence the per CPU stats in /proc/stat become stale.
Nice trick to tell the world how idle the system is (100%) while the CPU is 100% busy running tasks. Though we prefer realistic numbers.
None of the accounting values which use a previous value to account for fractions is reset at CPU hotplug time. update_rq_clock_task() has a sanity check for prev_irq_time and prev_steal_time_rq, but that sanity check solely deals with clock warps and limits the /proc/stat visible wreckage. The prev_time values are still wrong.
Solution is simple: Reset rq->prev_*_time when the CPU is plugged in again.
--- kernel/sched/core.c | 1 + kernel/sched/sched.h | 13 +++++++++++++ 2 files changed, 14 insertions(+)
kernel/sched/core.c +1 -0
@@ -5630,6 +5630,7 @@ migration_call(struct notifier_block *nfcase CPU_UP_PREPARE : rq->calc_load_update = calc_load_update; +account_reset_rq (rq);break ;case CPU_ONLINE :
kernel/sched/sched.h +13 -0
@@ -1738,3 +1738,16 @@ static inline u64 irq_time_read(int cpu) }#endif /* CONFIG_64BIT */ #endif /* CONFIG_IRQ_TIME_ACCOUNTING */ + +static inline void account_reset_rq (struct rq *rq) +{ +#ifdef CONFIG_IRQ_TIME_ACCOUNTING + rq->prev_irq_time =0 ; +#endif +#ifdef CONFIG_PARAVIRT + rq->prev_steal_time =0 ; +#endif +#ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING + rq->prev_steal_time_rq =0 ; +#endif +}
Greg Kroah-Hartman
maintainerPATCH 234/238 perf/x86/pebs: Add workaround for broken OVFL status on HSW+
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephane Eranian <[email protected]>
commit 8077eca079a212f26419c57226f28696b7100683 upstream.
This patch fixes an issue with the GLOBAL_OVERFLOW_STATUS bits on Haswell, Broadwell and Skylake processors when using PEBS.
The SDM stipulates that when the PEBS iterrupt threshold is crossed, an interrupt is posted and the kernel is interrupted. The kernel will find GLOBAL_OVF_SATUS bit 62 set indicating there are PEBS records to drain. But the bits corresponding to the actual counters should NOT be set. The kernel follows the SDM and assumes that all PEBS events are processed in the drain_pebs() callback. The kernel then checks for remaining overflows on any other (non-PEBS) events and processes these in the for_each_bit_set(&status) loop.
As it turns out, under certain conditions on HSW and later processors, on PEBS buffer interrupt, bit 62 is set but the counter bits may be set as well. In that case, the kernel drains PEBS and generates SAMPLES with the EXACT tag, then it processes the counter bits, and generates normal (non-EXACT) SAMPLES.
I ran into this problem by trying to understand why on HSW sampling on a PEBS event was sometimes returning SAMPLES without the EXACT tag. This should not happen on user level code because HSW has the eventing_ip which always point to the instruction that caused the event.
The workaround in this patch simply ensures that the bits for the counters used for PEBS events are cleared after the PEBS buffer has been drained. With this fix 100% of the PEBS samples on my user code report the EXACT tag.
Before:
$ perf record -e cpu/event=0xd0,umask=0x81/upp ./multichase
$ perf report -D | fgrep SAMPLES
PERF_RECORD_SAMPLE(IP, 0x2): 11775/11775: 0x406de5 period: 73469 addr: 0 exact=Y
\--- EXACT tag is missingAfter:
$ perf record -e cpu/event=0xd0,umask=0x81/upp ./multichase
$ perf report -D | fgrep SAMPLES
PERF_RECORD_SAMPLE(IP, 0x4002): 11775/11775: 0x406de5 period: 73469 addr: 0 exact=Y
\--- EXACT tag is setThe problem tends to appear more often when multiple PEBS events are used.
--- arch/x86/kernel/cpu/perf_event_intel.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
arch/x86/kernel/cpu/perf_event_intel.c +10 -0
@@ -1884,6 +1884,16 @@ again:if (__test_and_clear_bit (62 , (unsigned long *)&status)) { handled++; x86_pmu.drain_pebs (regs); +/* +* There are cases where, even though, the PEBS ovfl bit is set +* in GLOBAL_OVF_STATUS, the PEBS events may also have their +* overflow bits set for their counters. We must clear them +* here because they have been processed as exact samples in +* the drain_pebs() routine. They must not be processed again +* in the for_each_bit_set() loop for regular samples below. +*/ + status &= ~cpuc->pebs_enabled; + status &= x86_pmu.intel_ctrl |GLOBAL_STATUS_TRACE_TOPAPMI ; }/*
Greg Kroah-Hartman
maintainerPATCH 235/238 perf/x86/intel/uncore: Remove SBOX support for BDX-DE
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
commit e178b147e530c12a95871e78569554666fe01c0f upstream.
BDX-DE and BDX-EP share the same uncore code path. But there is no sbox in BDX-DE. This patch remove SBOX support for BDX-DE.
--- arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c +7 -1
@@ -2875,11 +2875,13 @@ static struct intel_uncore_type bdx_unco .format_group = &hswep_uncore_sbox_format_group, }; +#define BDX_MSR_UNCORE_SBOX 3 +static struct intel_uncore_type *bdx_msr_uncores[] = { &bdx_uncore_ubox, &bdx_uncore_cbox, - &bdx_uncore_sbox, &hswep_uncore_pcu, + &bdx_uncore_sbox,NULL , };
@@ -2888,6 +2890,10 @@ void bdx_uncore_cpu_init(void)if (bdx_uncore_cbox.num_boxes > boot_cpu_data.x86_max_cores) bdx_uncore_cbox.num_boxes = boot_cpu_data.x86_max_cores; uncore_msr_uncores = bdx_msr_uncores; + +/* BDX-DE doesn't have SBOX */ +if (boot_cpu_data.x86_model ==86 ) + uncore_msr_uncores[BDX_MSR_UNCORE_SBOX ] =NULL ; }static struct intel_uncore_type bdx_uncore_ha = {
Greg Kroah-Hartman
maintainerPATCH 237/238 perf/x86/intel: Use PAGE_SIZE for PEBS buffer size on Core2
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Olsa <[email protected]>
commit 3135a66b768c5ee84c8a98b21d0330dc1c1234b4 upstream.
Using PAGE_SIZE buffers makes the WRMSR to PERF_GLOBAL_CTRL in intel_pmu_enable_all() mysteriously hang on Core2. As a workaround, we don't do this.
The hard lockup is easily triggered by running 'perf test attr' repeatedly. Most of the time it gets stuck on sample session with small periods.
# perf test attr -vv
14: struct perf_event_attr setup :
--- start ---
...
'PERF_TEST_ATTR=/tmp/tmpuEKz3B /usr/bin/perf record -o /tmp/tmpuEKz3B/perf.data -c 123 kill >/dev/null 2>&1' ret 1--- arch/x86/kernel/cpu/perf_event.h | 1 + arch/x86/kernel/cpu/perf_event_intel_ds.c | 13 +++++++++++-- 2 files changed, 12 insertions(+), 2 deletions(-)
arch/x86/kernel/cpu/perf_event.h +1 -0
@@ -586,6 +586,7 @@ struct x86_pmu { pebs_broken :1 , pebs_prec_dist :1;int pebs_record_size; +int pebs_buffer_size;void (*drain_pebs)(struct pt_regs *regs);struct event_constraint *pebs_constraints;void (*pebs_aliases)(struct perf_event *event);
arch/x86/kernel/cpu/perf_event_intel_ds.c +11 -2
@@ -269,7 +269,7 @@ static int alloc_pebs_buffer(int cpu)if (!x86_pmu.pebs)return 0 ; - buffer =kzalloc_node (PEBS_BUFFER_SIZE ,GFP_KERNEL , node); + buffer =kzalloc_node (x86_pmu.pebs_buffer_size,GFP_KERNEL , node);if (unlikely (!buffer))return -ENOMEM ;
@@ -286,7 +286,7 @@ static int alloc_pebs_buffer(int cpu)per_cpu (insn_buffer, cpu) = ibuffer; } - max =PEBS_BUFFER_SIZE / x86_pmu.pebs_record_size; + max = x86_pmu.pebs_buffer_size / x86_pmu.pebs_record_size; ds->pebs_buffer_base = (u64 )(unsigned long )buffer; ds->pebs_index = ds->pebs_buffer_base;
@@ -1319,6 +1319,7 @@ void __init intel_ds_init(void) x86_pmu.bts =boot_cpu_has (X86_FEATURE_BTS ); x86_pmu.pebs =boot_cpu_has (X86_FEATURE_PEBS ); + x86_pmu.pebs_buffer_size =PEBS_BUFFER_SIZE ;if (x86_pmu.pebs) {char pebs_type = x86_pmu.intel_cap.pebs_trap ?'+' :'-' ;int format = x86_pmu.intel_cap.pebs_format;
@@ -1327,6 +1328,14 @@ void __init intel_ds_init(void)case 0 :printk (KERN_CONT "PEBS fmt0%c, " , pebs_type); x86_pmu.pebs_record_size =sizeof (struct pebs_record_core ); +/* +* Using >PAGE_SIZE buffers makes the WRMSR to +* PERF_GLOBAL_CTRL in intel_pmu_enable_all() +* mysteriously hang on Core2. +* +* As a workaround, we don't do this. +*/ + x86_pmu.pebs_buffer_size =PAGE_SIZE ; x86_pmu.drain_pebs = intel_pmu_drain_pebs_core;break ;
Greg Kroah-Hartman
maintainerPATCH 238/238 perf/x86/intel: Fix PEBS data source interpretation on Nehalem/Westmere
In reply to Greg Kroah-Hartman4.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andi Kleen <[email protected]>
commit 5e3f4cbd906c178510dccfed1131b007c96255ff upstream.
Jiri reported some time ago that some entries in the PEBS data source table in perf do not agree with the SDM. We investigated and the bits changed for Sandy Bridge, but the SDM was not updated.
perf already implements the bits correctly for Sandy Bridge and later. This patch patches it up for Nehalem and Westmere.
--- arch/x86/kernel/cpu/perf_event.h | 2 ++ arch/x86/kernel/cpu/perf_event_intel.c | 2 ++ arch/x86/kernel/cpu/perf_event_intel_ds.c | 11 ++++++++++- 3 files changed, 14 insertions(+), 1 deletion(-)
arch/x86/kernel/cpu/perf_event.h +2 -0
@@ -905,6 +905,8 @@ void intel_pmu_lbr_init_skl(void);void intel_pmu_lbr_init_knl (void ); +void intel_pmu_pebs_data_source_nhm (void ); +int intel_pmu_setup_lbr_filter (struct perf_event *event);void intel_pt_interrupt (void );
arch/x86/kernel/cpu/perf_event_intel.c +2 -0
@@ -3417,6 +3417,7 @@ __init int intel_pmu_init(void) intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_BACKEND ] = X86_CONFIG(.event=0xb1, .umask=0x3f, .inv=1, .cmask=1); +intel_pmu_pebs_data_source_nhm ();x86_add_quirk (intel_nehalem_quirk);pr_cont ("Nehalem events, " );
@@ -3480,6 +3481,7 @@ __init int intel_pmu_init(void) intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_BACKEND ] = X86_CONFIG(.event=0xb1, .umask=0x3f, .inv=1, .cmask=1); +intel_pmu_pebs_data_source_nhm ();pr_cont ("Westmere events, " );break ;
arch/x86/kernel/cpu/perf_event_intel_ds.c +10 -1
@@ -51,7 +51,8 @@ union intel_x86_pebs_dse {#define OP_LH (P(OP, LOAD) | P(LVL, HIT))#define SNOOP_NONE_MISS (P(SNOOP, NONE) | P(SNOOP, MISS)) -static const u64 pebs_data_source[] = { +/* Version for Sandy Bridge and later */ +static u64 pebs_data_source[] = {P (OP ,LOAD ) |P (LVL ,MISS ) |P (LVL ,L3 ) |P (SNOOP ,NA ),/* 0x00:ukn L3 */ OP_LH |P (LVL ,L1 ) |P (SNOOP ,NONE ),/* 0x01: L1 local */ OP_LH |P (LVL ,LFB ) |P (SNOOP ,NONE ),/* 0x02: LFB hit */
@@ -70,6 +71,14 @@ static const u64 pebs_data_source[] = { OP_LH | P(LVL, UNC) | P(SNOOP, NONE), /* 0x0f: uncached */ }; +/* Patch up minor differences in the bits */ +void __init intel_pmu_pebs_data_source_nhm (void ) +{ + pebs_data_source[0x05 ] =OP_LH |P (LVL ,L3 ) |P (SNOOP ,HIT ); + pebs_data_source[0x06 ] =OP_LH |P (LVL ,L3 ) |P (SNOOP ,HITM ); + pebs_data_source[0x07 ] =OP_LH |P (LVL ,L3 ) |P (SNOOP ,HITM ); +} +static u64 precise_store_data (u64 status) {union intel_x86_pebs_dse dse;
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.5.1 release. There are 238 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 Tue Apr 12 18:34:18 UTC 2016. Anything received after that time might be too late.
Build results:
total: 147 pass: 147 fail: 0 Qemu test results: total: 104 pass: 100 fail: 4
Failed tests:
arm:akita:pxa_defconfig
arm:borzoi:pxa_defconfig
arm:spitz:pxa_defconfig
arm:terrier:pxa_defconfig
Details are available at http://kerneltests.org/builders.
4.5 will require two patches from mainline to fix the known problems.
3c2e2266a5bd ("hwmon: (max1111) Return -ENODEV from max1111_read_channel if not instantiated") c4e5ffb6f224 ("gpio: pxa: fix legacy non pinctrl aware builds")
The first fixes the direct failures reported above, the second fixes a traceback seen as result of failed gpio pin initialization. The first patch is tagged Cc: stable, the second has a Fixes: tag, so both should already be in your queue for 4.5.
Thanks,
Guenter
Greg Kroah-Hartman
maintainerQuoted 24 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.5.1 release. There are 238 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 Tue Apr 12 18:34:18 UTC 2016. Anything received after that time might be too late.
Build results:
total: 147 pass: 147 fail: 0 Qemu test results: total: 104 pass: 100 fail: 4Failed tests:
arm:akita:pxa_defconfig
arm:borzoi:pxa_defconfig
arm:spitz:pxa_defconfig
arm:terrier:pxa_defconfigDetails are available at http://kerneltests.org/builders.
4.5 will require two patches from mainline to fix the known problems.
Quoted 7 lines
3c2e2266a5bd("hwmon: (max1111) Return-ENODEVfrommax1111_read_channelif not instantiated")c4e5ffb6f224("gpio: pxa: fix legacy non pinctrl aware builds")The first fixes the direct failures reported above, the second fixes a traceback seen as result of failed gpio pin initialization. The first patch is tagged Cc: stable, the second has a Fixes: tag, so both should already be in your queue for 4.5.
Yes, both should be queued up for the next round of 4.5-stable patches, I'll let them get merged then.
Thanks for testing 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.5.1 release. There are 238 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 Tue Apr 12 18:34:18 UTC 2016. Anything received after that time might be too late.
Quoted 8 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.5.1-rc1.gzand the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Greg Kroah-Hartman
maintainerQuoted 13 lines · shuahkh
Quoted 12 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.5.1 release. There are 238 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 Tue Apr 12 18:34:18 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.5.1-rc1.gzand the diffstat can be found below.
Quoted 6 lines
Quoted 4 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all of these and letting me know.
greg k-h