- 26 Nov, 2011 4 commits
-
-
Johannes Berg authored
commit c30bc947 upstream. L2TP for example uses NLA_MSECS like this: policy: [L2TP_ATTR_RECV_TIMEOUT] = { .type = NLA_MSECS, }, code: if (info->attrs[L2TP_ATTR_RECV_TIMEOUT]) cfg.reorder_timeout = nla_get_msecs(info->attrs[L2TP_ATTR_RECV_TIMEOUT]); As nla_get_msecs() is essentially nla_get_u64() plus the conversion to a HZ-based value, this will not properly reject attributes from userspace that aren't long enough and might overrun the message. Add NLA_MSECS to the attribute minlen array to check the size properly. Cc: Thomas Graf <tgraf@suug.ch> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
NeilBrown authored
commit dc6f55e9 upstream. The sunrpc layer keeps a cache of recently used credentials and 'unx_match' is used to find the credential which matches the current process. However unx_match allows a match when the cached credential has extra groups at the end of uc_gids list which are not in the process group list. So if a process with a list of (say) 4 group accesses a file and gains access because of the last group in the list, then another process with the same uid and gid, and a gid list being the first tree of the gids of the original process tries to access the file, it will be granted access even though it shouldn't as the wrong rpc credential will be used. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Bart Van Assche authored
commit 3308511c upstream. Make sure that SCSI device removal via scsi_remove_host() does finish all pending SCSI commands. Currently that's not the case and hence removal of a SCSI host during I/O can cause a deadlock. See also "blkdev_issue_discard() hangs forever if underlying storage device is removed" (http://bugzilla.kernel.org/show_bug.cgi?id=40472). See also http://lkml.org/lkml/2011/8/27/6. Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Petr Uzel authored
commit c68bf8ee upstream. The call to complete() in st_scsi_execute_end() wakes up sleeping thread in write_behind_check(), which frees the st_request, thus invalidating the pointer to the associated bio structure, which is then passed to the blk_rq_unmap_user(). Fix by storing pointer to bio structure into temporary local variable. This bug is present since at least linux-2.6.32. Signed-off-by:
Petr Uzel <petr.uzel@suse.cz> Reported-by:
Juergen Groß <juergen.gross@ts.fujitsu.com> Reviewed-by:
Jan Kara <jack@suse.cz> Acked-by:
Kai Mäkisara <kai.makisara@kolumbus.fi> Signed-off-by:
-
- 09 Nov, 2011 4 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This reverts commit 1badd98e. It breaks the build on powerpc systems: arch/powerpc/sysdev/mpic.c: In function 'irq_choose_cpu': arch/powerpc/sysdev/mpic.c:574: error: passing argument 1 of '__cpus_equal' from incompatible pointer type Reported-by:
Jiri Slaby <jslaby@suse.cz> Cc: Jiajun Wu <b06378@freescale.com> Cc: Li Yang <leoli@freescale.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit d85b1ce7. It breaks the build and probably shouldn't be in the 2.6.32 kernel Reported-by:
Stefan Bader <stefan.bader@canonical.com> Cc: Chris Paulson-Ellis <chris@edesix.com> Cc: Axel Lin <axel.lin@gmail.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 0f12a6ad. It causes too many build errors and needs to be done properly. Reported-by:
Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de> Cc: Ian Campbell <ian.campbell@citrix.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com> Cc: xen-devel <xen-devel@lists.xensource.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
- 07 Nov, 2011 32 commits
-
-
Greg Kroah-Hartman authored
-
Artur Zimmer authored
commit ce7e9065 upstream. Here is a patch for a new PID (zeitcontrol-device mifare-reader FT232BL(like FT232BM but lead free)). Signed-off-by:
Artur Zimmer <artur128@3dzimmer.de> Signed-off-by:
-
Florian Echtler authored
commit 2f1def26 upstream. A new device ID pair is added for Sierra Wireless MC8305. Signed-off-by:
Florian Echtler <floe@butterbrot.org> Signed-off-by:
-
Theodore Ts'o authored
commit 1cd9f097 upstream. This doesn't make much sense, and it exposes a bug in the kernel where attempts to create a new file in an append-only directory using O_CREAT will fail (but still leave a zero-length file). This was discovered when xfstests #79 was generalized so it could run on all file systems. Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Alexandre Bounine authored
commit e0c87bd9 upstream. Modify Ethernet addess macros to be compatible with BE/LE platforms Signed-off-by:
Alexandre Bounine <alexandre.bounine@idt.com> Cc: Chul Kim <chul.kim@idt.com> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Li Yang <leoli@freescale.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Zheng Liu authored
Does not corrispond with a direct commit in Linus's tree as it was fixed differently in the 3.0 release. We will meet with a BUG_ON() if following script is run. mkfs.ext4 -b 4096 /dev/sdb1 1000000 mount -t ext4 /dev/sdb1 /mnt/sdb1 fallocate -l 100M /mnt/sdb1/test sync for((i=0;i<170;i++)) do dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1 seek=`expr $i \* 2` done umount /mnt/sdb1 mount -t ext4 /dev/sdb1 /mnt/sdb1 dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1 seek=341 umount /mnt/sdb1 mount /dev/sdb1 /mnt/sdb1 dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1 seek=340 sync The reason is that it forgot to mark dirty when splitting two extents in ext4_ext_convert_to_initialized(). Althrough ex has been updated in memory, it is not dirtied both in ext4_ext_convert_to_initialized() and ext4_ext_insert_extent(). The disk layout is corrupted. Then it will meet with a BUG_ON() when writting at the start of that extent again. Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: Xiaoyun Mao <xiaoyun.maoxy@aliyun-inc.com> Cc: Yingbin Wang <yingbin.wangyb@aliyun-inc.com> Cc: Jia Wan <jia.wanj@aliyun-inc.com> Signed-off-by:Zheng Liu <wenqing.lz@taobao.com> Signed-off-by:
-
Eric Dumazet authored
commit 53b0f080 upstream. Ben Pfaff reported a kernel oops and provided a test program to reproduce it. https://kerneltrap.org/mailarchive/linux-netdev/2010/5/21/6277805 tc_fill_qdisc() should not be called for builtin qdisc, or it dereference a NULL pointer to get device ifindex. Fix is to always use tc_qdisc_dump_ignore() before calling tc_fill_qdisc(). Reported-by:
Ben Pfaff <blp@nicira.com> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Luciano Coelho authored
commit 57a27e1d upstream. When one of the SSID's length passed in a scan or sched_scan request is larger than 255, there will be an overflow in the u8 that is used to store the length before checking. This causes the check to fail and we overrun the buffer when copying the SSID. Fix this by checking the nl80211 attribute length before copying it to the struct. This is a follow up for the previous commit 208c72f4, which didn't fix the problem entirely. Reported-by:
Ido Yariv <ido@wizery.com> Signed-off-by:
Luciano Coelho <coelho@ti.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Dan Rosenberg authored
commit 7ac28817 upstream. A remote user can provide a small value for the command size field in the command header of an l2cap configuration request, resulting in an integer underflow when subtracting the size of the configuration request header. This results in copying a very large amount of data via memcpy() and destroying the kernel heap. Check for underflow. Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by:
Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by:
-
Hugh Dickins authored
commit 42c36f63 upstream. Commit a626ca6a ("vm: fix vm_pgoff wrap in stack expansion") fixed the case of an expanding mapping causing vm_pgoff wrapping when you had downward stack expansion. But there was another case where IA64 and PA-RISC expand mappings: upward expansion. This fixes that case too. Signed-off-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
-
Linus Torvalds authored
commit a626ca6a upstream. Commit 982134ba ("mm: avoid wrapping vm_pgoff in mremap()") fixed the case of a expanding mapping causing vm_pgoff wrapping when you used mremap. But there was another case where we expand mappings hiding in plain sight: the automatic stack expansion. This fixes that case too. This one also found by Robert Święcki, using his nasty system call fuzzer tool. Good job. Reported-and-tested-by:
Robert Święcki <robert@swiecki.net> Signed-off-by:
-
Filip Palian authored
commit 8d03e971 upstream. Structures "l2cap_conninfo" and "rfcomm_conninfo" have one padding byte each. This byte in "cinfo" is copied to userspace uninitialized. Signed-off-by:
Filip Palian <filip.palian@pjwstk.edu.pl> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Trond Myklebust authored
commit 0b760113 upstream. If the NLM daemon is killed on the NFS server, we can currently end up hanging forever on an 'unlock' request, instead of aborting. Basically, if the rpcbind request fails, or the server keeps returning garbage, we really want to quit instead of retrying. Tested-by:
Vasily Averin <vvs@sw.ru> Signed-off-by:
-
Al Viro authored
commit a9712bc1 upstream. All of those are rw-r--r-- and all are broken for suid - if you open a file before the target does suid-root exec, you'll be still able to access it. For personality it's not a big deal, but for syscall and stack it's a real problem. Fix: check that task is tracable for you at the time of read(). Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Eric Dumazet authored
commit bba14de9 upstream. Lower SCM_MAX_FD from 255 to 253 so that allocations for scm_fp_list are halved. (commit f8d570a4 added two pointers in this structure) scm_fp_dup() should not copy whole structure (and trigger kmemcheck warnings), but only the used part. While we are at it, only allocate needed size. Signed-off-by:
-
Manoj Iyer authored
commit 9fbdaeb4 upstream. The newer Lenovo ThinkPads have HKEY HID of LEN0068 instead of IBM0068. Added new HID so that thinkpad_acpi module will auto load on these newer Lenovo ThinkPads. Acked-by:
Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: stable@vger.kernel.org Signed-off-by:
Manoj Iyer <manoj.iyer@canonical.com> Signed-off-by:
Andy Lutomirski <luto@mit.edu> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Dan Carpenter authored
commit 4fd2c20d upstream. "m" is never NULL here. We need a different test for the end of list condition. Signed-off-by:
Dan Carpenter <error27@gmail.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by:
WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by:
-
Florian Fainelli authored
Commit 6d86a0ee (watchdog: mtx1-wdt: request gpio before using it) was backported from upstream. The patch is using a gpiolib call which is only available in kernel 2.6.34+. Fix build by using the "old" gpiolib API instead. Signed-off-by:
Florian Fainelli <florian@openwrt.org> Signed-off-by:
-
Florian Fainelli authored
Commit ec3eb823 was not applicable in 2.6.32 and introduces a build breakage. Revert that commit since it is irrelevant for this kernel version. Acked-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 262e2d9d. Turns out this breaks the build, and as such, really isn't needed for the 2.6.32-stable branch at all. Reported-by:
Phil Carmody <ext-phil.2.carmody@nokia.com> Cc: Anand Gadiyar <gadiyar@ti.com> Cc: Ajay Kumar Gupta <ajay.gupta@ti.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Ian Campbell authored
commit 9bab0b7f upstream This adds a mechanism to resume selected IRQs during syscore_resume instead of dpm_resume_noirq. Under Xen we need to resume IRQs associated with IPIs early enough that the resched IPI is unmasked and we can therefore schedule ourselves out of the stop_machine where the suspend/resume takes place. This issue was introduced by 676dc3cf "xen: Use IRQF_FORCE_RESUME". Back ported to 2.6.32 (which lacks syscore support) by calling the relavant resume function directly from sysdev_resume). Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com> Cc: xen-devel <xen-devel@lists.xensource.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Link: http://lkml.kernel.org/r/1318713254.11016.52.camel@dagon.hellion.org.ukSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Philipp Hahn authored
There is no upstream commit ID for this patch since it is not a straight backport from upstream. It is a fix only relevant to 2.6.32.y. Since 1d5f066e from 2.6.37 was back-ported to 2.6.32.40 as ad2088ca, the following patch is needed to add the needed reset logic to 2.6.32 as well. Bug #23257: Reset tsc_timestamp on TSC writes vcpu->last_guest_tsc is updated in vcpu_enter_guest() and kvm_arch_vcpu_put() by getting the last value of the TSC from the guest. On reset, the SeaBIOS resets the TSC to 0, which triggers a bug on the next call to kvm_write_guest_time(): Since vcpu->hw_clock.tsc_timestamp still contains the old value before the reset, "max_kernel_ns = vcpu->last_guest_tsc - vcpu->hw_clock.tsc_timestamp" gets negative. Since the variable is u64, it gets translated to a large positive value. [9333.197080] vcpu->last_guest_tsc =209_328_760_015 ← vcpu->hv_clock.tsc_timestamp=209_328_708_109 vcpu->last_kernel_ns =9_333_179_830_643 kernel_ns =9_333_197_073_429 max_kernel_ns =9_333_179_847_943 ← [9336.910995] vcpu->last_guest_tsc =9_438_510_584 ← vcpu->hv_clock.tsc_timestamp=211_080_593_143 vcpu->last_kernel_ns =9_333_763_732_907 kernel_ns =9_336_910_990_771 max_kernel_ns =6_148_296_831_006_663_830 ← For completeness, here are the values for my 3 GHz CPU: vcpu->hv_clock.tsc_shift =-1 vcpu->hv_clock.tsc_to_system_mul =2_863_019_502 This makes the guest kernel crawl very slowly when clocksource=kvmclock is used: sleeps take way longer than expected and don't match wall clock any more. The times printed with printk() don't match real time and the reboot often stalls for long times. In linux-git this isn't a problem, since on every MSR_IA32_TSC write vcpu->arch.hv_clock.tsc_timestamp is reset to 0, which disables above logic. The code there is only in arch/x86/kvm/x86.c, since much of the kvm-clock related code has been refactured for 2.6.37: 99e3e30a arch/x86/kvm/x86.c (Zachary Amsden 2010-08-19 22:07:17 -1000 1084) vcpu->arch.hv_clock.tsc_timestamp = 0; Signed-off-by:
Philipp Hahn <hahn@univention.de> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Ian Campbell authored
commit f611f2da upstream. The patches missed an indirect use of IRQF_NO_SUSPEND pulled in via IRQF_TIMER. The following patch fixes the issue. With this fixlet PV guest migration works just fine. I also booted the entire series as a dom0 kernel and it appeared fine. Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Jeff Moyer authored
commit c10b61f0 upstream. Hi, A user reported a kernel bug when running a particular program that did the following: created 32 threads - each thread took a mutex, grabbed a global offset, added a buffer size to that offset, released the lock - read from the given offset in the file - created a new thread to do the same - exited The result is that cfq's close cooperator logic would trigger, as the threads were issuing I/O within the mean seek distance of one another. This workload managed to routinely trigger a use after free bug when walking the list of merge candidates for a particular cfqq (cfqq->new_cfqq). The logic used for merging queues looks like this: static void cfq_setup_merge(struct cfq_queue *cfqq, struct cfq_queue *new_cfqq) { int process_refs, new_process_refs; struct cfq_queue *__cfqq; /* Avoid a circular list and skip interim queue merges */ while ((__cfqq = new_cfqq->new_cfqq)) { if (__cfqq == cfqq) return; new_cfqq = __cfqq; } process_refs = cfqq_process_refs(cfqq); /* * If the process for the cfqq has gone away, there is no * sense in merging the queues. */ if (process_refs == 0) return; /* * Merge in the direction of the lesser amount of work. */ new_process_refs = cfqq_process_refs(new_cfqq); if (new_process_refs >= process_refs) { cfqq->new_cfqq = new_cfqq; atomic_add(process_refs, &new_cfqq->ref); } else { new_cfqq->new_cfqq = cfqq; atomic_add(new_process_refs, &cfqq->ref); } } When a merge candidate is found, we add the process references for the queue with less references to the queue with more. The actual merging of queues happens when a new request is issued for a given cfqq. In the case of the test program, it only does a single pread call to read in 1MB, so the actual merge never happens. Normally, this is fine, as when the queue exits, we simply drop the references we took on the other cfqqs in the merge chain: /* * If this queue was scheduled to merge with another queue, be * sure to drop the reference taken on that queue (and others in * the merge chain). See cfq_setup_merge and cfq_merge_cfqqs. */ __cfqq = cfqq->new_cfqq; while (__cfqq) { if (__cfqq == cfqq) { WARN(1, "cfqq->new_cfqq loop detected\n"); break; } next = __cfqq->new_cfqq; cfq_put_queue(__cfqq); __cfqq = next; } However, there is a hole in this logic. Consider the following (and keep in mind that each I/O keeps a reference to the cfqq): q1->new_cfqq = q2 // q2 now has 2 process references q3->new_cfqq = q2 // q2 now has 3 process references // the process associated with q2 exits // q2 now has 2 process references // queue 1 exits, drops its reference on q2 // q2 now has 1 process reference // q3 exits, so has 0 process references, and hence drops its references // to q2, which leaves q2 also with 0 process references q4 comes along and wants to merge with q3 q3->new_cfqq still points at q2! We follow that link and end up at an already freed cfqq. So, the fix is to not follow a merge chain if the top-most queue does not have a process reference, otherwise any queue in the chain could be already freed. I also changed the logic to disallow merging with a queue that does not have any process references. Previously, we did this check for one of the merge candidates, but not the other. That doesn't really make sense. Without the attached patch, my system would BUG within a couple of seconds of running the reproducer program. With the patch applied, my system ran the program for over an hour without issues. This addresses the following bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16217 Thanks a ton to Phil Carns for providing the bug report and an excellent reproducer. [ Note for stable: this applies to 2.6.32/33/34 ]. Signed-off-by:
Jeff Moyer <jmoyer@redhat.com> Reported-by:
Phil Carns <carns@mcs.anl.gov> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
Suresh Jayaraman <sjayaraman@suse.de> Signed-off-by:
-
Jens Axboe authored
commit e00ef799 upstream We need to rework this logic post the cooperating cfq_queue merging, for now just get rid of it and Jeff Moyer will fix the fall out. Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Jeff Moyer authored
commit e6c5bc73 upstream. cfq_queues are merged if they are issuing requests within the mean seek distance of one another. This patch detects when the coopearting stops and breaks the queues back up. Signed-off-by:
-
Jeff Moyer authored
commit b3b6d040 upstream The flag used to indicate that a cfqq was allowed to jump ahead in the scheduling order due to submitting a request close to the queue that just executed. Since closely cooperating queues are now merged, the flag holds little meaning. Change it to indicate that multiple queues were merged. This will later be used to allow the breaking up of merged queues when they are no longer cooperating. Signed-off-by:
-
Jeff Moyer authored
commit df5fe3e8 upstream. When cooperating cfq_queues are detected currently, they are allowed to skip ahead in the scheduling order. It is much more efficient to automatically share the cfq_queue data structure between cooperating processes. Performance of the read-test2 benchmark (which is written to emulate the dump(8) utility) went from 12MB/s to 90MB/s on my SATA disk. NFS servers with multiple nfsd threads also saw performance increases. Signed-off-by:
-
Jeff Moyer authored
commit b2c18e1e upstream. async cfq_queue's are already shared between processes within the same priority, and forthcoming patches will change the mapping of cic to sync cfq_queue from 1:1 to 1:N. So, calculate the seekiness of a process based on the cfq_queue instead of the cfq_io_context. Signed-off-by:
-
Richard Weinberger authored
commit 85356398 upstream. ubd_file_size() cannot use ubd_dev->cow.file because at this time ubd_dev->cow.file is not initialized. Therefore, ubd_file_size() will always report a wrong disk size when COW files are used. Reading from /dev/ubd* would crash the kernel. We have to read the correct disk size from the COW file's backing file. Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Paul Fertser authored
commit 6571534b upstream. To configure pads during the initialisation a set of special constants is used, e.g. #define MX25_PAD_FEC_MDIO__FEC_MDIO IOMUX_PAD(0x3c4, 0x1cc, 0x10, 0, 0, PAD_CTL_HYS | PAD_CTL_PUS_22K_UP) The problem is that no pull-up/down is getting activated unless both PAD_CTL_PUE (pull-up enable) and PAD_CTL_PKE (pull/keeper module enable) set. This is clearly stated in the i.MX25 datasheet and is confirmed by the measurements on hardware. This leads to some rather hard to understand bugs such as misdetecting an absent ethernet PHY (a real bug i had), unstable data transfer etc. This might affect mx25, mx35, mx50, mx51 and mx53 SoCs. It's reasonable to expect that if the pullup value is specified, the intention was to have it actually active, so we implicitly add the needed bits. Signed-off-by:
Paul Fertser <fercerpav@gmail.com> Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 9bed77ee upstream. This device is not using the proper demod IF. Instead of using the IF macro, it is specifying a IF frequency. This doesn't work, as xc3028 needs to load an specific SCODE for the tuner. In this case, there's no IF table for 5 MHz. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
