- 17 Jan, 2013 40 commits
-
-
Ian Abbott authored
commit c0729eee upstream. Éric Piel reported a kernel oops in the "comedi_test" module. It was a NULL pointer dereference within `waveform_ai_interrupt()` (actually a timer function) that sometimes occurred when a running asynchronous command is cancelled (either by the `COMEDI_CANCEL` ioctl or by closing the device file). This seems to be a race between the caller of `waveform_ai_cancel()` which on return from that function goes and tears down the running command, and the timer function which uses the command. In particular, `async->cmd.chanlist` gets freed (and the pointer set to NULL) by `do_become_nonbusy()` in "comedi_fops.c" but a previously scheduled `waveform_ai_interrupt()` timer function will dereference that pointer regardless, leading to the oops. Fix it by replacing the `del_timer()` call in `waveform_ai_cancel()` with `del_timer_sync()`. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Reported-by:
Éric Piel <piel@delmic.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ian Abbott authored
commit 34ffb33e upstream. The 'ni_at_a2150' module links to `cfc_write_to_buffer` in the 'comedi_fc' module, so selecting 'COMEDI_NI_AT_A2150' in the kernel config needs to also select 'COMEDI_FC'. Signed-off-by:
-
Éric Piel authored
commit 34b55d8c upstream. The minimum period was set to 357 ns, while the divider for these boards is 50 ns. This prevented to output at maximum speed as ni_ao_cmdtest() would return 357 but would not accept it. Not sure why it was set to 357 ns (this was done before the git history, which starts 5 years ago). My guess is that it comes from reading the specification stating a 2.8 MHz rate (~ 357 ns). The latest specification states a 2.86 MHz rate (~ 350 ns), which makes a lot more sense. Tested on a pci-6251. Signed-off-by:
-
Ian Abbott authored
commit 7d3135af upstream. When a low-level comedi driver auto-configures a device, a `struct comedi_dev_file_info` is allocated (as well as a `struct comedi_device`) by `comedi_alloc_board_minor()`. A pointer to the hardware `struct device` is stored as a cookie in the `struct comedi_dev_file_info`. When the low-level comedi driver auto-unconfigures the device, `comedi_auto_unconfig()` uses the cookie to find the `struct comedi_dev_file_info` so it can detach the comedi device from the driver, clean it up and free it. A problem arises if the user manually unconfigures and reconfigures the comedi device using the `COMEDI_DEVCONFIG` ioctl so that is no longer associated with the original hardware device. The problem is that the cookie is not cleared, so that a call to `comedi_auto_unconfig()` from the low-level driver will still find it, detach it, clean it up and free it. Stop this problem occurring by always clearing the `hardware_device` cookie in the `struct comedi_dev_file_info` whenever the `COMEDI_DEVCONFIG` ioctl call is successful. Signed-off-by:
-
Mike Dunn authored
commit 3b4bc7bc upstream. This patch fixes some code that implements a work-around to a hardware bug in the ac97 controller on the pxa27x. A bug in the controller's warm reset functionality requires that the mfp used by the controller as the AC97_nRESET line be temporarily reconfigured as a generic output gpio (AF0) and manually held high for the duration of the warm reset cycle. This is what was done in the original code, but it was broken long ago by commit fb1bf8cd ([ARM] pxa: introduce processor specific pxa27x_assert_ac97reset()) which changed the mfp to a GPIO input instead of a high output. The fix requires the ac97 controller to obtain the gpio via gpio_request_one(), with arguments that configure the gpio as an output initially driven high. Tested on a palm treo 680 machine. Reportedly, this broken code only prevents a warm reset on hardware that lacks a pull-up on the line, which appears to be the case for me. Signed-off-by:
Mike Dunn <mikedunn@newsguy.com> Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Mike Dunn authored
commit 41b645c8 upstream. Cold reset on the pxa27x currently fails and pxa2xx_ac97_try_cold_reset: cold reset timeout (GSR=0x44) appears in the kernel log. Through trial-and-error (the pxa270 developer's manual is mostly incoherent on the topic of ac97 reset), I got cold reset to complete by setting the WARM_RST bit in the GCR register (and later noticed that pxa3xx does this for cold reset as well). Also, a timeout loop is needed to wait for the reset to complete. Tested on a palm treo 680 machine. Signed-off-by:
-
Takashi Iwai authored
commit d7dab4db upstream. We've got a few bug reports that the runtime D3 results in the dead HD-audio controller. It seems that the problem is in a deeper level than the sound driver itself, so as a temporal solution, disable the feature for these controllers again. Reported-and-tested-by:
Vincent Blut <vincent.debian@free.fr> Reported-and-tested-by:
Maurizio Avogadro <mavoga@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
David Henningsson authored
commit 7ed4165e upstream. This reverts commit 697c373e. The original patch was meant to remove clicking, but in fact caused even more clicking instead. Thanks to c4pp4 for doing most of the work with this bug. BugLink: https://bugs.launchpad.net/bugs/886975Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Linus Torvalds authored
commit 6d283dba upstream. Andrew Morton pointed this out a month ago, and then I completely forgot about it. If we read a partial last page of a block device, we will zero out the end of the page, but since that page can then be mapped into user space, we should also make sure to flush the cache on architectures that have virtual caches. We have the flush_dcache_page() function for this, so use it. Now, in practice this really never matters, because nobody sane uses virtual caches to begin with, and they largely exist on old broken RISC arhitectures. And even if you did run on one of those obsolete CPU's, the whole "mmap and access the last partial page of a block device" behavior probably doesn't actually exist. The normal IO functions (read/write) will never see the zeroed-out part of the page that migth not be coherent in the cache, because they honor the size of the device. So I'm marking this for stable (3.7 only), but I'm not sure anybody will ever care. Pointed-out-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Hans de Goede authored
commit 7b4cf994 upstream. This is a left-over from when udl_get_edid returned the amount of bytes successfully read, which it no longer does. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Hans de Goede authored
commit 242187b3 upstream. The buffer passed to usb_control_msg may end up in scatter-gather list, and may thus not be on the stack. Having it on the stack usually works on x86, but not on other archs. Signed-off-by:
-
Hans de Goede authored
commit c930812f upstream. udldrmfb only reads the main EDID block, and if that advertises extensions the drm_edid code expects them to be present, and starts reading beyond the buffer udldrmfb passes it. Although it may be possible to read more EDID info with the udl we simpy don't know how, and even if trial and error gets it working on one device, that is no guarantee it will work on other revisions. So this patch does a simple fix in the form of patching the EDID info to report 0 extension blocks, this fixes udldrmfb only doing 1024x768 on monitors with EDID extension blocks. Signed-off-by:
-
Mark Brown authored
commit 5f960294 upstream. These are not supported Signed-off-by:
-
Patrick Lai authored
commit 08b27848 upstream. When front-end PCM session is in paused state, back-end PCM session will be put in paused state as well if given front-end PCM session is the only client of given back-end. Then, application closes front-end PCM session, DPCM framework will not allow back-end enters HW_FREE state so back-end will never get shutdown completely. Signed-off-by:
Patrick Lai <plai@codeaurora.org> Acked-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
-
Axel Lin authored
commit ad1937cd upstream. Both the mask and mode settings are wrong in current code. According to the datasheet: S2PCFG0 (0x0A) BIT[3:1] DATA_FORMAT serial interface protocol format: 000: left Justified 001: I2S (default) 010: right justified 100: PCM no delay 101: PCM delay 111: DSP Thus fixes the defines for LEFT_J_DATA_FORMAT, I2S_DATA_FORMAT, and RIGHT_J_DATA_FORMAT. Also adds define for DATA_FORMAT_MSK. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Acked-by:
Rajeev Kumar <rajeev-dlh.kumar@st.com> Signed-off-by:
-
Mark Brown authored
commit 0cc411b9 upstream. These are not supported. Signed-off-by:
-
Axel Lin authored
commit 2a5f4315 upstream. According to the defines in wm2200.h: /* * R1284 (0x504) - Audio IF 1_5 */ We should not left shift 1 bit for fmt_val when setting dai format. Signed-off-by:
-
Mark Brown authored
commit 267f8fa2 upstream. Signed-off-by:
-
Mark Brown authored
commit d71753e2 upstream. These are not supported. Signed-off-by:
-
Axel Lin authored
commit 7110a287 upstream. ARIZONA_AIF1_RATE_MASK is 0x7800 /* AIF1_RATE - [14:11] */ Thus we need left shift ARIZONA_AIF1_RATE_SHIFT when setting aif1 rate. Signed-off-by:
-
Mark Brown authored
commit a8c02db0 upstream. The FLL source constants were numbered as a simple enumeration but were being used in the code as direct values to be written to the registers. Renumber the constants to reflect the usage. Reported-by:
Ryo Tsutsui <Ryo.Tsutsui@wolfsonmicro.com> Signed-off-by:
-
Roland Dreier authored
commit 64fe4f4f upstream. Commit 64c13330 ("iscsi-target: Fix bug in handling of ExpStatSN ACK during u32 wrap-around") introduced a bug where we compare the wrong SN against our ExpCmdSN. Reported-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Marek Vasut authored
commit 436136ce upstream. The USB recovery mode present in i.MX23 ROM emulates USB HID. It needs this quirk to behave properly. Even if the official branding of the chip is Freescale i.MX23, I named it Sigmatel STMP3780 since that's what the chip really is and it even reports itself as STMP3780. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Eric Wong authored
commit 128dd175 upstream. EPOLL_CTL_MOD sets the interest mask before calling f_op->poll() to ensure events are not missed. Since the modifications to the interest mask are not protected by the same lock as ep_poll_callback, we need to ensure the change is visible to other CPUs calling ep_poll_callback. We also need to ensure f_op->poll() has an up-to-date view of past events which occured before we modified the interest mask. So this barrier also pairs with the barrier in wq_has_sleeper(). This should guarantee either ep_poll_callback or f_op->poll() (or both) will notice the readiness of a recently-ready/modified item. This issue was encountered by Andreas Voellmy and Junchang(Jason) Wang in: http://thread.gmane.org/gmane.linux.kernel/1408782/Signed-off-by:
Eric Wong <normalperson@yhbt.net> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Davide Libenzi <davidel@xmailserver.org> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: David Miller <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andreas Voellmy <andreas.voellmy@yale.edu> Tested-by:
"Junchang(Jason) Wang" <junchang.wang@yale.edu> Cc: netdev@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Signed-off-by:
-
Mark Brown authored
commit db04328c upstream. If count is less than the size of a register then we may hit integer wraparound when trying to move backwards to check if we're still in the buffer. Instead move the position forwards to check if it's still in the buffer, we are unlikely to be able to allocate a buffer sufficiently big to overflow here. Signed-off-by:
-
Zhang Rui authored
commit b7e38304 upstream. When system enters power off, the _PSW of Lid device is enabled. But this may cause the system to reboot instead of power off. A proper way to fix this is to always disable lid wakeup capability for S5. References: https://bugzilla.kernel.org/show_bug.cgi?id=35262Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by:
-
Namjae Jeon authored
commit fb719c59 upstream. Incrementing lenExtents even while writing to a hole is bad for performance as calls to udf_discard_prealloc and udf_truncate_tail_extent would not return from start if isize != lenExtents Signed-off-by:
Namjae Jeon <namjae.jeon@samsung.com> Signed-off-by:
Ashish Sangwan <a.sangwan@samsung.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Shuah Khan <shuah.khan@hp.com> Signed-off-by:
-
Namjae Jeon authored
commit 2fb7d99d upstream. Need to brelse the buffer_head stored in cur_epos and next_epos. Signed-off-by:
-
Ed Cashin authored
commit 0a41409c upstream. Before the aoe driver was an I/O request handler, it was a make_request-style block driver. Even so, there was a problem where sysfs expected a request queue to exist, so one was provided in commit 7135a71b ("aoe: allocate unused request_queue for sysfs"). During the transition to the request-handler style, a patch was merged that was based on a driver without the noop queue, and the noop queue remained in place after the patch was merged, even though a new functional queue was introduced by the patch, allocated through blk_init_queue. The user impact is a memory leak proportional to the number of AoE targets discovered. This patch removes the memory leak and cleans up vestiges of the old do-nothing queue from the aoeblk_gdalloc function. Signed-off-by:
Ed Cashin <ecashin@coraid.com> Signed-off-by:
-
Guo Chao authored
commit 0ecaef06 upstream. If checksum fails, we should also release the buffer read from previous iteration. Signed-off-by:
Guo Chao <yan@linux.vnet.ibm.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Reviewed-by:
"Darrick J. Wong" <darrick.wong@oracle.com> Signed-off-by:
-
Theodore Ts'o authored
commit 0e9a9a1a upstream. When trying to mount a file system which does not contain a journal, but which does have a orphan list containing an inode which needs to be truncated, the mount call with hang forever in ext4_orphan_cleanup() because ext4_orphan_del() will return immediately without removing the inode from the orphan list, leading to an uninterruptible loop in kernel code which will busy out one of the CPU's on the system. This can be trivially reproduced by trying to mount the file system found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs source tree. If a malicious user were to put this on a USB stick, and mount it on a Linux desktop which has automatic mounts enabled, this could be considered a potential denial of service attack. (Not a big deal in practice, but professional paranoids worry about such things, and have even been known to allocate CVE numbers for such problems.) Signed-off-by:
Zheng Liu <wenqing.lz@taobao.com> Signed-off-by:
-
Theodore Ts'o authored
commit 721e3eba upstream. Commit c278531d added a warning when ext4_flush_unwritten_io() is called without i_mutex being taken. It had previously not been taken during orphan cleanup since races weren't possible at that point in the mount process, but as a result of this c278531d, we will now see a kernel WARN_ON in this case. Take the i_mutex in ext4_orphan_cleanup() to suppress this warning. Reported-by:
Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by:
-
Michael Tokarev authored
commit d096ad0f upstream. When a journal-less ext4 filesystem is mounted on a read-only block device (blockdev --setro will do), each remount (for other, unrelated, flags, like suid=>nosuid etc) results in a series of scary messages from kernel telling about I/O errors on the device. This is becauese of the following code ext4_remount(): if (sbi->s_journal == NULL) ext4_commit_super(sb, 1); at the end of remount procedure, which forces writing (flushing) of a superblock regardless whenever it is dirty or not, if the filesystem is readonly or not, and whenever the device itself is readonly or not. We only need call ext4_commit_super when the file system had been previously mounted read/write. Thanks to Eric Sandeen for help in diagnosing this issue. Signed-off-By:
Michael Tokarev <mjt@tls.msk.ru> Signed-off-by:
-
Jan Kara authored
commit d7961c7f upstream. The following race is possible between start_this_handle() and someone calling jbd2_journal_flush(). Process A Process B start_this_handle(). if (journal->j_barrier_count) # false if (!journal->j_running_transaction) { #true read_unlock(&journal->j_state_lock); jbd2_journal_lock_updates() jbd2_journal_flush() write_lock(&journal->j_state_lock); if (journal->j_running_transaction) { # false ... wait for committing trans ... write_unlock(&journal->j_state_lock); ... write_lock(&journal->j_state_lock); if (!journal->j_running_transaction) { # true jbd2_get_transaction(journal, new_transaction); write_unlock(&journal->j_state_lock); goto repeat; # eventually blocks on j_barrier_count > 0 ... J_ASSERT(!journal->j_running_transaction); # fails We fix the race by rechecking j_barrier_count after reacquiring j_state_lock in exclusive mode. Reported-by: yjwsignal@empal.com Signed-off-by:
-
Jan Kara authored
commit 261cb20c upstream. Currently we allow enabling dioread_nolock mount option on remount for filesystems where blocksize < PAGE_CACHE_SIZE. This isn't really supported so fix the bug by moving the check for blocksize != PAGE_CACHE_SIZE into parse_options(). Change the original PAGE_SIZE to PAGE_CACHE_SIZE along the way because that's what we are really interested in. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
-
Forrest Liu authored
commit c36575e6 upstream. When depth of extent tree is greater than 1, logical start value of interior node is not correctly updated in ext4_ext_rm_idx. Signed-off-by:
Forrest Liu <forrestl@synology.com> Signed-off-by:
Ashish Sangwan <ashishsangwan2@gmail.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit 9f6d8f6a upstream. Currently, the PM core disables runtime PM for all devices right after executing subsystem/driver .suspend() callbacks for them and re-enables it right before executing subsystem/driver .resume() callbacks for them. This may lead to problems when there are two devices such that the .suspend() callback executed for one of them depends on runtime PM working for the other. In that case, if runtime PM has already been disabled for the second device, the first one's .suspend() won't work correctly (and analogously for resume). To make those issues go away, make the PM core disable runtime PM for devices right before executing subsystem/driver .suspend_late() callbacks for them and enable runtime PM for them right after executing subsystem/driver .resume_early() callbacks for them. This way the potential conflitcs between .suspend_late()/.resume_early() and their runtime PM counterparts are still prevented from happening, but the subtle ordering issues related to disabling/enabling runtime PM for devices during system suspend/resume are much easier to avoid. Reported-and-tested-by:
Jan-Matthias Braun <jan_braun@gmx.net> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by:
Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by:
-
Seth Forshee authored
commit e04c200f upstream. BugLink: http://bugs.launchpad.net/bugs/1086921Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by:
-
Lothar Waßmann authored
commit 6c1ecba8 upstream. The VDCTRL4 register does not provide the MXS SET/CLR/TOGGLE feature. The write in mxsfb_disable_controller() sets the data_cnt for the LCD DMA to 0 which obviously means the max. count for the LCD DMA and leads to overwriting arbitrary memory when the display is unblanked. Signed-off-by:
Lothar Waßmann <LW@KARO-electronics.de> Acked-by:
Juergen Beisert <jbe@pengutronix.de> Tested-by:
Lauri Hintsala <lauri.hintsala@bluegiga.net> Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Hante Meuleman authored
commit 619c5a9a upstream. RSN IEs got incorrectly parsed and therefore ap mode using WPA2 security was not working. Reviewed-by:
Arend Van Spriel <arend@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by:
Hante Meuleman <meuleman@broadcom.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
