1. 13 1月, 2011 2 次提交
  2. 05 1月, 2011 1 次提交
    • J
      ipv4/route.c: respect prefsrc for local routes · 9fc3bbb4
      Joel Sing 提交于
      The preferred source address is currently ignored for local routes,
      which results in all local connections having a src address that is the
      same as the local dst address. Fix this by respecting the preferred source
      address when it is provided for local routes.
      
      This bug can be demonstrated as follows:
      
       # ifconfig dummy0 192.168.0.1
       # ip route show table local | grep local.*dummy0
       local 192.168.0.1 dev dummy0  proto kernel  scope host  src 192.168.0.1
       # ip route change table local local 192.168.0.1 dev dummy0 \
           proto kernel scope host src 127.0.0.1
       # ip route show table local | grep local.*dummy0
       local 192.168.0.1 dev dummy0  proto kernel  scope host  src 127.0.0.1
      
      We now establish a local connection and verify the source IP
      address selection:
      
       # nc -l 192.168.0.1 3128 &
       # nc 192.168.0.1 3128 &
       # netstat -ant | grep 192.168.0.1:3128.*EST
       tcp        0      0 192.168.0.1:3128        192.168.0.1:33228 ESTABLISHED
       tcp        0      0 192.168.0.1:33228       192.168.0.1:3128  ESTABLISHED
      Signed-off-by: NJoel Sing <jsing@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9fc3bbb4
  3. 04 1月, 2011 2 次提交
    • F
      bridge: stp: ensure mac header is set · e6f26129
      Florian Westphal 提交于
      commit bf9ae538
      (llc: use dev_hard_header) removed the
      skb_reset_mac_header call from llc_mac_hdr_init.
      
      This seems fine itself, but br_send_bpdu() invokes ebtables LOCAL_OUT.
      
      We oops in ebt_basic_match() because it assumes eth_hdr(skb) returns
      a meaningful result.
      
      Cc: acme@ghostprotocols.net
      References: https://bugzilla.kernel.org/show_bug.cgi?id=24532Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e6f26129
    • T
      bridge: fix br_multicast_ipv6_rcv for paged skbs · 9d89081d
      Tomas Winkler 提交于
      use pskb_may_pull to access ipv6 header correctly for paged skbs
      It was omitted in the bridge code leading to crash in blind
      __skb_pull
      
      since the skb is cloned undonditionally we also simplify the
      the exit path
      
      this fixes bug https://bugzilla.kernel.org/show_bug.cgi?id=25202
      
      Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: authenticated
      Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: associated (aid 2)
      Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 RADIUS: starting accounting session 4D0608A3-00000005
      Dec 15 14:36:41 User-PC kernel: [175576.120287] ------------[ cut here ]------------
      Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at include/linux/skbuff.h:1178!
      Dec 15 14:36:41 User-PC kernel: [175576.120609] invalid opcode: 0000 [#1] SMP
      Dec 15 14:36:41 User-PC kernel: [175576.120749] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
      Dec 15 14:36:41 User-PC kernel: [175576.121035] Modules linked in: approvals binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
      Dec 15 14:36:41 User-PC kernel: [175576.122712]
      Dec 15 14:36:41 User-PC kernel: [175576.122769] Pid: 0, comm: kworker/0:0 Tainted: G        W   2.6.37-rc5-wl+ #3 1015PE/1016P
      Dec 15 14:36:41 User-PC kernel: [175576.123012] EIP: 0060:[<f83edd65>] EFLAGS: 00010283 CPU: 1
      Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at br_multicast_rcv+0xc95/0xe1c [bridge]
      Dec 15 14:36:41 User-PC kernel: [175576.123362] EAX: 0000001c EBX: f5626318 ECX: 00000000 EDX: 00000000
      Dec 15 14:36:41 User-PC kernel: [175576.123550] ESI: ec512262 EDI: f5626180 EBP: f60b5ca0 ESP: f60b5bd8
      Dec 15 14:36:41 User-PC kernel: [175576.123737]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Dec 15 14:36:41 User-PC kernel: [175576.123902] Process kworker/0:0 (pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
      Dec 15 14:36:41 User-PC kernel: [175576.124137] Stack:
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  ec556500 f6d06800 f60b5be8 c01087d8 ec512262 00000030 00000024 f5626180
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  f572c200 ef463440 f5626300 3affffff f6d06dd0 e60766a4 000000c4 f6d06860
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  ffffffff ec55652c 00000001 f6d06844 f60b5c64 c0138264 c016e451 c013e47d
      Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01087d8>] ? sched_clock+0x8/0x10
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0138264>] ? enqueue_entity+0x174/0x440
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c016e451>] ? sched_clock_cpu+0x131/0x190
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c013e47d>] ? select_task_rq_fair+0x2ad/0x730
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0524fc1>] ? nf_iterate+0x71/0x90
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4914>] ? br_handle_frame_finish+0x184/0x220 [bridge]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e46e9>] ? br_handle_frame+0x189/0x230 [bridge]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4560>] ? br_handle_frame+0x0/0x230 [bridge]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04ff026>] ? __netif_receive_skb+0x1b6/0x5b0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04f7a30>] ? skb_copy_bits+0x110/0x210
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0503a7f>] ? netif_receive_skb+0x6f/0x80
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82cb74c>] ? ieee80211_deliver_skb+0x8c/0x1a0 [mac80211]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82cc836>] ? ieee80211_rx_handlers+0xeb6/0x1aa0 [mac80211]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04ff1f0>] ? __netif_receive_skb+0x380/0x5b0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c016e242>] ? sched_clock_local+0xb2/0x190
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c012b688>] ? default_spin_lock_flags+0x8/0x10
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82cd621>] ? ieee80211_prepare_and_rx_handle+0x201/0xa90 [mac80211]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82ce154>] ? ieee80211_rx+0x2a4/0x830 [mac80211]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f815a8d6>] ? iwl_update_stats+0xa6/0x2a0 [iwlcore]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f8499212>] ? iwlagn_rx_reply_rx+0x292/0x3b0 [iwlagn]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f8483697>] ? iwl_rx_handle+0xe7/0x350 [iwlagn]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f8486ab7>] ? iwl_irq_tasklet+0xf7/0x5c0 [iwlagn]
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01aece1>] ? __rcu_process_callbacks+0x201/0x2d0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0150d05>] ? tasklet_action+0xc5/0x100
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0150a07>] ? __do_softirq+0x97/0x1d0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d910c>] ? nmi_stack_correct+0x2f/0x34
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0150970>] ? __do_softirq+0x0/0x1d0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  <IRQ>
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01508f5>] ? irq_exit+0x65/0x70
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05df062>] ? do_IRQ+0x52/0xc0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01036b0>] ? common_interrupt+0x30/0x38
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c03a1fc2>] ? intel_idle+0xc2/0x160
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04daebb>] ? cpuidle_idle_call+0x6b/0x100
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0101dea>] ? cpu_idle+0x8a/0xf0
      Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d2702>] ? start_secondary+0x1e8/0x1ee
      
      Cc: David Miller <davem@davemloft.net>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Stephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d89081d
  4. 01 1月, 2011 1 次提交
  5. 26 12月, 2010 1 次提交
  6. 24 12月, 2010 3 次提交
  7. 23 12月, 2010 1 次提交
  8. 21 12月, 2010 1 次提交
    • E
      net_sched: sch_sfq: fix allot handling · aa3e2199
      Eric Dumazet 提交于
      When deploying SFQ/IFB here at work, I found the allot management was
      pretty wrong in sfq, even changing allot from short to int...
      
      We should init allot for each new flow, not using a previous value found
      in slot.
      
      Before patch, I saw bursts of several packets per flow, apparently
      denying the default "quantum 1514" limit I had on my SFQ class.
      
      class sfq 11:1 parent 11: 
       (dropped 0, overlimits 0 requeues 0) 
       backlog 0b 7p requeues 0 
       allot 11546 
      
      class sfq 11:46 parent 11: 
       (dropped 0, overlimits 0 requeues 0) 
       backlog 0b 1p requeues 0 
       allot -23873 
      
      class sfq 11:78 parent 11: 
       (dropped 0, overlimits 0 requeues 0) 
       backlog 0b 5p requeues 0 
       allot 11393 
      
      After patch, better fairness among each flow, allot limit being
      respected, allot is positive :
      
      class sfq 11:e parent 11: 
       (dropped 0, overlimits 0 requeues 86) 
       backlog 0b 3p requeues 86 
       allot 596 
      
      class sfq 11:94 parent 11: 
       (dropped 0, overlimits 0 requeues 0) 
       backlog 0b 3p requeues 0 
       allot 1468 
      
      class sfq 11:a4 parent 11: 
       (dropped 0, overlimits 0 requeues 0) 
       backlog 0b 4p requeues 0 
       allot 650 
      
      class sfq 11:bb parent 11: 
       (dropped 0, overlimits 0 requeues 0) 
       backlog 0b 3p requeues 0 
       allot 596 
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aa3e2199
  9. 20 12月, 2010 1 次提交
  10. 18 12月, 2010 2 次提交
  11. 17 12月, 2010 5 次提交
  12. 14 12月, 2010 3 次提交
  13. 11 12月, 2010 5 次提交
  14. 10 12月, 2010 1 次提交
  15. 09 12月, 2010 10 次提交
    • D
      econet: Fix crash in aun_incoming(). · 4e085e76
      David S. Miller 提交于
      Unconditional use of skb->dev won't work here,
      try to fetch the econet device via skb_dst()->dev
      instead.
      
      Suggested by Eric Dumazet.
      Reported-by: NNelson Elhage <nelhage@ksplice.com>
      Tested-by: NNelson Elhage <nelhage@ksplice.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4e085e76
    • E
      tcp: protect sysctl_tcp_cookie_size reads · f1987257
      Eric Dumazet 提交于
      Make sure sysctl_tcp_cookie_size is read once in
      tcp_cookie_size_check(), or we might return an illegal value to caller
      if sysctl_tcp_cookie_size is changed by another cpu.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: Ben Hutchings <bhutchings@solarflare.com>
      Cc: William Allen Simpson <william.allen.simpson@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f1987257
    • E
      tcp: avoid a possible divide by zero · ad9f4f50
      Eric Dumazet 提交于
      sysctl_tcp_tso_win_divisor might be set to zero while one cpu runs in
      tcp_tso_should_defer(). Make sure we dont allow a divide by zero by
      reading sysctl_tcp_tso_win_divisor exactly once.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad9f4f50
    • H
      mac80211: Fix BUG in pskb_expand_head when transmitting shared skbs · 7e244707
      Helmut Schaa 提交于
      mac80211 doesn't handle shared skbs correctly at the moment. As a result
      a possible resize can trigger a BUG in pskb_expand_head.
      
      [  676.030000] Kernel bug detected[#1]:
      [  676.030000] Cpu 0
      [  676.030000] $ 0   : 00000000 00000000 819662ff 00000002
      [  676.030000] $ 4   : 81966200 00000020 00000000 00000020
      [  676.030000] $ 8   : 819662e0 800043c0 00000002 00020000
      [  676.030000] $12   : 3b9aca00 00000000 00000000 00470000
      [  676.030000] $16   : 80ea2000 00000000 00000000 00000000
      [  676.030000] $20   : 818aa200 80ea2018 80ea2000 00000008
      [  676.030000] $24   : 00000002 800ace5c
      [  676.030000] $28   : 8199a000 8199bd20 81938f88 80f180d4
      [  676.030000] Hi    : 0000026e
      [  676.030000] Lo    : 0000757e
      [  676.030000] epc   : 801245e4 pskb_expand_head+0x44/0x1d8
      [  676.030000]     Not tainted
      [  676.030000] ra    : 80f180d4 ieee80211_skb_resize+0xb0/0x114 [mac80211]
      [  676.030000] Status: 1000a403    KERNEL EXL IE
      [  676.030000] Cause : 10800024
      [  676.030000] PrId  : 0001964c (MIPS 24Kc)
      [  676.030000] Modules linked in: mac80211_hwsim rt2800lib rt2x00soc rt2x00pci rt2x00lib mac80211 crc_itu_t crc_ccitt cfg80211 compat arc4 aes_generic deflate ecb cbc [last unloaded: rt2800pci]
      [  676.030000] Process kpktgend_0 (pid: 97, threadinfo=8199a000, task=81879f48, tls=00000000)
      [  676.030000] Stack : ffffffff 00000000 00000000 00000014 00000004 80ea2000 00000000 00000000
      [  676.030000]         818aa200 80f180d4 ffffffff 0000000a 81879f78 81879f48 81879f48 00000018
      [  676.030000]         81966246 80ea2000 818432e0 80f1a420 80203050 81814d98 00000001 81879f48
      [  676.030000]         81879f48 00000018 81966246 818432e0 0000001a 8199bdd4 0000001c 80f1b72c
      [  676.030000]         80203020 8001292c 80ef4aa2 7f10b55d 801ab5b8 81879f48 00000188 80005c90
      [  676.030000]         ...
      [  676.030000] Call Trace:
      [  676.030000] [<801245e4>] pskb_expand_head+0x44/0x1d8
      [  676.030000] [<80f180d4>] ieee80211_skb_resize+0xb0/0x114 [mac80211]
      [  676.030000] [<80f1a420>] ieee80211_xmit+0x150/0x22c [mac80211]
      [  676.030000] [<80f1b72c>] ieee80211_subif_start_xmit+0x6f4/0x73c [mac80211]
      [  676.030000] [<8014361c>] pktgen_thread_worker+0xfac/0x16f8
      [  676.030000] [<8002ebe8>] kthread+0x7c/0x88
      [  676.030000] [<80008e0c>] kernel_thread_helper+0x10/0x18
      [  676.030000]
      [  676.030000]
      [  676.030000] Code: 24020001  10620005  2502001f <0200000d> 0804917a  00000000  2502001f  00441023  00531021
      
      Fix this by making a local copy of shared skbs prior to mangeling them.
      To avoid copying the skb unnecessarily move the skb_copy call below the
      checks that don't need write access to the skb.
      
      Also, move the assignment of nh_pos and h_pos below the skb_copy to point
      to the correct skb.
      
      It would be possible to avoid another resize of the copied skb by using
      skb_copy_expand instead of skb_copy but that would make the patch more
      complex. Also, shared skbs are a corner case right now, so the resize
      shouldn't matter much.
      
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7e244707
    • T
      tcp: Replace time wait bucket msg by counter · 67631510
      Tom Herbert 提交于
      Rather than printing the message to the log, use a mib counter to keep
      track of the count of occurences of time wait bucket overflow.  Reduces
      spam in logs.
      Signed-off-by: NTom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      67631510
    • A
      x25: decrement netdev reference counts on unload · 171995e5
      Apollon Oikonomopoulos 提交于
      x25 does not decrement the network device reference counts on module unload.
      Thus unregistering any pre-existing interface after unloading the x25 module
      hangs and results in
      
       unregister_netdevice: waiting for tap0 to become free. Usage count = 1
      
      This patch decrements the reference counts of all interfaces in x25_link_free,
      the way it is already done in x25_link_device_down for NETDEV_DOWN events.
      Signed-off-by: NApollon Oikonomopoulos <apollon@noc.grnet.gr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      171995e5
    • M
      l2tp: Fix modalias of l2tp_ip · e8d34a88
      Michal Marek 提交于
      Using the SOCK_DGRAM enum results in
      "net-pf-2-proto-SOCK_DGRAM-type-115", so use the numeric value like it
      is done in net/dccp.
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e8d34a88
    • N
      econet: Do the correct cleanup after an unprivileged SIOCSIFADDR. · 0c62fc6d
      Nelson Elhage 提交于
      We need to drop the mutex and do a dev_put, so set an error code and break like
      the other paths, instead of returning directly.
      Signed-off-by: NNelson Elhage <nelhage@ksplice.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c62fc6d
    • E
      llc: fix a device refcount imbalance · 35d9b0c9
      Eric Dumazet 提交于
      Le dimanche 05 décembre 2010 à 12:23 +0100, Eric Dumazet a écrit :
      > Le dimanche 05 décembre 2010 à 09:19 +0100, Eric Dumazet a écrit :
      >
      > > Hmm..
      > >
      > > If somebody can explain why RTNL is held in arp_ioctl() (and therefore
      > > in arp_req_delete()), we might first remove RTNL use in arp_ioctl() so
      > > that your patch can be applied.
      > >
      > > Right now it is not good, because RTNL wont be necessarly held when you
      > > are going to call arp_invalidate() ?
      >
      > While doing this analysis, I found a refcount bug in llc, I'll send a
      > patch for net-2.6
      
      Oh well, of course I must first fix the bug in net-2.6, and wait David
      pull the fix in net-next-2.6 before sending this rcu conversion.
      
      Note: this patch should be sent to stable teams (2.6.34 and up)
      
      [PATCH net-2.6] llc: fix a device refcount imbalance
      
      commit abf9d537 (llc: add support for SO_BINDTODEVICE) added one
      refcount imbalance in llc_ui_bind(), because dev_getbyhwaddr() doesnt
      take a reference on device, while dev_get_by_index() does.
      
      Fix this using RCU locking. And since an RCU conversion will be done for
      2.6.38 for dev_getbyhwaddr(), put the rcu_read_lock/unlock exactly at
      their final place.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: stable@kernel.org
      Cc: Octavian Purdila <opurdila@ixiacom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      35d9b0c9
    • N
      tcp: Bug fix in initialization of receive window. · b1afde60
      Nandita Dukkipati 提交于
      The bug has to do with boundary checks on the initial receive window.
      If the initial receive window falls between init_cwnd and the
      receive window specified by the user, the initial window is incorrectly
      brought down to init_cwnd. The correct behavior is to allow it to
      remain unchanged.
      Signed-off-by: NNandita Dukkipati <nanditad@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b1afde60
  16. 08 12月, 2010 1 次提交
    • N
      sunrpc: prevent use-after-free on clearing XPT_BUSY · ed2849d3
      NeilBrown 提交于
      When an xprt is created, it has a refcount of 1, and XPT_BUSY is set.
      The refcount is *not* owned by the thread that created the xprt
      (as is clear from the fact that creators never put the reference).
      Rather, it is owned by the absence of XPT_DEAD.  Once XPT_DEAD is set,
      (And XPT_BUSY is clear) that initial reference is dropped and the xprt
      can be freed.
      
      So when a creator clears XPT_BUSY it is dropping its only reference and
      so must not touch the xprt again.
      
      However svc_recv, after calling ->xpo_accept (and so getting an XPT_BUSY
      reference on a new xprt), calls svc_xprt_recieved.  This clears
      XPT_BUSY and then svc_xprt_enqueue - this last without owning a reference.
      This is dangerous and has been seen to leave svc_xprt_enqueue working
      with an xprt containing garbage.
      
      So we need to hold an extra counted reference over that call to
      svc_xprt_received.
      
      For safety, any time we clear XPT_BUSY and then use the xprt again, we
      first get a reference, and the put it again afterwards.
      
      Note that svc_close_all does not need this extra protection as there are
      no threads running, and the final free can only be called asynchronously
      from such a thread.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Cc: stable@kernel.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      ed2849d3
反馈
建议
客服 返回
顶部