Skip to content

L
linux
Switch branch/tag
  1. 16 Jul, 2014 24 commits
  3. 15 Jul, 2014 12 commits
  5. 14 Jul, 2014 4 commits
    • Oleg Nesterov's avatar
      introduce for_each_thread() to replace the buggy while_each_thread() · e1790aea
      Oleg Nesterov authored 
      commit 0c740d0a upstream.

while_each_thread() and next_thread() should die, almost every lockless
usage is wrong.

1. Unless g == current, the lockless while_each_thread() is not safe.

   while_each_thread(g, t) can loop forever if g exits, next_thread()
   can't reach the unhashed thread in this case. Note that this can
   happen even if g is the group leader, it can exec.

2. Even if while_each_thread() itself was correct, people often use
   it wrongly.

   It was never safe to just take rcu_read_lock() and loop unless
   you verify that pid_alive(g) == T, even the first next_thread()
   can point to the already freed/reused memory.

This patch adds signal_struct->thread_head and task->thread_node to
create the normal rcu-safe list with the stable head.  The new
for_each_thread(g, t) helper is always safe under rcu_read_lock() as
long as this task_struct can't go away.

Note: of course it is ugly to have both task_struct->thread_node and the
old task_struct->thread_group, we will kill it later, after we change
the users of while_each_thread() to use for_each_thread().

Perhaps we can kill it even before we convert all users, we can
reimplement next_thread(t) using the new thread_head/thread_node.  But
we can't do this right now because this will lead to subtle behavioural
changes.  For example, do/while_each_thread() always sees at least one
task, while for_each_thread() can do nothing if the whole thread group
has died.  Or thread_group_empty(), currently its semantics is not clear
unless thread_group_leader(p) and we need to audit the callers before we
can change it.

So this patch adds the new interface which has to coexist with the old
one for some time, hopefully the next changes will be more or less
straightforward and the old one will go away soon.
Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
Reviewed-by: default avatarSergey Dyasly <dserrg@gmail.com>
Tested-by: default avatarSergey Dyasly <dserrg@gmail.com>
Reviewed-by: default avatarSameer Nanda <snanda@chromium.org>
Acked-by: default avatarDavid Rientjes <rientjes@google.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mandeep Singh Baines <msb@chromium.org>
Cc: "Ma, Xindong" <xindong.ma@intel.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: "Tu, Xiaobing" <xiaobing.tu@intel.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
[ kamal: 3.13-stable for backport convenience ]
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e1790aea
    • Florian Westphal's avatar
      netfilter: nf_nat: fix oops on netns removal · d17b4c8f
      Florian Westphal authored 
      commit 945b2b2d upstream.

Quoting Samu Kallio:

 Basically what's happening is, during netns cleanup,
 nf_nat_net_exit gets called before ipv4_net_exit. As I understand
 it, nf_nat_net_exit is supposed to kill any conntrack entries which
 have NAT context (through nf_ct_iterate_cleanup), but for some
 reason this doesn't happen (perhaps something else is still holding
 refs to those entries?).

 When ipv4_net_exit is called, conntrack entries (including those
 with NAT context) are cleaned up, but the
 nat_bysource hashtable is long gone - freed in nf_nat_net_exit. The
 bug happens when attempting to free a conntrack entry whose NAT hash
 'prev' field points to a slot in the freed hash table (head for that
 bin).

We ignore conntracks with null nat bindings.  But this is wrong,
as these are in bysource hash table as well.

Restore nat-cleaning for the netns-is-being-removed case.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=65191

Fixes: c2d421e1 ('netfilter: nf_nat: fix race when unloading protocol modules')
Reported-by: default avatarSamu Kallio <samu.kallio@aberdeencloud.com>
Debugged-by: default avatarSamu Kallio <samu.kallio@aberdeencloud.com>
Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
Tested-by: default avatarSamu Kallio <samu.kallio@aberdeencloud.com>
Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
Cc: Chris J Arges <chris.j.arges@canonical.com>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      d17b4c8f
    • Todd Fujinaka's avatar
      igb: fix stats for i210 rx_fifo_errors · e857a038
      Todd Fujinaka authored 
      commit e66c083a upstream.

RQDPC on i210/i211 is R/W not ReadClear. Clear after reading.
Signed-off-by: default avatarTodd Fujinaka <todd.fujinaka@intel.com>
Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e857a038
    • Johan Hedberg's avatar
      Bluetooth: Fix check for connection encryption · 44daeeb6
      Johan Hedberg authored 
      commit e694788d upstream.

The conn->link_key variable tracks the type of link key in use. It is
set whenever we respond to a link key request as well as when we get a
link key notification event.

These two events do not however always guarantee that encryption is
enabled: getting a link key request and responding to it may only mean
that the remote side has requested authentication but not encryption. On
the other hand, the encrypt change event is a certain guarantee that
encryption is enabled. The real encryption state is already tracked in
the conn->link_mode variable through the HCI_LM_ENCRYPT bit.

This patch fixes a check for encryption in the hci_conn_auth function to
use the proper conn->link_mode value and thereby eliminates the chance
of a false positive result.
Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      44daeeb6
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7