1. 28 6月, 2012 5 次提交
  2. 27 6月, 2012 5 次提交
  3. 26 6月, 2012 1 次提交
  4. 23 6月, 2012 2 次提交
  5. 22 6月, 2012 1 次提交
  6. 21 6月, 2012 5 次提交
  7. 20 6月, 2012 10 次提交
  8. 19 6月, 2012 1 次提交
  9. 18 6月, 2012 3 次提交
    • S
      ftrace: Make all inline tags also include notrace · 93b3cca1
      Steven Rostedt 提交于
      Commit 5963e317 ("ftrace/x86: Do not change stacks in DEBUG when
      calling lockdep") prevented lockdep calls from the int3 breakpoint handler
      from reseting the stack if a function that was called was in the process
      of being converted for tracing and had a breakpoint on it. The idea is,
      before calling the lockdep code, do a load_idt() to the special IDT that
      kept the breakpoint stack from reseting. This worked well as a quick fix
      for this kernel release, until a certain config caused a lockup in the
      function tracer start up tests.
      
      Investigating it, I found that the load_idt that was used to prevent
      the int3 from changing stacks was itself being traced!
      
      Even though the config had CONFIG_OPTIMIZE_INLINING disabled, and
      all 'inline' tags were set to always inline, there were still cases that
      it did not inline! This was caused by CONFIG_PARAVIRT_GUEST, where it
      would add a pointer to the native_load_idt() which made that function
      to be traced.
      
      Commit 45959ee7 ("ftrace: Do not function trace inlined functions")
      only touched the 'inline' tags when CONFIG_OPMITIZE_INLINING was enabled.
      PARAVIRT_GUEST shows that this was not enough and we need to also
      mark always_inline with notrace as well.
      Reported-by: NFengguang Wu <wfg@linux.intel.com>
      Tested-by: NFengguang Wu <wfg@linux.intel.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      93b3cca1
    • T
      NFSv4.1: Fix umount when filelayout DS is also the MDS · 2a4c8994
      Trond Myklebust 提交于
      Currently there is a 'chicken and egg' issue when the DS is also the mounted
      MDS. The nfs_match_client() reference from nfs4_set_ds_client bumps the
      cl_count, the nfs_client is not freed at umount, and nfs4_deviceid_purge_client
      is not called to dereference the MDS usage of a deviceid which holds a
      reference to the DS nfs_client.  The result is the umount program returns,
      but the nfs_client is not freed, and the cl_session hearbeat continues.
      
      The MDS (and all other nfs mounts) lose their last nfs_client reference in
      nfs_free_server when the last nfs_server (fsid) is umounted.
      The file layout DS lose their last nfs_client reference in destroy_ds
      when the last deviceid referencing the data server is put and destroy_ds is
      called. This is triggered by a call to nfs4_deviceid_purge_client which
      removes references to a pNFS deviceid used by an MDS mount.
      
      The fix is to track how many pnfs enabled filesystems are mounted from
      this server, and then to purge the device id cache once that count reaches
      zero.
      Reported-by: NJorge Mora <Jorge.Mora@netapp.com>
      Reported-by: NAndy Adamson <andros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      2a4c8994
    • C
      {nl,cfg,mac}80211: implement dot11MeshHWMPconfirmationInterval · 728b19e5
      Chun-Yeow Yeoh 提交于
      As defined in section 13.10.9.3 Case D (802.11-2012), this
      control variable is used to limit the mesh STA to send only
      one PREQ to a root mesh STA within this interval of time
      (in TUs). The default value for this variable is set to
      2000 TUs. However, for current implementation, the maximum
      configurable of dot11MeshHWMPconfirmationInterval is
      restricted by dot11MeshHWMPactivePathTimeout.
      Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com>
      [line-break commit log]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      728b19e5
  10. 16 6月, 2012 7 次提交
    • P
      netfilter: add user-space connection tracking helper infrastructure · 12f7a505
      Pablo Neira Ayuso 提交于
      There are good reasons to supports helpers in user-space instead:
      
      * Rapid connection tracking helper development, as developing code
        in user-space is usually faster.
      
      * Reliability: A buggy helper does not crash the kernel. Moreover,
        we can monitor the helper process and restart it in case of problems.
      
      * Security: Avoid complex string matching and mangling in kernel-space
        running in privileged mode. Going further, we can even think about
        running user-space helpers as a non-root process.
      
      * Extensibility: It allows the development of very specific helpers (most
        likely non-standard proprietary protocols) that are very likely not to be
        accepted for mainline inclusion in the form of kernel-space connection
        tracking helpers.
      
      This patch adds the infrastructure to allow the implementation of
      user-space conntrack helpers by means of the new nfnetlink subsystem
      `nfnetlink_cthelper' and the existing queueing infrastructure
      (nfnetlink_queue).
      
      I had to add the new hook NF_IP6_PRI_CONNTRACK_HELPER to register
      ipv[4|6]_helper which results from splitting ipv[4|6]_confirm into
      two pieces. This change is required not to break NAT sequence
      adjustment and conntrack confirmation for traffic that is enqueued
      to our user-space conntrack helpers.
      
      Basic operation, in a few steps:
      
      1) Register user-space helper by means of `nfct':
      
       nfct helper add ftp inet tcp
      
       [ It must be a valid existing helper supported by conntrack-tools ]
      
      2) Add rules to enable the FTP user-space helper which is
         used to track traffic going to TCP port 21.
      
      For locally generated packets:
      
       iptables -I OUTPUT -t raw -p tcp --dport 21 -j CT --helper ftp
      
      For non-locally generated packets:
      
       iptables -I PREROUTING -t raw -p tcp --dport 21 -j CT --helper ftp
      
      3) Run the test conntrackd in helper mode (see example files under
         doc/helper/conntrackd.conf
      
       conntrackd
      
      4) Generate FTP traffic going, if everything is OK, then conntrackd
         should create expectations (you can check that with `conntrack':
      
       conntrack -E expect
      
          [NEW] 301 proto=6 src=192.168.1.136 dst=130.89.148.12 sport=0 dport=54037 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=192.168.1.136 master-dst=130.89.148.12 sport=57127 dport=21 class=0 helper=ftp
      [DESTROY] 301 proto=6 src=192.168.1.136 dst=130.89.148.12 sport=0 dport=54037 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=192.168.1.136 master-dst=130.89.148.12 sport=57127 dport=21 class=0 helper=ftp
      
      This confirms that our test helper is receiving packets including the
      conntrack information, and adding expectations in kernel-space.
      
      The user-space helper can also store its private tracking information
      in the conntrack structure in the kernel via the CTA_HELP_INFO. The
      kernel will consider this a binary blob whose layout is unknown. This
      information will be included in the information that is transfered
      to user-space via glue code that integrates nfnetlink_queue and
      ctnetlink.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      12f7a505
    • P
      netfilter: ctnetlink: add CTA_HELP_INFO attribute · ae243bee
      Pablo Neira Ayuso 提交于
      This attribute can be used to modify and to dump the internal
      protocol information.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      ae243bee
    • P
      netfilter: nfnetlink_queue: add NAT TCP sequence adjustment if packet mangled · 8c88f87c
      Pablo Neira Ayuso 提交于
      User-space programs that receive traffic via NFQUEUE may mangle packets.
      If NAT is enabled, this usually puzzles sequence tracking, leading to
      traffic disruptions.
      
      With this patch, nfnl_queue will make the corresponding NAT TCP sequence
      adjustment if:
      
      1) The packet has been mangled,
      2) the NFQA_CFG_F_CONNTRACK flag has been set, and
      3) NAT is detected.
      
      There are some records on the Internet complaning about this issue:
      http://stackoverflow.com/questions/260757/packet-mangling-utilities-besides-iptables
      
      By now, we only support TCP since we have no helpers for DCCP or SCTP.
      Better to add this if we ever have some helper over those layer 4 protocols.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      8c88f87c
    • P
      netfilter: add glue code to integrate nfnetlink_queue and ctnetlink · 9cb01766
      Pablo Neira Ayuso 提交于
      This patch allows you to include the conntrack information together
      with the packet that is sent to user-space via NFQUEUE.
      
      Previously, there was no integration between ctnetlink and
      nfnetlink_queue. If you wanted to access conntrack information
      from your libnetfilter_queue program, you required to query
      ctnetlink from user-space to obtain it. Thus, delaying the packet
      processing even more.
      
      Including the conntrack information is optional, you can set it
      via NFQA_CFG_F_CONNTRACK flag with the new NFQA_CFG_FLAGS attribute.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      9cb01766
    • P
      netfilter: nf_ct_helper: implement variable length helper private data · 1afc5679
      Pablo Neira Ayuso 提交于
      This patch uses the new variable length conntrack extensions.
      
      Instead of using union nf_conntrack_help that contain all the
      helper private data information, we allocate variable length
      area to store the private helper data.
      
      This patch includes the modification of all existing helpers.
      It also includes a couple of include header to avoid compilation
      warnings.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      1afc5679
    • R
      vga_switcheroo.h: fix pci_dev warning · f8fee8f5
      Randy Dunlap 提交于
      Fix warnings on some architectures/configs (not on x86):
      
      include/linux/vga_switcheroo.h:28:30: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
      include/linux/vga_switcheroo.h:28:30: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Cc:	Takashi Iwai <tiwai@suse.de>
      Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      f8fee8f5
    • H
      swap: fix shmem swapping when more than 8 areas · 9b15b817
      Hugh Dickins 提交于
      Minchan Kim reports that when a system has many swap areas, and tmpfs
      swaps out to the ninth or more, shmem_getpage_gfp()'s attempts to read
      back the page cannot locate it, and the read fails with -ENOMEM.
      
      Whoops.  Yes, I blindly followed read_swap_header()'s pte_to_swp_entry(
      swp_entry_to_pte()) technique for determining maximum usable swap
      offset, without stopping to realize that that actually depends upon the
      pte swap encoding shifting swap offset to the higher bits and truncating
      it there.  Whereas our radix_tree swap encoding leaves offset in the
      lower bits: it's swap "type" (that is, index of swap area) that was
      truncated.
      
      Fix it by reducing the SWP_TYPE_SHIFT() in swapops.h, and removing the
      broken radix_to_swp_entry(swp_to_radix_entry()) from read_swap_header().
      
      This does not reduce the usable size of a swap area any further, it
      leaves it as claimed when making the original commit: no change from 3.0
      on x86_64, nor on i386 without PAE; but 3.0's 512GB is reduced to 128GB
      per swapfile on i386 with PAE.  It's not a change I would have risked
      five years ago, but with x86_64 supported for ten years, I believe it's
      appropriate now.
      
      Hmm, and what if some architecture implements its swap pte with offset
      encoded below type? That would equally break the maximum usable swap
      offset check.  Happily, they all follow the same tradition of encoding
      offset above type, but I'll prepare a check on that for next.
      Reported-and-Reviewed-and-Tested-by: NMinchan Kim <minchan@kernel.org>
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Cc: stable@vger.kernel.org [3.1, 3.2, 3.3, 3.4]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9b15b817