- 17 Oct, 2007 40 commits
-
-
Dave Hansen authored
I'm going to be modifying nfsd_rename() shortly to support read-only bind mounts. This #ifdef is around the area I'm patching, and it starts to get really ugly if I just try to add my new code by itself. Using this little helper makes things a lot cleaner to use. Signed-off-by:
Dave Hansen <haveblue@us.ibm.com> Acked-by:
Christoph Hellwig <hch@infradead.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Dave Hansen authored
First of all, this makes the structure jumping look a little bit cleaner. So, this stands alone as a tiny cleanup. But, we also need 'mnt' by itself a few more times later in this series, so this isn't _just_ a cleanup. Signed-off-by:
-
Dave Hansen authored
may_open() calls vfs_permission() before it does checks for IS_RDONLY(inode). It checks _again_ inside of vfs_permission(). The check inside of vfs_permission() is going away eventually. With the mnt_want/drop_write() functions, all of the r/o checks (except for this one) are consistently done before calling permission(). Because of this, I'd like to use permission() to hold a debugging check to make sure that the mnt_want/drop_write() calls are actually being made. So, to do this: 1. remove the IS_RDONLY() check from permission() 2. enforce that you must mnt_want_write() before even calling permission() 3. actually add the debugging check to permission() We need to rearrange may_open() to do r/o checks before calling permission(). Here's the patch. Signed-off-by:
-
Dave Hansen authored
Why do we need r/o bind mounts? This feature allows a read-only view into a read-write filesystem. In the process of doing that, it also provides infrastructure for keeping track of the number of writers to any given mount. This has a number of uses. It allows chroots to have parts of filesystems writable. It will be useful for containers in the future because users may have root inside a container, but should not be allowed to write to somefilesystems. This also replaces patches that vserver has had out of the tree for several years. It allows security enhancement by making sure that parts of your filesystem read-only (such as when you don't trust your FTP server), when you don't want to have entire new filesystems mounted, or when you want atime selectively updated. I've been using the following script to test that the feature is working as desired. It takes a directory and makes a regular bind and a r/o bind mount of it. It then performs some normal filesystem operations on the three directories, including ones that are expected to fail, like creating a file on the r/o mount. This patch: Some filesystems forego the vfs and may_open() and create their own 'struct file's. This patch creates a couple of helper functions which can be used by these filesystems, and will provide a unified place which the r/o bind mount code may patch. Also, rename an existing, static-scope init_file() to a less generic name. Signed-off-by:
-
Bjorn Helgaas authored
Add PNP debug message when adding a device, remove similar PNPACPI message with less information. Signed-off-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Adam Belay <ambx1@neo.rr.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by:
-
Bjorn Helgaas authored
Hoist the struct pnp_dev alloc up into the function where it's used. Signed-off-by:
-
Bjorn Helgaas authored
Use dev_info() for a little consistency. Changes this: pnp: 00:01: ioport range 0xf50-0xf58 has been reserved pnp: 00:01: ioport range 0x408-0x40f has been reserved pnp: 00:01: ioport range 0x900-0x903 has been reserved to this: system 00:01: ioport range 0xf50-0xf58 has been reserved system 00:01: ioport range 0x408-0x40f has been reserved system 00:01: ioport range 0x900-0x903 has been reserved Signed-off-by: -
Bjorn Helgaas authored
If we have the struct pnp_dev available, we can use dev_info(), dev_err(), etc., to give a little more information and consistency. [akpm@linux-foundation.org: fix warning] Signed-off-by:
-
Bjorn Helgaas authored
No functional change; just return errors early instead of putting the main part of the function inside an "if" statement. Signed-off-by:
-
Bjorn Helgaas authored
Remove some null pointer checks. Null pointers in these areas indicate programming errors, and I think it's better to oops immediately rather than return an error that is easily ignored. Signed-off-by:
-
Krzysztof Oledzki authored
Workaround for broken systems with BIOS that makes RTC interrupt level triggered and/or active low. See http://bugzilla.kernel.org/show_bug.cgi?id=5243 Based on the patch from Shaohua Li <shaohua.li@intel.com> Signed-off-by:
Krzysztof Piotr Oledzki <ole@ans.pl> Cc: "Li, Shaohua" <shaohua.li@intel.com> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Andi Kleen <ak@suse.de> Cc: Adam Belay <ambx1@neo.rr.com> Signed-off-by:
-
Jan Beulich authored
Most drivers for devices supporting ISA DMA can operate without DMA as well (falling back zo PIO). Thus it seems inappropriate for PNP to fail device initialization in case none of the possible DMA channels are available. Instead, it should be left to the driver to decide what to do if request_dma() fails. The patch at once adjusts the code to account for the fact that pnp_assign_dma() now doesn't need to report failure anymore. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Cc: Adam Belay <ambx1@neo.rr.com> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
-
Rafael J. Wysocki authored
pnpacpi_suspend() doesn't check the result returned by acpi_pm_device_sleep_state() before passing it to acpi_bus_set_power(), which may not be desirable. Make it select the target power state of the device using its second argument if acpi_pm_device_sleep_state() fails. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Looks-ok-to: Pavel Machek <pavel@ucw.cz> Cc: Adam Belay <ambx1@neo.rr.com> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
-
Miklos Szeredi authored
Define a new function fuse_refresh_attributes() that conditionally refreshes the attributes based on the validity timeout. In fuse_permission() only refresh the attributes for checking the execute bits if necessary. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
-
Miklos Szeredi authored
Don't return -ENOENT for a read() on the fuse device when the request was aborted. Instead return -ENODEV, meaning the filesystem has been force-umounted or aborted. Previously ENOENT meant that the request was interrupted, but now the 'aborted' flag is not set in case of interrupts. Signed-off-by:
-
Miklos Szeredi authored
Don't set 'aborted' flag on a request if it's interrupted. We have to wait for the answer anyway, and this would only a very little time while copying the reply. This means, that write() on the fuse device will not return -ENOENT during normal operation, only if the filesystem is aborted by a forced umount or through the fusectl interface. This could simplify userspace code somewhat when backward compatibility with earlier kernel versions is not required. Signed-off-by:
-
Miklos Szeredi authored
Move dput/mntput pair from request_end() to fuse_release_end(), because there's no other place they are used. Signed-off-by:
-
Miklos Szeredi authored
The VFS checks sticky bits on the parent directory even if the filesystem defines it's own ->permission(). In some situations (sshfs, mountlo, etc) the user does have permission to delete a file even if the attribute based checking would not allow it. So work around this by storing the permission bits separately and returning them in stat(), but cutting the permission bits off from inode->i_mode. This is slightly hackish, but it's probably not worth it to add new infrastructure in VFS and a slight performance penalty for all filesystems, just for the sake of fuse. [Jan Engelhardt] cosmetic fixes Signed-off-by:
-
Miklos Szeredi authored
fuse_permission() didn't refresh inode attributes before using them, even if the validity has already expired. Thanks to Junjiro Okajima for spotting this. Also remove some old code to unconditionally refresh the attributes on the root inode. Signed-off-by:
-
Miklos Szeredi authored
Aufs seems to depend on a positive i_nlink value. So fill in a dummy but sane value for the root inode at mount time. The inode attributes are refreshed with the correct values at the first opportunity. Signed-off-by:
-
Miklos Szeredi authored
Other than truncate, there are two cases, when fuse tries to get rid of cached pages: a) in open, if KEEP_CACHE flag is not set b) in getattr, if file size changed spontaneously Until now invalidate_mapping_pages() were used, which didn't get rid of mapped pages. This is wrong, and becomes more wrong as dirty pages are introduced. So instead properly invalidate all pages with invalidate_inode_pages2(). Signed-off-by:
-
Miklos Szeredi authored
Memory mappings were only truncated on an explicit truncate, but not when the file size was changed externally. Fix this by moving the truncation code from fuse_setattr to fuse_change_attributes. Yes, there are races between write and and external truncation, but we can't really do anything about them. Signed-off-by:
-
Miklos Szeredi authored
Make lifetime of 'struct fuse_file' independent from 'struct file' by adding a reference counter and destructor. This will enable asynchronous page writeback, where it cannot be guaranteed, that the file is not released while a request with this file handle is being served. The actual RELEASE request is only sent when there are no more references to the fuse_file. Signed-off-by:
-
Miklos Szeredi authored
Use wake_up_all instead of wake_up in put_reserved_req(), otherwise it is possible that the right task is not woken up. Also create a separate reserved_req_waitq in addition to the blocked_waitq, since they fulfill totally separate functions. Signed-off-by:
-
Miklos Szeredi authored
Set the read and write congestion state if the request queue is close to blocking, and clear it when it's not. This prevents unnecessary blocking in readahead and (when writable mmaps are allowed) writeback. Signed-off-by:
-
Jesper Juhl authored
The floppy drive is slow. These days I see absolutely no good reason why the floppy driver should try to gain a tiny bit of speed by telling gcc to optimize access to some variables via the register keyword. Better to just leave gcc free to do whatever optimizations it deduces to be sane and not hamper it by telling it that some variables in the floppy driver are special and need to be fast (they don't). Signed-off-by:
Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by:
-
Jesper Juhl authored
A good initial step for a cleanup seems to me to be getting rid of old dead code. This stuff is either commented out or inside '#if 0' so it is not currently in use at all, let's just get rid of it once and for all. That's a few lines less to deal with. Signed-off-by:
-
Jesper Juhl authored
Yes, some of this will likely be replaced in later patches, but I do not see anyone else coming out of the woodwork with any patches for this driver, so I'll ignore comments about churn. I want to get this driver cleaned up, and if I'm going to do so I want to start with this basic style cleanup to reduce the reading pain a bit. Signed-off-by:
-
Oleg Nesterov authored
Change migration_call(CPU_DEAD) to use direct spin_lock_irq() instead of task_rq_lock(rq->idle), rq->idle can't change its task_rq(). This makes the code a bit more symmetrical with migrate_dead_tasks()'s path which uses spin_lock_irq/spin_unlock_irq. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Cliff Wickman <cpw@sgi.com> Cc: Gautham R Shenoy <ego@in.ibm.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
-
Oleg Nesterov authored
Currently move_task_off_dead_cpu() is called under write_lock_irq(tasklist). This means it can't use task_lock() which is needed to improve migrating to take task's ->cpuset into account. Change the code to call move_task_off_dead_cpu() with irqs enabled, and change migrate_live_tasks() to use read_lock(tasklist). This all is a preparation for the futher changes proposed by Cliff Wickman, see http://marc.info/?t=117327786100003Signed-off-by:
-
NeilBrown authored
Whenever a read error is found, we should attempt to overwrite with correct data to 'fix' it. However when do a 'check' pass (which compares data blocks that are successfully read, but doesn't normally overwrite) we don't do that. We should. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
Iustin Pop authored
The 'degraded' attribute is useful to quickly determine if the array is degraded, instead of parsing 'mdadm -D' output or relying on the other techniques (number of working devices against number of defined devices, etc.). The md code already keeps track of this attribute, so it's useful to export it. Signed-off-by:
Iustin Pop <iusty@k1024.org> Signed-off-by:
-
NeilBrown authored
When an array is started read-only, MD_RECOVERY_NEEDED can be set but no recovery will be running. This causes 'sync_action' to report the wrong value. We could remove the test for MD_RECOVERY_NEEDED, but doing so would leave a small gap after requesting a sync action, where 'sync_action' would still report the old value. So make sure that for a read-only array, 'sync_action' always returns 'idle'. Signed-off-by:
-
NeilBrown authored
http://bugzilla.kernel.org/show_bug.cgi?id=3277 There is a seq_printf here that isn't being passed a 'seq'. Howeve as the code is inside #ifdef MD_DEBUG, nobody noticed. Also remove some extra spaces. Signed-off-by:
-
Adrian Bunk authored
bitmap_active() no longer exists and BITMAP_ACTIVE is no longer used. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Cc: Neil Brown <neilb@suse.de> Cc: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by:
-
Michael J. Evans authored
In current release kernels the md module (Software RAID) uses a static array (dev_t[128]) to store partition/device info temporarily for autostart. I discovered this (and that the devices are added as disks/partitions are discovered at boot) while I was debugging why only one of my MD arrays would come up whole, while all the others were short a disk. I eventually discovered that it was enumerating through all of 9 of my 11 hds (2 had only 4 partitions apiece) while the other 9 have 15 partitions (I wanted 64 per drive...). The last partition of the 8th drive in my 9 drive raid 5 sets wasn't added, thus making the final md array short both a parity and data disk, and it was started later, elsewhere. This patch replaces that static array with a list. [akpm@linux-foundation.org: removed unused var] Signed-off-by:
Michael J. Evans <mjevans1983@gmail.com> Cc: Neil Brown <neilb@suse.de> Signed-off-by:
-
Martin J. Bligh authored
Val's cross-port of the ext3 reservations code into ext2. [mbligh@mbligh.org: Small type error for printk [akpm@linux-foundation.org: fix types, sync with ext3] [mbligh@mbligh.org: Bring ext2 reservations code in line with latest ext3] [akpm@linux-foundation.org: kill noisy printk] [akpm@linux-foundation.org: remember to dirty the gdp's block] [akpm@linux-foundation.org: cross-port the missed 5dea5176] [akpm@linux-foundation.org: cross-port e6022603] [akpm@linux-foundation.org: Port the omitted 08fb306f] [akpm@linux-foundation.org: Backport the missed 20acaa18] [akpm@linux-foundation.org: fixes] [cmm@us.ibm.com: fix reservation extension] [bunk@stusta.de: make ext2_get_blocks() static] [hugh@veritas.com: fix hang] [hugh@veritas.com: ext2_new_blocks should reset the reservation window size] [hugh@veritas.com: ext2 balloc: fix off-by-one against rsv_end] [hugh@veritas.com: grp_goal 0 is a genuine goal (unlike -1), so ext2_try_to_allocate_with_rsv should treat it as such] [hugh@veritas.com: rbtree usage cleanup] [pbadari@us.ibm.com: Fix for ext2 reservation] [bunk@kernel.org: remove fs/ext2/balloc.c:reserve_blocks()] [hugh@veritas.com: ext2 balloc: use io_error label] Cc: "Martin J. Bligh" <mbligh@mbligh.org> Cc: Valerie Henson <val_henson@linux.intel.com> Cc: Mingming Cao <cmm@us.ibm.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by:
-
Fengguang Wu authored
We don't want to introduce pointless delays in throttle_vm_writeout() when the writeback limits are not yet exceeded, do we? Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: Pete Zaitcev <zaitcev@redhat.com> Cc: Greg KH <greg@kroah.com> Reviewed-by:
Rik van Riel <riel@redhat.com> Signed-off-by:
Fengguang Wu <wfg@mail.ustc.edu.cn> Signed-off-by:
-
Joern Engel authored
I_LOCK was used for several unrelated purposes, which caused deadlock situations in certain filesystems as a side effect. One of the purposes now uses the new I_SYNC bit. Also document the various bits and change their order from historical to logical. [bunk@stusta.de: make fs/inode.c:wake_up_inode() static] Signed-off-by:
Joern Engel <joern@wohnheim.fh-wedel.de> Cc: Dave Kleikamp <shaggy@linux.vnet.ibm.com> Cc: David Chinner <dgc@sgi.com> Cc: Anton Altaparmakov <aia21@cam.ac.uk> Cc: Al Viro <viro@ftp.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
Fengguang Wu authored
After making dirty a 100M file, the normal behavior is to start the writeback for all data after 30s delays. But sometimes the following happens instead: - after 30s: ~4M - after 5s: ~4M - after 5s: all remaining 92M Some analyze shows that the internal io dispatch queues goes like this: s_io s_more_io ------------------------- 1) 100M,1K 0 2) 1K 96M 3) 0 96M 1) initial state with a 100M file and a 1K file 2) 4M written, nr_to_write <= 0, so write more 3) 1K written, nr_to_write > 0, no more writes(BUG) nr_to_write > 0 in (3) fools the upper layer to think that data have all been written out. The big dirty file is actually still sitting in s_more_io. We cannot simply splice s_more_io back to s_io as soon as s_io becomes empty, and let the loop in generic_sync_sb_inodes() continue: this may starve newly expired inodes in s_dirty. It is also not an option to draw inodes from both s_more_io and s_dirty, an let the loop go on: this might lead to live locks, and might also starve other superblocks in sync time(well kupdate may still starve some superblocks, that's another bug). We have to return when a full scan of s_io completes. So nr_to_write > 0 does not necessarily mean that "all data are written". This patch introduces a flag writeback_control.more_io to indicate this situation. With it the big dirty file no longer has to wait for the next kupdate invocation 5s later. Cc: David Chinner <dgc@sgi.com> Cc: Ken Chen <kenchen@google.com> Signed-off-by:
-
