--- /dev/null
+From 118bdbd86b39dbb843155054021d2c59058f1e05 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Mon, 12 Aug 2013 11:04:29 -0400
+Subject: drm/edid: add quirk for Medion MD30217PG
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+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>
+
+---
+ drivers/gpu/drm/drm_edid.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/drm_edid.c
++++ b/drivers/gpu/drm/drm_edid.c
+@@ -125,6 +125,9 @@ static struct edid_quirk {
+
+ /* ViewSonic VA2026w */
+ { "VSC", 5020, EDID_QUIRK_FORCE_REDUCED_BLANKING },
++
++ /* Medion MD 30217 PG */
++ { "MED", 0x7b8, EDID_QUIRK_PREFER_LARGE_75 },
+ };
+
+ /*** DDC fetch and block validation ***/
--- /dev/null
+From 17b7f7cf58926844e1dd40f5eb5348d481deca6a Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Thu, 25 Jul 2013 11:49:11 +0200
+Subject: isofs: Refuse RW mount of the filesystem instead of making it RO
+
+From: Jan Kara <jack@suse.cz>
+
+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>
+
+---
+ fs/isofs/inode.c | 16 +++++-----------
+ 1 file changed, 5 insertions(+), 11 deletions(-)
+
+--- a/fs/isofs/inode.c
++++ b/fs/isofs/inode.c
+@@ -119,8 +119,8 @@ static void destroy_inodecache(void)
+
+ static int isofs_remount(struct super_block *sb, int *flags, char *data)
+ {
+- /* we probably want a lot more here */
+- *flags |= MS_RDONLY;
++ if (!(*flags & MS_RDONLY))
++ return -EROFS;
+ return 0;
+ }
+
+@@ -769,15 +769,6 @@ root_found:
+ */
+ s->s_maxbytes = 0x80000000000LL;
+
+- /*
+- * The CDROM is read-only, has no nodes (devices) on it, and since
+- * all of the files appear to be owned by root, we really do not want
+- * to allow suid. (suid or devices will not show up unless we have
+- * Rock Ridge extensions)
+- */
+-
+- s->s_flags |= MS_RDONLY /* | MS_NODEV | MS_NOSUID */;
+-
+ /* Set this for reference. Its not currently used except on write
+ which we don't have .. */
+
+@@ -1536,6 +1527,9 @@ struct inode *isofs_iget(struct super_bl
+ static struct dentry *isofs_mount(struct file_system_type *fs_type,
+ int flags, const char *dev_name, void *data)
+ {
++ /* We don't support read-write mounts */
++ if (!(flags & MS_RDONLY))
++ return ERR_PTR(-EACCES);
+ return mount_bdev(fs_type, flags, dev_name, data, isofs_fill_super);
+ }
+
--- /dev/null
+From 2bff24a3707093c435ab3241c47dcdb5f16e432b Mon Sep 17 00:00:00 2001
+From: Greg Thelen <gthelen@google.com>
+Date: Wed, 11 Sep 2013 14:23:08 -0700
+Subject: memcg: fix multiple large threshold notifications
+
+From: Greg Thelen <gthelen@google.com>
+
+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>
+
+---
+ mm/memcontrol.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/mm/memcontrol.c
++++ b/mm/memcontrol.c
+@@ -4349,7 +4349,13 @@ static int compare_thresholds(const void
+ const struct mem_cgroup_threshold *_a = a;
+ const struct mem_cgroup_threshold *_b = b;
+
+- return _a->threshold - _b->threshold;
++ if (_a->threshold > _b->threshold)
++ return 1;
++
++ if (_a->threshold < _b->threshold)
++ return -1;
++
++ return 0;
+ }
+
+ static int mem_cgroup_oom_notify_cb(struct mem_cgroup *memcg)
--- /dev/null
+From a8f531ebc33052642b4bd7b812eedf397108ce64 Mon Sep 17 00:00:00 2001
+From: Libin <huawei.libin@huawei.com>
+Date: Wed, 11 Sep 2013 14:20:38 -0700
+Subject: mm/huge_memory.c: fix potential NULL pointer dereference
+
+From: Libin <huawei.libin@huawei.com>
+
+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>
+
+---
+ mm/huge_memory.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/mm/huge_memory.c
++++ b/mm/huge_memory.c
+@@ -1894,6 +1894,8 @@ static void collapse_huge_page(struct mm
+ goto out;
+
+ vma = find_vma(mm, address);
++ if (!vma)
++ goto out;
+ hstart = (vma->vm_start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK;
+ hend = vma->vm_end & HPAGE_PMD_MASK;
+ if (address < hstart || address + HPAGE_PMD_SIZE > hend)
--- /dev/null
+From 28e8be31803b19d0d8f76216cb11b480b8a98bec Mon Sep 17 00:00:00 2001
+From: Jie Liu <jeff.liu@oracle.com>
+Date: Wed, 11 Sep 2013 14:20:05 -0700
+Subject: ocfs2: fix the end cluster offset of FIEMAP
+
+From: Jie Liu <jeff.liu@oracle.com>
+
+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>
+
+---
+ fs/ocfs2/extent_map.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/fs/ocfs2/extent_map.c
++++ b/fs/ocfs2/extent_map.c
+@@ -782,7 +782,6 @@ int ocfs2_fiemap(struct inode *inode, st
+ cpos = map_start >> osb->s_clustersize_bits;
+ mapping_end = ocfs2_clusters_for_bytes(inode->i_sb,
+ map_start + map_len);
+- mapping_end -= cpos;
+ is_last = 0;
+ while (cpos < mapping_end && !is_last) {
+ u32 fe_flags;
media-v4l2-added-missing-mutex.h-include-to-v4l2-ctrls.h.patch
mips-ath79-fix-ar933x-watchdog-clock.patch
intel-iommu-fix-leaks-in-pagetable-freeing.patch
+ocfs2-fix-the-end-cluster-offset-of-fiemap.patch
+memcg-fix-multiple-large-threshold-notifications.patch
+mm-huge_memory.c-fix-potential-null-pointer-dereference.patch
+isofs-refuse-rw-mount-of-the-filesystem-instead-of-making-it-ro.patch
+drm-edid-add-quirk-for-medion-md30217pg.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
