09 Nov, 2011
1 commit
-
The log item ops aren't nessecarily the biggest exploit vector, but marking
them const is easy enough. Also remove the unused xfs_item_ops_t typedef
while we're at it.Signed-off-by: Christoph Hellwig
Reviewed-by: Dave Chinner
Reviewed-by: Alex Elder
28 Jan, 2011
1 commit
-
After test 139, kmemleak shows:
unreferenced object 0xffff880078b405d8 (size 400):
comm "xfs_io", pid 4904, jiffies 4294909383 (age 1186.728s)
hex dump (first 32 bytes):
60 c1 17 79 00 88 ff ff 60 c1 17 79 00 88 ff ff `..y....`..y....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[] kmemleak_alloc+0x2d/0x60
[] kmem_cache_alloc+0x13f/0x2b0
[] kmem_zone_alloc+0x77/0xf0
[] kmem_zone_zalloc+0x1e/0x50
[] xfs_efi_init+0x4b/0xb0
[] xfs_trans_get_efi+0x58/0x90
[] xfs_bmap_finish+0x8b/0x1d0
[] xfs_itruncate_finish+0x2c4/0x5d0
[] xfs_setattr+0x8df/0xa70
[] xfs_vn_setattr+0x1b/0x20
[] notify_change+0x170/0x2e0
[] do_truncate+0x66/0xa0
[] sys_ftruncate+0xdb/0xe0
[] system_call_fastpath+0x16/0x1b
[] 0xffffffffffffffffThe cause of the leak is that the "remove" parameter of IOP_UNPIN()
is never set when a CIL push is aborted. This means that the EFI
item is never freed if it was in the push being cancelled. The
problem is specific to delayed logging, but has uncovered a couple
of problems with the handling of IOP_UNPIN(remove).Firstly, we cannot safely call xfs_trans_del_item() from IOP_UNPIN()
in the CIL commit failure path or the iclog write failure path
because for delayed loging we have no transaction context. Hence we
must only call xfs_trans_del_item() if the log item being unpinned
has an active log item descriptor.Secondly, xfs_trans_uncommit() does not handle log item descriptor
freeing during the traversal of log items on a transaction. It can
reference a freed log item descriptor when unpinning an EFI item.
Hence it needs to use a safe list traversal method to allow items to
be removed from the transaction during IOP_UNPIN().Signed-off-by: Dave Chinner
Reviewed-by: Alex Elder
20 Dec, 2010
2 commits
-
EFI/EFD interactions are protected from races by the AIL lock. They
are the only type of log items that require the the AIL lock to
serialise internal state, so they need to be separated from the AIL
lock before we can do bulk insert operations on the AIL.To acheive this, convert the counter of the number of extents in the
EFI to an atomic so it can be safely manipulated by EFD processing
without locks. Also, convert the EFI state flag manipulations to use
atomic bit operations so no locks are needed to record state
changes. Finally, use the state bits to determine when it is safe to
free the EFI and clean up the code to do this neatly.Signed-off-by: Dave Chinner
Reviewed-by: Christoph Hellwig -
XFS_EFI_CANCELED has not been set in the code base since
xfs_efi_cancel() was removed back in 2006 by commit
065d312e15902976d256ddaf396a7950ec0350a8 ("[XFS] Remove unused
iop_abort log item operation), and even then xfs_efi_cancel() was
never called. I haven't tracked it back further than that (beyond
git history), but it indicates that the handling of EFIs in
cancelled transactions has been broken for a long time.Basically, when we get an IOP_UNPIN(lip, 1); call from
xfs_trans_uncommit() (i.e. remove == 1), if we don't free the log
item descriptor we leak it. Fix the behviour to be correct and kill
the XFS_EFI_CANCELED flag.Signed-off-by: Dave Chinner
Reviewed-by: Christoph Hellwig
27 Jul, 2010
5 commits
-
By making this member a void pointer we can get rid of a lot of pointless
casts.Signed-off-by: Christoph Hellwig
Reviewed-by: Dave Chinner -
Stop the function pointer casting madness and give all the xfs_item_ops the
correct prototypes.Signed-off-by: Christoph Hellwig
Reviewed-by: Dave Chinner -
The unpin_remove item operation instances always share most of the
implementation with the respective unpin implementation. So instead
of keeping two different entry points add a remove flag to the unpin
operation and share the code more easily.Signed-off-by: Christoph Hellwig
Reviewed-by: Dave Chinner -
Currently we track log item descriptor belonging to a transaction using a
complex opencoded chunk allocator. This code has been there since day one
and seems to work around the lack of an efficient slab allocator.This patch replaces it with dynamically allocated log item descriptors
from a dedicated slab pool, linked to the transaction by a linked list.This allows to greatly simplify the log item descriptor tracking to the
point where it's just a couple hundred lines in xfs_trans.c instead of
a separate file. The external API has also been simplified while we're
at it - the xfs_trans_add_item and xfs_trans_del_item functions to add/
delete items from a transaction have been simplified to the bare minium,
and the xfs_trans_find_item function is replaced with a direct dereference
of the li_desc field. All debug code walking the list of log items in
a transaction is down to a simple list_for_each_entry.Note that we could easily use a singly linked list here instead of the
double linked list from list.h as the fastpath only does deletion from
sequential traversal. But given that we don't have one available as
a library function yet I use the list.h functions for simplicity.Signed-off-by: Christoph Hellwig
Reviewed-by: Dave Chinner -
Dmapi support was never merged upstream, but we still have a lot of hooks
bloating XFS for it, all over the fast pathes of the filesystem.This patch drops over 700 lines of dmapi overhead. If we'll ever get HSM
support in mainline at least the namespace events can be done much saner
in the VFS instead of the individual filesystem, so it's not like this
is much help for future work.Signed-off-by: Christoph Hellwig
Reviewed-by: Dave Chinner
19 May, 2010
2 commits
-
The staleness of a object being unpinned can be directly derived
from the object itself - there is no need to extract it from the
object then pass it as a parameter into IOP_UNPIN().This means we can kill the XFS_LID_BUF_STALE flag - it is set,
checked and cleared in the same places XFS_BLI_STALE flag in the
xfs_buf_log_item so it is now redundant and hence safe to remove.Signed-off-by: Dave Chinner
Reviewed-by: Christoph Hellwig -
Each log item type does manual initialisation of the log item.
Delayed logging introduces new fields that need initialisation, so
factor all the open coded initialisation into a common function
first.Signed-off-by: Dave Chinner
Reviewed-by: Christoph Hellwig
22 Jan, 2010
1 commit
-
This macro only obsfucates the log item type assignments, so kill it.
Signed-off-by: Christoph Hellwig
Reviewed-by: Dave Chinner
Signed-off-by: Alex Elder
30 Oct, 2008
3 commits
-
Change all the remaining AIL API functions that are passed struct
xfs_mount pointers to pass pointers directly to the struct xfs_ail being
used. With this conversion, all external access to the AIL is via the
struct xfs_ail. Hence the operation and referencing of the AIL is almost
entirely independent of the xfs_mount that is using it - it is now much
more tightly tied to the log and the items it is tracking in the log than
it is tied to the xfs_mount.SGI-PV: 988143
SGI-Modid: xfs-linux-melb:xfs-kern:32353a
Signed-off-by: David Chinner
Signed-off-by: Lachlan McIlroy
Signed-off-by: Christoph Hellwig -
Add an xfs_ail pointer to log items so that the log items can reference
the AIL directly during callbacks without needed a struct xfs_mount.SGI-PV: 988143
SGI-Modid: xfs-linux-melb:xfs-kern:32352a
Signed-off-by: David Chinner
Signed-off-by: Lachlan McIlroy
Signed-off-by: Christoph Hellwig -
Bring the ail lock inside the struct xfs_ail. This means the AIL can be
entirely manipulated via the struct xfs_ail rather than needing both the
struct xfs_mount and the struct xfs_ail.SGI-PV: 988143
SGI-Modid: xfs-linux-melb:xfs-kern:32350a
Signed-off-by: David Chinner
Signed-off-by: Lachlan McIlroy
Signed-off-by: Christoph Hellwig
28 Jul, 2008
1 commit
-
kmem_free() function takes (ptr, size) arguments but doesn't actually use
second one.This patch removes size argument from all callsites.
SGI-PV: 981498
SGI-Modid: xfs-linux-melb:xfs-kern:31050aSigned-off-by: Denys Vlasenko
Signed-off-by: David Chinner
Signed-off-by: Lachlan McIlroy
07 Feb, 2008
1 commit
-
SGI-PV: 970382
SGI-Modid: xfs-linux-melb:xfs-kern:29739aSigned-off-by: Donald Douwsma
Signed-off-by: Eric Sandeen
Signed-off-by: Tim Shimmin
15 Oct, 2007
1 commit
-
One of the perpetual scaling problems XFS has is indexing it's incore
inodes. We currently uses hashes and the default hash sizes chosen can
only ever be a tradeoff between memory consumption and the maximum
realistic size of the cache.As a result, anyone who has millions of inodes cached on a filesystem
needs to tunes the size of the cache via the ihashsize mount option to
allow decent scalability with inode cache operations.A further problem is the separate inode cluster hash, whose size is based
on the ihashsize but is smaller, and so under certain conditions (sparse
cluster cache population) this can become a limitation long before the
inode hash is causing issues.The following patchset removes the inode hash and cluster hash and
replaces them with radix trees to avoid the scalability limitations of the
hashes. It also reduces the size of the inodes by 3 pointers....SGI-PV: 969561
SGI-Modid: xfs-linux-melb:xfs-kern:29481aSigned-off-by: David Chinner
Signed-off-by: Christoph Hellwig
Signed-off-by: Tim Shimmin
10 Feb, 2007
1 commit
-
gcc-4.1 and more recent aggressively inline static functions which
increases XFS stack usage by ~15% in critical paths. Prevent this from
occurring by adding noinline to the STATIC definition.Also uninline some functions that are too large to be inlined and were
causing problems with CONFIG_FORCED_INLINING=y.Finally, clean up all the different users of inline, __inline and
__inline__ and put them under one STATIC_INLINE macro. For debug kernels
the STATIC_INLINE macro uninlines those functions.SGI-PV: 957159
SGI-Modid: xfs-linux-melb:xfs-kern:27585aSigned-off-by: David Chinner
Signed-off-by: David Chatterton
Signed-off-by: Tim Shimmin
28 Sep, 2006
1 commit
-
SGI-PV: 955302
SGI-Modid: xfs-linux-melb:xfs-kern:26747aSigned-off-by: Eric Sandeen
Signed-off-by: Nathan Scott
Signed-off-by: Tim Shimmin
20 Jun, 2006
1 commit
-
pure bloat.
SGI-PV: 952969
SGI-Modid: xfs-linux-melb:xfs-kern:26251aSigned-off-by: Nathan Scott
09 Jun, 2006
1 commit
-
64bit kernels allow recovery to handle both versions and do the necessary
decodingSGI-PV: 952214
SGI-Modid: xfs-linux-melb:xfs-kern:26011aSigned-off-by: Tim Shimmin
Signed-off-by: Nathan Scott
02 Nov, 2005
2 commits
-
boilerplate.
SGI-PV: 913862
SGI-Modid: xfs-linux:xfs-kern:23903aSigned-off-by: Nathan Scott
-
SGI-PV: 943122
SGI-Modid: xfs-linux:xfs-kern:23901aSigned-off-by: Nathan Scott
02 Sep, 2005
1 commit
-
SGI-PV: 931456
SGI-Modid: xfs-linux:xfs-kern:23155aSigned-off-by: Tim Shimmin
Signed-off-by: Nathan Scott
21 Jun, 2005
2 commits
-
SGI-PV: 938062
SGI-Modid: xfs-linux:xfs-kern:194415aSigned-off-by: Christoph Hellwig
Signed-off-by: Nathan Scott -
SGI-PV: 936255
SGI-Modid: xfs-linux:xfs-kern:192760aSigned-off-by: Christoph Hellwig
Signed-off-by: Nathan Scott
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
