summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-08-08fs/ocfs2/cluster/tcp.c: fix possible null pointer dereferencesSunil Mushran
Fix some possible null pointer dereferences that were detected by the static code analyser, smatch. Signed-off-by: Sunil Mushran <sunil.mushran@oracle.com> Reported-by: Dan Carpenter <error27@gmail.com> Reported-by: Guozhonghua <guozhonghua@h3c.com> Cc: Sunil Mushran <sunil.mushran@gmail.com> Cc: Joseph Qi <joseph.qi@huawei.com> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08ocfs2: ac_bits_wanted should be local_alloc_bits when returns -ENOSPCYounger Liu
There is an issue in reserving and claiming space for localalloc, When localalloc space is not enough, it would claim space from global_bitmap. And if there is not enough free space in global_bitmap, the size of claiming space would set to half of orignal size and retry. The issue is as follows: osb->local_alloc_bits is set to half of orignal size in ocfs2_recalc_la_window(), but ac->ac_bits_wanted is set to osb->local_alloc_default_bits which is not changed. localalloc always reserves and claims local_alloc_default_bits space and returns ENOSPC. So, ac->ac_bits_wanted should be osb->local_alloc_bits which would be changed. Signed-off-by: Younger Liu <younger.liu@huawei.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Jeff Liu <jeff.liu@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08ocfs2: dlm_request_all_locks() should deal with the status sent from target nodeXue jiufei
dlm_request_all_locks() should deal with the status sent from target node if DLM_LOCK_REQUEST_MSG is sent successfully, or recovery master will fall into endless loop, waiting for other nodes to send locks and DLM_RECO_DATA_DONE_MSG to me. NodeA NodeB selected as recovery master dlm_remaster_locks() ->dlm_request_all_locks() send DLM_LOCK_REQUEST_MSG to nodeA It happened that NodeA cannot alloc memory when it processes this message. dlm_request_all_locks_handler() do not queue dlm_request_all_locks_worker and returns -ENOMEM. It will never send locks andDLM_RECO_DATA_DONE_MSG to NodeB. NodeB do not deal with the status sent from nodeA, and will fall in endless loop waiting for the recovery state of NodeA to be changed. Signed-off-by: joyce <xuejiufei@huawei.com> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Jeff Liu <jeff.liu@oracle.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08ocfs2: use i_size_read() to access i_sizeJunxiao Bi
Though ocfs2 uses inode->i_mutex to protect i_size, there are both i_size_read/write() and direct accesses. Clean up all direct access to eliminate confusion. Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com> Cc: Jie Liu <jeff.liu@oracle.com> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08ocfs2: lighten up allocate transactionYounger Liu
The issue scenario is as following: When fallocating a very large disk space for a small file, __ocfs2_extend_allocation attempts to get a very large transaction. For some journal sizes, there may be not enough room for this transaction, and the fallocate will fail. The patch below extends & restarts the transaction as necessary while allocating space, and should work with even the smallest journal. This patch refers ext4 resize. Test: # mkfs.ocfs2 -b 4K -C 32K -T datafiles /dev/sdc ...(jounral size is 32M) # mount.ocfs2 /dev/sdc /mnt/ocfs2/ # touch /mnt/ocfs2/1.log # fallocate -o 0 -l 400G /mnt/ocfs2/1.log fallocate: /mnt/ocfs2/1.log: fallocate failed: Cannot allocate memory # tail -f /var/log/messages [ 7372.278591] JBD: fallocate wants too many credits (2051 > 2048) [ 7372.278597] (fallocate,6438,0):__ocfs2_extend_allocation:709 ERROR: status = -12 [ 7372.278603] (fallocate,6438,0):ocfs2_allocate_unwritten_extents:1504 ERROR: status = -12 [ 7372.278607] (fallocate,6438,0):__ocfs2_change_file_space:1955 ERROR: status = -12 ^C With this patch, the test works well. Signed-off-by: Younger Liu <younger.liu@huawei.com> Cc: Jie Liu <jeff.liu@oracle.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Mark Fasheh <mfasheh@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08ocfs2: update inode size after zeronig the holeJunxiao Bi
fs-writeback will release the dirty pages without page lock whose offset are over inode size, the release happens at block_write_full_page_endio(). If not update, dirty pages in file holes may be released before flushed to the disk, then file holes will contain some non-zero data, this will cause sparse file md5sum error. To reproduce the bug, find a big sparse file with many holes, like vm image file, its actual size should be bigger than available mem size to make writeback work more frequently, tar it with -S option, then keep untar it and check its md5sum again and again until you get a wrong md5sum. Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com> Cc: Younger Liu <younger.liu@huawei.com> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08ocfs2-fix-issue-that-ocfs2_setattr-does-not-deal-with-new_i_size==i_size-v2Younger Liu
Compared with PATCH V1, bug description is updated, and pointless comments are removed. Signed-off-by: Younger Liu <younger.liu@huawei.com> Cc: Jie Liu <jeff.liu@oracle.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Sunil Mushran <sunil.mushran@gmail.com> Cc: Jensen <shencanquan@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08ocfs2: fix issue that ocfs2_setattr() does not deal with new_i_size==i_sizeYounger Liu
The issue scenario is as following: - Create a small file and fallocate a large disk space for a file with FALLOC_FL_KEEP_SIZE option. - ftruncate the file back to the original size again. but the disk free space is not changed back. This is a real bug that be fixed in this patch. In order to solve the issue above, we modified ocfs2_setattr(), if attr->ia_size != i_size_read(inode), It calls ocfs2_truncate_file(), and truncate disk space to attr->ia_size. Signed-off-by: Younger Liu <younger.liu@huawei.com> Reviewed-by: Jie Liu <jeff.liu@oracle.com> Tested-by: Jie Liu <jeff.liu@oracle.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Sunil Mushran <sunil.mushran@gmail.com> Reviewed-by: Jensen <shencanquan@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08ocfs2: llseek requires ocfs2 inode lock for the file in SEEK_ENDJensen
llseek requires ocfs2 inode lock for updating the file size in SEEK_END. because the file size maybe update on another node. This bug can be reproduce the following scenario: at first, we dd a test fileA, the file size is 10k. on NodeA: --------- 1) open the test fileA, lseek the end of file. and print the position. 2) close the test fileA on NodeB: 1) open the test fileA, append the 5k data to test FileA. 2) lseek the end of file. and print the position. 3) close file. At first we run the test program1 on NodeA , the result is 10k. And then run the test program2 on NodeB, the result is 15k. At last, we run the test program1 on NodeA again, the result is 10k. After applying this patch the three step result is 15k. Signed-off-by: Jensen <shencanquan@huawei.com> Cc: Jie Liu <jeff.liu@oracle.com> Acked-by: Joel Becker <jlbec@evilplan.org> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Sunil Mushran <sunil.mushran@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08ocfs2: should call ocfs2_journal_access_di() before ocfs2_delete_entry() in ↵Younger Liu
ocfs2_orphan_del() While deleting a file into orphan dir in ocfs2_orphan_del(), it calls ocfs2_delete_entry() before ocfs2_journal_access_di(). If ocfs2_delete_entry() succeeded and ocfs2_journal_access_di() failed, there would be a inconsistency: the file is deleted from orphan dir, but orphan dir dinode is not updated. So we need to call ocfs2_journal_access_di() before ocfs2_orphan_del(). Signed-off-by: Younger Liu <younger.liu@huawei.com> Reviewed-by: Jensen <shencanquan@huawei.com> Cc: Jie Liu <jeff.liu@oracle.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Mark Fasheh <mfasheh@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08isdn: clean up debug format string usageKees Cook
Avoid unneeded local string buffers for constructing debug output. Also cleans up debug calls that contain a single parameter so that they cannot be accidentally parsed as format strings. Signed-off-by: Kees Cook <keescook@chromium.org> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: David Miller <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08drivers/atm/he.c: convert to module_pci_driverLibo Chen
Signed-off-by: Libo Chen <libo.chen@huawei.com> Cc: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08mISDN: add support for group membership checkJeff Mahoney
This patch adds a module parameter to allow a group access to the mISDN devices. Otherwise, unpriviledged users on systems with ISDN hardware have the ability to dial out, potentially causing expensive bills. Based on a different implementation by Patrick Koppen. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Jeff Mahoney <jeffm@suse.com> Cc: Patrick Koppen <isdn4linux@koppen.de> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08drivers/net/ethernet/ibm/ehea/ehea_main.c: add alias entry for portN propertiesOlaf Hering
Use separate table for alias entries in the ehea module, otherwise the probe() function will operate on the separate ports instead of the lhea-"root" entry of the device-tree Addresses https://bugzilla.novell.com/show_bug.cgi?id=435215 Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Olaf Hering <ohering@suse.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08scripts/sortextable: support objects with more than 64K sections.Jamie Iles
Building with a large config and -ffunction-sections results in a large number of sections and sortextable needs to be able to handle that. Implement support for > 64K sections as modpost does. Signed-off-by: Jamie Iles <jamie.iles@oracle.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08drivers/infiniband/core/cm.c: convert to using idr_alloc_cyclic()Zhao Hongjiang
commit 3e6628c4b347 ("idr: introduce idr_alloc_cyclic()") adds a new idr_alloc_cyclic routine and converts several of these users to it. This is just a missed one - add it. Signed-off-by: Zhao Hongjiang <zhaohongjiang@huawei.com> Cc: Roland Dreier <roland@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: Sean Hefty <sean.hefty@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08timer_list: correct the iterator for timer_listNathan Zimmer
Correct the issue with /proc/timer_list reported by Holger. When reading from the proc file with a sufficiently small buffer, 2k so not really that small, there was one could get hung trying to read the file a chunk at a time. The timer_list_start function failed to account for the possibility that the offset was adjusted outside the timer_list_next. Signed-off-by: Nathan Zimmer <nzimmer@sgi.com> Reported-by: Holger Hans Peter Freyther <holger@freyther.de> Cc: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@vger.kernel.org> # 3.10.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08hrtimer: one more expiry time overflow check in hrtimer_interruptShinya Kuribayashi
When executing a date command to set the system date and time to a few seconds before the 2038 problem expiration time, we got a WARN_ON_ONCE() like this: root@renesas:~# date -s "2038-1-19 3:14:00" Tue Jan 19 03:14:00 GMT 2038 (then wait for 7-8 seconds) root@renesas:~# [ 27.662658] ------------[ cut here ]------------ [ 27.667297] WARNING: at kernel/time/clockevents.c:209 clockevents_program_event+0x3c/0x138() [ 27.675720] Modules linked in: [ 27.678802] [<c00130ec>] (unwind_backtrace+0x0/0xe0) from [<c001f4d8>] (warn_slowpath_common+0x4c/0x64) [ 27.688201] [<c001f4d8>] (warn_slowpath_common+0x4c/0x64) from [<c001f508>] (warn_slowpath_null+0x18/0x1c) [ 27.697845] [<c001f508>] (warn_slowpath_null+0x18/0x1c) from [<c00549bc>] (clockevents_program_event+0x3c/0x138) [ 27.708007] [<c00549bc>] (clockevents_program_event+0x3c/0x138) from [<c005510c>] (tick_program_event+0x2c/0x34) [ 27.718170] [<c005510c>] (tick_program_event+0x2c/0x34) from [<c003fa98>] (hrtimer_interrupt+0x268/0x2a8) [ 27.727752] [<c003fa98>] (hrtimer_interrupt+0x268/0x2a8) from [<c00180c8>] (cmt_timer_interrupt+0x2c/0x34) [ 27.737396] [<c00180c8>] (cmt_timer_interrupt+0x2c/0x34) from [<c0066748>] (handle_irq_event_percpu+0xb0/0x2a8) [ 27.747467] [<c0066748>] (handle_irq_event_percpu+0xb0/0x2a8) from [<c0066998>] (handle_irq_event+0x58/0x74) [ 27.757293] [<c0066998>] (handle_irq_event+0x58/0x74) from [<c0068f24>] (handle_fasteoi_irq+0xc0/0x148) [ 27.766662] [<c0068f24>] (handle_fasteoi_irq+0xc0/0x148) from [<c0066014>] (generic_handle_irq+0x20/0x30) [ 27.776245] [<c0066014>] (generic_handle_irq+0x20/0x30) from [<c000ef54>] (handle_IRQ+0x60/0x84) [ 27.785003] [<c000ef54>] (handle_IRQ+0x60/0x84) from [<c0009334>] (gic_handle_irq+0x34/0x4c) [ 27.793426] [<c0009334>] (gic_handle_irq+0x34/0x4c) from [<c000e2c0>] (__irq_svc+0x40/0x70) [ 27.801788] Exception stack(0xc04aff68 to 0xc04affb0) [ 27.806823] ff60: 00000000 f0100000 00000001 00000000 c04ae000 c04ec388 [ 27.815002] ff80: c04b604c c0840d80 40004059 412fc093 00000000 00000000 c04ce140 c04affb0 [ 27.823150] ffa0: c000f064 c000f068 60000013 ffffffff [ 27.828216] [<c000e2c0>] (__irq_svc+0x40/0x70) from [<c000f068>] (default_idle+0x24/0x2c) [ 27.836395] [<c000f068>] (default_idle+0x24/0x2c) from [<c000f338>] (cpu_idle+0x74/0xc8) [ 27.844451] [<c000f338>] (cpu_idle+0x74/0xc8) from [<c048c6d4>] (start_kernel+0x248/0x288) [ 27.852722] ---[ end trace 9d8ad385bde80fd3 ]--- [ 27.857330] hrtimer: interrupt took 0 ns This is triggered with our v3.4-based custom ARM kernel, but we confirmed that v3.10-rc can still have the same problem. I found a similar issue fixed in v3.9 by Prarit Bhargava in commit 8f294b5a13 ("hrtimer: Add expiry time overflow check in hrtimer_interrupt", 2013-04-08). It tried to resolve a overflow issue detected around 1970 + 100 seconds. On the other hand, we have another call site of tick_program_event() at the bottom of hrtimer_interrupt(). The warning this time is triggered there, so we need to apply the same fix to it. Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com> Reported-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08include/linux/interrupt.h: add dummy irq_set_irq_wake() for "!GENERIC_HARDIRQS"Chen Gang
Since irq_set_irq_wake() has already declared in header file, when GENERIC_HARDIRQS enabled. Recommend to define the dummy one for GENERIC_HARDIRQS disabled, and also let the other related "static inline" functions are independent from GENERIC_HARDIRQS. So can avoid the compiling error below, and also let the code simpler and clearer. The related compiling error (ARCH=s390 allmodconfig): sound/soc/codecs/wm0010.c: In function ‘wm0010_spi_probe’: sound/soc/codecs/wm0010.c:976:2: error: implicit declaration of function ‘irq_set_irq_wake’ [-Werror=implicit-function-declaration] Signed-off-by: Chen Gang <gang.chen@asianux.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08cyber2000fb: avoid palette corruption at higher clocksOndrej Zary
When 1280x1024@75Hz mode is set, console palette is not set properly - sometimes the background is white, sometimes yellow and text colors are also messed up. This does not happen at 1280x1024@60Hz and below. It seems that the HW needs some time before setting the palette - maybe the PLL needs more time to lock at higher speeds. This patch fixes the problem but without knowing what register to check for PLL lock(?), the delay might be excessive. On Fri, 28 Jan 2011 18:15:37 +0000 Russell King <rmk@arm.linux.org.uk> wrote: > On Tue, Jan 18, 2011 at 01:14:24PM -0800, Andrew Morton wrote: > > Russell, I have an (old) note here that this is awaiting an ack from > > yourself? > > Well, I can reproduce this problem on the Netwinders here. I'm not sure > that we should delay all mode switches by one second - and any attempt > to reduce this value does result in the palette not being set correctly. > > For 1280x1024-75, the dotclock is 135MHz, which gives a PLL values of > 0x41 and 0x06. That's: M=0x41+1, N=0x06+1, P=0x00 (top 2 bits of 0x06) > -> Q=1 > > Fpll = 14.31818MHz * M / N > Fout = Fpll / Q > > The PLL itself is formed by dividing the 14-ish MHz frequency by N and > phase comparing the output of the VCO, divided by M, and adjusting the > VCO until the two correlate. As VCOs typically tend to have a limited > range, it's normal to divide the output frequency to produce a greater > range - and in this case that's done by Q. > > For the 800x600-100 copied from /etc/fb.modes, this has a dotclock of > 67.5MHz, which is exactly half this rate. The PLL values for this are: > M=0x41+1, N=0x06+1, P=0x01, giving PLL values of 0x41 and 0x46. > > Booting with 800x600-100 does not suffer the problem. So it's not > related to PLL lock time. There's something else going on. > > Another experiment I tried was forcing the PLL values to produce 108MHz > instead of 135MHz. 108MHz is the dotclock for 1280x1024-60. This too > doesn't suffer the problem. > > I've also tried chosing other delay values. 100ms is too short and > produces the problem, but 1s works. 1s for a PLL to lock is a hell of > a time, especially for a PLL operating in the MHz range. > > I've tried setting the PLL to a known good freqency, and then switching > to 135MHz - the problem persists. It's not like 135MHz is reaching the > limits - it'll go up to 206MHz. > > So, I don't think this has anything to do with PLL locking. I think > there's something else going on which isn't immediately obvious - maybe > bandwidth starvation preventing us from writing properly to the palette? > As it's a horrible VGA, where you write the same register multiple times > I wouldn't be surprised if some writes were going missing. > > I'll see if I can play around with it some more this evening, but I've > spent an awful long time on just this issue already this afternoon... > > I think further investigation needs to happen on this patch before it's > acceptable. Or maybe we should prevent the cyberpro coming up in Signed-off-by: Ondrej Zary <linux@rainbow-software.org> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08drivers/video/acornfb.c: remove dead codePaul Bolle
acornfb checks for HAS_VIDC while support for that macro was removed in v2.6.23 (when the arm26 port was removed). So we can remove a bit of dead code. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08drm/nouveau: make vga_switcheroo code depend on VGA_SWITCHEROOJeff Mahoney
Commit 8116188fdef594 ("nouveau/acpi: hook up to the MXM method for mux switching.") broke the build on non-x86 architectures due to the new dependency on MXM and MXM being an x86 platform driver. It built previously since the vga switcheroo registration routines were zereod out on !X86. The code was built in but unused. This patch makes all of the DSM code depend on CONFIG_VGA_SWITCHEROO, allowing it to build on non-x86 and shrinking the module size as well. Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: David Airlie <airlied@linux.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08drm/cirrus: correct register values for 16bppTakashi Iwai
When the mode is set with 16bpp on QEMU, the output gets totally broken. The culprit is the bogus register values set for 16bpp, which was likely copied from from a wrong place. Addresses https://bugzilla.novell.com/show_bug.cgi?id=799216 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: David Airlie <airlied@linux.ie> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08drm/fb-helper: don't sleep for screen unblank when an oops is in progressDaniel Vetter
Otherwise the system will burn even brighter and worse, leave the user wondering what's going on exactly. Since we already have a panic handler which will (try) to restore the entire fbdev console mode, we can just bail out. Inspired by a patch from Konstantin Khlebnikov. The callchain leading to this, cut&pasted from Konstantin's original patch: callstack: panic() bust_spinlocks(1) unblank_screen() vc->vc_sw->con_blank() fbcon_blank() fb_blank() info->fbops->fb_blank() drm_fb_helper_blank() drm_fb_helper_dpms() drm_modeset_lock_all() mutex_lock(&dev->mode_config.mutex) Note that the entire locking in the fb helper around panic/sysrq and kdbg is ... non-existant. So we have a decent change of blowing up everything. But since reworking this ties in with funny concepts like the fbdev notifier chain or the impressive things which happen around console_lock while oopsing, I'll leave that as an exercise for braver souls than me. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Dave Airlie <airlied@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08drivers/pcmcia/yenta_socket.c: convert to module_pci_driverLibo Chen
Use module_pci_driver instead of init/exit, make code clean. Signed-off-by: Libo Chen <libo.chen@huawei.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Bill Pemberton <wfp5p@virginia.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Eric Miao <eric.y.miao@gmail.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08drivers/pcmcia/pd6729.c: convert to module_pci_driverLibo Chen
Use module_pci_driver instead of init/exit, make code clean. Signed-off-by: Libo Chen <libo.chen@huawei.com> Cc: Bill Pemberton <wfp5p@virginia.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Eric Miao <eric.y.miao@gmail.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08x86: make 'mem=' option to work for efi platformWen Congyang
Current mem boot option only can work for non efi environment. If the user specifies add_efi_memmap, it cannot work for efi environment. In the efi environment, we call e820_add_region() to add the memory map. So we can modify __e820_add_region() and the mem boot option can work for efi environment. Note: Only E820_RAM is limited, and BOOT_SERVICES_{CODE,DATA} are always mapped(If its address >= mem_limit, the memory won't be freed in efi_free_boot_services()). Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> Cc: Matt Fleming <matt.fleming@intel.com> Cc: Rob Landley <rob@landley.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Yasuaki ISIMATU <isimatu.yasuaki@jp.fujitsu.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08sh64: kernel: remove useless variable 'regs'Chen Gang
Remove useless variable 'regs' to avoid the related warnings (warning is treated as error). Signed-off-by: Chen Gang <gang.chen@asianux.com> Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08sh64: kernel: use 'usp' instead of 'fn'Chen Gang
'fn' is not defined, according to the implementation copy_thread() in 'sh32', need use 'usp' instead of. Signed-off-by: Chen Gang <gang.chen@asianux.com> Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08arch: *: Kconfig: add "kernel/Kconfig.freezer" to "arch/*/Kconfig"Chen Gang
All architectures include "kernel/Kconfig.freezer" except three left, so let them include it too, or 'allmodconfig' will report error. The related errors: (with allmodconfig for openrisc): CC kernel/cgroup_freezer.o kernel/cgroup_freezer.c: In function 'freezer_css_online': kernel/cgroup_freezer.c:133:15: error: 'system_freezing_cnt' undeclared (first use in this function) kernel/cgroup_freezer.c:133:15: note: each undeclared identifier is reported only once for each function it appears in kernel/cgroup_freezer.c: In function 'freezer_css_offline': kernel/cgroup_freezer.c:157:15: error: 'system_freezing_cnt' undeclared (first use in this function) kernel/cgroup_freezer.c: In function 'freezer_attach': kernel/cgroup_freezer.c:200:4: error: implicit declaration of function 'freeze_task' kernel/cgroup_freezer.c: In function 'freezer_apply_state': kernel/cgroup_freezer.c:371:16: error: 'system_freezing_cnt' undeclared (first use in this function) Signed-off-by: Chen Gang <gang.chen@asianux.com> Cc: Richard Kuo <rkuo@codeaurora.org> Cc: Jonas Bonn <jonas@southpole.se> Cc: Chen Liqin <liqin.chen@sunplusct.com> Cc: Lennox Wu <lennox.wu@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08ocfs2: fix null pointer dereference in ocfs2_dir_foreach_blk_id()Jeff Liu
Fix a NULL pointer deference while removing an empty directory, which was introduced by 3704412bdbf3 ("[readdir] convert ocfs2"). BUG: unable to handle kernel NULL pointer dereference at (null) IP: [< (null)>] (null) PGD 6da85067 PUD 6da89067 PMD 0 Oops: 0010 [#1] SMP CPU: 0 PID: 6564 Comm: rmdir Tainted: G O 3.11.0-rc1 #4 RIP: 0010:[<0000000000000000>] [< (null)>] (null) Call Trace: [<ffffffffa038a30e>] ? ocfs2_dir_foreach_blk_id+0x17e/0x220 [ocfs2] [<ffffffffa038e5f9>] ocfs2_dir_foreach+0x49/0x50 [ocfs2] [<ffffffffa038ec2c>] ocfs2_empty_dir+0x12c/0x3e0 [ocfs2] [<ffffffffa03b3ade>] ocfs2_unlink+0x56e/0xc10 [ocfs2] [<ffffffff811b3a05>] vfs_rmdir+0xd5/0x140 [<ffffffff811b3c3b>] do_rmdir+0x1cb/0x1e0 [<ffffffff813697f4>] ? lockdep_sys_exit_thunk+0x35/0x67 [<ffffffff8136977e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff811b6996>] SyS_rmdir+0x16/0x20 [<ffffffff816e2a82>] system_call_fastpath+0x16/0x1b Code: Bad RIP value. RIP [< (null)>] (null) RSP <ffff88006daddc10> CR2: 0000000000000000 Signed-off-by: Jie Liu <jeff.liu@oracle.com> Reported-by: David Weber <wb@munzinger.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Joel Becker <jlbec@evilplan.org> Cc: Mark Fasheh <mfasheh@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08x86 get_unmapped_area(): use proper mmap base for bottom-up directionRadu Caragea
When the stack is set to unlimited, the bottomup direction is used for mmap-ings but the mmap_base is not used and thus effectively renders ASLR for mmapings along with PIE useless. Cc: Michel Lespinasse <walken@google.com> Cc: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Rik van Riel <riel@redhat.com> Acked-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Sendroiu <molecula2788@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08aoe: adjust ref of head for compound page tailsEd Cashin
As discussed previously, the fact that some users of the block layer provide bios that point to pages with a zero _count means that it is not OK for the network layer to do a put_page on the skb frags during an skb_linearize, so the aoe driver gets a reference to pages in bios and puts the reference before ending the bio. And because it cannot use get_page on a page with a zero _count, it manipulates the value directly. It is not OK to increment the _count of a compound page tail, though, since the VM layer will VM_BUG_ON a non-zero _count. Block users that do direct I/O can result in the aoe driver seeing compound page tails in bios. In that case, the same logic works as long as the head of the compound page is used instead of the tails. This patch handles compound pages and does not BUG. It relies on the block layer user leaving the relationship between the page tail and its head alone for the duration between the submission of the bio and its completion, whether successful or not. Signed-off-by: Ed Cashin <ecashin@coraid.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08microblaze: fix clone syscallMichal Simek
Fix inadvertent breakage in the clone syscall ABI for Microblaze that was introduced in f3268edb ("microblaze: switch to generic fork/vfork/clone"). The Microblaze syscall ABI for clone takes the parent tid address in the 4th argument; the third argument slot is used for the stack size. The incorrectly-used CLONE_BACKWARDS type assigned parent tid to the 3rd slot. This commit restores the original ABI so that existing userspace libc code will work correctly. All kernel versions from v3.8-rc1 were affected. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08mm: save soft-dirty bits on file pagesCyrill Gorcunov
Andy reported that if file page get reclaimed we lose the soft-dirty bit if it was there, so save _PAGE_BIT_SOFT_DIRTY bit when page address get encoded into pte entry. Thus when #pf happens on such non-present pte we can restore it back. Reported-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Acked-by: Pavel Emelyanov <xemul@parallels.com> Cc: Matt Mackall <mpm@selenic.com> Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08mm: save soft-dirty bits on swapped pagesCyrill Gorcunov
Andy Lutomirski reported that if a page with _PAGE_SOFT_DIRTY bit set get swapped out, the bit is getting lost and no longer available when pte read back. To resolve this we introduce _PTE_SWP_SOFT_DIRTY bit which is saved in pte entry for the page being swapped out. When such page is to be read back from a swap cache we check for bit presence and if it's there we clear it and restore the former _PAGE_SOFT_DIRTY bit back. One of the problem was to find a place in pte entry where we can save the _PTE_SWP_SOFT_DIRTY bit while page is in swap. The _PAGE_PSE was chosen for that, it doesn't intersect with swap entry format stored in pte. Reported-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Acked-by: Pavel Emelyanov <xemul@parallels.com> Cc: Matt Mackall <mpm@selenic.com> Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> Reviewed-by: Minchan Kim <minchan@kernel.org> Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08memcg: don't initialize kmem-cache destroying work for root cachesAndrey Vagin
struct memcg_cache_params has a union. Different parts of this union are used for root and non-root caches. A part with destroying work is used only for non-root caches. I fixed the same problem in another place v3.9-rc1-16204-gf101a94, but didn't notice this one. Signed-off-by: Andrey Vagin <avagin@openvz.org> Cc: Glauber Costa <glommer@openvz.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Balbir Singh <bsingharora@gmail.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: <stable@vger.kernel.org> [3.9.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-08include/linux/smp.h:on_each_cpu(): switch back to a C functionAndrew Morton
Revert c846ef7deba2d4f751 ("include/linux/smp.h:on_each_cpu(): switch back to a macro"). It turns out that the problematic linux/irqflags.h include was fixed within ia64 and mn10300. Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: David Daney <david.daney@cavium.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2013-08-06Merge branch 'for-3.11-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata Pull libata fix from Tejun Heo: "Just the addition of MODULE_DEVICE_TABLE() for a platform driver" * 'for-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata: pata_imx: expose module alias for loading from device-tree
2013-08-06Merge branch 'for-3.11-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fix from Tejun Heo: "Fix for a minor memory leak bug in the cgroup init failure path" * 'for-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup: fix a leak when percpu_ref_init() fails
2013-08-06Merge branch 'for-3.11-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq Pull two workqueue fixes from Tejun Heo: "A lockdep notation update so that nested work_on_cpu() invocations don't lead to spurious lockdep warnings and fix for an unbound attr bug which made what's shown in sysfs deviate from the actual ones. Both patches have pretty limited scope" * 'for-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: copy workqueue_attrs with all fields workqueue: allow work_on_cpu() to be called recursively
2013-08-06Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull misc x86 fixes from Peter Anvin. * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86, amd, microcode: Fix error path in apply_microcode_amd() x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz x86, efi: correct call to free_pages x86/iommu/vt-d: Expand interrupt remapping quirk to cover x58 chipset
2013-08-06printk: Fix return of braille_register_console()Steven Rostedt
Some of my configs I test with have CONFIG_A11Y_BRAILLE_CONSOLE set. When I started testing against v3.11-rc4 my console went bonkers. Using ktest to bisect the issue, it came down to: commit bbeddf52a "printk: move braille console support into separate braille.[ch] files" Looking into the patch I found the problem. It's with the return of braille_register_console(). As anything other than NULL is considered a failure. But for those of us that have CONFIG_A11Y_BRAILLE_CONSOLE set but do not define a "brl" or "brl=" on the command line, we still may want a console that those with sight can still use. Return NULL (success) if "brl" or "brl=" is not on the console line. Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Acked-by: Joe Perches <joe@perches.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-08-06Revert "ptrace: PTRACE_DETACH should do flush_ptrace_hw_breakpoint(child)"Oleg Nesterov
This reverts commit fab840fc2d542fabcab903db8e03589a6702ba5f. This commit even has the test-case to prove that the tracee can be killed by SIGTRAP if the debugger does not remove the breakpoints before PTRACE_DETACH. However, this is exactly what wineserver deliberately does, set_thread_context() calls PTRACE_ATTACH + PTRACE_DETACH just for PTRACE_POKEUSER(DR*) in between. So we should revert this fix and document that PTRACE_DETACH should keep the breakpoints. Reported-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-08-06Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds
Pull MIPS fixes from Ralf Baechle: "Two platform-specific fixes plus a fix for oprofile which was calling smp_processor_id() in preemptible code" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: BMIPS: fix hardware interrupt routing for boot CPU != 0 MIPS: oprofile: Fix BUG due to smp_processor_id() in preemptible code. MIPS: PNX833x: PNX8335_PCI_ETHERNET_INT depends on CONFIG_SOC_PNX8335
2013-08-06Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "Enable LZ4 compression for the kernel image, add the machine id for the new zBC12 model, fix an issue with hanging dasd devices, correct a Kconfig dependency, fix a compile error in the perf module with CONFIG_KVM=n and fix the find_next_bit_left primitive for the PCI base layer" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/dasd: fix hanging devices after path events s390/perf: fix compile error (undefined reference sie_exit) s390/bitops: fix find_next_bit_left s390: add support for IBM zBC12 machine s390/Kconfig: select 'TTY' when 'S390_GUEST' is enabled s390: add support for LZ4-compressed kernel
2013-08-06userns: unshare_userns(&cred) should not populate cred on failureOleg Nesterov
unshare_userns(new_cred) does *new_cred = prepare_creds() before create_user_ns() which can fail. However, the caller expects that it doesn't need to take care of new_cred if unshare_userns() fails. We could change the single caller, sys_unshare(), but I think it would be more clean to avoid the side effects on failure, so with this patch unshare_userns() does put_cred() itself and initializes *new_cred only if create_user_ns() succeeeds. Cc: stable@vger.kernel.org Signed-off-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-08-05MIPS: BMIPS: fix hardware interrupt routing for boot CPU != 0Florian Fainelli
The hardware interrupt routing for boot CPU != 0 is wrong because it will route all the hardware interrupts to TP0 which is not the one we booted from. Fix this by properly checking which boot CPU we are booting from and updating the right interrupt mask for the boot CPU. This fixes booting on BCM3368 with bmips_smp_emabled = 0. Signed-off-by: Florian Fainelli <florian@openwrt.org> Cc: linux-mips@linux-mips.org Cc: blogic@openwrt.org Cc: jogo@openwrt.org Cc: cernekee@gmail.com Patchwork: https://patchwork.linux-mips.org/patch/5650/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-08-05MIPS: oprofile: Fix BUG due to smp_processor_id() in preemptible code.Ralf Baechle
current_cpu_type() is not preemption-safe. If CONFIG_PREEMPT is enabled then mipsxx_reg_setup() can be called from preemptible state. Added get_cpu()/put_cpu() pair to make it preemption-safe. This was found while testing oprofile with CONFIG_DEBUG_PREEMPT enable. /usr/zntestsuite # opcontrol --init /usr/zntestsuite # opcontrol --setup --event=L2_CACHE_ACCESSES:500 --event=L2_CACHE_MISSES:500 --no-vmlinux /usr/zntestsuite # opcontrol --start Using 2.6+ OProfile kernel interface. BUG: using smp_processor_id() in preemptible [00000000] code: oprofiled/1362 caller is mipsxx_reg_setup+0x11c/0x164 CPU: 0 PID: 1362 Comm: oprofiled Not tainted 3.10.4 #18 Stack : 00000006 70757465 00000000 00000000 00000000 00000000 80b173f6 00000037 80b10000 00000000 80b21614 88f5a220 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 89c49c00 89c49c2c 80721254 807b7927 8012c1d0 80b10000 80721254 00000000 00000552 88f5a220 80b1335c 807b78e6 89c49ba8 ... Call Trace: [<801099a4>] show_stack+0x64/0x7c [<80665520>] dump_stack+0x20/0x2c [<803a2250>] debug_smp_processor_id+0xe0/0xf0 [<8052df24>] mipsxx_reg_setup+0x11c/0x164 [<8052cd70>] op_mips_setup+0x24/0x4c [<80529cfc>] oprofile_setup+0x5c/0x12c [<8052b9f8>] event_buffer_open+0x78/0xf8 [<801c3150>] do_dentry_open.isra.15+0x2b8/0x3b0 [<801c3270>] finish_open+0x28/0x4c [<801d49b8>] do_last.isra.41+0x2cc/0xd00 [<801d54a0>] path_openat+0xb4/0x4c4 [<801d5c44>] do_filp_open+0x3c/0xac [<801c4744>] do_sys_open+0x110/0x1f4 [<8010f47c>] stack_done+0x20/0x44 Bug reported and original patch by Jerin Jacob <jerinjacobk@gmail.com>. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Acked-by: Jerin Jacob <jerinjacobk@gmail.com>
2013-08-05MIPS: PNX833x: PNX8335_PCI_ETHERNET_INT depends on CONFIG_SOC_PNX8335Markos Chandras
The PNX8335_PCI_ETHERNET_INT macro is defined in arch/mips/include/asm/mach-pnx833x/irq-mapping.h only if CONFIG_SOC_PNX8335 is selected. Fixes the following randconfig problem: arch/mips/pnx833x/common/platform.c:210:12: error: 'PNX8335_PIC_ETHERNET_INT' undeclared here (not in a function) Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Acked-by: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/5585/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>