- 12 Sep, 2014 40 commits
-
-
Michal Schmidt authored
When running RHEL6 userspace on a current upstream kernel, "ip link" fails to show VF information. The reason is a kernel<->userspace API change introduced by commit 88c5b5ce ("rtnetlink: Call nlmsg_parse() with correct header length"), after which the kernel does not see iproute2's IFLA_EXT_MASK attribute in the netlink request. iproute2 adjusted for the API change in its commit 63338dca4513 ("libnetlink: Use ifinfomsg instead of rtgenmsg in rtnl_wilddump_req_filter"). The problem has been noticed before: http://marc.info/?l=linux-netdev&m=136692296022182&w=2 (Subject: Re: getting VF link info seems to be broken in 3.9-rc8) We can do better than tell those with old userspace to upgrade. We can recognize the old iproute2 in the kernel by checking the netlink message length. Even when including the IFLA_EXT_MASK attribute, its netlink message is shorter than struct ifinfomsg. With this patch "ip link" shows VF information in both old and new iproute2 versions. Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit e5eca6d4) Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Gavin Guo authored
When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller [1022:7814], the second hotplugging will experience the USB 3.0 pen drive is recognized as high-speed device. After bisecting the kernel, I found the commit number 41e7e056 (USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing some experiments, the bug can be fixed by avoiding executing the function hub_usb3_port_disable(). Because the port status with [AMD] FCH USB XHCI Controlleris [1022:7814] is already in RxDetect (I tried printing out the port status before setting to Disabled state), it's reasonable to check the port status before really executing hub_usb3_port_disable(). Fixes: 41e7e056 (USB: Allow USB 3.0 ports to be disabled.) Signed-off-by:
Gavin Guo <gavin.guo@canonical.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Cc: <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit bb86cf56) Signed-off-by:
-
Guenter Roeck authored
Temperature limit registers are signed. Limits therefore need to be clamped to (-128, 127) degrees C and not to (0, 255) degrees C. Without this fix, writing a limit of 128 degrees C sets the actual limit to -128 degrees C. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Cc: stable@vger.kernel.org Reviewed-by:
Axel Lin <axel.lin@ingics.com> (cherry picked from commit de12d6f4) Signed-off-by:
-
Alex Shi authored
There is div64_long() to handle the s64/long division, but no mocro do u64/ul division. It is necessary in some scenarios, so add this function. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Alex Shi <alex.shi@intel.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit c2853c8d) Signed-off-by:
-
Martin Lau authored
ring_buffer_poll_wait() should always put the poll_table to its wait_queue even there is immediate data available. Otherwise, the following epoll and read sequence will eventually hang forever: 1. Put some data to make the trace_pipe ring_buffer read ready first 2. epoll_ctl(efd, EPOLL_CTL_ADD, trace_pipe_fd, ee) 3. epoll_wait() 4. read(trace_pipe_fd) till EAGAIN 5. Add some more data to the trace_pipe ring_buffer 6. epoll_wait() -> this epoll_wait() will block forever ~ During the epoll_ctl(efd, EPOLL_CTL_ADD,...) call in step 2, ring_buffer_poll_wait() returns immediately without adding poll_table, which has poll_table->_qproc pointing to ep_poll_callback(), to its wait_queue. ~ During the epoll_wait() call in step 3 and step 6, ring_buffer_poll_wait() cannot add ep_poll_callback() to its wait_queue because the poll_table->_qproc is NULL and it is how epoll works. ~ When there is new data available in step 6, ring_buffer does not know it has to call ep_poll_callback() because it is not in its wait queue. Hence, block forever. Other poll implementation seems to call poll_wait() unconditionally as the very first thing to do. For example, tcp_poll() in tcp.c. Link: http://lkml.kernel.org/p/20140610060637.GA14045@devbig242.prn2.facebook.com Cc: stable@vger.kernel.org # 2.6.27 Fixes: 2a2cc8f7 "ftrace: allow the event pipe to be polled" Reviewed-by:
Chris Mason <clm@fb.com> Signed-off-by:
Martin Lau <kafai@fb.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> (cherry picked from commit 97b8ee84) Signed-off-by:
-
Alex Deucher authored
If there are error flags in the aux transaction return -EIO rather than -EBUSY. -EIO restarts the whole transaction while -EBUSY jus retries. Fixes problematic aux transfers. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80684Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org (cherry picked from commit f6be5e64) Signed-off-by:
-
Joe Thornber authored
There's a race condition between the atomic_dec_and_test(&io->count) in dec_count() and the waking of the sync_io() thread. If the thread is spuriously woken immediately after the decrement it may exit, making the on stack io struct invalid, yet the dec_count could still be using it. Fix this race by using a completion in sync_io() and dec_count(). Reported-by:
Minfei Huang <huangminfei@ucloud.cn> Signed-off-by:
Joe Thornber <thornber@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Acked-by:
Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org (cherry picked from commit 10f1d5d1) Signed-off-by:
-
Miklos Szeredi authored
As suggested by checkpatch.pl, use time_before64() instead of direct comparison of jiffies64 values. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Cc: <stable@vger.kernel.org> (cherry picked from commit 126b9d43) Signed-off-by:
-
Thomas Hellstrom authored
Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register: SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to SVGA_REG_PITCHLOCK. This patch is Cc'd stable because of the unknown effects writing to this register might have, particularly on older device versions. v2: Updated log message. Cc: stable@vger.kernel.org Cc: Christopher Friedt <chrisfriedt@gmail.com> Tested-by:
Christopher Friedt <chrisfriedt@gmail.com> Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com> (cherry picked from commit 4e578080) Signed-off-by:
-
Ben Hutchings authored
This reverts commit 59d9f389, which was commit ca6c5d4a upstream. It is a valid fix, but depends on sk_buff::local_df being set in all the right cases, which it wasn't in 3.2. We need to defer it unless and until the other fixes are also backported to 3.2.y. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> (cherry picked from commit 8bbfe822) (cherry picked from commit HEAD) Signed-off-by:
-
James Bottomley authored
We unconditionally execute scsi_eh_get_sense() to make sure all failed commands that should have sense attached, do. However, the routine forgets that some commands, because of the way they fail, will not have any sense code ... we should not bother them with a REQUEST_SENSE command. Fix this by testing to see if we actually got a CHECK_CONDITION return and skip asking for sense if we don't. Tested-by:
James Bottomley <JBottomley@Parallels.com> (cherry picked from commit d555a2ab) Signed-off-by:
-
Michal Schmidt authored
Any process is able to send netlink messages with leftover bytes. Make the warning rate-limited to prevent too much log spam. The warning is supposed to help find userspace bugs, so print the triggering command name to implicate the buggy program. [v2: Use pr_warn_ratelimited instead of printk_ratelimited.] Signed-off-by:
-
Markos Chandras authored
Add _TIF_SECCOMP flag to _TIF_WORK_SYSCALL_ENTRY to indicate that the system call needs to be checked against a seccomp filter. Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Reviewed-by:
Paul Burton <paul.burton@imgtec.com> Reviewed-by:
James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6405/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> (cherry picked from commit 137f7df8) Signed-off-by:
-
Ralf Baechle authored
This will simplify further modifications. Signed-off-by:
-
James Bottomley authored
In the highly unusual case where two threads are running concurrently through the scanning code scanning the same target, we run into the situation where one may allocate the target while the other is still using it. In this case, because the reap checks for STARGET_CREATED and kills the target without reference counting, the second thread will do the wrong thing on reap. Fix this by reference counting even creates and doing the STARGET_CREATED check in the final put. Tested-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org # delay backport for 2 months for field testing Signed-off-by:
-
James Bottomley authored
This patch eliminates the reap_ref and replaces it with a proper kref. On last put of this kref, the target is removed from visibility in sysfs. The final call to scsi_target_reap() for the device is done from __scsi_remove_device() and only if the device was made visible. This ensures that the target disappears as soon as the last device is gone rather than waiting until final release of the device (which is often too long). Reviewed-by:
-
Zhaowei Yuan authored
If user uses wrong ioctl command with _IOC_NONE and argument size greater than 0, it can cause NULL pointer access from memset of line 463. If _IOC_NONE, don't memset to 0 for kdata. Signed-off-by:
Zhaowei Yuan <zhaowei.yuan@samsung.com> Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 1539fb9b) Signed-off-by:
-
Thomas Gleixner authored
Even in the case when deadlock detection is not requested by the caller, we can detect deadlocks. Right now the code stops the lock chain walk and keeps the waiter enqueued, even on itself. Silly not to yell when such a scenario is detected and to keep the waiter enqueued. Return -EDEADLK unconditionally and handle it at the call sites. The futex calls return -EDEADLK. The non futex ones dequeue the waiter, throw a warning and put the task into a schedule loop. Tagged for stable as it makes the code more robust. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Brad Mouring <bmouring@ni.com> Link: http://lkml.kernel.org/r/20140605152801.836501969@linutronix.de Cc: stable@vger.kernel.org Signed-off-by:
-
David Henningsson authored
According to the bug reporter (Данило Шеган), the external mic starts to work and has proper jack detection if only pin 0x19 is marked properly as an external headset mic. AlsaInfo at https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1328587/+attachment/4128991/+files/AlsaInfo.txt Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1328587Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> (cherry picked from commit 2041d564) Signed-off-by:
-
Benjamin Tissoires authored
commit 421e08c4 fixed the reported min/max for the X and Y axis, but unfortunately, it broke the resolution of those same axis. On the t540p, the resolution is the same regarding X and Y. It is not a problem for xf86-input-synaptics because this driver is only interested in the ratio between X and Y. Unfortunately, xf86-input-cmt uses directly the resolution, and having a null resolution leads to some divide by 0 errors, which are translated by -infinity in the resulting coordinates. Reported-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> (cherry picked from commit d49cb7ae) Signed-off-by:
-
Benny Halevy authored
This fixes a bug in the handling of the fi_delegations list. nfs4_setlease does not hold the recall_lock when adding to it. The client_mutex is held, which prevents against concurrent list changes, but nfsd_break_deleg_cb does not hold while walking it. New delegations could theoretically creep onto the list while we're walking it there. Signed-off-by:
Benny Halevy <bhalevy@primarydata.com> Signed-off-by:
Jeff Layton <jlayton@primarydata.com> Cc: stable@vger.kernel.org Signed-off-by:
J. Bruce Fields <bfields@redhat.com> (cherry picked from commit 931ee56c) Signed-off-by:
-
Jérôme Carretero authored
This device normally comes with a proprietary driver, using a web GUI to configure RAID: http://www.highpoint-tech.com/USA_new/series_rr600-download.htm But thankfully it also works out of the box with the AHCI driver, being just a Marvell 88SE9235. Devices 640L, 644L, 644LS should also be supported but not tested here. Signed-off-by:
Jérôme Carretero <cJ-ko@zougloub.eu> Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org (cherry picked from commit d2518365) Signed-off-by:
-
Yann Droneaud authored
The i386 ABI disagrees with most other ABIs regarding alignment of data types larger than 4 bytes: on most ABIs a padding must be added at end of the structures, while it is not required on i386. So for most ABI struct c4iw_create_cq_resp gets implicitly padded to be aligned on a 8 bytes multiple, while for i386, such padding is not added. The tool pahole can be used to find such implicit padding: $ pahole --anon_include \ --nested_anon_include \ --recursive \ --class_name c4iw_create_cq_resp \ drivers/infiniband/hw/cxgb4/iw_cxgb4.o Then, structure layout can be compared between i386 and x86_64: +++ obj-i386/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 11:43:05.547432195 +0100 --- obj-x86_64/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 10:55:10.990133017 +0100 @@ -14,9 +13,8 @@ struct c4iw_create_cq_resp { __u32 size; /* 28 4 */ __u32 qid_mask; /* 32 4 */ - /* size: 36, cachelines: 1, members: 6 */ - /* last cacheline: 36 bytes */ + /* size: 40, cachelines: 1, members: 6 */ + /* padding: 4 */ + /* last cacheline: 40 bytes */ }; This ABI disagreement will make an x86_64 kernel try to write past the buffer provided by an i386 binary. When boundary check will be implemented, the x86_64 kernel will refuse to write past the i386 userspace provided buffer and the uverbs will fail. If the structure is on a page boundary and the next page is not mapped, ib_copy_to_udata() will fail and the uverb will fail. This patch adds an explicit padding at end of structure c4iw_create_cq_resp, and, like 92b0ca7c ("IB/mlx5: Fix stack info leak in mlx5_ib_alloc_ucontext()"), makes function c4iw_create_cq() not writting this padding field to userspace. This way, x86_64 kernel will be able to write struct c4iw_create_cq_resp as expected by unpatched and patched i386 libcxgb4. Link: http://marc.info/?i=cover.1399309513.git.ydroneaud@opteya.com Cc: <stable@vger.kernel.org> Fixes: cfdda9d7 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC") Fixes: e24a72a3 ("RDMA/cxgb4: Fix four byte info leak in c4iw_create_cq()") Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:Yann Droneaud <ydroneaud@opteya.com> Acked-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> (cherry picked from commit b6f04d3d) Signed-off-by:
-
Dan Carpenter authored
commit e24a72a3 upstream. There is a four byte hole at the end of the "uresp" struct after the ->qid_mask member. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Thomas Gleixner authored
The current deadlock detection logic does not work reliably due to the following early exit path: /* * Drop out, when the task has no waiters. Note, * top_waiter can be NULL, when we are in the deboosting * mode! */ if (top_waiter && (!task_has_pi_waiters(task) || top_waiter != task_top_pi_waiter(task))) goto out_unlock_pi; So this not only exits when the task has no waiters, it also exits unconditionally when the current waiter is not the top priority waiter of the task. So in a nested locking scenario, it might abort the lock chain walk and therefor miss a potential deadlock. Simple fix: Continue the chain walk, when deadlock detection is enabled. We also avoid the whole enqueue, if we detect the deadlock right away (A-A). It's an optimization, but also prevents that another waiter who comes in after the detection and before the task has undone the damage observes the situation and detects the deadlock and returns -EDEADLOCK, which is wrong as the other task is not in a deadlock situation. Signed-off-by:
-
Johan Hovold authored
Make sure to check return value of autopm get in write() in order to avoid urb leak and PM counter imbalance on errors. Fixes: 11ea859d ("USB: additional power savings for cdc-acm devices that support remote wakeup") Cc: <stable@vger.kernel.org> # v2.6.27 Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Rik van Riel authored
It is possible for "limit - setpoint + 1" to equal zero, after getting truncated to a 32 bit variable, and resulting in a divide by zero error. Using the fully 64 bit divide functions avoids this problem. It also will cause pos_ratio_polynom() to return the correct value when (setpoint - limit) exceeds 2^32. Also uninline pos_ratio_polynom, at Andrew's request. Signed-off-by:
Rik van Riel <riel@redhat.com> Reviewed-by:
Michal Hocko <mhocko@suse.cz> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Cc: Luiz Capitulino <lcapitulino@redhat.com> Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
paul.szabo@sydney.edu.au authored
In bdi_position_ratio(), get difference (setpoint-dirty) right even when negative. Both setpoint and dirty are unsigned long, the difference was zero-padded thus wrongly sign-extended to s64. This issue affects all 32-bit architectures, does not affect 64-bit architectures where long and s64 are equivalent. In this function, dirty is between freerun and limit, the pseudo-float x is between [-1,1], expected to be negative about half the time. With zero-padding, instead of a small negative x we obtained a large positive one so bdi_position_ratio() returned garbage. Casting the difference to s64 also prevents overflow with left-shift; though normally these numbers are small and I never observed a 32-bit overflow there. (This patch does not solve the PAE OOM issue.) Paul Szabo psz@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia Reviewed-by:
Jan Kara <jack@suse.cz> Reported-by:
Paul Szabo <psz@maths.usyd.edu.au> Reference: http://bugs.debian.org/695182Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> (cherry picked from commit ed84825b) Signed-off-by:
-
Oleg Nesterov authored
get_user_pages(mm) is simply wrong if mm->mm_users == 0 and exit_mmap/etc was already called (or is in progress), mm->mm_count can only pin mm->pgd and mm_struct itself. Change kvm_setup_async_pf/async_pf_execute to inc/dec mm->mm_users. kvm_create_vm/kvm_destroy_vm play with ->mm_count too but this case looks fine at first glance, it seems that this ->mm is only used to verify that current->mm == kvm->mm. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 41c22f62) Signed-off-by:
-
Radim Krčmář authored
'.done' is used to mark the completion of 'async_pf_execute()', but 'cancel_work_sync()' returns true when the work was canceled, so we use it instead. Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Reviewed-by:
Gleb Natapov <gleb@redhat.com> Signed-off-by:
-
Radim Krčmář authored
When we cancel 'async_pf_execute()', we should behave as if the work was never scheduled in 'kvm_setup_async_pf()'. Fixes a bug when we can't unload module because the vm wasn't destroyed. Signed-off-by:
-
Kazuya Mio authored
When we try to get 2^32-1 block of the file which has the extent (ee_block=2^32-2, ee_len=1) with FIBMAP ioctl, it causes BUG_ON in ext4_ext_put_gap_in_cache(). To avoid the problem, ext4_map_blocks() needs to check the file logical block number. ext4_ext_put_gap_in_cache() called via ext4_map_blocks() cannot handle 2^32-1 because the maximum file logical block number is 2^32-2. Note that ext4_ind_map_blocks() returns -EIO when the block number is invalid. So ext4_map_blocks() should also return the same errno. Signed-off-by:
Kazuya Mio <k-mio@sx.jp.nec.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Cc: stable@vger.kernel.org (cherry picked from commit 4adb6ab3) Signed-off-by:
-
Ben Hutchings authored
This reverts commit b93b90ff, which was commit 0ef38d70 upstream. It was intended to fix a regression which never occurred in 3.2. (cherry picked from commit 53119558) (cherry picked from commit HEAD) Signed-off-by:
-
Christopher Friedt authored
commit aa6de142 upstream. Previously, the vmwgfx_fb driver would allow users to call FBIOSET_VINFO, but it would not adjust the FINFO properly, resulting in distorted screen rendering. The patch corrects that behaviour. See https://bugs.gentoo.org/show_bug.cgi?id=494794 for examples. Signed-off-by:
-
Eric Whitney authored
Commit 9cb00419, which enables hole punching for bigalloc file systems, exposed a bug introduced by commit 6ae06ff5 in an earlier release. When run on a bigalloc file system, xfstests generic/013, 068, 075, 083, 091, 100, 112, 127, 263, 269, and 270 fail with e2fsck errors or cause kernel error messages indicating that previously freed blocks are being freed again. The latter commit optimizes the selection of the starting extent in ext4_ext_rm_leaf() when hole punching by beginning with the extent supplied in the path argument rather than with the last extent in the leaf node (as is still done when truncating). However, the code in rm_leaf that initially sets partial_cluster to track cluster sharing on extent boundaries is only guaranteed to run if rm_leaf starts with the last node in the leaf. Consequently, partial_cluster is not correctly initialized when hole punching, and a cluster on the boundary of a punched region that should be retained may instead be deallocated. Signed-off-by:
Eric Whitney <enwlinux@gmail.com> Signed-off-by:
-
Matthew Leach authored
When copying in a struct msghdr from the user, if the user has set the msg_namelen parameter to a negative value it gets clamped to a valid size due to a comparison between signed and unsigned values. Ensure the syscall errors when the user passes in a negative value. Signed-off-by:
Matthew Leach <matthew.leach@arm.com> Signed-off-by:
-
Peter Boström authored
With TX VLAN offload enabled the source MAC address for frames sent using the VLAN interface is currently set to the address of the real interface. This is wrong since the VLAN interface may be configured with a different address. The bug was introduced in commit 2205369a ("vlan: Fix header ops passthru when doing TX VLAN offload."). This patch sets the source address before calling the create function of the real interface. Signed-off-by:
Peter Boström <peter.bostrom@netrounds.com> Signed-off-by:
-
Al Viro authored
For one thing, there's an ABBA deadlock on hpfs fs-wide lock and i_mutex in hpfs_dir_lseek() - there's a lot of methods that grab the former with the caller already holding the latter, so it must take i_mutex first. For another, locking the damn thing, carefully validating the offset, then dropping locks and assigning the offset is obviously racy. Moreover, we _must_ do hpfs_add_pos(), or the machinery in dnode.c won't modify the sucker on B-tree surgeries. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> (cherry picked from commit 31abdab9) Signed-off-by:
-
Geert Uytterhoeven authored
When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0" on the kernel command line, it crashes with: Unable to handle kernel NULL pointer dereference at virtual address (null) Oops: 00000000 PC: [<0013ad28>] __pmz_startup+0x32/0x2a0 ... Call Trace: [<002c5d3e>] pmz_console_setup+0x64/0xe4 The normal tty driver doesn't crash, because init_pmz() checks pmz_ports_count again after calling pmz_probe(). In the serial console initialization path, pmz_console_init() doesn't do this, causing the driver to crash later. Add a check for pmz_ports_count to fix this. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Finn Thain <fthain@telegraphics.com.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Helge Deller authored
When compiling a 32bit kernel with CONFIG_LBDAF=n the compiler complains like shown below. Fix this warning by instead using sector_div() which is provided by the kernel.h header file. fs/nfs/blocklayout/extents.c: In function ‘normalize’: include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer types lacks a cast [enabled by default] fs/nfs/blocklayout/extents.c:47:13: note: in expansion of macro ‘do_div’ nfs/blocklayout/extents.c:47:2: warning: right shift count >= width of type [enabled by default] fs/nfs/blocklayout/extents.c:47:2: warning: passing argument 1 of ‘__div64_32’ from incompatible pointer type [enabled by default] include/asm-generic/div64.h:35:17: note: expected ‘uint64_t *’ but argument is of type ‘sector_t *’ extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor); Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> (cherry picked from commit 3873d064) Signed-off-by:
-
