Skip to content

L
linux
Switch branch/tag
  1. 29 Jan, 2015 35 commits
  3. 28 Jan, 2015 5 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7