OSDN Git Service
Bjorn Helgaas [Wed, 29 May 2013 22:29:55 +0000 (16:29 -0600)]
bio-integrity: Fix use of bs->bio_integrity_pool after free
commit
adbe6991efd36104ac9eaf751993d35eaa7f493a upstream.
This fixes a copy and paste error introduced by
9f060e2231
("block: Convert integrity to bvec_alloc_bs()").
Found by Coverity (CID
1020654).
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Kent Overstreet <koverstreet@google.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Cc: Jonghwan Choi <jhbird.choi@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andi Kleen [Thu, 25 Apr 2013 00:03:02 +0000 (17:03 -0700)]
perf tools: Handle JITed code in shared memory
commit
89365e6c9ad4c0e090e4c6a4b67a3ce319381d89 upstream.
Need to check for /dev/zero.
Most likely more strings are missing too.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/1366848182-30449-1-git-send-email-andi@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Vinson Lee <vlee@freedesktop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Khalid Aziz [Wed, 11 Sep 2013 21:22:20 +0000 (14:22 -0700)]
mm: fix aio performance regression for database caused by THP
commit
7cb2ef56e6a8b7b368b2e883a0a47d02fed66911 upstream.
I am working with a tool that simulates oracle database I/O workload.
This tool (orion to be specific -
<http://docs.oracle.com/cd/E11882_01/server.112/e16638/iodesign.htm#autoId24>)
allocates hugetlbfs pages using shmget() with SHM_HUGETLB flag. It then
does aio into these pages from flash disks using various common block
sizes used by database. I am looking at performance with two of the most
common block sizes - 1M and 64K. aio performance with these two block
sizes plunged after Transparent HugePages was introduced in the kernel.
Here are performance numbers:
pre-THP 2.6.39 3.11-rc5
1M read 8384 MB/s 5629 MB/s 6501 MB/s
64K read 7867 MB/s 4576 MB/s 4251 MB/s
I have narrowed the performance impact down to the overheads introduced by
THP in __get_page_tail() and put_compound_page() routines. perf top shows
>40% of cycles being spent in these two routines. Every time direct I/O
to hugetlbfs pages starts, kernel calls get_page() to grab a reference to
the pages and calls put_page() when I/O completes to put the reference
away. THP introduced significant amount of locking overhead to get_page()
and put_page() when dealing with compound pages because hugepages can be
split underneath get_page() and put_page(). It added this overhead
irrespective of whether it is dealing with hugetlbfs pages or transparent
hugepages. This resulted in 20%-45% drop in aio performance when using
hugetlbfs pages.
Since hugetlbfs pages can not be split, there is no reason to go through
all the locking overhead for these pages from what I can see. I added
code to __get_page_tail() and put_compound_page() to bypass all the
locking code when working with hugetlbfs pages. This improved performance
significantly. Performance numbers with this patch:
pre-THP 3.11-rc5 3.11-rc5 + Patch
1M read 8384 MB/s 6501 MB/s 8371 MB/s
64K read 7867 MB/s 4251 MB/s 6510 MB/s
Performance with 64K read is still lower than what it was before THP, but
still a 53% improvement. It does mean there is more work to be done but I
will take a 53% improvement for now.
Please take a look at the following patch and let me know if it looks
reasonable.
[akpm@linux-foundation.org: tweak comments]
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
Cc: Pravin B Shelar <pshelar@nicira.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Rik van Riel <riel@redhat.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Konstantin Khlebnikov [Tue, 24 Sep 2013 22:27:42 +0000 (15:27 -0700)]
audit: fix endless wait in audit_log_start()
commit
8ac1c8d5deba65513b6a82c35e89e73996c8e0d6 upstream.
After commit
829199197a43 ("kernel/audit.c: avoid negative sleep
durations") audit emitters will block forever if userspace daemon cannot
handle backlog.
After the timeout the waiting loop turns into busy loop and runs until
daemon dies or returns back to work. This is a minimal patch for that
bug.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>
Cc: Eric Paris <eparis@redhat.com>
Cc: Chuck Anderson <chuck.anderson@oracle.com>
Cc: Dan Duval <dan.duval@oracle.com>
Cc: Dave Kleikamp <dave.kleikamp@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Thu, 25 Jul 2013 14:15:16 +0000 (16:15 +0200)]
udf: Refuse RW mount of the filesystem instead of making it RO
commit
e729eac6f65e11c5f03b09adcc84bd5bcb230467 upstream.
Refuse RW mount of udf filesystem. So far we just silently changed it
to RO mount but when the media is writeable, block layer won't notice
this change and thus will think device is used RW and will block eject
button of the drive. That is unexpected by users because for
non-writeable media eject button works just fine.
Userspace mount(8) command handles this just fine and retries mounting
with MS_RDONLY set so userspace shouldn't see any regression. Plus any
tool mounting udf is likely confronted with the case of read-only
media where block layer already refuses to mount the filesystem without
MS_RDONLY set so our behavior shouldn't be anything new for it.
Reported-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Thu, 25 Jul 2013 17:10:59 +0000 (19:10 +0200)]
udf: Standardize return values in mount sequence
commit
d759bfa4e7919b89357de50a2e23817079889195 upstream.
Change all function used in filesystem discovery during mount to user
standard kernel return values - -errno on error, 0 on success instead
of 1 on failure and 0 on success. This allows us to pass error number
(not just failure / success) so we can abort device scanning earlier
in case of errors like EIO or ENOMEM . Also we will be able to return
EROFS in case writeable mount is requested but writing isn't supported.
Signed-off-by: Jan Kara <jack@suse.cz>
Cc: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Wed, 22 May 2013 14:25:52 +0000 (11:25 -0300)]
Properly handle tristate dependencies on USB/PCI menus
commit
5077ac3b8108007f4a2b4589f2d373cf55453206 upstream.
As USB/PCI/MEDIA_SUPPORT dependencies can be tristate, we can't
simply make the bool menu to be dependent on it. Everything below
the menu should also depend on it, otherwise, we risk to allow
building them with 'y', while only 'm' would be supported.
So, add an IF just before everything below, in order to avoid
such risks.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Randy Dunlap [Wed, 8 May 2013 20:28:13 +0000 (17:28 -0300)]
media: media/usb: fix kconfig dependencies
commit
a0f9354b1a319cb29c331bfd2e5a15d7f9b87fa4 upstream.
(a.k.a. Kconfig bool depending on a tristate considered harmful)
Fix various build errors when CONFIG_USB=m and media USB drivers
are builtin. In this case, CONFIG_USB_ZR364XX=y,
CONFIG_VIDEO_PVRUSB2=y, and CONFIG_VIDEO_STK1160=y.
This is caused by (from drivers/media/usb/Kconfig):
menuconfig MEDIA_USB_SUPPORT
bool "Media USB Adapters"
depends on USB && MEDIA_SUPPORT
=m =y
so MEDIA_USB_SUPPORT=y and all following Kconfig 'source' lines
are included. By adding an "if USB" guard around most of this file,
the needed dependencies are enforced.
drivers/built-in.o: In function `zr364xx_start_readpipe':
zr364xx.c:(.text+0xc726a): undefined reference to `usb_alloc_urb'
zr364xx.c:(.text+0xc72bb): undefined reference to `usb_submit_urb'
drivers/built-in.o: In function `zr364xx_stop_readpipe':
zr364xx.c:(.text+0xc72fd): undefined reference to `usb_kill_urb'
zr364xx.c:(.text+0xc7309): undefined reference to `usb_free_urb'
drivers/built-in.o: In function `read_pipe_completion':
zr364xx.c:(.text+0xc7acc): undefined reference to `usb_submit_urb'
drivers/built-in.o: In function `send_control_msg.constprop.12':
zr364xx.c:(.text+0xc7d2f): undefined reference to `usb_control_msg'
drivers/built-in.o: In function `pvr2_ctl_timeout':
pvrusb2-hdw.c:(.text+0xcadb6): undefined reference to `usb_unlink_urb'
pvrusb2-hdw.c:(.text+0xcadcb): undefined reference to `usb_unlink_urb'
drivers/built-in.o: In function `pvr2_hdw_create':
(.text+0xcc42c): undefined reference to `usb_alloc_urb'
drivers/built-in.o: In function `pvr2_hdw_create':
(.text+0xcc448): undefined reference to `usb_alloc_urb'
drivers/built-in.o: In function `pvr2_hdw_create':
(.text+0xcc5f9): undefined reference to `usb_set_interface'
drivers/built-in.o: In function `pvr2_hdw_create':
(.text+0xcc65a): undefined reference to `usb_free_urb'
drivers/built-in.o: In function `pvr2_hdw_create':
(.text+0xcc666): undefined reference to `usb_free_urb'
drivers/built-in.o: In function `pvr2_send_request_ex.part.22':
pvrusb2-hdw.c:(.text+0xccbe3): undefined reference to `usb_submit_urb'
pvrusb2-hdw.c:(.text+0xccc83): undefined reference to `usb_submit_urb'
drivers/built-in.o: In function `pvr2_hdw_remove_usb_stuff.part.25':
pvrusb2-hdw.c:(.text+0xcd3f9): undefined reference to `usb_kill_urb'
pvrusb2-hdw.c:(.text+0xcd405): undefined reference to `usb_free_urb'
pvrusb2-hdw.c:(.text+0xcd421): undefined reference to `usb_kill_urb'
pvrusb2-hdw.c:(.text+0xcd42d): undefined reference to `usb_free_urb'
drivers/built-in.o: In function `pvr2_hdw_device_reset':
(.text+0xcd658): undefined reference to `usb_lock_device_for_reset'
drivers/built-in.o: In function `pvr2_hdw_device_reset':
(.text+0xcd664): undefined reference to `usb_reset_device'
drivers/built-in.o: In function `pvr2_hdw_cpureset_assert':
(.text+0xcd6f9): undefined reference to `usb_control_msg'
drivers/built-in.o: In function `pvr2_hdw_cpufw_set_enabled':
(.text+0xcd84e): undefined reference to `usb_control_msg'
drivers/built-in.o: In function `pvr2_upload_firmware1':
pvrusb2-hdw.c:(.text+0xcda47): undefined reference to `usb_clear_halt'
pvrusb2-hdw.c:(.text+0xcdb04): undefined reference to `usb_control_msg'
drivers/built-in.o: In function `pvr2_upload_firmware2':
(.text+0xce7dc): undefined reference to `usb_bulk_msg'
drivers/built-in.o: In function `pvr2_stream_buffer_count':
pvrusb2-io.c:(.text+0xd2e05): undefined reference to `usb_alloc_urb'
pvrusb2-io.c:(.text+0xd2e5b): undefined reference to `usb_kill_urb'
pvrusb2-io.c:(.text+0xd2e9f): undefined reference to `usb_free_urb'
drivers/built-in.o: In function `pvr2_stream_internal_flush':
pvrusb2-io.c:(.text+0xd2f9b): undefined reference to `usb_kill_urb'
drivers/built-in.o: In function `pvr2_buffer_queue':
(.text+0xd3328): undefined reference to `usb_kill_urb'
drivers/built-in.o: In function `pvr2_buffer_queue':
(.text+0xd33ea): undefined reference to `usb_submit_urb'
drivers/built-in.o: In function `stk1160_read_reg':
(.text+0xd3efa): undefined reference to `usb_control_msg'
drivers/built-in.o: In function `stk1160_write_reg':
(.text+0xd3f4f): undefined reference to `usb_control_msg'
drivers/built-in.o: In function `stop_streaming':
stk1160-v4l.c:(.text+0xd4997): undefined reference to `usb_set_interface'
drivers/built-in.o: In function `start_streaming':
stk1160-v4l.c:(.text+0xd4a9f): undefined reference to `usb_set_interface'
stk1160-v4l.c:(.text+0xd4afa): undefined reference to `usb_submit_urb'
stk1160-v4l.c:(.text+0xd4ba3): undefined reference to `usb_set_interface'
drivers/built-in.o: In function `stk1160_isoc_irq':
stk1160-video.c:(.text+0xd509b): undefined reference to `usb_submit_urb'
drivers/built-in.o: In function `stk1160_cancel_isoc':
(.text+0xd50ef): undefined reference to `usb_kill_urb'
drivers/built-in.o: In function `stk1160_free_isoc':
(.text+0xd5155): undefined reference to `usb_free_coherent'
drivers/built-in.o: In function `stk1160_free_isoc':
(.text+0xd515d): undefined reference to `usb_free_urb'
drivers/built-in.o: In function `stk1160_alloc_isoc':
(.text+0xd5278): undefined reference to `usb_alloc_urb'
drivers/built-in.o: In function `stk1160_alloc_isoc':
(.text+0xd52c2): undefined reference to `usb_alloc_coherent'
drivers/built-in.o: In function `stk1160_alloc_isoc':
(.text+0xd53c4): undefined reference to `usb_free_urb'
drivers/built-in.o: In function `zr364xx_driver_init':
zr364xx.c:(.init.text+0x463e): undefined reference to `usb_register_driver'
drivers/built-in.o: In function `pvr_init':
pvrusb2-main.c:(.init.text+0x4662): undefined reference to `usb_register_driver'
drivers/built-in.o: In function `stk1160_usb_driver_init':
stk1160-core.c:(.init.text+0x467d): undefined reference to `usb_register_driver'
drivers/built-in.o: In function `zr364xx_driver_exit':
zr364xx.c:(.exit.text+0x1377): undefined reference to `usb_deregister'
drivers/built-in.o: In function `pvr_exit':
pvrusb2-main.c:(.exit.text+0x1389): undefined reference to `usb_deregister'
drivers/built-in.o: In function `stk1160_usb_driver_exit':
stk1160-core.c:(.exit.text+0x13a0): undefined reference to `usb_deregister'
Suggested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Sun, 15 Sep 2013 11:31:28 +0000 (13:31 +0200)]
drm/radeon: avoid UVD corruptions on AGP cards
commit
4f66c59922cbcda14c9e103e6c7f4ee616360d43 upstream.
Putting everything into VRAM seems to help.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 13 Sep 2013 22:33:16 +0000 (18:33 -0400)]
drm/radeon: fix panel scaling with eDP and LVDS bridges
commit
855f5f1d882a34e4e9dd27b299737cd3508a5624 upstream.
We were using the wrong set_properly callback so we always
ended up with Full scaling even if something else (Center or
Full aspect) was selected.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 9 Sep 2013 14:54:22 +0000 (10:54 -0400)]
drm/radeon/atom: workaround vbios bug in transmitter table on rs880 (v2)
commit
91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 upstream.
The OUTPUT_ENABLE action jumps past the point in the coder where
the data_offset is set on certain rs780 cards. This worked
previously because the OUTPUT_ENABLE action is always called
immediately after the ENABLE action so the data_offset remained
set. In
6f8bbaf568c7f2c497558bfd04654c0b9841ad57
(drm/radeon/atom: initialize more atom interpretor elements to 0),
we explictly reset data_offset to 0 between atom calls which then
caused this to fail. The fix is to just skip calling the
OUTPUT_ENABLE action on the problematic chipsets. The ENABLE
action does the same thing and more. Ultimately, we could
probably drop the OUTPUT_ENABLE action all together on DCE3
asics.
fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60791
v2: only rs880 seems to be affected
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Mon, 9 Sep 2013 10:37:37 +0000 (12:37 +0200)]
rt2800: change initialization sequence to fix system freeze
commit
f4e1a4d3ecbb9e42bdf8e7869ee8a4ebfa27fb20 upstream.
My commit
commit
c630ccf1a127578421a928489d51e99c05037054
Author: Stanislaw Gruszka <stf_xl@wp.pl>
Date: Sat Mar 16 19:19:46 2013 +0100
rt2800: rearrange bbp/rfcsr initialization
make Maxim machine freeze when try to start wireless device.
Initialization order and sending MCU_BOOT_SIGNAL request, changed in
above commit, is important. Doing things incorrectly make PCIe bus
problems, which can froze the machine.
This patch change initialization sequence like vendor driver do:
function NICInitializeAsic() from
2011_1007_RT5390_RT5392_Linux_STA_V2.5.0.3_DPO (PCI devices) and
DPO_RT5572_LinuxSTA_2.6.1.3_20121022 (according Mediatek, latest driver
for RT8070/RT3070/RT3370/RT3572/RT5370/RT5372/RT5572 USB devices).
It fixes freezes on Maxim system.
Resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=
1000679
Reported-and-tested-by: Maxim Polyakov <polyakov@dexmalabs.com>
Bisected-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 27 Aug 2013 16:36:01 +0000 (12:36 -0400)]
drm/radeon: fix handling of variable sized arrays for router objects
commit
fb93df1c2d8b3b1fb16d6ee9e32554e0c038815d upstream.
The table has the following format:
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT //usSrcDstTableOffset pointing to this structure
{
UCHAR ucNumberOfSrc;
USHORT usSrcObjectID[1];
UCHAR ucNumberOfDst;
USHORT usDstObjectID[1];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;
usSrcObjectID[] and usDstObjectID[] are variably sized, so we
can't access them directly. Use pointers and update the offset
appropriately when accessing the Dst members.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 26 Aug 2013 21:52:12 +0000 (17:52 -0400)]
drm/radeon: fix resume on some rs4xx boards (v2)
commit
acf88deb8ddbb73acd1c3fa32fde51af9153227f upstream.
Setting MC_MISC_CNTL.GART_INDEX_REG_EN causes hangs on
some boards on resume. The systems seem to work fine
without touching this bit so leave it as is.
v2: read-modify-write the GART_INDEX_REG_EN bit.
I suspect the problem is that we are losing the other
settings in the register.
fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=52952
Reported-by: Ondrej Zary <linux@rainbow-software.org>
Tested-by: Daniel Tobias <dan.g.tob@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 19 Aug 2013 15:15:43 +0000 (11:15 -0400)]
drm/radeon: update line buffer allocation for dce6
commit
290d24576ccf1aa0373d2185cedfe262d0d4952a upstream.
We need to allocate line buffer to each display when
setting up the watermarks. Failure to do so can lead
to a blank screen. This fixes blank screen problems
on dce6 asics.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=64850
Based on an initial fix from:
Jay Cornwall <jay.cornwall@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 19 Aug 2013 15:06:50 +0000 (11:06 -0400)]
drm/radeon: update line buffer allocation for dce4.1/5
commit
0b31e02363b0db4e7931561bc6c141436e729d9f upstream.
We need to allocate line buffer to each display when
setting up the watermarks. Failure to do so can lead
to a blank screen. This fixes blank screen problems
on dce4.1/5 asics.
Based on an initial fix from:
Jay Cornwall <jay.cornwall@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tom Stellard [Fri, 16 Aug 2013 21:47:39 +0000 (17:47 -0400)]
drm/radeon/si: Add support for CP DMA to CS checker for compute v2
commit
e5b9e7503eb1f4884efa3b321d3cc47806779202 upstream.
Also add a new RADEON_INFO query to check that CP DMA packets are
supported on the compute ring.
CP DMA has been supported since the 3.8 kernel, but due to an oversight
we forgot to teach the CS checker that the CP DMA packet was legal for
the compute ring on Southern Islands GPUs.
This patch fixes a bug where the radeon driver will incorrectly reject a legal
CP DMA packet from user space. I would like to have the patch
backported to stable so that we don't have to require Mesa users to use a
bleeding edge kernel in order to take advantage of this feature which
is already present in the stable kernels (3.8 and newer).
v2:
- Don't bump kms version, so this patch can be backported to stable
kernels.
Signed-off-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Wed, 7 Aug 2013 23:34:53 +0000 (19:34 -0400)]
drm/radeon: fix endian bugs in hw i2c atom routines
commit
4543eda52113d1e2cc0e9bf416f79597e6ef1ec7 upstream.
Need to swap the data fetched over i2c properly. This
is the same fix as the endian fix for aux channel
transactions.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 20 Aug 2013 18:59:01 +0000 (14:59 -0400)]
drm/radeon: fix LCD record parsing
commit
95663948ba22a4be8b99acd67fbf83e86ddffba4 upstream.
If the LCD table contains an EDID record, properly account
for the edid size when walking through the records.
This should fix error messages about unknown LCD records.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Emil Velikov [Fri, 23 Aug 2013 17:43:42 +0000 (18:43 +0100)]
drm/nv50/disp: prevent false output detection on the original nv50
commit
5087f51da805f53cba7366f70d596e7bde2a5486 upstream.
Commit
ea9197cc323839ef3d5280c0453b2c622caa6bc7 effectively enabled the
use of an improved DAC detection code, but introduced a regression on
the original nv50 chipset, causing a ghost monitor to be detected.
v2 (Ben Skeggs): the offending line was likely a thinko, removed it for
all chipsets (tested nv50 and nve6 to cover entire range) and added
some additional debugging.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67382
Tested-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Skeggs [Tue, 17 Sep 2013 04:21:15 +0000 (14:21 +1000)]
drm/ttm: fix the tt_populated check in ttm_tt_destroy()
commit
182b17c8dc4e83aab000ce86587b6810e515da87 upstream.
After a vmalloc failure in ttm_dma_tt_alloc_page_directory(),
ttm_dma_tt_init() will call ttm_tt_destroy() to cleanup, and end up
inside the driver's unpopulate() hook when populate() has never yet
been called.
On nouveau, the first issue to be hit because of this is that
dma_address[] may be a NULL pointer. After working around this,
ttm_pool_unpopulate() may potentially hit the same issue with
the pages[] array.
It seems to make more sense to avoid calling unpopulate on already
unpopulated TTMs than to add checks to all the implementations.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Airlie [Thu, 12 Sep 2013 05:31:04 +0000 (15:31 +1000)]
drm/ast: fix the ast open key function
commit
2e8378136f28bea960cec643d3fa5d843c9049ec upstream.
When porting from UMS I mistyped this from the wrong place, AST noticed
and pointed it out, so we should fix it to be like the X.org driver.
Reported-by: Y.C. Chen <yc_chen@aspeedtech.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Herrmann [Mon, 26 Aug 2013 13:16:49 +0000 (15:16 +0200)]
drm: fix DRM_IOCTL_MODE_GETFB handle-leak
commit
101b96f32956ee99bf1468afaf572b88cda9f88b upstream.
DRM_IOCTL_MODE_GETFB is used to retrieve information about a given
framebuffer ID. It is a read-only helper and was thus declassified for
unprivileged access in:
commit
a14b1b42477c5ef089fcda88cbaae50d979eb8f9
Author: Mandeep Singh Baines <mandeep.baines@gmail.com>
Date: Fri Jan 20 12:11:16 2012 -0800
drm: remove master fd restriction on mode setting getters
However, alongside width, height and stride information,
DRM_IOCTL_MODE_GETFB also passes back a handle to the underlying buffer of
the framebuffer. This handle allows users to mmap() it and read or write
into it. Obviously, this should be restricted to DRM-Master.
With the current setup, *any* process with access to /dev/dri/card0 (which
means any process with access to hardware-accelerated rendering) can
access the current screen framebuffer and modify it ad libitum.
For backwards-compatibility reasons we want to keep the
DRM_IOCTL_MODE_GETFB call unprivileged. Besides, it provides quite useful
information regarding screen setup. So we simply test whether the caller
is the current DRM-Master and if not, we return 0 as handle, which is
always invalid. A following DRM_IOCTL_GEM_CLOSE on this handle will fail
with EINVAL, but we accept this. Users shouldn't test for errors during
GEM_CLOSE, anyway. And it is still better as a failing MODE_GETFB call.
v2: add capable(CAP_SYS_ADMIN) check for compatibility with i-g-t
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Sun, 8 Sep 2013 19:57:13 +0000 (21:57 +0200)]
drm/i915: fix wait_for_pending_flips vs gpu hang deadlock
commit
17e1df07df0fbc77696a1e1b6ccf9f2e5af70e40 upstream.
My g33 here seems to be shockingly good at hitting them all. This time
around kms_flip/flip-vs-panning-vs-hang blows up:
intel_crtc_wait_for_pending_flips correctly checks for gpu hangs and
if a gpu hang is pending aborts the wait for outstanding flips so that
the setcrtc call will succeed and release the crtc mutex. And the gpu
hang handler needs that lock in intel_display_handle_reset to be able
to complete outstanding flips.
The problem is that we can race in two ways:
- Waiters on the dev_priv->pending_flip_queue aren't woken up after
we've the reset as pending, but before we actually start the reset
work. This means that the waiter doesn't notice the pending reset
and hence will keep on hogging the locks.
Like with dev->struct_mutex and the ring->irq_queue wait queues we
there need to wake up everyone that potentially holds a lock which
the reset handler needs.
- intel_display_handle_reset was called _after_ we've already
signalled the completion of the reset work. Which means a waiter
could sneak in, grab the lock and never release it (since the
pageflips won't ever get released).
Similar to resetting the gem state all the reset work must complete
before we update the reset counter. Contrary to the gem reset we
don't need to have a second explicit wake up call since that will
have happened already when completing the pageflips. We also don't
have any issues that the completion happens while the reset state is
still pending - wait_for_pending_flips is only there to ensure we
display the right frame. After a gpu hang&reset events such
guarantees are out the window anyway. This is in contrast to the gem
code where too-early wake-up would result in unnecessary restarting
of ioctls.
Also, since we've gotten these various deadlocks and ordering
constraints wrong so often throw copious amounts of comments at the
code.
This deadlock regression has been introduced in the commit which added
the pageflip reset logic to the gpu hang work:
commit
96a02917a0131e52efefde49c2784c0421d6c439
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Feb 18 19:08:49 2013 +0200
drm/i915: Finish page flips and update primary planes after a GPU reset
v2:
- Add comments to explain how the wake_up serves as memory barriers
for the atomic_t reset counter.
- Improve the comments a bit as suggested by Chris Wilson.
- Extract the wake_up calls before/after the reset into a little
i915_error_wake_up and unconditionally wake up the
pending_flip_queue waiters, again as suggested by Chris Wilson.
v3: Throw copious amounts of comments at i915_error_wake_up as
suggested by Chris Wilson.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Wed, 4 Sep 2013 15:36:14 +0000 (17:36 +0200)]
drm/i915: fix gpu hang vs. flip stall deadlocks
commit
122f46badaafbe651f05c2c0f24cadee692f761b upstream.
Since we've started to clean up pending flips when the gpu hangs in
commit
96a02917a0131e52efefde49c2784c0421d6c439
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Feb 18 19:08:49 2013 +0200
drm/i915: Finish page flips and update primary planes after a GPU reset
the gpu reset work now also grabs modeset locks. But since work items
on our private work queue are not allowed to do that due to the
flush_workqueue from the pageflip code this results in a neat
deadlock:
INFO: task kms_flip:14676 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kms_flip D
ffff88019283a5c0 0 14676 13344 0x00000004
ffff88018e62dbf8 0000000000000046 ffff88013bdb12e0 ffff88018e62dfd8
ffff88018e62dfd8 00000000001d3b00 ffff88019283a5c0 ffff88018ec21000
ffff88018f693f00 ffff88018eece000 ffff88018e62dd60 ffff88018eece898
Call Trace:
[<
ffffffff8138ee7b>] schedule+0x60/0x62
[<
ffffffffa046c0dd>] intel_crtc_wait_for_pending_flips+0xb2/0x114 [i915]
[<
ffffffff81050ff4>] ? finish_wait+0x60/0x60
[<
ffffffffa0478041>] intel_crtc_set_config+0x7f3/0x81e [i915]
[<
ffffffffa031780a>] drm_mode_set_config_internal+0x4f/0xc6 [drm]
[<
ffffffffa0319cf3>] drm_mode_setcrtc+0x44d/0x4f9 [drm]
[<
ffffffff810e44da>] ? might_fault+0x38/0x86
[<
ffffffffa030d51f>] drm_ioctl+0x2f9/0x447 [drm]
[<
ffffffff8107a722>] ? trace_hardirqs_off+0xd/0xf
[<
ffffffffa03198a6>] ? drm_mode_setplane+0x343/0x343 [drm]
[<
ffffffff8112222f>] ? mntput_no_expire+0x3e/0x13d
[<
ffffffff81117f33>] vfs_ioctl+0x18/0x34
[<
ffffffff81118776>] do_vfs_ioctl+0x396/0x454
[<
ffffffff81396b37>] ? sysret_check+0x1b/0x56
[<
ffffffff81118886>] SyS_ioctl+0x52/0x7d
[<
ffffffff81396b12>] system_call_fastpath+0x16/0x1b
2 locks held by kms_flip/14676:
#0: (&dev->mode_config.mutex){+.+.+.}, at: [<
ffffffffa0316545>] drm_modeset_lock_all+0x22/0x59 [drm]
#1: (&crtc->mutex){+.+.+.}, at: [<
ffffffffa031656b>] drm_modeset_lock_all+0x48/0x59 [drm]
INFO: task kworker/u8:4:175 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u8:4 D
ffff88018de9a5c0 0 175 2 0x00000000
Workqueue: i915 i915_error_work_func [i915]
ffff88018e37dc30 0000000000000046 ffff8801938ab8a0 ffff88018e37dfd8
ffff88018e37dfd8 00000000001d3b00 ffff88018de9a5c0 ffff88018ec21018
0000000000000246 ffff88018e37dca0 000000005a865a86 ffff88018de9a5c0
Call Trace:
[<
ffffffff8138ee7b>] schedule+0x60/0x62
[<
ffffffff8138f23d>] schedule_preempt_disabled+0x9/0xb
[<
ffffffff8138d0cd>] mutex_lock_nested+0x205/0x3b1
[<
ffffffffa0477094>] ? intel_display_handle_reset+0x7e/0xbd [i915]
[<
ffffffffa0477094>] ? intel_display_handle_reset+0x7e/0xbd [i915]
[<
ffffffffa0477094>] intel_display_handle_reset+0x7e/0xbd [i915]
[<
ffffffffa044e0a2>] i915_error_work_func+0x128/0x147 [i915]
[<
ffffffff8104a89a>] process_one_work+0x1d4/0x35a
[<
ffffffff8104a821>] ? process_one_work+0x15b/0x35a
[<
ffffffff8104b4a5>] worker_thread+0x144/0x1f0
[<
ffffffff8104b361>] ? rescuer_thread+0x275/0x275
[<
ffffffff8105076d>] kthread+0xac/0xb4
[<
ffffffff81059d30>] ? finish_task_switch+0x3b/0xc0
[<
ffffffff810506c1>] ? __kthread_parkme+0x60/0x60
[<
ffffffff81396a6c>] ret_from_fork+0x7c/0xb0
[<
ffffffff810506c1>] ? __kthread_parkme+0x60/0x60
3 locks held by kworker/u8:4/175:
#0: (i915){.+.+.+}, at: [<
ffffffff8104a821>] process_one_work+0x15b/0x35a
#1: ((&dev_priv->gpu_error.work)){+.+.+.}, at: [<
ffffffff8104a821>] process_one_work+0x15b/0x35a
#2: (&crtc->mutex){+.+.+.}, at: [<
ffffffffa0477094>] intel_display_handle_reset+0x7e/0xbd [i915]
This blew up while running kms_flip/flip-vs-panning-vs-hang-interruptible
on one of my older machines.
Unfortunately (despite the proper lockdep annotations for
flush_workqueue) lockdep still doesn't detect this correctly, so we
need to rely on chance to discover these bugs.
Apply the usual bugfix and schedule the reset work on the system
workqueue to keep our own driver workqueue free of any modeset lock
grabbing.
Note that this is not a terribly serious regression since before the
offending commit we'd simply have stalled userspace forever due to
failing to abort all outstanding pageflips.
v2: Add a comment as requested by Chris.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Tue, 30 Jul 2013 19:18:15 +0000 (15:18 -0400)]
usb: gadget: fix a bug and a WARN_ON in dummy-hcd
commit
5f5610f69be3a925b1f79af27150bb7377bc9ad6 upstream.
This patch fixes a NULL pointer dereference and a WARN_ON in
dummy-hcd. These things were the result of moving to the UDC core
framework, and possibly of changes to that framework.
Now unloading a gadget driver causes the UDC to be stopped after the
gadget driver is unbound, not before. Therefore the "driver" argument
to dummy_udc_stop() can be NULL, so we must not try to print the
driver's name without checking first.
Also, the UDC framework automatically unregisters the gadget when the
UDC is deleted. Therefore a sysfs attribute file attached to the
gadget must be removed before the UDC is deleted, not after.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 11 Sep 2013 19:56:56 +0000 (21:56 +0200)]
HID: logitech-dj: validate output report details
commit
297502abb32e225fb23801fcdb0e4f6f8e17099a upstream.
A HID device could send a malicious output report that would cause the
logitech-dj HID driver to leak kernel memory contents to the device, or
trigger a NULL dereference during initialization:
[ 304.424553] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b
...
[ 304.780467] BUG: unable to handle kernel NULL pointer dereference at
0000000000000028
[ 304.781409] IP: [<
ffffffff815d50aa>] logi_dj_recv_send_report.isra.11+0x1a/0x90
CVE-2013-2895
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 11 Sep 2013 19:56:55 +0000 (21:56 +0200)]
HID: lenovo-tpkbd: validate output report details
commit
0a9cd0a80ac559357c6a90d26c55270ed752aa26 upstream.
A HID device could send a malicious output report that would cause the
lenovo-tpkbd HID driver to write just beyond the output report allocation
during initialization, causing a heap overflow:
[ 76.109807] usb 1-1: New USB device found, idVendor=17ef, idProduct=6009
...
[ 80.462540] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten
CVE-2013-2894
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 11 Sep 2013 19:56:53 +0000 (21:56 +0200)]
HID: steelseries: validate output report details
commit
41df7f6d43723deb7364340b44bc5d94bf717456 upstream.
A HID device could send a malicious output report that would cause the
steelseries HID driver to write beyond the output report allocation
during initialization, causing a heap overflow:
[ 167.981534] usb 1-1: New USB device found, idVendor=1038, idProduct=1410
...
[ 182.050547] BUG kmalloc-256 (Tainted: G W ): Redzone overwritten
CVE-2013-2891
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Benjamin Tissoires [Wed, 11 Sep 2013 19:56:59 +0000 (21:56 +0200)]
HID: lenovo-tpkbd: fix leak if tpkbd_probe_tp fails
commit
0ccdd9e7476680c16113131264ad6597bd10299d upstream.
If tpkbd_probe_tp() bails out, the probe() function return an error,
but hid_hw_stop() is never called.
fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=
1003998
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 11 Sep 2013 19:56:51 +0000 (21:56 +0200)]
HID: zeroplus: validate output report details
commit
78214e81a1bf43740ce89bb5efda78eac2f8ef83 upstream.
The zeroplus HID driver was not checking the size of allocated values
in fields it used. A HID device could send a malicious output report
that would cause the driver to write beyond the output report allocation
during initialization, causing a heap overflow:
[ 1442.728680] usb 1-1: New USB device found, idVendor=0c12, idProduct=0005
...
[ 1466.243173] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten
CVE-2013-2889
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 11 Sep 2013 19:56:54 +0000 (21:56 +0200)]
HID: LG: validate HID output report details
commit
0fb6bd06e06792469acc15bbe427361b56ada528 upstream.
A HID device could send a malicious output report that would cause the
lg, lg3, and lg4 HID drivers to write beyond the output report allocation
during an event, causing a heap overflow:
[ 325.245240] usb 1-1: New USB device found, idVendor=046d, idProduct=c287
...
[ 414.518960] BUG kmalloc-4096 (Not tainted): Redzone overwritten
Additionally, while lg2 did correctly validate the report details, it was
cleaned up and shortened.
CVE-2013-2893
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Benjamin Tissoires [Wed, 11 Sep 2013 19:56:58 +0000 (21:56 +0200)]
HID: multitouch: validate indexes details
commit
8821f5dc187bdf16cfb32ef5aa8c3035273fa79a upstream.
When working on report indexes, always validate that they are in bounds.
Without this, a HID device could report a malicious feature report that
could trick the driver into a heap overflow:
[ 634.885003] usb 1-1: New USB device found, idVendor=0596, idProduct=0500
...
[ 676.469629] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten
Note that we need to change the indexes from s8 to s16 as they can
be between -1 and 255.
CVE-2013-2897
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Benjamin Tissoires [Wed, 11 Sep 2013 19:56:57 +0000 (21:56 +0200)]
HID: validate feature and input report details
commit
cc6b54aa54bf40b762cab45a9fc8aa81653146eb upstream.
When dealing with usage_index, be sure to properly use unsigned instead of
int to avoid overflows.
When working on report fields, always validate that their report_counts are
in bounds.
Without this, a HID device could report a malicious feature report that
could trick the driver into a heap overflow:
[ 634.885003] usb 1-1: New USB device found, idVendor=0596, idProduct=0500
...
[ 676.469629] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten
CVE-2013-2897
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 11 Sep 2013 19:56:50 +0000 (21:56 +0200)]
HID: provide a helper for validating hid reports
commit
331415ff16a12147d57d5c953f3a961b7ede348b upstream.
Many drivers need to validate the characteristics of their HID report
during initialization to avoid misusing the reports. This adds a common
helper to perform validation of the report exisitng, the field existing,
and the expected number of values within the field.
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daisuke Nishimura [Tue, 10 Sep 2013 09:16:36 +0000 (18:16 +0900)]
sched/fair: Fix small race where child->se.parent,cfs_rq might point to invalid ones
commit
6c9a27f5da9609fca46cb2b183724531b48f71ad upstream.
There is a small race between copy_process() and cgroup_attach_task()
where child->se.parent,cfs_rq points to invalid (old) ones.
parent doing fork() | someone moving the parent to another cgroup
-------------------------------+---------------------------------------------
copy_process()
+ dup_task_struct()
-> parent->se is copied to child->se.
se.parent,cfs_rq of them point to old ones.
cgroup_attach_task()
+ cgroup_task_migrate()
-> parent->cgroup is updated.
+ cpu_cgroup_attach()
+ sched_move_task()
+ task_move_group_fair()
+- set_task_rq()
-> se.parent,cfs_rq of parent
are updated.
+ cgroup_fork()
-> parent->cgroup is copied to child->cgroup. (*1)
+ sched_fork()
+ task_fork_fair()
-> se.parent,cfs_rq of child are accessed
while they point to old ones. (*2)
In the worst case, this bug can lead to "use-after-free" and cause a panic,
because it's new cgroup's refcount that is incremented at (*1),
so the old cgroup(and related data) can be freed before (*2).
In fact, a panic caused by this bug was originally caught in RHEL6.4.
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<
ffffffff81051e3e>] sched_slice+0x6e/0xa0
[...]
Call Trace:
[<
ffffffff81051f25>] place_entity+0x75/0xa0
[<
ffffffff81056a3a>] task_fork_fair+0xaa/0x160
[<
ffffffff81063c0b>] sched_fork+0x6b/0x140
[<
ffffffff8106c3c2>] copy_process+0x5b2/0x1450
[<
ffffffff81063b49>] ? wake_up_new_task+0xd9/0x130
[<
ffffffff8106d2f4>] do_fork+0x94/0x460
[<
ffffffff81072a9e>] ? sys_wait4+0xae/0x100
[<
ffffffff81009598>] sys_clone+0x28/0x30
[<
ffffffff8100b393>] stub_clone+0x13/0x20
[<
ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b
Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/039601ceae06$733d3130$59b79390$@mxp.nes.nec.co.jp
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Wed, 4 Sep 2013 13:16:03 +0000 (15:16 +0200)]
sched/cputime: Do not scale when utime == 0
commit
5a8e01f8fa51f5cbce8f37acc050eb2319d12956 upstream.
scale_stime() silently assumes that stime < rtime, otherwise
when stime == rtime and both values are big enough (operations
on them do not fit in 32 bits), the resulting scaling stime can
be bigger than rtime. In consequence utime = rtime - stime
results in negative value.
User space visible symptoms of the bug are overflowed TIME
values on ps/top, for example:
$ ps aux | grep rcu
root 8 0.0 0.0 0 0 ? S 12:42 0:00 [rcuc/0]
root 9 0.0 0.0 0 0 ? S 12:42 0:00 [rcub/0]
root 10
62422329 0.0 0 0 ? R 12:42
21114581:37 [rcu_preempt]
root 11 0.1 0.0 0 0 ? S 12:42 0:02 [rcuop/0]
root 12
62422329 0.0 0 0 ? S 12:42
21114581:35 [rcuop/1]
root 10
62422329 0.0 0 0 ? R 12:42
21114581:37 [rcu_preempt]
or overflowed utime values read directly from /proc/$PID/stat
Reference:
https://lkml.org/lkml/2013/8/20/259
Reported-and-tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: stable@vger.kernel.org
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Borislav Petkov <bp@alien8.de>
Link: http://lkml.kernel.org/r/20130904131602.GC2564@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John Stultz [Wed, 11 Sep 2013 23:50:56 +0000 (16:50 -0700)]
timekeeping: Fix HRTICK related deadlock from ntp lock changes
commit
7bd36014460f793c19e7d6c94dab67b0afcfcb7f upstream.
Gerlando Falauto reported that when HRTICK is enabled, it is
possible to trigger system deadlocks. These were hard to
reproduce, as HRTICK has been broken in the past, but seemed
to be connected to the timekeeping_seq lock.
Since seqlock/seqcount's aren't supported w/ lockdep, I added
some extra spinlock based locking and triggered the following
lockdep output:
[ 15.849182] ntpd/4062 is trying to acquire lock:
[ 15.849765] (&(&pool->lock)->rlock){..-...}, at: [<
ffffffff810aa9b5>] __queue_work+0x145/0x480
[ 15.850051]
[ 15.850051] but task is already holding lock:
[ 15.850051] (timekeeper_lock){-.-.-.}, at: [<
ffffffff810df6df>] do_adjtimex+0x7f/0x100
<snip>
[ 15.850051] Chain exists of: &(&pool->lock)->rlock --> &p->pi_lock --> timekeeper_lock
[ 15.850051] Possible unsafe locking scenario:
[ 15.850051]
[ 15.850051] CPU0 CPU1
[ 15.850051] ---- ----
[ 15.850051] lock(timekeeper_lock);
[ 15.850051] lock(&p->pi_lock);
[ 15.850051] lock(timekeeper_lock);
[ 15.850051] lock(&(&pool->lock)->rlock);
[ 15.850051]
[ 15.850051] *** DEADLOCK ***
The deadlock was introduced by
06c017fdd4dc48451a ("timekeeping:
Hold timekeepering locks in do_adjtimex and hardpps") in 3.10
This patch avoids this deadlock, by moving the call to
schedule_delayed_work() outside of the timekeeper lock
critical section.
Reported-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Tested-by: Lin Ming <minggr@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Link: http://lkml.kernel.org/r/1378943457-27314-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Mon, 26 Aug 2013 13:18:53 +0000 (15:18 +0200)]
rt2800: fix wrong TX power compensation
commit
6e956da2027c767859128b9bfef085cf2a8e233b upstream.
We should not do temperature compensation on devices without
EXTERNAL_TX_ALC bit set (called DynamicTxAgcControl on vendor driver).
Such devices can have totally bogus TSSI parameters on the EEPROM,
but still threaded by us as valid and result doing wrong TX power
calculations.
This fix inability to connect to AP on slightly longer distance on
some Ralink chips/devices.
Reported-and-tested-by: Fabien ADAM <id2ndr@crocobox.org>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafał Miłecki [Sat, 14 Sep 2013 22:22:47 +0000 (00:22 +0200)]
bgmac: fix internal switch initialization
commit
6a391e7bf26c04a6df5f77290e1146941d210d49 upstream.
Some devices (BCM4749, BCM5357, BCM53572) have internal switch that
requires initialization. We already have code for this, but because
of the typo in code it was never working. This resulted in network not
working for some routers and possibility of soft-bricking them.
Use correct bit for switch initialization and fix typo in the define.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miklos Szeredi [Mon, 16 Sep 2013 12:51:59 +0000 (14:51 +0200)]
cifs: fix filp leak in cifs_atomic_open()
commit
dfb1d61b0e9f9e2c542e9adc8d970689f4114ff6 upstream.
If an error occurs after having called finish_open() then fput() needs to
be called on the already opened file.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Steve French <sfrench@samba.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fabio Porcedda [Mon, 16 Sep 2013 09:47:50 +0000 (11:47 +0200)]
net: usb: cdc_ether: Use wwan interface for Telit modules
commit
0092820407901a0b2c4e343e85f96bb7abfcded1 upstream.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafael J. Wysocki [Sat, 14 Sep 2013 01:38:20 +0000 (03:38 +0200)]
PCI / ACPI / PM: Clear pme_poll for devices in D3cold on wakeup
commit
834145156bedadfb50121f0bc5e9d9f9f942bcca upstream.
Commit
448bd85 (PCI/PM: add PCIe runtime D3cold support) added a
piece of code to pci_acpi_wake_dev() causing that function to behave
in a special way for devices in D3cold (so that their configuration
registers are not accessed before those devices are resumed).
However, it didn't take the clearing of the pme_poll flag into
account. That has to be done for all devices, even if they are in
D3cold, or pci_pme_list_scan() will not know that wakeup has been
signaled for the device and will poll its PME Status bit
unnecessarily.
Fix the problem by moving the clearing of the pme_poll flag in
pci_acpi_wake_dev() before the code introduced by commit
448bd85.
Reported-and-tested-by: David E. Box <david.e.box@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 27 Sep 2013 00:18:49 +0000 (17:18 -0700)]
Linux 3.10.13
Miklos Szeredi [Tue, 3 Sep 2013 12:28:38 +0000 (14:28 +0200)]
fuse: readdir: check for slash in names
commit
efeb9e60d48f7778fdcad4a0f3ad9ea9b19e5dfd upstream.
Userspace can add names containing a slash character to the directory
listing. Don't allow this as it could cause all sorts of trouble.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maxim Patlasov [Fri, 30 Aug 2013 13:06:04 +0000 (17:06 +0400)]
fuse: hotfix truncate_pagecache() issue
commit
06a7c3c2781409af95000c60a5df743fd4e2f8b4 upstream.
The way how fuse calls truncate_pagecache() from fuse_change_attributes()
is completely wrong. Because, w/o i_mutex held, we never sure whether
'oldsize' and 'attr->size' are valid by the time of execution of
truncate_pagecache(inode, oldsize, attr->size). In fact, as soon as we
released fc->lock in the middle of fuse_change_attributes(), we completely
loose control of actions which may happen with given inode until we reach
truncate_pagecache. The list of potentially dangerous actions includes
mmap-ed reads and writes, ftruncate(2) and write(2) extending file size.
The typical outcome of doing truncate_pagecache() with outdated arguments
is data corruption from user point of view. This is (in some sense)
acceptable in cases when the issue is triggered by a change of the file on
the server (i.e. externally wrt fuse operation), but it is absolutely
intolerable in scenarios when a single fuse client modifies a file without
any external intervention. A real life case I discovered by fsx-linux
looked like this:
1. Shrinking ftruncate(2) comes to fuse_do_setattr(). The latter sends
FUSE_SETATTR to the server synchronously, but before getting fc->lock ...
2. fuse_dentry_revalidate() is asynchronously called. It sends FUSE_LOOKUP
to the server synchronously, then calls fuse_change_attributes(). The
latter updates i_size, releases fc->lock, but before comparing oldsize vs
attr->size..
3. fuse_do_setattr() from the first step proceeds by acquiring fc->lock and
updating attributes and i_size, but now oldsize is equal to
outarg.attr.size because i_size has just been updated (step 2). Hence,
fuse_do_setattr() returns w/o calling truncate_pagecache().
4. As soon as ftruncate(2) completes, the user extends file size by
write(2) making a hole in the middle of file, then reads data from the hole
either by read(2) or mmap-ed read. The user expects to get zero data from
the hole, but gets stale data because truncate_pagecache() is not executed
yet.
The scenario above illustrates one side of the problem: not truncating the
page cache even though we should. Another side corresponds to truncating
page cache too late, when the state of inode changed significantly.
Theoretically, the following is possible:
1. As in the previous scenario fuse_dentry_revalidate() discovered that
i_size changed (due to our own fuse_do_setattr()) and is going to call
truncate_pagecache() for some 'new_size' it believes valid right now. But
by the time that particular truncate_pagecache() is called ...
2. fuse_do_setattr() returns (either having called truncate_pagecache() or
not -- it doesn't matter).
3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).
4. mmap-ed write makes a page in the extended region dirty.
The result will be the lost of data user wrote on the fourth step.
The patch is a hotfix resolving the issue in a simplistic way: let's skip
dangerous i_size update and truncate_pagecache if an operation changing
file size is in progress. This simplistic approach looks correct for the
cases w/o external changes. And to handle them properly, more sophisticated
and intrusive techniques (e.g. NFS-like one) would be required. I'd like to
postpone it until the issue is well discussed on the mailing list(s).
Changed in v2:
- improved patch description to cover both sides of the issue.
Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anand Avati [Tue, 20 Aug 2013 06:21:07 +0000 (02:21 -0400)]
fuse: invalidate inode attributes on xattr modification
commit
d331a415aef98717393dda0be69b7947da08eba3 upstream.
Calls like setxattr and removexattr result in updation of ctime.
Therefore invalidate inode attributes to force a refresh.
Signed-off-by: Anand Avati <avati@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maxim Patlasov [Mon, 12 Aug 2013 16:39:30 +0000 (20:39 +0400)]
fuse: postpone end_page_writeback() in fuse_writepage_locked()
commit
4a4ac4eba1010ef9a804569058ab29e3450c0315 upstream.
The patch fixes a race between ftruncate(2), mmap-ed write and write(2):
1) An user makes a page dirty via mmap-ed write.
2) The user performs shrinking truncate(2) intended to purge the page.
3) Before fuse_do_setattr calls truncate_pagecache, the page goes to
writeback. fuse_writepage_locked fills FUSE_WRITE request and releases
the original page by end_page_writeback.
4) fuse_do_setattr() completes and successfully returns. Since now, i_mutex
is free.
5) Ordinary write(2) extends i_size back to cover the page. Note that
fuse_send_write_pages do wait for fuse writeback, but for another
page->index.
6) fuse_writepage_locked proceeds by queueing FUSE_WRITE request.
fuse_send_writepage is supposed to crop inarg->size of the request,
but it doesn't because i_size has already been extended back.
Moving end_page_writeback to the end of fuse_writepage_locked fixes the
race because now the fact that truncate_pagecache is successfully returned
infers that fuse_writepage_locked has already called end_page_writeback.
And this, in turn, infers that fuse_flush_writepages has already called
fuse_send_writepage, and the latter used valid (shrunk) i_size. write(2)
could not extend it because of i_mutex held by ftruncate(2).
Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Brown [Thu, 29 Aug 2013 11:21:01 +0000 (12:21 +0100)]
clk: wm831x: Initialise wm831x pointer on init
commit
08442ce993deeb15a070c14cc3f3459e87d111e0 upstream.
Otherwise any attempt to interact with the hardware will crash. This is
what happens when drivers get written blind.
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Norris [Thu, 18 Jul 2013 08:17:02 +0000 (01:17 -0700)]
mtd: nand: fix NAND_BUSWIDTH_AUTO for x16 devices
commit
68e8078072e802e77134664f11d2ffbfbd2f8fbe upstream.
The code for NAND_BUSWIDTH_AUTO is broken. According to Alexander:
"I have a problem with attach NAND UBI in 16 bit mode.
NAND works fine if I specify NAND_BUSWIDTH_16 option, but not
working with NAND_BUSWIDTH_AUTO option. In second case NAND
chip is identifyed with ONFI."
See his report for the rest of the details:
http://lists.infradead.org/pipermail/linux-mtd/2013-July/047515.html
Anyway, the problem is that nand_set_defaults() is called twice, we
intend it to reset the chip functions to their x16 buswidth verions
if the buswidth changed from x8 to x16; however, nand_set_defaults()
does exactly nothing if called a second time.
Fix this by hacking nand_set_defaults() to reset the buswidth-dependent
functions if they were set to the x8 version the first time. Note that
this does not do anything to reset from x16 to x8, but that's not the
supported use case for NAND_BUSWIDTH_AUTO anyway.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reported-by: Alexander Shiyan <shc_work@mail.ru>
Tested-by: Alexander Shiyan <shc_work@mail.ru>
Cc: Matthieu Castet <matthieu.castet@parrot.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Grant Likely [Wed, 28 Aug 2013 20:24:17 +0000 (21:24 +0100)]
of: Fix missing memory initialization on FDT unflattening
commit
0640332e073be9207f0784df43595c0c39716e42 upstream.
Any calls to dt_alloc() need to be zeroed. This is a temporary fix, but
the allocation function itself needs to zero memory before returning
it. This is a follow up to patch
9e4012752, "of: fdt: fix memory
initialization for expanded DT" which fixed one call site but missed
another.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Acked-by: Wladislav Wiebe <wladislav.kw@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergei Shtylyov [Sun, 25 Aug 2013 03:38:15 +0000 (23:38 -0400)]
mmc: tmio_mmc_dma: fix PIO fallback on SDHI
commit
f936f9b67b7f8c2eae01dd303a0e90bd777c4679 upstream.
I'm testing SH-Mobile SDHI driver in DMA mode with a new DMA controller using
'bonnie++' and getting DMA error after which the tmio_mmc_dma.c code falls back
to PIO but all commands time out after that. It turned out that the fallback
code calls tmio_mmc_enable_dma() with RX/TX channels already freed and pointers
to them cleared, so that the function bails out early instead of clearing the
DMA bit in the CTL_DMA_ENABLE register. The regression was introduced by commit
162f43e31c5a376ec16336e5d0ac973373d54c89 (mmc: tmio: fix a deadlock).
Moving tmio_mmc_enable_dma() calls to the top of the PIO fallback code in
tmio_mmc_start_dma_{rx|tx}() helps.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Durgin [Tue, 27 Aug 2013 00:55:38 +0000 (17:55 -0700)]
rbd: fix I/O error propagation for reads
commit
17c1cc1d9293a568a00545469078e29555cc7f39 upstream.
When a request returns an error, the driver needs to report the entire
extent of the request as completed. Writes already did this, since
they always set xferred = length, but reads were skipping that step if
an error other than -ENOENT occurred. Instead, rbd would end up
passing 0 xferred to blk_end_request(), which would always report
needing more data. This resulted in an assert failing when more data
was required by the block layer, but all the object requests were
done:
[ 1868.719077] rbd: obj_request read result -108 xferred 0
[ 1868.719077]
[ 1868.719518] end_request: I/O error, dev rbd1, sector 0
[ 1868.719739]
[ 1868.719739] Assertion failure in rbd_img_obj_callback() at line 1736:
[ 1868.719739]
[ 1868.719739] rbd_assert(more ^ (which == img_request->obj_request_count));
Without this assert, reads that hit errors would hang forever, since
the block layer considered them incomplete.
Fixes: http://tracker.ceph.com/issues/5647
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Alex Elder <alex.elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
majianpeng [Tue, 16 Jul 2013 11:36:21 +0000 (19:36 +0800)]
ceph: Don't forget the 'up_read(&osdc->map_sem)' if met error.
commit
494ddd11be3e2621096bb425eed2886f8e8446d4 upstream.
Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sage Weil [Thu, 29 Aug 2013 00:17:29 +0000 (17:17 -0700)]
libceph: use pg_num_mask instead of pgp_num_mask for pg.seed calc
commit
9542cf0bf9b1a3adcc2ef271edbcbdba03abf345 upstream.
Fix a typo that used the wrong bitmask for the pg.seed calculation. This
is normally unnoticed because in most cases pg_num == pgp_num. It is, however,
a bug that is easily corrected.
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Alex Elder <alex.elder@linary.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
majianpeng [Tue, 16 Jul 2013 07:45:48 +0000 (15:45 +0800)]
libceph: unregister request in __map_request failed and nofail == false
commit
73d9f7eef3d98c3920e144797cc1894c6b005a1e upstream.
For nofail == false request, if __map_request failed, the caller does
cleanup work, like releasing the relative pages. It doesn't make any sense
to retry this request.
Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Weinberger [Sat, 17 Aug 2013 16:46:00 +0000 (18:46 +0200)]
um: Implement probe_kernel_read()
commit
f75b1b1bedfb498cc43a992ce4d7ed8df3b1e770 upstream.
UML needs it's own probe_kernel_read() to handle kernel
mode faults correctly.
The implementation uses mincore() on the host side to detect
whether a page is owned by the UML kernel process.
This fixes also a possible crash when sysrq-t is used.
Starting with 3.10 sysrq-t calls probe_kernel_read() to
read details from the kernel workers. As kernel worker are
completely async pointers may turn NULL while reading them.
Signed-off-by: Richard Weinberger <richard@nod.at>
Cc: <stian@nixia.no>
Cc: <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 12 Aug 2013 15:04:29 +0000 (11:04 -0400)]
drm/edid: add quirk for Medion MD30217PG
commit
118bdbd86b39dbb843155054021d2c59058f1e05 upstream.
This LCD monitor (1280x1024 native) has a completely
bogus detailed timing (640x350@70hz). User reports that
1280x1024@60 has waves so prefer 1280x1024@75.
Manufacturer: MED Model: 7b8 Serial#: 99188
Year: 2005 Week: 5
EDID Version: 1.3
Analog Display Input, Input Voltage Level: 0.700/0.700 V
Sync: Separate
Max Image Size [cm]: horiz.: 34 vert.: 27
Gamma: 2.50
DPMS capabilities: Off; RGB/Color Display
First detailed timing is preferred mode
redX: 0.645 redY: 0.348 greenX: 0.280 greenY: 0.605
blueX: 0.142 blueY: 0.071 whiteX: 0.313 whiteY: 0.329
Supported established timings:
720x400@70Hz
640x480@60Hz
640x480@72Hz
640x480@75Hz
800x600@56Hz
800x600@60Hz
800x600@72Hz
800x600@75Hz
1024x768@60Hz
1024x768@70Hz
1024x768@75Hz
1280x1024@75Hz
Manufacturer's mask: 0
Supported standard timings:
Supported detailed timing:
clock: 25.2 MHz Image Size: 337 x 270 mm
h_active: 640 h_sync: 688 h_sync_end 784 h_blank_end 800 h_border: 0
v_active: 350 v_sync: 350 v_sync_end 352 v_blanking: 449 v_border: 0
Monitor name: MD30217PG
Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 145 MHz
Serial No:
501099188
EDID (in hex):
00ffffffffffff0034a4b80774830100
050f010368221b962a0c55a559479b24
125054afcf00310a0101010101018180
000000000000d60980a0205e63103060
0200510e1100001e000000fc004d4433
3032313750470a202020000000fd0038
4c1e530e000a202020202020000000ff
003530313039393138380a2020200078
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reported-by: friedrich@mailstation.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Tue, 23 Jul 2013 18:01:23 +0000 (20:01 +0200)]
amd64_edac: Fix single-channel setups
commit
f0a56c480196a98479760862468cc95879df3de0 upstream.
It can happen that configurations are running in a single-channel mode
even with a dual-channel memory controller, by, say, putting the DIMMs
only on the one channel and leaving the other empty. This causes a
problem in init_csrows which implicitly assumes that when the second
channel is enabled, i.e. channel 1, the struct dimm hierarchy will be
present. Which is not.
So always allocate two channels unconditionally.
This provides for the nice side effect that the data structures are
initialized so some day, when memory hotplug is supported, it should
just work out of the box when all of a sudden a second channel appears.
Reported-and-tested-by: Roger Leigh <rleigh@debian.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Thu, 25 Jul 2013 09:49:11 +0000 (11:49 +0200)]
isofs: Refuse RW mount of the filesystem instead of making it RO
commit
17b7f7cf58926844e1dd40f5eb5348d481deca6a upstream.
Refuse RW mount of isofs filesystem. So far we just silently changed it
to RO mount but when the media is writeable, block layer won't notice
this change and thus will think device is used RW and will block eject
button of the drive. That is unexpected by users because for
non-writeable media eject button works just fine.
Userspace mount(8) command handles this just fine and retries mounting
with MS_RDONLY set so userspace shouldn't see any regression. Plus any
tool mounting isofs is likely confronted with the case of read-only
media where block layer already refuses to mount the filesystem without
MS_RDONLY set so our behavior shouldn't be anything new for it.
Reported-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric W. Biederman [Tue, 26 Mar 2013 02:57:10 +0000 (19:57 -0700)]
proc: Restrict mounting the proc filesystem
commit
aee1c13dd0f6c2fc56e0e492b349ee8ac655880f upstream.
Don't allow mounting the proc filesystem unless the caller has
CAP_SYS_ADMIN rights over the pid namespace. The principle here is if
you create or have capabilities over it you can mount it, otherwise
you get to live with what other people have mounted.
Andy pointed out that this is needed to prevent users in a user
namespace from remounting proc and specifying different hidepid and gid
options on already existing proc mounts.
Reported-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Libin [Wed, 11 Sep 2013 21:20:38 +0000 (14:20 -0700)]
mm/huge_memory.c: fix potential NULL pointer dereference
commit
a8f531ebc33052642b4bd7b812eedf397108ce64 upstream.
In collapse_huge_page() there is a race window between releasing the
mmap_sem read lock and taking the mmap_sem write lock, so find_vma() may
return NULL. So check the return value to avoid NULL pointer dereference.
collapse_huge_page
khugepaged_alloc_page
up_read(&mm->mmap_sem)
down_write(&mm->mmap_sem)
vma = find_vma(mm, address)
Signed-off-by: Libin <huawei.libin@huawei.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Thelen [Wed, 11 Sep 2013 21:23:08 +0000 (14:23 -0700)]
memcg: fix multiple large threshold notifications
commit
2bff24a3707093c435ab3241c47dcdb5f16e432b upstream.
A memory cgroup with (1) multiple threshold notifications and (2) at least
one threshold >=2G was not reliable. Specifically the notifications would
either not fire or would not fire in the proper order.
The __mem_cgroup_threshold() signaling logic depends on keeping 64 bit
thresholds in sorted order. mem_cgroup_usage_register_event() sorts them
with compare_thresholds(), which returns the difference of two 64 bit
thresholds as an int. If the difference is positive but has bit[31] set,
then sort() treats the difference as negative and breaks sort order.
This fix compares the two arbitrary 64 bit thresholds returning the
classic -1, 0, 1 result.
The test below sets two notifications (at 0x1000 and 0x81001000):
cd /sys/fs/cgroup/memory
mkdir x
for x in 4096
2164264960; do
cgroup_event_listener x/memory.usage_in_bytes $x | sed "s/^/$x listener:/" &
done
echo $$ > x/cgroup.procs
anon_leaker 500M
v3.11-rc7 fails to signal the 4096 event listener:
Leaking...
Done leaking pages.
Patched v3.11-rc7 properly notifies:
Leaking...
4096 listener:2013:8:31:14:13:36
Done leaking pages.
The fixed bug is old. It appears to date back to the introduction of
memcg threshold notifications in
v2.6.34-rc1-116-g2e72b6347c94 "memcg:
implement memory thresholds"
Signed-off-by: Greg Thelen <gthelen@google.com>
Acked-by: Michal Hocko <mhocko@suse.cz>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jie Liu [Wed, 11 Sep 2013 21:20:05 +0000 (14:20 -0700)]
ocfs2: fix the end cluster offset of FIEMAP
commit
28e8be31803b19d0d8f76216cb11b480b8a98bec upstream.
Call fiemap ioctl(2) with given start offset as well as an desired mapping
range should show extents if possible. However, we somehow figure out the
end offset of mapping via 'mapping_end -= cpos' before iterating the
extent records which would cause problems if the given fiemap length is
too small to a cluster size, e.g,
Cluster size 4096:
debugfs.ocfs2 1.6.3
Block Size Bits: 12 Cluster Size Bits: 12
The extended fiemap test utility From David:
https://gist.github.com/anonymous/
6172331
# dd if=/dev/urandom of=/ocfs2/test_file bs=1M count=1000
# ./fiemap /ocfs2/test_file 4096 10
start: 4096, length: 10
File /ocfs2/test_file has 0 extents:
# Logical Physical Length Flags
^^^^^ <-- No extent is shown
In this case, at ocfs2_fiemap(): cpos == mapping_end == 1. Hence the
loop of searching extent records was not executed at all.
This patch remove the in question 'mapping_end -= cpos', and loops
until the cpos is larger than the mapping_end as usual.
# ./fiemap /ocfs2/test_file 4096 10
start: 4096, length: 10
File /ocfs2/test_file has 1 extents:
# Logical Physical Length Flags
0:
0000000000000000 0000000056a01000 0000000006a00000 0000
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Reported-by: David Weber <wb@munzinger.de>
Tested-by: David Weber <wb@munzinger.de>
Cc: Sunil Mushran <sunil.mushran@gmail.com>
Cc: Mark Fashen <mfasheh@suse.de>
Cc: Joel Becker <jlbec@evilplan.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Wed, 11 Sep 2013 21:19:38 +0000 (14:19 -0700)]
pidns: fix vfork() after unshare(CLONE_NEWPID)
commit
e79f525e99b04390ca4d2366309545a836c03bf1 upstream.
Commit
8382fcac1b81 ("pidns: Outlaw thread creation after
unshare(CLONE_NEWPID)") nacks CLONE_VM if the forking process unshared
pid_ns, this obviously breaks vfork:
int main(void)
{
assert(unshare(CLONE_NEWUSER | CLONE_NEWPID) == 0);
assert(vfork() >= 0);
_exit(0);
return 0;
}
fails without this patch.
Change this check to use CLONE_SIGHAND instead. This also forbids
CLONE_THREAD automatically, and this is what the comment implies.
We could probably even drop CLONE_SIGHAND and use CLONE_THREAD, but it
would be safer to not do this. The current check denies CLONE_SIGHAND
implicitely and there is no reason to change this.
Eric said "CLONE_SIGHAND is fine. CLONE_THREAD would be even better.
Having shared signal handling between two different pid namespaces is
the case that we are fundamentally guarding against."
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Colin Walters <walters@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric W. Biederman [Thu, 29 Aug 2013 20:56:50 +0000 (13:56 -0700)]
pidns: Fix hang in zap_pid_ns_processes by sending a potentially extra wakeup
commit
a606488513543312805fab2b93070cefe6a3016c upstream.
Serge Hallyn <serge.hallyn@ubuntu.com> writes:
> Since commit
af4b8a83add95ef40716401395b44a1b579965f4 it's been
> possible to get into a situation where a pidns reaper is
> <defunct>, reparented to host pid 1, but never reaped. How to
> reproduce this is documented at
>
> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/
1168526
> (and see
> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/
1168526/comments/13)
> In short, run repeated starts of a container whose init is
>
> Process.exit(0);
>
> sysrq-t when such a task is playing zombie shows:
>
> [ 131.132978] init x
ffff88011fc14580 0 2084 2039 0x00000000
> [ 131.132978]
ffff880116e89ea8 0000000000000002 ffff880116e89fd8 0000000000014580
> [ 131.132978]
ffff880116e89fd8 0000000000014580 ffff8801172a0000 ffff8801172a0000
> [ 131.132978]
ffff8801172a0630 ffff88011729fff0 ffff880116e14650 ffff88011729fff0
> [ 131.132978] Call Trace:
> [ 131.132978] [<
ffffffff816f6159>] schedule+0x29/0x70
> [ 131.132978] [<
ffffffff81064591>] do_exit+0x6e1/0xa40
> [ 131.132978] [<
ffffffff81071eae>] ? signal_wake_up_state+0x1e/0x30
> [ 131.132978] [<
ffffffff8106496f>] do_group_exit+0x3f/0xa0
> [ 131.132978] [<
ffffffff810649e4>] SyS_exit_group+0x14/0x20
> [ 131.132978] [<
ffffffff8170102f>] tracesys+0xe1/0xe6
>
> Further debugging showed that every time this happened, zap_pid_ns_processes()
> started with nr_hashed being 3, while we were expecting it to drop to 2.
> Any time it didn't happen, nr_hashed was 1 or 2. So the reaper was
> waiting for nr_hashed to become 2, but free_pid() only wakes the reaper
> if nr_hashed hits 1.
The issue is that when the task group leader of an init process exits
before other tasks of the init process when the init process finally
exits it will be a secondary task sleeping in zap_pid_ns_processes and
waiting to wake up when the number of hashed pids drops to two. This
case waits forever as free_pid only sends a wake up when the number of
hashed pids drops to 1.
To correct this the simple strategy of sending a possibly unncessary
wake up when the number of hashed pids drops to 2 is adopted.
Sending one extraneous wake up is relatively harmless, at worst we
waste a little cpu time in the rare case when a pid namespace
appropaches exiting.
We can detect the case when the pid namespace drops to just two pids
hashed race free in free_pid.
Dereferencing pid_ns->child_reaper with the pidmap_lock held is safe
without out the tasklist_lock because it is guaranteed that the
detach_pid will be called on the child_reaper before it is freed and
detach_pid calls __change_pid which calls free_pid which takes the
pidmap_lock. __change_pid only calls free_pid if this is the
last use of the pid. For a thread that is not the thread group leader
the threads pid will only ever have one user because a threads pid
is not allowed to be the pid of a process, of a process group or
a session. For a thread that is a thread group leader all of
the other threads of that process will be reaped before it is allowed
for the thread group leader to be reaped ensuring there will only
be one user of the threads pid as a process pid. Furthermore
because the thread is the init process of a pid namespace all of the
other processes in the pid namespace will have also been already freed
leading to the fact that the pid will not be used as a session pid or
a process group pid for any other running process.
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Tested-by: Serge Hallyn <serge.hallyn@canonical.com>
Reported-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Williamson [Sat, 15 Jun 2013 16:27:19 +0000 (10:27 -0600)]
intel-iommu: Fix leaks in pagetable freeing
commit
3269ee0bd6686baf86630300d528500ac5b516d7 upstream.
At best the current code only seems to free the leaf pagetables and
the root. If you're unlucky enough to have a large gap (like any
QEMU guest with more than 3G of memory), only the first chunk of leaf
pagetables are freed (plus the root). This is a massive memory leak.
This patch re-writes the pagetable freeing function to use a
recursive algorithm and manages to not only free all the pagetables,
but does it without any apparent performance loss versus the current
broken version.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gera Kazakov [Mon, 9 Sep 2013 22:47:06 +0000 (15:47 -0700)]
target: Fix >= v3.9+ regression in PR APTPL + ALUA metadata write-out
commit
f730f9158f6ee7b5c4d892af6b51a72194445ea4 upstream.
This patch fixes a >= v3.9+ regression in __core_scsi3_write_aptpl_to_file()
+ core_alua_write_tpg_metadata() write-out, where a return value of -EIO was
incorrectly being returned upon success.
This bug was originally introduced in:
commit
0e9b10a90f1c30f25dd6f130130240745ab14010
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Sat Feb 23 15:22:43 2013 -0500
target: writev() on single-element vector is pointless
However, given that the return of core_scsi3_update_and_write_aptpl()
was not used to determine if a command should be returned with non GOOD
status, this bug was not being triggered in PR logic until v3.11-rc1 by
commit:
commit
459f213ba162bd13e113d6f92a8fa6c780fd67ed
Author: Andy Grover <agrover@redhat.com>
Date: Thu May 16 10:41:02 2013 -0700
target: Allocate aptpl_buf inside update_and_write_aptpl()
So, go ahead and only return -EIO if kernel_write() returned a
negative value.
Reported-by: Gera Kazakov <gkazakov@msn.com>
Signed-off-by: Gera Kazakov <gkazakov@msn.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felix Fietkau [Wed, 28 Aug 2013 08:41:42 +0000 (10:41 +0200)]
MIPS: ath79: Fix ar933x watchdog clock
commit
a1191927ace7e6f827132aa9e062779eb3f11fa5 upstream.
The watchdog device on the AR933x is connected to
the AHB clock, however the current code uses the
reference clock. Due to the wrong rate, the watchdog
driver can't calculate correct register values for
a given timeout value and the watchdog unexpectedly
restarts the system.
The code uses the wrong value since the initial
commit
04225e1d227c8e68d685936ecf42ac175fec0e54
(MIPS: ath79: add AR933X specific clock init)
The patch fixes the code to use the correct clock
rate to avoid the problem.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5777/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Brown [Thu, 29 Aug 2013 14:18:14 +0000 (07:18 -0700)]
leds: wm831x-status: Request a REG resource
commit
61abeba5222895d6900b13115f5d8eba7988d7d6 upstream.
The wm831x-status driver was not converted to use a REG resource when they
were introduced and the rest of the wm831x drivers converted, causing it
to fail to probe due to requesting the wrong resource type.
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Wed, 11 Sep 2013 15:47:26 +0000 (17:47 +0200)]
uprobes: Fix utask->depth accounting in handle_trampoline()
commit
878b5a6efd38030c7a90895dc8346e8fb1e09b4c upstream.
Currently utask->depth is simply the number of allocated/pending
return_instance's in uprobe_task->return_instances list.
handle_trampoline() should decrement this counter every time we
handle/free an instance, but due to typo it does this only if
->chained == T. This means that in the likely case this counter
is never decremented and the probed task can't report more than
MAX_URETPROBE_DEPTH events.
Reported-by: Mikhail Kulemin <Mikhail.Kulemin@ru.ibm.com>
Reported-by: Hemant Kumar Shaw <hkshaw@linux.vnet.ibm.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Anton Arapov <anton@redhat.com>
Cc: masami.hiramatsu.pt@hitachi.com
Cc: srikar@linux.vnet.ibm.com
Cc: systemtap@sourceware.org
Link: http://lkml.kernel.org/r/20130911154726.GA8093@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Behrens [Mon, 19 Aug 2013 16:51:13 +0000 (18:51 +0200)]
Btrfs: don't allow the replace procedure on read only filesystems
commit
bbb651e469d99f0088e286fdeb54acca7bb4ad4e upstream.
If you start the replace procedure on a read only filesystem, at
the end the procedure fails to write the updated dev_items to the
chunk tree. The problem is that this error is not indicated except
for a WARN_ON(). If the user now thinks that everything was done
as expected and destroys the source device (with mkfs or with a
hammer). The next mount fails with "failed to read chunk root" and
the filesystem is gone.
This commit adds code to fail the attempt to start the replace
procedure if the filesystem is mounted read-only.
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Wed, 14 Aug 2013 08:24:39 +0000 (05:24 -0300)]
media: siano: fix divide error on 0 counters
commit
ec532503209053bbee0c7dac410031e50835e01a upstream.
GIT_AUTHOR_DATE=
1376465691
I took a quick look at the code and wonder if the problem is caused by
an initial zero statistics message? This is all just a wild guess, but
if it is correct, then the attached untested patch might fix it...
Bjørn
>From
d78a0599d5b5d4da384eae08bf7da316389dfbe5 Mon Sep 17 00:00:00 2001
ts_packets and ets_packets counters can be 0. Don't fall over
if they are. Fixes:
[ 846.851711] divide error: 0000 [#1] SMP
[ 846.851806] Modules linked in: smsdvb dvb_core ir_lirc_codec lirc_dev ir_sanyo_decoder ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder rc_hauppauge smsusb smsmdtv rc_core pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) parport_pc ppdev lp parport cpufreq_userspace cpufreq_powersave cpufreq_stats cpufreq_conservative rfcomm bnep binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd dns_resolver fscache sunrpc ext4 jbd2 fuse tp_smapi(O) thinkpad_ec(O) loop firewire_sbp2 dm_crypt snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm thinkpad_acpi nvram snd_page_alloc hid_generic snd_seq_midi snd_seq_midi_event arc4 usbhid snd_rawmidi uvcvideo hid iwldvm coretemp kvm_intel mac8021
1 cdc_wdm
[ 846.853477] cdc_acm snd_seq videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media kvm radeon r852 ttm joydev cdc_ether usbnet pcmcia mii sm_common nand btusb drm_kms_helper tpm_tis acpi_cpufreq bluetooth iwlwifi nand_ecc drm nand_ids i2c_i801 mtd snd_seq_device iTCO_wdt iTCO_vendor_support r592 memstick lpc_ich mperf tpm yenta_socket pcmcia_rsrc pcmcia_core cfg80211 snd_timer snd pcspkr i2c_algo_bit crc16 i2c_core tpm_bios processor mfd_core wmi psmouse mei_me rfkill mei serio_raw soundcore evdev battery button video ac microcode ext3 mbcache jbd md_mod dm_mirror dm_region_hash dm_log dm_mod sg sr_mod sd_mod cdrom crc_t10dif firewire_ohci sdhci_pci sdhci mmc_core firewire_core crc_itu_t thermal thermal_sys ahci libahci ehci_pci uhci_hcd ehci_hcd libata scsi_mod usbcore e1000
e usb_common
[ 846.855310] ptp pps_core
[ 846.855356] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 3.10-2-amd64 #1 Debian 3.10.5-1
[ 846.855490] Hardware name: LENOVO 4061WFA/4061WFA, BIOS 6FET92WW (3.22 ) 12/14/2011
[ 846.855609] task:
ffffffff81613400 ti:
ffffffff81600000 task.ti:
ffffffff81600000
[ 846.855636] RIP: 0010:[<
ffffffffa092be0c>] [<
ffffffffa092be0c>] smsdvb_onresponse+0x264/0xa86 [smsdvb]
[ 846.863906] RSP: 0018:
ffff88013bc03cf0 EFLAGS:
00010046
[ 846.863906] RAX:
0000000000000000 RBX:
ffff880133bf6000 RCX:
0000000000000000
[ 846.863906] RDX:
0000000000000000 RSI:
ffff88005d3b58c0 RDI:
ffff880133bf6000
[ 846.863906] RBP:
ffff88005d1da000 R08:
0000000000000058 R09:
0000000000000015
[ 846.863906] R10:
0000000000001a0d R11:
000000000000021a R12:
ffff88005d3b58c0
[ 846.863906] R13:
ffff88005d1da008 R14:
00000000ffffff8d R15:
ffff880036cf5060
[ 846.863906] FS:
0000000000000000(0000) GS:
ffff88013bc00000(0000) knlGS:
0000000000000000
[ 846.863906] CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
[ 846.863906] CR2:
00007f3a4b69ae50 CR3:
0000000036dac000 CR4:
00000000000407f0
[ 846.863906] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 846.863906] DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
[ 846.863906] Stack:
[ 846.863906]
ffff88007a102000 ffff88005d1da000 ffff88005d3b58c0 0000000000085824
[ 846.863906]
ffffffffa08c5aa3 ffff88005d1da000 ffff8800a6907390 ffff8800a69073b0
[ 846.863906]
ffff8800a6907000 ffffffffa08b642c 000000000000021a ffff8800a69073b0
[ 846.863906] Call Trace:
[ 846.863906] <IRQ>
[ 846.863906]
[ 846.863906] [<
ffffffffa08c5aa3>] ? smscore_onresponse+0x1d5/0x353 [smsmdtv]
[ 846.863906] [<
ffffffffa08b642c>] ? smsusb_onresponse+0x146/0x192 [smsusb]
[ 846.863906] [<
ffffffffa004cb1a>] ? usb_hcd_giveback_urb+0x6c/0xac [usbcore]
[ 846.863906] [<
ffffffffa0217be1>] ? ehci_urb_done+0x62/0x72 [ehci_hcd]
[ 846.863906] [<
ffffffffa0217c82>] ? qh_completions+0x91/0x364 [ehci_hcd]
[ 846.863906] [<
ffffffffa0219bba>] ? ehci_work+0x8a/0x68e [ehci_hcd]
[ 846.863906] [<
ffffffff8107336c>] ? timekeeping_get_ns.constprop.10+0xd/0x31
[ 846.863906] [<
ffffffff81064d41>] ? update_cfs_rq_blocked_load+0xde/0xec
[ 846.863906] [<
ffffffff81058ec2>] ? run_posix_cpu_timers+0x25/0x575
[ 846.863906] [<
ffffffffa021aa46>] ? ehci_irq+0x211/0x23d [ehci_hcd]
[ 846.863906] [<
ffffffffa004c0c1>] ? usb_hcd_irq+0x31/0x48 [usbcore]
[ 846.863906] [<
ffffffff810996fd>] ? handle_irq_event_percpu+0x49/0x1a4
[ 846.863906] [<
ffffffff8109988a>] ? handle_irq_event+0x32/0x4b
[ 846.863906] [<
ffffffff8109bd76>] ? handle_fasteoi_irq+0x80/0xb6
[ 846.863906] [<
ffffffff8100e93e>] ? handle_irq+0x18/0x20
[ 846.863906] [<
ffffffff8100e657>] ? do_IRQ+0x40/0x95
[ 846.863906] [<
ffffffff813883ed>] ? common_interrupt+0x6d/0x6d
[ 846.863906] <EOI>
[ 846.863906]
[ 846.863906] [<
ffffffff812a011c>] ? arch_local_irq_enable+0x4/0x8
[ 846.863906] [<
ffffffff812a04f3>] ? cpuidle_enter_state+0x52/0xc1
[ 846.863906] [<
ffffffff812a0636>] ? cpuidle_idle_call+0xd4/0x143
[ 846.863906] [<
ffffffff8101398c>] ? arch_cpu_idle+0x5/0x17
[ 846.863906] [<
ffffffff81072571>] ? cpu_startup_entry+0x10d/0x187
[ 846.863906] [<
ffffffff816b3d3d>] ? start_kernel+0x3e8/0x3f3
[ 846.863906] [<
ffffffff816b3777>] ? repair_env_string+0x54/0x54
[ 846.863906] [<
ffffffff816b3598>] ? x86_64_start_kernel+0xf2/0xfd
[ 846.863906] Code: 25 09 00 00 c6 83 da 08 00 00 03 8b 45 54 48 01 83 b6 08 00 00 8b 45 50 48 01 83 db 08 00 00 8b 4d 18 69 c1 ff ff 00 00 03 4d 14 <48> f7 f1 89 83 a8 09 00 00 e9 68 fe ff ff 48 8b 7f 10 e8 79 92
[ 846.863906] RIP [<
ffffffffa092be0c>] smsdvb_onresponse+0x264/0xa86 [smsdvb]
[ 846.863906] RSP <
ffff88013bc03cf0>
Reference: http://bugs.debian.org/719623
Reported-by: Johannes Rohr <jorohr@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Fri, 9 Aug 2013 11:53:26 +0000 (08:53 -0300)]
media: mb86a20s: Fix TS parallel mode
commit
9d32069faacdc81fe1dcb5d297c32a3ac81da8f0 upstream.
changeset
768e6dadd74 caused a regression on using mb86a20s
in parallel mode, as the parallel mode selection got
overriden by mb86a20s_init2.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Shiyan [Sat, 15 Jun 2013 11:09:57 +0000 (08:09 -0300)]
media: media: coda: Fix DT driver data pointer for i.MX27
commit
7b0dd9e60e714951b5400dd0740b3c4c3c3cb76f upstream.
The data pointer should point to DT data, and not to the ID
array.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 28 Jun 2013 08:44:22 +0000 (05:44 -0300)]
media: v4l2: added missing mutex.h include to v4l2-ctrls.h
commit
a19dec6ea94c036af68c31930c1c92681f55af41 upstream.
This patch fixes following error:
include/media/v4l2-ctrls.h:193:15: error: field ‘_lock’ has incomplete type
include/media/v4l2-ctrls.h: In function ‘v4l2_ctrl_lock’:
include/media/v4l2-ctrls.h:570:2: error: implicit declaration of
function ‘mutex_lock’ [-Werror=implicit-function-declaration]
include/media/v4l2-ctrls.h: In function ‘v4l2_ctrl_unlock’:
include/media/v4l2-ctrls.h:579:2: error: implicit declaration of
function ‘mutex_unlock’ [-Werror=implicit-function-declaration]
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexey Khoroshilov [Wed, 3 Jul 2013 19:17:34 +0000 (16:17 -0300)]
media: hdpvr: fix iteration over uninitialized lists in hdpvr_probe()
commit
2e923a0527ac439e135b9961e58d3acd876bba10 upstream.
free_buff_list and rec_buff_list are initialized in the middle of hdpvr_probe(),
but if something bad happens before that, error handling code calls hdpvr_delete(),
which contains iteration over the lists (via hdpvr_free_buffers()).
The patch moves the lists initialization to the beginning and by the way fixes
goto label in error handling of registering videodev.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 28 Jun 2013 08:34:20 +0000 (05:34 -0300)]
media: DocBook: upgrade media_api DocBook version to 4.2
commit
8bfd4a68ecc003c1a142f35551be846d6b13e822 upstream.
Fixes the last three errors of media_api DocBook validatation:
(...)
media_api.xml:414: element imagedata: validity error : Value "SVG" for attribute format of imagedata is not among the enumerated set
media_api.xml:432: element imagedata: validity error : Value "SVG" for attribute format of imagedata is not among the enumerated set
media_api.xml:452: element imagedata: validity error : Value "SVG" for attribute format of imagedata is not among the enumerated set
(...)
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sachin Kamat [Mon, 15 Jul 2013 05:36:23 +0000 (02:36 -0300)]
media: s5p-g2d: Fix registration failure
commit
8a09a4cc9bd9389dc6a3b5b2dd3a7d64d2fab7e1 upstream.
Commit
1c1d86a1ea ("[media] v4l2: always require v4l2_dev,
rename parent to dev_parent") expects v4l2_dev to be always set.
It converted most of the drivers using the parent field of video_device
to v4l2_dev field. G2D driver did not set the parent field. Hence it got
left out. Without this patch we get the following boot warning and G2D
driver fails to register the video device.
WARNING: CPU: 0 PID: 1 at drivers/media/v4l2-core/v4l2-dev.c:775 __video_register_device+0xfc0/0x1028()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.11.0-rc1-00001-g1c3e372-dirty #9
[<
c0014b7c>] (unwind_backtrace+0x0/0xf4) from [<
c0011524>] (show_stack+0x10/0x14)
[<
c0011524>] (show_stack+0x10/0x14) from [<
c041d7a8>] (dump_stack+0x7c/0xb0)
[<
c041d7a8>] (dump_stack+0x7c/0xb0) from [<
c001dc94>] (warn_slowpath_common+0x6c/0x88)
[<
c001dc94>] (warn_slowpath_common+0x6c/0x88) from [<
c001dd4c>] (warn_slowpath_null+0x1c/0x24)
[<
c001dd4c>] (warn_slowpath_null+0x1c/0x24) from [<
c02cf8d4>] (__video_register_device+0xfc0/0x1028)
[<
c02cf8d4>] (__video_register_device+0xfc0/0x1028) from [<
c0311a94>] (g2d_probe+0x1f8/0x398)
[<
c0311a94>] (g2d_probe+0x1f8/0x398) from [<
c0247d54>] (platform_drv_probe+0x14/0x18)
[<
c0247d54>] (platform_drv_probe+0x14/0x18) from [<
c0246b10>] (driver_probe_device+0x108/0x220)
[<
c0246b10>] (driver_probe_device+0x108/0x220) from [<
c0246cf8>] (__driver_attach+0x8c/0x90)
[<
c0246cf8>] (__driver_attach+0x8c/0x90) from [<
c0245050>] (bus_for_each_dev+0x60/0x94)
[<
c0245050>] (bus_for_each_dev+0x60/0x94) from [<
c02462c8>] (bus_add_driver+0x1c0/0x24c)
[<
c02462c8>] (bus_add_driver+0x1c0/0x24c) from [<
c02472d0>] (driver_register+0x78/0x140)
[<
c02472d0>] (driver_register+0x78/0x140) from [<
c00087c8>] (do_one_initcall+0xf8/0x144)
[<
c00087c8>] (do_one_initcall+0xf8/0x144) from [<
c05b29e8>] (kernel_init_freeable+0x13c/0x1d8)
[<
c05b29e8>] (kernel_init_freeable+0x13c/0x1d8) from [<
c041a108>] (kernel_init+0xc/0x160)
[<
c041a108>] (kernel_init+0xc/0x160) from [<
c000e2f8>] (ret_from_fork+0x14/0x3c)
---[ end trace
4e0ec028b0028e02 ]---
s5p-g2d
12800000.g2d: Failed to register video device
s5p-g2d: probe of
12800000.g2d failed with error -22
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sylwester Nawrocki [Mon, 29 Jul 2013 09:53:59 +0000 (06:53 -0300)]
media: exynos4-is: Fix entity unregistration on error path
commit
d2b903b4427e417a73863cef36ad0796ea6b7404 upstream.
This patch corrects media entities unregistration order to make sure
the fimc.N.capture and fimc-lite video nodes are unregistered with
fimc->lock mutex held. This prevents races between video device open()
and defered probing and NULL pointer dereference in open() callback
as follows:
[ 77.645000] Unable to handle kernel NULL pointer dereference at virtual address 00000290t
[ 77.655000] pgd =
ee7a8000
[ 77.660000] [
00000290] *pgd=
6e13c831, *pte=
00000000, *ppte=
00000000
[ 77.665000] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 77.670000] Modules linked in: s5p_fimc ipv6 exynos_fimc_is exynos_fimc_lite
s5p_csis v4l2_mem2mem videobuf2_dma_contig videobuf2_memops exynos4_is_common videobuf2_core [last unloaded: s5p_fimc]
[ 77.685000] CPU: 0 PID : 2998 Comm: v4l_id Tainted: G W
3.10.0-next-20130709-00039-g39f491b-dirty #1548
[ 77.695000] task:
ee084000 ti:
ee46e000 task.ti:
ee46e000
[ 77.700000] PC is at __mutex_lock_slowpath+0x54/0x368
[ 77.705000] LR is at __mutex_lock_slowpath+0x24/0x368
[ 77.710000] pc : [<
c038dc10>] lr : [<
c038dbe0>] psr:
60000093
[ 77.710000] sp :
ee46fd70 ip :
000008c8 fp :
c054e34c
[ 77.725000] r10:
ee084000 r9 :
00000000 r8 :
ee439480
[ 77.730000] r7 :
ee46e000 r6 :
60000013 r5 :
00000290 r4 :
0000028c
[ 77.735000] r3 :
00000000 r2 :
00000000 r1 :
20000093 r0 :
00000001
[ 77.740000] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
[ 77.750000] Control:
10c5387d Table:
6e7a804a DAC:
00000015
[ 77.755000] Process v4l_id (pid: 2998, stack limit = 0xee46e238)
[ 77.760000] Stack: (0xee46fd70 to 0xee470000)
...
[ 77.935000] [<
c038dc10>] (__mutex_lock_slowpath+0x54/0x368) from [<
c038df30>] (mutex_lock+0xc/0x24)
[ 77.945000] [<
c038df30>] (mutex_lock+0xc/0x24) from [<
bf03fa90>] (fimc_lite_open+0x12c/0x2bc [exynos_fimc_lite])
[ 77.955000] [<
bf03fa90>] (fimc_lite_open+0x12c/0x2bc [exynos_fimc_lite]) from [<
c02ab11c>] (v4l2_open+0xa0/0xe0)
[ 77.965000] [<
c02ab11c>] (v4l2_open+0xa0/0xe0) from [<
c00b1de4>] (chrdev_open+0x88/0x170)
[ 77.975000] [<
c00b1de4>] (chrdev_open+0x88/0x170) from [<
c00ac710>] (do_dentry_open.isra.14+0x1d8/0x258)
[ 77.985000] [<
c00ac710>] (do_dentry_open.isra.14+0x1d8/0x258) from [<
c00ac860>] (finish_open+0x20/0x38)
[ 77.995000] [<
c00ac860>] (finish_open+0x20/0x38) from [<
c00ba658>] (do_last.isra.43+0x538/0xb1c)
[ 78.000000] [<
c00ba658>] (do_last.isra.43+0x538/0xb1c) from [<
c00bacf0>] (path_openat+0xb4/0x5c4)
[ 78.010000] [<
c00bacf0>] (path_openat+0xb4/0x5c4) from [<
c00bb4b4>] (do_filp_open+0x2c/0x80)
[ 78.020000] [<
c00bb4b4>] (do_filp_open+0x2c/0x80) from [<
c00ad744>] (do_sys_open+0xf4/0x1a8)
[ 78.025000] [<
c00ad744>] (do_sys_open+0xf4/0x1a8) from [<
c000e320>] (ret_fast_syscall+0x0/0x30)
[ 78.035000] Code:
1a000093 e10f6000 f10c0080 e2845004 (
e1953f9f)
Reported-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arun Kumar K [Fri, 26 Jul 2013 10:28:01 +0000 (07:28 -0300)]
media: exynos-gsc: Register v4l2 device
commit
d0b1c31349969973204fad21a076aecf131cc5e4 upstream.
Gscaler video device registration was happening without reference to
a parent v4l2_dev causing probe to fail. The patch creates a parent
v4l2 device and uses it for the gsc m2m video device registration.
This fixes regression introduced with comit commit
1c1d86a1ea07506
[media] v4l2: always require v4l2_dev, rename parent to dev_parent
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vasily Titskiy [Fri, 30 Aug 2013 22:25:04 +0000 (18:25 -0400)]
HID: usbhid: quirk for N-Trig DuoSense Touch Screen
commit
9e0bf92c223dabe0789714f8f85f6e26f8f9cda4 upstream.
The DuoSense touchscreen device causes a 10 second timeout. This fix
removes the delay.
Signed-off-by: Vasily Titskiy <qehgt0@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 28 Aug 2013 20:32:01 +0000 (22:32 +0200)]
HID: check for NULL field when setting values
commit
be67b68d52fa28b9b721c47bb42068f0c1214855 upstream.
Defensively check that the field to be worked on is not NULL.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Manoj Chourasia [Mon, 22 Jul 2013 10:03:13 +0000 (15:33 +0530)]
HID: hidraw: correctly deallocate memory on device disconnect
commit
212a871a3934beccf43431608c27ed2e05a476ec upstream.
This changes puts the commit
4fe9f8e203f back in place
with the fixes for slab corruption because of the commit.
When a device is unplugged, wait for all processes that
have opened the device to close before deallocating the device.
This commit was solving kernel crash because of the corruption in
rb tree of vmalloc. The rootcause was the device data pointer was
geting excessed after the memory associated with hidraw was freed.
The commit
4fe9f8e203f was buggy as it was also freeing the hidraw
first and then calling delete operation on the list associated with
that hidraw leading to slab corruption.
Signed-off-by: Manoj Chourasia <mchourasia@nvidia.com>
Tested-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Kosina [Mon, 2 Sep 2013 11:43:00 +0000 (13:43 +0200)]
HID: battery: don't do DMA from stack
commit
6c2794a2984f4c17a58117a68703cc7640f01c5a upstream.
Instead of using data from stack for DMA in hidinput_get_battery_property(),
allocate the buffer dynamically.
Reported-by: Richard Ryniker <ryniker@alum.mit.edu>
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bruno Prémont [Sat, 31 Aug 2013 12:07:48 +0000 (14:07 +0200)]
HID: picolcd: Prevent NULL pointer dereference on _remove()
commit
1cde501bb4655e98fb832194beb88ac73be5a05d upstream.
When picolcd is switched into bootloader mode (for FW flashing) make
sure not to try to dereference NULL-pointers of feature-devices during
unplug/unbind.
This fixes following BUG:
BUG: unable to handle kernel NULL pointer dereference at
00000298
IP: [<
f811f56b>] picolcd_exit_framebuffer+0x1b/0x80 [hid_picolcd]
*pde =
00000000
Oops: 0000 [#1]
Modules linked in: hid_picolcd syscopyarea sysfillrect sysimgblt fb_sys_fops
CPU: 0 PID: 15 Comm: khubd Not tainted
3.11.0-rc7-00002-g50d62d4 #2
EIP: 0060:[<
f811f56b>] EFLAGS:
00010292 CPU: 0
EIP is at picolcd_exit_framebuffer+0x1b/0x80 [hid_picolcd]
Call Trace:
[<
f811d1ab>] picolcd_remove+0xcb/0x120 [hid_picolcd]
[<
c1469b09>] hid_device_remove+0x59/0xc0
[<
c13464ca>] __device_release_driver+0x5a/0xb0
[<
c134653f>] device_release_driver+0x1f/0x30
[<
c134603d>] bus_remove_device+0x9d/0xd0
[<
c13439a5>] device_del+0xd5/0x150
[<
c14696a4>] hid_destroy_device+0x24/0x60
[<
c1474cbb>] usbhid_disconnect+0x1b/0x40
...
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 28 Aug 2013 20:31:28 +0000 (22:31 +0200)]
HID: ntrig: validate feature report details
commit
875b4e3763dbc941f15143dd1a18d10bb0be303b upstream.
A HID device could send a malicious feature report that would cause the
ntrig HID driver to trigger a NULL dereference during initialization:
[57383.031190] usb 3-1: New USB device found, idVendor=1b96, idProduct=0001
...
[57383.315193] BUG: unable to handle kernel NULL pointer dereference at
0000000000000030
[57383.315308] IP: [<
ffffffffa08102de>] ntrig_probe+0x25e/0x420 [hid_ntrig]
CVE-2013-2896
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Rafi Rubin <rafi@seas.upenn.edu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 28 Aug 2013 20:31:52 +0000 (22:31 +0200)]
HID: picolcd_core: validate output report details
commit
1e87a2456b0227ca4ab881e19a11bb99d164e792 upstream.
A HID device could send a malicious output report that would cause the
picolcd HID driver to trigger a NULL dereference during attr file writing.
[jkosina@suse.cz: changed
report->maxfield < 1
to
report->maxfield != 1
as suggested by Bruno].
CVE-2013-2899
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Bruno Prémont <bonbons@linux-vserver.org>
Acked-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 28 Aug 2013 20:29:55 +0000 (22:29 +0200)]
HID: validate HID report id size
commit
43622021d2e2b82ea03d883926605bdd0525e1d1 upstream.
The "Report ID" field of a HID report is used to build indexes of
reports. The kernel's index of these is limited to 256 entries, so any
malicious device that sets a Report ID greater than 255 will trigger
memory corruption on the host:
[ 1347.156239] BUG: unable to handle kernel paging request at
ffff88094958a878
[ 1347.156261] IP: [<
ffffffff813e4da0>] hid_register_report+0x2a/0x8b
CVE-2013-2888
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 28 Aug 2013 20:31:44 +0000 (22:31 +0200)]
HID: sensor-hub: validate feature report details
commit
9e8910257397372633e74b333ef891f20c800ee4 upstream.
A HID device could send a malicious feature report that would cause the
sensor-hub HID driver to read past the end of heap allocation, leaking
kernel memory contents to the caller.
CVE-2013-2898
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Kriwanek [Sun, 25 Aug 2013 08:46:13 +0000 (10:46 +0200)]
HID: Fix Speedlink VAD Cezanne support for some devices
commit
06bb5219118fb098f4b0c7dcb484b28a52bf1c14 upstream.
Some devices of the "Speedlink VAD Cezanne" model need more aggressive fixing
than already done.
I made sure through testing that this patch would not interfere with the proper
working of a device that is bug-free. (The driver drops EV_REL events with
abs(val) >= 256, which are not achievable even on the highest laser resolution
hardware setting.)
Signed-off-by: Stefan Kriwanek <mail@stefankriwanek.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 28 Aug 2013 20:30:49 +0000 (22:30 +0200)]
HID: pantherlord: validate output report details
commit
412f30105ec6735224535791eed5cdc02888ecb4 upstream.
A HID device could send a malicious output report that would cause the
pantherlord HID driver to write beyond the output report allocation
during initialization, causing a heap overflow:
[ 310.939483] usb 1-1: New USB device found, idVendor=0e8f, idProduct=0003
...
[ 315.980774] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten
CVE-2013-2892
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Henrik Rydberg [Sun, 1 Sep 2013 13:31:44 +0000 (15:31 +0200)]
HID: Correct the USB IDs for the new Macbook Air 6
commit
8c89cc17b91992845bd635813cd162fe8dfcec6e upstream.
A recent patch (
9d9a04ee) added support for the new machine, but got
the sequence of USB ids wrong. Reports from both Ian and Linus T show
that the 0x0291 id is for ISO, not ANSI, which should have the missing
number 0x0290. This patchs moves the three numbers accordingly, fixing
the problem.
Reported-and-tested-by: Ian Munsie <darkstarsword@gmail.com>
Tested-by: Linus G Thiel <linus@hanssonlarsson.se>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felix Fietkau [Tue, 13 Aug 2013 10:33:28 +0000 (12:33 +0200)]
ath9k: avoid accessing MRC registers on single-chain devices
commit
a1c781bb20ac1e03280e420abd47a99eb8bbdd3b upstream.
They are not implemented, and accessing them might trigger errors
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felix Fietkau [Sat, 10 Aug 2013 13:59:15 +0000 (15:59 +0200)]
ath9k: fix rx descriptor related race condition
commit
e96542e55a2aacf4bdeccfe2f17b77c4895b4df2 upstream.
Similar to a race condition that exists in the tx path, the hardware
might re-read the 'next' pointer of a descriptor of the last completed
frame. This only affects non-EDMA (pre-AR93xx) devices.
To deal with this race, defer clearing and re-linking a completed rx
descriptor until the next one has been processed.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felix Fietkau [Tue, 6 Aug 2013 12:18:10 +0000 (14:18 +0200)]
ath9k: always clear ps filter bit on new assoc
commit
026d5b07c03458f9c0ccd19c3850564a5409c325 upstream.
Otherwise in some cases, EAPOL frames might be filtered during the
initial handshake, causing delays and assoc failures.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John W. Linville [Fri, 9 Aug 2013 17:36:21 +0000 (13:36 -0400)]
brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()
commit
67d0cf50bd32b66eab709871714e55725ee30ce4 upstream.
The driver fails to check the results of DMA mapping in twp places,
which results in the following warning:
[ 28.078515] ------------[ cut here ]------------
[ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
[ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
single]
[ 28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
[ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O 3.10.0-rc7-wl+ #42
[ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
[ 28.078607]
0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
[ 28.078612]
ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
[ 28.078617]
ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
[ 28.078622] Call Trace:
[ 28.078624] <IRQ> [<
ffffffff8144f898>] dump_stack+0x19/0x1b
[ 28.078634] [<
ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
[ 28.078638] [<
ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
[ 28.078650] [<
ffffffff8122d7ae>] check_unmap+0x47e/0x930
[ 28.078655] [<
ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
[ 28.078679] [<
ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
[ 28.078691] [<
ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
[ 28.078707] [<
ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
[ 28.078717] [<
ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
[ 28.078731] [<
ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
[ 28.078736] [<
ffffffff81047dcc>] tasklet_action+0x6c/0xf0
--snip--
[ 28.078974] [<
ffffffff813891bd>] SyS_sendmsg+0xd/0x20
[ 28.078979] [<
ffffffff81455c24>] tracesys+0xdd/0xe2
[ 28.078982] ---[ end trace
6164d1a08148e9c8 ]---
[ 28.078984] Mapped at:
[ 28.078985] [<
ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
[ 28.078989] [<
ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
[ 28.079001] [<
ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
[ 28.079010] [<
ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
[ 28.079018] [<
ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
comment at the start of the routine to add that information, I also polished
the wording.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Cc: Hante Meuleman <meuleman@broadcom.com>
Cc: brcm80211-dev-list@broadcom.com
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Sat, 17 Aug 2013 14:07:17 +0000 (10:07 -0400)]
ext4: simplify truncation code in ext4_setattr()
commit
5208386c501276df18fee464e21d3c58d2d79517 upstream.
Merge conditions in ext4_setattr() handling inode size changes, also
move ext4_begin_ordered_truncate() call somewhat earlier because it
simplifies error recovery in case of failure. Also add error handling in
case i_disksize update fails.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Boris BREZILLON [Tue, 27 Aug 2013 13:19:21 +0000 (15:19 +0200)]
pinctrl: at91: fix get_pullup/down function return
commit
05d3534a321d7fe4524b3b83bb20318282f3ec2c upstream.
In PIO_PUSR and PIO_PPDSR register if a given bit is set 1 this means the
pullup/down for this pin (pin is represented as a bit position) is
disabled.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Mon, 9 Sep 2013 08:20:48 +0000 (10:20 +0200)]
ALSA: hda - Add Toshiba Satellite C870 to MSI blacklist
commit
83f72151352791836a1b9c1542614cc9bf71ac61 upstream.
Toshiba Satellite C870 shows interrupt problems occasionally when
certain mixer controls like "Mic Switch" is toggled. This seems
worked around by not using MSI.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=833585
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>