- 03 Dec, 2012 31 commits
-
-
Oliver Hartkopp authored
commit c9faaa09 upstream. The skb->tstamp is set to the hardware timestamp when available in the USB urb message. This leads to user visible timestamps which contain the 'uptime' of the USB adapter - and not the usual system generated timestamp. Fix this wrong assignment by applying the available hardware timestamp to the skb_shared_hwtstamps data structure - which is intended for this purpose. Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Paul Bolle authored
commit 45171002 upstream. The Intel 82855PM host bridge / Mobility FireGL 9000 RV250 combination in an (outdated) ThinkPad T41 needs AGPMode 1 for suspend/resume (under KMS, that is). So add a quirk for it. (Change R250 to RV250 in comment for preceding quirk too.) Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Simon Wunderlich authored
commit b78a4932 upstream. The check whether the IBSS is active and can be removed should be performed before deinitializing the fields used for the check/search. Otherwise, the configured BSS will not be found and removed properly. To make it more clear for the future, rename sdata->u.ibss to the local pointer ifibss which is used within the checks. This behaviour was introduced by f3209bea ("mac80211: fix IBSS teardown race") Signed-off-by:
Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Cc: Ignacy Gawedzki <i@lri.fr> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Darren Hart authored
commit aa10990e upstream. Dave Jones reported a bug with futex_lock_pi() that his trinity test exposed. Sometime between queue_me() and taking the q.lock_ptr, the lock_ptr became NULL, resulting in a crash. While futex_wake() is careful to not call wake_futex() on futex_q's with a pi_state or an rt_waiter (which are either waiting for a futex_unlock_pi() or a PI futex_requeue()), futex_wake_op() and futex_requeue() do not perform the same test. Update futex_wake_op() and futex_requeue() to test for q.pi_state and q.rt_waiter and abort with -EINVAL if detected. To ensure any future breakage is caught, add a WARN() to wake_futex() if the same condition is true. This fix has seen 3 hours of testing with "trinity -c futex" on an x86_64 VM with 4 CPUS. [akpm@linux-foundation.org: tidy up the WARN()] Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Reported-by:
Dave Jones <davej@redat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: John Kacur <jkacur@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jens Axboe authored
commit a8c32a5c upstream. Request based dm attempts to re-run the request queue off the request completion path. If used with a driver that potentially does end_io from its request_fn, we could deadlock trying to recurse back into request dispatch. Fix this by punting the request queue run to kblockd. Tested to fix a quickly reproducible deadlock in such a scenario. Acked-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
NeilBrown authored
commit 884162df upstream. When a write to a replacement device completes, we carefully and correctly found the rdev that the write actually went to and the blithely called rdev_dec_pending on the primary rdev, even if this write was to the replacement. This means that any writes to an array while a replacement was ongoing would cause the nr_pending count for the primary device to go negative, so it could never be removed. This bug has been present since replacement was introduced in 3.3, so it is suitable for any -stable kernel since then. Reported-by:
"George Spelvin" <linux@horizon.com> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
majianpeng authored
commit 35f9ac2d upstream. If read_seqretry returned true and bbp was changed, it will write invalid address which can cause some serious problem. This bug was introduced by commit v3.0-rc7-130-g2699b672. So fix is suitable for 3.0.y thru 3.6.y. Reported-by: zhuwenfeng@kedacom.com Tested-by: zhuwenfeng@kedacom.com Signed-off-by:
Jianpeng Ma <majianpeng@gmail.com> Signed-off-by:
-
majianpeng authored
commit ab05613a upstream. This bug was introduced by commit(v3.0-rc7-126-g2230dfe). So fix is suitable for 3.0.y thru 3.6.y. Signed-off-by:
-
Thomas Betker authored
commit 5ffd3412 upstream. jffs2_write_begin() first acquires the page lock, then f->sem. This causes an AB-BA deadlock with jffs2_garbage_collect_live(), which first acquires f->sem, then the page lock: jffs2_garbage_collect_live mutex_lock(&f->sem) (A) jffs2_garbage_collect_dnode jffs2_gc_fetch_page read_cache_page_async do_read_cache_page lock_page(page) (B) jffs2_write_begin grab_cache_page_write_begin find_lock_page lock_page(page) (B) mutex_lock(&f->sem) (A) We fix this by restructuring jffs2_write_begin() to take f->sem before the page lock. However, we make sure that f->sem is not held when calling jffs2_reserve_space(), as this is not permitted by the locking rules. The deadlock above was observed multiple times on an SoC with a dual ARMv7 (Cortex-A9), running the long-term 3.4.11 kernel; it occurred when using scp to copy files from a host system to the ARM target system. The fix was heavily tested on the same target system. Signed-off-by:
Thomas Betker <thomas.betker@rohde-schwarz.com> Acked-by:
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
-
Sachin Kamat authored
commit 5a6ea4af upstream. The pointer returned by kzalloc should be tested for NULL to avoid potential NULL pointer dereference later. Incorrect pointer was being tested for NULL. Bug introduced by commit fbcf62a3 (mtd: physmap_of: move parse_obsolete_partitions to become separate parser). This patch fixes this bug. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Cc: Artem Bityutskiy <artem.bityutskiy@intel.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Jiri Engelthaler authored
commit c36a7ff4 upstream. Fixed parsing end absolute address. Signed-off-by:
Jiri Engelthaler <engycz@gmail.com> Signed-off-by:
-
Al Viro authored
commit 441a179d upstream. int sys32_rt_sigprocmask(int how, compat_sigset_t __user *set, compat_sigset_t __user *oset, unsigned int sigsetsize) { sigset_t old_set, new_set; int ret; if (set && get_sigset32(set, &new_set, sigsetsize)) ... static int get_sigset32(compat_sigset_t __user *up, sigset_t *set, size_t sz) { compat_sigset_t s; int r; if (sz != sizeof *set) panic("put_sigset32()"); In other words, rt_sigprocmask(69, (void *)69, 69) done by 32bit process will promptly panic the box. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
James Bottomley authored
commit 949a05d0 upstream. On Thu, 2012-11-01 at 16:45 -0700, Michel Lespinasse wrote: > Looking at the arch/parisc/kernel/sys_parisc.c implementation of > get_shared_area(), I do have a concern though. The function basically > ignores the pgoff argument, so that if one creates a shared mapping of > pages 0-N of a file, and then a separate shared mapping of pages 1-N > of that same file, both will have the same cache offset for their > starting address. > > This looks like this would create obvious aliasing issues. Am I > misreading this ? I can't understand how this could work good enough > to be undetected, so there must be something I'm missing here ??? This turns out to be correct and we need to pay attention to the pgoff as well as the address when creating the virtual address for the area. Fortunately, the bug is rarely triggered as most applications which use pgoff tend to use large values (git being the primary one, and it uses pgoff in multiples of 16MB) which are larger than our cache coherency modulus, so the problem isn't often seen in practise. Reported-by:
Michel Lespinasse <walken@google.com> Signed-off-by:
-
David Henningsson authored
commit 34c3d192 upstream. If this array is not cleared, the jack related code later might fail to create "Internal Speaker Phantom Jack" on Dell Inspiron 3420 and Dell Vostro 2420. BugLink: https://bugs.launchpad.net/bugs/1076840Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Clemens Ladisch authored
commit e99ddfde upstream. Commit 88a8516a (ALSA: usbaudio: implement USB autosuspend) added autosuspend code to all files making up the snd-usb-audio driver. However, midi.c is part of snd-usb-lib and is also used by other drivers, not all of which support autosuspend. Thus, calls to usb_autopm_get_interface() could fail, and this unexpected error would result in the MIDI output being completely unusable. Make it work by ignoring the error that is expected with drivers that do not support autosuspend. Reported-by:
Colin Fletcher <colin.m.fletcher@googlemail.com> Reported-by:
Devin Venable <venable.devin@gmail.com> Reported-by:
Dr Nick Bailey <nicholas.bailey@glasgow.ac.uk> Reported-by:
Jannis Achstetter <jannis_achstetter@web.de> Reported-by:
Rui Nuno Capela <rncbc@rncbc.org> Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Alex Deucher authored
commit 0181bd5d upstream. Signed-off-by:
-
Maciej Patelczyk authored
commit 49bd665c upstream. SATA MICROCODE DOWNALOAD fails on isci driver. After receiving Register Device to Host (FIS 0x34) frame Initiator resets phy. In the frame handler routine response (FIS 0x34) was copied into wrong buffer and upper layer did not receive any answer which resulted in timeout and reset. This patch corrects this bug. Signed-off-by:
Maciej Patelczyk <maciej.patelczyk@intel.com> Signed-off-by:
Lukasz Dorau <lukasz.dorau@intel.com> Signed-off-by:
-
Bing Zhao authored
commit b1a47aa5 upstream. Reported by Tim Shepard: I was seeing sporadic failures (wedgeups), and the majority of those failures I saw printed the printouts in mwifiex_cmd_timeout_func with cmd = 0xe5 which is CMD_802_11_HS_CFG_ENH. When this happens, two minutes later I get notified that the rtcwake thread is blocked, like this: INFO: task rtcwake:3495 blocked for more than 120 seconds. To get the hung thread unblocked we wake up the cmd wait queue and cancel the ioctl. Reported-by:
Tim Shepard <shep@laptop.org> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Bing Zhao authored
commit dd321acd upstream. When host_sleep_config command fails we should return error to MMC core to indicate the failure for our device. The misspelled variable is also removed as it's redundant. Signed-off-by:
-
Albert Pool authored
commit a485e827 upstream. This is an ISY IWL 2000. Probably a clone of Belkin F7D1102 050d:1102. Its FCC ID is the same. Signed-off-by:
Albert Pool <albertpool@solcon.nl> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Boris Ostrovsky authored
commit 36c46ca4 upstream. Add valid patch size for family 16h processors. [ hpa: promoting to urgent/stable since it is hw enabling and trivial ] Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@amd.com> Acked-by:
Andreas Herrmann <herrmann.der.user@googlemail.com> Link: http://lkml.kernel.org/r/1353004910-2204-1-git-send-email-boris.ostrovsky@amd.comSigned-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Matt Fleming authored
commit 0f905a43 upstream. Building for Athlon/Duron/K7 results in the following build error, arch/x86/boot/compressed/eboot.o: In function `__constant_memcpy3d': eboot.c:(.text+0x385): undefined reference to `_mmx_memcpy' arch/x86/boot/compressed/eboot.o: In function `efi_main': eboot.c:(.text+0x1a22): undefined reference to `_mmx_memcpy' because the boot stub code doesn't link with the kernel proper, and therefore doesn't have access to the 3DNow version of memcpy. So, follow the example of misc.c and #undef memcpy so that we use the version provided by misc.c. See https://bugzilla.kernel.org/show_bug.cgi?id=50391Reported-by:
Ryan Underwood <nemesis@icequake.net> Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Signed-off-by:
-
Robert Richter authored
commit 10226238 upstream. In 32 bit the stack address provided by kernel_stack_pointer() may point to an invalid range causing NULL pointer access or page faults while in NMI (see trace below). This happens if called in softirq context and if the stack is empty. The address at ®s->sp is then out of range. Fixing this by checking if regs and ®s->sp are in the same stack context. Otherwise return the previous stack pointer stored in struct thread_info. If that address is invalid too, return address of regs. BUG: unable to handle kernel NULL pointer dereference at 0000000a IP: [<c1004237>] print_context_stack+0x6e/0x8d *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: Pid: 4434, comm: perl Not tainted 3.6.0-rc3-oprofile-i386-standard-g4411a05 #4 Hewlett-Packard HP xw9400 Workstation/0A1Ch EIP: 0060:[<c1004237>] EFLAGS: 00010093 CPU: 0 EIP is at print_context_stack+0x6e/0x8d EAX: ffffe000 EBX: 0000000a ECX: f4435f94 EDX: 0000000a ESI: f4435f94 EDI: f4435f94 EBP: f5409ec0 ESP: f5409ea0 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: 0000000a CR3: 34ac9000 CR4: 000007d0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process perl (pid: 4434, ti=f5408000 task=f5637850 task.ti=f4434000) Stack: 000003e8 ffffe000 00001ffc f4e39b00 00000000 0000000a f4435f94 c155198c f5409ef0 c1003723 c155198c f5409f04 00000000 f5409edc 00000000 00000000 f5409ee8 f4435f94 f5409fc4 00000001 f5409f1c c12dce1c 00000000 c155198c Call Trace: [<c1003723>] dump_trace+0x7b/0xa1 [<c12dce1c>] x86_backtrace+0x40/0x88 [<c12db712>] ? oprofile_add_sample+0x56/0x84 [<c12db731>] oprofile_add_sample+0x75/0x84 [<c12ddb5b>] op_amd_check_ctrs+0x46/0x260 [<c12dd40d>] profile_exceptions_notify+0x23/0x4c [<c1395034>] nmi_handle+0x31/0x4a [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45 [<c13950ed>] do_nmi+0xa0/0x2ff [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45 [<c13949e5>] nmi_stack_correct+0x28/0x2d [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45 [<c1003603>] ? do_softirq+0x4b/0x7f <IRQ> [<c102a06f>] irq_exit+0x35/0x5b [<c1018f56>] smp_apic_timer_interrupt+0x6c/0x7a [<c1394746>] apic_timer_interrupt+0x2a/0x30 Code: 89 fe eb 08 31 c9 8b 45 0c ff 55 ec 83 c3 04 83 7d 10 00 74 0c 3b 5d 10 73 26 3b 5d e4 73 0c eb 1f 3b 5d f0 76 1a 3b 5d e8 73 15 <8b> 13 89 d0 89 55 e0 e8 ad 42 03 00 85 c0 8b 55 e0 75 a6 eb cc EIP: [<c1004237>] print_context_stack+0x6e/0x8d SS:ESP 0068:f5409ea0 CR2: 000000000000000a ---[ end trace 62afee3481b00012 ]--- Kernel panic - not syncing: Fatal exception in interrupt V2: * add comments to kernel_stack_pointer() * always return a valid stack address by falling back to the address of regs Reported-by:
Yang Wei <wei.yang@windriver.com> Signed-off-by:
Robert Richter <robert.richter@amd.com> Link: http://lkml.kernel.org/r/20120912135059.GZ8285@erda.amd.comSigned-off-by:
-
Larry Finger authored
commit f761b694 upstream. With gcc 4.7.x, the following warning is issued as the routine that sets the array has the possibility of not initializing the values: CC [M] drivers/net/wireless/rtlwifi/rtl8192se/phy.o drivers/net/wireless/rtlwifi/rtl8192se/phy.c: In function ‘rtl92s_phy_set_txpower’: drivers/net/wireless/rtlwifi/rtl8192se/phy.c:1268:23: warning: ‘ofdmpowerLevel[0]’ may be used uninitialized in this function [-Wuninitialized] Signed-off-by:
-
Krzysztof Wilczynski authored
commit b631cf1f upstream. This is to change use of "0x%08x" in favour of "%p" as per ../Documentation/printk-formats.txt, which also takes care about the following warning during compilation time: drivers/scsi/aha152x.c: In function ‘get_command’: drivers/scsi/aha152x.c:2987: warning: cast from pointer to integer of different size Signed-off-by:
Krzysztof Wilczynski <krzysztof.wilczynski@linux.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Dan Carpenter authored
commit cca85013 upstream. We don't use "dev" any more after 07ec747a5f ("libsas: remove ata_port.lock management duties from lldds") and it causes a compile warning. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Xiangliang Yu <yuxiangl@marvell.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Dan Carpenter authored
commit 5bc9ad77 upstream. Gcc 4.6.2 complains that: drivers/leds/leds-lp5521.c: In function `lp5521_load_program': drivers/leds/leds-lp5521.c:214:21: warning: `mode' may be used uninitialized in this function [-Wuninitialized] drivers/leds/leds-lp5521.c: In function `lp5521_probe': drivers/leds/leds-lp5521.c:788:5: warning: `buf' may be used uninitialized in this function [-Wuninitialized] drivers/leds/leds-lp5521.c:740:6: warning: `ret' may be used uninitialized in this function [-Wuninitialized] These are real problems if lp5521_read() returns an error. When that happens we should handle it, instead of ignoring it or doing a bitwise OR with all the other error codes and continuing. Signed-off-by:
-
Daniel Mack authored
commit da185443 upstream. Fixes the following warning: CC [M] sound/usb/caiaq/device.o sound/usb/caiaq/device.c: In function ‘snd_probe’: sound/usb/caiaq/device.c:500:16: warning: ‘card’ may be used uninitialized in this function [-Wmaybe-uninitialized] Signed-off-by:
Daniel Mack <zonque@gmail.com> Signed-off-by:
-
Szymon Janc authored
commit 8f321f85 upstream. If remote device sends bogus RFC option with invalid length, undefined options values are used. Fix this by using defaults when remote misbehaves. This also fixes the following warning reported by gcc 4.7.0: net/bluetooth/l2cap_core.c: In function 'l2cap_config_rsp': net/bluetooth/l2cap_core.c:3302:13: warning: 'rfc.max_pdu_size' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.max_pdu_size' was declared here net/bluetooth/l2cap_core.c:3298:25: warning: 'rfc.monitor_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.monitor_timeout' was declared here net/bluetooth/l2cap_core.c:3297:25: warning: 'rfc.retrans_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.retrans_timeout' was declared here net/bluetooth/l2cap_core.c:3295:2: warning: 'rfc.mode' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.mode' was declared here Signed-off-by:
Szymon Janc <szymon.janc@tieto.com> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
-
Keith Busch authored
commit c7d36ab8 upstream. Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Matthew Wilcox <matthew.r.wilcox@intel.com> Signed-off-by:
-
Alexandre Pereira da Silva authored
commit 782759b9 upstream. Fix the following compilation warning: fs/ubifs/dir.c: In function 'ubifs_rename': fs/ubifs/dir.c:972:15: warning: 'saved_nlink' may be used uninitialized in this function Use the 'uninitialized_var()' macro to get rid of this false-positive. Artem: massaged the patch a bit. Signed-off-by:
Alexandre Pereira da Silva <aletes.xgr@gmail.com> Signed-off-by:
-
- 26 Nov, 2012 9 commits
-
-
Greg Kroah-Hartman authored
-
Alex Elder authored
commit 26103021 upstream. For some reason the declaration of ceph_con_get() and ceph_con_put() did not get deleted in this commit: d59315ca libceph: drop ceph_con_get/put helpers and nref member Clean that up. Signed-off-by:
Alex Elder <elder@inktank.com> Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by:
-
Felipe Balbi authored
commit a4f74385 upstream. This reverts commit 957ee727 (serial: omap: fix software flow control). As Russell has pointed out, that commit isn't fixing Software Flow Control at all, and it actually makes it even more broken. It was agreed to revert this commit and use Russell's latest UART patches instead. Signed-off-by:
Felipe Balbi <balbi@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by:
Tony Lindgren <tony@atomide.com> Cc: Andreas Bießmann <andreas.devel@googlemail.com> Signed-off-by:
-
Igor Murzov authored
commit fba4e087 upstream. There are systems where video module known to work fine regardless of broken _DOD and ignoring returned value here doesn't cause any issues later. This should fix brightness controls on some laptops. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47861Signed-off-by:
Igor Murzov <e-mail@date.by> Reviewed-by:
Sergey V <sftp.mtuci@gmail.com> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
Abdallah Chatila <abdallah.chatila@ericsson.com>
-
Alex Elder authored
(cherry picked from commit 6285bc23) A pgoff_t is defined (by default) to have type (unsigned long). On architectures such as i686 that's a 32-bit type. The ceph address space code was attempting to produce 64 bit offsets by shifting a page's index by PAGE_CACHE_SHIFT, but the result was not what was desired because the shift occurred before the result got promoted to 64 bits. Fix this by converting all uses of page->index used in this way to use the page_offset() macro, which ensures the 64-bit result has the intended value. This fixes http://tracker.newdream.net/issues/3112Reported-by:
Mohamed Pakkeer <pakkeer.mohideen@realimage.com> Signed-off-by:
Sage Weil <sage@inktank.com> Signed-off-by:
-
Sage Weil authored
(cherry picked from commit d63b77f4) If we encounter an invalid (e.g., zeroed) mapping, return an error and avoid a divide by zero. Signed-off-by:
-
Yan, Zheng authored
(cherry picked from commit 3e8f43a0) When i >= newmap->m_max_mds, ceph_mdsmap_get_addr(newmap, i) return NULL. Passing NULL to memcmp() triggers oops. Signed-off-by:
Yan, Zheng <zheng.z.yan@intel.com> Signed-off-by:
-
Sage Weil authored
(cherry picked from commit 9bd95261) The ceph_on_in_msg_alloc() method drops con->mutex while it allocates a message. If that races with a timeout that resends a zillion messages and resets the connection, and the ->alloc_msg() method returns a NULL message, it will call ceph_msg_put(NULL) and BUG. Fix by only calling put if msg is non-NULL. Fixes http://tracker.newdream.net/issues/3142Signed-off-by:
-
Alex Elder authored
(cherry picked from commit 588377d6) If ceph_fault() is unable to queue work after a delay, it sets the BACKOFF connection flag so con_work() will attempt to do so. In con_work(), when BACKOFF is set, if queue_delayed_work() doesn't result in newly-queued work, it simply ignores this condition and proceeds as if no backoff delay were desired. There are two problems with this--one of which is a bug. The first problem is simply that the intended behavior is to back off, and if we aren't able queue the work item to run after a delay we're not doing that. The only reason queue_delayed_work() won't queue work is if the provided work item is already queued. In the messenger, this means that con_work() is already scheduled to be run again. So if we simply set the BACKOFF flag again when this occurs, we know the next con_work() call will again attempt to hold off activity on the connection until after the delay. The second problem--the bug--is a leak of a reference count. If queue_delayed_work() returns 0 in con_work(), con->ops->put() drops the connection reference held on entry to con_work(). However, processing is (was) allowed to continue, and at the end of the function a second con->ops->put() is called. This patch fixes both problems. Signed-off-by:
-
