Commit Graph

56 Commits

Author SHA1 Message Date
Daniel Drake f246315e1a [PATCH] procfs: Fix hardlink counts for /proc/<PID>/task
The current logic assumes that a /proc/<PID>/task directory should have a
hardlink count of 3, probably counting ".", "..", and a directory for a
single child task.

It's fairly obvious that this doesn't work out correctly when a PID has
more than one child task, which is quite often the case.

Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01 08:59:03 -07:00
Daniel Drake bcf88e1163 [PATCH] procfs: Fix hardlink counts
The pid directories in /proc/ currently return the wrong hardlink count - 3,
when there are actually 4 : ".", "..", "fd", and "task".

This is easy to notice using find(1):
	cd /proc/<pid>
	find

In the output, you'll see a message similar to:

find: WARNING: Hard link count is wrong for .: this may be a bug in your
filesystem driver.  Automatically turning on find's -noleaf option.
Earlier results may have failed to include directories that should have
been searched.

http://bugs.gentoo.org/show_bug.cgi?id=86031

I also noticed that CONFIG_SECURITY can add a 5th: attr, and performed a
similar fix on the task directories too.

Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01 08:59:03 -07:00
Steve Grubb 456be6cd90 [AUDIT] LOGIN message credentials
Attached is a new patch that solves the issue of getting valid credentials 
into the LOGIN message. The current code was assuming that the audit context 
had already been copied. This is not always the case for LOGIN messages.

To solve the problem, the patch passes the task struct to the function that 
emits the message where it can get valid credentials.

Signed-off-by: Steve Grubb <sgrubb@redhat.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2005-04-29 17:30:07 +01:00
Martin Hicks 4c4c402d6c [PATCH] meminfo: add Cached underflow check
Working on some code lately I've been getting huge values for "Cached".
The cause is that get_page_cache_size() is an approximate value, and for a
sufficiently small returned value of get_page_cache_size() the value
underflows.

Signed-off-by:  Martin Hicks <mort@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:24:08 -07:00
Andrea Arcangeli 79befd0c08 [PATCH] oom-killer disable for iscsi/lvm2/multipath userland critical sections
iscsi/lvm2/multipath needs guaranteed protection from the oom-killer, so
make the magical value of -17 in /proc/<pid>/oom_adj defeat the oom-killer
altogether.

(akpm: we still need to document oom_adj and friends in
Documentation/filesystems/proc.txt!)

Signed-off-by: Andrea Arcangeli <andrea@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:24:05 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00