1. 29 3月, 2014 1 次提交
  2. 28 3月, 2014 2 次提交
  3. 27 3月, 2014 2 次提交
  4. 25 3月, 2014 2 次提交
    • E
      tipc: fix spinlock recursion bug for failed subscriptions · a5d0e7c0
      Erik Hugne 提交于
      If a topology event subscription fails for any reason, such as out
      of memory, max number reached or because we received an invalid
      request the correct behavior is to terminate the subscribers
      connection to the topology server. This is currently broken and
      produces the following oops:
      
      [27.953662] tipc: Subscription rejected, illegal request
      [27.955329] BUG: spinlock recursion on CPU#1, kworker/u4:0/6
      [27.957066]  lock: 0xffff88003c67f408, .magic: dead4ead, .owner: kworker/u4:0/6, .owner_cpu: 1
      [27.958054] CPU: 1 PID: 6 Comm: kworker/u4:0 Not tainted 3.14.0-rc6+ #5
      [27.960230] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [27.960874] Workqueue: tipc_rcv tipc_recv_work [tipc]
      [27.961430]  ffff88003c67f408 ffff88003de27c18 ffffffff815c0207 ffff88003de1c050
      [27.962292]  ffff88003de27c38 ffffffff815beec5 ffff88003c67f408 ffffffff817f0a8a
      [27.963152]  ffff88003de27c58 ffffffff815beeeb ffff88003c67f408 ffffffffa0013520
      [27.964023] Call Trace:
      [27.964292]  [<ffffffff815c0207>] dump_stack+0x45/0x56
      [27.964874]  [<ffffffff815beec5>] spin_dump+0x8c/0x91
      [27.965420]  [<ffffffff815beeeb>] spin_bug+0x21/0x26
      [27.965995]  [<ffffffff81083df6>] do_raw_spin_lock+0x116/0x140
      [27.966631]  [<ffffffff815c6215>] _raw_spin_lock_bh+0x15/0x20
      [27.967256]  [<ffffffffa0008540>] subscr_conn_shutdown_event+0x20/0xa0 [tipc]
      [27.968051]  [<ffffffffa000fde4>] tipc_close_conn+0xa4/0xb0 [tipc]
      [27.968722]  [<ffffffffa00101ba>] tipc_conn_terminate+0x1a/0x30 [tipc]
      [27.969436]  [<ffffffffa00089a2>] subscr_conn_msg_event+0x1f2/0x2f0 [tipc]
      [27.970209]  [<ffffffffa0010000>] tipc_receive_from_sock+0x90/0xf0 [tipc]
      [27.970972]  [<ffffffffa000fa79>] tipc_recv_work+0x29/0x50 [tipc]
      [27.971633]  [<ffffffff8105dbf5>] process_one_work+0x165/0x3e0
      [27.972267]  [<ffffffff8105e869>] worker_thread+0x119/0x3a0
      [27.972896]  [<ffffffff8105e750>] ? manage_workers.isra.25+0x2a0/0x2a0
      [27.973622]  [<ffffffff810648af>] kthread+0xdf/0x100
      [27.974168]  [<ffffffff810647d0>] ? kthread_create_on_node+0x1a0/0x1a0
      [27.974893]  [<ffffffff815ce13c>] ret_from_fork+0x7c/0xb0
      [27.975466]  [<ffffffff810647d0>] ? kthread_create_on_node+0x1a0/0x1a0
      
      The recursion occurs when subscr_terminate tries to grab the
      subscriber lock, which is already taken by subscr_conn_msg_event.
      We fix this by checking if the request to establish a new
      subscription was successful, and if not we initiate termination of
      the subscriber after we have released the subscriber lock.
      Signed-off-by: NErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a5d0e7c0
    • L
      netpoll: fix the skb check in pkt_is_ns · c27f0872
      Li RongQing 提交于
      Neighbor Solicitation is ipv6 protocol, so we should check
      skb->protocol with ETH_P_IPV6
      Signed-off-by: NLi RongQing <roy.qing.li@gmail.com>
      Cc: WANG Cong <amwang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c27f0872
  5. 21 3月, 2014 4 次提交
  6. 19 3月, 2014 1 次提交
    • L
      ipv6: ip6_append_data_mtu do not handle the mtu of the second fragment properly · e367c2d0
      lucien 提交于
      In ip6_append_data_mtu(), when the xfrm mode is not tunnel(such as
      transport),the ipsec header need to be added in the first fragment, so the mtu
      will decrease to reserve space for it, then the second fragment come, the mtu
      should be turn back, as the commit 0c183379
      said.  however, in the commit a493e60ac4bbe2e977e7129d6d8cbb0dd236be, it use
      *mtu = min(*mtu, ...) to change the mtu, which lead to the new mtu is alway
      equal with the first fragment's. and cannot turn back.
      
      when I test through  ping6 -c1 -s5000 $ip (mtu=1280):
      ...frag (0|1232) ESP(spi=0x00002000,seq=0xb), length 1232
      ...frag (1232|1216)
      ...frag (2448|1216)
      ...frag (3664|1216)
      ...frag (4880|164)
      
      which should be:
      ...frag (0|1232) ESP(spi=0x00001000,seq=0x1), length 1232
      ...frag (1232|1232)
      ...frag (2464|1232)
      ...frag (3696|1232)
      ...frag (4928|116)
      
      so delete the min() when change back the mtu.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Fixes: 75a493e6 ("ipv6: ip6_append_data_mtu did not care about pmtudisc and frag_size")
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e367c2d0
  7. 14 3月, 2014 1 次提交
  8. 13 3月, 2014 1 次提交
  9. 12 3月, 2014 8 次提交
  10. 11 3月, 2014 3 次提交
  11. 10 3月, 2014 3 次提交
    • A
      00e188ef
    • N
      selinux: add gfp argument to security_xfrm_policy_alloc and fix callers · 52a4c640
      Nikolay Aleksandrov 提交于
      security_xfrm_policy_alloc can be called in atomic context so the
      allocation should be done with GFP_ATOMIC. Add an argument to let the
      callers choose the appropriate way. In order to do so a gfp argument
      needs to be added to the method xfrm_policy_alloc_security in struct
      security_operations and to the internal function
      selinux_xfrm_alloc_user. After that switch to GFP_ATOMIC in the atomic
      callers and leave GFP_KERNEL as before for the rest.
      The path that needed the gfp argument addition is:
      security_xfrm_policy_alloc -> security_ops.xfrm_policy_alloc_security ->
      all users of xfrm_policy_alloc_security (e.g. selinux_xfrm_policy_alloc) ->
      selinux_xfrm_alloc_user (here the allocation used to be GFP_KERNEL only)
      
      Now adding a gfp argument to selinux_xfrm_alloc_user requires us to also
      add it to security_context_to_sid which is used inside and prior to this
      patch did only GFP_KERNEL allocation. So add gfp argument to
      security_context_to_sid and adjust all of its callers as well.
      
      CC: Paul Moore <paul@paul-moore.com>
      CC: Dave Jones <davej@redhat.com>
      CC: Steffen Klassert <steffen.klassert@secunet.com>
      CC: Fan Du <fan.du@windriver.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: LSM list <linux-security-module@vger.kernel.org>
      CC: SELinux list <selinux@tycho.nsa.gov>
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: NPaul Moore <paul@paul-moore.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      52a4c640
    • N
      net: af_key: fix sleeping under rcu · 87536a81
      Nikolay Aleksandrov 提交于
      There's a kmalloc with GFP_KERNEL in a helper
      (pfkey_sadb2xfrm_user_sec_ctx) used in pfkey_compile_policy which is
      called under rcu_read_lock. Adjust pfkey_sadb2xfrm_user_sec_ctx to have
      a gfp argument and adjust the users.
      
      CC: Dave Jones <davej@redhat.com>
      CC: Steffen Klassert <steffen.klassert@secunet.com>
      CC: Fan Du <fan.du@windriver.com>
      CC: David S. Miller <davem@davemloft.net>
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      87536a81
  12. 07 3月, 2014 12 次提交
    • S
      ipv6: don't set DST_NOCOUNT for remotely added routes · c88507fb
      Sabrina Dubroca 提交于
      DST_NOCOUNT should only be used if an authorized user adds routes
      locally. In case of routes which are added on behalf of router
      advertisments this flag must not get used as it allows an unlimited
      number of routes getting added remotely.
      Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c88507fb
    • A
      ipv6: Fix exthdrs offload registration. · d2d273ff
      Anton Nayshtut 提交于
      Without this fix, ipv6_exthdrs_offload_init doesn't register IPPROTO_DSTOPTS
      offload, but returns 0 (as the IPPROTO_ROUTING registration actually succeeds).
      
      This then causes the ipv6_gso_segment to drop IPv6 packets with IPPROTO_DSTOPTS
      header.
      
      The issue detected and the fix verified by running MS HCK Offload LSO test on
      top of QEMU Windows guests, as this test sends IPv6 packets with
      IPPROTO_DSTOPTS.
      Signed-off-by: NAnton Nayshtut <anton@swortex.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2d273ff
    • A
      net: unix socket code abuses csum_partial · 0a13404d
      Anton Blanchard 提交于
      The unix socket code is using the result of csum_partial to
      hash into a lookup table:
      
      	unix_hash_fold(csum_partial(sunaddr, len, 0));
      
      csum_partial is only guaranteed to produce something that can be
      folded into a checksum, as its prototype explains:
      
       * returns a 32-bit number suitable for feeding into itself
       * or csum_tcpudp_magic
      
      The 32bit value should not be used directly.
      
      Depending on the alignment, the ppc64 csum_partial will return
      different 32bit partial checksums that will fold into the same
      16bit checksum.
      
      This difference causes the following testcase (courtesy of
      Gustavo) to sometimes fail:
      
      #include <sys/socket.h>
      #include <stdio.h>
      
      int main()
      {
      	int fd = socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0);
      
      	int i = 1;
      	setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &i, 4);
      
      	struct sockaddr addr;
      	addr.sa_family = AF_LOCAL;
      	bind(fd, &addr, 2);
      
      	listen(fd, 128);
      
      	struct sockaddr_storage ss;
      	socklen_t sslen = (socklen_t)sizeof(ss);
      	getsockname(fd, (struct sockaddr*)&ss, &sslen);
      
      	fd = socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0);
      
      	if (connect(fd, (struct sockaddr*)&ss, sslen) == -1){
      		perror(NULL);
      		return 1;
      	}
      	printf("OK\n");
      	return 0;
      }
      
      As suggested by davem, fix this by using csum_fold to fold the
      partial 32bit checksum into a 16bit checksum before using it.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a13404d
    • F
      inet: frag: make sure forced eviction removes all frags · e588e2f2
      Florian Westphal 提交于
      Quoting Alexander Aring:
        While fragmentation and unloading of 6lowpan module I got this kernel Oops
        after few seconds:
      
        BUG: unable to handle kernel paging request at f88bbc30
        [..]
        Modules linked in: ipv6 [last unloaded: 6lowpan]
        Call Trace:
         [<c012af4c>] ? call_timer_fn+0x54/0xb3
         [<c012aef8>] ? process_timeout+0xa/0xa
         [<c012b66b>] run_timer_softirq+0x140/0x15f
      
      Problem is that incomplete frags are still around after unload; when
      their frag expire timer fires, we get crash.
      
      When a netns is removed (also done when unloading module), inet_frag
      calls the evictor with 'force' argument to purge remaining frags.
      
      The evictor loop terminates when accounted memory ('work') drops to 0
      or the lru-list becomes empty.  However, the mem accounting is done
      via percpu counters and may not be accurate, i.e. loop may terminate
      prematurely.
      
      Alter evictor to only stop once the lru list is empty when force is
      requested.
      Reported-by: NPhoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
      Reported-by: NAlexander Aring <alex.aring@gmail.com>
      Tested-by: NAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e588e2f2
    • E
      tipc: don't log disabled tasklet handler errors · 2892505e
      Erik Hugne 提交于
      Failure to schedule a TIPC tasklet with tipc_k_signal because the
      tasklet handler is disabled is not an error. It means TIPC is
      currently in the process of shutting down. We remove the error
      logging in this case.
      Signed-off-by: NErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2892505e
    • E
      tipc: fix memory leak during module removal · 1bb8dce5
      Erik Hugne 提交于
      When the TIPC module is removed, the tasklet handler is disabled
      before all other subsystems. This will cause lingering publications
      in the name table because the node_down tasklets responsible to
      clean up publications from an unreachable node will never run.
      When the name table is shut down, these publications are detected
      and an error message is logged:
      tipc: nametbl_stop(): orphaned hash chain detected
      This is actually a memory leak, introduced with commit
      993b858e ("tipc: correct the order
      of stopping services at rmmod")
      
      Instead of just logging an error and leaking memory, we free
      the orphaned entries during nametable shutdown.
      Signed-off-by: NErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1bb8dce5
    • E
      tipc: drop subscriber connection id invalidation · edcc0511
      Erik Hugne 提交于
      When a topology server subscriber is disconnected, the associated
      connection id is set to zero. A check vs zero is then done in the
      subscription timeout function to see if the subscriber have been
      shut down. This is unnecessary, because all subscription timers
      will be cancelled when a subscriber terminates. Setting the
      connection id to zero is actually harmful because id zero is the
      identity of the topology server listening socket, and can cause a
      race that leads to this socket being closed instead.
      Signed-off-by: NErik Hugne <erik.hugne@ericsson.com>
      Acked-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      edcc0511
    • Y
      tipc: avoid to unnecessary process switch under non-block mode · fe8e4649
      Ying Xue 提交于
      When messages are received via tipc socket under non-block mode,
      schedule_timeout() is called in tipc_wait_for_rcvmsg(), that is,
      the process of receiving messages will be scheduled once although
      timeout value passed to schedule_timeout() is 0. The same issue
      exists in accept()/wait_for_accept(). To avoid this unnecessary
      process switch, we only call schedule_timeout() if the timeout
      value is non-zero.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fe8e4649
    • Y
      tipc: fix connection refcount leak · 4652edb7
      Ying Xue 提交于
      When tipc_conn_sendmsg() calls tipc_conn_lookup() to query a
      connection instance, its reference count value is increased if
      it's found. But subsequently if it's found that the connection is
      closed, the work of sending message is not queued into its server
      send workqueue, and the connection reference count is not decreased.
      This will cause a reference count leak. To reproduce this problem,
      an application would need to open and closes topology server
      connections with high intensity.
      
      We fix this by immediately decrementing the connection reference
      count if a send fails due to the connection being closed.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Acked-by: NErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4652edb7
    • Y
      tipc: allow connection shutdown callback to be invoked in advance · 6d4ebeb4
      Ying Xue 提交于
      Currently connection shutdown callback function is called when
      connection instance is released in tipc_conn_kref_release(), and
      receiving packets and sending packets are running in different
      threads. Even if connection is closed by the thread of receiving
      packets, its shutdown callback may not be called immediately as
      the connection reference count is non-zero at that moment. So,
      although the connection is shut down by the thread of receiving
      packets, the thread of sending packets doesn't know it. Before
      its shutdown callback is invoked to tell the sending thread its
      connection has been closed, the sending thread may deliver
      messages by tipc_conn_sendmsg(), this is why the following error
      information appears:
      
      "Sending subscription event failed, no memory"
      
      To eliminate it, allow connection shutdown callback function to
      be called before connection id is removed in tipc_close_conn(),
      which makes the sending thread know the truth in time that its
      socket is closed so that it doesn't send message to it. We also
      remove the "Sending XXX failed..." error reporting for topology
      and config services.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d4ebeb4
    • G
      l2tp: fix userspace reception on plain L2TP sockets · 9e9cb622
      Guillaume Nault 提交于
      As pppol2tp_recv() never queues up packets to plain L2TP sockets,
      pppol2tp_recvmsg() never returns data to userspace, thus making
      the recv*() system calls unusable.
      
      Instead of dropping packets when the L2TP socket isn't bound to a PPP
      channel, this patch adds them to its reception queue.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9e9cb622
    • G
      l2tp: fix manual sequencing (de)activation in L2TPv2 · bb5016ea
      Guillaume Nault 提交于
      Commit e0d4435f "l2tp: Update PPP-over-L2TP driver to work over L2TPv3"
      broke the PPPOL2TP_SO_SENDSEQ setsockopt. The L2TP header length was
      previously computed by pppol2tp_l2t_header_len() before each call to
      l2tp_xmit_skb(). Now that header length is retrieved from the hdr_len
      session field, this field must be updated every time the L2TP header
      format is modified, or l2tp_xmit_skb() won't push the right amount of
      data for the L2TP header.
      
      This patch uses l2tp_session_set_header_len() to adjust hdr_len every
      time sequencing is (de)activated from userspace (either by the
      PPPOL2TP_SO_SENDSEQ setsockopt or the L2TP_ATTR_SEND_SEQ netlink
      attribute).
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb5016ea