1. 04 5月, 2011 2 次提交
  2. 03 5月, 2011 2 次提交
  3. 02 5月, 2011 2 次提交
    • A
      ipv4: don't spam dmesg with "Using LC-trie" messages · 7cfd2609
      Alexey Dobriyan 提交于
      fib_trie_table() is called during netns creation and
      Chromium uses clone(CLONE_NEWNET) to sandbox renderer process.
      
      Don't print anything.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7cfd2609
    • E
      af_unix: Only allow recv on connected seqpacket sockets. · a05d2ad1
      Eric W. Biederman 提交于
      This fixes the following oops discovered by Dan Aloni:
      > Anyway, the following is the output of the Oops that I got on the
      > Ubuntu kernel on which I first detected the problem
      > (2.6.37-12-generic). The Oops that followed will be more useful, I
      > guess.
      
      >[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference
      > at           (null)
      > [ 5594.681606] IP: [<ffffffff81550b7b>] unix_dgram_recvmsg+0x1fb/0x420
      > [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0
      > [ 5594.693720] Oops: 0002 [#1] SMP
      > [ 5594.699888] last sysfs file:
      
      The bug was that unix domain sockets use a pseduo packet for
      connecting and accept uses that psudo packet to get the socket.
      In the buggy seqpacket case we were allowing unconnected
      sockets to call recvmsg and try to receive the pseudo packet.
      
      That is always wrong and as of commit 7361c36c the pseudo
      packet had become enough different from a normal packet
      that the kernel started oopsing.
      
      Do for seqpacket_recv what was done for seqpacket_send in 2.5
      and only allow it on connected seqpacket sockets.
      
      Cc: stable@kernel.org
      Tested-by: NDan Aloni <dan@aloni.org>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a05d2ad1
  4. 29 4月, 2011 1 次提交
  5. 27 4月, 2011 4 次提交
  6. 26 4月, 2011 1 次提交
    • H
      net: provide cow_metrics() methods to blackhole dst_ops · 0972ddb2
      Held Bernhard 提交于
      Since commit 62fa8a84 (net: Implement read-only protection and COW'ing
      of metrics.) the kernel throws an oops.
      
      [  101.620985] BUG: unable to handle kernel NULL pointer dereference at
                 (null)
      [  101.621050] IP: [<          (null)>]           (null)
      [  101.621084] PGD 6e53c067 PUD 3dd6a067 PMD 0
      [  101.621122] Oops: 0010 [#1] SMP
      [  101.621153] last sysfs file: /sys/devices/virtual/ppp/ppp/uevent
      [  101.621192] CPU 2
      [  101.621206] Modules linked in: l2tp_ppp pppox ppp_generic slhc
      l2tp_netlink l2tp_core deflate zlib_deflate twofish_x86_64
      twofish_common des_generic cbc ecb sha1_generic hmac af_key
      iptable_filter snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device loop
      snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec
      snd_pcm snd_timer snd i2c_i801 iTCO_wdt psmouse soundcore snd_page_alloc
      evdev uhci_hcd ehci_hcd thermal
      [  101.621552]
      [  101.621567] Pid: 5129, comm: openl2tpd Not tainted 2.6.39-rc4-Quad #3
      Gigabyte Technology Co., Ltd. G33-DS3R/G33-DS3R
      [  101.621637] RIP: 0010:[<0000000000000000>]  [<          (null)>]   (null)
      [  101.621684] RSP: 0018:ffff88003ddeba60  EFLAGS: 00010202
      [  101.621716] RAX: ffff88003ddb5600 RBX: ffff88003ddb5600 RCX:
      0000000000000020
      [  101.621758] RDX: ffffffff81a69a00 RSI: ffffffff81b7ee61 RDI:
      ffff88003ddb5600
      [  101.621800] RBP: ffff8800537cd900 R08: 0000000000000000 R09:
      ffff88003ddb5600
      [  101.621840] R10: 0000000000000005 R11: 0000000000014b38 R12:
      ffff88003ddb5600
      [  101.621881] R13: ffffffff81b7e480 R14: ffffffff81b7e8b8 R15:
      ffff88003ddebad8
      [  101.621924] FS:  00007f06e4182700(0000) GS:ffff88007fd00000(0000)
      knlGS:0000000000000000
      [  101.621971] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  101.622005] CR2: 0000000000000000 CR3: 0000000045274000 CR4:
      00000000000006e0
      [  101.622046] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
      0000000000000000
      [  101.622087] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
      0000000000000400
      [  101.622129] Process openl2tpd (pid: 5129, threadinfo
      ffff88003ddea000, task ffff88003de9a280)
      [  101.622177] Stack:
      [  101.622191]  ffffffff81447efa ffff88007d3ded80 ffff88003de9a280
      ffff88007d3ded80
      [  101.622245]  0000000000000001 ffff88003ddebbb8 ffffffff8148d5a7
      0000000000000212
      [  101.622299]  ffff88003dcea000 ffff88003dcea188 ffffffff00000001
      ffffffff81b7e480
      [  101.622353] Call Trace:
      [  101.622374]  [<ffffffff81447efa>] ? ipv4_blackhole_route+0x1ba/0x210
      [  101.622415]  [<ffffffff8148d5a7>] ? xfrm_lookup+0x417/0x510
      [  101.622450]  [<ffffffff8127672a>] ? extract_buf+0x9a/0x140
      [  101.622485]  [<ffffffff8144c6a0>] ? __ip_flush_pending_frames+0x70/0x70
      [  101.622526]  [<ffffffff8146fbbf>] ? udp_sendmsg+0x62f/0x810
      [  101.622562]  [<ffffffff813f98a6>] ? sock_sendmsg+0x116/0x130
      [  101.622599]  [<ffffffff8109df58>] ? find_get_page+0x18/0x90
      [  101.622633]  [<ffffffff8109fd6a>] ? filemap_fault+0x12a/0x4b0
      [  101.622668]  [<ffffffff813fb5c4>] ? move_addr_to_kernel+0x64/0x90
      [  101.622706]  [<ffffffff81405d5a>] ? verify_iovec+0x7a/0xf0
      [  101.622739]  [<ffffffff813fc772>] ? sys_sendmsg+0x292/0x420
      [  101.622774]  [<ffffffff810b994a>] ? handle_pte_fault+0x8a/0x7c0
      [  101.622810]  [<ffffffff810b76fe>] ? __pte_alloc+0xae/0x130
      [  101.622844]  [<ffffffff810ba2f8>] ? handle_mm_fault+0x138/0x380
      [  101.622880]  [<ffffffff81024af9>] ? do_page_fault+0x189/0x410
      [  101.622915]  [<ffffffff813fbe03>] ? sys_getsockname+0xf3/0x110
      [  101.622952]  [<ffffffff81450c4d>] ? ip_setsockopt+0x4d/0xa0
      [  101.622986]  [<ffffffff813f9932>] ? sockfd_lookup_light+0x22/0x90
      [  101.623024]  [<ffffffff814b61fb>] ? system_call_fastpath+0x16/0x1b
      [  101.623060] Code:  Bad RIP value.
      [  101.623090] RIP  [<          (null)>]           (null)
      [  101.623125]  RSP <ffff88003ddeba60>
      [  101.623146] CR2: 0000000000000000
      [  101.650871] ---[ end trace ca3856a7d8e8dad4 ]---
      [  101.651011] __sk_free: optmem leakage (160 bytes) detected.
      
      The oops happens in dst_metrics_write_ptr()
      include/net/dst.h:124: return dst->ops->cow_metrics(dst, p);
      
      dst->ops->cow_metrics is NULL and causes the oops.
      
      Provide cow_metrics() methods, like we did in commit 214f45c9
      (net: provide default_advmss() methods to blackhole dst_ops)
      Signed-off-by: NHeld Bernhard <berny156@gmx.de>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0972ddb2
  7. 25 4月, 2011 1 次提交
  8. 22 4月, 2011 3 次提交
  9. 21 4月, 2011 2 次提交
  10. 20 4月, 2011 1 次提交
  11. 19 4月, 2011 6 次提交
  12. 16 4月, 2011 4 次提交
  13. 15 4月, 2011 1 次提交
  14. 14 4月, 2011 2 次提交
  15. 13 4月, 2011 8 次提交
    • J
      netfilter: ipset: set match and SET target fixes · eafbd3fd
      Jozsef Kadlecsik 提交于
      The SET target with --del-set did not work due to using wrongly
      the internal dimension of --add-set instead of --del-set.
      Also, the checkentries did not release the set references when
      returned an error. Bugs reported by Lennert Buytenhek.
      Signed-off-by: NJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      eafbd3fd
    • J
      netfilter: ipset: bitmap:ip,mac type requires "src" for MAC · 0e8a835a
      Jozsef Kadlecsik 提交于
      Enforce that the second "src/dst" parameter of the set match and SET target
      must be "src", because we have access to the source MAC only in the packet.
      The previous behaviour, that the type required the second parameter
      but actually ignored the value was counter-intuitive and confusing.
      Signed-off-by: NJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      0e8a835a
    • W
      sctp: fix oops while removed transport still using as retran path · 9494c7c5
      Wei Yongjun 提交于
      Since we can not update retran path to unconfirmed transports,
      when we remove a peer, the retran path may not be update if the
      other transports are all unconfirmed, and we will still using
      the removed transport as the retran path. This may cause panic
      if retrasnmit happen.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9494c7c5
    • V
      sctp: fix oops when updating retransmit path with DEBUG on · 25f7bf7d
      Vlad Yasevich 提交于
      commit fbdf501c
        sctp: Do no select unconfirmed transports for retransmissions
      
      Introduced the initial falt.
      
      commit d598b166
        sctp: Make sure we always return valid retransmit path
      
      Solved the problem, but forgot to change the DEBUG statement.
      Thus it was still possible to dereference a NULL pointer.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      25f7bf7d
    • B
      net: Disable NETIF_F_TSO_ECN when TSO is disabled · 31d8b9e0
      Ben Hutchings 提交于
      NETIF_F_TSO_ECN has no effect when TSO is disabled; this just means
      that feature state will be accurately reported to user-space.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31d8b9e0
    • B
      net: Disable all TSO features when SG is disabled · ea2d3688
      Ben Hutchings 提交于
      The feature flags NETIF_F_TSO and NETIF_F_TSO6 independently enable
      TSO for IPv4 and IPv6 respectively.  However, the test in
      netdev_fix_features() and its predecessor functions was never updated
      to check for NETIF_F_TSO6, possibly because it was originally proposed
      that TSO for IPv6 would be dependent on both feature flags.
      
      Now that these feature flags can be changed independently from
      user-space and we depend on netdev_fix_features() to fix invalid
      feature combinations, it's important to disable them both if
      scatter-gather is disabled.  Also disable NETIF_F_TSO_ECN so
      user-space sees all TSO features as disabled.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ea2d3688
    • D
      ieee802154: Remove hacked CFLAGS in net/ieee802154/Makefile · bfac3693
      David S. Miller 提交于
      It adds -Wall (which the kernel carefully controls already) and of all
      things -DDEBUG (which should be set by other means if desired, please
      we have dynamic-debug these days).
      
      Kill this noise.
      Reported-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bfac3693
    • D
      irda: fix locking unbalance in irda_sendmsg · 020318d0
      Dave Jones 提交于
      5b40964e ("irda: Remove BKL instances
      from af_irda.c") introduced a path where we have a locking unbalance.
      If we pass invalid flags, we unlock a socket we never locked,
      resulting in this...
      
      =====================================
      [ BUG: bad unlock balance detected! ]
      -------------------------------------
      trinity/20101 is trying to release lock (sk_lock-AF_IRDA) at:
      [<ffffffffa057f001>] irda_sendmsg+0x207/0x21d [irda]
      but there are no more locks to release!
      
      other info that might help us debug this:
      no locks held by trinity/20101.
      
      stack backtrace:
      Pid: 20101, comm: trinity Not tainted 2.6.39-rc3+ #3
      Call Trace:
       [<ffffffffa057f001>] ? irda_sendmsg+0x207/0x21d [irda]
       [<ffffffff81085041>] print_unlock_inbalance_bug+0xc7/0xd2
       [<ffffffffa057f001>] ? irda_sendmsg+0x207/0x21d [irda]
       [<ffffffff81086aca>] lock_release+0xcf/0x18e
       [<ffffffff813ed190>] release_sock+0x2d/0x155
       [<ffffffffa057f001>] irda_sendmsg+0x207/0x21d [irda]
       [<ffffffff813e9f8c>] __sock_sendmsg+0x69/0x75
       [<ffffffff813ea105>] sock_sendmsg+0xa1/0xb6
       [<ffffffff81100ca3>] ? might_fault+0x5c/0xac
       [<ffffffff81086b7c>] ? lock_release+0x181/0x18e
       [<ffffffff81100cec>] ? might_fault+0xa5/0xac
       [<ffffffff81100ca3>] ? might_fault+0x5c/0xac
       [<ffffffff81133b94>] ? fcheck_files+0xb9/0xf0
       [<ffffffff813f387a>] ? copy_from_user+0x2f/0x31
       [<ffffffff813f3b70>] ? verify_iovec+0x52/0xa6
       [<ffffffff813eb4e3>] sys_sendmsg+0x23a/0x2b8
       [<ffffffff81086b7c>] ? lock_release+0x181/0x18e
       [<ffffffff810773c6>] ? up_read+0x28/0x2c
       [<ffffffff814bec3d>] ? do_page_fault+0x360/0x3b4
       [<ffffffff81087043>] ? trace_hardirqs_on_caller+0x10b/0x12f
       [<ffffffff810458aa>] ? finish_task_switch+0xb2/0xe3
       [<ffffffff8104583e>] ? finish_task_switch+0x46/0xe3
       [<ffffffff8108364a>] ? trace_hardirqs_off_caller+0x33/0x90
       [<ffffffff814bbaf9>] ? retint_swapgs+0x13/0x1b
       [<ffffffff81087043>] ? trace_hardirqs_on_caller+0x10b/0x12f
       [<ffffffff810a9dd3>] ? audit_syscall_entry+0x11c/0x148
       [<ffffffff8125609e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
       [<ffffffff814c22c2>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      020318d0
反馈
建议
客服 返回
顶部