On Tue, 2007-12-04 at 15:05 -0500, Mathieu Desnoyers wrote:
* Dave Hansen ([EMAIL PROTECTED]) wrote:
On Tue, 2007-12-04 at 14:25 -0500, Mathieu Desnoyers wrote:
- I also dump the equivalent of /proc/swaps (with kernel internal
information) at trace start to know what swap files
Or, think out of the box...
Maybe you can introduce some interfaces that expose information both in
sysfs (in normal human-readable formats) and in a way that lets you get
the same data out in some binary format.
Seems to me you'll have a lot easier time justifying all of these lines
of code
On Wed, 2007-12-05 at 20:07 +0530, Bharata B Rao wrote:
In this approach, the cached dirents are given offsets in the form of
linearly increasing indices/cookies (like 0, 1, 2,...). This helps us to
uniformly define offsets across all the directories of the union
irrespective of the type of
On Wed, 2007-12-05 at 20:08 +0530, Bharata B Rao wrote:
Remove the existing readdir implementation.
You may have had a better description in your 0/5 mail, but this is what
goes into the git log in the end, so I think you need to beef this up a
bit.
-- Dave
--
To unsubscribe from this list:
On Thu, 2007-12-06 at 11:01 +0100, Jan Blunck wrote:
Rather than give each _dirent_ an offset, could we give each sub-mount
an offset? Let's say we have three members comprising a union mount
directory. The first has 100 dirents, the second 200, and the third
10,000. When the first
On Tue, 2007-11-27 at 10:26 +0800, WANG Cong wrote:
@@ -414,7 +418,7 @@ int sparse_add_one_section(struct zone *
out:
pgdat_resize_unlock(pgdat, flags);
if (ret = 0)
- __kfree_section_memmap(memmap, nr_pages);
+ kfree(usemap);
return
On Wed, 2007-11-28 at 09:09 -0500, Mathieu Desnoyers wrote:
===
--- linux-2.6-lttng.orig/mm/filemap.c 2007-11-28 08:38:46.0 -0500
+++ linux-2.6-lttng/mm/filemap.c 2007-11-28 08:59:05.0 -0500
@@ -514,9 +514,13
On Wed, 2007-11-28 at 00:41 -0800, Andrew Morton wrote:
Given that nameidata_to_filp() can call path_release() which destroys the
original nameidata, it looks like this was always buggy?
It does. I can see how I introduced the bug, and your fix does look
like a good one. Thanks.
-- Dave
-
On Wed, 2007-11-28 at 21:34 -0500, Mathieu Desnoyers wrote:
Before I start digging deeper in checking whether it is already
instrumented by the fs instrumentation (and would therefore be
redundant), is there a particular data structure from mm/ that you
suggest taking the swap file number and
On Wed, 2007-12-26 at 15:12 +0100, Christoph Hellwig wrote:
Btw, I just noticed in current -mm fs_may_remount_ro() is still around
and not replaced by ther per-sb writers count. That surely sounds like
some kind of mismerge..
I was actually leaving that for later. Getting rid of the filp
On Mon, 2007-12-31 at 11:54 -0800, Dave Hansen wrote:
On Wed, 2007-12-26 at 15:12 +0100, Christoph Hellwig wrote:
Btw, I just noticed in current -mm fs_may_remount_ro() is still around
and not replaced by ther per-sb writers count. That surely sounds like
some kind of mismerge..
I
writable mounts during a remount.
The alternative to doing this is to do a much simpler list
of mounts for each superblock. I could also code that up
to see what it look like. Shouldn't be too bad.
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
linux-2.6.git-dave/fs/file_table.c | 24
if
cpu_writer was passed in as NULL, the patch seems good.
Yeah, I screwed that up. Should be fixed now.
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
linux-2.6.git-dave/fs/file_table.c | 24 -
linux-2.6.git-dave/fs/namespace.c| 134
On Fri, 2007-10-26 at 14:37 -0600, Eric W. Biederman wrote:
+static int pid_in_pid_ns(struct pid *pid, struct pid_namespace *ns)
+{
+ return pid (ns-level = pid-level)
+ pid-numbers[ns-level].ns == ns;
+}
Could we blow this out a little bit? (I think the blown-out
On Mon, 2007-10-29 at 11:59 -0600, Eric W. Biederman wrote:
ier to read.) Also, can
we think of any better name for this? It seems a bit funky that:
pid_in_pid_ns(mypid, init_pid_ns);
would _ever_ return 0.
It can't.
So, it isn't truly a test for belonging *in* a
I'm seeing these in the latest git:
kernel/marker.c: In function `marker_probe_unregister':
kernel/marker.c:355: warning: `probe_module' might be used uninitialized in
this function
kernel/marker.c: In function `marker_probe_unregister_private_data':
kernel/marker.c:389: warning: `probe_module'
On Tue, 2007-10-30 at 22:08 -0400, Mathieu Desnoyers wrote:
* Dave Hansen ([EMAIL PROTECTED]) wrote:
I'm seeing these in the latest git:
kernel/marker.c: In function `marker_probe_unregister':
kernel/marker.c:355: warning: `probe_module' might be used uninitialized in
this function
On Sat, 2007-10-20 at 10:56 -0400, Rik van Riel wrote:
I just tried it. In the latest git tree, autofs still works.
The regression is in -mm only.
Andrew,
Rik tracked it down to an interaction with futexes from the pid
namespace code. I believe r/o bind mounts are innocent for now.
--
I just noticed this in mainline:
kernel/cgroup.c: In function `proc_cgroupstats_show':
kernel/cgroup.c:2405: warning: unused variable `root'
---
linux-2.6.git-dave/kernel/cgroup.c |1 -
1 file changed, 1 deletion(-)
diff -puN kernel/cgroup.c~cgroup-warning kernel/cgroup.c
---
reason that it was done this way? Was it ever tested?
-- Dave
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 65a70b7..cbbf35d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -115,7 +115,8 @@ config ARCH_HAS_CPU_RELAX
config
On Mon, 2008-02-11 at 17:24 +0100, Jan-Bernd Themann wrote:
the eHEA patch belongs to a patchset that is usually
added by Jeff Garzik once this dependency (EXPORTS)
is resolved.
I know that's already in mainline but, man, that code is nasty. It has
stuff indented 7 levels or so and is
On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
are you the right person to address this patch to?
You might want to check the top of the file. ;)
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
On Mon, 2008-02-11 at 17:24 +0100, Jan-Bernd Themann wrote:
Drivers like eHEA need memory notifiers in order to
update their internal DMA memory map when memory is added
to or removed from the system.
Patch for eHEA memory hotplug support that uses these functions:
On Mon, 2008-02-11 at 16:57 +0100, Jan-Bernd Themann wrote:
Drivers like eHEA need memory notifiers in order to
update their internal DMA memory map when memory is added
to or removed from the system.
Could you post this with the new users as well so we can make sure
they're not abusing this
On Tue, 2008-02-12 at 15:03 -0800, Badari Pulavarty wrote:
Here is the version with your suggestion. Do you like this better ?
I do like how it looks, better, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Tue, 2008-02-12 at 14:07 -0800, Badari Pulavarty wrote:
On Tue, 2008-02-12 at 13:57 -0800, Dave Hansen wrote:
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
+static void __remove_section(struct zone *zone, unsigned long
section_nr)
+{
+ if (!valid_section_nr
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
+ /*
+* Its ugly, but this is the best I can do - HELP !!
+* We don't know where the allocations for section memmap and usemap
+* came from. If they are allocated at the boot time, they would come
+* from
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
+static void __remove_section(struct zone *zone, unsigned long
section_nr)
+{
+ if (!valid_section_nr(section_nr))
+ return;
+
+ unregister_memory_section(__nr_to_section(section_nr));
+
On Tue, 2008-02-12 at 09:22 -0800, Badari Pulavarty wrote:
+static void __remove_section(struct zone *zone, unsigned long phys_start_pfn)
+{
+ if (!pfn_valid(phys_start_pfn))
+ return;
I think you need at least a WARN_ON() there.
I'd probably also not use pfn_valid(),
On Mon, 2008-02-11 at 17:24 +0100, Jan-Bernd Themann wrote:
Drivers like eHEA need memory notifiers in order to
update their internal DMA memory map when memory is added
to or removed from the system.
Patch for eHEA memory hotplug support that uses these functions:
On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
Constraints imposed by HW / FW:
- eHEA has own MMU
- eHEA Memory Regions (MRs) are used by the eHEA MMU to translate virtual
addresses to absolute addresses (like DMA mapped memory on a PCI bus)
- The number of MRs is limited
On Thu, 2008-02-14 at 09:46 +0100, Christoph Raisch wrote:
Dave Hansen [EMAIL PROTECTED] wrote on 13.02.2008 18:05:00:
On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
Constraints imposed by HW / FW:
- eHEA has own MMU
- eHEA Memory Regions (MRs) are used by the eHEA MMU
On Thu, 2008-02-14 at 09:36 -0800, Badari Pulavarty wrote:
I am not sure what you are trying to do with walk_memory_resource().
The
behavior is different on ppc64. Hotplug memory usage assumes that all
the memory resources (all system memory, not just IOMEM) are
represented
in
On 10/20/2012 01:29 AM, Mel Gorman wrote:
I'm travelling at the moment so apologies that I have not followed up on
this. My problem is still the same with the patch - it changes more
headers than is necessary and it is sparsemem specific. At minimum, try
the suggestion of
if
On 11/06/2012 11:53 AM, Srivatsa S. Bhat wrote:
This is the main change - we keep the pageblocks in region-sorted order,
where pageblocks belonging to region-0 come first, followed by those belonging
to region-1 and so on. But the pageblocks within a given region need *not* be
sorted, since we
On 11/06/2012 11:52 AM, Srivatsa S. Bhat wrote:
But of course, memory regions are sub-divisions *within* a node, so it makes
sense to keep the data-structures in the node's struct pglist_data. (Thus
this placement makes memory regions parallel to zones in that node).
I think it's pretty silly
On 10/18/2012 03:20 PM, Andrew Morton wrote:
On Wed, 17 Oct 2012 08:09:55 -0700
Dave Hansen d...@linux.vnet.ibm.com wrote:
+#ifdef CONFIG_MEMORY_FAILURE
+static void clear_hwpoisoned_pages(struct page *memmap, int nr_pages)
+{
+ int i;
+
+ if (!memmap)
+ return;
I guess
On 10/24/2012 12:54 PM, Andrew Morton wrote:
hmpf. This patch worries me. If there are people out there who are
regularly using drop_caches because the VM sucks, it seems pretty
obnoxious of us to go dumping stuff into their syslog. What are they
supposed to do? Stop using drop_caches?
On 10/24/2012 02:06 PM, Borislav Petkov wrote:
On Wed, Oct 24, 2012 at 01:48:36PM -0700, Andrew Morton wrote:
Well who knows. Could be that people's vm *does* suck. Or they have
some particularly peculiar worklosd or requirement[*]. Or their VM
*used* to suck, and the drop_caches is not really
On 10/24/2012 03:48 PM, Borislav Petkov wrote:
On Wed, Oct 24, 2012 at 02:18:38PM -0700, Dave Hansen wrote:
Sounds fairly valid to me. But, it's also one that would not be harmed
or disrupted in any way because of a single additional printk() during
each suspend-to-disk operation.
back
On 10/25/2012 02:24 AM, Borislav Petkov wrote:
But let's discuss this a bit further. So, for the benchmarking aspect,
you're either going to have to always require dmesg along with
benchmarking results or /proc/vmstat, depending on where the drop_caches
stats end up.
Is this how you
On 10/26/2012 02:59 AM, Lai Jiangshan wrote:
Current free_area_init_core() has incorrect adjustment code to adjust
-present_pages. It will cause -present_pages overflow, make the
system unusable(can't create any process/thread in our test) and cause
further problem.
Details:
1) Some/many
On 11/09/2012 07:23 AM, Srivatsa S. Bhat wrote:
FWIW, kernbench is actually (and surprisingly) showing a slight performance
*improvement* with this patchset, over vanilla 3.7-rc3, as I mentioned in
my other email to Dave.
https://lkml.org/lkml/2012/11/7/428
I don't think I can dismiss it
On 10/12/2012 05:57 AM, Michal Hocko wrote:
I would like to resurrect the following Dave's patch. The last time it
has been posted was here https://lkml.org/lkml/2010/9/16/250 and there
didn't seem to be any strong opposition.
Kosaki was worried about possible excessive logging when somebody
Hi Wen,
+#ifdef CONFIG_MEMORY_FAILURE
+static void clear_hwpoisoned_pages(struct page *memmap, int nr_pages)
+{
+ int i;
+
+ if (!memmap)
+ return;
I guess free_section_usemap() does the same thing.
+ for (i = 0; i PAGES_PER_SECTION; i++) {
+ if
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 [EMAIL PROTECTED]
---
lxc-dave/fs/namei.c
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
. When that is complete, we can actually
introduce code that will safely check the counts before
allowing r/w-r/o transitions to occur.
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/namespace.c| 54 +
lxc-dave/include/linux/mount.h
-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/open.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff -puN fs/open.c~make-access-use-helper fs/open.c
--- lxc/fs/open.c~make-access-use-helper2007-09-20 12:16:13.0
-0700
+++ lxc-dave/fs/open.c 2007-09-20
-by: Dave Hansen [EMAIL PROTECTED]
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
---
lxc-dave/fs/ext2/ioctl.c | 46 +-
lxc-dave/fs/ext3/ioctl.c | 100 +---
lxc-dave/fs/ext4/ioctl.c | 105
Some ioctls need write access, but others don't. Make a helper
function to decide when write access is needed, and take it.
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/ncpfs/ioctl.c | 54 +-
1 file changed, 53 insertions(+), 1
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/namei.c | 10 ++
1 file changed, 10 insertions(+)
diff -puN fs/namei.c~elevate-write-count-for-link-and-symlink-calls fs/namei.c
--- lxc/fs/namei.c~elevate-write-count-for-link
-off-by: Dave Hansen [EMAIL PROTECTED]
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
---
lxc-dave/fs/open.c | 39 ++-
1 file changed, 30 insertions(+), 9 deletions(-)
diff -puN fs/open.c~elevate-writer-count-for-chown-and-friends fs/open.c
--- lxc/fs/open.c
Pretty self-explanatory. Fits in with the rest of the series.
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
---
lxc-dave/fs/namei.c|5 +
lxc-dave/fs/nfsd/nfs4recover.c |4
2 files changed, 9 insertions(+)
diff -puN fs
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
---
lxc-dave/net/unix/af_unix.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff -puN
net/unix/af_unix.c~unix-find-other-elevate-write-count-for-touch-atime
net/unix
two are probably unnecessary and duplicate existing
checks in the VFS. This won't make them better checks than
before, but it will make them detect r/o mounts.
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/nfs/dir.c |3 ++-
lxc-dave
This also uses the little helper in the NFS code to
make an if() a little bit less ugly. We introduced
the helper at the beginning of the series.
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
---
lxc-dave/fs/namei.c|4
lxc-dave/fs/nfsd
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 [EMAIL PROTECTED]
---
lxc-dave/fs/namei.c |8
1 file changed, 4 insertions(+), 4
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
---
lxc-dave/fs/inode.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff -puN fs/inode.c~elevate-write-count-for-file_update_time fs/inode.c
--- lxc/fs/inode.c~elevate-write
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/open.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff -puN fs/open.c~elevate-writer-count-for-do-sys-truncate fs/open.c
--- lxc/fs/open.c~elevate-writer
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/utimes.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff -puN fs/utimes.c~elevate-write-count-for-do-utimes fs/utimes.c
--- lxc/fs/utimes.c~elevate-write
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/inode.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff -puN fs/inode.c~elevate-write-count-for-do-sys-utime-and-touch-atime
fs/inode.c
--- lxc/fs
This basically audits the callers of xattr_permission(), which
calls permission() and can perform writes to the filesystem.
This conflicts with the current (~2.6.23-rc7) audit
git tree in -mm. wiggle'ing the patch merges it.
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
Signed-off-by: Dave
file,
while the vfsmount is ro. That is bad.
Some filesystems forego the use of normal vfs calls to create
struct files. Make sure that these users elevate the mnt writer
count because they will get __fput(), and we need to make
sure they're balanced.
Signed-off-by: Dave Hansen [EMAIL PROTECTED
outside of the switch.
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/namei.c | 32 +---
lxc-dave/fs/nfsd/vfs.c |4
lxc-dave/net/unix/af_unix.c |4
3 files changed, 29
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/namei.c |4
lxc-dave/ipc/mqueue.c |5 -
2 files changed, 8 insertions(+), 1 deletion(-)
diff -puN fs/namei.c~elevate-mnt-writers-for-vfs-unlink-callers fs/namei.c
Elevate the write count during the vfs_rmdir() call.
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
---
lxc-dave/fs/namei.c |5 +
1 file changed, 5 insertions(+)
diff -puN fs/namei.c~do-rmdir-elevate-write-count fs/namei.c
--- lxc/fs/namei.c
mounts.)
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/namespace.c| 205 ++---
lxc-dave/include/linux/mount.h |8 +
2 files changed, 198 insertions(+), 15 deletions(-)
diff -puN fs/namespace.c~numa_mnt_want_write fs/namespace.c
' operation.
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/namespace.c| 46 ++---
lxc-dave/include/linux/mount.h |1
2 files changed, 40 insertions(+), 7 deletions(-)
diff -puN fs/namespace.c~honor-r-w-changes-at-do-remount-time fs
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 [EMAIL PROTECTED]
---
lxc-dave/fs/namei.c
On Fri, 2007-09-21 at 01:17 -0700, Andrew Morton wrote:
On Thu, 20 Sep 2007 12:52:57 -0700 Dave Hansen [EMAIL PROTECTED] wrote:
+ ret = mnt_want_write(filp-f_vfsmnt);
It still creeps me out that we have this sprinkled *all over* the tree and
people will forget to do
On Fri, 2007-09-21 at 16:03 -0700, Andrew Morton wrote:
Dave Hansen [EMAIL PROTECTED] wrote:
Some ioctl()s can cause writes to the filesystem. Take
these, and make them use mnt_want/drop_write() instead.
We need to pass the filp one layer deeper in XFS, but
somebody _just_ pulled
On Mon, 2007-09-24 at 08:58 -0400, [EMAIL PROTECTED] wrote:
do_times passes an unitialized vfsmount into mnt_want_write. Here's
the quick fix (untested), but the right fix is to restructure the complete
mess do_utimes is (never let a libc developer write your kernel code.. :)):
Close -
On Mon, 2007-09-24 at 09:26 -0700, Andrew Morton wrote:
On Mon, 24 Sep 2007 13:51:05 +0400 Alexey Dobriyan [EMAIL PROTECTED] wrote:
static void lock_and_coalesce_cpu_mnt_writer_counts(void)
{
int cpu;
struct mnt_writer *cpu_writer;
for_each_possible_cpu(cpu) {
[c0427207] prepare_namespace+0x89/0x187
[c0426cdd] kernel_init+0x9a/0xa3
[c010336f] kernel_thread_helper+0x7/0x10
===
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/namespace.c |2 ++
1 file changed, 2 insertions(+)
diff -puN fs/namespace.c~make-lockdep
On Mon, 2007-09-24 at 18:54 +0100, Christoph Hellwig wrote:
As we already say in various messages the percpu counters in here
look rather fishy. I'd recomment to take a look at the per-cpu
superblock counters in XFS as they've been debugged quite well
now and could probably be lifted into a
This is on top of the ext2-reservations.patch in -mm.
The original r/o bind mount set didn't address the new
ext2 ioctl: EXT2_IOC_SETRSVSZ, because it doesn't exist
in mainline. This fixes that up for -mm.
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/ext2/ioctl.c | 17
-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/ext2/ioctl.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff -puN fs/ext2/ioctl.c~ext2-reservations-take-writer-count fs/ext2/ioctl.c
--- lxc/fs/ext2/ioctl.c~ext2-reservations-take-writer-count 2007-09-24
13
On Sun, 2007-09-23 at 23:17 -0700, Andrew Morton wrote:
It look like a false positive to me, but really, for a patchset of this
complexity and maturity I cannot fathom how it could have escaped any
lockdep testing.
I test with lockdep all the time. The problem was that lockdep doesn't
On Mon, 2007-09-24 at 15:25 -0700, Andrew Morton wrote:
hm. I saw that warning on my 2-way. It has CONFIG_NR_CPUS=8 so perhaps
the kernel has decided that this machine can possibly have eight CPUs.
It's an old super-micro board, doesn't have ACPI.
Well, it's looking like we only set
On Mon, 2007-09-24 at 16:15 -0700, Andrew Morton wrote:
On Mon, 24 Sep 2007 16:05:37 -0700
Dave Hansen [EMAIL PROTECTED] wrote:
On Mon, 2007-09-24 at 15:25 -0700, Andrew Morton wrote:
hm. I saw that warning on my 2-way. It has CONFIG_NR_CPUS=8 so perhaps
the kernel has decided
curious, do you have a normal program that uses mknod(2) this way?
I'd like to add it to my test scripts.
Acked-by: Dave Hansen [EMAIL PROTECTED]
-- Dave
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Wed, 2007-09-26 at 01:14 +0200, Miklos Szeredi wrote:
I get this at umount, if there was a failed open():
WARNING: at fs/namespace.c:586 __mntput()
I think the problem is that may_open() calls mnt_want_write(), but if
open doesn't succeed, mnt_drop_write() will not be called.
I see
On Wed, 2007-09-26 at 01:14 +0200, Miklos Szeredi wrote:
I get this at umount, if there was a failed open():
WARNING: at fs/namespace.c:586 __mntput()
I think the problem is that may_open() calls mnt_want_write(), but if
open doesn't succeed, mnt_drop_write() will not be called.
Does this
On Fri, 2007-09-21 at 01:17 -0700, Andrew Morton wrote:
On Thu, 20 Sep 2007 12:52:57 -0700 Dave Hansen [EMAIL PROTECTED] wrote:
+ ret = mnt_want_write(filp-f_vfsmnt);
It still creeps me out that we have this sprinkled *all over* the tree and
people will forget to do it and there's
On Wed, 2007-09-26 at 10:38 +0200, Miklos Szeredi wrote:
On Wed, 2007-09-26 at 01:14 +0200, Miklos Szeredi wrote:
I get this at umount, if there was a failed open():
WARNING: at fs/namespace.c:586 __mntput()
I think the problem is that may_open() calls mnt_want_write(), but if
On Wed, 2007-09-26 at 10:38 +0200, Miklos Szeredi wrote:
In __dentry_open() there's still a few places where fput() won't be
called, notably when -open fails, which is what I'm triggering I
think.
Also even more horrible things can happen because of the
nd-intent.open.file thing. For
On Wed, 2007-09-26 at 19:50 +0200, Miklos Szeredi wrote:
Maybe. Can we do the mnt_want_write() from __dentry_open(), instead
of may_open()? That would be a lot cleaner.
I'll explore that. It may make very good sense.
Btw, may_open() doesn't do mnt_want_write() around the truncation if
The first three patches here fix actual bugs. I think
the last two will reduce the chance for any future bugs
to creep in. RFC for now.
--
This is a bug fix for the r/o bind mount patch set.
We need to ensure taking a mnt write on the mnt
referenced by any new struct file.
---
If open_namei() succeeds, there is potentially a mnt_want_write()
that needs to get balanced. If the caller doesn't create a
'struct file' and eventually __fput() it, or manually drop the
write count on an error, we have a bug.
Forcing open_namei() to return a filp fixes this. Any caller
In a moment, we're going to make may_open() stop doing
the mnt_want/drop_write() pair. Doing this first makes
the next patch simpler.
---
lxc-dave/fs/namei.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff -puN
My end goal here is to make sure all users of may_open()
return filps. This will ensure that we properly release
mount write counts which were taken for the filp in
may_open().
This patch moves the sys_open flags to namei flags
calculation into fs/namei.c. We'll shortly be moving
the
may_open() can fail in a lot of ways. It is also named
such that it doesn't appear to be _taking_ action, just
checking a bunch of conditions.
So, it makes a poor place to take and release the mnt
writer count. This moves the burder of taking the
mnt writer counts into the callers. The
This kills off the almost empty do_filp_open(). However,
let's keep filp_open() around. It does the nameidata allocation
on the stack, and also adds the AT_FDCWD argument. I think
that's enough to keep it around.
---
lxc-dave/fs/open.c | 40 ++--
1 file
On Thu, 2007-09-27 at 12:48 -0700, Andrew Morton wrote:
Hi, Dave!
It's fully reproducible.
/home is mounted with the following options:
/dev/mapper/vglinux1-lvhome on /home type reiserfs
(rw,noatime,nodiratime,user_xattr)
This BUG happened with rc8-mm1 too.
rc6-mm1 works
On Thu, 2007-09-27 at 21:26 +0100, Christoph Hellwig wrote:
Dave will probably find a bandaid to work around this, but the
right fix is to stop using a file struct here entirely. If you
look at reiserfs_xattr_set it's not actually used at all except
for passing it to -prepare_write and
On Thu, 2007-09-27 at 22:04 +0100, Christoph Hellwig wrote:
On Thu, Sep 27, 2007 at 01:53:39PM -0700, Dave Hansen wrote:
-int reiserfs_commit_write(struct file *f, struct page *page,
- unsigned from, unsigned to);
-int reiserfs_prepare_write(struct file *f, struct page
, this should probably go in there.
In general, I think reiser4 also lets the 'struct file' get way too deep
into its internals. For instance, I would expect reiser4_write_extent()
to take a plain inode, not a 'struct file'.
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/reiser4
In a moment, we're going to make may_open() stop doing
the mnt_want/drop_write() pair. Doing this first makes
the next patch simpler.
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/namei.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions
getting a 'struct file' back must consider that filp instantiated
and fput() it normally. The callers no longer have to worry about
ever manually releasing a mnt write count.
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
---
lxc-dave/fs/namei.c | 16
lxc-dave/fs/open.c
101 - 200 of 9732 matches
Mail list logo
