1. 12 1月, 2011 1 次提交
  2. 05 1月, 2011 7 次提交
    • J
      svcrpc: ensure cache_check caller sees updated entry · fdef7aa5
      J. Bruce Fields 提交于
      Supposes cache_check runs simultaneously with an update on a different
      CPU:
      
      	cache_check			task doing update
      	^^^^^^^^^^^			^^^^^^^^^^^^^^^^^
      
      	1. test for CACHE_VALID		1'. set entry->data
      	   & !CACHE_NEGATIVE
      
      	2. use entry->data		2'. set CACHE_VALID
      
      If the two memory writes performed in step 1' and 2' appear misordered
      with respect to the reads in step 1 and 2, then the caller could get
      stale data at step 2 even though it saw CACHE_VALID set on the cache
      entry.
      
      Add memory barriers to prevent this.
      Reviewed-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      fdef7aa5
    • J
      svcrpc: take lock on turning entry NEGATIVE in cache_check · 6bab93f8
      J. Bruce Fields 提交于
      We attempt to turn a cache entry negative in place.  But that entry may
      already have been filled in by some other task since we last checked
      whether it was valid, so we could be modifying an already-valid entry.
      If nothing else there's a likely leak in such a case when the entry is
      eventually put() and contents are not freed because it has
      CACHE_NEGATIVE set.
      
      So, take the cache_lock just as sunrpc_cache_update() does.
      Reviewed-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      6bab93f8
    • J
      svcrpc: simpler request dropping · 9e701c61
      J. Bruce Fields 提交于
      Currently we use -EAGAIN returns to determine when to drop a deferred
      request.  On its own, that is error-prone, as it makes us treat -EAGAIN
      returns from other functions specially to prevent inadvertent dropping.
      
      So, use a flag on the request instead.
      
      Returning an error on request deferral is still required, to prevent
      further processing, but we no longer need worry that an error return on
      its own could result in a drop.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      9e701c61
    • J
      svcrpc: avoid double reply caused by deferral race · d76d1815
      J. Bruce Fields 提交于
      Commit d29068c4 "sunrpc: Simplify cache_defer_req and related
      functions." asserted that cache_check() could determine success or
      failure of cache_defer_req() by checking the CACHE_PENDING bit.
      
      This isn't quite right.
      
      We need to know whether cache_defer_req() created a deferred request,
      in which case sending an rpc reply has become the responsibility of the
      deferred request, and it is important that we not send our own reply,
      resulting in two different replies to the same request.
      
      And the CACHE_PENDING bit doesn't tell us that; we could have
      succesfully created a deferred request at the same time as another
      thread cleared the CACHE_PENDING bit.
      
      So, partially revert that commit, to ensure that cache_check() returns
      -EAGAIN if and only if a deferred request has been created.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      Acked-by: NNeilBrown <neilb@suse.de>
      d76d1815
    • J
      SUNRPC: Remove more code when NFSD_DEPRECATED is not configured · bdd5f05d
      J. Bruce Fields 提交于
      Signed-off-by: NNeilBrown <neilb@suse.de>
      [bfields@redhat.com: moved svcauth_unix_purge outside ifdef's.]
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      bdd5f05d
    • J
      svcrpc: modifying valid sunrpc cache entries is racy · 31f7aa65
      J. Bruce Fields 提交于
      Once a sunrpc cache entry is VALID, we should be replacing it (and
      allowing any concurrent users to destroy it on last put) instead of
      trying to update it in place.
      
      Otherwise someone referencing the ip_map we're modifying here could try
      to use the m_client just as we're putting the last reference.
      
      The bug should only be seen by users of the legacy nfsd interfaces.
      
      (Thanks to Neil for suggestion to use sunrpc_invalidate.)
      Reviewed-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      31f7aa65
    • 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 6 次提交
  11. 17 12月, 2010 5 次提交
  12. 14 12月, 2010 3 次提交
  13. 11 12月, 2010 5 次提交
  14. 10 12月, 2010 1 次提交
  15. 09 12月, 2010 2 次提交
新手
引导
客服 返回
顶部