- 19 Apr, 2015 40 commits
-
-
Laura Abbott authored
commit cfa86943 upstream. Commit 3c605096 ("mm/page_alloc: restrict max order of merging on isolated pageblock") changed the logic of unset_migratetype_isolate to check the buddy allocator and explicitly call __free_pages to merge. The page that is being freed in this path never had prep_new_page called so set_page_refcounted is called explicitly but there is no call to kernel_map_pages. With the default kernel_map_pages this is mostly harmless but if kernel_map_pages does any manipulation of the page tables (unmapping or setting pages to read only) this may trigger a fault: alloc_contig_range test_pages_isolated(ceb00, ced00) failed Unable to handle kernel paging request at virtual address ffffffc0cec00000 pgd = ffffffc045fc4000 [ffffffc0cec00000] *pgd=0000000000000000 Internal error: Oops: 9600004f [#1] PREEMPT SMP Modules linked in: exfatfs CPU: 1 PID: 23237 Comm: TimedEventQueue Not tainted 3.10.49-gc72ad36-dirty #1 task: ffffffc03de52100 ti: ffffffc015388000 task.ti: ffffffc015388000 PC is at memset+0xc8/0x1c0 LR is at kernel_map_pages+0x1ec/0x244 Fix this by calling kernel_map_pages to ensure the page is set in the page table properly Fixes: 3c605096 ("mm/page_alloc: restrict max order of merging on isolated pageblock") Signed-off-by:
Laura Abbott <lauraa@codeaurora.org> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Mel Gorman <mgorman@suse.de> Acked-by:
Rik van Riel <riel@redhat.com> Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Cc: Xishi Qiu <qiuxishi@huawei.com> Cc: Vladimir Davydov <vdavydov@parallels.com> Acked-by:
Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Gioh Kim <gioh.kim@lge.com> Cc: Michal Nazarewicz <mina86@mina86.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gu Zheng authored
commit b0dc3a34 upstream. Qiu Xishi reported the following BUG when testing hot-add/hot-remove node under stress condition: BUG: unable to handle kernel paging request at 0000000000025f60 IP: next_online_pgdat+0x1/0x50 PGD 0 Oops: 0000 [#1] SMP ACPI: Device does not support D3cold Modules linked in: fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod coretemp mperf crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 pcspkr microcode igb dca i2c_algo_bit ipv6 megaraid_sas iTCO_wdt i2c_i801 i2c_core iTCO_vendor_support tg3 sg hwmon ptp lpc_ich pps_core mfd_core acpi_pad rtc_cmos button ext3 jbd mbcache sd_mod crc_t10dif scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh ahci libahci libata scsi_mod [last unloaded: rasf] CPU: 23 PID: 238 Comm: kworker/23:1 Tainted: G O 3.10.15-5885-euler0302 #1 Hardware name: HUAWEI TECHNOLOGIES CO.,LTD. Huawei N1/Huawei N1, BIOS V100R001 03/02/2015 Workqueue: events vmstat_update task: ffffa800d32c0000 ti: ffffa800d32ae000 task.ti: ffffa800d32ae000 RIP: 0010: next_online_pgdat+0x1/0x50 RSP: 0018:ffffa800d32afce8 EFLAGS: 00010286 RAX: 0000000000001440 RBX: ffffffff81da53b8 RCX: 0000000000000082 RDX: 0000000000000000 RSI: 0000000000000082 RDI: 0000000000000000 RBP: ffffa800d32afd28 R08: ffffffff81c93bfc R09: ffffffff81cbdc96 R10: 00000000000040ec R11: 00000000000000a0 R12: ffffa800fffb3440 R13: ffffa800d32afd38 R14: 0000000000000017 R15: ffffa800e6616800 FS: 0000000000000000(0000) GS:ffffa800e6600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000025f60 CR3: 0000000001a0b000 CR4: 00000000001407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: refresh_cpu_vm_stats+0xd0/0x140 vmstat_update+0x11/0x50 process_one_work+0x194/0x3d0 worker_thread+0x12b/0x410 kthread+0xc6/0xd0 ret_from_fork+0x7c/0xb0 The cause is the "memset(pgdat, 0, sizeof(*pgdat))" at the end of try_offline_node, which will reset all the content of pgdat to 0, as the pgdat is accessed lock-free, so that the users still using the pgdat will panic, such as the vmstat_update routine. process A: offline node XX: vmstat_updat() refresh_cpu_vm_stats() for_each_populated_zone() find online node XX cond_resched() offline cpu and memory, then try_offline_node() node_set_offline(nid), and memset(pgdat, 0, sizeof(*pgdat)) zone = next_zone(zone) pg_data_t *pgdat = zone->zone_pgdat; // here pgdat is NULL now next_online_pgdat(pgdat) next_online_node(pgdat->node_id); // NULL pointer access So the solution here is postponing the reset of obsolete pgdat from try_offline_node() to hotadd_new_pgdat(), and just resetting pgdat->nr_zones and pgdat->classzone_idx to be 0 rather than the memset 0 to avoid breaking pointer information in pgdat. Signed-off-by:
Gu Zheng <guz.fnst@cn.fujitsu.com> Reported-by:
Xishi Qiu <qiuxishi@huawei.com> Suggested-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: David Rientjes <rientjes@google.com> Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: Taku Izumi <izumi.taku@jp.fujitsu.com> Cc: Tang Chen <tangchen@cn.fujitsu.com> Cc: Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
-
Leon Yu authored
commit 3fe89b3e upstream. I have constantly stumbled upon "kernel BUG at mm/rmap.c:399!" after upgrading to 3.19 and had no luck with 4.0-rc1 neither. So, after looking into new logic introduced by commit 7a3ef208 ("mm: prevent endless growth of anon_vma hierarchy"), I found chances are that unlink_anon_vmas() is called without incrementing dst->anon_vma->degree in anon_vma_clone() due to allocation failure. If dst->anon_vma is not NULL in error path, its degree will be incorrectly decremented in unlink_anon_vmas() and eventually underflow when exiting as a result of another call to unlink_anon_vmas(). That's how "kernel BUG at mm/rmap.c:399!" is triggered for me. This patch fixes the underflow by dropping dst->anon_vma when allocation fails. It's safe to do so regardless of original value of dst->anon_vma because dst->anon_vma doesn't have valid meaning if anon_vma_clone() fails. Besides, callers don't care dst->anon_vma in such case neither. Also suggested by Michal Hocko, we can clean up vma_adjust() a bit as anon_vma_clone() now does the work. [akpm@linux-foundation.org: tweak comment] Fixes: 7a3ef208 ("mm: prevent endless growth of anon_vma hierarchy") Signed-off-by:
Leon Yu <chianglungyu@gmail.com> Signed-off-by:
Konstantin Khlebnikov <koct9i@gmail.com> Reviewed-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
-
Johannes Berg authored
commit 788211d8 upstream. There's an issue with the way the RX A-MPDU reorder timer is deleted that can cause a kernel crash like this: * tid_rx is removed - call_rcu(ieee80211_free_tid_rx) * station is destroyed * reorder timer fires before ieee80211_free_tid_rx() runs, accessing the station, thus potentially crashing due to the use-after-free The station deletion is protected by synchronize_net(), but that isn't enough -- ieee80211_free_tid_rx() need not have run when that returns (it deletes the timer.) We could use rcu_barrier() instead of synchronize_net(), but that's much more expensive. Instead, to fix this, add a field tracking that the session is being deleted. In this case, the only re-arming of the timer happens with the reorder spinlock held, so make that code not rearm it if the session is being deleted and also delete the timer after setting that field. This ensures the timer cannot fire after ___ieee80211_stop_rx_ba_session() returns, which fixes the problem. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Sudip Mukherjee authored
commit ff6b8090 upstream. we have already allocated memory for nbd_dev, but we were not releasing that memory and just returning the error value. Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Acked-by:
Paul Clements <Paul.Clements@SteelEye.com> Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Signed-off-by:
-
Paul Clarke authored
commit fea559f3 upstream. Implement arch_irq_work_has_interrupt() for powerpc Commit 9b01f5bf introduced a dependency on "IRQ work self-IPIs" for full dynamic ticks to be enabled, by expecting architectures to implement a suitable arch_irq_work_has_interrupt() routine. Several arches have implemented this routine, including x86 (3010279f) and arm (09f6edd4), but powerpc was omitted. This patch implements this routine for powerpc. The symptom, at boot (on powerpc systems) with "nohz_full=<CPU list>" is displayed: NO_HZ: Can't run full dynticks because arch doesn't support irq work self-IPIs after this patch: NO_HZ: Full dynticks CPUs: <CPU list>. Tested against 3.19. powerpc implements "IRQ work self-IPIs" by setting the decrementer to 1 in arch_irq_work_raise(), which causes a decrementer exception on the next timebase tick. We then handle the work in __timer_interrupt(). CC: Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by:
Paul A. Clarke <pc@us.ibm.com> Reviewed-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> [mpe: Flesh out change log, fix ws & include guards, remove include of processor.h] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Jan Stancek authored
commit d52356e7 upstream. Space allocated for paca is based off nr_cpu_ids, but pnv_alloc_idle_core_states() iterates paca with cpu_nr_cores()*threads_per_core, which is using NR_CPUS. This causes pnv_alloc_idle_core_states() to write over memory, which is outside of paca array and may later lead to various panics. Fixes: 7cba160a (powernv/cpuidle: Redesign idle states management) Signed-off-by:
Jan Stancek <jstancek@redhat.com> Signed-off-by:
Preet U. Murthy <preeti@linux.vnet.ibm.com> Signed-off-by:
-
Jeff Layton authored
commit f9c72d10 upstream. We currently have a problem that SELinux policy is being enforced when creating debugfs files. If a debugfs file is created as a side effect of doing some syscall, then that creation can fail if the SELinux policy for that process prevents it. This seems wrong. We don't do that for files under /proc, for instance, so Bruce has proposed a patch to fix that. While discussing that patch however, Greg K.H. stated: "No kernel code should care / fail if a debugfs function fails, so please fix up the sunrpc code first." This patch converts all of the sunrpc debugfs setup code to be void return functins, and the callers to not look for errors from those functions. This should allow rpc_clnt and rpc_xprt creation to work, even if the kernel fails to create debugfs files for some reason. Symptoms were failing krb5 mounts on systems using gss-proxy and selinux. Fixes: 388f0c77 "sunrpc: add a debugfs rpc_xprt directory..." Signed-off-by:
Jeff Layton <jeff.layton@primarydata.com> Acked-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
commit 340f0ba1 upstream. alloc_init_lock_stateowner can return an already freed entry if there is a race to put openowners in the hashtable. Noticed by inspection after Jeff Layton fixed the same bug for open owners. Depending on client behavior, this one may be trickier to trigger in practice. Fixes: c58c6610 "nfsd: Protect adding/removing lock owners using client_lock" Cc: Trond Myklebust <trond.myklebust@primarydata.com> Acked-by:
-
Jeff Layton authored
commit c5952338 upstream. alloc_init_open_stateowner can return an already freed entry if there is a race to put openowners in the hashtable. In commit 7ffb5880, we changed it so that we allocate and initialize an openowner, and then check to see if a matching one got stuffed into the hashtable in the meantime. If it did, then we free the one we just allocated and take a reference on the one already there. There is a bug here though. The code will then return the pointer to the one that was allocated (and has now been freed). This wasn't evident before as this race almost never occurred. The Linux kernel client used to serialize requests for a single openowner. That has changed now with v4.0 kernels, and this race can now easily occur. Fixes: 7ffb5880 Cc: Trond Myklebust <trond.myklebust@primarydata.com> Reported-by:
Christoph Hellwig <hch@infradead.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Juergen Gross authored
commit 3c56b3a1 upstream. Commit 25b884a8 ("x86/xen: set regions above the end of RAM as 1:1") introduced a regression. To be able to add memory pages which were added via memory hotplug to a pv domain, the pages must be "invalid" instead of "identity" in the p2m list before they can be added. Suggested-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by:
-
Juergen Gross authored
commit 633d6f17 upstream. Commit 054954eb ("xen: switch to linear virtual mapped sparse p2m list") introduced a regression regarding to memory hotplug for a pv-domain: as the virtual space for the p2m list is allocated for the to be expected memory size of the domain only, hotplugged memory above that size will not be usable by the domain. Correct this by using a configurable size for the p2m list in case of memory hotplug enabled (default supported memory size is 512 GB for 64 bit domains and 4 GB for 32 bit domains). Signed-off-by:
-
Emmanuel Grumbach authored
commit 9c8928f5 upstream. The assumption before this patch was that we don't need to run again the INIT firmware after the system booted. The INIT firmware runs calibrations which impact the physical layer's behavior. Users reported that it may be helpful to run these calibrations again every time the interface is brought up. The penatly is minimal, since the calibrations run fast. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=94341Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Shachar Raindel authored
commit 8494057a upstream. Properly verify that the resulting page aligned end address is larger than both the start address and the length of the memory area requested. Both the start and length arguments for ib_umem_get are controlled by the user. A misbehaving user can provide values which will cause an integer overflow when calculating the page aligned end address. This overflow can cause also miscalculation of the number of pages mapped, and additional logic issues. Addresses: CVE-2014-8159 Signed-off-by:
Shachar Raindel <raindel@mellanox.com> Signed-off-by:
Jack Morgenstein <jackm@mellanox.com> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
David Sterba authored
commit 9c4f61f0 upstream. We can search and add the orphan item in one go, btrfs_insert_orphan_item will find out if the item already exists. Signed-off-by:
David Sterba <dsterba@suse.cz> Cc: Chris Mason <clm@fb.com> Cc: Roman Mamedov <rm@romanrm.net> Signed-off-by:
-
Daniel Vetter authored
commit f37b5c2b upstream. Some bios really like to joke and start the planes at an offset ... hooray! Align start and end to fix this. v2: Fixup calculation of size, spotted by Chris Wilson. v3: Fix serious fumble I've just spotted. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883 Cc: Johannes W <jargon@molb.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-and-tested-by:
Johannes W <jargon@molb.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> [Jani: split WARN_ONs, rebase on v4.0-rc1] Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Oded Gabbay authored
commit 1365aa62 upstream. This patch fixes a bug in the initialization of the pipelines. The init_pipelines() function was called with a constant value of 0 in the first_pipe argument. This is an error because amdkfd doesn't handle pipe 0. The correct way is to pass the value that get_first_pipe() returns as the argument for first_pipe. This bug appeared in 3.19 (first version with amdkfd) and it causes around 15% drop in CPU performance of Kaveri (A10-7850). v2: Don't set get_first_pipe() as inline because it calls BUG_ON() Signed-off-by:
Oded Gabbay <oded.gabbay@amd.com> Tested-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Jesse Barnes authored
commit 5df0582b upstream. Looks like it was introduced in: commit 650ad970 Author: Imre Deak <imre.deak@intel.com> Date: Fri Apr 18 16:35:02 2014 +0300 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of but I'm not sure why. It has caused problems for us in the past (see 85250ddf "drm/i915/chv: Remove Wait for a previous gfx force-off" and 8d4eee9c "drm/i915: vlv: increase timeout when forcing on the GFX clock") and doesn't seem to be required, so let's just drop it. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by:
Darren Hart <dvhart@linux.intel.com> Reviewed-by:
Deepak S <deepak.s@linux.intel.com> Signed-off-by:
-
Jesse Barnes authored
commit 9c25210f upstream. Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this reg. If it's unlocked, we can just restore the previous value, and if it's locked (in case the BIOS re-programmed it for us) the write will be ignored and we'll still have "did it move" sanity check in the PM code to warn us if something is still amiss. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Deepak S authored
commit c9c52e24 upstream. On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a sticky bit and it will always be set. So ignore Check for previous Gfx force off during suspend and allow the force clk as part S0ix Sequence Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Christian König authored
commit 22e2e865 upstream. We need to wait for all fences, not just the exclusive one. Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Christian König authored
commit 863653fe upstream. We somehow try to free the SG table twice. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89734Signed-off-by:
-
Alex Deucher authored
commit 3899ca84 upstream. Need to expand the check to handle short circuiting if the selected state is the same as current state. bug: https://bugs.freedesktop.org/show_bug.cgi?id=87796Signed-off-by:
-
Ville Syrjälä authored
commit 840a1cf0 upstream. The legcy colorkey ioctls are only implemented for sprite planes, so reject the ioctl for primary/cursor planes. If we want to support colorkeying with these planes (assuming we have hw support of course) we should just move ahead with the colorkey property conversion. Testcase: kms_legacy_colorkey Cc: Tommi Rantala <tt.rantala@gmail.com> Reference: http://mid.gmane.org/CA+ydwtr+bCo7LJ44JFmUkVRx144UDFgOS+aJTfK6KHtvBDVuAw@mail.gmail.comReported-and-tested-by:
Tommi Rantala <tt.rantala@gmail.com> Signed-off-by:
-
Jani Nikula authored
commit ad692b46 upstream. If the user supplies EDID through firmware or debugfs override, the driver callbacks are bypassed and the connector ELD does not get updated, and audio fails. Set ELD for firmware and debugfs EDIDs too. There should be no harm in gratuitously doing this for non HDMI/DP connectors, as it's still up to the driver to use the ELD, if any. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82349 Reference: https://bugs.freedesktop.org/show_bug.cgi?id=80691Reported-by:
Emil <emilsvennesson@gmail.com> Reported-by:
Rob Engle <grenoble@gmail.com> Tested-by:
Jolan Luff <jolan@gormsby.com> Reviewed-by:
-
Daniel Vetter authored
commit 8218c3f4 upstream. Originally it was impossible to be dropping the last refcount in this function since there was always one around still from the idr. But in commit 83f45fc3 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 6 09:10:18 2014 +0200 drm: Don't grab an fb reference for the idr we've switched to weak references, broke that assumption but forgot to fix it up. Since we still force-disable planes it's only possible to hit this when racing multiple rmfb with fbdev restoring or similar evil things. As long as userspace is nice it's impossible to hit the BUG_ON. But the BUG_ON would most likely be hit from fbdev code, which usually invovles the console_lock besides all modeset locks. So very likely we'd never get the bug reports if this was hit in the wild, hence better be safe than sorry and backport. Spotted by Matt Roper while reviewing other patches. [airlied: pull this back into 4.0 - the oops happens there] Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Mike Snitzer authored
commit e9637415 upstream. Linux 3.19 commit 69c953c8 ("lib/lcm.c: lcm(n,0)=lcm(0,n) is 0, not n") caused blk_stack_limits() to not properly stack queue_limits for stacked devices (e.g. DM). Fix this regression by establishing lcm_not_zero() and switching blk_stack_limits() over to using it. DM uses blk_set_stacking_limits() to establish the initial top-level queue_limits that are then built up based on underlying devices' limits using blk_stack_limits(). In the case of optimal_io_size (io_opt) blk_set_stacking_limits() establishes a default value of 0. With commit 69c953c8, lcm(0, n) is no longer n, which compromises proper stacking of the underlying devices' io_opt. Test: $ modprobe scsi_debug dev_size_mb=10 num_tgts=1 opt_blks=1536 $ cat /sys/block/sde/queue/optimal_io_size 786432 $ dmsetup create node --table "0 100 linear /dev/sde 0" Before this fix: $ cat /sys/block/dm-5/queue/optimal_io_size 0 After this fix: $ cat /sys/block/dm-5/queue/optimal_io_size 786432 Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Acked-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Wenbo Wang authored
commit 7ee8e4f3 upstream. Use the right array index to reference the last element of rq->biotail->bi_io_vec[] Signed-off-by:
Wenbo Wang <wenbo.wang@memblaze.com> Reviewed-by:
Chong Yuan <chong.yuan@memblaze.com> Fixes: 66cb45aa ("block: add support for limiting gaps in SG lists") Signed-off-by:
-
Sam Bradshaw authored
commit bc188d81 upstream. When allocating from the reserved tags pool, bt_get() is called with a NULL hctx. If all tags are in use, the hw queue is kicked to push out any pending IO, potentially freeing tags, and tag allocation is retried. The problem is that blk_mq_run_hw_queue() doesn't check for a NULL hctx. So we avoid it with a simple NULL hctx test. Tested by hammering mtip32xx with concurrent smartctl/hdparm. Signed-off-by:
Sam Bradshaw <sbradshaw@micron.com> Signed-off-by:
Selvan Mani <smani@micron.com> Fixes: b3223207 ("blk-mq: fix hang in bt_get()") Added appropriate comment. Signed-off-by:
-
Mike Snitzer authored
commit 9a30b096 upstream. If percpu_ref_init() fails the allocated q and hctxs must get cleaned up; using 'err_map' doesn't allow that to happen. Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
-
Joe Perches authored
commit 6436a123 upstream. Return a negative error value like the rest of the entries in this function. Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
Stephen Smalley <sds@tycho.nsa.gov> [PM: tweaked subject line] Signed-off-by:
Paul Moore <pmoore@redhat.com> Signed-off-by:
-
Chen-Yu Tsai authored
commit fdc0074c upstream. As the sunxi usb clocks all contain a reset controller, it is not possible to build the sunxi clock driver without RESET_CONTROLLER enabled. Doing so results in an undefined symbol error: drivers/built-in.o: In function `sunxi_gates_clk_setup': linux/drivers/clk/sunxi/clk-sunxi.c:1071: undefined reference to `reset_controller_register' This is possible if building a minimal kernel without PHY_SUN4I_USB. The dependency issue is made visible at compile time instead of link time by the new A80 mmc clocks, which also use a reset control itself. This patch makes ARCH_SUNXI select ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER. Fixes: 559482d1 ARM: sunxi: Split the various SoCs support in Kconfig Reported-by:
Lourens Rozema <ik@lourensrozema.nl> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Vineet Gupta authored
commit e4140819 upstream. A malicious signal handler / restorer can DOS the system by fudging the user regs saved on stack, causing weird things such as sigreturn returning to user mode PC but cpu state still being kernel mode.... Ensure that in sigreturn path status32 always has U bit; any other bogosity (gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms. Reproducer signal handler: void handle_sig(int signo, siginfo_t *info, void *context) { ucontext_t *uc = context; struct user_regs_struct *regs = &(uc->uc_mcontext.regs); regs->scratch.status32 = 0; } Before the fix, kernel would go off to weeds like below: --------->8----------- [ARCLinux]$ ./signal-test Path: /signal-test CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65 task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000 [ECR ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698 [EFA ]: 0x00000010 [BLINK ]: 0x2007c1ee [ERET ]: 0x10698 [STAT32]: 0x00000000 : <-------- BTA: 0x00010680 SP: 0x5ffe7e48 FP: 0x00000000 LPS: 0x20003c6c LPE: 0x20003c70 LPC: 0x00000000 ... --------->8----------- Reported-by:
Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Vineet Gupta authored
commit 6914e1e3 upstream. The regfile provided to SA_SIGINFO signal handler as ucontext was off by one due to pt_regs gutter cleanups in 2013. Before handling signal, user pt_regs are copied onto user_regs_struct and copied back later. Both structs are binary compatible. This was all fine until commit 2fa91904 (ARC: pt_regs update #2) which removed the empty stack slot at top of pt_regs (corresponding to first pad) and made the corresponding fixup in struct user_regs_struct (the pad in there was moved out of @scratch - not removed altogether as it is part of ptrace ABI) struct user_regs_struct { + long pad; struct { - long pad; long bta, lp_start, lp_end,.... } scratch; ... } This meant that now user_regs_struct was off by 1 reg w.r.t pt_regs and signal code needs to user_regs_struct.scratch to reflect it as pt_regs, which is what this commit does. This problem was hidden for 2 years, because both save/restore, despite using wrong location, were using the same location. Only an interim inspection (reproducer below) exposed the issue. void handle_segv(int signo, siginfo_t *info, void *context) { ucontext_t *uc = context; struct user_regs_struct *regs = &(uc->uc_mcontext.regs); printf("regs %x %x\n", <=== prints 7 8 (vs. 8 9) regs->scratch.r8, regs->scratch.r9); } int main() { struct sigaction sa; sa.sa_sigaction = handle_segv; sa.sa_flags = SA_SIGINFO; sigemptyset(&sa.sa_mask); sigaction(SIGSEGV, &sa, NULL); asm volatile( "mov r7, 7 \n" "mov r8, 8 \n" "mov r9, 9 \n" "mov r10, 10 \n" :::"r7","r8","r9","r10"); *((unsigned int*)0x10) = 0; } Fixes: 2fa91904 "ARC: pt_regs update #2: Remove unused gutter at start of pt_regs" Signed-off-by:
-
Matwey V. Kornilov authored
commit a43f32d6 upstream. Struct spear13xx_pcie_driver was in initdata, but we passed a pointer to it to platform_driver_register(), which can use the pointer at arbitrary times in the future, even after the initdata is freed. That leads to crashes. Move spear13xx_pcie_driver and things referenced by it (spear13xx_pcie_probe() and dw_pcie_host_init()) out of initdata. [bhelgaas: changelog] Fixes: 6675ef21 ("PCI: spear: Fix Section mismatch compilation warning for probe()") Signed-off-by:
Matwey V. Kornilov <matwey@sai.msu.ru> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Bjorn Helgaas authored
commit 8647ca9a upstream. Booting a v3.18 or newer Xen domU kernel with PCI devices passed through results in an oops (this is a 32-bit 3.13.11 dom0 with a 64-bit 4.4.0 hypervisor and 32-bit domU): BUG: unable to handle kernel paging request at 0030303e IP: [<c06ed0e6>] acpi_ns_validate_handle+0x12/0x1a Call Trace: [<c06eda4d>] ? acpi_evaluate_object+0x31/0x1fc [<c06b78e1>] ? pci_get_hp_params+0x111/0x4e0 [<c0407bc7>] ? xen_force_evtchn_callback+0x17/0x30 [<c04085fb>] ? xen_restore_fl_direct_reloc+0x4/0x4 [<c0699d34>] ? pci_device_add+0x24/0x450 Don't look for ACPI configuration information if ACPI has been disabled. I don't think this is the best fix, because we can boot plain Linux (no Xen) with "acpi=off", and we don't need this check in pci_get_hp_params(). There should be a better fix that would make Xen domU work the same way. The domU kernel has ACPI support but it has no AML. There should be a way to initialize the ACPI data structures so things fail gracefully rather than oopsing. This is an interim fix to address the regression. Fixes: 6cd33649 ("PCI: Add pci_configure_device() during enumeration") Link: https://bugzilla.kernel.org/show_bug.cgi?id=96301Reported-by:
Michael D Labriola <mlabriol@gdeb.com> Tested-by:
-
Bjorn Helgaas authored
commit d10b730f upstream. This reverts commit d63e2e1f. David Ahern reported that d63e2e1f breaks booting on an 8-socket T5 sparc system. He also verified that the system boots with d63e2e1f reverted. Yinghai has some fixes, but they need a little more polishing than we can do before v4.0. Link: http://lkml.kernel.org/r/5514391F.2030300@oracle.com # report Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org # patches Signed-off-by:
-
Dan Carpenter authored
commit bc3b5b47 upstream. I don't have this hardware but it looks like we weren't adding bridge devices as intended. Maybe the bridge is always the last device? Fixes: 05b12500 ("PCI: cpcihp: Iterate over all devices in slot, not functions 0-7") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Yijing Wang <wangyijing@huawei.com> Signed-off-by:
-
Rasmus Villemoes authored
commit a1b7f2f6 upstream. Commit fab4c256 ("PCI/AER: Add a TLP header print helper") introduced the helper function __print_tlp_header(), but contrary to the intention, the behaviour did change: Since we're taking the address of the parameter t, the first 4 or 8 bytes printed will be the value of the pointer t itself, and the remaining 12 or 8 bytes will be who-knows-what (something from the stack). We want to show the values of the four members of the struct aer_header_log_regs; that can be done without ugly and error-prone casts. On little-endian this should produce the same output as originally intended, and since no-one has complained about getting garbage output so far, I think big-endian should be ok too. Fixes: fab4c256 ("PCI/AER: Add a TLP header print helper") Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit cc7016ab upstream. Some BIOS version of Fujitsu Lifebook T731 seems to set up the headphone pin (0x21) without the assoc number 0x0f while it's set only to the output on the docking port (0x1a). With the recent commit [03ad6a8c: ALSA: hda - Fix "PCM" name being used on one DAC when there are two DACs], this resulted in the weird mixer element mapping where the headphone on the laptop is assigned as a shared volume with the speaker and the docking port is assigned as an individual headphone. This patch improves the situation by correcting the headphone pin config to the more appropriate value. Reported-and-tested-by:
Taylor Smock <smocktaylor@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
