1. 25 9月, 2015 14 次提交
    • N
      target: Propigate backend read-only to core_tpg_add_lun · eeeb9522
      Nicholas Bellinger 提交于
      This patch adds a DF_READ_ONLY flag that is used by IBLOCK to
      signal when a backend has been set to read-only mode, in order
      to propigate read-only status up to core_tpg_add_lun() for all
      future LUN fabric exports.
      
      With this is place, existing emulation for reporting read-only
      in spc_emulate_modesense() and normal transport_lookup_cmd_lun()
      TCM_WRITE_PROTECTED status checking just works as expected.
      Reported-by: NJoeue Deng <joeue404@gmail.com>
      Reported-by: NAndy Grover <agrover@redhat.com>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      eeeb9522
    • R
      phy: add phy_device_remove() · 38737e49
      Russell King 提交于
      Add a phy_device_remove() function to complement phy_device_register(),
      which undoes the effects of phy_device_register() by removing the phy
      device from visibility, but not freeing it.
      
      This allows these details to be moved out of the mdio bus code into
      the phy code where this action belongs.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      38737e49
    • R
      phy: fix mdiobus module safety · 3e3aaf64
      Russell King 提交于
      Re-implement the mdiobus module refcounting to ensure that we actually
      ensure that the mdiobus module code does not go away while we might call
      into it.
      
      The old scheme using bus->dev.driver was buggy, because bus->dev is a
      class device which never has a struct device_driver associated with it,
      and hence the associated code trying to obtain a refcount did nothing
      useful.
      
      Instead, take the approach that other subsystems do: pass the module
      when calling mdiobus_register(), and record that in the mii_bus struct.
      When we need to increment the module use count in the phy code, use
      this stored pointer.  When the phy is deteched, drop the module
      refcount, remembering that the phy device might go away at that point.
      
      This doesn't stop the mii_bus going away while there are in-use phys -
      it merely stops the underlying code vanishing.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e3aaf64
    • J
      lwtunnel: remove source and destination UDP port config option · b194f30c
      Jiri Benc 提交于
      The UDP tunnel config is asymmetric wrt. to the ports used. The source and
      destination ports from one direction of the tunnel are not related to the
      ports of the other direction. We need to be able to respond to ARP requests
      using the correct ports without involving routing.
      
      As the consequence, UDP ports need to be fixed property of the tunnel
      interface and cannot be set per route. Remove the ability to set ports per
      route. This is still okay to do, as no kernel has been released with these
      attributes yet.
      
      Note that the ability to specify source and destination ports is preserved
      for other users of the lwtunnel API which don't use routes for tunnel key
      specification (like openvswitch).
      
      If in the future we rework ARP handling to allow port specification, the
      attributes can be added back.
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Acked-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b194f30c
    • J
      ipv4: send arp replies to the correct tunnel · 63d008a4
      Jiri Benc 提交于
      When using ip lwtunnels, the additional data for xmit (basically, the actual
      tunnel to use) are carried in ip_tunnel_info either in dst->lwtstate or in
      metadata dst. When replying to ARP requests, we need to send the reply to
      the same tunnel the request came from. This means we need to construct
      proper metadata dst for ARP replies.
      
      We could perform another route lookup to get a dst entry with the correct
      lwtstate. However, this won't always ensure that the outgoing tunnel is the
      same as the incoming one, and it won't work anyway for IPv4 duplicate
      address detection.
      
      The only thing to do is to "reverse" the ip_tunnel_info.
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Acked-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      63d008a4
    • P
      skbuff: Fix skb checksum flag on skb pull · 6ae459bd
      Pravin B Shelar 提交于
      VXLAN device can receive skb with checksum partial. But the checksum
      offset could be in outer header which is pulled on receive. This results
      in negative checksum offset for the skb. Such skb can cause the assert
      failure in skb_checksum_help(). Following patch fixes the bug by setting
      checksum-none while pulling outer header.
      
      Following is the kernel panic msg from old kernel hitting the bug.
      
      ------------[ cut here ]------------
      kernel BUG at net/core/dev.c:1906!
      RIP: 0010:[<ffffffff81518034>] skb_checksum_help+0x144/0x150
      Call Trace:
      <IRQ>
      [<ffffffffa0164c28>] queue_userspace_packet+0x408/0x470 [openvswitch]
      [<ffffffffa016614d>] ovs_dp_upcall+0x5d/0x60 [openvswitch]
      [<ffffffffa0166236>] ovs_dp_process_packet_with_key+0xe6/0x100 [openvswitch]
      [<ffffffffa016629b>] ovs_dp_process_received_packet+0x4b/0x80 [openvswitch]
      [<ffffffffa016c51a>] ovs_vport_receive+0x2a/0x30 [openvswitch]
      [<ffffffffa0171383>] vxlan_rcv+0x53/0x60 [openvswitch]
      [<ffffffffa01734cb>] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch]
      [<ffffffff8157addc>] udp_queue_rcv_skb+0x2dc/0x3b0
      [<ffffffff8157b56f>] __udp4_lib_rcv+0x1cf/0x6c0
      [<ffffffff8157ba7a>] udp_rcv+0x1a/0x20
      [<ffffffff8154fdbd>] ip_local_deliver_finish+0xdd/0x280
      [<ffffffff81550128>] ip_local_deliver+0x88/0x90
      [<ffffffff8154fa7d>] ip_rcv_finish+0x10d/0x370
      [<ffffffff81550365>] ip_rcv+0x235/0x300
      [<ffffffff8151ba1d>] __netif_receive_skb+0x55d/0x620
      [<ffffffff8151c360>] netif_receive_skb+0x80/0x90
      [<ffffffff81459935>] virtnet_poll+0x555/0x6f0
      [<ffffffff8151cd04>] net_rx_action+0x134/0x290
      [<ffffffff810683d8>] __do_softirq+0xa8/0x210
      [<ffffffff8162fe6c>] call_softirq+0x1c/0x30
      [<ffffffff810161a5>] do_softirq+0x65/0xa0
      [<ffffffff810687be>] irq_exit+0x8e/0xb0
      [<ffffffff81630733>] do_IRQ+0x63/0xe0
      [<ffffffff81625f2e>] common_interrupt+0x6e/0x6e
      Reported-by: NAnupam Chanda <achanda@vmware.com>
      Signed-off-by: NPravin B Shelar <pshelar@nicira.com>
      Acked-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ae459bd
    • T
      cgroup, writeback: don't enable cgroup writeback on traditional hierarchies · 9badce00
      Tejun Heo 提交于
      inode_cgwb_enabled() gates cgroup writeback support.  If it returns
      true, each inode is attached to the corresponding memory domain which
      gets mapped to io domain.  It currently only tests whether the
      filesystem and bdi support cgroup writeback; however, cgroup writeback
      support doesn't work on traditional hierarchies and thus it should
      also test whether memcg and iocg are on the default hierarchy.
      
      This caused traditional hierarchy setups to hit the cgroup writeback
      path inadvertently and ended up creating separate writeback domains
      for each memcg and mapping them all to the root iocg uncovering a
      couple issues in the cgroup writeback path.
      
      cgroup writeback was never meant to be enabled on traditional
      hierarchies.  Make inode_cgwb_enabled() test whether both memcg and
      iocg are on the default hierarchy.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NArtem Bityutskiy <dedekind1@gmail.com>
      Reported-by: NDexuan Cui <decui@microsoft.com>
      Link: http://lkml.kernel.org/g/1443012552.19983.209.camel@gmail.com
      Link: http://lkml.kernel.org/g/f30d4a6aa8a546ff88f73021d026a453@SIXPR30MB031.064d.mgd.msft.net
      9badce00
    • T
      drm/irq: Add drm_crtc_vblank_count_and_time() · cf648305
      Thierry Reding 提交于
      This function is the KMS native variant of drm_vblank_count_and_time().
      It takes a struct drm_crtc * instead of a struct drm_device * and an
      index of the CRTC.
      
      Eventually the goal is to access vblank data through the CRTC only so
      that the per-CRTC data can be moved to struct drm_crtc.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      cf648305
    • L
      vga_switcheroo: Set active attribute to false for audio clients · 21b45676
      Lukas Wunner 提交于
      The active attribute in struct vga_switcheroo_client denotes whether
      the outputs are currently switched to this client. The attribute is
      only meaningful for vga clients. It is never used for audio clients.
      
      The function vga_switcheroo_register_audio_client() misuses this
      attribute to store whether the audio device is fully initialized.
      Most likely there was a misunderstanding about the meaning of
      "active" when this was added.
      
      Comment from Takashi's review:
      
      "Not really.  The full initialization of audio was meant that the audio
      is active indeed.  Admittedly, though, the active flag for each audio
      client doesn't play any role because the audio always follows the gfx
      state changes, and the value passed there doesn't reflect the actual
      state due to the later change.  So, I agree with the removal of the
      flag itself -- or let the audio active flag following the
      corresponding gfx flag.  The latter will make the proc output more
      consistent while the former is certainly more reduction of code."
      
      Set the active attribute to false for audio clients. Remove the
      active parameter from vga_switcheroo_register_audio_client() and
      its sole caller, hda_intel.c:register_vga_switcheroo().
      
      vga_switcheroo_register_audio_client() was introduced by 3e9e63db
      ("vga_switcheroo: Add the support for audio clients"). Its use in
      hda_intel.c was introduced by a82d51ed ("ALSA: hda - Support
      VGA-switcheroo").
      
      v1.1: The changes above imply that in find_active_client() the call
      to client_is_vga() is now superfluous. Drop it.
      
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      [danvet: Add Takashi's clarification to the commit message.]
      Reviewed-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      21b45676
    • V
      drm: Kill pixeldur_ns · 20b20203
      Ville Syrjälä 提交于
      pixeldur_ns is now unsued, so kill it from drm_vblank_crtc. framedur_ns
      is also currently unused but we will have use for it in the near future
      so leave it be. linedur_ns is still used by nouveau for some internal
      delays.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      20b20203
    • V
      drm: Stop using linedur_ns and pixeldur_ns for vblank timestamps · 3bb403bf
      Ville Syrjälä 提交于
      linedur_ns, and especially pixeldur_ns are becoming rather inaccurate
      to be used for the vblank timestamp correction. With 4k@60 the pixel
      duration is already below 2ns, so the amount of error due to the
      truncation to nanoseconds is introducing quite a bit of error.
      
      We can avoid such problems if we instead calculate the timestamp
      delta_ns directly from the dislay timings, avoiding the use of
      these intermediate truncated values.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      [danvet: Squash in fixup from Thierry Reding for amdgpu.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3bb403bf
    • V
      drm: Move timestamping constants into drm_vblank_crtc · eba1f35d
      Ville Syrjälä 提交于
      Collect the timestamping constants alongside the rest of the relevant
      stuff under drm_vblank_crtc.
      
      We can now get rid of the 'refcrtc' parameter to
      drm_calc_vbltimestamp_from_scanoutpos().
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      eba1f35d
    • G
      drm: fix kernel-doc warnings in drm_crtc.h · 5e7d4944
      Geliang Tang 提交于
      Fix the following 'make htmldocs' warning:
      
        .//include/drm/drm_crtc.h:929: warning: Excess struct/union/enum/typedef member 'base' description in 'drm_bridge'
      Signed-off-by: NGeliang Tang <geliangtang@163.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5e7d4944
    • L
      drm: Spell vga_switcheroo consistently · f15a66e6
      Lukas Wunner 提交于
      Currently everyone and their dog has their own favourite spelling
      for vga_switcheroo. This makes it hard to grep dmesg for log entries
      relating to vga_switcheroo. It also makes it hard to find related
      source files in the tree.
      
      vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f15a66e6
  2. 24 9月, 2015 1 次提交
    • N
      netpoll: Close race condition between poll_one_napi and napi_disable · 2d8bff12
      Neil Horman 提交于
      Drivers might call napi_disable while not holding the napi instance poll_lock.
      In those instances, its possible for a race condition to exist between
      poll_one_napi and napi_disable.  That is to say, poll_one_napi only tests the
      NAPI_STATE_SCHED bit to see if there is work to do during a poll, and as such
      the following may happen:
      
      CPU0				CPU1
      ndo_tx_timeout			napi_poll_dev
       napi_disable			 poll_one_napi
        test_and_set_bit (ret 0)
      				  test_bit (ret 1)
         reset adapter		   napi_poll_routine
      
      If the adapter gets a tx timeout without a napi instance scheduled, its possible
      for the adapter to think it has exclusive access to the hardware  (as the napi
      instance is now scheduled via the napi_disable call), while the netpoll code
      thinks there is simply work to do.  The result is parallel hardware access
      leading to corrupt data structures in the driver, and a crash.
      
      Additionaly, there is another, more critical race between netpoll and
      napi_disable.  The disabled napi state is actually identical to the scheduled
      state for a given napi instance.  The implication being that, if a napi instance
      is disabled, a netconsole instance would see the napi state of the device as
      having been scheduled, and poll it, likely while the driver was dong something
      requiring exclusive access.  In the case above, its fairly clear that not having
      the rings in a state ready to be polled will cause any number of crashes.
      
      The fix should be pretty easy.  netpoll uses its own bit to indicate that that
      the napi instance is in a state of being serviced by netpoll (NAPI_STATE_NPSVC).
      We can just gate disabling on that bit as well as the sched bit.  That should
      prevent netpoll from conducting a napi poll if we convert its set bit to a
      test_and_set_bit operation to provide mutual exclusion
      
      Change notes:
      V2)
      	Remove a trailing whtiespace
      	Resubmit with proper subject prefix
      
      V3)
      	Clean up spacing nits
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: jmaxwell@redhat.com
      Tested-by: jmaxwell@redhat.com
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d8bff12
  3. 23 9月, 2015 2 次提交
  4. 22 9月, 2015 2 次提交
    • L
      vga_switcheroo: Document _ALL_ the things! · a645654b
      Lukas Wunner 提交于
      This adds an "Overview" DOC section plus two DOC sections for the modes
      of use ("Manual switching and manual power control" and "Driver power
      control").
      
      Also included is kernel-doc for all public functions, structs and enums.
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a645654b
    • E
      tcp/dccp: fix timewait races in timer handling · ed2e9239
      Eric Dumazet 提交于
      When creating a timewait socket, we need to arm the timer before
      allowing other cpus to find it. The signal allowing cpus to find
      the socket is setting tw_refcnt to non zero value.
      
      As we set tw_refcnt in __inet_twsk_hashdance(), we therefore need to
      call inet_twsk_schedule() first.
      
      This also means we need to remove tw_refcnt changes from
      inet_twsk_schedule() and let the caller handle it.
      
      Note that because we use mod_timer_pinned(), we have the guarantee
      the timer wont expire before we set tw_refcnt as we run in BH context.
      
      To make things more readable I introduced inet_twsk_reschedule() helper.
      
      When rearming the timer, we can use mod_timer_pending() to make sure
      we do not rearm a canceled timer.
      
      Note: This bug can possibly trigger if packets of a flow can hit
      multiple cpus. This does not normally happen, unless flow steering
      is broken somehow. This explains this bug was spotted ~5 months after
      its introduction.
      
      A similar fix is needed for SYN_RECV sockets in reqsk_queue_hash_req(),
      but will be provided in a separate patch for proper tracking.
      
      Fixes: 789f558c ("tcp/dccp: get rid of central timewait timer")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NYing Cai <ycai@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ed2e9239
  5. 21 9月, 2015 3 次提交
    • N
      ip6tunnel: make rx/tx bytes counters consistent · 83cf9a25
      Nicolas Dichtel 提交于
      Like the previous patch, which fixes ipv4 tunnels, here is the ipv6 part.
      
      Before the patch, the external ipv6 header + gre header were included on
      tx.
      
      After the patch:
      $ ping -c1 192.168.6.121 ; ip -s l ls dev ip6gre1
      PING 192.168.6.121 (192.168.6.121) 56(84) bytes of data.
      64 bytes from 192.168.6.121: icmp_req=1 ttl=64 time=1.92 ms
      
      --- 192.168.6.121 ping statistics ---
      1 packets transmitted, 1 received, 0% packet loss, time 0ms
      rtt min/avg/max/mdev = 1.923/1.923/1.923/0.000 ms
      7: ip6gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN mode DEFAULT group default
          link/gre6 20:01:06:60:30:08:c1:c3:00:00:00:00:00:00:01:23 peer 20:01:06:60:30:08:c1:c3:00:00:00:00:00:00:01:21
          RX: bytes  packets  errors  dropped overrun mcast
          84         1        0       0       0       0
          TX: bytes  packets  errors  dropped carrier collsns
          84         1        0       0       0       0
      $ ping -c1 192.168.1.121 ; ip -s l ls dev ip6tnl1
      PING 192.168.1.121 (192.168.1.121) 56(84) bytes of data.
      64 bytes from 192.168.1.121: icmp_req=1 ttl=64 time=2.28 ms
      
      --- 192.168.1.121 ping statistics ---
      1 packets transmitted, 1 received, 0% packet loss, time 0ms
      rtt min/avg/max/mdev = 2.288/2.288/2.288/0.000 ms
      8: ip6tnl1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state UNKNOWN mode DEFAULT group default
          link/tunnel6 2001:660:3008:c1c3::123 peer 2001:660:3008:c1c3::121
          RX: bytes  packets  errors  dropped overrun mcast
          84         1        0       0       0       0
          TX: bytes  packets  errors  dropped carrier collsns
          84         1        0       0       0       0
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83cf9a25
    • N
      net: Fix behaviour of unreachable, blackhole and prohibit routes · 0315e382
      Nikola Forró 提交于
      Man page of ip-route(8) says following about route types:
      
        unreachable - these destinations are unreachable.  Packets are dis‐
        carded and the ICMP message host unreachable is generated.  The local
        senders get an EHOSTUNREACH error.
      
        blackhole - these destinations are unreachable.  Packets are dis‐
        carded silently.  The local senders get an EINVAL error.
      
        prohibit - these destinations are unreachable.  Packets are discarded
        and the ICMP message communication administratively prohibited is
        generated.  The local senders get an EACCES error.
      
      In the inet6 address family, this was correct, except the local senders
      got ENETUNREACH error instead of EHOSTUNREACH in case of unreachable route.
      In the inet address family, all three route types generated ICMP message
      net unreachable, and the local senders got ENETUNREACH error.
      
      In both address families all three route types now behave consistently
      with documentation.
      Signed-off-by: NNikola Forró <nforro@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0315e382
    • J
      b7f76ea2
  6. 19 9月, 2015 1 次提交
  7. 18 9月, 2015 6 次提交
  8. 17 9月, 2015 4 次提交
  9. 16 9月, 2015 7 次提交