1. 29 Jan, 2015 36 commits
  2. 28 Jan, 2015 4 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