- 27 Apr, 2017 22 commits
-
-
Uwe Kleine-König authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit 3bd32722 upstream. On some QNAP NAS devices the rtc can wake the machine. Several people noticed that once the machine was woken this way it fails to shut down. That's because the driver fails to acknowledge the interrupt and so it keeps active and restarts the machine immediatly after shutdown. See https://bugs.debian.org/794266 for a bug report. Doing this correctly requires to interpret the INT2 flag of the first read of the STATUS1 register because this bit is cleared by read. Note this is not maximally robust though because a pending irq isn't detected when the STATUS1 register was already read (and so INT2 is not set) but the irq was not disabled. But that is a hardware imposed problem that cannot easily be fixed by software. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Uwe Kleine-König authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit 8e6583f1 upstream. There were two deviations from the reference manual: you have to wait half a second when POC is active and you might have to repeat initialization when POC or BLD are still set after the sequence. Note however that as POC and BLD are cleared by read the driver might not be able to detect that a reset is necessary. I don't have a good idea how to fix this. Additionally report the value read from STATUS1 to the caller. This prepares the next patch. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Uwe Kleine-König authored
BugLink: http://bugs.launchpad.net/bugs/1681862 The rtc core calls the .read_alarm with all fields initialized to 0. As the s35390a driver doesn't touch some fields the returned date is interpreted as a date in January 1900. So make sure all fields are set to -1; some of them are then overwritten with the right data depending on the hardware state. In mainline this is done by commit d68778b8 ("rtc: initialize output parameter for read alarm to "uninitialized"") in the core. This is considered to dangerous for stable as it might have side effects for other rtc drivers that might for example rely on alarm->time.tm_sec being initialized to 0. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Uwe Kleine-König authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit f87e904d upstream. There are several issues fixed in this patch: - When alarm isn't enabled, set .enabled to zero instead of returning -EINVAL. - Ignore how IRQ1 is configured when determining if IRQ2 is on. - The three alarm registers have an enable flag which must be evaluated. - The chip always triggers when the seconds register gets 0. Note that the rtc framework however doesn't handle the result correctly because it doesn't check wday being initialized and so interprets an alarm being set for 10:00 AM in three days as 10:00 AM tomorrow (or today if that's not over yet). Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Felix Fietkau authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit 6c356eda upstream. With the IRQ stack changes integrated, the XRX200 devices started emitting a constant stream of kernel messages like this: [ 565.415310] Spurious IRQ: CAUSE=0x1100c300 This is caused by IP0 getting handled by plat_irq_dispatch() rather than its vectored interrupt handler, which is fixed by commit de856416e714 ("MIPS: IRQ Stack: Fix erroneous jal to plat_irq_dispatch"). Fix plat_irq_dispatch() to handle non-vectored IPI interrupts correctly by setting up IP2-6 as proper chained IRQ handlers and calling do_IRQ for all MIPS CPU interrupts. Signed-off-by: Felix Fietkau <nbd@nbd.name> Acked-by: John Crispin <john@phrozen.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/15077/ [james.hogan@imgtec.com: tweaked commit message] Signed-off-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Amit Pundir <amit.pundir@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Naoya Horiguchi authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit c9d398fa upstream. I found the race condition which triggers the following bug when move_pages() and soft offline are called on a single hugetlb page concurrently. Soft offlining page 0x119400 at 0x700000000000 BUG: unable to handle kernel paging request at ffffea0011943820 IP: follow_huge_pmd+0x143/0x190 PGD 7ffd2067 PUD 7ffd1067 PMD 0 [61163.582052] Oops: 0000 [#1] SMP Modules linked in: binfmt_misc ppdev virtio_balloon parport_pc pcspkr i2c_piix4 parport i2c_core acpi_cpufreq ip_tables xfs libcrc32c ata_generic pata_acpi virtio_blk 8139too crc32c_intel ata_piix serio_raw libata virtio_pci 8139cp virtio_ring virtio mii floppy dm_mirror dm_region_hash dm_log dm_mod [last unloaded: cap_check] CPU: 0 PID: 22573 Comm: iterate_numa_mo Tainted: P OE 4.11.0-rc2-mm1+ #2 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:follow_huge_pmd+0x143/0x190 RSP: 0018:ffffc90004bdbcd0 EFLAGS: 00010202 RAX: 0000000465003e80 RBX: ffffea0004e34d30 RCX: 00003ffffffff000 RDX: 0000000011943800 RSI: 0000000000080001 RDI: 0000000465003e80 RBP: ffffc90004bdbd18 R08: 0000000000000000 R09: ffff880138d34000 R10: ffffea0004650000 R11: 0000000000c363b0 R12: ffffea0011943800 R13: ffff8801b8d34000 R14: ffffea0000000000 R15: 000077ff80000000 FS: 00007fc977710740(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffea0011943820 CR3: 000000007a746000 CR4: 00000000001406f0 Call Trace: follow_page_mask+0x270/0x550 SYSC_move_pages+0x4ea/0x8f0 SyS_move_pages+0xe/0x10 do_syscall_64+0x67/0x180 entry_SYSCALL64_slow_path+0x25/0x25 RIP: 0033:0x7fc976e03949 RSP: 002b:00007ffe72221d88 EFLAGS: 00000246 ORIG_RAX: 0000000000000117 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc976e03949 RDX: 0000000000c22390 RSI: 0000000000001400 RDI: 0000000000005827 RBP: 00007ffe72221e00 R08: 0000000000c2c3a0 R09: 0000000000000004 R10: 0000000000c363b0 R11: 0000000000000246 R12: 0000000000400650 R13: 00007ffe72221ee0 R14: 0000000000000000 R15: 0000000000000000 Code: 81 e4 ff ff 1f 00 48 21 c2 49 c1 ec 0c 48 c1 ea 0c 4c 01 e2 49 bc 00 00 00 00 00 ea ff ff 48 c1 e2 06 49 01 d4 f6 45 bc 04 74 90 <49> 8b 7c 24 20 40 f6 c7 01 75 2b 4c 89 e7 8b 47 1c 85 c0 7e 2a RIP: follow_huge_pmd+0x143/0x190 RSP: ffffc90004bdbcd0 CR2: ffffea0011943820 ---[ end trace e4f81353a2d23232 ]--- Kernel panic - not syncing: Fatal exception Kernel Offset: disabled This bug is triggered when pmd_present() returns true for non-present hugetlb, so fixing the present check in follow_huge_pmd() prevents it. Using pmd_present() to determine present/non-present for hugetlb is not correct, because pmd_present() checks multiple bits (not only _PAGE_PRESENT) for historical reason and it can misjudge hugetlb state. Fixes: e66f17ff ("mm/hugetlb: take page table lock in follow_huge_pmd()") Link: http://lkml.kernel.org/r/1490149898-20231-1-git-send-email-n-horiguchi@ah.jp.nec.comSigned-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Hugh Dickins <hughd@google.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.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> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Michel Dänzer authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit ce4b4f22 upstream. We were accidentally only overriding the first VRAM placement. For BOs with the RADEON_GEM_NO_CPU_ACCESS flag set, radeon_ttm_placement_from_domain creates a second VRAM placment with fpfn == 0. If VRAM is almost full, the first VRAM placement with fpfn > 0 may not work, but the second one with fpfn == 0 always will (the BO's current location trivially satisfies it). Because "moving" the BO to its current location puts it back on the LRU list, this results in an infinite loop. Fixes: 2a85aedd ("drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first") Reported-by: Zachary Michaels <zmichaels@oblong.com> Reported-and-Tested-by: Julien Isorce <jisorce@oblong.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Peter Xu authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit df630b8c upstream. When releasing the bus, let's clear the bus pointers to mark it out. If any further device unregister happens on this bus, we know that we're done if we found the bus being released already. Signed-off-by: Peter Xu <peterx@redhat.com> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Alan Stern authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit 16336820 upstream. Using KASAN, Dmitry found a bug in the rh_call_control() routine: If buffer allocation fails, the routine returns immediately without unlinking its URB from the control endpoint, eventually leading to linked-list corruption. This patch fixes the problem by jumping to the end of the routine (where the URB is unlinked) when an allocation failure occurs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Nicolas Ferre authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit 497e1e16 upstream. A side effect of 89d82324 ("tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx") is that the console can be called with TX path disabled. Then the system would hang trying to push charecters out in atmel_console_putchar(). Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Fixes: 89d82324 ("tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Richard Genoud authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit 31ca2c63 upstream. If uart_flush_buffer() is called between atmel_tx_dma() and atmel_complete_tx_dma(), the circular buffer has been cleared, but not atmel_port->tx_len. That leads to a circular buffer overflow (dumping (UART_XMIT_SIZE - atmel_port->tx_len) bytes). Tested-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Joerg Roedel authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit 08f63d97 upstream. No platform-device is required for IO(x)APICs, so don't even create them. [ rjw: This fixes a problem with leaking platform device objects after IOAPIC/IOxAPIC hot-removal events.] Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Josh Poimboeuf authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit 61b79e16 upstream. Paul Menzel reported a warning: WARNING: CPU: 0 PID: 774 at /build/linux-ROBWaj/linux-4.9.13/kernel/trace/trace_functions_graph.c:233 ftrace_return_to_handler+0x1aa/0x1e0 Bad frame pointer: expected f6919d98, received f6919db0 from func acpi_pm_device_sleep_wake return to c43b6f9d The warning means that function graph tracing is broken for the acpi_pm_device_sleep_wake() function. That's because the ACPI Makefile unconditionally sets the '-Os' gcc flag to optimize for size. That's an issue because mcount-based function graph tracing is incompatible with '-Os' on x86, thanks to the following gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109 I have another patch pending which will ensure that mcount-based function graph tracing is never used with CONFIG_CC_OPTIMIZE_FOR_SIZE on x86. But this patch is needed in addition to that one because the ACPI Makefile overrides that config option for no apparent reason. It has had this flag since the beginning of git history, and there's no related comment, so I don't know why it's there. As far as I can tell, there's no reason for it to be there. The appropriate behavior is for it to honor CONFIG_CC_OPTIMIZE_FOR_{SIZE,PERFORMANCE} like the rest of the kernel. Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Songjun Wu authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit cd3ac9af upstream. Fix the audio clock rate according to the datasheet. Reported-by: Dushara Jayasinghe <dushara@successful.com.au> Signed-off-by: Songjun Wu <songjun.wu@microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Hui Wang authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit 2f726aec upstream. On this Dell AIO machine, the lineout jack does not work. We found the pin 0x1a is assigned to lineout on this machine, and in the past, we applied ALC298_FIXUP_DELL1_MIC_NO_PRESENCE to fix the heaset-set mic problem for this machine, this fixup will redefine the pin 0x1a to headphone-mic, as a result the lineout doesn't work anymore. After consulting with Dell, they told us this machine doesn't support microphone via headset jack, so we add a new fixup which only defines the pin 0x18 as the headset-mic. [rearranged the fixup insertion position by tiwai in order to make the merge with other branches easier -- tiwai] Fixes: 59ec4b57 ("ALSA: hda - Fix headset mic detection problem for two dell machines") Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit 2d7d5400 upstream. When a new event is queued while processing to resize the FIFO in snd_seq_fifo_clear(), it may lead to a use-after-free, as the old pool that is being queued gets removed. For avoiding this race, we need to close the pool to be deleted and sync its usage before actually deleting it. The issue was spotted by syzkaller. Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
John Garry authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit 9702c67c upstream. The total ata xfer length may not be calculated properly, in that we do not use the proper method to get an sg element dma length. According to the code comment, sg_dma_len() should be used after dma_map_sg() is called. This issue was found by turning on the SMMUv3 in front of the hisi_sas controller in hip07. Multiple sg elements were being combined into a single element, but the original first element length was being use as the total xfer length. Fixes: ff2aeb1e ("libata: convert to chained sg") Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
peter chang authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit bf33f87d upstream. The user can control the size of the next command passed along, but the value passed to the ioctl isn't checked against the usable max command size. Signed-off-by: Peter Chang <dpf@google.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
James Bottomley authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit ffb58456 upstream. mpt3sas has a firmware failure where it can only handle one pass through ATA command at a time. If another comes in, contrary to the SAT standard, it will hang until the first one completes (causing long commands like secure erase to timeout). The original fix was to block the device when an ATA command came in, but this caused a regression with commit 669f0441 Author: Bart Van Assche <bart.vanassche@sandisk.com> Date: Tue Nov 22 16:17:13 2016 -0800 scsi: srp_transport: Move queuecommand() wait code to SCSI core So fix the original fix of the secure erase timeout by properly returning SAM_STAT_BUSY like the SAT recommends. The original patch also had a concurrency problem since scsih_qcmd is lockless at that point (this is fixed by using atomic bitops to set and test the flag). [mkp: addressed feedback wrt. test_bit and fixed whitespace] Fixes: 18f6084a (mpt3sas: Fix secure erase premature termination) Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Acked-by: Sreekanth Reddy <Sreekanth.Reddy@broadcom.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reported-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Cc: Joe Korty <joe.korty@ccur.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Conflicts: drivers/scsi/mpt3sas/mpt3sas_base.h Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Ross Lagerwall authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit 7ecec850 upstream. When relocating the p2m, take special care not to relocate it so that is overlaps with the current location of the p2m/initrd. This is needed since the full extent of the current location is not marked as a reserved region in the e820. This was seen to happen to a dom0 with a large initial p2m and a small reserved region in the middle of the initial p2m. Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Ilya Dryomov authored
BugLink: http://bugs.launchpad.net/bugs/1681862 commit 633ee407 upstream. sock_alloc_inode() allocates socket+inode and socket_wq with GFP_KERNEL, which is not allowed on the writeback path: Workqueue: ceph-msgr con_work [libceph] ffff8810871cb018 0000000000000046 0000000000000000 ffff881085d40000 0000000000012b00 ffff881025cad428 ffff8810871cbfd8 0000000000012b00 ffff880102fc1000 ffff881085d40000 ffff8810871cb038 ffff8810871cb148 Call Trace: [<ffffffff816dd629>] schedule+0x29/0x70 [<ffffffff816e066d>] schedule_timeout+0x1bd/0x200 [<ffffffff81093ffc>] ? ttwu_do_wakeup+0x2c/0x120 [<ffffffff81094266>] ? ttwu_do_activate.constprop.135+0x66/0x70 [<ffffffff816deb5f>] wait_for_completion+0xbf/0x180 [<ffffffff81097cd0>] ? try_to_wake_up+0x390/0x390 [<ffffffff81086335>] flush_work+0x165/0x250 [<ffffffff81082940>] ? worker_detach_from_pool+0xd0/0xd0 [<ffffffffa03b65b1>] xlog_cil_force_lsn+0x81/0x200 [xfs] [<ffffffff816d6b42>] ? __slab_free+0xee/0x234 [<ffffffffa03b4b1d>] _xfs_log_force_lsn+0x4d/0x2c0 [xfs] [<ffffffff811adc1e>] ? lookup_page_cgroup_used+0xe/0x30 [<ffffffffa039a723>] ? xfs_reclaim_inode+0xa3/0x330 [xfs] [<ffffffffa03b4dcf>] xfs_log_force_lsn+0x3f/0xf0 [xfs] [<ffffffffa039a723>] ? xfs_reclaim_inode+0xa3/0x330 [xfs] [<ffffffffa03a62c6>] xfs_iunpin_wait+0xc6/0x1a0 [xfs] [<ffffffff810aa250>] ? wake_atomic_t_function+0x40/0x40 [<ffffffffa039a723>] xfs_reclaim_inode+0xa3/0x330 [xfs] [<ffffffffa039ac07>] xfs_reclaim_inodes_ag+0x257/0x3d0 [xfs] [<ffffffffa039bb13>] xfs_reclaim_inodes_nr+0x33/0x40 [xfs] [<ffffffffa03ab745>] xfs_fs_free_cached_objects+0x15/0x20 [xfs] [<ffffffff811c0c18>] super_cache_scan+0x178/0x180 [<ffffffff8115912e>] shrink_slab_node+0x14e/0x340 [<ffffffff811afc3b>] ? mem_cgroup_iter+0x16b/0x450 [<ffffffff8115af70>] shrink_slab+0x100/0x140 [<ffffffff8115e425>] do_try_to_free_pages+0x335/0x490 [<ffffffff8115e7f9>] try_to_free_pages+0xb9/0x1f0 [<ffffffff816d56e4>] ? __alloc_pages_direct_compact+0x69/0x1be [<ffffffff81150cba>] __alloc_pages_nodemask+0x69a/0xb40 [<ffffffff8119743e>] alloc_pages_current+0x9e/0x110 [<ffffffff811a0ac5>] new_slab+0x2c5/0x390 [<ffffffff816d71c4>] __slab_alloc+0x33b/0x459 [<ffffffff815b906d>] ? sock_alloc_inode+0x2d/0xd0 [<ffffffff8164bda1>] ? inet_sendmsg+0x71/0xc0 [<ffffffff815b906d>] ? sock_alloc_inode+0x2d/0xd0 [<ffffffff811a21f2>] kmem_cache_alloc+0x1a2/0x1b0 [<ffffffff815b906d>] sock_alloc_inode+0x2d/0xd0 [<ffffffff811d8566>] alloc_inode+0x26/0xa0 [<ffffffff811da04a>] new_inode_pseudo+0x1a/0x70 [<ffffffff815b933e>] sock_alloc+0x1e/0x80 [<ffffffff815ba855>] __sock_create+0x95/0x220 [<ffffffff815baa04>] sock_create_kern+0x24/0x30 [<ffffffffa04794d9>] con_work+0xef9/0x2050 [libceph] [<ffffffffa04aa9ec>] ? rbd_img_request_submit+0x4c/0x60 [rbd] [<ffffffff81084c19>] process_one_work+0x159/0x4f0 [<ffffffff8108561b>] worker_thread+0x11b/0x530 [<ffffffff81085500>] ? create_worker+0x1d0/0x1d0 [<ffffffff8108b6f9>] kthread+0xc9/0xe0 [<ffffffff8108b630>] ? flush_kthread_worker+0x90/0x90 [<ffffffff816e1b98>] ret_from_fork+0x58/0x90 [<ffffffff8108b630>] ? flush_kthread_worker+0x90/0x90 Use memalloc_noio_{save,restore}() to temporarily force GFP_NOIO here. Link: http://tracker.ceph.com/issues/19309Reported-by: Sergey Jerusalimov <wintchester@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Thadeu Lima de Souza Cascardo authored
Ignore: yes Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
- 26 Apr, 2017 4 commits
-
-
Kleber Sacilotto de Souza authored
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Kleber Sacilotto de Souza authored
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Haiyang Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1684971Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Brad Figg <brad.figg@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1669672Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Brad Figg <brad.figg@canonical.com> Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
- 25 Apr, 2017 5 commits
-
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1669672 This patch updates the kernel config for latest Redpine Wifi-BT combo chip driver ver. 1.2.RC4 Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1669672 Vendor release ver: 1.2.RC4 Changelog: 1.2.RC4 - WLAN Bug Fixes: --------------- 1) Buffer status interrupt handling improved. 2) Scan results update in sta+bt dual mode issue resolved WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. BT Limitations/Features NOT Supported: ---------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.2.RC3 - WLAN Bug Fixes: --------------- 1) WoWLAN multiple cycles issue resolved. 2) Driver Version is correctly updated. 3) Default operating mode for Caracalla board is corrected. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. BT New Features: ---------------- 1) Multiple slaves issue in WLAN-BT coex mode resolved. BT Limitations/Features NOT Supported: -------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.2.RC2 - WLAN Bug Fixes: --------------- 1) Suspend/resume issues resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. 3) EAP not tested BT Limitations/Features NOT Supported: -------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.2.RC1 - WLAN New Features: ------------------ 1) Restrict functional modes as per device operating mode 2) Default operating mode for Caracalla board is 13 WLAN Bug Fixes: --------------- 1) Driver oops issue if more than 4 clients try to connect in operating mode 14 resolved. 2) Issue with connecting more than max clients and disconnection issue resolved. 3) L2 test stop when wlan interface down issue resolved. 4) Driver version corrected. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. 3) EAP not tested 4) For channels 12 and 13 in US region max TX power is coming 0 in beacons. BT Limitations/Features NOT Supported: ---------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.1 - Generic ------- 1) Firmware file name is displayed along with version information. at the driver load time. 2) Device operating mode is made available in the below files: /sys/module/rsi_sdio/parameters/dev_oper_mode /sys/module/rsi_usb/parameters/dev_oper_mode 3) Wi-Fi BT radio sharing has been improved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. 3) EAP not tested 4) For channels 12 and 13 in US region max TX power is coming 0 in beacons. BT Limitations/Features NOT Supported: -------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.0.RC7 - Generic ------- 1) Driver version, Firmware version and operating mode information is displayed at the driver load time. 2) Driver version is made available in the below files: /sys/module/rsi_91x/version /sys/module/rsi_sdio/version /sys/module/rsi_usb/version WLAN Bug Fixes: --------------- 1) Power save latencies resolved WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. 3) EAP not tested BT Limitations/Features NOT Supported: -------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.0 - WLAN New Features: ------------------ 1) Station mode 2) All Security modes (WEP/WPA/WPA2) 3) Station Power save (legacy and UAPSD) 4) Bgscan and roaming 5) External antenna selection 6) Neighbour report request in RRM 7) Regulatory (802)11d) support 8) Management frame protection support (802)11w) 9) Software RF-kill 10) AP mode 11) S3, S4 suspend and resume 12) WoWLAN 13) AP Power save 14) Wi-Fi direct WLAN Bug Fixes: --------------- 1) Allowed channels 12 and 13 in FCC region. 2) For the allowed channels 12 and 13 in any region, power configuration updated as per Caracalla regulatory rules. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. 3) EAP not tested BT New Features: ---------------- 1) BT EDR mode 2) BT LE mode 3) BT coex mode (All the coex modes)) 4) Multi-slave mode supported) BT Limitations/Features NOT Supported: ---------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.0_RC3 - Gerenic: -------- 1) Device operating mode is changed as module parameter. Please check README or TRM on how to configure this while loading the modules. 2) Max number of stations supported in Wi-Fi AP alone mode is 32, and AP + BT coex mode is 4. 3) AP + BT-EDR + BLE support added. WLAN Bug Fixes: --------------- 1) Bgscan probe request issue resolved. 2) WoWLAN before association issue resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S4 with and without WoWLAN works with the work-around implemented by Canonical. 2) S5 with WoWLAN does not work. 3) For GTK rekey, wakeup trigger send to host. 4) EAP not tested 5) To connect multiple BT slaves, connection should be initiated from rsi module. 6) In coex mode, BT file transfer fails at times with certain mobiles. BT New Features: ---------------- 1) Multi-slave mode supported. BT Bug Fixes: ------------- 1) Radio sharing of coex modes improved. 1.0.RC2 - WLAN Bug Fixes: --------------- 1) PVB preparation issue in AP mode resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Issue while Resume in S4 with or without WoWLAN. 3) S5 with WoWLAN does not work. 4) For GTK rekey, wakeup trigger send to host. BT Bug Fixes: ------------- 1) BT dual mode disconnection issue resolved 2) AP BT dual mode issue resolved 1.0_RC1 - WLAN Bug Fixes: --------------- 1) WoWLAN in Co-ex mode issue resolved. 2) AP beacon DTIM count update issue resolved. 3) Firmware assertion (0x5d) in bgscan issue is resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Issue while Resume in S4 with or without WoWLAN. 3) S5 with WoWLAN does not work. 4) For GTK rekey, wakeup trigger send to host. 0.9.8.5_RC6 - WLAN Bug Fixes: --------------- 1) Firmware CRC check fail issue resolved 2) Compilation fails on 4.10.1 kernel issue resolved 3) BG scan issues resolved 4) AP mode regulatory fixes 5) WoWLAN issues resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Issue while Resume in S4 with or without WoWLAN. 3) S5 with WoWLAN does not work. 4) For GTK rekey, wakeup trigger send to host. 0.9.8.5_RC4 - WLAN Bug Fixes: ------------------- 1) AP mode configuration in channels 12 and 13 for EU region issue resolved. 2) Data latencies in AP mode issue resolved. 3) Roaming issues resolved. 4) AP WEP mode issue resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Issue while Resume in S4 with or without WoWLAN. 3) S5 with WoWLAN does not work. 4) For GTK rekey, wakeup trigger send to host. 5) WoWLAN does not work in WEP mode. Others: ------- 1) USB binds only to RS9113, let upstream kernel driver handle other RSI chips 0.9.8.5_RC3 - WLAN Bug Fixes: ------------------- 1) Power save issue in station mode (By default UAPSD is enabled on Caracalla board) fixed. 2) WoWLAN with S3 issue resolved WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Not verified removing SDIO interrupt polling 3) S4/S5 sleep states not supported (with and without WoWLAN) 0.9.8.5_RC2 - WLAN Bug Fixes: ------------------- 1) Power save issue in station mode (By default UAPSD is enabled on Caracalla board) fixed. 2) Firmware assert 0x71 (while doing bgscan) issue fixed. 3) Keep alive functionality in station mode issue fixed. 4) Data traffic stops when connected to multiple stations issue resolved 5) WoWLAN not working issue is resolved WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Not verified removing SDIO interrupt polling 3) S4/S5 sleep states not supported (with and without WoWLAN) 4) Wi-Fi direct testing is in progress 0.9.8.5_RC1 - WLAN Bug Fixes: ------------------- 1) Observed unicast probe requests during bgscan issue fixed 2) Firmware assert 0x71 (while doing bgscan) issue fixed. 3) Crash when doing rmmod while data traffic is going on issue resolved. 4) Beacons stopped after 5 minutes of data traffic issue fixed. 5) Keep alive functionality in station mode issue fixed 6) 11n data rates issue in station mode resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Not verified removing SDIO interrupt polling 3) S4/S5 sleep states not supported (with.without WoWLAN) 4) power save is not working consistently 5) WoWLAN is not working consistently 0.9.8.3 - WLAN New Features: ----------------------------------------- 1) AP Mode 2) S3, S4 suspend and resume 3) WoWLAN [Testing in progress] WLAN Bug Fixes: ------------------- 1) First EAPOL drop issue is resolved 2) Firmware Assert while roaming issue is resolved (Provide driver bgsan should be enabled along with supplicant bgscan) 3) Roaming takes longer time issue is resolved 4) Added polling support as a work-around for the SDIO interrupt issue on some platforms WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) Wi-Fi Direct mode not supported 2) EAP not supported 3) SDIO interrupts are not being delivered to the 9113 driver 4) In S4 state 9113 device gets reset but device isn't getting re-enumerated. Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1669672 This patch adds a guard against changes in commit 2171e55 being applied to the complete SDHCI sub-system. PCI Subsystem ID 1028:07b9 is used to uniquely identify Dell IoT gateway. Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1685133 This patch adds the vendor release version on the Exar USB serial device. Features include: 1. Fix for RX fail after wake-up from sleep (S3/S4) 2. Removes unnecessary debug messages Changelog: Version 1B, 11/6/2015 Fixed Bug: The conditional logic to support kernel 3.9 was incorrect(line 396 in xr_usb_serial_common.c). Version 1A, 1/9/2015 This driver will work with any USB UART function in these Exar devices: XR21V1410/1412/1414 XR21B1411 XR21B1420/1422/1424 XR22801/802/804 Exar serial devices are typically enuremated as /dev/ttyXRUSB[0-3]. Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Kleber Sacilotto de Souza authored
Ignore: yes Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
- 20 Apr, 2017 2 commits
-
-
Stefan Bader authored
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1682561 Waiting for release_event in all three drivers introduced issues on release as on_reset() hook is not always called. E.g. if the device was never opened we will never get the completion. Move the waiting code to hvutil_transport_destroy() and make sure it is only called when the device is open. hvt->lock serialization should guarantee the absence of races. Fixes: 5a66fecb ("Drivers: hv: util: kvp: Fix a rescind processing issue") Fixes: 20951c75 ("Drivers: hv: util: Fcopy: Fix a rescind processing issue") Fixes: d77044d1 ("Drivers: hv: util: Backup: Fix a rescind processing issue") Reported-by: Dexuan Cui <decui@microsoft.com> Tested-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit e9c18ae6) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Brad Figg <brad.figg@canonical.com> Acked-by: Colin King <colin.king@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
- 19 Apr, 2017 1 commit
-
-
Stefan Bader authored
Ignore: yes Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
- 12 Apr, 2017 3 commits
-
-
Stefan Bader authored
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1681893 DoS protection conditions were altered in WS2016 and now it's easy to get -EAGAIN returned from vmbus_post_msg() (e.g. when we try changing MTU on a netvsc device in a loop). All vmbus_post_msg() callers don't retry the operation and we usually end up with a non-functional device or crash. While host's DoS protection conditions are unknown to me my tests show that it can take up to 10 seconds before the message is sent so doing udelay() is not an option, we really need to sleep. Almost all vmbus_post_msg() callers are ready to sleep but there is one special case: vmbus_initiate_unload() which can be called from interrupt/NMI context and we can't sleep there. I'm also not sure about the lonely vmbus_send_tl_connect_request() which has no in-tree users but its external users are most likely waiting for the host to reply so sleeping there is also appropriate. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit c0bb0392) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Brad Figg <brad.figg@canonical.com> Acked-by: Marcelo Cerri <marcelo.cerri@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
Stefan Bader authored
Ignore: yes Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
-
- 06 Apr, 2017 3 commits
-
-
Thadeu Lima de Souza Cascardo authored
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Marcelo Ricardo Leitner authored
commit 2dcab598 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf") attempted to avoid a BUG_ON call when the association being used for a sendmsg() is blocked waiting for more sndbuf and another thread did a peeloff operation on such asoc, moving it to another socket. As Ben Hutchings noticed, then in such case it would return without locking back the socket and would cause two unlocks in a row. Further analysis also revealed that it could allow a double free if the application managed to peeloff the asoc that is created during the sendmsg call, because then sctp_sendmsg() would try to free the asoc that was created only for that call. This patch takes another approach. It will deny the peeloff operation if there is a thread sleeping on the asoc, so this situation doesn't exist anymore. This avoids the issues described above and also honors the syscalls that are already being handled (it can be multiple sendmsg calls). Joint work with Xin Long. Fixes: 2dcab598 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf") Cc: Alexander Popov <alex.popov@linux.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit dfcb9f4f) CVE-2017-6353 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
-
Paolo Pisati authored
BugLink: http://bugs.launchpad.net/bugs/1677230Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-