1. 02 May, 2015 1 commit
  2. 15 Apr, 2015 1 commit
  3. 09 Apr, 2015 3 commits
  4. 05 Apr, 2015 1 commit
  5. 08 Jan, 2015 14 commits
  6. 23 Dec, 2014 1 commit
  7. 10 Dec, 2014 5 commits
    • Erik Kline's avatar
      net: ipv6: allow choosing optimistic addresses with use_optimistic · bfd5c1bc
      Erik Kline authored
      The use_optimistic sysctl makes optimistic IPv6 addresses
      equivalent to preferred addresses for source address selection
      (e.g., when calling connect()), but it does not allow an
      application to bind to optimistic addresses. This behaviour is
      inconsistent - for example, it doesn't make sense for bind() to
      an optimistic address fail with EADDRNOTAVAIL, but connect() to
      choose that address outgoing address on the same socket.
      
      Bug: 17769720
      Bug: 18609055
      Change-Id: I9de0d6c92ac45e29d28e318ac626c71806666f13
      Signed-off-by: default avatarErik Kline <ek@google.com>
      Signed-off-by: default avatarLorenzo Colitti <lorenzo@google.com>
      bfd5c1bc
    • Jane Zhou's avatar
      net/ping: handle protocol mismatching scenario · 954e7e0e
      Jane Zhou authored
      ping_lookup() may return a wrong sock if sk_buff's and sock's protocols
      dont' match. For example, sk_buff's protocol is ETH_P_IPV6, but sock's
      sk_family is AF_INET, in that case, if sk->sk_bound_dev_if is zero, a wrong
      sock will be returned.
      the fix is to "continue" the searching, if no matching, return NULL.
      
      [cherry-pick of net 91a0b603469069cdcce4d572b7525ffc9fd352a6]
      
      Bug: 18512516
      Change-Id: I520223ce53c0d4e155c37d6b65a03489cc7fd494
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: James Morris <jmorris@namei.org>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: netdev@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJane Zhou <a17711@motorola.com>
      Signed-off-by: default avatarYiwei Zhao <gbjc64@motorola.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      954e7e0e
    • Devin Kim's avatar
      cgroup: remove synchronize_rcu() from cgroup_attach_{task|proc}() · 9e6ff30b
      Devin Kim authored
      These 2 syncronize_rcu()s make attaching a task to a cgroup
      quite slow, and it can't be ignored in some situations.
      
      A real case from Colin Cross: Android uses cgroups heavily to
      manage thread priorities, putting threads in a background group
      with reduced cpu.shares when they are not visible to the user,
      and in a foreground group when they are. Some RPCs from foreground
      threads to background threads will temporarily move the background
      thread into the foreground group for the duration of the RPC.
      This results in many calls to cgroup_attach_task.
      
      In cgroup_attach_task() it's task->cgroups that is protected by RCU,
      and put_css_set() calls kfree_rcu() to free it.
      
      If we remove this synchronize_rcu(), there can be threads in RCU-read
      sections accessing their old cgroup via current->cgroups with
      concurrent rmdir operation, but this is safe.
      
       # time for ((i=0; i<50; i++)) { echo $$ > /mnt/sub/tasks; echo $$ > /mnt/tasks; }
      
      real    0m2.524s
      user    0m0.008s
      sys     0m0.004s
      
      With this patch:
      
      real    0m0.004s
      user    0m0.004s
      sys     0m0.000s
      
      tj: These synchronize_rcu()s are utterly confused.  synchornize_rcu()
          necessarily has to come between two operations to guarantee that
          the changes made by the former operation are visible to all rcu
          readers before proceeding to the latter operation.  Here,
          synchornize_rcu() are at the end of attach operations with nothing
          beyond it.  Its only effect would be delaying completion of
          write(2) to sysfs tasks/procs files until all rcu readers see the
          change, which doesn't mean anything.
      
      cherry-picked from:
      https://android.googlesource.com/kernel/common/+/5d65bc0ca1bceb73204dab943922ba3c83276a8c
      
      Bug: 17709419
      Change-Id: I98dacd6c13da27cb3496fe4a24a24084e46bdd9c
      Signed-off-by: default avatarLi Zefan <lizefan@huawei.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarColin Cross <ccross@google.com>
      Signed-off-by: default avatarDevin Kim <dojip.kim@lge.com>
      9e6ff30b
    • Erik Kline's avatar
      net: ipv6: Add a sysctl to make optimistic addresses useful candidates · 085ab6c2
      Erik Kline authored
      Add a sysctl that causes an interface's optimistic addresses
      to be considered equivalent to other non-deprecated addresses
      for source address selection purposes.  Preferred addresses
      will still take precedence over optimistic addresses, subject
      to other ranking in the source address selection algorithm.
      
      This is useful where different interfaces are connected to
      different networks from different ISPs (e.g., a cell network
      and a home wifi network).
      
      The current behaviour complies with RFC 3484/6724, and it
      makes sense if the host has only one interface, or has
      multiple interfaces on the same network (same or cooperating
      administrative domain(s), but not in the multiple distinct
      networks case.
      
      For example, if a mobile device has an IPv6 address on an LTE
      network and then connects to IPv6-enabled wifi, while the wifi
      IPv6 address is undergoing DAD, IPv6 connections will try use
      the wifi default route with the LTE IPv6 address, and will get
      stuck until they time out.
      
      Also, because optimistic nodes can receive frames, issue
      an RTM_NEWADDR as soon as DAD starts (with the IFA_F_OPTIMSTIC
      flag appropriately set).  A second RTM_NEWADDR is sent if DAD
      completes (the address flags have changed), otherwise an
      RTM_DELADDR is sent.
      
      Also: add an entry in ip-sysctl.txt for optimistic_dad.
      
      [backport of net-next 7fd2561e4ebdd070ebba6d3326c4c5b13942323f]
      Signed-off-by: default avatarErik Kline <ek@google.com>
      Acked-by: default avatarLorenzo Colitti <lorenzo@google.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Bug: 17769720
      Bug: 18180674
      Change-Id: I440a9b8c788db6767d191bbebfd2dff481aa9e0d
      085ab6c2
    • Iliyan Malchev's avatar
      Revert "tegra3_android_defconfig: switch to SLUB" · 6ff7a516
      Iliyan Malchev authored
      This reverts commit 9ec1bb86.
      6ff7a516
  8. 01 Dec, 2014 1 commit
  9. 29 Nov, 2014 1 commit
  10. 28 Nov, 2014 4 commits
  11. 27 Nov, 2014 2 commits
    • Iliyan Malchev's avatar
      cpufreq: sysfs knobs for disabling hotplug during UI interaction · 770b156c
      Iliyan Malchev authored
      Provide the following sysfs knobs:
      	/sys/devices/system/cpu/cpufreq/interactive
      		core_lock_period, default 200000ns
      		core_lock_count, default 0 (num_online_cpus)
      
      Sysfs file core_lock_period controls the amount of time, in nanoseconds, to
      hold some cores online.  It defaults to 200ms.  The number of cores to keep
      online for that duration is controlled by core_lock_count, which defaults to 0.
      When 0, we simply force num_online_cpus() to stay online; if greater than 0, we
      force max(core_lock_count, num_online_cpus()) to stay online.
      
      Note that you can write any value to core_lock_count, but it will get capped to
      the number of cores actually available.
      
      Change-Id: I6937e433c8343f8205e305d9da1a62f284b47f4f
      Signed-off-by: default avatarIliyan Malchev <malchev@google.com>
      770b156c
    • Dennis Rassmann's avatar
      defconfig: update · 6fe1ebca
      Dennis Rassmann authored
      Signed-off-by: Dennis Rassmann's avatarDennis Rassmann <showp1984@gmail.com>
      6fe1ebca
  12. 26 Nov, 2014 5 commits
  13. 25 Nov, 2014 1 commit