1. 23 Jun, 2010 5 commits
    • Dave Chinner's avatar
      xfs: remove block number from inode lookup code · 7b6259e7
      Dave Chinner authored
      The block number comes from bulkstat based inode lookups to shortcut
      the mapping calculations. We ar enot able to trust anything from
      bulkstat, so drop the block number as well so that the correct
      lookups and mappings are always done.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
    • Dave Chinner's avatar
      xfs: rename XFS_IGET_BULKSTAT to XFS_IGET_UNTRUSTED · 1920779e
      Dave Chinner authored
      Inode numbers may come from somewhere external to the filesystem
      (e.g. file handles, bulkstat information) and so are inherently
      untrusted. Rename the flag we use for these lookups to make it
      obvious we are doing a lookup of an untrusted inode number and need
      to verify it completely before trying to read it from disk.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
    • Dave Chinner's avatar
      xfs: validate untrusted inode numbers during lookup · 7124fe0a
      Dave Chinner authored
      When we decode a handle or do a bulkstat lookup, we are using an
      inode number we cannot trust to be valid. If we are deleting inode
      chunks from disk (default noikeep mode), then we cannot trust the on
      disk inode buffer for any given inode number to correctly reflect
      whether the inode has been unlinked as the di_mode nor the
      generation number may have been updated on disk.
      This is due to the fact that when we delete an inode chunk, we do
      not write the clusters back to disk when they are removed - instead
      we mark them stale to avoid them being written back potentially over
      the top of something that has been subsequently allocated at that
      location. The result is that we can have locations of disk that look
      like they contain valid inodes but in reality do not. Hence we
      cannot simply convert the inode number to a block number and read
      the location from disk to determine if the inode is valid or not.
      As a result, and XFS_IGET_BULKSTAT lookup needs to actually look the
      inode up in the inode allocation btree to determine if the inode
      number is valid or not.
      It should be noted even on ikeep filesystems, there is the
      possibility that blocks on disk may look like valid inode clusters.
      e.g. if there are filesystem images hosted on the filesystem. Hence
      even for ikeep filesystems we really need to validate that the inode
      number is valid before issuing the inode buffer read.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
    • Christoph Hellwig's avatar
      xfs: always use iget in bulkstat · 7dce11db
      Christoph Hellwig authored
      The non-coherent bulkstat versionsthat look directly at the inode
      buffers causes various problems with performance optimizations that
      make increased use of just logging inodes.  This patch makes bulkstat
      always use iget, which should be fast enough for normal use with the
      radix-tree based inode cache introduced a while ago.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
    • Dan Rosenberg's avatar
      xfs: prevent swapext from operating on write-only files · 1817176a
      Dan Rosenberg authored
      This patch prevents user "foo" from using the SWAPEXT ioctl to swap
      a write-only file owned by user "bar" into a file owned by "foo" and
      subsequently reading it.  It does so by checking that the file
      descriptors passed to the ioctl are also opened for reading.
      Signed-off-by: default avatarDan Rosenberg <dan.j.rosenberg@gmail.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
  2. 11 Jun, 2010 33 commits
  3. 10 Jun, 2010 2 commits
    • Eric Dumazet's avatar
      pkt_sched: gen_estimator: add a new lock · ae638c47
      Eric Dumazet authored
      gen_kill_estimator() / gen_new_estimator() is not always called with
      RTNL held.
      net/netfilter/xt_RATEEST.c is one user of these API that do not hold
      RTNL, so random corruptions can occur between "tc" and "iptables".
      Add a new fine grained lock instead of trying to use RTNL in netfilter.
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • John Fastabend's avatar
      net: deliver skbs on inactive slaves to exact matches · 597a264b
      John Fastabend authored
      Currently, the accelerated receive path for VLAN's will
      drop packets if the real device is an inactive slave and
      is not one of the special pkts tested for in
      skb_bond_should_drop().  This behavior is different then
      the non-accelerated path and for pkts over a bonded vlan.
      For example,
      vlanx -> bond0 -> ethx
      will be dropped in the vlan path and not delivered to any
      packet handlers at all.  However,
      bond0 -> vlanx -> ethx
      bond0 -> ethx
      will be delivered to handlers that match the exact dev,
      because the VLAN path checks the real_dev which is not a
      slave and netif_recv_skb() doesn't drop frames but only
      delivers them to exact matches.
      This patch adds a sk_buff flag which is used for tagging
      skbs that would previously been dropped and allows the
      skb to continue to skb_netif_recv().  Here we add
      logic to check for the deliver_no_wcard flag and if it
      is set only deliver to handlers that match exactly.  This
      makes both paths above consistent and gives pkt handlers
      a way to identify skbs that come from inactive slaves.
      Without this patch in some configurations skbs will be
      delivered to handlers with exact matches and in others
      be dropped out right in the vlan path.
      I have tested the following 4 configurations in failover modes
      and load balancing modes.
      # bond0 -> ethx
      # vlanx -> bond0 -> ethx
      # bond0 -> vlanx -> ethx
      # bond0 -> ethx
        vlanx -> --
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>