1. 28 Jan, 2015 13 commits
    • Trond Myklebust's avatar
      NFSv4.1: Fix client id trunking on Linux · d4317010
      Trond Myklebust authored
      commit 1fc0703a upstream.
      
      Currently, our trunking code will check for session trunking, but will
      fail to detect client id trunking. This is a problem, because it means
      that the client will fail to recognise that the two connections represent
      shared state, even if they do not permit a shared session.
      By removing the check for the server minor id, and only checking the
      major id, we will end up doing the right thing in both cases: we close
      down the new nfs_client and fall back to using the existing one.
      
      Fixes: 05f4c350 ("NFS: Discover NFSv4 server trunking when mounting")
      Cc: Chuck Lever <chuck.lever@oracle.com>
      Tested-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d4317010
    • Steven Rostedt (Red Hat)'s avatar
      ftrace/jprobes/x86: Fix conflict between jprobes and function graph tracing · 98621891
      Steven Rostedt (Red Hat) authored
      commit 237d28db upstream.
      
      If the function graph tracer traces a jprobe callback, the system will
      crash. This can easily be demonstrated by compiling the jprobe
      sample module that is in the kernel tree, loading it and running the
      function graph tracer.
      
       # modprobe jprobe_example.ko
       # echo function_graph > /sys/kernel/debug/tracing/current_tracer
       # ls
      
      The first two commands end up in a nice crash after the first fork.
      (do_fork has a jprobe attached to it, so "ls" just triggers that fork)
      
      The problem is caused by the jprobe_return() that all jprobe callbacks
      must end with. The way jprobes works is that the function a jprobe
      is attached to has a breakpoint placed at the start of it (or it uses
      ftrace if fentry is supported). The breakpoint handler (or ftrace callback)
      will copy the stack frame and change the ip address to return to the
      jprobe handler instead of the function. The jprobe handler must end
      with jprobe_return() which swaps the stack and does an int3 (breakpoint).
      This breakpoint handler will then put back the saved stack frame,
      simulate the instruction at the beginning of the function it added
      a breakpoint to, and then continue on.
      
      For function tracing to work, it hijakes the return address from the
      stack frame, and replaces it with a hook function that will trace
      the end of the call. This hook function will restore the return
      address of the function call.
      
      If the function tracer traces the jprobe handler, the hook function
      for that handler will not be called, and its saved return address
      will be used for the next function. This will result in a kernel crash.
      
      To solve this, pause function tracing before the jprobe handler is called
      and unpause it before it returns back to the function it probed.
      
      Some other updates:
      
      Used a variable "saved_sp" to hold kcb->jprobe_saved_sp. This makes the
      code look a bit cleaner and easier to understand (various tries to fix
      this bug required this change).
      
      Note, if fentry is being used, jprobes will change the ip address before
      the function graph tracer runs and it will not be able to trace the
      function that the jprobe is probing.
      
      Link: http://lkml.kernel.org/r/20150114154329.552437962@goodmis.orgAcked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      98621891
    • Mugunthan V N's avatar
      drivers: net: cpsw: fix multicast flush in dual emac mode · 487873cf
      Mugunthan V N authored
      commit 25906052 upstream.
      
      Since ALE table is a common resource for both the interfaces in Dual EMAC
      mode and while bringing up the second interface in cpsw_ndo_set_rx_mode()
      all the multicast entries added by the first interface is flushed out and
      only second interface multicast addresses are added. Fixing this by
      flushing multicast addresses based on dual EMAC port vlans which will not
      affect the other emac port multicast addresses.
      
      Fixes: d9ba8f9e (driver: net: ethernet: cpsw: dual emac interface implementation)
      Signed-off-by: default avatarMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      487873cf
    • Wei Yang's avatar
      vfio-pci: Fix the check on pci device type in vfio_pci_probe() · da5c0ae9
      Wei Yang authored
      commit 7c2e211f upstream.
      
      Current vfio-pci just supports normal pci device, so vfio_pci_probe() will
      return if the pci device is not a normal device. While current code makes a
      mistake. PCI_HEADER_TYPE is the offset in configuration space of the device
      type, but we use this value to mask the type value.
      
      This patch fixs this by do the check directly on the pci_dev->hdr_type.
      Signed-off-by: default avatarWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      da5c0ae9
    • Takashi Iwai's avatar
      uvcvideo: Fix destruction order in uvc_delete() · 5a075f4a
      Takashi Iwai authored
      commit 2228d80d upstream.
      
      We've got a bug report at disconnecting a Webcam, where the kernel
      spews warnings like below:
        WARNING: CPU: 0 PID: 8385 at ../fs/sysfs/group.c:219 sysfs_remove_group+0x87/0x90()
        sysfs group c0b2350c not found for kobject 'event3'
        CPU: 0 PID: 8385 Comm: queue2:src Not tainted 3.16.2-1.gdcee397-default #1
        Hardware name: ASUSTeK Computer INC. A7N8X-E/A7N8X-E, BIOS ASUS A7N8X-E Deluxe ACPI BIOS Rev 1013  11/12/2004
          c08d0705 ddc75cbc c0718c5b ddc75ccc c024b654 c08c6d44 ddc75ce8 000020c1
          c08d0705 000000db c03d1ec7 c03d1ec7 00000009 00000000 c0b2350c d62c9064
          ddc75cd4 c024b6a3 00000009 ddc75ccc c08c6d44 ddc75ce8 ddc75cfc c03d1ec7
        Call Trace:
          [<c0205ba6>] try_stack_unwind+0x156/0x170
          [<c02046f3>] dump_trace+0x53/0x180
          [<c0205c06>] show_trace_log_lvl+0x46/0x50
          [<c0204871>] show_stack_log_lvl+0x51/0xe0
          [<c0205c67>] show_stack+0x27/0x50
          [<c0718c5b>] dump_stack+0x3e/0x4e
          [<c024b654>] warn_slowpath_common+0x84/0xa0
          [<c024b6a3>] warn_slowpath_fmt+0x33/0x40
          [<c03d1ec7>] sysfs_remove_group+0x87/0x90
          [<c05a2c54>] device_del+0x34/0x180
          [<c05e3989>] evdev_disconnect+0x19/0x50
          [<c05e06fa>] __input_unregister_device+0x9a/0x140
          [<c05e0845>] input_unregister_device+0x45/0x80
          [<f854b1d6>] uvc_delete+0x26/0x110 [uvcvideo]
          [<f84d66f8>] v4l2_device_release+0x98/0xc0 [videodev]
          [<c05a25bb>] device_release+0x2b/0x90
          [<c04ad8bf>] kobject_cleanup+0x6f/0x1a0
          [<f84d5453>] v4l2_release+0x43/0x70 [videodev]
          [<c0372f31>] __fput+0xb1/0x1b0
          [<c02650c1>] task_work_run+0x91/0xb0
          [<c024d845>] do_exit+0x265/0x910
          [<c024df64>] do_group_exit+0x34/0xa0
          [<c025a76f>] get_signal_to_deliver+0x17f/0x590
          [<c0201b6a>] do_signal+0x3a/0x960
          [<c02024f7>] do_notify_resume+0x67/0x90
          [<c071ebb5>] work_notifysig+0x30/0x3b
          [<b7739e60>] 0xb7739e5f
         ---[ end trace b1e56095a485b631 ]---
      
      The cause is that uvc_status_cleanup() is called after usb_put_*() in
      uvc_delete().  usb_put_*() removes the sysfs parent and eventually
      removes the children recursively, so the later device_del() can't find
      its sysfs.  The fix is simply rearrange the call orders in
      uvc_delete() so that the child is removed before the parent.
      
      Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=897736Reported-and-tested-by: default avatarMartin Pluskal <mpluskal@suse.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      5a075f4a
    • Mauro Carvalho Chehab's avatar
      sound: Update au0828 quirks table · b6f8e9ab
      Mauro Carvalho Chehab authored
      commit 678fa12f upstream.
      
      The au0828 quirks table is currently not in sync with the au0828
      media driver.
      
      Syncronize it and put them on the same order as found at au0828
      driver, as all the au0828 devices with analog TV need the
      same quirks.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b6f8e9ab
    • Mauro Carvalho Chehab's avatar
      sound: simplify au0828 quirk table · a4687a6d
      Mauro Carvalho Chehab authored
      commit 5d1f00a2 upstream.
      
      Add a macro to simplify au0828 quirk table. That makes easier
      to check it against the USB IDs at drivers/media/usb/au0828/au0828-cards.c.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      a4687a6d
    • Sakari Ailus's avatar
      smiapp: Take mutex during PLL update in sensor initialisation · 6b77d12b
      Sakari Ailus authored
      commit f85698cd upstream.
      
      The mutex does not serialise anything in this case but avoids a lockdep
      warning from the control framework.
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Acked-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      6b77d12b
    • Frank Schaefer's avatar
      af9005: fix kernel panic on init if compiled without IR · ed1b779d
      Frank Schaefer authored
      commit 22799487 upstream.
      
      This patches fixes an ancient bug in the dvb_usb_af9005 driver, which
      has been reported at least in the following threads:
      https://lkml.org/lkml/2009/2/4/350
      https://lkml.org/lkml/2014/9/18/558
      
      If the driver is compiled in without any IR support (neither
      DVB_USB_AF9005_REMOTE nor custom symbols), the symbol_request calls in
      af9005_usb_module_init() return pointers != NULL although the IR
      symbols are not available.
      
      This leads to the following oops:
      ...
      [    8.529751] usbcore: registered new interface driver dvb_usb_af9005
      [    8.531584] BUG: unable to handle kernel paging request at 02e00000
      [    8.533385] IP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d
      [    8.535613] *pde = 00000000
      [    8.536416] Oops: 0000 [#1] PREEMPT PREEMPT DEBUG_PAGEALLOCDEBUG_PAGEALLOC
      [    8.537863] CPU: 0 PID: 1 Comm: swapper Not tainted 3.15.0-rc6-00151-ga5c075cf #1
      [    8.539827] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
      [    8.541519] task: 89c9a670 ti: 89c9c000 task.ti: 89c9c000
      [    8.541519] EIP: 0060:[<7d9d67c6>] EFLAGS: 00010206 CPU: 0
      [    8.541519] EIP is at af9005_usb_module_init+0x6b/0x9d
      [    8.541519] EAX: 02e00000 EBX: 00000000 ECX: 00000006 EDX: 00000000
      [    8.541519] ESI: 00000000 EDI: 7da33ec8 EBP: 89c9df30 ESP: 89c9df2c
      [    8.541519]  DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068
      [    8.541519] CR0: 8005003b CR2: 02e00000 CR3: 05a54000 CR4: 00000690
      [    8.541519] Stack:
      [    8.541519]  7d9d675b 89c9df90 7d992a49 7d7d5914 89c9df4c 7be3a800 7d08c58c 8a4c3968
      [    8.541519]  89c9df80 7be3a966 00000192 00000006 00000006 7d7d3ff4 8a4c397a 00000200
      [    8.541519]  7d6b1280 8a4c3979 00000006 000009a6 7da32db8 b13eec81 00000006 000009a6
      [    8.541519] Call Trace:
      [    8.541519]  [<7d9d675b>] ? ttusb2_driver_init+0x16/0x16
      [    8.541519]  [<7d992a49>] do_one_initcall+0x77/0x106
      [    8.541519]  [<7be3a800>] ? parameqn+0x2/0x35
      [    8.541519]  [<7be3a966>] ? parse_args+0x113/0x25c
      [    8.541519]  [<7d992bc2>] kernel_init_freeable+0xea/0x167
      [    8.541519]  [<7cf01070>] kernel_init+0x8/0xb8
      [    8.541519]  [<7cf27ec0>] ret_from_kernel_thread+0x20/0x30
      [    8.541519]  [<7cf01068>] ? rest_init+0x10c/0x10c
      [    8.541519] Code: 08 c2 c7 05 44 ed f9 7d 00 00 e0 02 c7 05 40 ed f9 7d 00 00 e0 02 c7 05 3c ed f9 7d 00 00 e0 02 75 1f b8 00 00 e0 02 85 c0 74 16 <a1> 00 00 e0 02 c7 05 54 84 8e 7d 00 00 e0 02 a3 58 84 8e 7d eb
      [    8.541519] EIP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d SS:ESP 0068:89c9df2c
      [    8.541519] CR2: 0000000002e00000
      [    8.541519] ---[ end trace 768b6faf51370fc7 ]---
      
      The prefered fix would be to convert the whole IR code to use the kernel IR
      infrastructure (which wasn't available at the time this driver had been created).
      
      Until anyone who still has this old hardware steps up an does the conversion,
      fix it by not calling the symbol_request calls if the driver is compiled in
      without the default IR symbols (CONFIG_DVB_USB_AF9005_REMOTE).
      Due to the IR related pointers beeing NULL by default, IR support will then be disabled.
      
      The downside of this solution is, that it will no longer be possible to
      compile custom IR symbols (not using CONFIG_DVB_USB_AF9005_REMOTE) in.
      
      Please note that this patch has NOT been tested with all possible cases.
      I don't have the hardware and could only verify that it fixes the reported
      bug.
      Reported-by: default avatarFengguag Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarFrank Schäfer <fschaefer.oss@googlemail.com>
      Acked-by: default avatarLuca Olivetti <luca@ventoso.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ed1b779d
    • Sakari Ailus's avatar
      smiapp-pll: Correct clock debug prints · 01e5703e
      Sakari Ailus authored
      commit bc47150a upstream.
      
      The PLL flags were not used correctly.
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Acked-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      01e5703e
    • Tomi Valkeinen's avatar
      video/logo: prevent use of logos after they have been freed · 8871196b
      Tomi Valkeinen authored
      commit 92b004d1 upstream.
      
      If the probe of an fb driver has been deferred due to missing
      dependencies, and the probe is later ran when a module is loaded, the
      fbdev framework will try to find a logo to use.
      
      However, the logos are __initdata, and have already been freed. This
      causes sometimes page faults, if the logo memory is not mapped,
      sometimes other random crashes as the logo data is invalid, and
      sometimes nothing, if the fbdev decides to reject the logo (e.g. the
      random value depicting the logo's height is too big).
      
      This patch adds a late_initcall function to mark the logos as freed. In
      reality the logos are freed later, and fbdev probe may be ran between
      this late_initcall and the freeing of the logos. In that case we will
      miss drawing the logo, even if it would be possible.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      8871196b
    • Felipe Balbi's avatar
      net: ethernet: cpsw: fix hangs with interrupts · 8e2aaf56
      Felipe Balbi authored
      commit 7ce67a38 upstream.
      
      The CPSW IP implements pulse-signaled interrupts. Due to
      that we must write a correct, pre-defined value to the
      CPDMA_MACEOIVECTOR register so the controller generates
      a pulse on the correct IRQ line to signal the End Of
      Interrupt.
      
      The way the driver is written today, all four IRQ lines
      are requested using the same IRQ handler and, because of
      that, we could fall into situations where a TX IRQ fires
      but we tell the controller that we ended an RX IRQ (or
      vice-versa). This situation triggers an IRQ storm on the
      reserved IRQ 127 of INTC which will in turn call ack_bad_irq()
      which will, then, print a ton of:
      
      	unexpected IRQ trap at vector 00
      
      In order to fix the problem, we are moving all calls to
      cpdma_ctlr_eoi() inside the IRQ handler and making sure
      we *always* write the correct value to the CPDMA_MACEOIVECTOR
      register. Note that the algorithm assumes that IRQ numbers and
      value-to-be-written-to-EOI are proportional, meaning that a
      write of value 0 would trigger an EOI pulse for the RX_THRESHOLD
      Interrupt and that's the IRQ number sitting in the 0-th index
      of our irqs_table array.
      
      This, however, is safe at least for current implementations of
      CPSW so we will refrain from making the check smarter (and, as
      a side-effect, slower) until we actually have a platform where
      IRQ lines are swapped.
      
      This patch has been tested for several days with AM335x- and
      AM437x-based platforms. AM57x was left out because there are
      still pending patches to enable ethernet in mainline for that
      platform. A read of the TRM confirms the statement on previous
      paragraph.
      Reported-by: default avatarYegor Yefremov <yegorslists@googlemail.com>
      Fixes: 510a1e7 (drivers: net: davinci_cpdma: acknowledge interrupt properly)
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      8e2aaf56
    • Long Li's avatar
      storvsc: ring buffer failures may result in I/O freeze · 2d4e63b5
      Long Li authored
      commit e86fb5e8 upstream.
      
      When ring buffer returns an error indicating retry, storvsc may not
      return a proper error code to SCSI when bounce buffer is not used.
      This has introduced I/O freeze on RAID running atop storvsc devices.
      This patch fixes it by always returning a proper error code.
      Signed-off-by: default avatarLong Li <longli@microsoft.com>
      Reviewed-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2d4e63b5
  2. 27 Jan, 2015 2 commits
  3. 26 Jan, 2015 25 commits